Thanks. That's a really important comment about a critical issue. We don't want to sacrifice security. This isn't as straightforward in the Docker world as apt-get update + upgrade. I'll find out how my organisation does this currently. Also, I think think should be a requirement of the solution "It must be a single bash command to get the latest security patches".

Otherwise I'd consider it a security nightmare with a jungle of not properly maintained docker images.

A simple fix is to make official Sovereign Docker images that are vetted for security. It could be a part of the Sovereign value proposition that these Docker images are locked-down.

I really like this idea. How complicated is it to build your own docker images?

Excellent work on all this! Here's my pie-in-the-sky wish list:

• Add a Samba domain controller to the mix for unified auth and multi-user management. Should be pretty straightforward for all the apps that support LDAP.
• Add Leanote to the mix.
• Replace RoundCube, Z-Push and the contacts/calendar portion of OwnCloud/NextCloud with SoGO.
• Replace cgit/gitolite with GoGit.
• It seems a little redundant to have both MySQL and PostgreSQL installed. Can the architecture be consolidated down to one DB?

I think using Docker images will make it much harder as those images need an individual update. Or in that case we are better of splitting sovereign into individual services and each service is the one that builds the docker image.
My biggest issue with sovereign is that it is not modular enough to configure which services I want to install in my server. I see that is the intention of using the docker images,(and in my ignorant opinion) I feel using the playbook with more modular roles is a simpler solution.

My biggest issue with sovereign is that it is not modular enough

This was what prevented me from using sovereign, since it has many interdependent parts (and also because it had many services I don't need, and I wanted to learn ansible/ configuration management in general).

I'm still following development here as I consider it high quality work and the commit log is very instructive; feel free to borrow ideas from my (personal, wouldn't yet recommend for production use) ansible based self-hosting solution at https://github.com/nodiscc/srv01 - it is not as feature complete as sovereign but I think it solves the modularity problem (roles are sometimes interconnected but it takes advantage of ansible's tagging system). Criticism and bug reports are also welcome.

I'm not very interested in Docker based containerization but I'd like to learn/work on seccomp/LXC/... based sandboxing in the future.

Best of luck with future work on sovereign

@nodiscc Your self-hosting solution at https://github.com/nodiscc/srv01 is very intresting, thanks for sharing the link. I'am working on something compareable see https://github.com/return42/handsOn.

handsOn was created for german users, the description is in german: http://return42.github.io/handsOn

But I guess, with a little bash knowledge, reading the scripts https://github.com/return42/handsOn/tree/master/scripts and with a look at the templates https://github.com/return42/handsOn/tree/master/templates everyone will see how my setups are made.

@return42 with all respect I would not use your project at all; and I don't think it can actually be used to improve sovereign. Sovereign's only indesirable characteristic is interdependence of roles. Regarding handsOn

