Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
openRC instead of sysVinit?
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4  Next  
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sat Jul 29, 2017 9:59 pm    Post subject: Reply with quote

steveL wrote:
You need to be careful how you refer to this stuff, as the above sounds like this is "innovation", when it is in fact entirely old-hat.
CasperVector wrote:
This is somehow similar to the self-pipe trick
Absolutely; in fact I was thinking of that when I posted the above.
Quote:
.. what I wanted was to show that you can do readiness notification, with little additional complexity in the init/rc system and minimal modification to the daemon, using only POSIX mechanisms, in a resource-efficient way.
No argument from me: I've been stating the same thing on these forums for five years or so (however long people have been arguing about "replacing sysvinit" when they mean "sysvrc", whereas Gentoo has been using openrc for over a decade.)
Quote:
If the proposed standard is technically sound, "setting the standards" would not be bad. And I argue that this is technically the best way to daemon readiness notification I know: it is stable, portable and efficient, and has the lowest complexity (of both the interface and the implementation); additionally, it is politically neutral (the client-side needs nothing but the standard library; so instead of enforcing vendor lock-in, it prevents vendor lock-in).
My point was not about whether it is vendor-neutral at the API level, though ofc that is a necessary prerequisite.

My point was simply that it's a cop-out: you've redefined the problem, in order to say that the problem is solved.
In case it's not clear, the initial requirement, and indeed selling-point, of all of these newer rc-systems is that they handle your daemons without changes to their codebase.
Talking about compliance at the daemon-level just does not wash.

This has nothing to do with technique.
steveL wrote:
It's OK, I can handle that things are (finally) changing to avoid double-forking (which wiser heads than I have argued for decades is a bad idea) but when that's more than encouraging an -F foregrounding flag of some kind in the ones that still prefer double-fork as default, and encouraging others to simply use foregrounding by default; when you're now talking about an enforced parameter, for example, to specify the fd to listen on (as systemdbust does it), or whatever other OS- and/or rc-specific approach you use (relying on the daemon to know the fd being the worst), then frankly all you've done is fail on the initial requirement you set yourself, and sold to your users.
And more importantly, in the process you've fractured the ecosystem.
Quote:
The fd is decided by the daemon, not s6: a daemon provides an command line option to write a newline to fd 3 upon readiness, the user writes `3' in `notification-fd', that is it.
Sure; a new cli-option (what I called an "enforced parameter" above) for some binary daemon in /opt.
Yeah, I know, they're not "compliant" so it doesn't matter, and they're handled as "legacy" daemons (and everyone hopes they'll go away soon, etc. Certainly all the mindshare goes on the nu-standards-compliant ones.)
Quote:
This way, the modification to the daemon can probably be limited to several lines for a new option and one line for writing into the fd; no additional dependency, almost certainly much less code than a polling script, and therefore much less total complexity. If you want readiness notification, it really cannot be simpler; additionally, this is completely optional, and you still can use polling if you really dislike the idea of changing the daemon code.
Please stop putting words in my mouth; I never said anything about wanting to use polling.

The technical point is that "readiness notification" is a specific instance of process-synchronisation, which is much more interesting, and has lots of methods, none of which actually needs to be in the daemon itself (and keeping it out has pros, like flexibility as well as simplicity, besides the obvious compatibility.)

FTR, though, I'm fine with this as an option; it replaces the exit from the initial process as a means of notifying the parent.
It's just TELL_PARENT via a pipe; one of several standard variants.

I just think it's unnecessary if you actually do proper monitoring, which seems to me to be required, both technically and in business-terms, based on what admins say: "the daemon telling you everything is okay at startup, does not actually mean it is, nor that the daemon will run correctly." (process state tells you even less, so "process supervision" is irrelevant.)
And that it's a deflection from those real issues. "Good enough" at the "compliance" level, so why bother monitoring correctly?
I can also foresee a move toward "let's make that byte mean something" and hello, version 2.0 of the "standard."

Whereas if you monitored correctly from the get-go, then you wouldn't ever need changes to any daemon, and you could provide true dependency-resolution, where it actually matters. That smells like a much better overall approach. (and no, it does not imply "polling", though ofc an admin can specify a periodic check.)

