On Wed, Aug 21, 2013 at 7:45 PM, "Jóhann B. Gušmundsson" <johannbg@gmail.com> wrote:
Greetings all

After sitting Dan's Walsh Secure Linux Containers talk at flock where he mentioned him and Dan B. had successfully scaled application containers to what 8000 instances or so and I noticing that his slide where a bit dated due to the changes in croup I decided to have a look at the current state in systemd to see what we needed to fix and properly integrate those changes into Fedora and deliver good out of the box container experience for our administrators and users as well as document those changes ( early readers can jump here [1] just note this page is a work in progress ).

Now I've been poking and prodding, fixing and preparing us for those upcoming cgroup changes in systemd in relation to Linux OS Containers known as "machine slices"
( Essentially this feature [2]  which btw does not work as advertised due to several bugs in various places ).

Now aiming at achieving some simple practical steps something like this for administrators to use

# btrfs subvolume create /containers/container01.example.com

Install minimal package set into the OS container being created

# yum -y --releasever=rawhide --nogpg --installroot=/containers/container01.example.com --disablerepo='*' --enablerepo=fedora install systemd passwd yum fedora-release vim-minimal procps-ng

Spawn the container and set the machine hostname

# systemd-nspawn -jbD /containers/example.com/ -M container01.example.com

( perfect admin steps for setup would stop here but due to several bugs additional steps and workarounds are needed at this point )

And I have come across a bit of scalability issue due to us defaulting to using short hostnames in login and command prompt when creating OS containers in any real numbers.

Now for those that are not familiar with our default using the short fqdn it cuts the fqdn at the highest level domain as in the first "dot"  so in the sample case the login and command line promt is shown as "container01".

That scalability problem comes immediately apparent when you would create the next container01 for the next second level domain like container01.ackme.com you as an ISP would be hosting, it would be also showing "container01" at the login and command line prompt just begging for administrative mistake and headaches.

I would like us to change our default to use long hostname instead as in the fqdn or "container01.ackme.com" and would love any kind of feed back in that regard ( why we should not default to that ).

The downside of doing that ofcourse if you have like 6 level domain name in your infrastructure like "i'm.a.really.long.domain.name.com" it might become a bit of a nuance but administrators could always revert those change to use short hostname instead if that was the case.

I think it's a deployment decision as opposed to a Fedora as a distro decision.
 
The other issue I would like to get some comments on is that we default to setting an empty root password which will allow administrators to log into containers as root and set the root password as well as removing few line from spin kickstarts as well being beneficial to the arm community.

Now the only reason I see for not doing this is because on the releng dvd installs we enable ssh by default ( which we arguably should not be doing ) but the argument can be made in that regard that we leave the users anyway open to bruteforce attacks out of the box without them even knowing that it's happening so it comes as bit of security through obscurity not allowing this in the first place.

On cloud images we actually lock the root account so it's unusable. In the case of cloud providers the standard deployment is generally along the lines of either injecting ssh keys for root and unlocking it or creating a standard user account, injecting ssh keys and configuring sudo for that user. So a blank password in root is generally not an issue. I would expect the deployment of containers would use the same methods.

Peter