Re: [suse-security] Problems with YaST / Usermanagement
The problem that you encounter is most likely caused by incoherent caching of the nscd. You could change some settings in /etc/nscd.conf, or you disable it completely (since you don't use NIS(+) or alike) in /etc/rc.config.
What about NSCD starting up AUTONOMOUSLY?! I have it explicitly disabled in the /etc/rc.config of a 24/7 server of mine, and after a while I find 7 (SEVEN) instances of /usr/sbin/nscd up and happily running! I've no idea about who or what invokes it. :-( ===== ===================== Dr. Simone Grabstein gsimon@rocketmail.com ===================== __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/
Hi Simone, i have got this problem with SuSE 6.3 too. Sometimes after YaST was running the nscd was again running. I simply solved it by deleting the daemon :-/ not nice but it works :-) Perhaps it's a problem within the startup scripts? Simone Grabstein wrote:
What about NSCD starting up AUTONOMOUSLY?!
I have it explicitly disabled in the /etc/rc.config of a 24/7 server of mine, and after a while I find 7 (SEVEN) instances of /usr/sbin/nscd up and happily running!
I've no idea about who or what invokes it. :-(
===== ===================== Dr. Simone Grabstein gsimon@rocketmail.com =====================
cheers -- Steffen M. Noe Darmstadt University of Technology Webmaster Institut fuer Soziologie Institut fuer Botanik Fachbereich 2 Fachbereich 10 Residenzschloss Schnittspahnstrasse 3-5 D-64283 Darmstadt D-64287 Darmstadt +49 6151 16-6591 +49 6151 16-3239 noe@ifs.tu-darmstadt.de noe@bio.tu-darmstadt.de MAY THE SOURCE BE WITH YOU !
On Wed, 2 Aug 2000, Simone Grabstein wrote:
The problem that you encounter is most likely caused by incoherent caching of the nscd. You could change some settings in /etc/nscd.conf, or you disable it completely (since you don't use NIS(+) or alike) in /etc/rc.config.
What about NSCD starting up AUTONOMOUSLY?!
I have it explicitly disabled in the /etc/rc.config of a 24/7 server of mine, and after a while I find 7 (SEVEN) instances of /usr/sbin/nscd up and happily running!
I've no idea about who or what invokes it. :-(
Have you checked the daemon startup script (/etc/rc.d/nscd)? Mine looks ok, but maybe in your distribution there is a typo which causes it to not check for a START_NSCD=yes. Just a thought.
===== ===================== Dr. Simone Grabstein gsimon@rocketmail.com =====================
__________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
Stefan ========================================== Stefan Suurmeijer Network Specialist University of Groningen tel: (+31) 50 363 3423 fax: (+31) 50 363 7272 E-mail (business): s.m.suurmeijer@let.rug.nl E-mail (private): stefan@symbolica.nl ========================================== Quis custodiet ipsos custodes? (Who'll watch the watchmen?) - Unknown
[snip]
What about NSCD starting up AUTONOMOUSLY?!
I have it explicitly disabled in the /etc/rc.config of a 24/7 server of mine, and after a while I find 7 (SEVEN) instances of /usr/sbin/nscd up and happily running!
I've no idea about who or what invokes it. :-(
Have you checked the daemon startup script (/etc/rc.d/nscd)? Mine looks ok, but maybe in your distribution there is a typo which causes it to not check for a START_NSCD=yes. Just a thought.
Dr. Simone Grabstein gsimon@rocketmail.com Stefan Suurmeijer E-mail (business): s.m.suurmeijer@let.rug.nl
You're right. This is most definitely a bug. It is fixed in later
versions. :-(
The effects should only be noticeable shortly after one or more out of
username, uid, groupname or gid has been changed.
Today, all account handling utilities work around nscd's incoherent
caching by accessing the files directly.
Note that encrypted passwords aren't cached.
Thanks,
Roman.
--
- -
| Roman Drahtmüller
participants (4)
-
Roman Drahtmueller -
Simone Grabstein -
Stefan Suurmeijer -
Steffen Noe