(Fri, Nov 15, 2013 at 09:45:15AM +0100) Rodrigo Rivas :

On Fri, Nov 15, 2013 at 1:55 AM, Ismael Bouya wrote:

...

However when we need to boot into "fallback mode", initramfs asks for root password! Is there a standard/automated way to ask/permit another user via initramfs in Archlinux?

...because you should only do that when your boot console is secure. The argument is that if anyone has physical access to your computer, they can boot from a LiveCD or USB anyway...

Well, that's how I dealt with my problem, I was lucky that I had one, but...

...

If not, how do you deal with that usually?

Let's go to the point! The pasword is asked by the systemd services "emergency.service" or "rescue.service", that run "/sbin/sulogin".

So your easiest solution is to modify these services to use the argument "--force", that according to "man sulogin" will do what you want:

For that create the directory "/etc/systemd/system/emergency.service.d" and in it the file "10-nopasswd.conf" with this content:

[Service] ExecStart=-/sbin/sulogin --force

And the same repacing rescue for emergency.

Hum that will accept passwordless login wont it? I was telling of accepting a specific (trusted) user's password instead of root's But at least I know now which direction to look at, I'll test it next time I have physical access to my computer, and report.. Thanks! -- Ismael

(Fri, Nov 15, 2013 at 02:52:33PM +0100) Rodrigo Rivas :

Yes, I thought that was the point. But you want to use the user password... the same as with "sudo", makes sense. You could using "login" instead of "sulogin". Or if you feel brave enough you could even add a link to "getty@tty2.service" or "getty@tty1.service" into "/etc/systemd/system/{rescue,emergency}.target.wants" and see what happens (you may have to manually switch to VT2, though).

Yes, that's what more or less what I thought about and just did, if I break something up to a point that even this solution doesn't work then maybe I reached a point where it might be a good idea to boot from a key :) Thanks a lot! Mvh, -- Ismael

On 11/15/13 at 06:37pm, Ismael Bouya wrote:

By the way I came to a "dark" point : how does systemd knows that he is started in fallbackmode ?

Likely, something is broken with your fallback initramfs. Booting from the fallback should be no different than booting from the normal initramfs. The fallback simply doesn't apply the autodetect hook, so it does not try to exclude unnecessary modules. The fallback is typically useful if you have a disk that you might want to move to another machine with different hardware. It is just not machine specific like th normal one. -- Curtis Shimamoto sugar.and.scruffy [at] gmail.com

Hum I started to write answers to different emails, but it looks like I messed things between an actual problem (A non-critical hard disk that crashed with no "nofail" option in the fstab) and my tries afterwards to boot in rescue/emergency mode. To answer to Gaëtan, the message that I saw was exactly the one in /usr/lib/systemd/system/{rescue,emergency}.service I know the difference is important but I cannot remember which one it was (most probably it's the one corresponding to what happens when things go bad) Mainly, I made a confusion with what is "usual" in Ubuntu in the grub, that is to have a line for normal booting, and one line for "emergency", that tries as hard as possible to reach a (root) shell even when things go badly. Now I know that I'll have to configure this behavior somehow manually (?) Thanks all for your help! Best regards, -- Ismael

Am 15.11.2013 15:55, schrieb Anatol Pomozov:

The "correct" way to disable root completely is to make it expired "usermod --expiredate DATE_IN_PAST root". I tried it on my machine and found that pacman is broken. I believe it uses "su" before running install scripts.

Nothing about disabling the root account is "correct". If you disable the account, both 'su' and 'sudo' cannot function. You _need_ the root account.

On Fri, 15 Nov 2013 08:33:33 -0800 Anatol Pomozov wrote:

Hi

On Fri, Nov 15, 2013 at 7:02 AM, Thomas Bächler wrote:

...

Am 15.11.2013 15:55, schrieb Anatol Pomozov:

...

The "correct" way to disable root completely is to make it expired "usermod --expiredate DATE_IN_PAST root". I tried it on my machine and found that pacman is broken. I believe it uses "su" before running install scripts.

I need to check pacman src, but I find this unlikely. If pacman called su(1) wouldn't there be an entry in auth.log? Besides, calling external binaries is a bad practice -- that's what shared libraries are for.

...

Nothing about disabling the root account is "correct".

Disabling root account is typical practice on multi-user machines. "sudo" is much better solution as it allows fine-grained control to super-user abilities.

I don't know what you mean by "typical", but I am yet to see a rootless supercomputer (as you know, these machines usually have ~100 users logged in at the headnode). The _only_ scenario in which disabling root is useful is when you require audit logs of every administration-related operation, so you use sudo. Everything else sounds like a false sense of security to me... Cheers, -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D