Victor Duchovni:
> On Thu, Apr 28, 2011 at 12:50:57PM -0400, Wietse Venema wrote:
>
> > Victor Duchovni:
> > > On Wed, Apr 27, 2011 at 08:55:53PM -0400, Wietse Venema wrote:
> > >
> > > > Of course, I could simply mandate that people run only the latest
> > > > systems and that they always set al
On Thu, Apr 28, 2011 at 12:50:57PM -0400, Wietse Venema wrote:
> Victor Duchovni:
> > On Wed, Apr 27, 2011 at 08:55:53PM -0400, Wietse Venema wrote:
> >
> > > Of course, I could simply mandate that people run only the latest
> > > systems and that they always set all the flags that disable SUN,
>
Victor Duchovni:
> On Wed, Apr 27, 2011 at 08:55:53PM -0400, Wietse Venema wrote:
>
> > Of course, I could simply mandate that people run only the latest
> > systems and that they always set all the flags that disable SUN,
> > SGI etc. default backwards compatibility (meaning it may not work
> > w
On Wed, Apr 27, 2011 at 08:55:53PM -0400, Wietse Venema wrote:
> Of course, I could simply mandate that people run only the latest
> systems and that they always set all the flags that disable SUN,
> SGI etc. default backwards compatibility (meaning it may not work
> with third-party libraries tha
Timo Sirainen:
> On 27.4.2011, at 18.04, Wietse Venema wrote:
>
> >> I think the POSIX API works in all OSes commonly used nowadays. FreeBSD
> >> 5.1, NetBSD 3.0, OpenBSD 4.4, Solaris 5(?), OS X (some version), Linux
> >> for last 5+ years.
> >> I wrote some wrappers for these and people haven't c
On 27.4.2011, at 18.04, Wietse Venema wrote:
>> I think the POSIX API works in all OSes commonly used nowadays. FreeBSD
>> 5.1, NetBSD 3.0, OpenBSD 4.4, Solaris 5(?), OS X (some version), Linux
>> for last 5+ years.
>> I wrote some wrappers for these and people haven't complained about them
>> muc
Timo Sirainen:
> On Wed, 2011-04-27 at 07:19 -0400, Wietse Venema wrote:
> > > It is clear. getpwnam_r() returns 0 both on success and "user not
> > > found", you just need to check if the result is NULL or not. If
> > > it returns anything else than 0 it's a transient error. If the
> > > NSS code
On Wed, 2011-04-27 at 07:19 -0400, Wietse Venema wrote:
> > It is clear. getpwnam_r() returns 0 both on success and "user not
> > found", you just need to check if the result is NULL or not. If
> > it returns anything else than 0 it's a transient error. If the
> > NSS code internally messes this up
On Wed, Apr 27, 2011 at 07:19:42AM -0400, Wietse Venema wrote:
> Just because a system has getpwnam_r(), that does not mean it works
> like your API; and on some systems, getpwnam() does report errors
> via errno (e.g. FreeBSD8), whereas the original UNIX getpwnam()
> never returned for transient
Timo Sirainen:
> On 27.4.2011, at 0.53, Victor Duchovni wrote:
>
> >> Just wondering: Is it really the nss-ldap code that is buggy or just
> >> the libc's getpwnam() call that is fundamentally broken? I recently
> >> changed Dovecot to use getpwnam_r() instead, since it allows proper
> >> error ch
Victor Duchovni:
> On Tue, Apr 26, 2011 at 05:19:13PM -0400, Wietse Venema wrote:
>
> > diff -cr -C4 src/local/bounce_workaround.c src/local/bounce_workaround.c
> > *** src/local/bounce_workaround.c Sat Feb 13 21:00:24 2010
> > --- src/local/bounce_workaround.c Tue Apr 26 16:44:22 2011
> > ***
Timo Sirainen:
> On 27.4.2011, at 0.53, Victor Duchovni wrote:
>
> >> Just wondering: Is it really the nss-ldap code that is buggy or just
> >> the libc's getpwnam() call that is fundamentally broken? I recently
> >> changed Dovecot to use getpwnam_r() instead, since it allows proper
> >> error ch
On 27.4.2011, at 0.53, Victor Duchovni wrote:
>> Just wondering: Is it really the nss-ldap code that is buggy or just
>> the libc's getpwnam() call that is fundamentally broken? I recently
>> changed Dovecot to use getpwnam_r() instead, since it allows proper
>> error checking.
>
> Most likely a
On Wed, Apr 27, 2011 at 12:34:43AM +0300, Timo Sirainen wrote:
> > This is a bug in the SYSTEM NSS LDAP client. The SYSTEM NSS LDAP
> > client works incorrectly: when the LDAP server fails to respond,
> > the SYSTEM NSS LDAP client returns a NOTFOUND result.
>
> Just wondering: Is it really the n
On 26.4.2011, at 15.44, Wietse Venema wrote:
>> However, for mail that originates on the mail host, e.g. by mail(1),
>> when an LDAP outage causes local users to disappear (getent passwd
>> username returns no results with exit code 2) local bounces the mail as
>> user unknown. While this is not s
On Tue, Apr 26, 2011 at 05:19:13PM -0400, Wietse Venema wrote:
> diff -cr -C4 src/local/bounce_workaround.c src/local/bounce_workaround.c
> *** src/local/bounce_workaround.c Sat Feb 13 21:00:24 2010
> --- src/local/bounce_workaround.c Tue Apr 26 16:44:22 2011
> ***
> *** 96,126
William Ono:
> I was hoping that setting mailbox_transport_maps to the same LDAP map as
> local_recipient_maps would cause local to tempfail rather than bounce in
> this case. It turns out that it does not.
The same error happens in mailbox_command_maps, mailbox_transport_maps,
and fallback_transp
William Ono:
> On Tue, Apr 26, 2011 at 08:44:05AM -0400, Wietse Venema wrote:
> > That is because the POSTFIX LDAP client queries the LDAP server.
> > The POSTFIX LDAP client works correctly: when the LDAP server fails
> > to respond, the POSTFIX LDAP client returns a temporary error.
> >
> > > Ho
On Tue, Apr 26, 2011 at 08:44:05AM -0400, Wietse Venema wrote:
> That is because the POSTFIX LDAP client queries the LDAP server.
> The POSTFIX LDAP client works correctly: when the LDAP server fails
> to respond, the POSTFIX LDAP client returns a temporary error.
>
> > However, for mail that orig
William Ono:
> Hello all,
>
> Yes, this again. I promise it's slightly different this time.
>
> I have users in LDAP and they're brought in as local users by
> libnss-ldapd. With local_recipient_maps set to use a LDAP map instead of
> unix:passwd.byname, smtpd correctly tempfails incoming mail wh
On Apr 25, 2011, at 10:22 PM, William Ono wrote:
> Hello all,
>
> Yes, this again. I promise it's slightly different this time.
>
> I have users in LDAP and they're brought in as local users by
> libnss-ldapd. With local_recipient_maps set to use a LDAP map instead of
> unix:passwd.byname, smtp
Hello all,
Yes, this again. I promise it's slightly different this time.
I have users in LDAP and they're brought in as local users by
libnss-ldapd. With local_recipient_maps set to use a LDAP map instead of
unix:passwd.byname, smtpd correctly tempfails incoming mail when the
LDAP service is unav
22 matches
Mail list logo
