local users: /etc/passwd vs ldap

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

local users: /etc/passwd vs ldap

paul sorenson-6
My Fedora 11 postfix installation won't recognise local recipients.  It
appears only to deliver to users found in /etc/passwd, those in the ldap
directory are treated as "unknown users".  On Fedora 10, same hardware,
same postfix configuration, I did not have this problem.

Initially, smptd rejected the mail, then with some help of folk on
#postfix, I added ldap to local_recipient_maps but now the local process
bounces these as "unknown users".

Logs and more background can be found at:

http://metrak.com/tmp/postfix-local.txt

Any suggestions on:

        a) How I could configure postfix to get around this

        b) Simple tests to establish this as a fedora issue (rule out postfix)

Would be greatly appreciated.

cheers
Reply | Threaded
Open this post in threaded view
|

Re: local users: /etc/passwd vs ldap

Barney Desmond
2009/7/5 paul sorenson <[hidden email]>:
> Logs and more background can be found at:
> http://metrak.com/tmp/postfix-local.txt

It's generally advisable to include this information in your email -
for the sake of the archives, but it removes the external dependency.
The level of detail on your linked page is good, excepting the
"verbose" logging (generally unwanted except on request).

My LDAP and NSS-fu is weak, but I have a couple of ideas.

> My Fedora 11 postfix installation won't recognise local recipients.  It
> appears only to deliver to users found in /etc/passwd, those in the ldap
> directory are treated as "unknown users".  On Fedora 10, same hardware,
> same postfix configuration, I did not have this problem.

Did you upgrade the configuration between installations? (I've no idea
what the version difference is between F10 and F11, and whether you've
copied in the files verbatim).
http://www.postfix.org/postfix.1.html

> Initially, smptd rejected the mail, then with some help of folk on
> #postfix, I added ldap to local_recipient_maps but now the local process
> bounces these as "unknown users".
>
> Any suggestions on:
>
>        a) How I could configure postfix to get around this
>
>        b) Simple tests to establish this as a fedora issue (rule out postfix)

"config #1 default local_recipient_maps":
LDAP isn't included, so you get "unknown user in local recipient table".

"# config #2 modified "local_recipient_maps ="": (I assume you meant
double quotes there, ie. empty value
By my reading, that disables local recipient verification entirely -
http://www.postfix.org/LOCAL_RECIPIENT_README.html
Mail is accepted for a local domain, then bounces because delivery fails.

"config #3 modified local_recipient_maps modified to use ldap:
local_recipient_maps = unix:passwd.byname
ldap:/etc/postfix/ldap-aliases.cf":
I believe that's correct. As it's still bouncing, it sounds like a
problem in the "local" agent, which you've provided logging for. I'm
personally stuck here, but I expect someone else has seen this problem
before.

> "The command "getent passwd <user>" returns the expected values for both users.  However
> "postmap -q <user> unix:passwd.byname" returns a result only for user pms.

This is expected - postmap doesn't exactly emulate how Postfix does
the lookups. Specifically, postfix will lookup all the necessary
tables, but manually invoking postmap queries only tests exactly what
you ask. You should get a result if you run `postmap -q bells
ldap:/etc/postfix/ldap-aliases.cf`. I expect that you do, given that
you're not getting the "unknown user in local recipient table" error.

Does removing procmail as the mailbox_command help? Does the "bells"
user's mailspool already exist? (for systems with locally-maintained
users, it's usually created at useradd time)
Reply | Threaded
Open this post in threaded view
|

Re: local users: /etc/passwd vs ldap

paul sorenson-6
Barney,

Thanks for your quick response.

On 05/07/09 19:45, Barney Desmond wrote:
> 2009/7/5 paul sorenson <[hidden email]>:
>> Logs and more background can be found at:
>> http://metrak.com/tmp/postfix-local.txt
>
> It's generally advisable to include this information in your email -
> for the sake of the archives, but it removes the external dependency.
> The level of detail on your linked page is good, excepting the
> "verbose" logging (generally unwanted except on request).

I tried to paste the text but my email client wrapped everything into a
godawful mess.

> My LDAP and NSS-fu is weak, but I have a couple of ideas.
>
>> My Fedora 11 postfix installation won't recognise local recipients.  It
>> appears only to deliver to users found in /etc/passwd, those in the ldap
>> directory are treated as "unknown users".  On Fedora 10, same hardware,
>> same postfix configuration, I did not have this problem.
>
> Did you upgrade the configuration between installations? (I've no idea
> what the version difference is between F10 and F11, and whether you've
> copied in the files verbatim).
> http://www.postfix.org/postfix.1.html

I used a graphical merge program to check my old config against the new
(there were no changes - maybe some comment lines).  I have since hacked
the config slightly so they are no longer identical.

>> Initially, smptd rejected the mail, then with some help of folk on
>> #postfix, I added ldap to local_recipient_maps but now the local process
>> bounces these as "unknown users".
>>
>> Any suggestions on:
>>
>>        a) How I could configure postfix to get around this
>>
>>        b) Simple tests to establish this as a fedora issue (rule out postfix)
>
> "config #1 default local_recipient_maps":
> LDAP isn't included, so you get "unknown user in local recipient table".