One other niggle: an rc-system needs to distinguish between daemons (or "services") and actions. This should be part of the base terminology, reflected in the codebase, not a bolt-on.
Much as LDEPEND (like BSD LIB_DEPENDS) needs to be a base concept, not a bolt-on, in portage-space.
steveL wrote:
"Use htop" (which any admin already does) is a copout. Either we're managing this, or we are not.
You seem to think I was indicating a desire to go back to using solely pid-files, in the traditional manner for double-forked, unmonitored daemons; when I meant them as a fallback, as quoted: to let the admin know without equivocation or fuss, what we were managing before we crashed.
Quote:
I mean, if you are concerned about these cases, you do not get significantly better solutions: simply relying on PID files ignores the possible race conditions, and is therefore roughly as reliable as using htop.
And again; who said anything about "simply" ie solely using PID files? In fact I'd specifically excluded that.
We dress in layers, not in a wool blanket.
Quote:
My point is that
Quote:
The "dangers of signalling the wrong process" can easily be mitigated
is incorrect, and that mitigation techniques for this, other than process supervision, tend to be complicated and therefore less favourable.
*sigh* you're missing the point: this is about when your daemon manager (s6), ie "process supervisor", has crashed.
I was simply stating that it must leave some persistent state in a (likely tmpfs) filesystem, for recovery; and at that point, an "skill" command is both useful, and seemingly a no-brainer. The rest is about how you possibly go about that; I don't want to get into an argument about the specifics, as I think we're getting bogged-down, and it is not relevant to whether or not, the command facility is in fact useful.

"Process supervision" is not a mitigation technique for stopping crashes in your code.
Nor is it anything new: it's the standard state of affairs whenever you fork; so it is by no means specific to an rc-system.

AFAICT you still haven't said anything about what you would do when the supervisor crashes: where is the monitoring then? how do you recover? (which is essentially a wrapper for) what does the admin fall back on when everything truly is FUBAR? ("htop" is not enough.)

"It's very unlikely" is the wrong answer on more than one level. (imnsho ofc.)
Quote:
Does those you'd rather learn from include Plan 9?
Obviously it does; though I don't agree with every decision (whoever does?) and I find the notion of all the old-school beardies running Macs nowadays to be hilarious.
Quote:
Which seemingly does not apply at least to s6/s6-rc and nosh, which appear at least as portable as openrc.
OFC not; I was talking about systemdbust, and the cargo-cult, which seems to have a real problem with reading books. (I blame the indoctrination^W education system.)
Quote:
And I doubt many people can write much better shell scripts than this.
Lul, this keeps happening. Run that by #bash (they teach sh as well, if specified upfront) and see what you get. The style is ${shit} I'm afraid, and the over use of eval where unneeded is painful, as is the apparent inability to use case directly. (I know full well that expansion of user variables is required in configure-space, believe me.) Oh and there's a bug in the loop trying to establish $tmpc/$tmpe, as well as a portability-SNAFU iirc (I could be wrong; it's happened before.. ;)

Don't get me started on 'test'; it reads like it's written by someone who has read all the GNU and RedHat guidelines for configure, which are cack afaic (many of them have to do with the misuse of m4); not by someone who groks shell.
It's pretty much what I'd expect from a C coder, iow: nowhere near as robust as their code.

Please don't take that as personal criticism of whoever wrote it: it's my honest reaction on reading it, and is purely about the sh.
http://lists.busybox.net/pipermail/busybox/2015-March/082606.html wrote:
Pardon my bluntness, ... You are certainly very experienced, but you are not the only one who knows how Unix works; ... we are not as clueless or malevolent as some people you may have had the displeasure of working with; and would you believe, some of us know how to design Unix software that does not need a power plant to run.
Point taken.
I am sorry if my rant came across as aimed at you; it never was.
Like I said: this is discussion with people who know what the words mean; intended by contrast to most people we meet IRL.

edit: Having read the above discussion, I feel I might be coming across as critical of specific projects, when that is not my intent, nor even in mind.
FTR I like the approach taken by s6; it is a natural progression from Bernstein's work, eg: the split of tcpserver into various aspects makes sense.


Last edited by steveL on Sun Jul 30, 2017 4:57 pm; edited 1 time in total
Back to top
View user's profile Send private message
Tony0945
Watchman
Watchman


Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA

PostPosted: Sat Jul 29, 2017 10:10 pm    Post subject: Reply with quote

Thanks, josephg.
Back to top
View user's profile Send private message
CasperVector
Apprentice
Apprentice


Joined: 03 Apr 2012
Posts: 156

PostPosted: Tue Aug 01, 2017 1:10 pm    Post subject: Reply with quote

steveL wrote:
Absolutely; in fact I was thinking of that when I posted the above.

So I think you have, perhaps because of the systemd fiasco, become too sensitive to advocation of things that are technically sound, but less well-known (resulting in worse solutions being "demographically" dominant). Yes, they are just combinations of old mechanisms; no, I do not want to hide the fact that they are, and actually I always stress that they are.

steveL wrote:
My point was simply that it's a cop-out: you've redefined the problem, in order to say that the problem is solved.
In case it's not clear, the initial requirement, and indeed selling-point, of all of these newer rc-systems is that they handle your daemons without changes to their codebase.

I am afraid you are really wrong on this point: at least I never know any author of a daemontools-like software suite claiming this (feel free to prove me wrong). For instance, introducing foregrounding is usually much more complicated than implementing the s6 readiness protocol; so if your point stands, daemontools would never exist, let alone others including s6. Please do not take the false promises made for systemd as those for others.

