Live data from Hacker News

Run0, a systemd based alternative to sudo, announced

mastodon.social

341–350 of 902 posts

Re: Run0, a systemd based alternative to sudo, announced

#341

Earlier quoted context omitted.

I just switch every system to systemd-networkd immediately. The same .ini sytax as for service files, and dependencies are easy to handle, e.g. on one system I have two physical Interfaces eth0 and eth1, I want two vlans on eth0, and then bridge one of those vlans with eth1 and then run a DHCP client on that bridge but at the same time assign an additional IP address. This is dead simple to describe with one .ini fil…

Eh, I could. But I'm quite sure that the method of switching to systemd-networkd also requires the same if not much more maintenance as simply changing the ifconfig template every few years... I really don't care about interface configurations that much. It's an annoyance, but one that's quite easy to fix. I think introducing yet another network configuration here isn't the answer, but my linux fleet just run k8s any…

Sure, I made that choice at a time where after upgrading, Ubuntu suddenly wanted netplan, debian stayed with /etc/network/interfaces and I think fedora went with networkmanager. So I though f- it, they all have systemd so I'll give networkd a spin. And never looked back.

So maybe don't just switch out of the blue right now if you've got a working setup, but maybe keep it in mind for the next time. :)

Re: Run0, a systemd based alternative to sudo, announced

#342

Earlier quoted context omitted.

The follow argument is identical to tail `-f`. `sudo journalctl -f -u `

And what would be the equivalent to, "Oh, I don´t know the name of the log for this process I can see in 'ps aux', let me cd into /var/log and see what filenames I can find ... or grep everything until I can find a couple of words that make some sense so I can keep digging further"? The lack of explorability in journalctl, the "need" to keep everything locked behind their own flavor of tools and magic file types, is…

You do have to learn a few new things, yes. But it's not too difficult. We all have to learn new things sometimes.

I spent around 15 minutes a few weeks ago learning how to do a few things with journalctl, and I came away from it with a great appreciation for its power.

Re: Run0, a systemd based alternative to sudo, announced

#344

Earlier quoted context omitted.

And what would be the equivalent to, "Oh, I don´t know the name of the log for this process I can see in 'ps aux', let me cd into /var/log and see what filenames I can find ... or grep everything until I can find a couple of words that make some sense so I can keep digging further"? The lack of explorability in journalctl, the "need" to keep everything locked behind their own flavor of tools and magic file types, is…

# journalctl -f _PID=${your_pid} # option 1 # systemctl status ${your_pid} # option 2 [1]: https://www.freedesktop.org/software/systemd/man/latest/jour... [2]: https://www.freedesktop.org/software/systemd/man/latest/syst...

These absolutely SUCK as answers to that question. They entirely miss the point. They provide a specific answer to a general problem.

The problem with systemnd is it assumes that it's possible for all needs to be predicted and accounted for ahead of time. While "look around at directories and files, and grep within them" works after the fact without any special knowledge or tools. The person who wrote the log file did not need to know how someone will maybe try to access it 23 years later on a different OS. It's just a regular file that can be read by anything over any kind of channel on any os. The person finding themselves needing to read the file does not need to have any particular command installed, or installable, or runnable. It does not require the happy path in order to work.

I have a joke I always say, often self-deprecating making fun of my own self for the way I do things sometimes, but also when I'm trying to commiserate with a customer so they don't feel intimidated by "the expert" or "the engineer": "37 easy steps!"

Every answer that starts with "it's simple, just journalctl ..." is FUCKING 37 easy steps. The very name of the program itself is a trainwreck. journalctl... it takes me 18 seconds just to type it.

systemd is great for managing exquisitely washed masses of drone vms. It's utter and complete shit for direct administration, operation, development, debugging, flexibility, or custom integrations.

Re: Run0, a systemd based alternative to sudo, announced

#345

I have seldom come across unix multiuser environments getting used anymore for servers. Its generally just one user on one physical machine now a days. I understand run0's promise is still useful but i would really like to see the whole unix permission system simplified for just one user who has sudo access.

