ntpd from openntpd simply terminates on startup attempt when acct-user/ntp sets HOME for ntp user to /dev/null. openntpd ebuilds expect HOME to be /var/lib/openntpd/chroot
It should probably use a different user account to avoid conflicts with net-misc/ntp.
Didn't Michael mentioned that case in his "[gentoo-dev] RFC: GLEP81 home directory guidelines" mail?
Yeah, the openntpd ebuild sets NTP_HOME="${NTP_HOME:=/var/lib/openntpd/chroot}" and then relies on that path existing: econf \ --with-privsep-user=ntp \ --with-privsep-path=${NTP_HOME} ... I have a feeling it doesn't care about the home directory at all, but I'm on my way out the door and don't have time to check. Instead, the openntpd ebuild should probably be doing keepdir /var/lib/openntpd/chroot with the appropriate permissions and ownership in diropts. If the package needs a path, it shouldn't count on the acct-user package coincidentally creating it as ACCT_USER_HOME. If that works, no separate account is needed.
Nevermind, the INSTALL file says, --with-privsep-path=path ntpd will always use the home directory of the privsep user to chroot to, but specifying this parameter will change the post-installation checks and instructions to match the specified path. Unless there's a good reason to try to share the same user between the two daemons, a separate user is probably the way to go. Gotta run for real now,
I've noticed the discussion of the new user/group handling mechanism on the dev list, but I think it's above my proxy-maintainer pay grade :). Let me know what you want me to change to resolve this, or feel free to update the user/group handling stuff to your satisfaction directly. Thanks...
Understood Paul =) I think the best solution here is to switch the openntpd username and group from "ntp" to "openntpd". This conflict already existed -- the net-misc/ntp ebuilds have always created the "ntp" user with home directory set to /dev/null. And net-misc/openntpd has always fought about it: pkg_setup() { ... # make sure user has correct HOME ... esethome ntp "${NTP_HOME}" ... } Before GLEP81, this happened to work, because the "enewuser" command run by net-misc/ntp would *not* switch the home directory back to what it originally was (/dev/null). The new acct-user packages do, so the "ntp" user's home directory will occasionally be reset to /dev/null, and that of course breaks openntpd. The fact that it *really* doesn't work now just highlights the fact that maybe we shouldn't have tried to share the same user for two different packages in the first place. It was never great to have the home directory for the net-misc/ntp daemon's user set to /var/lib/openntpd/chroot, for example. So, tl;dr, do what Mike said and use "openntpd" as your user/group from now on. This will require some tweaks to the ebuild, but will also allow you to drop the esethome hack used above. With two separate users for two separate daemons, there's no need to fight over a home directory.
Ok. Should I just update the ebuild as is with the new user/group, or do I need to switch to using the new design that depends on separate acct-user/openntpd and acct-group/openntpd ebuilds to create the user/group? Right now the uid/gid are random, not statically set.
(In reply to Paul B. Henson from comment #7) > Ok. Should I just update the ebuild as is with the new user/group, or do I > need to switch to using the new design You can switch the username first and then migrate to the new GLEP81 user-packages later if that's easier.
(In reply to Michael Orlitzky from comment #8) > (In reply to Paul B. Henson from comment #7) > > Ok. Should I just update the ebuild as is with the new user/group, or do I > > need to switch to using the new design > > You can switch the username first and then migrate to the new GLEP81 > user-packages later if that's easier. However, please request fixed UID/GID and make sure to include it in enewuser/enewgroup calls to save users from having to update later on.
What's the process for getting a reserved fixed uid/gid? I posted on the dev list but nobody responded.
(In reply to Paul B. Henson from comment #10) > What's the process for getting a reserved fixed uid/gid? I posted on the dev > list but nobody responded. Practically, it's best to pick one and then post to the list asking if anyone sees a problem with your choice. That way, if no one responds, you can assume that it's OK to proceed. Since ntp has taken uid/gid 123, might I suggest uid/gid 321 for openntpd? Neither Fedora nor Arch has already assigned that uid/gid, and neither of them have an "openntpd" user or group with another ID, so I don't see any immediate problems with it.
Ok, here's a pull request: https://github.com/gentoo/gentoo/pull/13051 Let me know if anything else needs fixing. Is there a particular timeline desired for migrating ebuilds to the new user/group depends mechanism?
(In reply to Paul B. Henson from comment #12) > > Is there a particular timeline desired for migrating ebuilds to the new > user/group depends mechanism? The new way is a lot better, so "as soon as possible," but we'll be migrating for years so there's no need to stress about it.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e499d09c6711bad8dfaba4b1640e1a2be6f78057 commit e499d09c6711bad8dfaba4b1640e1a2be6f78057 Author: Paul B. Henson <henson@acm.org> AuthorDate: 2019-11-26 05:03:46 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2019-12-08 10:08:15 +0000 net-misc/openntpd: EAPI=7, Use GLEP 81 for user/group instead of user eclass Bug: https://bugs.gentoo.org/693050 Signed-off-by: Paul B. Henson <henson@acm.org> Closes: https://github.com/gentoo/gentoo/pull/13763 Signed-off-by: Joonas Niilola <juippis@gentoo.org> net-misc/openntpd/openntpd-6.2_p3-r1.ebuild | 66 +++++++++++++++++++++++++++++ 1 file changed, 66 insertions(+)
