Summary: | sys-libs/glibc-2.26 makes NIS systems unusable | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | peteru <bugs.gentoo.org> |
Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | critical | CC: | floppym |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://github.com/gentoo/gentoo/pull/6214 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 628768 |
Description
peteru
2017-11-17 17:00:44 UTC
You will probably have to use a third party package, like this one: https://github.com/thkukuk/libnss_nis Which is not in portage. The problem is that this change makes systems unusable without notice and without a clear path forward. I appreciate that the removal of NIS from glibc is an upstream change, but distributions need to have some form of strategy for rolling out a change that can leave users locked out of the system. At a minimum, there should be a news item about this, giving plenty of warning and ideally suggest the required packages that should be in portage. At this stage the only reasonable option for my systems is to do an emergency roll-back of glibc. In the long term, I need to figure out whether Gentoo will maintain NIS support or whether it will be finally killed off. It would be a shame, but it looks like NIS has no maintainers - see ypbind and friends. :-( I strongly suggest changing the glibc package to do a pre-merge check to check if a system is configured to use NIS maps. (In reply to peteru from comment #2) > Which is not in portage. > > The problem is that this change makes systems unusable without notice and > without a clear path forward. And that's why you don't run unsupervised ~arch on production systems. > At a minimum, there should be a news item about this, giving plenty of > warning and ideally suggest the required packages that should be in portage. Given that you're the first one to even notice or complain... > > At this stage the only reasonable option for my systems is to do an > emergency roll-back of glibc. In the long term, I need to figure out whether > Gentoo will maintain NIS support or whether it will be finally killed off. > It would be a shame, but it looks like NIS has no maintainers - see ypbind > and friends. :-( It will be maintained. > I strongly suggest changing the glibc package to do a pre-merge check to > check if a system is configured to use NIS maps. It's only two systems that are affected. The production systems are not ~arch, so they are safe for now. I've already pushed out a package.mask for glibc-2.26 until I have a better idea how to move forward. However, I am now stuck with this problem: * Sanity check to keep you from breaking your system: * Downgrading glibc is not supported and a sure way to destruction * ERROR: sys-libs/glibc-2.25-r9::gentoo failed (pretend phase): * aborting to save your system Any suggestions on how to proceed? (In reply to peteru from comment #4) > Any suggestions on how to proceed? You can comment out the relevant "die" command in toolchain-glibc.eclass to enable the downgrade. Not that if you have rebuild any other critical system packages since upgrading to glibc-2.26, downgrading may very likely make the system completely unusable. In that case, you would need to reinstall from a stable stage3 tarball, or reinstall those system packages from binpkgs built against glibc-2.25. peteru, you could try glibc 2.26 configure option "--enable-obsolete-nsl". Please note that this is only a workaround. See release notes at: https://savannah.gnu.org/forum/forum.php?forum_id=8921 The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7cf52c674ca56d22b039982de815439c0d102bf2 commit 7cf52c674ca56d22b039982de815439c0d102bf2 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2017-11-17 19:13:26 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2017-11-17 23:20:43 +0000 sys-auth/libnss-nis: new package (Note added- I've made it install into /usr for the moment. dilfridge) Bug: https://bugs.gentoo.org/637946 Closes: https://github.com/gentoo/gentoo/pull/6214 Package-Manager: Portage-2.3.14_p5, Repoman-2.3.6 sys-auth/libnss-nis/Manifest | 1 + sys-auth/libnss-nis/files/map_v4v6_address.patch | 112 +++++++++++++++++++++++ sys-auth/libnss-nis/libnss-nis-1.3.ebuild | 49 ++++++++++ sys-auth/libnss-nis/metadata.xml | 7 ++ 4 files changed, 169 insertions(+)} @peteru, with sys-auth/libnss-nis, is your system working again? Great work! Adding sys-auth/libnss-nis to the system brings back the NIS functionality. I guess glibc should pull sys-auth/libnss-nis in as a dependency when the "nis" USE flag is set. That ought to prevent breakage, on systems that use NIS. Thanks for the fix. Saved me from rolling back glibc. ;-) The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=468d6930bad211f5744c1e41d99c496923bae677 commit 468d6930bad211f5744c1e41d99c496923bae677 Author: Andreas K. Hüttel <dilfridge@gentoo.org> AuthorDate: 2017-11-18 18:34:12 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2017-11-18 18:34:30 +0000 sys-libs/glibc: Output fat warning if NIS is used and sys-auth/libnss-nis is not installed Closes: https://bugs.gentoo.org/637946 Package-Manager: Portage-2.3.14, Repoman-2.3.6 sys-libs/glibc/glibc-2.26-r3.ebuild | 15 +++++++++++++++ sys-libs/glibc/glibc-9999.ebuild | 15 +++++++++++++++ 2 files changed, 30 insertions(+) |