• cloc reports 4000+ lines of Shell scripts... ಠ_ಠ
• Improper quoting, improper use of comparison operators, shellcheck scripts/* reports hundreds of errors/warnings...
• No idempotence at all
• (Apparently?) tight coupling between components
• No configuration hardening
• No english documentation

This is just a list of few things you could improve (hint: you might be better off starting from scratch and using configuration management).

Re. sovereign 2: I would definitely use something based on/similar to DebOps ansible playbooks, which can actually be run separately, but with an added layer that eases configuration/customization (which Sovereign is actually good at, and was a great inspiration for my work - single config file). A docker-container approach is the complete opposite of this, and as others have said, would be a security/maintenance nightmare.

@nodiscc: As I wrote, handsOn is for german audience. It focus on productivity AND education, describing the setups in detail to give the audiance a chance to admin in a different context. It's far from what sovereign is (no plug&play character). I gave the link to show how my service-setups are / if someone is intrested e.g to see how to place this or that service behind an apache instance (your speach: "feel free to borrow ideas from my"). If there is nothing for you, leaf it.

Anyway, thanks for your hints. Good point, I have to lint my scripts ;) ... BTW:

ShellCheck does not attempt to figure out runtime or dynamic assignments like with source ...

.. one reason for the hundreds of errors :o

@return42 I understand; juste a note that if you use it for educational purposes - aside from a few ansible-specific tricks and basic config - I think ansible makes the whole setup much easier to understand than bash scripts - ie. you don't have to learn bash intricacies; along several other advantages. Not trying to detract from your work, it looks rather well done aside unavoidable problems when working with a large bash codebase, which ansible effectively abstracts away.

@alexec I have re-read your writeup and I think it brings some good points, can you give some details on the following:

• Requires a too much experience in Linux system administration to set-up and maintain. E.g. You need to know DKIM, DMARC, Postgresql, MySQL, Apache etc etc: How so?
• Requires too much time to set-up: Been a while since I tried it. How much time does it take? What is the longest step and can it be automated?
• Requires too much time to maintain: Same question, what are required maintenance tasks? I've come up with a soltuion that only requires running an upgrade command periodically. How can this be automated?
• Does not work on Ubuntu (package version problems): WHile I understand it is tempting to support every distribution, I think focusing on a single (or 2) distributions is part of the project's value (I chose Debian stable)
• Needs manual configuration (OwnCloud is insecure by default): How so? Can you link to that particular proble/can it be automated?
• Configuration is not consistent: How can it be solved? The way I solved this is a single configuration file.
• Hard to choose what components to install: Yes. Roles probably need to be split up and reorganized
• Components are not isolated: Further sandboxing/isolating services through seccomp/LXC/SELinux could be done without requiring downloading a full docker container each time.

@alexec

Ad owncloud/nextcloud: You need to set the permissions correctly after install and as far as I could tell right now sovereign is not doing that. Install documentations

@cstich Here are the tasks I use to harden Owncloud file permissions: https://github.com/nodiscc/srv01/blob/master/roles/webapp-owncloud/tasks/owncloud.yml#L140.

@nodiscc Oh nice. Thanks for pointing this out.

@alexec Awesome that you consider going for nginx as well! 🎉 That would be another reason to reopen the issue with the answer to life the universe and everything. 😉

Sorry for a delay in replying, I wanted to take some time over my reply.

First, a bit about me. I've worked with *nix development for 15 years, but I'm not an expert. I've worked extensively with Docker. I.e. I'm Docker strong, but *nix weak.

My primary concerns are reliability, security, and privacy. Naturally, I'd like these at minimum cost.

Everything I say is from my personal experience.

It's great to see everyone so excited about this discussion.

Requires a too much experience in Linux system administration to set-up and maintain. E.g. You need to know DKIM, DMARC, Postgresql, MySQL, Apache etc etc: How so?
Requires too much time to set-up: Been a while since I tried it. How much time does it take? What is the longest step and can it be automated?

I'd say it took me around 20 hours to set-up my server, including one prototype. Most of the time was spent reading and understanding both the documentation and code. Understanding what applications do what, and then making modifications to remove the ones I didn't want to reduce the attack surface.

This felt like a long time when I just wanted to run an email server initially.

I would expect pulling and starting Docker images to be quicker.

Requires too much time to maintain: Same question, what are required maintenance tasks? I've come up with a soltuion that only requires running an upgrade command periodically. How can this be automated?

I've spent time fixing cron jobs and the ilk, e.g. so they work with recent versions of PHP or MySQL.

Does not work on Ubuntu (package version problems): WHile I understand it is tempting to support every distribution, I think focusing on a single (or 2) distributions is part of the project's value (I chose Debian stable)

I'm very familiar with Ubuntu, and it's a popular and well supported, e.g. DigitalOcean's "One-click apps" all run on Ubuntu.

Needs manual configuration (OwnCloud is insecure by default): How so? Can you link to that particular proble/can it be automated?

OwnCloud needs to be set-up after install. I don't know how this could be automated. I don't know much about this.

Configuration is not consistent: How can it be solved? The way I solved this is a single configuration file.

Some manual config, some config files. Some passwords in one place, some in another. Various hacking of files after install to get them working with Ubuntu.

Components are not isolated: Further sandboxing/isolating services through seccomp/LXC/SELinux could be done without requiring downloading a full docker container each time.

Personally, I would have less confidence in its effectiveness than isolated containers.

A docker-container approach is the complete opposite of this, and as others have said, would be a security/maintenance nightmare.

This is quite the opposite of my experience with Docker. I've found time and again getting Docker running, especially using a container management tool, extremely quick and easy.

I'm quite experienced with Docker, and if you're not experienced with it, I could imagine this would be a concern for you. Therefore, I won't dismiss this as an issue that would need to be addressed.

My biggest issue with sovereign is that it is not modular enough

Absolutely, this impacts both security (via lack of isolation) and maintenance (coupling).

Build it straight from the Debian packages so that a simple "apt-get
update; apt-get upgrade" gives you the latest security fixes.

Apt-get update gets you the latest security fixes, but it would be magical thinking to believe this gives you a secure system. You'll still have many un-patched bugs and vulnerabilities, and this is more likely the more packages you install. Sovereign can install (IMHO) a very large number of packages and programs. This is why isolation is so important.

Quite a few people seemed concerned about getting good quality Docker images and keeping them up to date. The security and maintenance benefits of Docker are well documented, but they come at a price. That price includes having a build pipeline for you images, and having a container management solution, and requiring more powerful machines to run on.

There's no such thing as a free lunch, and the question that needs to asked is -is the trade off worthwhile?

Awesome that you consider going for nginx as well

Sorry :( The intent of using Nginx would be TLS termination and level 7 routing.

What concerns do people have about security and maintenance with Sovereign currently? Have you had an easier ride that I have? If so, why do you think that is? Do you have different skills and expertise? Different levels of experience? What are your goals and what do you want to get out of it?

Just my 2 cents.

Skills:
I don't have a particular background in maintaining *nix systems or doing anything with Docker. My background is mainly in academic computing (as a user).

Maintenance:
Sovereign, at least for me, is no solution that just works. I have had to dig into various config files, deal with broken or outdated packages, and some things still don't work (and that's on a vanilla debian install).

OwnCloud:
You can set the install up to be automatic. The guys at debops did that.

Configuration:
I had a hard time figuring out where all the passwords were stored as well and then I had to change a few passwords for postgress manually anyway.

Security:
I do not know enough to really be able to comment on that. Sandboxing/putting things in a container would be nice, however that is done.

Goals:
Ideally I get an e-mail server, a place to sync my calendar, and files---that is modular and does require less effort to maintain than sovereign right now.

Contribution:
I do not have a massive amount of time but if there will be a modular setup, I am happy to maintain one or maybe two "packages".

I think making Sovereign easier to setup and to maintain has little to do with putting the individual services in containers.
Containers will just make it more complicated with a little gain in security perhaps.

The biggest issue that we seem to have is that some things are broken and there aren't enough people fixing them (like Ubuntu 16.04 compatability). I'm one of those people who should fix more stuff 😊

Perhaps we should create some milestones and when we reach them we create releases. That way we have something to work towards and a sense of achievement. Right now it's just a never ending thing.

Re: owncloud auto configuration: apparently being worked on in #669

A proof of concept of Docker compatibility would be interesting (eg. fork the repository, remove except everything the common and eg. apache roles, adapt them to a docker setup, setup automatic builds, work from there to try and merge it - as an optional feature? - to sovereign). This would also probably help in identifying unneeded coupling.

Re: Multiple distribution compatibility: maybe adding compatible/targeted distributions to the README would help in clarifying this? And identifying things that don't work out of the box. I've found no mention of targeted distros.

Re: complex/time-consuming configuration/installation: centralizing configuration in a single file (maybe a 2nd for advanced settings) and automating steps described in https://github.com/sovereign/sovereign#installation would probably help. Ansible Filter plugins [1] [2] could be used to generate hashes/etc.

Re: general organization: have something to work towards and a sense of achievement. Right now it's just a never ending thing: Yep opening a new issue for each separate concern (eg those listed in https://github.com/alexec/sovereign/wiki/Sovereign-2) would be good.

Re: concerns about security and maintenance with Sovereign: I don't understand quite well how it works. The accpeted method of running a trimmed down Sovereign is to remove components - I prefer it to be the other way around (start minimal, add components with minimum hassle, my approach to this). Configuration is confusing (my take on it)

Re: expertise: I'm just a user with some experience in Linux system admin. My end goals are: deploying a server with just the services I need as quickly as possible, have it easily extensible/configurable, have sane defaults re. security/hardening/config, tend toward zero maintenance, and learn more about system administration.

Overall I really like this system! Mainly, for me at least having installed this on several systems it would be awesome to make it more customizable - as mentioned above having containers. This way we could turn on a few things and not others.

As for making this more user-accessible while working with one person they did find it difficult to generate all the hash values on their system. I think that's relevant as it requires more advanced skills and confidence.

Does Docker work on low-cost VPS's? I didn't think it did and that would rule it out for a lot of people.

That's one of the things that attracted me to Sovereign. I've also had problems running Docker on local hardware with limited resources as well.

Really the Ansible scripting is the thing that sets Sovereign apart from other efforts.

Hey all! Thanks for the great work in this repo! From my understanding of things, here's my 2 cents on this matter:

1. Containers is definitely the way to go to achieve better isolation. Regarding perf: Docker even runs on RPi.

2. You may want to consider using Ansible-Containers to leverage Ansible for creating and managing them Docker containers.

3. Additionally, for future versions, you may also want to consider Ansible Playbook Bundles (APBs). This is a new deployment strategy for Kubernetes. Essentially, APBs will be consumable through the Server-App-Store-like Service Catalog on Kubernetes-based Paas (e.g. on vanilla Kubernetes or a distro like Openshift), complete with GUI. I assume this will pose a very low entrance barrier for non-IT people. Kubernetes can already be run from a single machine (and easily, too, e.g with oc cluster up). Also, Kubernetes would allow Sovereign to scale much more easily, as one can replicate the Kubernetes containers (called Pods) on other machines connected to the cluster, or (in future releases) even mirror the entire cluster to another location (private/local, AWS, GCE) via Federation. A Pod usually consists of one or more containers that somehow belong together logically and need to scale together (e.g. postfix, dovecot and rspamd could live in one pod). Although the processes in different containers within a pod are isolated, they can communicate via localhost (meaning not too much config would have to change. For the mail server for example, Postfix->Dovecot comms would have to change from a unix socket to an inet socket on localhost:dovecot-port). In this, a Kubernetes deployment looks very similar to a Docker Compose.

Note that N° 3 probably isn't production ready as of now (because Service Catalog and APBs haven't gone GA, yet), but one could start out with containerization of the different processes (e.g. like in N° 2, or done directly with Docker / rkt / OCI-containers) which is needed before running them on Kube anyway.

If you want to fully leverage Ansible, I feel like N° 2 would be a good starting point!

Cheers

the docker approach is interesting because it help to integrate news applications.

such as a good example where docker is preferable is when you come to upgrade from php5 to php7
with docker you could do apps per apps instead of server per server ;)

Docker and ressources
As hard it could be to believe it, peoples and serious project (like rancher) turn docker on raspi.

For the security perspective
I'll recommend to run docker in the userspace
debian and ubuntu handle it nicely even with apparmor
but centos still have issue with the userspace when SELinux is activate
I personally run a bunch of apps in userspace on Alpine with GRCSecurity without really more configuration or privilege and particular issues.

Apps perspective
If I was you, I'll give a look to the awesome work made by LinuxServer, they produce and maintain lot of secure image.

the proxy (Nginx)
It could also be dockerize without issue
but as Cloudron they put nginx, mariadb and postgres outside and I think it's not a bad approach too.

Let's Encrypt
they provide a great docker image (certbot/certbot)
so again, why outside of docker ?

Why not turning DB outside of docker ?
It might facilitate the backup part ;)

Next/Owncloud
Why mariadb/myql DB only for next/own cloud ? it works well with postgres too ?

I concur with @TotallyInformation - Sovereign would loose its main advantage if it became Docker-exclusive. Right now breaking up Sovereign isn't hard (see my mailstack-only hardfork https://github.com/ubermail/ubermail), and can be perfectly containerized as it is i.e. with LXD. Dockerizing Sovereign would make it a real pain for low-cost as well as high-performance deployments as well as Sovereign customizations/forks.