Bluehost.com Web Hosting $6.95

PATCH: Re: local_recipient_maps & NIS

This is a discussion on PATCH: Re: local_recipient_maps & NIS within the mailing.postfix.users forums, part of the Mail Servers and Related category; On Mon, 09 Feb 2004, Victor.Duchovni@morganstanley.com wrote: > On Mon, 9 Feb 2004, Matthias Andree wrote: > &...


Go Back   Usenet Forums > Mail Servers and Related > mailing.postfix.users

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 02-10-2004
Matthias Andree
 
Posts: n/a
Default PATCH: Re: local_recipient_maps & NIS

On Mon, 09 Feb 2004, Victor.Duchovni@morganstanley.com wrote:

> On Mon, 9 Feb 2004, Matthias Andree wrote:
>
> > Remedy (works for me on <ducks>SuSE Linux 8.2</ducks> but the NIS server
> > is the same as the Postfix server):
> >
> > * use "nis:" instead of "unix:" all over main.cf and make sure all users
> > who want to receive mail are listed either in NIS (or in alias_maps
> > and aliases to a NIS-listed account)
> >
> > dict_nis "handles" temporary errors, see
> > postfix-2.0.18-20040205/src/util/dict_nis.c lines 181ff.

>
> This will still fail when the local delivery agent is unable to find the
> user in the password map. The solution is to use a platform with a working
> NIS or to not use NIS.


I beg to differ (I did some practical research on that way back, please
look through the archives).

1. Assume Postfix uses unix: (default)

2. Assume the system is configured for traditional NIS compatibility
mode (however that manifests itself, +:::: in /etc/passwd or some
nsswitch.conf configuration, does not matter)

3. Assume that NIS client and server code are bug-free but concede that
there may be ypbind, ypserv or network trouble at any time.

4. unix: uses getpwnam() to figure if a user is present. getpwnam()
returns either the user data or NULL if either there was a problem or
the passwd entry was not found.

GLIBC manual pages make me think looking at the errno may bear some
hint as to the nature of the problem, ENOMEM, EIO, EINTR, ENFILE,
EMFILE, should in any case be treated as temporary (or ERANGE for
getpwnam_r).

GLIBC documents for errno "0 or ENOENT or ESRCH or EBADF or EPERM or ...
The given name or uid was not found."

Practically, errno is always 0 regardless of whether ypbind is dead,
ypserv is dead or either is running and the user is not found.

FreeBSD does not document errno behaviour for getpwnam().

5. nis: uses RPC to look up in the maps

6. Solaris' default nsswitch behaviour is to retry forever on
"TRYAGAIN" conditions. Quoting Solaris' nsswitch.conf:

"The default criteria for all other sources is [SUCCESS=return
NOTFOUND=continue UNAVAIL=continue TRYAGAIN=forever]."

"all other" means "anything except DNS when NIS is in DNS-forwarding
mode" - doesn't apply to our passwd lookup.

7. GNU glibc and FreeBSD getpwnam() will chat RPC just like Solaris
does, but they return NULL after some time when there is NIS trouble,
regardless what kind of trouble it is.

GLIBC has a nsswitch.conf but doesn't support a "try again" option
for a "TRYAGAIN" condition. You can abort (return NULL right away) or
continue (try other data sources, such as files). Talk about broken
as designed. FreeBSD, not having an nsswitch concept, has a hardwired
timeout and returns NULL after that time.

Consequence: when getpwnam() on Linux or FreeBSD does not convey any
information about the nature of the problem, whether the user was
missing from the map, NIS wasn't configured properly, the server
dropped dead, whatever.

8. Postfix' nis: map chats RPC and gets to know the nature of a problem
through a more detailed interface. It can tell domain not bound, no
domain set, map not found, key not in map and other conditions from
each other, unlike getpwnam().

9. A further complication is that Postfix' sanity checks are limited to
doing getpwuid(0) or getgrgid(0) - these will always work on my
systems since I'd never stuff the privileged account/group into NIS.

Solution: Configure Postfix to use a nis: map, this will log warnings
and TEMPORARILY reject mail. Just tested again to be sure, on SuSE Linux
8.2.

--
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95
Reply With Quote
Reply
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are Off
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On




All times are GMT +1. The time now is 07:36 AM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2009, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO 3.0.0