On 02 Oct 2004 09:41:49 GMT Casper H.S. Dik <Casper.Dik@Sun.COM> wrote:
> You should not/need not stop:
>
> nscd -> kills some performance and may unmask bugs;
> makes it impossible to edit /etc/resolv.conf
> or nsswitch.conf after booting and have
> the changes take effect.

How's that? Restarting your app must reinitialize the resolver, yes?

/fc

Frank Cusack <fcusack@fcusack.com> writes:

>On 02 Oct 2004 09:41:49 GMT Casper H.S. Dik <Casper.Dik@Sun.COM> wrote:
>> You should not/need not stop:
>>
>> nscd -> kills some performance and may unmask bugs;
>> makes it impossible to edit /etc/resolv.conf
>> or nsswitch.conf after booting and have
>> the changes take effect.

>How's that? Restarting your app must reinitialize the resolver, yes?

Yes; but that is not always an option; the nice thing about nscd
is that you can change the hostname lookup methods and configuration
without having to restart long running applications.

(There are also some known bugs in various name lookup codes
which are masked when nscd runs)

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

In article <x5y3c0u6ka7.fsf@mother.corp.google.com>,
Frank Cusack <fcusack@fcusack.com> writes:
> On 02 Oct 2004 09:41:49 GMT Casper H.S. Dik <Casper.Dik@Sun.COM> wrote:
>> You should not/need not stop:
>>
>> nscd -> kills some performance and may unmask bugs;
>> makes it impossible to edit /etc/resolv.conf
>> or nsswitch.conf after booting and have
>> the changes take effect.
>
> How's that? Restarting your app must reinitialize the resolver, yes?

Restarting everything on the system that does gethostby* or getipnodeby*
calls will presumably do it; restarting one app may not be sufficient to
produce consistent results for everything running on the system. (even
restarting everything would be inconsistent during the time between
restarting the first thing and restarting the last)

nscd presumably monitors resolv.conf and nsswitch.conf for changes, and
reinitializes itself as much as needed to pick up the changes, and
transparently gives the benefit to all using the libs that talk to nscd if
it's running. So running nscd ensures consistent results without a reboot
in a way that nothing else does.

The only reason I can see to worry about nscd is if it's a version that's
got reliability problems (possible denial of service) or if there's
a name-service based buffer overflow attack (crafted malformed DNS reply,
for example).

If you were not running nscd, but had anything that ran with the same
privileges that did a name service lookup, you'd have the exact same
vulnerability there.

If nscd were modified to give up root whenever it didn't need it, I think
one might actually be safer to run it than not.

--
mailto:rlhamil@smart.net http://www.smart.net/~rlhamil

Lasik/PRK theme music:
"In the Hall of the Mountain King", from "Peer Gynt"

Casper H.S. Dik wrote:
>
> You should not/need not stop:
>
> nscd -> kills some performance and may unmask bugs;
> makes it impossible to edit /etc/resolv.conf
> or nsswitch.conf after booting and have
> the changes take effect.

That's far more an argument against running nscd than for it.
Without nscd, don't changes to resolv.conf and nsswitch.conf
go into effect within the next 60 seconds when the system
does a sync? If not, when was that abysmal change added? It
did not happen in Solaris 7 and back.

If performance is an issue, it's because your host is going
very many DNS lookups or other name service lookups. The best
way to fix that is to run a cache-only nameserver and list
iself in /etc/resolv.conf. The nameserver will cache all
repeat requests and correctly handle all new requests at least
as well as nscd.

In comp.unix.solaris Doug Freyburger <dfreybur@yahoo.com> wrote:
> Casper H.S. Dik wrote:
>>
>> You should not/need not stop:
>>
>> nscd -> kills some performance and may unmask bugs;
>> makes it impossible to edit /etc/resolv.conf
>> or nsswitch.conf after booting and have
>> the changes take effect.

> That's far more an argument against running nscd than for it.
> Without nscd, don't changes to resolv.conf and nsswitch.conf
> go into effect within the next 60 seconds when the system
> does a sync? If not, when was that abysmal change added? It
> did not happen in Solaris 7 and back.

Sync is irrelevant here. Yes, newly lauched programs (say, 'ping') will
will pick up the change. I believe the note was talking about programs
that were launched prior to the change, but looking up a host after the
change.

I'm not aware of any change in Solaris 7 or later in this behavior.

http://groups.google.com/groups?thre...ne ws.atx.net

--
Darren Dunham ddunham@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >

In comp.sys.sun.admin Doug Freyburger <dfreybur@yahoo.com> wrote:
> Casper H.S. Dik wrote:
>>
>> You should not/need not stop:
>>
>> nscd -> kills some performance and may unmask bugs;
>> makes it impossible to edit /etc/resolv.conf
>> or nsswitch.conf after booting and have
>> the changes take effect.
>
> That's far more an argument against running nscd than for it.
> Without nscd, don't changes to resolv.conf and nsswitch.conf
> go into effect within the next 60 seconds when the system
> does a sync? If not, when was that abysmal change added? It
> did not happen in Solaris 7 and back.
>
> If performance is an issue, it's because your host is going
> very many DNS lookups or other name service lookups. The best
> way to fix that is to run a cache-only nameserver and list
> iself in /etc/resolv.conf. The nameserver will cache all
> repeat requests and correctly handle all new requests at least
> as well as nscd.

