Hi. NSCD stands for name service caching daemon, which is what it does: cache name lookups (uid <-> user name, port <-> service name, gid <-> group name, you get the feeling). Now, when you use NIS, you have to look up every uid, name, gid... on the NIS server, which can take a looong time. So those lookups are cached by nscd (easily seen with the following command sequence:) ls -l change username in /etc/passwd (which is where uid-username mappings reside) ls -l again Hope that explains it a little bit. Greetings olli On Tue, 19 Dec 2000, Nix wrote:

Can someone explain the advantage to NSCD in Laymans terms? I'm under the impression after reading man pages etc that it simply caches authentication data for a period of time. Is this correct? I know that I almost always turn it off on servers I build, with no ill- effects. I figgured that it certainly wasn't needed on things like web servers where authentication happens at most once or twice per day. I guess mail servers and shell servers are a different story. I'm just wondering at what point is it actually "worth" running.

(*grin* Just thought I'd ask a question for once instead of writing rambling replies..)

-Nix

At 09:26 PM 18/12/2000 +0000, you wrote:

...

Hi folks,

It may be slightly off topic but I believe this problem belongs in the SuSE support DB:

After adding a user with useradd (or YaST) I tried to set a password with passwd, only to receive the reply "unknown user".

Searching in my usual source of answers, the suse.de support database, gave me no answers, instead a google search (built into opera) pointed me towards this article, which mentions nscd as the source of evil:

http://archives.neohapsis.com/archives/linux/suse/2000-q1/0328.html

Would the Suse Team (cheers to them!) be so good as to add this to the SDB? Although I've found the answer there are most likely others who are having the same problem!!

Regards,

Barry

--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com

-- -------------------------------------- Oliver Hensel http://www.ohensel.de/ Training + Consulting Unix - Linux - Firewalls - Security --------------------------------------

Hi, Monday, December 18, 2000, 11:19:14 PM, you wrote: N> I guess I knew most of that, I'm still wondering if it's worth running at all N> if you don't use NIS, and at what point (if any) it does become worth running. My initial thoughts were that web server logging could take advantage of this. I.e. if a visitor downloads multiple pages from a server, then the server needn't query the DNS server for each page to find out the FQDN from the ip address. But I would have thought that any good webserver would cache internally anyway ?! Alternatively, say you telnet to a certain machine frequently - would nscd help to speedup the resolving ?? Or does nscd only cache the /etc/hosts entries, and not "ns-looked up" ones ?? Best regards, Barry mailto:barry@penrallt.clara.co.uk

Hi, Monday, December 18, 2000, 11:51:25 PM, you wrote: N> I hope to hell that you don't log DNS names in you web server logs!!??!! N> FYI, you should NEVER log dns names for anything. It slows you server N> down to the speed of DNS replies, which is most definately a "bad idea" (tm) Hmm, I suppose you've got a point - but FQDNs are sure helpful in determining whence visitors came. And AFAIK only expensive log analysers (e.g. WebTrends) resolve IPs while analysing logs. Or is there a script I could run in crontab to convert unresolved IPs in the background? To not be completely off topic: Who uses NIS these days? I don't know anyone ... If it's not popular, then why is it enabled as default? Best regards, Barry mailto:barry@penrallt.clara.co.uk

Hmm, I suppose you've got a point - but FQDNs are sure helpful in determining whence visitors came.

And AFAIK only expensive log analysers (e.g. WebTrends) resolve IPs while analysing logs.

Yeah or that webalizer that costs ... oh wait it's free. To turn ip's into names in your log files takes a few lines of perl....

Or is there a script I could run in crontab to convert unresolved IPs in the background?

Yes. Has it been written, well, you tell us =).

To not be completely off topic: Who uses NIS these days? I don't know anyone ... If it's not popular, then why is it enabled as default?

Large organizations tend to, universities/companies. Is it popular, hell no, neither are wisdom teeth extractions either but it has to be done =). As for enabled by default, yeah, why is it Roman/Marc/Tom? -Kurt

On Tue, Dec 19, 2000 at 04:12:25AM +0100, Roman Drahtmueller wrote:

...

...

To not be completely off topic: Who uses NIS these days? I don't know anyone ... If it's not popular, then why is it enabled as default?

