Ubuntu

DNS hostname lookups fail in chroot after natty upgrade

Reported by Kenyon Ralph on 2011-04-17
70
This bug affects 14 people
Affects Status Importance Assigned to Milestone
postfix (Ubuntu)
High
Steve Langasek
Natty
High
Steve Langasek
Oneiric
High
Steve Langasek

Bug Description

SRU justification: the postfix package in natty runs in a chroot by default, but does not know to copy nss modules from the multiarch library paths to set up the chroot. As a result, various sorts of NSS resolution, such as mapping port names to numbers or resolving the hostnames of incoming connections, will fail. This will break postfix in various common configurations.

TEST CASE:
1. install postfix and configure it to use a smart host, specifying only a hostname (no port) for the smart host.
2. verify that there is no /var/spool/postfix/lib/<triplet> directory.
3. send mail and verify that the mail delivery fails because postfix can't resolve 'smtp' to a port number.
4. upgrade postfix to the SRU version
5. verify that after upgrade, there is a /var/spool/postfix/lib/<triplet> directory
6. send mail and verify that it now can be sent to the smarthost successfully.

Risk of regression: if I've done something wrong and the tar command fails under certain conditions, postfix will fail to start.

Binary package hint: postfix

I haven't yet determined the cause of this, but after upgrading to natty from maverick, postfix smtpd DNS lookups always fail when running in chroot (which is the default). This can be seen by lines like "postfix/smtpd[12287]: connect from unknown" in mail.log, where unknown should be the hostname. After editing master.cf so that smtpd is not in a chroot, hostname lookups work normally, as can be seen in mail.log.

There were no changes in my configuration other than upgrading from maverick to natty. Hostname lookups worked fine in chroot with maverick.

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: postfix 2.8.2-1ubuntu1
ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2
Uname: Linux 2.6.38-8-generic i686
Architecture: i386
Date: Sun Apr 17 16:46:24 2011
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/sh
SourcePackage: postfix
UpgradeStatus: Upgraded to natty on 2011-04-16 (1 days ago)

Kenyon Ralph (kralph) wrote :
Andreas Roth (aroth) wrote :

I'm using LDAP maps for aliases, but since i upgraded to natty the LDAP lookup does not anymore, since i get the following error messages from postfix:
Apr 30 13:37:22 host postfix/cleanup[30160]: dict_ldap_debug: ldap_connect_to_host: TCP ldapmaster.domain.com:389
Apr 30 13:37:22 host postfix/cleanup[30160]: dict_ldap_debug: ldap_connect_to_host: getaddrinfo failed: Name or service not known
Apr 30 13:37:22 host postfix/cleanup[30160]: dict_ldap_debug: ldap_err2string
Apr 30 13:37:22 host postfix/cleanup[30160]: warning: dict_ldap_lookup: Search error -1: Can't contact LDAP server
Apr 30 13:37:22 host postfix/cleanup[30160]: warning: AF28B226A2: sender_canonical_maps map lookup problem for <email address hidden>

Changed in postfix (Ubuntu):
status: New → Confirmed
Changed in postfix (Ubuntu):
importance: Undecided → High
Tom (tom-sogetthis) wrote :

I found it!

/etc/init.d/postfix:

replace these two lines:

rm -f lib/libnss_*so*
tar cf - /lib/libnss_*so* 2>/dev/null |tar xf -

with these two:

rm -f lib/x86_64-linux-gnu/libnss_*so*
tar cf - /lib/x86_64-linux-gnu/libnss_*so* 2>/dev/null |tar xf -

My fix is specific for x64 architecture, change it if you use x86.
It should be possible to create architecture independent fix, but I don't know how.

On 2011-05-01T07:13:14-0000, Tom <email address hidden> wrote:
> I found it!
>
> /etc/init.d/postfix:
>
> replace these two lines:
>
> rm -f lib/libnss_*so*
> tar cf - /lib/libnss_*so* 2>/dev/null |tar xf -
>
> with these two:
>
> rm -f lib/x86_64-linux-gnu/libnss_*so*
> tar cf - /lib/x86_64-linux-gnu/libnss_*so* 2>/dev/null |tar xf -
>
> My fix is specific for x64 architecture, change it if you use x86.
> It should be possible to create architecture independent fix, but I don't know how.

