Hi, on a NIS client, deluser tries to delete entries that are stored on the NIS server, for instance: # deluser attali Removing user attali... userdel: error deleting password entry userdel: error deleting shadow password entry done. What's worse, adduser refuses to create a user with the same login as another user stored on the NIS server. This prevents installing a package that creates users both on the NIS server and client. One such example is snort. I hesitate to submit RC bugs to frozen base packages, but as it prevents another package from installing, this would qualify as "critical" (makes unrelated software on the system break).
In article <E15c1x4-0002Wm-00@irancy.lis.inpg.fr>, laurent bonnaud <Laurent.Bonnaud@inpg.fr> wrote: Hmm. I seem to recall that every time adduser is updated it has problems on systems running NIS. Perhaps the debian/rules build process should print out 'if you changed any of the code make sure it still works on a NIS system!' Mike.
laurent bonnaud wrote: There is not much I can do about it though. Adduser uses the shadow tools to do its work, and they refuse to add users to passwd if a user with the specified name does already exists. Similar for removing users. On my system, the user bar is in LDAP. So it's a similar situation: roland@newton:~% id bar uid=1009(bar) gid=100 groups=100 roland@newton:~% grep bar /etc/passwd roland@newton:~% sudo useradd bar useradd: user bar exists roland@newton:~% sudo userdel bar userdel: error deleting password entry userdel: error deleting shadow password entry roland@newton:~% id bar uid=1009(bar) gid=100 groups=100 roland@newton:~% Roland
Miquel van Smoorenburg wrote: Not really. Adduser used to care not at all about NIS. Recently I added some code to call make -C /var/yp which of course failed on NIS clients, but should be fixed for quite some time now. Actually, the core stuff didn't change at all for a long time. Roland
Roland> Roland> There is not much I can do about it though. Adduser uses the Roland> shadow tools to do its work, and they refuse to add users to Roland> passwd if a user with the specified name does already Roland> exists. Similar for removing users. Could you then reassign this bug to package passwd ?
According to Roland Bauerschmidt: Well what has happened before is that adduser started to add new entries _after_ the +:::::: marker that makes NIS entries magically appear. And those entries were never processed by getpwnam() and friends. At least that bug has surfaced several times, and was fixed several times. That's probably a good idea if the machine is both a NIS server and a client. I didn't mean to insult anyone, I merely stated some facts. It appears that you are very much aware of the interaction with NIS - I appreciate that. Mike.
Hi, I was about to file a new bug, then saw these two. (Can they perhaps be merged?) My symptom: if I "adduser xyzpdq" on an NIS server, but give mismatched passwords, then subsequent "adduser xyzpdq" attempts fail outright. The problem is that NIS still has xyzpdq in /var/yp/<domain>/passwd.byname, group.byname and passwd.byuid. So adduser needs to do a "cd /var/yp && make" if the passwords don't match, or even if they do match, according to 143432. If this is added, I think both bugs can be closed. (These are pretty old bugs...) Maintainer: would you accept a patch which does this? Zeen,
Hi, I was about to file a new bug, then saw these two. (Can they perhaps be merged?) My symptom: if I "adduser xyzpdq" on an NIS server, but give mismatched passwords, then subsequent "adduser xyzpdq" attempts fail outright. The problem is that NIS still has xyzpdq in /var/yp/<domain>/passwd.byname, group.byname and passwd.byuid. So adduser needs to do a "cd /var/yp && make" if the passwords don't match, or even if they do match, according to 143432. If this is added, I think both bugs can be closed. (These are pretty old bugs...) Maintainer: would you accept a patch which does this? Zeen,
Isn't this the job of the shadow tools that are used by adduser to do the grunt work? How will your patch behave on a non-NIS system? Greetings Marc
Is it still necessary to reassign this bug? Greetings Marc
Isn't this the job of the shadow tools that are used by adduser to do the grunt work? How will your patch behave on a non-NIS system? Greetings Marc
Is it still necessary to reassign this bug? Greetings Marc
I don't known but probably because the same problem exists in utils from package passwd: # userdel attali userdel: error deleting password entry userdel: error deleting shadow password entry # useradd attali useradd: user attali exists There are 3 possibilities to fix this problem: - change adduser to not use useradd and the info in /etc/nsswitch.conf. It would ignore NIS/LDAP stuff and only touch local files. - fix the passwd package (to display an error message about the account being a network account) or add an option to ignore NSS stuff. - fix all Debian packages that create users to create them with an UID below 1000. BTW, my initial problem with snort is fixed since snort now uses an UID below 1000 that is not exported by the NIS server.
vanish as well. Cc: ing passwd maintainers - can you please verify if this is your bug? That's a bad idea. adduser is a high level interface, and fixing the low-level tools (if they're indeed buggy) will implicitly fix adduser as well. That sounds to me as a valid solution. Debian packages that create system accounts without --system are buggy and should have bugs filed on the. But there might be valid reasons for Debian packages to create non-system accounts. So this will probably not solve our problem here. Greetings Marc