On Wed, Aug 21, 2013 at 7:45 PM, "Jóhann B. Guðmundsson" <johannbg(a)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<http://container01.example.com>
Install minimal package set into the OS container being created
# yum -y --releasever=rawhide --nogpg --installroot=/containers/cont**
ainer01.example.com <
http://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