Nice! On my i386 natty machine, this is the pattern:
/lib/i386-linux-gnu/libnss_*so*

I think the architecture independent fix would include a call to
dpkg-architecture. dpkg-architecture returns this on my Ubuntu natty
system:

DEB_BUILD_ARCH=i386
DEB_BUILD_ARCH_OS=linux
DEB_BUILD_ARCH_CPU=i386
DEB_BUILD_ARCH_BITS=32
DEB_BUILD_ARCH_ENDIAN=little
DEB_BUILD_GNU_CPU=i686
DEB_BUILD_GNU_SYSTEM=linux-gnu
DEB_BUILD_GNU_TYPE=i686-linux-gnu
DEB_BUILD_MULTIARCH=i386-linux-gnu
DEB_HOST_ARCH=i386
DEB_HOST_ARCH_OS=linux
DEB_HOST_ARCH_CPU=i386
DEB_HOST_ARCH_BITS=32
DEB_HOST_ARCH_ENDIAN=little
DEB_HOST_GNU_CPU=i686
DEB_HOST_GNU_SYSTEM=linux-gnu
DEB_HOST_GNU_TYPE=i686-linux-gnu
DEB_HOST_MULTIARCH=i386-linux-gnu

So DEB_HOST_MULTIARCH would be correct. But my Debian squeeze x86_64
system doesn't have MULTIARCH variables, this is its output:

DEB_BUILD_ARCH=amd64
DEB_BUILD_ARCH_OS=linux
DEB_BUILD_ARCH_CPU=amd64
DEB_BUILD_ARCH_BITS=64
DEB_BUILD_ARCH_ENDIAN=little
DEB_BUILD_GNU_CPU=x86_64
DEB_BUILD_GNU_SYSTEM=linux-gnu
DEB_BUILD_GNU_TYPE=x86_64-linux-gnu
DEB_HOST_ARCH=amd64
DEB_HOST_ARCH_OS=linux
DEB_HOST_ARCH_CPU=amd64
DEB_HOST_ARCH_BITS=64
DEB_HOST_ARCH_ENDIAN=little
DEB_HOST_GNU_CPU=x86_64
DEB_HOST_GNU_SYSTEM=linux-gnu
DEB_HOST_GNU_TYPE=x86_64-linux-gnu

I guess this change will have to go into the Debian package too, since
Debian will have multiarch support eventually:
http://wiki.debian.org/Multiarch

--
Kenyon Ralph

Steve Langasek (vorlon) on 2011-05-02
Changed in postfix (Ubuntu):
assignee: nobody → Steve Langasek (vorlon)
tags: added: regression-release
Changed in postfix (Ubuntu Natty):
status: New → Confirmed
importance: Undecided → High
milestone: none → natty-updates
Kevin Sumner (kevin-sumner) wrote :

This simple patch has fixed my problems, at least temporarily:

--- /etc/init.d/postfix.distrib 2011-05-03 15:33:19.000000000 +0000
+++ /etc/init.d/postfix 2011-05-03 15:35:27.000000000 +0000
@@ -139,8 +139,8 @@
                rm -f usr/lib/zoneinfo/localtime
                mkdir -p usr/lib/zoneinfo
                ln -sf /etc/localtime usr/lib/zoneinfo/localtime
- rm -f lib/libnss_*so*
- tar cf - /lib/libnss_*so* 2>/dev/null |tar xf -
+ rm -f lib/libnss_*so* lib/*/libnss_*so*
+ tar cf - /lib/libnss_*so* /lib/*/libnss_*so* 2>/dev/null |tar xf -
                umask $oldumask
            fi

Kevin Sumner (kevin-sumner) wrote :