NixOS may be helping multiuser make a comeback, at least it is for me and my home servers. I no longer have to containerize my apps, i can have one baremetal server with a dozen+ services, all with their own users and permissions, and i don't have to actually think about any of the separation. Plus there’s network shares. Multiple people in my home with linux PCs, each with their own slice of the NFS pie based on use…

I’m not sure how “I don’t have to actually think about any of the separation” meshes with the fact that you explicitly setup multiple users and configured file and group permissions accordingly. You clearly put a lot of thought into it.

Alternatively, containers really are a no-thinking-required solution. Everything maximally isolated by default.

Re: Run0, a systemd based alternative to sudo, announced

#346
post #4

I'm really starting to hate the sub-community in Linux that tries to constantly change it. I don't want to learn a new network config alternative with every update (Ubuntu changed its net config tool again with 24.04). I don't want an immutable os. I don't want to learn to write new config files. I just want to do what I've been doing but with new packages. If there's a problem with something, just fix it. Don't thro…

It's very fair to eschew change for negligible improvements. But I've also seen the community defend terrible stuff just because. Look at what happened with the init system. System V, fstab, etc was awful. Doing anything with a reasonable level of robustness was grotesquely obtuse and complicated. And yet it was "perfectly fine" to the greybeards. Alternative proposals were near zero. I don't have a dog in the networ…

Daemontools was pretty popular with greybeards, actually. But yeah, daemontools/runit/s6 and company have always been for handcrafted server setups, where the thing about init scripts and unit files is that they're a standard thing a package can supply and have work out of the box with minimal tweaking across distros.

Any serious challenge to systemd nowadays is probably going to have to at least offer compatibility with it. No one is going to rip it all out and start over again (again).

Re: Run0, a systemd based alternative to sudo, announced

#347
post #313

Earlier quoted context omitted.

It's just journalctl -u apache -f, assuming your distribution calls the unit file "apache", and the last few messages of the logfile appear with systemctl status apache And you don't need to worry about "is this service rotating logs appropriately?"

The important thing for me at least isn't he `-u apache` but rather knowing that `apache` exists as one of the installed services on this box. In the old ways, that was apparent because of the presence of the log file. Granted, this isn't the problem it used to be for us, however, it would come up because we'd have our services named things like `foo-ws` and knowing that `foo-ws` existed on a given box might be trick…

    journalctl -f -u 
Shows you all installed units if you have working shell completion, or 'a' gets you all units starting with 'a', etc.

Re: Run0, a systemd based alternative to sudo, announced

#348

Let's assume for a moment that it is lower risk than sudo (which is the problem is it addressing), why isn't it also called 'sudo', designed to behave the same as the thing it is replacing, so that anyone (and any scripts) that currently use sudo can carry on and be oblivious to the security benefits this new implementation offers? I'd instead like to see a post saying something like 'on systemd based systems, a more…

Presumably because it uses different options and other different stuff, it has a different name. However, it might be useful to have a command "sudo" which emulates the options of sudo so that you can still use the same "sudo" command on systemd-based systems as well as on non-systemd-based systems. I don't really know how well that would work, though.

Re: Run0, a systemd based alternative to sudo, announced

#349

Earlier quoted context omitted.

I think a micro-kernel architecture would be better in many ways, security being just one of them. With GCC, it couldn't really be separated into logically distinct modules any more than it already is. All of the constituent parts essentially use the full functionality of the base compiler part, so there is little to be gained separating them. It's not as if the C compiler from GCC, could for instance, be written in…

Given how common LZMA as a compression algorithm is, are you certain that your init system of choice doesn’t use it in any way? It’s a very common algorithm in network protocols, it’s a direct dependency of libxml, … - and if any part of your init system uses LZMA, then it just happens not to be affected because the attacker chose to target one specific system.

I wouldn't be affected regardless, because SSH doesn't depend on my init system.

Re: Run0, a systemd based alternative to sudo, announced

#350

I have seldom come across unix multiuser environments getting used anymore for servers. Its generally just one user on one physical machine now a days. I understand run0's promise is still useful but i would really like to see the whole unix permission system simplified for just one user who has sudo access.

I've never understood the need for sudo(1) on single-user, physical machines: I keep a root shell (su(1)) around for admin tasks, and it's always been sufficient.
Post reply on HN