On Mon, Aug 31, 2020 at 01:22:32AM +1000, Russell Coker wrote:
curl URL | sudo bash
If you trust someone who's written the daemon then trusting their install script is no more risk.
part of my point is that anyone who suggests using brawndo-installer to install their code can not be trusted. they clearly fail the competence test.
Now you can modify all scripts to use runuser, but that's going to be a pain. systemd does all this for you.
which is nice if you never need to do anything in a way that the systemd devs didn't think or use themselves. or deliberately disallow. in that situation, you're fucked.
Which situations are you thinking of?
being able to manually change the exact order that particular daemons/services are loaded.
The "kill processes in user session when they logout" was a good feature for some use cases and it was annoying that last time I checked the Debian systemd maintainers had disabled it instead of leaving it as a configuration option.
actually it was a terrible anti-feature. one that has little reason to exist, and certainly should never be enabled by default. are the systemd devs completely ignorant of decades of normal *nix usage? they certainly act like it sometimes. anyone who needs or wants that kill-all-my-processes-when-i-logout functionality can do it in their .bash_logout (or equivalent for whatever shell they run). for everyone else, it's an extremely unpleasant surprise to find that the program they deliberately left running with nohup or screen or tmux or whatever was killed when they logged out. nobody expects their processes to be killed just because they logout. that's not how things are supposed to work.
Also systemd allows blocking daemons from accessing /home and other security features.
no, the kernel does that. systemd just makes use of kernel namespace features. it's not alone in being able to do that - containerd and docker and firejail and many other programs make use of namespaces.
Yes, but systemd has a configuration option for it.
so do other programs that make use of namespaces. systemd devs like to pretend that their baby is the only program capable of doing certain things, when that's not even remotely true. half the things they claim as wonderful features exclusive to systemd are re-implementations of ideas from other programs. and most of the rest are things that an init system has no business doing anyway.
I really don't get why systemd fans are so terrified of shell scripts.
Because I've worked on so many shell scripts written by other people.
So have I. I've also had to fix several broken unit files. It's possible to create shit with any tool. The reason i mention it is because "shell scripts are bad" is a common reason brought up to prove that systemd is great and why it's better than any other init. to me, cretinous statements like that say a lot more about the person saying it than about either systemd or shell scripts. or sysvinit. etc. Also, IME, shell scripts are easier to understand and fix when required. They're easier to modify, easier to temporarily enable/disable parts of them when testing stuff, easier to add diagnostic code, and more. lots of things are easier with shell scripts. They're not scary at all. sh scripting is a useful tool. systemd devs are doing everyone a great dis-service by teaching them that they're scary and difficult.
especially when systemd is so poorly documented. it's not as if systemd unit files are paragons of clarity, or that there's any easy way to get an overview of the dependency relationship between units.
"systemd-analyze critical-chain" is very handy.
that tells you what happened during the current boot session. it doesn't tell you what WILL happen during the next reboot. AFAIK there's no way of listing which unit files will be loaded, or in what order. e.g. definitive answers to questions like "will docker load before or after zfs.mount?", not just "maybe. reboot and find out". you can get that just by doing 'ls -l' of an /etc/rc[0-6].d/ directory. The Snn and Knn symlinks tell you the *exact* order that the scripts will run at boot or shutdown time, and you can override the default with insserv and the script's INIT INFO comments. BTW, i used that example (of zfs.mount and docker) for a reason. My main server runs docker configured to use zfs. Every reboot it's a gamble whether docker will start before or after zfs.mount. If it starts after, it works fine. That's what's supposed to happen. If it starts after zfs.mount, it breaks. and it creates and populates a fresh new /var/lib/docker directory, which prevents my zfs docker dataset from being mounted (I have to manually stop docker, and delete the directory before I can zfs mount /var/lib/docker and restart docker). this kind of shit is one of the reasons i'm reluctant to reboot my main server if i can possibly avoid it (and why i'd NEVER use systemd on a remote machine that I didn't have easy physical access to). There's always half a dozen or so little annoying things like this that I have to fix manually before the system is in its normal operating state. and finding out WHAT happened this time with systemd-analyze critical-chain doesn't tell me what will happen next time. and it doesn't tell me anything about WHY it happened or HOW to fix it permanently. craig -- craig sanders <cas@taz.net.au>