The at present (11-Aug-2006 23:54 EDT) latest stable baselayout breaks yp based systems, due to a flaw: /etc/init.d/domainname no longer exists The dnsdomainname is now set in /etc/init.d/net.lo, but that doesn't help NIS systems who need NISDOMAIN from /etc/conf.d/domainname set. This prevents ypbind from running, which causes automount to fail, and the systems do not come up. Problem seen on two systems: System 1: selinux/2005.1/x86 System 2: default-linux/amd64/2006.0 emerge --info from system 1: Portage 2.1-r2 (selinux/2005.1/x86, gcc-3.4.6, glibc-2.3.6-r4, 2.6.17-gentoo-r4 i686) ================================================================= System uname: 2.6.17-gentoo-r4 i686 Intel(R) Pentium(R) 4 CPU 2.53GHz Gentoo Base System version 1.6.15 ccache version 2.3 [enabled] app-admin/eselect-compiler: [Not Present] dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.3 dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -pipe -march=pentium4 -momit-leaf-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb /var/bind" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/splash /etc/terminfo" CXXFLAGS="-O2 -pipe -march=pentium4 -momit-leaf-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks fixpackages metadata-transfer sandbox selinux sfperms strict" GENTOO_MIRRORS="http://open-systems.ufl.edu/mirrors/gentoo http://prometheus.cs.wmich.edu/gentoo http://distro.ibiblio.org/pub/linux/distributions/gentoo/" LDFLAGS="-Wl,-O1" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" USE="X acpi alsa apache2 berkdb caps crypt cups dri eds fam gdbm gif gnome gstreamer gtk idn ipv6 jpeg logrotate mad mbox mikmod mmap mmx motif ncurses nfs nis nls nptl offensive pam pcre perl pic png posix python qt4 readline sdl selinux spell spl sse sse2 ssl tcpd threads truetype vorbis x86 xml xv zlib elibc_glibc input_devices_keyboard input_devices_mouse kernel_linux userland_GNU video_cards_radeon video_cards_vesa"
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.