Large organizations tend to, universities/companies. Is it popular, hell no, neither are wisdom teeth extractions either but it has to be done =). As for enabled by default, yeah, why is it Roman/Marc/Tom?

You guys should try to run 30000 or even 600000 users on a single box and see the performance drop to zero. :-) It's just not possible without nscd, whereas the overhead that results from the socket operations is a bit more than what results from the Solaris doors mechanism. Anyway, START_NSCD is set to "yes" by default because the nscd has become a basic ingredient of the library space. Some other things like nis+ or ldap don't work without nscd. Killing/disabling it doesn't really make sense because it's very inexpensive: around 600-900 kB for one single process (keep in mind that it's multithreaded).

Well i think most of us do not run 30000 or even 600000 users at all and if you do, then there are that many other speed related problems to solve. This amount of users needs a lot of tuning and i think installing a program like NSCD is or should be part of that tuning. I personaly run SuSE on a web-servers and have NSCD turned of. The reason is that i only read difficulties of NSCD and every pogram adds a security risc. Just my 2 (euro-)cents. GRTNX, RobJE -- Home is where my keyboard is. ====================================================================== Tel: +31 - 317 - 423300 s-mail: P.O. box 617 Fax: +31 - 317 - 423164 6700 AP Wageningen MailTo: r.epping@weer.nl WWW: http://www.weer.nl/

Hi, Barry Hill wrote:

Hi,

Monday, December 18, 2000, 11:51:25 PM, you wrote:

N> I hope to hell that you don't log DNS names in you web server logs!!??!! N> FYI, you should NEVER log dns names for anything. It slows you server N> down to the speed of DNS replies, which is most definately a "bad idea" (tm)

Hmm, I suppose you've got a point - but FQDNs are sure helpful in determining whence visitors came.

And AFAIK only expensive log analysers (e.g. WebTrends) resolve IPs while analysing logs.

Or is there a script I could run in crontab to convert unresolved IPs in the background?

There is an article in the actual magazine i'x dealing with this topic. But the Perl Skripts mentioned there are not fully listed, only a small fragment. May be they are laying around somewhere on www.heise.de

To not be completely off topic: Who uses NIS these days? I don't know anyone ... If it's not popular, then why is it enabled as default?

Best regards,

Barry mailto:barry@penrallt.clara.co.uk

--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com

Hello Nix, FWIW... I tend to make an 'attic' directory in most of my rcX.d dirs. Then I dump a whole lot of 'enterprise grade service' SXX* and KXX* links into that dir - nscd is generally nr 1 on my list of favourite overkill services ;-) Then there's 'handy' stuff like *pcnfsd, *gpm, *rwhod that goes into the attic too. On my IRIX and solaris boxen the whole plethora of remote admin/monitoring daemons are next... just my 0.02 ttfn, avi -------------------------------------------------------------------------- Avi Bercovich bercovic@swi.psy.uva.nl Sinjeur Semeynsstraat 9 Dept. of Social Science Informatics (SWI) 1183LD Amstelveen University of Amsterdam On Tue, 19 Dec 2000, Nix wrote:

Yeah,

I guess I knew most of that, I'm still wondering if it's worth running at all if you don't use NIS, and at what point (if any) it does become worth running.

Nix

At 12:06 AM 19/12/2000 +0100, you wrote:

...

Hi.

NSCD stands for name service caching daemon, which is what it does: cache name lookups (uid <-> user name, port <-> service name, gid <-> group name, you get the feeling). Now, when you use NIS, you have to look up every uid, name, gid... on the NIS server, which can take a looong time. So those lookups are cached by nscd (easily seen with the following command sequence:)

ls -l change username in /etc/passwd (which is where uid-username mappings reside) ls -l again

Hope that explains it a little bit.

Greetings olli

On Tue, 19 Dec 2000, Nix wrote:

...

Can someone explain the advantage to NSCD in Laymans terms? I'm under the impression after reading man pages etc that it simply caches authentication data for a period of time. Is this correct? I know that I almost always turn it off on servers I build, with no ill- effects. I figgured that it certainly wasn't needed on things like web servers where authentication happens at most once or twice per day. I guess mail servers and shell servers are a different story. I'm just wondering at what point is it actually "worth" running.

