reassign 347545 glibc thanks On Wed, Jan 11, 2006 at 01:57:27PM +0100, Edward Welbourne wrote: > When root tried to su - eddy it got this response on stderr: > -su: nss_nis/nis-netgrp.c:79: _nss_nis_setnetgrent: Assertion `malloc_usable_size (netgrp->data) >= len + 1' failed. This is a problem with an NSS module which is part of glibc rather than with the NIS package. On client systems the NIS package just maintains the binding to the server and provides utility programs like ypcat. No code from the package actually runs in a process doing database lookups or authentication through the glibc APIs. Reassigning the bug to glibc which provides the NSS module. I'll try to address the other issues you have raised here but there's quite a few of them. If you would like any of these issues addressing further please file appropriate low severity bugs against the NIS package. I'd especially welcome improvements to the documentation. > The debconf info (which used to contain the nis/domain datum discussed > above) says nis is "not yet configured". Since I've uninstalled nis Actually, no, it doesn't say that. It reports that there is a Debconf note called nis/not-yet-configured - there will always be some reference to that note in the template generated by reportbug for NIS (the presence or absence of a '*' indicates if it's been shown or not). > and re-installed it recently, I can only suppose this is due to the > installation scripts not configuring nis. Getting to the point above > had involved a great deal of guess-work, reading of man pages, > stumbling by chance on relevant files and filling those with data by > trial and error. Nothing made itself even remotely obvious as a "how > to tell nis to configure itself", even in the course of all that > rummaging. Given the above I'm guessing that this is based on your understanding of what the Debconf information displayed by reportbug means. I would therefore expect that you had in fact already configured NIS fully and that the reason you were unable to find any documentation on what you were missing was that you weren't missing anything. > Running dpkg-reconfigure, I get consulted for the > nis/domain value; it already knows the value I had configured it to by > hand; and I think this was run when I re-installed nis. Yes, NIS will prompt for that when installed. Each time it is configured it will also take any value configured on the system and use it to seed the Debconf question. > (The prompt > for this is, fundamentally, unhelpful: only when I'd got it wrong, and > rummaged a lot as above, did I discover a passing comment, probably in > a man page: from which I realized that it isn't a domain name in the > normal sense; and gleaned that the datum is stored in Right, unfortunately someone decided to use the same term for the two concepts. Fortunately most installations I've encountered use the same value for both DNS and NIS domains so it's actually not frequently a problem in practice. > It would be worth saying "look in your NIS server's > /etc/defaultdomain for the authoritative version of this variable" or > some such.) Saying things like that gets a bit tricky: for example the user may not have sufficient access to their NIS server to be able to go and look at files like that or their NIS server may use some completely different configuration mechanism. I can't off-hand think of much to do with that prompt beyond reinforcing the idea that you should consult whoever is admining the network about the value if you're not picking the name on the server yourself. I'll see if I can come up with something better next time I upload. > I didn't get consulted for the ypserver's IP address, nor The default installation relies on broadcasting to discover a suitable server; in most situations that will work fine. I'm not going to add support for configuring this without also providing support for adding compat entries to passwd and whatnot since it's not already supported and it's something that relatively few users will need. > was I asked whether I wanted to enable nis in passwd and group. The package doesn't do that automatically because editing /etc/passwd and /etc/group during configuration is rather nasty and is not supported by base-passwd which is what manages those files. There is a bug open against base-passwd (#311531) requesting support for adding NIS entries but, well, it's open. Doing this is much more tricky than it might at first appear since the package has to deal with combinations of install, upgrade, removal and configuration operations along with user changes to the system (which we have to respect above anything else). Other distributions that I've seen deal with this do so by having a separate program that manages all authentication and system database related stuff through a unified interface rather than by having the packages deal with it themselves. > Until the package's installation scripts ask those questions and sort > out the correct magic in /etc/*, this package is not ready for normal > mortals to use: crucial information is only available by asking > someone who already knows, or by insane amounts of effort, persistence > and lucky guess-work. But I digress. You should find that the set of instructions which is provided /usr/share/doc/nis/nis.debian.howto.gz is sufficient to configure most systems - if you have found any major omissions in there please do let me know. Users do get explicitly referred to that document when they first install the package although they aren't prompted during a dpkg-reconfigure run. -- "You grabbed my hand and we fell into it, like a daydream - or a fever."
Attachment:
signature.asc
Description: Digital signature