On Fri, 23.01.15 19:35, Christian Seiler ([email protected]) wrote: > - explicitly enable getty@tty{1,2,3,4}.service
Why? This cannot work. The getty services assume a Linux console tty, they will issue ioctls and ansi sequences that only the linux console supports, and do VT management on them. /dev/tty1, /dev/tty2 and so on must refer to proper VT devices, that come with the matching files in /sys/class/tty/, with matching /dev/vcsa* and so on. Mounting a pseudo-tty to /dev/tty1, /dev/tt2 and so on is a *really* bad idea. If LXC suggests such a configuration, then please talk to the LXC guys, this is *very* broken and should not be done. You'll confuse systemd, logind and the gettys with that. You'll get an incorrect TERM, and everything else will be fucked up, too. Also, there's really no reason to do this. Just create as many ptys as you wish, and then pass $container_ttys= to PID 1 with their names, and systemd will do the right thing. See http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/ for details. > - no ConditrionPathExists=/dev/tty0 for [email protected] Yeah, well, this stuff is there for a reason. Don't remove that stuff. This automatically disables the VT logic if no VT is available. You shouldn't hack around that. Just use proper container gettys instead ("[email protected]", which are automatcailly instantiated via $container_ttys= among others). > - mask systemd-udevd.service (haven't tested if that's actually needed, > the lxc-debian template also does this however) There's no point in doing that. udev uses ConditionPathIsReadWrite=/sys anyway, and is automatically skipped hence when /sys is read-only. COntainer manager really should set up /sys read-only in containers, so that the various cotnainers don't confuse each other by all trying to manage and change /sys, and more importantly cannot fuck with security-sensitive settings. > - touch /etc/fstab if you debootstrap it directly You can just remove it. You don't need it in containers (and not even on most hosts, unless you actually need to refer to external partitions that cannot be auto-configured. > - I hope I didn't forget anything I spent quite some time to ensuer that systemd systems work out-of-the-box in container managers. Any container manager that implements this stuff http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/ should just work out-of-the-box, without *any* modification of the system to boot. > > I am tempted to just > > change nspawn to mount a private tmpfs into /run/user, too, as it > > already mounts /run anyway. > > That would solve /run-quota issues for CAP_SYS_ADMIN-less containers, > but is unnecessary (although harmless) for those that do have it. I decided against doing this after all. I think that systemd in a container and on baremetal should work as similar as possible, and thus not have orthogonal setups in /run. Hence, we either do something (possibly skipping it it on missing perms) or, we don't do it at all, but we don't do completely different things in different cases. > (Note that in Debian you can also configure it to be on the same tmpfs > as /run, but since on Debian it has mode 1777, there's a good reason NOT > to do that.) Yuck. Maybe Debian should lock that down. World-writable directories are dangerous, nobody should use that. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