(*grin* Just thought I'd ask a question for once instead of writing rambling replies..)

-Nix

At 09:26 PM 18/12/2000 +0000, you wrote:

...

Hi folks,

It may be slightly off topic but I believe this problem belongs in the SuSE support DB:

After adding a user with useradd (or YaST) I tried to set a password with passwd, only to receive the reply "unknown user".

Searching in my usual source of answers, the suse.de support database, gave me no answers, instead a google search (built into opera) pointed me towards this article, which mentions nscd as the source of evil:

http://archives.neohapsis.com/archives/linux/suse/2000-q1/0328.html

Would the Suse Team (cheers to them!) be so good as to add this to the SDB? Although I've found the answer there are most likely others who are having the same problem!!

Regards,

Barry

--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com

-- -------------------------------------- Oliver Hensel http://www.ohensel.de/

Training + Consulting Unix - Linux - Firewalls - Security --------------------------------------

--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com

-- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking

--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com

On Tue, 19 Dec 2000, Nix wrote:

errrm.. Doesn't this sorta defeat the whole "niceness" of the SuSE boot structure.

I know this is the way to do it on solaris etc, but SuSE's init structure is gorgeous. Surely you don't want to cripple that :-)

;-) true - but in the end I tend to use SuSE as a stable base, only to maul it beyond recognition to suit my own pet sysadmin hang-ups... sorry mr & mrs SuSE. ttfn, avi

-Nix

At 12:51 AM 19/12/2000 +0100, you wrote:

...

Hello Nix,

FWIW... I tend to make an 'attic' directory in most of my rcX.d dirs. Then I dump a whole lot of 'enterprise grade service' SXX* and KXX* links into that dir - nscd is generally nr 1 on my list of favourite overkill services ;-) Then there's 'handy' stuff like *pcnfsd, *gpm, *rwhod that goes into the attic too. On my IRIX and solaris boxen the whole plethora of remote admin/monitoring daemons are next...

just my 0.02

ttfn,

avi

-------------------------------------------------------------------------- Avi Bercovich bercovic@swi.psy.uva.nl Sinjeur Semeynsstraat 9 Dept. of Social Science Informatics (SWI) 1183LD Amstelveen University of Amsterdam

On Tue, 19 Dec 2000, Nix wrote:

...

Yeah,

I guess I knew most of that, I'm still wondering if it's worth running at all if you don't use NIS, and at what point (if any) it does become worth running.

Nix

...

Hi.

NSCD stands for name service caching daemon, which is what it does: cache name lookups (uid <-> user name, port <-> service name, gid <-> group name, you get the feeling). Now, when you use NIS, you have to look up every uid, name, gid... on the NIS server, which can take a looong time. So those lookups are cached by nscd (easily seen with the following command sequence:)

ls -l change username in /etc/passwd (which is where uid-username mappings reside) ls -l again

Hope that explains it a little bit.

Greetings olli

On Tue, 19 Dec 2000, Nix wrote:

...

Can someone explain the advantage to NSCD in Laymans terms? I'm under the impression after reading man pages etc that it simply caches authentication data for a period of time. Is this correct? I know that I almost always turn it off on servers I build, with no ill- effects. I figgured that it certainly wasn't needed on things like web servers where authentication happens at most once or twice per day. I guess mail servers and shell servers are a different story. I'm just wondering at what point is it actually "worth" running.

