SUMMARY: Is "passwd: files compat" a valid configuration in nsswitch.conf?

From: Powell, Mark \(Harvey Nash\) <Mark.Powell_at_uk.bp.com>
Date: Thu Jan 04 2007 - 05:57:55 EST
Well, yes AND no...

but firstly: "thanks" to Marius Sicoie, Roland Merk, and Robert Murray
who kindly advised me that they were "Out of Office", and specially to
Postmaster@aubay.it who advised me my email was spam. ;-)

Genuine thanks to John Julian and Mike Adams for their helpful answers
and Special Thanks to Darren Dunham for the golden answer that sorted
the whole issue. (and therefore is owed the case of Dr Pepper!)

To summarise:
The addition of files before compat in the nsswitch.conf search order is
accepted and honoured but should NOT be necessary on a "neatly"
configured Solaris box. Quite simply (in the case of /etc/passwd &
related lookups) with the "compat" setting the file /etc/passwd is
ALWAYS going to be read but my problem came because the ORDER is
important. Sounds obvious to me now, but the lines in the /etc/passwd
file will be checked in the order in which they are encountered. So, if
the DB tokens (i.e. the "+@<NETGROUPNAME>:x:::::" entries in
/etc/passwd) that refer to NIS-netgroup-style entries are found BEFORE a
line containing the local "files" configuration they will be checked
before those lines later in the file. In my case I had some lines in
/etc/passwd like this type:

+@ldn-ops:x:::::

BEFORE lines specifically like this:

oracle:x:1019:100:oracle user:/export/home/oracle:/bin/ksh

and that was the cause of the constant LDAP searching.
The adding of "files" before compat worked because it forces the
/etc/passwd file to be read first as a "plain" file (non-Nis-style)
before "compat" reads it again in the NIS-compatible manner. Therefore
the answer is; it's honoured, it works, it temporarily fixed my problem
but it's a bit of a fudge and ideally isn't necessary if the order in
/etc/passwd is "correct" by having all the DB tokens at the end.

I asked:
---
> My question 'Is "passwd: files compat" a valid configuration in
> nsswitch.conf?' relates to a couple of things that made me ask this:
> On a Solaris 9 server (LDAP client) I recently experienced a very
heavy
> load from the client to the LDAP server. The reason being was that it
> was constantly resolving UID to username (could tell from LDAP logs)
for
> an Oracle user's script (FWIW did something like ps -ef...) and nscd
had
> died. Restarting nscd fixed the heavy load issue BUT, the strange
thing
> was that this was a service account (local application UID) defined in
> /etc/passwd (i.e. files), so shouldn't have to be resolved using LDAP.
> The system's nsswitch.conf is set "passwd: compat" with the following
> line set "passwd_compat: ldap". I wondered whether for performance
maybe
> the passwd line should be changed to read "passwd: files compat" so as
> to hit files first. However a couple of other admins here say that, on
> Solaris, the "compat" option uses files first.
> Supporting their view, in the man page for passwd(1) it states:
> "Failure to comply with the  configurations will  prevent  users from
> logging onto the system. The password update configurations are:
>         o  passwd: files
>         o  passwd: files ldap
>         o  passwd: compat (==> files ldap)
>      passwd_compat: ldap"
>
> The line "passwd: compat (==> files ldap)" does imply a link but is
that
> the same as a search order?
> I can see this configuration in nsswitch.conf has been referenced
before
> here on SunManagers:
> http://www.sunmanagers.org/pipermail/summaries/2004-October.txt but
> other than that I have not found reference to using the "passwd: files
> compat" name service search order on Solaris. (It seems popular on
Linux
> however...)
---

Thanks again and kind regards,

Mark Powell
G DCT GO UK&A EMDC UNIX
Support Team		+44 (0) 20 7579 7989
Desk			+44 (0) 20 7579 6279
Remedy			EMDC Ops Unix
Mail 			mark.powell@uk.bp.com
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
Received on Thu Jan 4 05:59:22 2007

This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:44:03 EST