Your argument would be correct if nameservers do more then host-IP or
IP-host lookups (which they don't), or nscd would only cache those,
which is doesn't. Nscd cache's naming services lookup in a much broader
sence then you think: it also caches username to usernumber, groupname
to groupnumber, service-name to service-number etc. and the other way
around. Now look at /etc/nsswitch.conf and all it's 'databases' instead
of just "host", and imagine al this information being centrally
administrered in say an LDAP server. Now don't cache this information
(i.e. disable nscd) and do an "ls -l" of a directory with lots of files
owned by lots of different users: For every file "ls" will need to do a
usernumber to username, and a groupnumber to groupname lookup. Imagine
this is done on a LDAP server with a Secure LDAP connection. To establish
the connection you need to verify the certificate. Of course you have the
LDAP-servers IP in your configuration (not it's name, it's your DNS-server
too), but the certificate has "host.subdomain.domain". To verify that you'll
need a lookup in the hosts database on the LDAP-server. So that's 2 lookups
for the usernumber (certificate check and usernumber query itself) and
another 2 for the group (certificate check again, not caching anything
are you?), so 4 per file.....

I don't think I need to go into this anymore to make the point that this
information should be cached (assuming DNS is not your only centrally
administered naming service). This is apart from the other arguments already
mentioned.

HTH, Erik
BTW: I don't know if the above illustration has the exact number of queries
per file for "ls -l", it's just an illustration of the point (I do know
that logins to a Solaris 8 machine with an LDAP-administered account use
about 20 queries without RBAC, and over 40 with if you disable the caching).

In article <4162a01d$0$10528$e4fe514c@news.xs4all.nl>, Casper H.S. Dik <Casper.Dik@Sun.COM> writes:
> Frank Cusack <fcusack@fcusack.com> writes:
>
> >On 02 Oct 2004 09:41:49 GMT Casper H.S. Dik <Casper.Dik@Sun.COM> wrote:
> >> You should not/need not stop:
> >>
> >> nscd -> kills some performance and may unmask bugs;
> >> makes it impossible to edit /etc/resolv.conf
> >> or nsswitch.conf after booting and have
> >> the changes take effect.
>
> >How's that? Restarting your app must reinitialize the resolver, yes?
>
> Yes; but that is not always an option; the nice thing about nscd
> is that you can change the hostname lookup methods and configuration
> without having to restart long running applications.
>
> (There are also some known bugs in various name lookup codes
> which are masked when nscd runs)
>
> Casper

On the other hand, nscd introduces its own bugs.
1. We have experienced a rare loss of certain host names: the system
suddenly insists in "host unknown", until nscd is killed.
2. We have moved from NIS to LDAP to overcome the NIS limits of data
records. But nscd has the same limits as NIS, so must be disabled in
order to enjoy this LDAP benefit.

--
Michael Tosch
IT Specialist
HP Managed Services
Technology Solutions Group
Hewlett-Packard GmbH
Phone: +49 2407 575 313
Mail: michael.tosch:hp.com

dfreybur@yahoo.com (Doug Freyburger) writes:

>That's far more an argument against running nscd than for it.
>Without nscd, don't changes to resolv.conf and nsswitch.conf
>go into effect within the next 60 seconds when the system
>does a sync? If not, when was that abysmal change added? It
>did not happen in Solaris 7 and back.

No, without nscd changes *never* go into effect, except for
new applications.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

On 05 Oct 2004 13:22:37 GMT Casper H.S. Dik <Casper.Dik@Sun.COM> wrote:
> Frank Cusack <fcusack@fcusack.com> writes:
>
>>On 02 Oct 2004 09:41:49 GMT Casper H.S. Dik <Casper.Dik@Sun.COM> wrote:
>>> You should not/need not stop:
>>>
>>> nscd -> kills some performance and may unmask bugs;
>>> makes it impossible to edit /etc/resolv.conf
>>> or nsswitch.conf after booting and have
>>> the changes take effect.
>
>>How's that? Restarting your app must reinitialize the resolver, yes?
>
> Yes; but that is not always an option; the nice thing about nscd
> is that you can change the hostname lookup methods and configuration
> without having to restart long running applications.
>
> (There are also some known bugs in various name lookup codes
> which are masked when nscd runs)

Agreed on both points, however nscd introduces its own problems w.r.t.
host resolution. One no one has yet mentioned is that it doesn't
honor TTL. This was a "dumb" implementation choice (and dumb of Linux
to copy) although I understand the value of simple. This is such an
issue at every place I've ever been that nscd for hostname caching is
always a no-no. If we need hostnames to be cached we run a local
caching nameserver.

OTOH, with ldap nscd is a requirement.

/fc

On 05 Oct 2004 19:41:09 GMT Casper H.S. Dik <Casper.Dik@Sun.COM> wrote:
> No, without nscd changes *never* go into effect, except for
> new applications.

Although a smarter resolver library would fix that.

/fc