Activate the console at boot

[specing]

Okay... 1) you should have patched write_distro_inittab() and not write_distro_init_fixes() 2) I'd rather see we remove sed -i 's/^c[1-9]/#&/' "$ROOTFS/$INITTAB" # disable getty on the first line of write_distro_inittab() and thus have whoever used lxc-gentoo deal with consoles as (s)he pleases (as this would be the case if you used a stage3) this would also reduce the amount of changes we do to get a stage3 running (and disabling consoles is not necessary to get it running).

On the other hand... this adds yet another process to be spawned in the container (are we keeping things minimal here?)

[cthuun]

My bad, it was my first editing. 1) I should read the code more carefully... 2) I think we need at least one terminal, at least to connect and customize the lxc. After this step we could just let the container live on its own (ie disabling the console and/or ssh)

2013/9/24 Fedja Beader notifications@github.com

Okay... 1) you should have patched write_distro_inittab() and not write_distro_init_fixes() 2) I'd rather see we remove sed -i 's/^c[1-9]/#&/' "$ROOTFS/$INITTAB" # disable getty on the first line of write_distro_inittab() and thus have whoever used lxc-gentoo deal with consoles as (s)he pleases (as this would be the case if you used a stage3) this would also reduce the amount of changes we do to get a stage3 running (and disabling consoles is not necessary to get it running).

On the other hand... this adds yet another process to be spawned in the container (are we keeping things minimal here?)

— Reply to this email directly or view it on GitHubhttps://github.com/globalcitizen/lxc-gentoo/pull/65#issuecomment-25015886 .

KURTZ Jerome EPITA 2012 Spécialisation GISTRE Ingénieur Système - OpenWide +33 6 88 24 15 22

[specing]

lxc-start provides an auto-login terminal: echo "# Lxc main console" >> "$ROOTFS/$INITTAB" echo "1:12345:respawn:/sbin/agetty -a root --noclear 115200 console linux" >> "$ROOTFS/$INITTAB" But if we change anything, my vote is on nuking: sed -i 's/^c[1-9]/#&/' "$ROOTFS/$INITTAB" # disable getty or for bonus points changing that line to enable-autologin like the console line above (having to type a password to login when you have direct access to container's /etc/shadow is time consuming and doesen't improve security at all)

PS: I was using SSH to configure hosts because the lxc-start console has that annoying line wrap issue -- Im surprised lxc-console doesen't suffer from this.

[globalcitizen]

Here's my take.

As a general Gentoo environment setup script, lxc-gentoo mainly aims to configure an efficient container populated similarly to a standard Gentoo system with some 'low-hanging fruit'-style simpler system optimizations for in-container execution. It's really not aiming to be all things to all people, rather "a good general container generation script". This means any feature removed is probably removed because it is perceived to be an edge case, and any feature added is probably added because it is perceived to be generally useful.

The reason getty was originally removed is that LXC can support but is not really intended for providing a full featured interactive Linux console from the container-virtualized machine. Historically, the interactive console from container use case (via both lxc-start and lxc-console, but mostly the latter) was also rather buggy across different kernel and userspace versions. For the perhaps far more frequent and normal use case of setting up LXC for automated processes and/or virtualized hosting, eating memory and startup time to initiate interactive login processes and getty instances for multiple terminals is undesirable... particularly when ssh is such an effective, secure, industry standard solution for exporting console access which also solves the issue across networks.

If people have reasonable use cases for virtualized console interactive use, perhaps we should consider a command line option that means "do not disable console entries in inittab (and corresponding device entries)" to enable this. The most valid case I could see for that is if some form of LXC management infrastructure (if libvirt or virtualization management tools based upon it, for example) expect a functional console. Honestly though, the whole point of fast virtualization is automation - and I really struggle to see widespread appeal for manual interaction with an entire Linux system type container such as that lxc-gentoo produces, particularly when LXC also supports individual application containers without any system-related overheads and ssh is a more familiar, network-capable mechanism to achieve the same.