We need to wait for a better solution in Jessie+1
We need to wait for a better solution in Jessie+1
Posted Feb 13, 2014 8:58 UTC (Thu) by tao (subscriber, #17563)In reply to: We need to wait for a better solution in Jessie+1 by roskegg
Parent article: The Debian technical committee vote concludes
Again, as others already explained, if you don't like binary formats, just set journald to pass-through mode and use rsyslogd, or keep the journald settings as they are but run rsyslogd on the side (that way you get your beloved text-logs, which still having the extended logs that journald provides available side by side).
The system configuration for systemd is done using text files and are much easier to overview and understand than initscripts.
TINC.
Also, towards the end of your message you really sound like a troll. Next time try to plead your case with rational arguments instead of troll-like behaviour.
Posted Feb 15, 2014 22:42 UTC (Sat)
by lsl (subscriber, #86508)
[Link] (4 responses)
It's probably just a mounted FUSE filesystem. Per default those can't be accessed by root to prevent random users from DOSing or at least annoying root's processes.
There's no connection to Pulseaudio.
Posted Feb 16, 2014 1:51 UTC (Sun)
by roskegg (subscriber, #105)
[Link] (3 responses)
NOTHING should be withheld from root. When I am root, I want to be able to access my directories! Also, since all the permissions were turned off, even running tar with the correct user permissions didn't work. It is frickin UGLY.
Posted Feb 16, 2014 2:35 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link]
On the root-is-omnipotent front, have you heard of Secure Boot? I think it has benefits for groups like schools and companies who want to ensure that *their* hardware is used as intended, not by the student or employee. If I have root, it is not necessarily true that I own the hardware too (e.g., installing packages might be relevant for teachers). The fear with SB is that manufactures will start "owning" hardware they sell indefinitely. *That* is valid, but it is not a reason to not do it.
Posted Feb 18, 2014 21:30 UTC (Tue)
by Wol (subscriber, #4433)
[Link]
From Rev19 onwards, Primos had ACLs. The one thing you couldn't take away from the superuser was the ability to override them (actually, it was implemented as a "priority acl").
So if I was testing stuff that required to run as super-user, I could just do a "set-priority-acl live-data superuser:no-rights", and then be CERTAIN that however badly I screwed up, I couldn't damage the live system. Once I was happy it was all working, I would delete the priority acl and could run the script for live.
After all, if the super-user always has the ability to edit access rights, then any (by default) lack of access rights merely makes things that little bit harder. Which is what you want - the last thing you want is the system making it easy for finger-trouble et al to cause a disaster. It's a safety-catch, not a barrier.
Cheers,
Posted Feb 18, 2014 21:56 UTC (Tue)
by rodgerd (guest, #58896)
[Link]
Anyone who has worked as a sysadmin for anything other than their own toy boxes should understand that.
We need to wait for a better solution in Jessie+1
We need to wait for a better solution in Jessie+1
We need to wait for a better solution in Jessie+1
We need to wait for a better solution in Jessie+1
Wol
We need to wait for a better solution in Jessie+1