361–370 of 902 posts
Earlier quoted context omitted.
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.
The attacker chose to target a very specific component of a very specific system. It was their choice, not some sort of technical requirement that made it impossible to use a different attack vector. Just as they chose not to target other Linux distributions that use systemd.
You’re essentially saying “I was safe because the attacker chose to ignore me.” That worked well this time, but it’s a pretty dangerous stance.
I wonder what other existing programs Will Systemd attempt to replace in the future. My bet is /bin/sh, maybe they went further to replace the entire POSIX utilities.
It will come with `filectl` for all your file operations, so you will no longer need `cd`, `pwd`, `touch`, `rm`, `mkdir`, `cat`, `grep`, `find`, etc. Instead you do everything through `filectl` commands.
This will deprecate many commands from GNU coreutils, which is a good thing because replacing things is always good.
Then, since programs are just files, and filesystem will be part of systemd, any program you want to use will obviously have to go through systemd as well, meaning they will need to be a service unit of type `oneshot`, because this way we keep everything well integrated together.
Don't worry tho, you only write the unit files once and they work forever. The only thing you need to remember is that, instead of `cargo build` you'll need to use `filectl exec -u cargo build` (`filectl exec -u` is only 3 words, so you don't have the right to ever complain about this tiny little change).
Anyone who doesn't like these changes is stuck in the past.
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…
Earlier quoted context omitted.
I tried it a bit ago (when it was still called uid0, pre-release), I also wasn't a fan of the tinting. I like the intent behind it, but some terminals already tint the header color when running sudo, I haven't tested if its done specifically for sudo or if its in a more generic way that could handle this as well.
I can think of a number of things this tinting would break.
I'll give them the benefit of the doubt and assume they only do this if $TERM supports color. But still. That $TERM variable can surprise a poor programmer in all sorts of ways.
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.
This will be great. We can finally deprecate sudo on systemd systems. Then we should be able to deprecate PAM, setuid bit, etc.
Is removing setuid actually a win? I know it presents a security risk, but it feels like we're not actually removing that attack surface, just moving it around.
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…
No they don't. They are good answers. If you want answers to a more general problem, then ask. This is not an emotive topic.
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 could `tail -f *.logs`. I remember how I didn't need to remember about `--no-pager` and `--follow`. journalctl supports -f, which by your own account you were already using for tail, so I'm not clear what's worse there. > 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 created by logrotate with a date in the filename. My memory of thi…
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 improvement, and I'm not even really 100% sure that this new "inflate and snap" shoe model is actually an improvement, except for very specific use cases.
Earlier quoted context omitted.
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.
Its just maybe easier way to not have to go to the root shell.