I probably shouldn't post patches in my comments. :) Here's the actual file.

tags: added: patch
Steve Langasek (vorlon) on 2011-05-04
Changed in postfix (Ubuntu Natty):
assignee: nobody → Steve Langasek (vorlon)
Steve Langasek (vorlon) on 2011-05-05
description: updated
Changed in postfix (Ubuntu Natty):
status: Confirmed → In Progress
Changed in postfix (Ubuntu Oneiric):
status: Confirmed → In Progress

Accepted postfix into natty-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in postfix (Ubuntu Natty):
status: In Progress → Fix Committed
tags: added: verification-needed
Malac (malacusp) wrote :

Just fell foul of this bug myself.
Upgraded to Natty suddenly no mail out.
Thanks for posting the fix seems to have sorted the problem.
Can't believe this was released with this bug. But then I supposed that's the nature of bugs, they're things people haven't noticed. :)
Thanks again, launchpad saved my bacon...again.

Scott Kitterman (kitterman) wrote :

I suffered from the rDNS lookup failure in the duplicate and I confirm that's fixed.

Log entry with ...ubuntu1:

May 1 09:08:36 mailout00 postfix/smtpd[30503]: connect from unknown[72.81.252.21]
May 1 09:08:36 mailout00 postfix/smtpd[30503]: setting up TLS connection from unknown[72.81.252.21]
May 1 09:08:36 mailout00 postfix/smtpd[30503]: Anonymous TLS connection established from unknown[72.81.252.21]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)
May 1 09:08:36 mailout00 postfix/smtpd[30503]: C2BD638C0FA: client=unknown[72.81.252.21]

Log entry with ...ubuntu2:

May 5 07:02:52 mailout00 postfix/smtpd[25080]: connect from static-72-81-252-21.bltmmd.fios.verizon.net[72.81.252.21]
May 5 07:02:52 mailout00 postfix/smtpd[25080]: setting up TLS connection from static-72-81-252-21.bltmmd.fios.verizon.net[72.81.252.21]
May 5 07:02:53 mailout00 postfix/smtpd[25080]: Anonymous TLS connection established from static-72-81-252-21.bltmmd.fios.verizon.net[72.81.252.21]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)
May 5 07:02:53 mailout00 postfix/smtpd[25080]: 1981238C101: client=static-72-81-252-21.bltmmd.fios.verizon.net[72.81.252.21]

So that symptom is definitely fixed.

windracer (windracer) wrote :

After installing postfix/natty-proposed, my problem with the relayhost requiring the port has also been fixed. Thanks!

Martin Pitt (pitti) wrote :

As I specify an IP for relayhost in the configuration I never noticed a DNS problem. I confirm that with the version in -proposed, mail delivery still works fine for me.

tags: added: verification-done
removed: verification-needed
Martin Pitt (pitti) wrote :

For the record, waiving the 7 day period for this update. This will go into -updates tomorrow if there are no regression reports.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package postfix - 2.8.2-1ubuntu2

---------------
postfix (2.8.2-1ubuntu2) natty-proposed; urgency=low

  * debian/init.d: copy both /lib/libnss_*.so and /lib/*/libnss_*.so to the
    chroot; this is overbroad since it will pick up NSS modules for
    architectures other than our own, but avoids a runtime dep on dpkg-dev
    or build-time munging of the init script. Thanks to Kevin Sumner for
    the patch. LP: #764096.
 -- Steve Langasek <email address hidden> Wed, 04 May 2011 14:48:07 -0700

Changed in postfix (Ubuntu Natty):
status: Fix Committed → Fix Released
Martin Pitt (pitti) wrote :

Copied to oneiric as well.

Changed in postfix (Ubuntu Oneiric):
status: In Progress → Fix Released
Tom (tom-sogetthis) wrote :

I see the exact same problem again after upgrading from 11.10 to 12.04.

Tom (tom-sogetthis) wrote :

Sorry, false alarm, 12.04 is fine, must have been temporary DNS problems.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Related questions