The 50-udev.rules file contains this rule: KERNEL=="tpm*", NAME="%k", OWNER="tss", GROUP="tss", MODE="0600" This causes a nss lookup of 'tss' in the passwd data, and 'tss' in the group data. In the case that nsswitch.conf contains: group: files ldap passwd: files ldap (or 'compat' instead of 'files') an ldap lookup is attempted for each item. nss_ldap defaults to an indefinate search timeout, and each lookup is performed multiple times. Even if you change the search timeout, you must still wait for it to be performed multiple times (at least 4, but I lost count). This should be resolved by making sure that EVERY user and group mentioned in the 50-udev.rules file is in the base system /etc/passwd and /etc/group. Reproducible: Always Steps to Reproduce: 1. emerge udev nss_ldap 2. configure nss_ldap in nsswitch.conf and ldap.conf 3. reboot Actual Results: machine hangs when running udevstart, waiting infinitely for nss_ldap to return the data for the 'tss' user and group. Expected Results: should boot properly. Portage 2.0.51.22-r1 (default-linux/x86/2005.0, gcc-3.4.3, glibc-2.3.5-r0, 2.6.12-gentoo-r5 i686) ================================================================= System uname: 2.6.12-gentoo-r5 i686 AMD Athlon(tm) Processor Gentoo Base System version 1.6.13 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.3.5, 2.4.1-r1 sys-apps/sandbox: 1.2.11 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 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=i686 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=i686 -fomit-frame-pointer" DISTDIR="/mnt/distfiles" FEATURES="autoconfig ccache distlocks fixpackages sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://mirror.iat.sfu.ca/gentoo-portage" USE="x86 # 3dnow X a a52 aac aalib alsa apm audio avi bitmap-fonts cdr codecs crypt cups dbus divx4linux eds emboss encode faad fam flac foomaticdb gdbm gif gnome gpm gstreamer gtk gtk2 hal i'm imagemagick imlib ipv6 java jpeg junit ldap libg++ libwww matroska mikmod mmx mono mozilla moznocompose moznoirc moznomail mp3 mpeg ncurses nls not nptl nptlonly nvidia ogg oggvorbis opengl oss pam pdflib perl png ppds python qt quicktime readline sdl server slang snmp spell sqlite ssl svga tcpd truetype truetype-fonts type1-fonts usb v4l v4l2 vorbis win32codecs wxwindows xine xinerama xml xml2 xmms xv xvid zeroconf zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
how exactly is that a fix ? if your system doesnt use /etc/{passwd,group} for authentication, then why should udev ? and really, why should udev care beyond the API that the libc presents it ?
/etc/passwd and /etc/group ARE still used. LDAP contains only user accounts, no system accounts (because system accounts are NOT easily portable over multiple UNIX systems, eg IRIX, Solarix and Linux). tss is a system account that should be shipped with baselayout instead of only being created by app-crypt/trousers. I'm saying the entire bug is fixed by simply shipping with a 'tss' entry in both /etc/passwd and /etc/group. The nsswitch.conf I noted makes NSS/libc look in the files FIRST, then check LDAP if the entry is not found in the files.
sorry, got your logic reversed regardless, i dont think tss belongs in baselayout (especially since we're trying to cut out a lot of the crap users/groups)
ok, if we won't add tss to baselayout, could we please remove it's use from the default udev, so that udev doesn't try it by default (it would make sense to only probe it if the related packages are installed).
I would have thought that if the user patches his kernel with tpm or enable it in 2.6.12 (which includes it), that he would merge trousers as well?
I don't use TPM at all. It's the nss-lookups themselves that are causing trouble. Either they should have an entry in the baselayout /etc/passwd (so the lookup doesn't hit ldap), or the lookup shouldn't take place.
seems reasonable that udev shouldnt look up group info unless the rule is used ... any thoughts gregkh ? :)
Hi, I have this problem too. Can't boot with udev-068 and it's default config. I had to comment the line : KERNEL=="tpm*", NAME="%k", OWNER="tss", GROUP="tss", MODE="0600" in 50-udev.rules to boot. But, what is the real good solution please ? English is not my native language and I can't understand all what you mean here...
To fix this problem: - press ctrl+c while your system is hung waiting for udev; this will give you a prompt to enter your root password or press ctrl+d. If you don't have initrd you'll need to use your livecd. - enter your root password. - type 'mount -o rw,remount /' - then comment the entry for the tss user/group in /etc/udev/rules.d/50- udev.rules (line 244 on my revision). - type 'reboot'
This is still a problem on udev-70-r1. Anyone that does the openldap authentication guide will be effected by this problem. It's critical because their system is not booting. An inline sed command should be added to the next udev ebuild revision... sed - i 's/"KERNEL==\"tpm/# "KERNEL==\"tpm/' /etc/udev/rules.d/50-udev.rules
No, the "correct" fix is to not lookup the group information unless we are going to apply a rule. But, we just added the ability to "compile" the rules so we don't parse them all every time we get a device, and that will be in the next release, which should cause things like this to only timeout once (not perfict, but better.) If you wish to fix this in the "real" way, patches are always accepted upstream, otherwise it will have to wait until I get some spare time.
*** Bug 111495 has been marked as a duplicate of this bug. ***
udevstart don't run at all at start with only version 077 and 077-r1 I mask this, and 073 appear ... then all done with it (I use ~x86 of udev because of they need be kde 3.5) what's up in this version ?
ok udev-077 and plus after missing dependancy to baselayout-0.12 and plus ... in 0.11 they miss to launch udevstart correctly with new udev adding dependancy should correct it
Yes, there's nothing I can do in the udev package for the ldap issues, unless someone else has some ideas. If you want to do this, I recommend changing all of the "GROUP=" portions in your udev config file to be numbers. That way we don't look up the id. And if you have other udev issues unrelated to the bug subject, please open new bugs for it. 077-r3 is out which should fix the udevd and baselayout problem.
i think the idea was that udev should only look up GROUPs if they are actually needed ... that would "resolve" this bug for most people
Ah, got it, that makes more sense, I'll reopen this...
My problem is almost identical, but on my configuration it triggers with enabling ldap-lookups for hosts in nsswitch.conf (ldap is also enabled for passwd/group etc. but that doesn't seem to cause an error): hosts: files dns ldap I have no self-written udev-rules whatsoever, the standard ones I have in /etc/udev/rules.de are: 05-udev-early.rules 30-svgalib.rules 50-udev.rules 60-vmware.rules What could trigger this behaviour?
Status update? Can we get an item added to the openldap authentication guide? I attempted to contact the author but he seems out of gentoo now
I too use ldap authentication for users. I was first bitten by this bug upgrading from 058 to 068 (I think it was 068). Found the solution here and commented out the "KERNEL==tmp..." line in /etc/udev/rules.d/50-udev.rules. I just updated from 070 to 079. I don't have any custom rules nor do I ever change the udev rules, so I blinded replaced my 50-udev.rules with the update using etc-update. MY BAD! So I spent 2 hours scouring the forums. Should have checked here first! At the very least, there should be a BIG FAT RED einfo warning at the end of the emerge process regarding the problem and the simple solution. IMHO, a better solution would be to remove the "KERNEL==tpm..." rule from udev completely and have the trousers ebuild add it to 50-udev.rules or maybe its own rule file like 99-trousers.rules. The reason? How many Gentoo users use trousers? I did a search for trousers in the forums - only 7 results, none having to do with the app. Did a search in bugs.gentoo.org - 2 bugs filed, both resolved. The results may be misleading I admit.... So how about it? Can we at least get the einfo warning in the ebuild?
OK, did a little more digging... Seems like I was talking out of my rear end. tpm is kernel related. How about a kernel sanity check for the udev ebuld? If the kernel is configured for tpm, then insert the needed udev rule. If not, don't add it
not acceptable ... kernel can be changed later
(In reply to comment #22) > not acceptable ... kernel can be changed later > ??? Care to elaborate? I dont have tpm in my kernel, so why should I get a udev rule that causes my system to hang?
(In reply to comment #23) > (In reply to comment #22) > > not acceptable ... kernel can be changed later > > > > ??? Care to elaborate? > > I dont have tpm in my kernel, so why should I get a udev rule that causes my > system to hang? > Nevermind, I see ur point. How about the einfo warning?
No, we are working on the proper solution in udev, sorry for the delay...
I may be a goof here but isn't it bad to have a blocker severity bug open since July 19th 2005? Sure it should be downgraded a bit but nobody has done that & then it just looks bad to have this still open. I think there are some very obvious, easy to implement, solutions listed here and you're ignoring them in what I assume is an attempt to get upstream to fix the problem... I normally don't rant to devs but frankly *I think you're making bad choices regarding this bug* - it's fine to persue it upstream but lets get a working solution in like 'yesturyear'...
There, it's not a "blocker" bug anymore. And if you don't like to "rant" at developers, do not do so, it only makes us want to go work on other things instead...
Comenting out the line KERNEL=="tpm*", NAME="%k", OWNER="tss", GROUP="tss", MODE="0600" is a quick solution to avoid udev eternal lookups. However there's another step that also blocks the init process: "Cleaning /tmp" /etc/init.d/bootmisc on the line chown 0:0 /tmp/.{ICE,X11}-unix If I comment that line out then the system boots ok (not a definite solution though). System is EM64T (amd64 iso), latest udev and latest baselayout. nsswitch.conf needs ldap in my case.
i have the same problem. i have changed chown 0:0 ... back in root:root and now it works again (i am using ldap for authentification but root is in passwd file).
I ran into this problem as well on two machines, a Pentium 3 and a PentiumD-64 which use ldap for nss and pam. On top of that, I had trouble remounting / as rw even with -o remount,rw (said / wasn't all ready mounted...leave out remount and it said it was all ready mounted) I had to boot from a liveCD to fix this. ldap obviously can't be queried before ldap or the network have a chance to come up. This is a pretty serious error
Same problem here on 2 of 3 machines, but no real solution. Only a init-script with a mount --bind makes the system booting and using ldap. But on one machine, i still cannot login while getent is getting the right information.
(In reply to comment #31) Same problem here on 1 machine with ldap It got a long time to understand the problem, the first cause was that this machine is running unattended without display and kb. And it's only after searching in the forums that I found this Bug. It's difficult to understand why this "old" bug has no solution or has not any red flag during installation. For me it's the first time that my gentoo didn't Boot. I have learned to always have a LiveCd whis me.....
As I stated earlier in Comment #20, commenting out the "tpm" line in /etc/udev/rules.d/50-udev.rules works for me, however, I was upgrading an old dormant machine and came across info on the web regarding an option in /etc/nsswitch.conf According to the manpage for nsswitch.con ( # man nsswitch.conf ) there is a paramter for the status of the lookup and an action. ....Snippet from manpage nsswitch.conf begin..... hosts: dns [!UNAVAIL=return] files networks: nis [NOTFOUND=return] files ethers: nis [NOTFOUND=return] files protocols: nis [NOTFOUND=return] files rpc: nis [NOTFOUND=return] files services: nis [NOTFOUND=return] files The configuration specification for each database can contain two dif- ferent items: * The service specification like `files', `db', or `nis'. * The reaction on lookup result like `[NOTFOUND=return]'. .....later in manpage.... The second item in the specification gives the user much finer control on the lookup process. Action items are placed between two service names and are written within brackets. The general form is `[' ( `!'? STATUS `=' ACTION )+ `]' where STATUS => success | notfound | unavail | tryagain ACTION => return | continue The case of the keywords is insignificant. The STATUS values are the results of a call to a lookup function of a specific service. They mean: success No error occurred and the wanted entry is returned. The default action for this is `return'. notfound The lookup process works ok but the needed value was not found. The default action is `continue'. unavail The service is permanently unavailable. This can either mean the needed file is not available, or, for DNS, the server is not available or does not allow queries. The default action is `continue'. tryagain The service is temporarily unavailable. This could mean a file is locked or a server currently cannot accept more connections. The default action is `continue'. ....End of Snippet.... That being the case, perhaps a setting such as passwd: ldap [NOTFOUND=return] db files or passwd: ldap [!UNAVAIL=return] db files in /etc/nsswitch.conf may be the correct workaround for this problem. I haven't tried it my self yet since commenting out the "tpm" line in the udev rules did the trick for me. Anyone try this or have experience with this paramater?
there's an alternate solution to this: http://www.nabble.com/Re%3A-nss_ldap-and-udevd-p3202151.html works for me with nss_ldap-249 and udev-079
*** Bug 128907 has been marked as a duplicate of this bug. ***
*** Bug 129680 has been marked as a duplicate of this bug. ***
*** Bug 132940 has been marked as a duplicate of this bug. ***
Switched to Ubuntu. No longer interested in gentoo issues.
Make the UDEV ebuild react to the ldap USE flag. (and comment that line out if ldap is being used) Its so simple you should praise and worship me. Hail to the king.
No praise is worthy without a patch :(
Since yesterday, I had this problem too. After commenting out the tss line from /etc/udev/rules.d/50-udev.rules, no problem anymore with udev, but wiping /tmp took far too long. Also named seemed to hang, at least long enough for me too press ctrl-alt-del. After digging emerge.log I found out sys-auth/nss_ldap was upgraded from 239-r1 to 249 since the last reboot. Degraded solved the problem, but of course I want to stay up2date so I tried the alternate solution from comment #34 and after upgrading sys-auth/nss_ldap to 249 again, the problem didn't come back. So, I think the solution from comment #34 rocks, just add the next line to /etc/ldap.conf: bind_policy soft
"bind_policy soft" is not really a good solution. If something happens with the network connection on the client, user processes would break. On a large computing cluster, the jobs are starting to crash instead of waiting some time for connection to come up. I had to downgrade to 239-r1 due to that problem.
So if I understand right, the whole problem of this bug is caused by sys-auth/nss_ldap-249 or am I wrong now?
evert: no, it's not a bug with nss_ldap. this bug will occur with any network based NSS lookup, and that service is not yet available at the time udev is doing lookups of entries not in the basic system. As it stands, there are two solutions better than messing with the the NSS service. 1. (this is the proper solution) fix udev to not look up the tss entry (that it really doesn't need to). see comment #11 from gregkh. 2. add tss entries back to /etc/{passwd,group}. this is against gentoo policy, so they were removed from the files provided by baselayout, and are with the tss/tpm package instead. 3. comment out the tss/tpm entries in the udev rules. Using 'bind_policy soft' is dangerous as it can break applications later. Messing with nsswitch.conf is not desirable because you still need to wait for the 60 second timeout for each lookup.
I was hit by this bug after updating over the weekend. I didn't find this bug report until after I fixed it on my system. My thought was that services should not be trying to access the network until the network is up. I created a solution that prevents this problem on LDAP systems. It could be modified for other network-based authentication schemes. I added the following to /etc/conf.d/net: postup() { if test -a /etc/nsswitch.conf.net; then mv /etc/nsswitch.conf.net /etc/nsswitch.conf fi } postdown() { if grep ldap /etc/nsswitch.conf > /dev/null ; then cp -a /etc/nsswitch.conf /etc/nsswitch.conf.net sed 's/ldap//' /etc/nsswitch.conf.net > /etc/nsswitch.conf fi } This solution prevents hangs while waiting for the ldap server to fail due to the interface not being up.
I had a similar workaround before I notice this bug, but then using /etc/conf.d/local.{start,stop}. This workaround only doesn't work after a system crash since in that case, local.stop isn't called and nsswitch.conf is still refering to ldap at boot.
I experienced also hangs with udev-087, baselayout-1.11.14-r8 and nss_ldap-249 when booting on our systems. I fixed them temporarily with the solutions in this bug: - hang on starting udev, fixed with commenting out the tpm line in /etc/udev/rules.d/50-udev.rules - hang on cleaning out /tmp, fixed with changing the line chown 0:0 to chown root.root in /etc/init.d/bootmisc Sorry, I can't help more on this for a better solution.
Thanks all. Just got hit by this bug. For myself, since there is obviously no definitive fix, I'll simply downgrade nss_ldap until someone puts their pants on.
I took the other approach and simply added a tss user/group. If it's supposed to be a system level thing, it might as well be there. Also this method means I don't have to worry about missing upgrades to nss_ldap or udev or whatever.
I had the same problem on a desktop system here which, after working just fine for a year or so, became nearly unbootable and unusable after an emerge -uD world today. Booting took nearly 45 minutes and many operations involving authentication took many minutes to complete. nsswitch.conf contained: passwd: files ldap shadow: files ldap group: files ldap I took ldap out of the auth mix here, commented out the tpm entry in /etc/udev/rules.d/50-udev.rules, backversioned nss_ldap and things seem to be back to normal. Part of the problem here is that I need ldap client behavior in several user apps such as evolution, and need basic ldap tools for working with a remote ldap server, however I don't need ldap authentication or to have ldap client functionality built into system components. Setting USE=ldap in make.conf, as I have it, seems like a one-size-fits-all solution that doesn't always fit. Perhaps applications which can optionally be built with ldap client capabilities could USE an alternate flag such as "ldap-client". USE flag or not, I'm not sure why udev and nss_ldap are trying to bind, or even allowed to try to bind to _any_ ldap server before either the network or the local ldap server are started during boot. Like Sebastien, I'm waiting for Greg KH and others to get their pants on and figure out just where this needs to be addressed. It's really nasty! If it had happened on my commercial server rather than my desktop it would have cost me customers.
Why is this bug still not resolved? I remember having this problem when I switched to LDAP users around a year ago. It was an issue then - and now upgrading to the "stable" nss_ldap-249 breaks my entire system boot. Why not just remove the trousers line from udev rules, already? Would that be such a terrible consequence? The trousers ebuild could add it back in, or put it in its own udev rulefile - then at least you wouldn't be breaking us normal users who don't even have the component that's indirectly causing the issue. Or remask nss_ldap-249, since it makes this issue resurface.
for everybody following here: nss_ldap-250-r1 is in the tree, and documents the timeout functionality, as well as using much shorter defaults (timeout 15 seconds per lookup instead of 124 seconds). Please do read my blog post linked from the ChangeLog about this.
*** Bug 137535 has been marked as a duplicate of this bug. ***
Hy, I have the same problem: udev-087-r1 and nss_ldap-249. Is there a solution to this problem? I have 2 production servers that were hit by this problem!!!
*** Bug 138561 has been marked as a duplicate of this bug. ***
Neagul Marian: upgrade to nss_ldap-250-r1
There is no real fix yet! - but there is a workaround. The workaround has two steps: 1. You have to do either of this two: a. Create user "tss" and group "tss" b. comment the line following line in '/etc/udev/rules.d/50-udev.rules': "KERNEL=="tpm*", NAME="%k", OWNER="tss", GROUP="tss", MODE="0600" 2. Emerge "nss_ldapnss_ldap-250-r1" - else it hangs forever on "Cleaning /tmp directory ..."
*** Bug 138901 has been marked as a duplicate of this bug. ***
(In reply to comment #57) > There is no real fix yet! - and what are they waiting for?? common LDAP today is a mayor componet of a corporate network enviroment, as me I have 340 desktops and 67 servers running gentoo/ldap and other services... everyone I know have move from NIS to ldap why is this been treat as a second level issue? if I had the time and understanding of the udev code/ldap I will give a hand but in this one I have to sit back and wait.. PLEASE DO SOMETHING
Created attachment 91130 [details, diff] Stop udev resolving names when loading rules This should solve the problem of udev looking up the uid/gid's unless adding a device, but I don't have a spare LDAP server to test against, and cannot set one up easily.
What, no-one's even tested this patch to fix this "critical" bug? Well, I was able to test against our production LDAP today as our server needed to be rebooted for a hardware upgrade so I took the opportunity to test the patch and it seems to work. Greg, is this OK to add to portage?
Sorry, been busy with different conferences right now. That patch doesn't look right, it takes out all group and owner lookups, which would break non-ldap systems, right?
(In reply to comment #62) > Sorry, been busy with different conferences right now. > > That patch doesn't look right, it takes out all group and owner lookups, which > would break non-ldap systems, right? The patch basically only looks up uid/gid when a rule is being applied. However, this lookup is made each time the rule is applied. I've tested this on non-LDAP and LDAP systems and it works 100% for me.
Ok, care to post it upstream at the linux-hotplug-devel mailing list so that the upstream developers can comment on it? If they accept it, I'll add it to the build.
Created attachment 93451 [details, diff] Stop udev resolving names when loading rules New patch remembers looked up uid/gid in the rule, making us more efficient than before :) C'mon guys, there's plently of you here! Do these patches fix it for you?
(In reply to comment #65) > C'mon guys, there's plently of you here! Do these patches fix it for you? I disabled upgrading of nss-ldap until this is fixed. :P I simply don't have the time to break things. I want to salute your effort though. It's truly appreciated.
Comment on attachment 93451 [details, diff] Stop udev resolving names when loading rules Addition to patch does not work.
*** Bug 142877 has been marked as a duplicate of this bug. ***
After using the new nss_ldap I've pump into another bug.... This help http://forums.gentoo.org/viewtopic-t-477895-highlight-chroot+named.html My dear Friends, it have been a year and it HAVE TO BE SOLVE, Please.
that issue is totally unrelated if you have nothing to contribute, then dont bother speaking, it just pisses off people
(In reply to comment #64) > Ok, care to post it upstream at the linux-hotplug-devel mailing list so that > the upstream developers can comment on it? If they accept it, I'll add > it to the build. > Upstream (well, Kay) seems to think that this patch is bad as it would slow down users who have thousands of devices and that the issue should be fixed by adding any user/group combos to passwd/group files. http://sourceforge.net/mailarchive/forum.php?thread_id=28927892&forum_id=3157 http://sourceforge.net/mailarchive/forum.php?thread_id=29547555&forum_id=3157 As previously discused here, that is a bad idea. So upstream doesn't like the patch and based on that discussion will probably never fix it. An impasse has been reached. Interesting to note that a debian guy piped up saying that this issue also applies to Debian and could not see anything wrong with my patch. If anyone has any more bright ideas then I'm all ears. However, my patch does solve the immediate issue so if no-one speaks up (ie Greg) then I'll add it to portage in a few days.
Just noticed this patch. I missed it when you first posted it Uberlord. Works awesome for me. Now the only issue is the pause after Cleaning /tmp... But I believe nss_ldap-250 made this pause more managable since it was only about 15 seconds. Good job with the patch. :)
(In reply to comment #72) > Now the only issue is the pause after Cleaning /tmp... That's fixed with baselayout-1.12.4-r2 We don't do a chown anymore as bsd doesn't have root:root and 0:0 caused network lookups for names 0:0 due to chown design - see bug #139411
I'll just remove the tpm group/user stuff from our rules file, don't add the patch to the package. Then the tpm userspace package can add it as a rules file, if the user installs it, as then there will be such a user. That sound ok to everyone? And yes, I agree with Kay, we shouldn't be shipping a rules file with groups/users specified in it that we do not include in our baselayout.
Uberlord... baselayout-1.12.4-r2 might fix it but it's not stable... And I haven't heard of 1.12.x becoming stable anytime soon. There's been a lot of requests for it to become stable....
*** Bug 143795 has been marked as a duplicate of this bug. ***
Will be fixed in 098 udev release, please try this. The offending entry is now gone from the file. The TPM package will have to add their own udev rule file, if they need it, but if they do that, the user/group will have been created.
*** Bug 153456 has been marked as a duplicate of this bug. ***
Shouldn't the solution for this bug be: "Add the following line to /etc/ldap.conf: nss_initgroups_ignoreusers tss " Also, shouldn't this solution become standard for stock distribution of nss_ldap for EVERY local system group? LDAP queries shouldn't be used to find out if user 'tape' or user 'djbdns' exist. This information is suposed to be local and remain local. Otherwise every configuration that queries LDAP will have a bloated set of users and groups. P.S. - I personally think that /etc/ldap.conf should be renamed to /etc/nssldap.conf to reduce naming conflicts and confusion.
pedrorandrade: it's expected that you add yourself to the CC list if you post on a bug and expect a response. You are attacking the problem at the wrong level. If your system is correctly configured, every lookup for a system user will hit the files backend. The 'tss' lookup problem happened because the user got removed from /etc/passwd, which meant on LDAP systems, the lookup went to ldap next, which wasn't available because the system was still booting, combined with the very long timeouts that upstream nss_ldap has as defaults (and we patched back down in 250-r1). Using the nss_initgroups_ignoreusers configuration option would not help the original situation at all, because the lookup was for the numeric uid of the user, not what groups they were in. If you really want to be helpful on the seperate issue of initgroups_ignoreusers, write a patch to nss_ldap that permits only ldap users to be in ldap groups, and considers local users to never be in ldap groups. (And make sure the patch works when the LDAP server is not available).
(In reply to comment #81) > pedrorandrade: it's expected that you add yourself to the CC list if you post > on a bug and expect a response. Sorry. I very seldomly report/comment on bugs. I'll keep that in mind. (snip) > Using the nss_initgroups_ignoreusers configuration option would not help the > original situation at all, because the lookup was for the numeric uid of the > user, not what groups they were in. OK. Got it. Numeric ID, NOT uid. > If you really want to be helpful on the seperate issue of > initgroups_ignoreusers, write a patch to nss_ldap that permits only ldap users > to be in ldap groups, and considers local users to never be in ldap groups. Don't really know how to write and submit a patch, but i'll get into it. > (And make sure the patch works when the LDAP server is not available). I guess that nss_initgroups_ignoreuser will never try to contact the LDAP server for the listed users so I don't see a problem there...
