Summary: | baselayout 1.11.15-r3 breaks yp (NIS) systems | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Arthur Hagen <art-gt> |
Component: | [OLD] baselayout | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED DUPLICATE | ||
Severity: | critical | ||
Priority: | High | ||
Version: | 2006.0 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Arthur Hagen
2006-08-11 21:13:05 UTC
Note: Please do NOT mark this as a duplicate of bug # 129451 without updating/reassigning that bug. Reason: That ypbind now provides /etc/init.d/domainname doesn't help, since baselayout unconditionally and forcibly removes it: # tail -8 /usr/portage/sys-apps/baselayout/baselayout-1.12.4-r2.ebuild if [[ -e "${ROOT}"/etc/init.d/domainname ]] ; then rm -f "${ROOT}"/etc/init.d/domainname rm -f "${ROOT}"/etc/runlevels/*/domainname ewarn "The domainname init script has been removed in this vers on." ewarn "Consult ${ROOT}/etc/conf.d/net.example for details about how" ewarn "to apply dns/nis information to the loopback interface." fi } Furthermore, on selinux where the latest stable is 1.11.15-r3, it's even worse: # touch /etc/init.d/domainname # equery belongs /etc/init.d/domainname [ Searching for file(s) /etc/init.d/domainname in *... ] sys-apps/baselayout-1.11.15-r3 (/etc/init.d/domainname) In other words, the latest stable version provides the file, and deletes it. If baselayout unconditionally removes files created by ypbind, this makes this a baselayout problem, not an ypbind problem. Hard removing files from /etc/init.d is against gentoo conventions anyhow -- that's why there's cfgpro (In reply to comment #1) > That ypbind now provides /etc/init.d/domainname doesn't help, since baselayout > unconditionally and forcibly removes it: Yes, that's intentional. And the script is no-op, doesn't work, isn't honored, only produces error -> it's being removed by baselayout so that people don't report invalid bugs about it b/c of CONFIG_PROTECT. Nothing should depend on domainname init script -> not a baselayout bug. *** This bug has been marked as a duplicate of 129451 ***
>
> Yes, that's intentional. And the script is no-op, doesn't work, isn't honored,
> only produces error -> it's being removed by baselayout so that people don't
> report invalid bugs about it b/c of CONFIG_PROTECT.
If that's the case, please tell me how to get the nis domain name from a DHCP server using the stable version of baselayout. (No, setting nis_domain_{interface} in /etc/conf.d/net doesn't work, cause that overrides the value from dhcp)
The only solution I've found is to revert to an earlier baselayout *and* use /etc/init.d/domainname with NISDOMAIN="" in /etc/conf.d/domainname
As long as baselayout has just been marked stable, and breaks something as fundamental as nis, I'd call it a baselayout problem. NIS isn't just a small optional package that can be updated later at leisure -- it prevents whole systems from working, and should BLOCK baselayout from being marked stable until this has been resolved, whether it's resolved in baselayout or in ypbind.
Please reconsider. This isn't about placing blame, but about getting this quite real and severe problem fixed ASAP. Closing tickets where there's a known problem because doesn't achieve that.
(In reply to comment #3) > (No, setting > nis_domain_{interface} in /etc/conf.d/net doesn't work, cause that overrides > the value from dhcp) > The only solution I've found is to revert to an earlier baselayout *and* use > /etc/init.d/domainname with NISDOMAIN="" in /etc/conf.d/domainname Why are you setting such thing if you want to receive the settings from DHCP server? And how would domainname initscript that doesn't set anything NIS related solve this? It doesn't even do anything, read the domainname initscript, it doesn't run the NIS stuff if the NISDOMAIN variable is empty. Really, please read /etc/conf.d/net.example, fix your configuration, re-emerge the yp stuff so that you get fixed init scripts, and move on. (In reply to comment #4) > (In reply to comment #3) > > The only solution I've found is to revert to an earlier baselayout *and* use > > /etc/init.d/domainname with NISDOMAIN="" in /etc/conf.d/domainname > > Why are you setting such thing if you want to receive the settings from DHCP > server? Because the version of ypbind that *works* with dhcp requires /etc/init.d/domainname. > And how would domainname initscript that doesn't set anything NIS > related solve this? By allowing the version of ypbind that *works* with dhcp to run. It doesn't even do anything, read the domainname > initscript, it doesn't run the NIS stuff if the NISDOMAIN variable is empty. > > Really, please read /etc/conf.d/net.example, fix your configuration, > re-emerge the yp stuff so that you get fixed init scripts, and move on. I did re-emerge ypbind -- unfortunately, because I now can't revert. I'd love to fix my configuration move on, but I am apparently VERY stupid, because I can't figure out any way at all to use the nis-domain/nis-server as returned by the dhcp server with the latest baselayout and ypbind. If you know how, adding a note here would be very welcome. There's nothing in net.example on this -- only how to do a static setup, and a "nonis" option to dhcp_{interface} (which appears to be a no-op, since it doesn't use what's returned anyow -- a bug?). Any help would be much appreciated -- I'd love to get my systems back working like they were yesterday, and reading /etc/init.d/net.example doesn't solve that. |