steveL wrote:
Sure; a new cli-option (what I called an "enforced parameter" above) for some binary daemon in /opt.
Yeah, I know, they're not "compliant" so it doesn't matter, and they're handled as "legacy" daemons (and everyone hopes they'll go away soon, etc. Certainly all the mindshare goes on the nu-standards-compliant ones.)

Since this point is somehow based on a guess of Laurent's mentality, I found this relevant: I do not think a programmer as conservative as him would expect what you call "legacy" daemons to go extinct. I tend to believe that he does not think all daemons need readiness notification, and that he would never intend those which do not need to signal readiness to implement the interface.

steveL wrote:
The technical point is that "readiness notification" is a specific instance of process-synchronisation, which is much more interesting, and has lots of methods, none of which actually needs to be in the daemon itself (and keeping it out has pros, like flexibility as well as simplicity, besides the obvious compatibility.)
...
I just think it's unnecessary if you actually do proper monitoring, which seems to me to be required, both technically and in business-terms, based on what admins say: "the daemon telling you everything is okay at startup, does not actually mean it is, nor that the daemon will run correctly." (process state tells you even less, so "process supervision" is irrelevant.)
And that it's a deflection from those real issues. "Good enough" at the "compliance" level, so why bother monitoring correctly?

Although I generally avoid introducing philosophical issues, here I find it imperative to reference "worse is better" (note that Laurent's conservativeness can also be considered as adherence to this principle). Complete monitoring is of course desirable, but it would require significantly higher complexity in the codebase, in exchange for relatively little benefit (again feel free to prove me wrong); and instead, it would be more advisable to fix daemons that are buggy and to make daemons tolerant to transient failures in dependencies. In comparison with "waiting for a dependency to be ready", "waiting for a dependency to report readiness" is much better defined, and useful enough.
And "process supervision" is surely relevant, for reasons I will show below.

steveL wrote:
I can also foresee a move toward "let's make that byte mean something" and hello, version 2.0 of the "standard."

Note that the server (`s6-supervise') will close the fd immediately upon reading any one character, so there would not be much point in the "something": the amount of information is limited to that of a return value; and if the daemon needs to return a value, it is obviously better for it to simply exit() that value. So even technically, this kind of change would be virtually meaningless, not to mention that Laurent would need to be desperate to do it.

steveL wrote:
One other niggle: an rc-system needs to distinguish between daemons (or "services") and actions. This should be part of the base terminology, reflected in the codebase, not a bolt-on.
Much as LDEPEND (like BSD LIB_DEPENDS) needs to be a base concept, not a bolt-on, in portage-space.

The functionality of oneshots (as well as dependency-based starting/stopping of services, including oneshots and longruns) is provided by s6-rc; s6 does not know or care about oneshots, because its job is to take care of longruns.

steveL wrote:
And again; who said anything about "simply" ie solely using PID files? In fact I'd specifically excluded that.
We dress in layers, not in a wool blanket.

Well, in fact I found htop to be significantly more powerful than PID files, because it can view process command lines; though it might be slightly worse than `skill' as you supposed, mainly because of more severe vulnerability to the TOCTTOU problem. So I think it is fair to say `skill' is not a significantly better solution.

steveL wrote:
*sigh* you're missing the point: this is about when your daemon manager (s6), ie "process supervisor", has crashed.
I was simply stating that it must leave some persistent state in a (likely tmpfs) filesystem, for recovery; and at that point, an "skill" command is both useful, and seemingly a no-brainer. The rest is about how you possibly go about that; I don't want to get into an argument about the specifics, as I think we're getting bogged-down, and it is not relevant to whether or not, the command facility is in fact useful.

So I misunderstood you. But do note that I still disagree wrt the "easily" part.

steveL wrote:
"Process supervision" is not a mitigation technique for stopping crashes in your code.
Nor is it anything new: it's the standard state of affairs whenever you fork; so it is by no means specific to an rc-system.

And it is not intended as one, or otherwise the s6 codebase would grow crazily like systemd does, just to mitigate problems with other software. I always considered auto-restart to be a minor consequence of process supervision (but this is my personal opinion; Laurent does prefer auto-restart); simpler (just write() to stderr) and more robust (fd holding of the pipe) logging, reproducible execution environments, and the dramatic reduction of complexity and incorrectness introduced by pidfiles are much more important instead.
Of course it is not specific; however, it does have specific nice properties when applied in service management and logging, as shown above.

steveL wrote:
AFAICT you still haven't said anything about what you would do when the supervisor crashes: where is the monitoring then? how do you recover? (which is essentially a wrapper for) what does the admin fall back on when everything truly is FUBAR? ("htop" is not enough.)
"It's very unlikely" is the wrong answer on more than one level. (imnsho ofc.)

I presume `s6-svscan' as init; it will try its best (within reasonable complexity) to stay alive; when it cannot, it exec()s into a `crash' script provided by the sysadmin. `s6-svscan' supervises `s6-supervise' processes, which are the real supervisors; when `s6-supervise' dies, it is restarted by `s6-svscan' (you can write a wrapper script to replace `s6-supervise', so hooking is doable). The mechanism is there, and the policy is up to the sysadmin.
"It's very unlikely" is a wrong answer if you take it as synonymous to "the problem does not exist". However, what I meant (sorry I did not expand on this), is that the problem can exist, but will be very rare, and just in case, (1) you are provided with mechanisms to do handle it; (2) it might be more productive (cf. "worse is better") to focus on investigating the causes and fixing existing bugs, and prepared redundancy will certainly help. I am also interested in whether you consciously use ECC memory on most servers, considering that the probabilities of the events seem to be on similar magnitudes.

steveL wrote:
Lul, this keeps happening. Run that by #bash (they teach sh as well, if specified upfront) and see what you get. The style is ${shit} I'm afraid, and the over use of eval where unneeded is painful, as is the apparent inability to use case directly. (I know full well that expansion of user variables is required in configure-space, believe me.) Oh and there's a bug in the loop trying to establish $tmpc/$tmpe, as well as a portability-SNAFU iirc (I could be wrong; it's happened before.. ;)
Don't get me started on 'test'; it reads like it's written by someone who has read all the GNU and RedHat guidelines for configure, which are cack afaic (many of them have to do with the misuse of m4); not by someone who groks shell.
It's pretty much what I'd expect from a C coder, iow: nowhere near as robust as their code.

May I, sincerely, request an elaboration on the issues you see? I can report those unforgivable to Laurent. Laurent is not LP, and I am not his fanboy; I think you can trust us.
I found the style (including the use of `test') to be, while somewhat weird, mostly clear and understandable. Perhaps not outstanding, but definitely better than most shell scripts I see from various open source projects, which is why I said "many".
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C


Last edited by CasperVector on Tue Aug 08, 2017 3:49 am; edited 1 time in total
Back to top
View user's profile Send private message
Bones McCracker
Veteran
Veteran


Joined: 14 Mar 2006
Posts: 1611
Location: U.S.A.

PostPosted: Tue Aug 08, 2017 3:20 am    Post subject: Reply with quote

We wouldn't need an init system if they'd just put a chip in everybody's head, like I been saying.
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 20048

PostPosted: Wed Sep 27, 2017 12:23 am    Post subject: Reply with quote

Has anyone downgraded to 0.17 (or earlier)? I'm currently on 0.28, so I'm curious how feasible it would be? Is maintaining an older version significantly problematic with updates?

I've retrieved the ebuilds from attic and the tar file from git. Not sure yet if that's enough to keep it locally.

Alternatively, is anyone moving to an alternative? I've read of some tests, but it doesn't yet appear that there's any significant abandoning of <=0.17.
_________________
Quis separabit? Quo animo?
Back to top
View user's profile Send private message
Tony0945
Watchman
Watchman


Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA

PostPosted: Wed Sep 27, 2017 12:49 am    Post subject: Reply with quote

pjp wrote:
Has anyone downgraded to 0.17 (or earlier)? I'm currently on 0.28, so I'm curious how feasible it would be? Is maintaining an older version significantly problematic with updates?<=0.17.


Looks like 0.17 here on three of four boxes. I think the fourth may be 0.13 but it's dual boot and booted to Windoze right now.

I've updated the ebuild to pass repoman -a, no code changes. The ebuild is at https://paste.pound-python.org/show/T3eqvbpbAT5o4sQo3vyv/
I can pastebin the patches too if you can't find them. And obviously I have the 0.17 tarballs. Don't know how to send them, though.
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 20048

PostPosted: Wed Sep 27, 2017 2:07 am    Post subject: Reply with quote

Thanks. I can't find reference to the specific patches, do you know what they are?

I'm hesitant to trust random overlays, but of the 3 I found which had 0.17, this one seems to have the most content:
Code:
localmount.initd                      openrc-0.12.4-bootmisc.in.patch      openrc-0.22.4-rc.conf.patch
localmount-r1.initd                   openrc-0.12.4-norun.patch            openrc-0.23.2-checkpath-mkdir.patch
localmount-r2.initd                   openrc-0.12.4-rc-cgroup.sh.in.patch  openrc-0.23.2-norun.patch
localmount-r3.initd                   openrc-0.12.4-tmpfs.patch            openrc-0.23.2-rc.conf.patch
localmount-r4.initd                   openrc-0.13.7-init-common-post.sh    openrc-0.8.3-ccwgroup.patch
Manifest.gentoo                       openrc-0.13.7-norun.patch            openrc-0.8.3-deprecation_warning.patch
Manifest.gentoo_prefix                openrc-0.16.4-cgroup-race.patch      openrc-9999-msg-style.patch
openrc-0.11.5-bootmisc.in.patch       openrc-0.16.4-init.patch             openrc-9999-pause.patch
openrc-0.11.5-init.sh.Linux.in.patch  openrc-0.16.4-norun.patch            openrc.logrotate
openrc-0.11.5-rc.h.in.patch           openrc-0.18.4-devfs.patch            root.initd
openrc-0.11.8-init.sh.Linux.in.patch  openrc-0.19.1-functions.sh.in.patch  root-r1.initd
openrc-0.11.8-norun.patch             openrc-0.21.3-rc.conf.in.patch       root-r2.initd
openrc-0.11.8-rc.h.in.patch           openrc-0.22.4-cgroup-race.patch      start-stop-daemon.pam
openrc-0.11.8-tmpfs.patch             openrc-0.22.4-norun.patch


And of the 3 overlays plus the ebuild you provided, and the ones I found in attic, none have the same checksum :)
Code:
295ba9373605aa4b6c4016d6870e210b  openrc-0.17.ebuild
b7edb0bae55311057bf0ce0c18e50e93  openrc-0.17.ebuild
11d15f30c04a624baa2580b79fd3a78c  openrc-0.17.ebuild

54aa8c6fbc4369636a83da3a3714f692  openrc-0.17.ebuild

b12108f5f6ffdbc51084d6253ae97ac2  openrc-0.17-r1.ebuild
7d6b1b652b68a9a971a0b6e58d7d04b3  openrc-0.17-r2.ebuild
ccc06af27a821fa7eae039a31630c870  openrc-0.17-r3.ebuild

_________________
Quis separabit? Quo animo?
Back to top
View user's profile Send private message
Tony0945
Watchman
Watchman


Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA

PostPosted: Wed Sep 27, 2017 2:24 am    Post subject: Reply with quote

Mine had changes to reflect current guidelines like removing the Id$ line. Try diff or meld to see the changes.

Re patches:
Code:
openrc-0.8.3-ccwgroup.patch             openrc-9999-pause.patch
openrc-0.8.3-deprecation_warning.patch  openrc.logrotate
openrc-9999-msg-style.patch             start-stop-daemon.pam
Not sure which patches 0.17 uses and no time right now to investigate. Doubt if the 9999 patches apply.
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6095
Location: Dallas area

PostPosted: Wed Sep 27, 2017 9:32 am    Post subject: Reply with quote

sys-apps/openrc-0.13.11

I've had it locked at this version for quite a while and haven't used any extra scripts to modify it.
But I've had it locked at that version, not downgraded, but downgrading shouldn't be a problem.
I have a few packages that I've had to lock with it, netifrc and udev-init-scripts, I think.
There might be one or two others but I can't think of them off the top of my head.
Running 4.11.7-zen kernel

System works perfectly fine, IMO.

Edit to add:
I have eudev locked with anything above 2.0 and am running 1.10-r2 but not sure if that's due entirely to the openrc version.
I keep stuff like that in my local repository and mask as necessary.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
Tony0945
Watchman
Watchman


Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA

PostPosted: Wed Sep 27, 2017 1:36 pm    Post subject: Reply with quote

Anon-E-moose wrote:
Edit to add:
I have eudev locked with anything above 2.0 and am running 1.10-r2 but not sure if that's due entirely to the openrc version.
I keep stuff like that in my local repository and mask as necessary.

With the 0.17 I'm running:
Code:
X3 ~ # emerge -pv openrc eudev udev-init-scripts netifrc

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R    ] sys-apps/openrc-0.17::oldgentoo  USE="ncurses netifrc pam -audit -debug -newnet (-prefix) (-selinux) -static-libs -tools -unicode" 0 KiB
[ebuild   R    ] net-misc/netifrc-0.2.2::gentoo  0 KiB
[ebuild   R    ] sys-fs/eudev-1.10-r2::local  USE="doc gudev hwdb introspection keymap kmod modutils openrc rule-generator (-selinux) -static-libs {-test}" ABI_X86="32 (64) (-x32)" 0 KiB
[ebuild   R    ] sys-fs/udev-init-scripts-32::gentoo  0 KiB


And on the one machine that runs eudev-3.15:
Code:
k6 ~ # emerge -pv openrc eudev udev-init-scripts netifrc

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R    ] sys-apps/openrc-0.17::oldgentoo  USE="ncurses netifrc pam unicode -audit -debug -newnet (-prefix) (-selinux) -static-libs -tools" 0 KiB
[ebuild   R    ] net-misc/netifrc-0.2.2::gentoo  60 KiB
[ebuild   R    ] sys-fs/eudev-3.1.5::gentoo  USE="hwdb kmod -introspection -rule-generator (-selinux) -static-libs {-test}" 0 KiB
[ebuild     U  ] virtual/udev-217::gentoo [215::gentoo] USE="-systemd" 0 KiB
[ebuild     U  ] sys-fs/udev-init-scripts-32::gentoo [27::gentoo] 4 KiB
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 20048