That's fair enough except that it used to work and I thought the
/etc/pam.d/smtp would take care of it.

> "# config #2 modified "local_recipient_maps ="": (I assume you meant
> double quotes there, ie. empty value
> By my reading, that disables local recipient verification entirely -
> http://www.postfix.org/LOCAL_RECIPIENT_README.html
> Mail is accepted for a local domain, then bounces because delivery fails.

correct

> "config #3 modified local_recipient_maps modified to use ldap:
> local_recipient_maps = unix:passwd.byname
> ldap:/etc/postfix/ldap-aliases.cf":
> I believe that's correct. As it's still bouncing, it sounds like a
> problem in the "local" agent, which you've provided logging for. I'm
> personally stuck here, but I expect someone else has seen this problem
> before.
>
>> "The command "getent passwd <user>" returns the expected values for both users.  However
>> "postmap -q <user> unix:passwd.byname" returns a result only for user pms.
>
> This is expected - postmap doesn't exactly emulate how Postfix does
> the lookups. Specifically, postfix will lookup all the necessary
> tables, but manually invoking postmap queries only tests exactly what
> you ask. You should get a result if you run `postmap -q bells
> ldap:/etc/postfix/ldap-aliases.cf`. I expect that you do, given that
> you're not getting the "unknown user in local recipient table" error.

[root@homer pam.d]# postmap -q bells ldap:/etc/postfix/ldap-aliases.cf
bells

> Does removing procmail as the mailbox_command help? Does the "bells"
> user's mailspool already exist? (for systems with locally-maintained
> users, it's usually created at useradd time)

procmail removed - no change
/var/mail/bells exists and writable by user and group mail.


Reply | Threaded
Open this post in threaded view
|

Re: local users: /etc/passwd vs ldap

Victor Duchovni
In reply to this post by Barney Desmond
On Sun, Jul 05, 2009 at 07:45:31PM +1000, Barney Desmond wrote:

> > "The command "getent passwd <user>" returns the expected values for both users.  However
> > "postmap -q <user> unix:passwd.byname" returns a result only for user pms.
>
> This is expected - [...]

No, this is not "expected". The "passwd.byname" lookup result is exactly
the result of the C-library getpwnam(3). If this is not working, that's
the problem. The output of

        getent passwd user
    and
    postmap -q user unix:passwd.byname

must be the same, or the underlying system is broken in some fashion.
The example below shows the two commands producing *identical* output,
hence a count of "2" from "uniq -c":

    $ (getent passwd viktor
       postmap -q viktor unix:passwd.byname) |
      sort |
      uniq -c |
      awk '{print $1}'
    2

The tests must be done as a non-root user to make sure that file
permissions don't restrict getpwnam(3) to the super-user.

--
        Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:[hidden email]?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
Reply | Threaded
Open this post in threaded view
|

Re: local users: /etc/passwd vs ldap

paul sorenson-6
On 05/07/09 22:37, Victor Duchovni wrote:

> On Sun, Jul 05, 2009 at 07:45:31PM +1000, Barney Desmond wrote:
>
>>> "The command "getent passwd <user>" returns the expected values for both users.  However
>>> "postmap -q <user> unix:passwd.byname" returns a result only for user pms.
>> This is expected - [...]
>
> No, this is not "expected". The "passwd.byname" lookup result is exactly
> the result of the C-library getpwnam(3). If this is not working, that's
> the problem. The output of
>
> getent passwd user
>     and
>     postmap -q user unix:passwd.byname
>
> must be the same, or the underlying system is broken in some fashion.
> The example below shows the two commands producing *identical* output,
> hence a count of "2" from "uniq -c":
>
>     $ (getent passwd viktor
>        postmap -q viktor unix:passwd.byname) |
>       sort |
>       uniq -c |
>       awk '{print $1}'
>     2
>
> The tests must be done as a non-root user to make sure that file
> permissions don't restrict getpwnam(3) to the super-user.
>

# user with ldap entry only:
[pms@homer domestic]$ (getent passwd bells; postmap -q bells
unix:passwd.byname) | sort |  uniq -c | awk '{print $1}'
1

# user with /etc/passwd entry
[pms@homer domestic]$ (getent passwd pms; postmap -q pms
unix:passwd.byname) | sort |  uniq -c | awk '{print $1}'
2

Any tips on how to dig deeper would be appreciated.  Would it be
premature to create a bug report for this?


Reply | Threaded
Open this post in threaded view
|

Re: local users: /etc/passwd vs ldap

Victor Duchovni
On Mon, Jul 06, 2009 at 08:45:15AM +1000, paul sorenson wrote:

> > The tests must be done as a non-root user to make sure that file
> > permissions don't restrict getpwnam(3) to the super-user.
> >
>
> # user with ldap entry only:
> [pms@homer domestic]$ (getent passwd bells; postmap -q bells
> unix:passwd.byname) | sort |  uniq -c | awk '{print $1}'
> 1

If getent(1) is returning results that are not found via getpwnam(3),
your C-library or nsswitch are broken. Trace the system calls made by
"postmap -q" and "getent" and see if anything interesting turns up.

Is LANG set to any particularly unusual value? Have you tried:

        LANG=C postmap -q bells unix:passwd.byname

> Any tips on how to dig deeper would be appreciated.  Would it be
> premature to create a bug report for this?

This is a non-Postfix problem, start with a question on the support
forum for your O/S.

--
        Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:[hidden email]?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
Reply | Threaded
Open this post in threaded view
|

Re: local users: /etc/passwd vs ldap

paul sorenson-6
On 06/07/09 15:08, Victor Duchovni wrote:

> On Mon, Jul 06, 2009 at 08:45:15AM +1000, paul sorenson wrote:
>
>>> The tests must be done as a non-root user to make sure that file
>>> permissions don't restrict getpwnam(3) to the super-user.
>>>
>> # user with ldap entry only:
>> [pms@homer domestic]$ (getent passwd bells; postmap -q bells
>> unix:passwd.byname) | sort |  uniq -c | awk '{print $1}'
>> 1
>
> If getent(1) is returning results that are not found via getpwnam(3),
> your C-library or nsswitch are broken. Trace the system calls made by
> "postmap -q" and "getent" and see if anything interesting turns up.

getent returns identical results to getpwnam(), I wrote a short program
to test this.

[pms@homer postfix]$ ./getpwname
fields from getpwnam("pms"):
pms:x:500:500:paul sorenson:/home/pms:/bin/bash
fields from getpwnam("bells"):
bells:x:503:503:Helen Sorenson:/home/bells:/bin/bash

[pms@homer postfix]$ getent passwd pms
pms:x:500:500:paul sorenson:/home/pms:/bin/bash
[pms@homer postfix]$ getent passwd bells
bells:x:503:503:Helen Sorenson:/home/bells:/bin/bash

>
> Is LANG set to any particularly unusual value? Have you tried:
>
> LANG=C postmap -q bells unix:passwd.byname

[pms@homer postfix]$ echo $LANG
en_AU.UTF-8

[pms@homer postfix]$ LANG=C postmap -q bells unix:passwd.byname
(no output)

>> Any tips on how to dig deeper would be appreciated.  Would it be
>> premature to create a bug report for this?
>
> This is a non-Postfix problem, start with a question on the support
> forum for your O/S.

Thanks for your help - the problem is solved.  Tracing through postmap,
libnss_ldap.so was not found.  Closer inspection revealed that this was
a 32 bit postfix package installed on a 64 bit system so it didn't look
in /usr/lib64.

I went back to yum and it seems that the 64 bit rpm is missing from the
repository.  I found one on rpmfind.net, installed it and badabing.

I will let the fedora guys know.

cheers

Reply | Threaded
Open this post in threaded view
|

Re: local users: /etc/passwd vs ldap

Victor Duchovni
On Mon, Jul 06, 2009 at 09:26:52PM +1000, paul sorenson wrote:

> > If getent(1) is returning results that are not found via getpwnam(3),
> > your C-library or nsswitch are broken. Trace the system calls made by
> > "postmap -q" and "getent" and see if anything interesting turns up.
>
> Thanks for your help - the problem is solved.  Tracing through postmap,
> libnss_ldap.so was not found.  Closer inspection revealed that this was
> a 32 bit postfix package installed on a 64 bit system so it didn't look
> in /usr/lib64.

So all 32-bit executables have a non-working getpwnam(3), when LDAP is
involved. This is broken, the solution is to install a 32-bit libnss_ldap.so,
you should not need a 64-bit Postfix (nothing wrong with 64-bit Postfix
of course, but it solves only part of the problem).

--
        Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:[hidden email]?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.