Live data from Hacker News

Run0, a systemd based alternative to sudo, announced

mastodon.social

431–440 of 902 posts

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

#431
post #230

Earlier quoted context omitted.

> remember when you had to write bash scripts to start, stop, restart services This was a really big pain, yes, but I also remember how I could `tail -f *.logs`. I remember how I didn't need to remember about `--no-pager` and `--follow`. I knew where the files were, what they were called. I remember how I didn't have to google how to find logs between 10 days ago and 4 days ago, because the logs would be in a .tar cr…

I've recently become a fan of the `-x` flag to journalctl, which adds additional context to log entries and even suggests remediations at times. I've identified and fixed several issues on my Linux systems that way. Kind of hard to get that with tail -f!

How does it work? Can I pipe non-journald logs into the -x flag to take advantage of this lookup?

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

#432

Earlier quoted context omitted.

> You yourself just said these crappy commands were good, as a purely unfounded assertion. They are great because you just say they are great. That is even less objective than my rant. I at least explained what exactly I find so bad. Tell me more about not emotive. Very well: I didn't say the commands were good or great. If you attempt a little objectivity you'll see it.

If you attempt a little objectivity, you will see that addressing the answers (vs the commands) was in my first response. Before even going into the nature of the commands, I said that the answer does not match the question. The answers addressed details, while the details in the question were merely examples. Missing the point is actually merely one of the at least two dimensions along which the answers suck. Thank…

> The answers addressed details, while the details in the question were merely examples.

No, the answers addressed the two scenarios in the question. That's why they don't "SUCK". They are good answers to the question as asked, and not the question as you dreamed it. If you spent ten words on asking the question of your dreams, rather than having a go at people for not answering it (whatever it is), you might have an answer.

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

#433
post #374

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 always still split up "sysadmin" from "deploy". Ephemeral setups (amongst which k8s) remove that need but introduce a big load of other stuff. Having a VPS that is managed by sysadmins (users with sudo rights, authed with keys) and on which partly overlapping "deploy" users can write to small parts and maybe do a passwordless "sudo sysctl restart fooapp" but only that, is a nice and simple setup. I manage at least…

I think you mean systemctl.

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

#434

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…

alias sudo="run0"

If run0 supports the same flags and parameters they'll be interchangeable with just an alias.

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

#435

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…

> Oh, I don´t know the name of the log for this process I can see in 'ps aux',

With services using journald, there's no "name of the log" because everything's in the journal, so that part isn't a problem. Rather than "is this in auth.log or syslog or thisservice.log", it'll always be in the journal.

> let me cd into /var/log and see what filenames I can find

You can filter journal entries by unit (-u) or by service identifier (-t). Often, though, I find it really useful to be able to see the adjacent entries from other services at the same time, since that can give some indication of what's happening on the system that caused an issue.

> or grep everything until I can find a couple of words that make some sense so I can keep digging further

journalctl --grep, or more conveniently, journalctl and then / to search.

> The lack of explorability in journalctl

It's explorable by dozens of different axes, and if all of those aren't sufficient, you always can get the whole thing as text and run any command you like on it, or get it in structured form and do structured queries on it.

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

#436

Just a reminder that there are plenty of systemd-less distros available. Also a reminder that those distros would have been safe from the nearly-solar-winds-level backdooring of Linux distros from XZ utils.

Also remember that systemd-using distros like, say, Arch were also safe from the nearly-solar-winds-level backdooring because the backdoor targeted specific distros widely used as servers. Obviously the solution to security from backdoors is only using distros that aren't popular for servers

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

#437
post #303

Earlier quoted context omitted.

It was a bit unclear to me from the thread, is there a persistent configuration option for this? I like the idea of tinting the terminal, but I also want to be able to turn it off with a global config option rather than having to type out a --background flag every invocation.

Aliasing the command as the command + your default arguments is the easiest general solution to this kind of problem. I'm not sure if there is a "systemd way" to permanently set it though.

I accidentally compile color support out of st, or set xterm*colorMode:false to avoid seeing the backside of a unicorn randomly rubbed all over the terminal, on account of git and other wares being bad at their inability to not spew color codes. A sensible default would be to set no colors, in the event that the colors are unreadable (due to colorblindness, etc) or distracting, but that ship sailed. Most of my vim config on RedHat linux was disabling wacky vendorisms, and back when I used linux I did have a "special terminal" for some NVIDIA installer that mandated colors to be usable. Maybe the terminal title was set to Fisher-Price, maybe not.

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

#438

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.

You'll just end up implementing multiuser support anyway due to different permissions to different devices services

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

#440

Earlier quoted context omitted.

No, it hasn't. You forget, the reason systemd was originally rationalized for its insertion into our trees was "boot times are too slow". Its chameleon-like nature and ability to solve the hastily described problem du jour seems to be its only consistently touted feature. Bash scripts that start processes are ephemeral. If it's signal handling you want, that was your program's problem. Either that or your program did…

Same thing is happening with Wayland. It reduces features adds complexity and solves no new problems but here it comes.

How is Wayland more complex than X?
Post reply on HN