It’s been in the pipe for a while, it’s now available!
We are very pleased to announce that today (21 Aug,2019), /e/cloud services can be installed on any server for self-hosting!
You can now manage and host your mail, drive, etc. for your family or corporate, using a single identity on your own custom domain, and connect it with your/e/OS smartphone.
This is nice to hear, although I don’t have any experience in Linux server administration so it might take me a while before I can work out how to set it up!
How does this link to the /e/ account? If we set up our /e/ smartphones with our self-hosted /e/ services does that replace our /e/ account? What if we already have an /e/ account, do we effectively have two accounts which we need to link our smartphones to?
We have not tested this case with two /e/ account on a single smartphone. It’s not supposed to work well.
So I think it’s better to choose between the two, or use self hosting for specific usage.
I have been following /e/ for some time but unfortunately neither of my “spare” Android phones are supported yet, but this announcement right here is enough to convince me to buy one of the refurbished phones with /e/ preinstalled and give it a try!
My server OS of choice is CentOS. Have you tried deploying the self hosting stack on CentOS yet? If not I will try it and report back if I run into any major issues.
I don’t have Linux server experience. Could we imagine a future implementation of this for a Synology NAS ? With the user-friendness of Synology home-user products
For support of embedded “SoC” hardware (ARM etc.) maybe have a look at making your script work on alpine linux, this very compact OS natively supports running in ram for example and to only save system state on demand, i.e. after system changes. (Running in RAM completely avoids constant wear on and predictable breaking of the system’s sdcard, or flash memory corruption (“bricking”) on sudden power failures).
Hi @cedricoola at present the self hosting is in beta. We will be working towards making it more user friendly and easy for people who are not exactly all that technical to install.
Looks awesome!!! Very nice job /e/ team… Can’t wait to try it!
and @madbilly and @cedricoola the whole web basically runs on linux so I think it’s time for all three of us to get our hands on some linux server!!! ( I have as little experience as you do but am more than eager to try it out as soon as I build my server from raspberry pi cluster)
As /e/ Cloud server is based on nextcloud do you know if could be possible to install some nextcloudapps? there are some others interesting apps, like OnlyOffice that you have add.
More than have one phone attached to one or more /e/Cloud server[s], will be more interesting and effective (:= less implementations to take care of) considering the federation capabilities of actual NC servers https://docs.nextcloud.com/server/stable/admin_manual/search.html?q=federation&check_keywords=yes&area=default. In the present announce from Gael the concept of “single sign on” to one /e/Cloud is embedded. Combine this /e/ feature with NC-federation feature may give results actually not available on proprietary solutions.
Thanks @GaelDuval. So we can host all the same services as ecloud, but only actually use a subset of them? For example, I might not want to use the email server built into this self-hosting image, but I would like to use everything else. So in this case I would have both my ecloud and self-hosted accounts active on my /e/OS smartphone and would have to choose which account I’m using each time I accessed, for example, drive, notes, calendar, etc.
This sounds fine, but I can’t help wondering what the advantage of this package is over just self-hosting nextcloud locally? I think Nextcloud can now be installed as a Snap, so is even easier than Docker as far as I understand (from my armchair!).
Any more explanations will be much appreciated.
Thanks
The /e/OS single identity is a question of integration of all those services.
When using it, all you have to do in /e/OS is login once with your /e/ identity, and everything works:
local data is synchronized with drive
@e.email works in the email client
calendar works in calendar application
notes works in notes application
tasks works in tasks application
(This is a similar behaviour as what you would find in iOS or Android with Google.)
And you can retrieve all those data server side with a single login too.
Of course, geeks don’t care about this because they don’t mind entering their login/password in various services again and again. But /e/OS is not targetting geeks.
That’s the reason why we are providing those self-hosting packages for server, for convience, because achieving the same result from the various components we are using (NextCloud, Postfix, Dovecot…) is a complex thing.
Most people will probably prefer to use https://ecloud.global, but we wanted to release the server package too, for the few people who have doubts about what we’re doing with user data at ecloud.global.
Thanks @GaelDuval. So this is almost the same software as runs in ecloud.global, but when running is completely separate and unrelated to ecloud.global? No /e/ account is needed to run the self-hosted version at all?
This makes me think about what Mozilla are doing with their IoT project WebThings Gateway. They produce an image which will run on a raspberry pi and as part of the initial set-up the user can create a domain at *.mozilla-iot.org. The RPi tunnels to a Mozilla server which only hosts the IP address for this domain; all traffic is tunnelled back to the RPi. This approach removes the hassle from the end user of having to register a domain name, get a static IP address from their ISP, configure their router, etc. If someone wants to run the Webthings Gateway without using the mozilla-iot.org domain name then they can reconfigure the RPi to do this.
In a later phase, would /e/ consider doing this? For example you could allow people to create domains *.ecloud.global (for example), provide the IP address and tunnel but running the server would be the user’s responsibility. The /e/ account could still be used for logging into both ecloud.global and the self-hosted version, with no need to mess around with different accounts on the smartphone. I can see how this might complicate the process of providing services for this account in ecloud.global, but maybe instead of providing the full service you can provide an encrypted cloud backup service for key data which the user consider wants to keep available if their server crashes. Maybe the data could be encrypted with a private key which only the user should know, this would help reassure people that /e/ aren’t spying. The initial setup process for the self-hosted server could ask if there is a backup in ecloud.global that the user wants to restore. Or even without a cloud backup the initial set up could ask the user if they want to download all the data from the ecloud.global servers which currently exists for that account, so that the self-hosted server can take over from the cloud server more easily (otherwise transporting data between the two could be messy, especially emails).
Please excuse the brain dump; once I started typing I could foresee lots of possibilities!
Thanks for clarification.
Since I’ve been thinking about self-hosting I might try this, if I find time, but I think porting to ARM will be beyond me!
Cheers
