On Wed, 2013-08-21 at 18:45 +0000, "Jóhann B. Guðmundsson" 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 ). +1 always good to show the full name IMO, at least at the ssh/shell level, let the pretty graphical UIs be more lax and try to prettify things. > 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. One way to make it less painful could be to preint the fqdn on one line and then just login on the next. Ie instead of haiving container01 login: you would have container01.my.really.deep.sub.domain.name.hierarchy login: I think people will object less to something like this, after all we already print the full fedora name and kernel version on console logins in previous lines. > 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. Sounds like a bad idea. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
