Live data from Hacker News

Run0, a systemd based alternative to sudo, announced

mastodon.social

531–540 of 902 posts

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

#531
post #506

Over the years I've switched from various cron daemons (anacron, cronie), sysloggers (r-syslog, syslog-ng), network managers (netifrc, NetworkManager) even ssh servers/clients (dropbear, openssh), and init systems (sysvinit, openrc) and never have I felt the need to switch to systemd despite reading some of Lennart's posts. I've used Gentoo over the years, maybe that's why. Doas is available on Linux as a sudo altern…

Now if then the commands run via some kind of privilege elevation mechanism would require pledges to be used, that would be awesome: https://news.ycombinator.com/item?id=38037075

"This needs root", okay. But you only get exactly what you need.

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

#532
post #463

Earlier quoted context omitted.

Well `-u` refers to the unit file, so I would start with `sudo systemctl status` which lists the status of active unit files. I bet I could find the unit name I'm looking for there. If not, then `sudo systemctl list-units` should have it. (and you can grep the output of both) Systemd and Journald are less opaque than I used to think. Even if you don't want to learn the commands, all of its unit files (and the relatio…

How would you exclude certain units from your logs? Let's say that Auditd is spamming your logs, and you just want to exclude those? Can you filter on search? How do you prevent applications from writing to Systemd at all?

I would start with `man systemd`, or maybe `journalctl —help`.

If you don’t want a service to log to systemd, then don’t run it in systemd?

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

#533

Earlier quoted context omitted.

# 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 di…

I didn’t answer the general question because I don’t care, I have no dog in this fight. Im just happy to provide information.

I like systemd and have found it extremely useful. If it doesn’t fill a need for you then use something else.

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

#534

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.

Technically not with virtual machines as the hardware is shared, though I agree, nowadays accounts and access control of the system belong to the virtualization layer below. The benefits of multiple accounts per machine are tiny and not worth the complexity for server setups. We could significantly simplify things by getting rid of the account system. The same could be said for a lot of systems like database servers.…

>> Typically it's just one database, one user (your application server) with full access

This is a terrifying way to access databases.

Super user, A Modify user (just below super but cant delegate rights) for schema changes. A read/write app user... Probably a pile of read only users who, have audit trails... You might want some admins or analytics users (who have their own scheme additions).

The words security and audit trails all spring to mind.

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

#535
post #472

Earlier quoted context omitted.

Regarding your first point: some people agree, most notably the OpenBSD people who did something about it and wrote “doas” as a replacement; which fits the most common use-cases of sudo without fanfare.

And, as LP points out, fails to solve the actual problem because it's still locked into the exact same flawed Unix model, and refuses to integrate with anything else in the system to get things done in a better more systematic way. It's just a slightly refined version of the same tired old Unix way

If you don't like Unix maybe don't write software for a Unix clone.

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

#536

I'm not a fan of sudo. It's does so much it needs BNF to describe it's configuration format. Who knows, maybe replacing the configuration with polkit is a good idea. Still it's a stand alone binary with one clear job to do, simple enough that one person has no trouble getting their head around it so it's not surprising it hasn't had too many problems over it's long life time. This made me smile: > sudo has serious pr…

I initially had the same reaction although having read the whole thread, the author convinced me that SUID is in fact a fatally flawed architecture and that run0's client-server architecture is correct.

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

#538
post #392
post #369

Earlier quoted context omitted.

I appreciate that someone's invented shoes you inflate and snap. I can see some advantages. That said, when I'm in a hurry and going to do a thing that I've been doing every day of my life, I'm really not a big fan of having to stop what I'm doing and reexamine a tool I've used all my life to figure out how to use it. I learned this stuff decades ago and I'm not anxious to relearn how to do it for a fractional improv…

Don’t think of it as relearning a tool, think of it as learning one tool which works for everything. You no longer have to implement your own log rotation, compression, etc. or work out which configuration each program needs to do that in the manner you expect – for example, “is it safe to rotate a log file?” requires you to know implementation details on each program.

>think of it as learning one tool which works for everything.

For how long?

I've been around for decades at this point with people telling me how the newest and greatest thing will obsolete everything that came before it.

The best way to look through logs is still to materialize them in as text in a files hierarchy and use find with grep to look for issues.

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

#539
post #510

Earlier quoted context omitted.

Two things: - Non code files were counted for both sudo and systemd. That's because I'm lazy, not because I think it influences the result one way or the other (I don't what effect it would have). - Separate binaries are not separate logical entities. Pointing to separate binaries is a misdirection. systemd is a set of binaries cooperating using RPC (dbus) to yield something bigger than any single binary. The biggest…

> Separate binaries are not separate logical entities. They're separate programs, sometimes essentially completely independent, sometimes sharing almost no code at all. For example, systemd-init does not have dependencies on all of the other programs, or vice versa. You can use the systemd-boot bootloader without using systemd's init daemon. You can use the systemd init daemon without using the systemd-boot bootloade…

[flagged]

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

#540
post #81
post #62

Earlier quoted context omitted.

> you can actually declare startup dependencies and other useful relationships In theory, yes. In practice, I had a lot of trouble ordering things correctly in non-trivial cases. > it's quite annoying that the armchair linux experts complain about how "lol systemd is so stupid for reinventing the wheel, give me my shell scripts back" I can only speak for myself, but I don't want the abysmal sysvinit scripts back. I j…

In a similar vein, systems like openrc use "shell scripts" as well, but can generally be written declaratively[1]. This provides greater flexibility when it comes to creating one-shot services or services that require a little setup before running, as you can just re-define the start() function, rather than requiring one to make a separate shell script for it, or dependency tree, like you'd have to in systemd land. "…

Debian's sysvinit scripts can also be declarative. https://github.com/DanielAdolfsson/ndppd/blob/master/ndppd-i...

The full system also cares about dependencies and parallel running. And this is not recent, but the black legend will never die.

Bonus: by having the shipped scripts under /etc, tools like etckeeper can show your changes as well as updates, all in one place.

Post reply on HN