[gentoo-dev] Re: eselect init
Pacho Ramos posted on Fri, 21 Jun 2013 17:48:59 +0200 as excerpted: El vie, 21-06-2013 a las 09:36 -0500, William Hubbs escribió: [...] No, he has his own versions of the systemd and sysvinit ebuilds which move some of the installation to non-standard places as part of this machinery, so it is not opt-in. Also, there was an email on this thread showing that using init=/sbin/einit works, so I'm not seeing what mgorny's objections are. William I think mgorny was referring to a case where einit fails to work and, then, kernel will fallback to using /sbin/init, that could cause problems as it would always run /sbin/init from sysvinit... but maybe he was referring to something else :| This is my understanding as well. If there's a problem with /sbin/einit, the kernel will fallback to /sbin/init. If /sbin/init runs a sysv init that's setup for an old, no longer sysadmin maintained openrc (or whatever other) setup, there's little telling what sort of unpredictable things that openrc config from three years ago might end up doing to a painstakingly configured systemd (or runit, or...) current config. That's the worry, and as an admin, I'd be worried about it myself, but in practice, I'm not sure it's particularly valid, simply because in the real world, the failures are more likely to be full service breakage, etc, than they are to be anything really destructive. The caveat, and this one's big enough to give an admin ulcers for sure, is if the machine is a server, and that old no-longer-maintained openrc config starts up say a no-longer-maintained sshd instance with a poor password that has long since been forgotten about, thus exposing the machine to any cracker taking a probe. However unlikely that is (such an unmaintained sshd config should have long since been removed on any responsibly administered gentoo system), just the possibility is enough to give a responsible admin ulcers worrying about it, because even responsible sysadmins fat-finger things, or simply forget about them, once in awhile. THAT's our REAL weakness, and we know it all too well! -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: eselect init
After talking with WilliamH yesterday, I have this opinion: - Playing with /sbin/init (instead of /sbin/einit) has two interesting advantages: 1. For example, I now have init=/sbin/e4rat-preload in my grub.conf, if I do a typo, it would fallback to /sbin/init. If /sbin/init is provided by sysvinit, people running other init providers could have problems. This wouldn't occur if /sbin/init has been changed to use desired init system. 2. Tools like e4rat or bootchart launch /sbin/init, if I switch to systemd, I would need to edit separate configuration files for each tool to point to new init. This wouldn't occur if we play with /sbin/init = we would only change init in one place - I have two doubts: 1. Why do we need a wrapper instead of changing symlinks? 2. Why Fabio chose to move sysvinit to subdirectories... wouldn't be much simpler to simply rename /sbin/init to /sbin/sysvinit?
Re: [gentoo-dev] Re: eselect init
On 06/22/2013 12:07 PM, Pacho Ramos wrote: After talking with WilliamH yesterday, I have this opinion: - Playing with /sbin/init (instead of /sbin/einit) has two interesting advantages: 1. For example, I now have init=/sbin/e4rat-preload in my grub.conf, if I do a typo, it would fallback to /sbin/init. If /sbin/init is provided by sysvinit, people running other init providers could have problems. This wouldn't occur if /sbin/init has been changed to use desired init system. 2. Tools like e4rat or bootchart launch /sbin/init, if I switch to systemd, I would need to edit separate configuration files for each tool to point to new init. This wouldn't occur if we play with /sbin/init = we would only change init in one place good point. maybe a ton other wrapper of that kind. shouldn't they read /proc/cmdline for init=^H^H^H^H^Hreal_init= , but that takes time. - I have two doubts: 1. Why do we need a wrapper instead of changing symlinks? And a plain symlink has the charm to either resolve (and load and most likely execure the target) or dangles and kernel tries the next one. No late, wrapper bailouts leaving the kernel in You killed pid 1 panic. === kexec === speaking of panic. I've never actually used it, but newer kernels support kexec and in conjunction with pre-loaded panic-images[1] and corresponding (compiled-in) initramfs, it'd be possible to have an recovery shell. for either /sbin/init mixups, or late runtime crashes. These should have a the decency to respect the panic= timeout to allow automated reboots or idle till to the end of days. [sad enought, that kexec'd kernels don't pick up the process tables/heap of their predecessors and enable real kernel-hotswitching] === more fallback == maybe we could ask Mr. Tovalds to ad another line in init/main.c, say /sbin/init.fallback (but don't mention systemd) or we could abuse /etc/init or /bin/init or /sbin/sh (with an wrapper to test for PID=1) for an recovery-environment. Fabio: did you mean that? === security === Bailing into /bin/sh or whatever can compromise filesystem integrity/reveal root access to an uncrypted rootfs. There is a scenario of vandalism-proof installed computer pools (no physical access except keyboard/monitor) w/ unattended boot that should not end up in root-shell. ;-) Maybe I should fix that on my systems ... [1] sys-apps/kexec-tools http://kernel.org/pub/linux/utils/kernel/kexec/ -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org
Re: [gentoo-dev] Re: eselect init
On Sat, Jun 22, 2013 at 7:13 AM, Michael Weber x...@gentoo.org wrote: === kexec === speaking of panic. I've never actually used it, but newer kernels support kexec and in conjunction with pre-loaded panic-images[1] and corresponding (compiled-in) initramfs, it'd be possible to have an recovery shell. for either /sbin/init mixups, or late runtime crashes. These should have a the decency to respect the panic= timeout to allow automated reboots or idle till to the end of days. I wrote up the wiki guide on this, but for the last six months I haven't been able to get it to work. If somebody does have it working please see if the guide needs updating - something seems to have changed. It is annoying because my system seems to freeze up on rare occasion and I'm sure there is a panic/etc on the console obscured by X11. At the moment, however, some kind of xorg freezeup seems to be what is driving me crazy (seems like a driver puts it into a loop and makes it freeze for 30s at a time, with even alt-sysrq-r not always working. Moving both kernel and xorg from stable to ~arch didn't help with that either... Ugh. Rich
Re: [gentoo-dev] Re: eselect init
On 06/22/2013 12:07 PM, Pacho Ramos wrote: After talking with WilliamH yesterday, I have this opinion: - Playing with /sbin/init (instead of /sbin/einit) has two interesting advantages: 1. For example, I now have init=/sbin/e4rat-preload in my grub.conf, if I do a typo, it would fallback to /sbin/init. If /sbin/init is provided by sysvinit, people running other init providers could have problems. This wouldn't occur if /sbin/init has been changed to use desired init system. 2. Tools like e4rat or bootchart launch /sbin/init, if I switch to systemd, I would need to edit separate configuration files for each tool to point to new init. This wouldn't occur if we play with /sbin/init = we would only change init in one place - I have two doubts: 1. Why do we need a wrapper instead of changing symlinks? So once I'm not busy playing with pixels and hw accels I would implement addons support in the wrapper (so bootchart and e4rat would just ran by the init wrapper) 2. Why Fabio chose to move sysvinit to subdirectories... wouldn't be much simpler to simply rename /sbin/init to /sbin/sysvinit? I prefer /bin/init but any place would fit (and should be configurable anyway) lu
[gentoo-dev] Re: eselect init
Fabio Erculiani wrote: - only init is currently handled by eselect-init, which is now using a very small wrapper POSIX shell script to redirect the calls to the currently running init How does say, switching inittab format, work under this setup? -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
Re: [gentoo-dev] Re: eselect init
On Thu, Jun 20, 2013 at 06:10:27PM +0100, Steven J. Long wrote: Fabio Erculiani wrote: - only init is currently handled by eselect-init, which is now using a very small wrapper POSIX shell script to redirect the calls to the currently running init How does say, switching inittab format, work under this setup? I think this is a separate issue -- if busybox init's inittab is a different format than sysvinbb's inittab, it should also use a different file name, e.g. bb-inittab or something similar. bb could fall back to inittab, but I think it should look for something liike bb-inittab first. That way eselect init wouldn't have to worry about it at all. William signature.asc Description: Digital signature
[gentoo-dev] Re: eselect init
Luca Barbato posted on Mon, 03 Jun 2013 00:35:29 +0200 as excerpted: To not make this a waste of time here a summary of the whole thing: - eselect init will be opt-in for the time being, people can be left on their own tools if the want it - the default init will stay sysvinit. Discussion ongoing if is better to have it installed in a secondary fallback path is open (e.g. /bin/init). - I still need to send patches to busybox and sysvinit upstream to add a command line switch to locate the inittab. - people wanting to switch init or enable/disable init addons using eselect init might have to refer to /sbin/einit or such custom path (assuming we fail to come to an agreement regarding /bin/init) The wrapper in /sbin/init is mostly needed to get to the point of a clean reboot. The first time you boot on a new system it is executed picking the new init and just that. For addons such as bootchart2 and e4rat it would do slightly more. Thanks for the summary. In the muddle of a contentious thread it's not easy to figure out which points have been settled on and which are still considered under discussion, so a summary by someone suitably involved as to be authoritative can be valuable indeed, even for those who (like me) have read the entire thread. And valuable it was to me here. =:^) The only concern I had with the above is the one Walter D. brought up, that for the time being caveat. But rich0 well addressed that, so... I'm good! =:^) Meanwhile, Walter D: Thanks for your work too. I'm not using your bb-init work ATM, but I deeply appreciate having the alternative available, should I find the need for it in the future, and am thus very thankful that /someone/ was suitably motivated to create it. I haven't seen a lot of direct thanks on-list for your work, but I suspect there's others who seriously appreciate it as well, whether we're already using it or may actually never use it but deeply value having the alternative should we have need of it, so let this be a thanks from all of us. It's projects like yours, someone seeing a need and addressing it for themselves, then simply making that work available for use by others, that form the grassroots of FLOSS. =:^) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: eselect init
On 06/01/2013 11:23 AM, Steven J. Long wrote: That's not an argument for using a symlink switcher or the equivalent across the board, by any means. Your opinion. Firstly, we should be recommending people install Gentoo with enough flexibility to configure and use their system how they choose. In the UEFI arena, why not simply recommend something like rEFIt instead of making everyone go through a load of development effort, to restrict us all to a crippled use-case? Beside rEFIt being deprecated and rEFInd being in early stage of development (thus working great on some platforms and not working at all on some other) and with a good chunk of documentation to read before being able of deploying it? NOTE: If you still wish to pursue a fixed config, then it's easy enough to build it with init=/sbin/einit since presumably you want that setup for your users. Had been considered All I'm saying is: can we please stop trying to reinvent the kernel, which accepts a bootloader parameter from initramfs as well, and focus instead on the difficult part: making sure the system is in a fit state to switch in the first place. ... That's where the development effort is needed, if you are to provide a mechanism to switch. The symlink and hooks etc is a total dead-end, imo. It's simply reinventing the wheel using octagons instead of circles. IMHO you hadn't read enough about it. There's nothing to stop systemd being the default init, should you want to put the install together like that. Because let's be honest: someone has to put this install together, irrespective of how incapable the end-user is of editing a file by themselves. And just because the user can do it simply, that's no reason to make our method to do it any more complex (I've never heard such a bizarre argument.) Just edit the file via script. I do not care about systemd. FOCUS on getting the system safe to switch. Not on reinventing init/main.c, badly. You should read the whole thread before commenting like this that late. lu
[gentoo-dev] Re: eselect init
On Sat, May 25, 2013 at 11:54:48AM +0200, Luca Barbato wrote: I'm back to the other part of it: switching the actual init implementation. # WHY (not just edit your bootloader) Since efi at least some people started to put in the kernel the bootargs and we have at least few new options brewing for init, some are small impact (bootchar, bb-init-openrc and runit-openrc) some are more invasive (runit and systemd). In those setup changing bootargs requires a kernel rebuild and some effort, while the eselect approach stays completely transparent. That's not an argument for using a symlink switcher or the equivalent across the board, by any means. Firstly, we should be recommending people install Gentoo with enough flexibility to configure and use their system how they choose. In the UEFI arena, why not simply recommend something like rEFIt instead of making everyone go through a load of development effort, to restrict us all to a crippled use-case? NOTE: If you still wish to pursue a fixed config, then it's easy enough to build it with init=/sbin/einit since presumably you want that setup for your users. So even for the restricted corner-case of a Gentoo install without a bootloader this is not needed. In fact it would be better done using the existing mechanism. All I'm saying is: can we please stop trying to reinvent the kernel, which accepts a bootloader parameter from initramfs as well, and focus instead on the difficult part: making sure the system is in a fit state to switch in the first place. That's where the development effort is needed, if you are to provide a mechanism to switch. The symlink and hooks etc is a total dead-end, imo. It's simply reinventing the wheel using octagons instead of circles. There's nothing to stop systemd being the default init, should you want to put the install together like that. Because let's be honest: someone has to put this install together, irrespective of how incapable the end-user is of editing a file by themselves. And just because the user can do it simply, that's no reason to make our method to do it any more complex (I've never heard such a bizarre argument.) Just edit the file via script. If we're on a crippled EFI setup, or the user has specified to use the boot wrapper, then we're simply editing a file for the wrapper to read instead. It's trivial. FOCUS on getting the system safe to switch. Not on reinventing init/main.c, badly. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-dev] Re: eselect init
In the UEFI arena, why not simply recommend something like rEFIt sorry should have been rEFInd: http://www.rodsbooks.com/refind/ as discussed recently on gentoo-user@. --