(*grin* Just thought I'd ask a question for once instead of writing rambling replies..)

-Nix

At 09:26 PM 18/12/2000 +0000, you wrote:

...

Hi folks,

It may be slightly off topic but I believe this problem belongs in the SuSE support DB:

After adding a user with useradd (or YaST) I tried to set a password with passwd, only to receive the reply "unknown user".

Searching in my usual source of answers, the suse.de support database, gave me no answers, instead a google search (built into opera)

At 12:06 AM 19/12/2000 +0100, you wrote: pointed

...

...

...

me towards this article, which mentions nscd as the source of evil:

http://archives.neohapsis.com/archives/linux/suse/2000-q1/0328.html

Would the Suse Team (cheers to them!) be so good as to add this to the SDB? Although I've found the answer there are most likely others who are having the same problem!!

Regards,

Barry

--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com

-- -------------------------------------- Oliver Hensel http://www.ohensel.de/

Training + Consulting Unix - Linux - Firewalls - Security --------------------------------------

--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com

-- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking

--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com

-- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking

--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com

Hi. On Tue, 19 Dec 2000, Bastian Friedrich wrote:

Moin.

[snip]

I most definitely want to do that in a couple of cases. Although SuSE's init structure is fine for the regular user, there's no point in parsing /etc/rc.config `ls /etc/rc.d/rc3.d/ |wc -l` (= 102 in my place) times just to pick out a single "yes" or "no" for services you'll _never_ want to start and in some cases even haven't installed (and yes, as everybody else I wonder why the heck SuSE believes users want nscd).

How much time does it take for a modern computer to parse this? 1 sec? 2 sec? will you really notice?

If I'll get my laptop on wednesday (most definitely booting more than once a day), I'll throw out 90% of the start scripts.

do what you want, but I would recommend to just set it to "no" in /etc/rc.config. What happens if you install the update for, say nkitb? servers start again, which you didn't want?

Ciao, Basti

PS: Nix, if you quote the question _above_ your answer in your reply, things will be easyer... And plz stop full quoting.

Hey, it's not the really big volume list, is it? Greetings olli -- -------------------------------------- Oliver Hensel http://www.ohensel.de/ Training + Consulting Unix - Linux - Firewalls - Security --------------------------------------

Hi. On Tue, 19 Dec 2000, Avi Bercovich wrote:

Hello Nix,

FWIW... I tend to make an 'attic' directory in most of my rcX.d dirs. Then I dump a whole lot of 'enterprise grade service' SXX* and KXX* links into that dir - nscd is generally nr 1 on my list of favourite overkill services ;-) Then there's 'handy' stuff like *pcnfsd, *gpm, *rwhod that goes into the attic too. On my IRIX and solaris boxen the whole plethora of remote admin/monitoring daemons are next...

Just shut it off in /etc/rc.config (e.g. START_NSCD=no)

just my 0.02

ttfn,

avi

my 0.02 (Euro) Greetings olli

-------------------------------------------------------------------------- Avi Bercovich bercovic@swi.psy.uva.nl Sinjeur Semeynsstraat 9 Dept. of Social Science Informatics (SWI) 1183LD Amstelveen University of Amsterdam

On Tue, 19 Dec 2000, Nix wrote:

...

Yeah,

I guess I knew most of that, I'm still wondering if it's worth running at all if you don't use NIS, and at what point (if any) it does become worth running.

Nix

At 12:06 AM 19/12/2000 +0100, you wrote:

...

Hi.

NSCD stands for name service caching daemon, which is what it does: cache name lookups (uid <-> user name, port <-> service name, gid <-> group name, you get the feeling). Now, when you use NIS, you have to look up every uid, name, gid... on the NIS server, which can take a looong time. So those lookups are cached by nscd (easily seen with the following command sequence:)

ls -l change username in /etc/passwd (which is where uid-username mappings reside) ls -l again

Hope that explains it a little bit.

Greetings olli

On Tue, 19 Dec 2000, Nix wrote:

...

Can someone explain the advantage to NSCD in Laymans terms? I'm under the impression after reading man pages etc that it simply caches authentication data for a period of time. Is this correct? I know that I almost always turn it off on servers I build, with no ill- effects. I figgured that it certainly wasn't needed on things like web servers where authentication happens at most once or twice per day. I guess mail servers and shell servers are a different story. I'm just wondering at what point is it actually "worth" running.

(*grin* Just thought I'd ask a question for once instead of writing rambling replies..)

-Nix

At 09:26 PM 18/12/2000 +0000, you wrote:

...

Hi folks,

It may be slightly off topic but I believe this problem belongs in the SuSE support DB:

After adding a user with useradd (or YaST) I tried to set a password with passwd, only to receive the reply "unknown user".

Searching in my usual source of answers, the suse.de support database, gave me no answers, instead a google search (built into opera) pointed me towards this article, which mentions nscd as the source of evil:

http://archives.neohapsis.com/archives/linux/suse/2000-q1/0328.html

Would the Suse Team (cheers to them!) be so good as to add this to the SDB? Although I've found the answer there are most likely others who are having the same problem!!

Regards,

Barry

--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com

-- -------------------------------------- Oliver Hensel http://www.ohensel.de/

Training + Consulting Unix - Linux - Firewalls - Security --------------------------------------

--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com

-- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking

--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com

--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com

-- -------------------------------------- Oliver Hensel http://www.ohensel.de/ Training + Consulting Unix - Linux - Firewalls - Security --------------------------------------