PAM, glibc 2.14, and NIS

After my list of issues related to glibc-2.14, the situation is somewhat more manageable: Mike fixed his own mistakes in the build of libtirpc, which now builds a working library, but on the other hand resolved to use a dirty hack to install the old NIS/YP header files, which are need by both libtirpc and other packages. Dirty or not, this at least produces some reasonable expectations of a working starting point.

I won’t even quote Mike’s suggestion for how to add support for libtirpc since that’s going to cause huge trouble with non-Linux platforms, given that for instances FreeBSD has a working RPC implementation (which, as far as I can tell, supports iPv6) in its C library itself. This means that what you should have in the ebuild, is probably something along these lines:

IUSE="elibc_glibc"

RDEPEND="elibc_glibc? ( || ( net-libs/libtirpc 

The option of creating a virtual package for this is sweet, but unfortunately, supporting libtirpc requires the buildsystem to identify it properly. it takes a bit of work on making it possible to build against that implementation in most cases, so simply adding the virtual is unlikely to be of help.

With enough support to actually fix the packages, tonight I looked into PAM, which I knew would become troublesome, since I already tried removing NIS support from it a few years ago; at the time I was unable to follow through with upstream because it was still the time I was getting in and out of hospitals.

At the time I had a patch that allowed building if NIS was unavailable, but it didn’t make it possible to disable NIS when available; this is instead implemented now in version 1.1.3-r1, with the nis USE flag, which I suggest to keep disabled (it is disabled by default). When actually enabling it, it’ll require either libtirpc (preferred) or an old glibc version.

Since NIS/YP is a virtually dead technology, it shouldn’t surprise that the default is now to keep it disabled, it’s not just a matter of requiring an extra dependency; I doubt anybody is using that stuff on any modern system; definitely not on users’ desktops or servers, which would be probably happy to drop a bunch of code that was left unused.

For those who wonder how much code are we talking about, comparing the before and after of the pam_unix module, which is the main consumer of the NIS/YP interfaces, it shows the total size decreasing of about 3KiB, one of which is purely part of the executable code, while the rest is distributed across data and rodata sections (which seem to mostly relate to string literals), and the overhead (imported symbol and string tables). Might not sound like a lot, especially on a module with about 50KiB of copy-on-write bss section, but it’s still something you gain by simply removing unused code, without even the need to optimize anything.

7 thoughts on “PAM, glibc 2.14, and NIS

  1. My networking school still uses NIS (with /home on a NFS export with root_no_squash).Old legacy system will be around for a long time…

    Like

  2. My school still use NIS (and a NFSv2 export for /home with no_root_squash).Legacy system will be around for a long time …

    Like

  3. I recently had the interesting opportunity of helping someone attempt to get a Fedora 15 system (using systemd) to join an NIS domain with automounted NFS home directories… To discover that it was broken, due to incorrect dependencies in the init scripts causing ypbind to start before autofs. A trivial fix (remove some ‘$’ signs from the LSB init script headers), but it would be really nice if these things would actually get tested before they trickle down to the corporations that still use NIS.Where I work? Got around 50 multi-user servers, mixed SPARC/Solaris10 and Intel/Linux (RHEL 5.5), most using NIS and NFS automounts. We plan to start deploying Linux to desktops soon… And will probably continue to use NIS there. If it still works.

    Like

  4. Oops, I mean that it was incorrectly starting autofs before ypbind. Why didn’t I catch that before hitting “Submit” :)

    Like

  5. Not too long ago I had the (un)pleasant experience of working with a network still using token ring. And rebooting a server with a floppy that loaded the dos drivers to access the network.I daresay they are still using it.

    Like

  6. I still run a system of 5 or 6 systems at home with an NFS server for all the files and NIS to link it together. I hope we don’t loose NIS support anytime soon.Thanks for your good explanations and all your hard work.

    Like

  7. We still have a ton of NIS installations on-site (at least 3-4) and on all of our customer’s sites.It’s… unfortunate, really.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s