PostPosted: Wed Sep 27, 2017 3:49 pm    Post subject: Reply with quote

Excellent. Thank you both.

I think I'll test it in a chroot. I'm not feeling particularly like fixing a mess if it were to somehow break.
_________________
Quis separabit? Quo animo?
Back to top
View user's profile Send private message
miket
Guru
Guru


Joined: 28 Apr 2007
Posts: 483
Location: Gainesville, FL, USA

PostPosted: Wed Sep 27, 2017 6:53 pm    Post subject: Reply with quote

Except for a recent build for testing in a virtual machine, I've never gone past version 0.17 of openrc. I saved the ebuild before it went away and still have the original tarball.

I've been doing something similar with eudev, sticking with 1.5.3-r1 because later versions want to have the kernel built with FHANDLE enabled. The feature always sounded to me like an exploit waiting to happen: a mechanism to pass open file handles among processes for the sake of systemd. There have already been a couple CVE's around the feature, but I'm waiting for some big one to hit the news. I'm wary of the name_to_handle_at() and open_by_handle_at() calls even though I don't run systemd.

The trouble I've run into now is that powerdevil has a consistent build failure with eudev 1.5.3-r1 and GCC 5. I tried a few ways around that but nothing has worked. So much for building KDE Plasma 5 with GCC 5, I thought. I went ahead to build KDE 5.10 using the latest Stage 3, thinking that I would be just as happy because KDE would surely still be too undercooked to use. What I got instead was cold satisfaction. Satisfaction because it seems that Plasma 5 is usable* at last, but cold because it won't work with my old eudev. (Let it be known that I did the build without downgrading either openrc or eudev from the Stage 3, but I don't think think the powerdevil-build problem came because of openrc.)

So I don't know that you can still use the old eudev, but the old openrc does seem to work OK.

---

* "usable" meaning that it wouldn't drive me nuts when using it on machines where I'm trying to do real work.
Back to top
View user's profile Send private message
Tony0945
Watchman
Watchman


Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA

PostPosted: Wed Sep 27, 2017 9:17 pm    Post subject: Reply with quote

miket wrote:
I've been doing something similar with eudev, sticking with 1.5.3-r1 because later versions want to have the kernel built with FHANDLE enabled. The feature always sounded to me like an exploit waiting to happen: a mechanism to pass open file handles among processes for the sake of systemd. There have already been a couple CVE's around the feature, but I'm waiting for some big one to hit the news. I'm wary of the name_to_handle_at() and open_by_handle_at() calls even though I don't run systemd.

Thanks for the definition of FHANDLE. I think I'll downgrade eudev on that machine because I only use it to name the two NIC's based on MAC address. (lan0 etc not those goofy "persistent" names that will change if you move the card to a different PCI slot anyway)
Back to top
View user's profile Send private message
Tony0945
Watchman
Watchman


Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA

PostPosted: Wed Sep 27, 2017 11:25 pm    Post subject: Reply with quote

I forgot that I added two patches to eudev-1.10 in order for it to work with later compilers.

files/eudev-fix-types.patch https://paste.pound-python.org/show/M4P7lpODVci5xuak7xfY/
and
files/eudev-fix-types2.patch https://paste.pound-python.org/show/gyR49HFw6Mnw17P5xOg1/

Just encountered this while downgrading eudev-3.5 on the 32-bit box (bug is in 64-bit too)

See this thread https://forums.gentoo.org/viewtopic-p-8010312.html?sid=9bd685d23cd2c63d11cc3943b7787d2c
EDIT:
corrected name of second patch


Last edited by Tony0945 on Thu Sep 28, 2017 7:56 am; edited 1 time in total
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6920

PostPosted: Thu Sep 28, 2017 2:53 am    Post subject: Reply with quote

miket wrote:
The feature always sounded to me like an exploit waiting to happen: a mechanism to pass open file handles among processes for the sake of systemd. There have already been a couple CVE's around the feature, but I'm waiting for some big one to hit the news. I'm wary of the name_to_handle_at() and open_by_handle_at() calls even though I don't run systemd.

Linux can already pass open filehandles between processes without that — read unix(7).
Back to top
View user's profile Send private message
miket
Guru
Guru


Joined: 28 Apr 2007
Posts: 483
Location: Gainesville, FL, USA

PostPosted: Thu Sep 28, 2017 3:33 am    Post subject: Reply with quote

Tony0945 wrote:
I think I'll downgrade eudev on that machine

There is something I have to point out on the FHANDLE front. I remember from some time ago that you had to enable FHANDLE in menuconfig if you wanted it. Now--on version 4.12.5 anyway--you don't even get the option. If you want to disable FHANDLE, you get into deeper aspects of kernel configuration than I had at first suspected.

The first assumption, I would suppose, is that you could simply change the line CONFIG_FHANDLE=y to
Code:
# CONFIG_FHANDLE is not set
to disable the feature. Ah, but what if the kernel could not deal with that setting by itself--what if something else had to be enabled or disabled along with the changing of the definition of CONFIG_FHANDLE? They do tell you not to edit the .config file manually, after all.

If you search for FHANDLE in menuconfig (by typing /FHANDLE), the search results say nothing about what enables the display of the prompt "Open by fhandle syscalls". The magic sauce is in init/Kconfig, which I found by grepping for "FHANDLE" in the Kconfig files. Here you find the line
Code:
bool "open by fhandle syscalls" if EXPERT


So there. To expose the prompt that controls FHANDLE, all you need to do is say Y to "Configure standard kernel features (expert users)". Problem solved? Not so fast. I read here in this forum a week or two ago about the bad experience that someone had when he enabled CONFIG_EXPERT. Lovely. How do you know what to change? A grep for "if EXPERT" gives 129 hits in vanilla linux-4.12, more than I really want to track down. For each one I'd need to see the default setting for the item in question.

It seems not to be so hard in reality. The only items that would be bothersome are the ones where changing the setting of EXPERT would change the default. The thing would be to enable EXPERT and then flip those 19 setting to what I would really want.

Here is the list of settings that get new defaults when enabling CONFIG_EXPERT in gentoo-sources. Every one of them defaults to Y in the default configuration but defaults to N when CONFIG_EXPERT is set.

  • DEBUG_MEMORY_INIT: "Debug memory initialisation"
  • HID_A4TECH: "A4 tech mice"
  • HID_APPLE: "Apple {i,Power,Mac}Books"
  • HID_BELKIN: "Belkin Flip KVM and Wireless keyboard"
  • HID_CHERRY: "Cherry Cymotion keyboard"
  • HID_CHICONY: "Chicony Tactical pad"
  • HID_CYPRESS: "Cypress mouse and barcode readers"
  • HID_EZKEY: "Ezkey BTC 8193 keyboard"
  • HID_KENSINGTON: "Kensington Slimblade Trackball"
  • HID_LOGITECH: "Logitech devices"
  • HID_MICROSOFT: "Microsoft non-fully HID-compliant devices"
  • HID_MONTEREY: "Monterey Genius KB29E keyboard"
  • HID_PICOLCD_FB: "Framebuffer support" (subitem of HID_PICOLCD)
  • HID_PICOLCD_BACKLIGHT: "Backlight control" (subitem of HID_PICOLCD)
  • HID_PICOLCD_CIR: "CIR via RC class" (subitem of HID_PICOLCD
  • HID_PICOLCD_LCD: "Contrast control" (subitem of HID_PICOLCD)
  • HID_PICOLCD_LEDS: "GPO via leds class" (subitem of HID_PICOLCD)
  • NAMESPACES: "Namespaces support"
  • RFKILL_INPUT: "RF switch input support"


Well! How much time do we spend disabling unneed device drivers when configuring a kernel? I don't know about you, but the next time I do it the first thing I'll do is select "Configure standard kernel features (expert users)"!

Be an expert.


As to your problem in compiling eudev with GCC 5, I had forgotten that I had run into the same thing with eudev-1.5.3-r1. I ended up figuring it out: found the error message in the emerge output, found what symbol was missing, found what header file supplies the symbol, made a patch in the overlay to alter the #include to make it load <stdint.h>. The next trick will be to make it play nicely with powerdevil.
Back to top
View user's profile Send private message
miket
Guru
Guru


Joined: 28 Apr 2007
Posts: 483
Location: Gainesville, FL, USA

PostPosted: Thu Sep 28, 2017 4:10 am    Post subject: Reply with quote

Ant P. wrote:
miket wrote:
The feature always sounded to me like an exploit waiting to happen: a mechanism to pass open file handles among processes for the sake of systemd. There have already been a couple CVE's around the feature, but I'm waiting for some big one to hit the news. I'm wary of the name_to_handle_at() and open_by_handle_at() calls even though I don't run systemd.

Linux can already pass open filehandles between processes without that — read unix(7).

Then why don't the systemd people use Unix sockets? The thing with the socket approach is that the open file handles get sent without delay. In the FHANDLE scheme, the process passing the open file handle "serializes" it by calling name_to_handle_at() to get an "opaque" blob that not only is subject to being hacked but also may be transmitted and reconstituted with so long a delay that the needed DENTRY ages out of the cache.

Using sendmsg(2) to transmit file handles using a socket is sane enough of a thing that a process needs no special privilege to do it. The FHANDLE function open_by_handle_at(), by contrast, has such a possibility for misuse that a process must have the CAP_DAC_READ_SEARCH capability to call it. Who knows what mischief an intruder might make by passing doctored "opaque" blobs to the unsuspecting privileged process?

There was already a mechanism that worked and worked pretty well. Why did they have to make a funky new one?
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 20048

PostPosted: Thu Sep 28, 2017 4:38 am    Post subject: Reply with quote

eudev-1.10-r2 is the only in tree version not requiring FHANDLE, so I guess my choice is made there.


Tony0945 wrote:
I forgot that I added two patches to eudev-1.10 in order for it to work with later compilers.

files/eudev-fix-types.patch https://paste.pound-python.org/show/M4P7lpODVci5xuak7xfY/
and
files/eudev-fix-types.patch https://paste.pound-python.org/show/gyR49HFw6Mnw17P5xOg1/

Just encountered this while downgrading eudev-3.5 on the 32-bit box (bug is in 64-bit too)

See this thread https://forums.gentoo.org/viewtopic-p-8010312.html?sid=9bd685d23cd2c63d11cc3943b7787d2c
Is only one of those patches used at a time? They have the same name (eudev-fix-types.patch)?
_________________
Quis separabit? Quo animo?
Back to top
View user's profile Send private message
Tony0945
Watchman
Watchman


Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA

PostPosted: Thu Sep 28, 2017 7:59 am    Post subject: Reply with quote

pjp wrote:
Is only one of those patches used at a time? They have the same name (eudev-fix-types.patch)?


My connection is flaky and often keystrokes are lost. I've corrected the second name in the original post.

The second one is named files/eudev-fix-types2.patch

Sorry.
Back to top
View user's profile Send private message
miket
Guru
Guru


Joined: 28 Apr 2007
Posts: 483
Location: Gainesville, FL, USA

PostPosted: Thu Sep 28, 2017 1:29 pm    Post subject: Reply with quote

pjp wrote:
eudev-1.10-r2 is the only in tree version not requiring FHANDLE, so I guess my choice is made there.

Really? From eudev-1.10-r2.ebuild:
Code:
pkg_setup() {
        CONFIG_CHECK="~BLK_DEV_BSG ~DEVTMPFS ~!IDE ~INOTIFY_USER ~!SYSFS_DEPRECATED ~!SYSFS_DEPRECATED_V2 ~SIGNALFD ~EPOLL ~FHANDLE ~NET ~UNIX"

Contrast with the setting of CONFIG_CHECK in the pkg_setup function in eudev-1.5.3-r1.ebuild:
Code:
CONFIG_CHECK="~BLK_DEV_BSG ~DEVTMPFS ~!IDE ~INOTIFY_USER ~SIGNALFD ~!SYSFS_DEPRECATED ~!SYSFS_DEPRECATED_V2"
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 20048

PostPosted: Thu Sep 28, 2017 3:17 pm    Post subject: Reply with quote

I may have worded that poorly, but 1.5.3 is not in the tree (at least not mine).

Does ~ not mean unstable in the CONFIG_CHECK context?

miket wrote:
I've been doing something similar with eudev, sticking with 1.5.3-r1 because later versions want to have the kernel built with FHANDLE enabled.
I interpreted that to mean that at least as far as you knew, <1.5.3 didn't require it, so when I checked my tree, only 1.10-r2 seemed to qualify.
_________________
Quis separabit? Quo animo?
Back to top
View user's profile Send private message
miket
Guru
Guru


Joined: 28 Apr 2007
Posts: 483
Location: Gainesville, FL, USA

PostPosted: Thu Sep 28, 2017 5:49 pm    Post subject: Reply with quote

Wow, finding the information on CONFIG_CHECK took a little while.

pjp wrote:
I may have worded that poorly, but 1.5.3 is not in the tree (at least not mine).


1.5.3 hasn't been in the tree for a long time. When there was first an upgrade for it, the FHANDLE requirement glared at me from the elog. I looked a bit into FHANDLE and to the eudev ebuilds that wanted it. I saw that everything past 1.5.3-r1 wanted FHANDLE, so right away I masked everything past that version. It was still in the tree then.

pjp wrote:
Does ~ not mean unstable in the CONFIG_CHECK context?


No, according to https://devmanual.gentoo.org/eclass-reference/linux-info.eclass/index.html, the tilde prefix means to display a warning rather than cause a fatal error.

pjp wrote:
miket wrote:
I've been doing something similar with eudev, sticking with 1.5.3-r1 because later versions want to have the kernel built with FHANDLE enabled.
I interpreted that to mean that at least as far as you knew, <1.5.3 didn't require it, so when I checked my tree, only 1.10-r2 seemed to qualify.

I don't know what further evil followed 1.10-r2 for it still to be stable today, but I never got far enough to try it.
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6920

PostPosted: Thu Sep 28, 2017 6:16 pm    Post subject: Reply with quote

miket wrote:
There was already a mechanism that worked and worked pretty well. Why did they have to make a funky new one?

To add an unnecessary Linux-specific dependency, obviously. What's that one phrase... "Redhat ain't done till BSD don't run" ;-)
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6095
Location: Dallas area

PostPosted: Fri Sep 29, 2017 9:58 am    Post subject: Reply with quote

I wouldn't worry too much about FHANDLE

Quote:
# CONFIG_FHANDLE was introduced by 2.6.39
local MINKV=2.6.39

_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 20048

PostPosted: Fri Oct 13, 2017 9:09 pm    Post subject: Reply with quote

openrc-0.32.1 recently became "stable."

Haven't yet had a chance to try downgrading from 0.28.
_________________
Quis separabit? Quo animo?
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Goto page Previous  1, 2, 3, 4  Next
Page 3 of 4

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum