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: > &...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
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 |