Loading ...
Sorry, an error occurred while loading the content.

postfix and Berkeley DB

Expand Messages
  • LuKreme
    # ldd /usr/local/libexec/postfix/smtpd /usr/local/libexec/postfix/smtpd: libmysqlclient.so.16 = /usr/local/lib/mysql/libmysqlclient.so.16 (0x280cf000)
    Message 1 of 9 , Apr 11 3:35 PM
    View Source
    • 0 Attachment
      # ldd /usr/local/libexec/postfix/smtpd
      /usr/local/libexec/postfix/smtpd:
      libmysqlclient.so.16 => /usr/local/lib/mysql/libmysqlclient.so.16 (0x280cf000)
      libz.so.3 => /lib/libz.so.3 (0x28139000)
      libm.so.4 => /lib/libm.so.4 (0x2814a000)
      libssl.so.7 => /usr/local/lib/libssl.so.7 (0x28160000)
      libcrypto.so.7 => /usr/local/lib/libcrypto.so.7 (0x281ad000)
      libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x2830a000)
      libpcre.so.0 => /usr/local/lib/libpcre.so.0 (0x28321000)
      libc.so.6 => /lib/libc.so.6 (0x28354000)
      libcrypt.so.3 => /lib/libcrypt.so.3 (0x2843b000)
      # file /etc/postfix/virtual.db
      /etc/postfix/virtual.db: Berkeley DB 1.85 (Hash, version 2, native byte-order)

      So, postfix appears to be using Berkeley DB but is not linked against it?

      # cat /usr/local/bin/where
      #! /bin/bash
      for i in `ls /var/db/pkg | grep -i $1`; do echo $i "is in" `pkgdb -o $i`; done
      # where Berkeley
      p5-BerkeleyDB-0.41 is in databases/p5-BerkeleyDB databases/p5-BerkeleyDB
      #

      --
    • Reindl Harald
      ... unlikely generated with the build from the ldd-output libdb-5.3.so = /lib64/libdb-5.3.so (0x00007f28243c5000) rpm -q --file /lib64/libdb-5.3.so
      Message 2 of 9 , Apr 11 4:03 PM
      View Source
      • 0 Attachment
        Am 12.04.2013 00:35, schrieb LuKreme:
        > # ldd /usr/local/libexec/postfix/smtpd
        > /usr/local/libexec/postfix/smtpd:
        > libmysqlclient.so.16 => /usr/local/lib/mysql/libmysqlclient.so.16 (0x280cf000)
        > libz.so.3 => /lib/libz.so.3 (0x28139000)
        > libm.so.4 => /lib/libm.so.4 (0x2814a000)
        > libssl.so.7 => /usr/local/lib/libssl.so.7 (0x28160000)
        > libcrypto.so.7 => /usr/local/lib/libcrypto.so.7 (0x281ad000)
        > libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x2830a000)
        > libpcre.so.0 => /usr/local/lib/libpcre.so.0 (0x28321000)
        > libc.so.6 => /lib/libc.so.6 (0x28354000)
        > libcrypt.so.3 => /lib/libcrypt.so.3 (0x2843b000)
        > # file /etc/postfix/virtual.db
        > /etc/postfix/virtual.db: Berkeley DB 1.85 (Hash, version 2, native byte-order)
        > So, postfix appears to be using Berkeley DB but is not linked against it?

        unlikely generated with the build from the ldd-output

        libdb-5.3.so => /lib64/libdb-5.3.so (0x00007f28243c5000)

        rpm -q --file /lib64/libdb-5.3.so
        libdb-5.3.21-3.fc18.x86_64

        Name : libdb
        Arch : x86_64
        Version : 5.3.21
        Release : 3.fc18
        Size : 1.7 M
        Repo : installed
        Summary : The Berkeley DB database library for C
        URL : http://www.oracle.com/database/berkeley-db/
        License : BSD

        ldd /usr/libexec/postfix/smtpd
        linux-vdso.so.1 => (0x00007fff84780000)
        libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f28257d2000)
        libmysqlclient.so.18 => /usr/lib64/mysql/libmysqlclient.so.18 (0x00007f28252db000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f2824fd9000)
        libsasl2.so.2 => /lib64/libsasl2.so.2 (0x00007f2824dbe000)
        libssl.so.10 => /lib64/libssl.so.10 (0x00007f2824b55000)
        libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f2824779000)
        libdb-5.3.so => /lib64/libdb-5.3.so (0x00007f28243c5000)
        libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f28241ac000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f2823f92000)
        libgomp.so.1 => /lib64/libgomp.so.1 (0x00007f2823d83000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f2823b67000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f28237ae000)

        libz.so.1 => /lib64/libz.so.1 (0x00007f2823596000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f2823392000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f2823189000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f2822e86000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f2822c4f000)
        libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f2822a0b000)
        libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f2822726000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f2822522000)
        libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f28222f6000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f2825cde000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f28220e0000)
        libfreebl3.so => /lib64/libfreebl3.so (0x00007f2821e73000)
        libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f2821c68000)
        libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f2821a64000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f2821841000)
      • LuKreme
        Reindl Harald opined on Thursday 11-Apr-2013@17:03:50 ... I don’t understand what you mean. That is the output of my mailserver running postfix 2.8 ... Well,
        Message 3 of 9 , Apr 11 5:00 PM
        View Source
        • 0 Attachment
          Reindl Harald opined on Thursday 11-Apr-2013@17:03:50
          >
          >
          > Am 12.04.2013 00:35, schrieb LuKreme:
          >> # ldd /usr/local/libexec/postfix/smtpd
          >> /usr/local/libexec/postfix/smtpd:
          >> libmysqlclient.so.16 => /usr/local/lib/mysql/libmysqlclient.so.16 (0x280cf000)
          >> libz.so.3 => /lib/libz.so.3 (0x28139000)
          >> libm.so.4 => /lib/libm.so.4 (0x2814a000)
          >> libssl.so.7 => /usr/local/lib/libssl.so.7 (0x28160000)
          >> libcrypto.so.7 => /usr/local/lib/libcrypto.so.7 (0x281ad000)
          >> libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x2830a000)
          >> libpcre.so.0 => /usr/local/lib/libpcre.so.0 (0x28321000)
          >> libc.so.6 => /lib/libc.so.6 (0x28354000)
          >> libcrypt.so.3 => /lib/libcrypt.so.3 (0x2843b000)
          >> # file /etc/postfix/virtual.db
          >> /etc/postfix/virtual.db: Berkeley DB 1.85 (Hash, version 2, native byte-order)
          >> So, postfix appears to be using Berkeley DB but is not linked against it?
          >
          > unlikely generated with the build from the ldd-output

          I don’t understand what you mean. That is the output of my mailserver running postfix 2.8

          > libdb-5.3.so => /lib64/libdb-5.3.so (0x00007f28243c5000)
          >
          > rpm -q --file /lib64/libdb-5.3.so
          > libdb-5.3.21-3.fc18.x86_64

          Well, I do have libdb.so:

          # locate libdb.so
          /usr/local/lib/db42/libdb.so
          /usr/local/lib/db44/libdb.so
          /usr/local/lib/db48/libdb.so

          > libdb-5.3.so => /lib64/libdb-5.3.so (0x00007f28243c5000)

          And I was expecting a line like that, only "libdb.so => /usr/local/lib/db48/libdv.so", only it is not there. Postfix seems to be using it anyway, though I am not sure which version of libdb corresponds to Berkeley DB 1.85. I’m pretty sure it is not 4.8.


          --
          "@Drhorrible is not following you" Whew! that's a relief, I was sure
          some super villain was following me. Hope it's not Dick Cheney.
        • Reindl Harald
          ... i can not imagine that this file is created by the postfix of which you posted the ld-output because it is not linked against it ... which doe snot matter
          Message 4 of 9 , Apr 11 5:09 PM
          View Source
          • 0 Attachment
            Am 12.04.2013 02:00, schrieb LuKreme:
            > Reindl Harald opined on Thursday 11-Apr-2013@17:03:50
            >>
            >>
            >> Am 12.04.2013 00:35, schrieb LuKreme:
            >>> # ldd /usr/local/libexec/postfix/smtpd
            >>> /usr/local/libexec/postfix/smtpd:
            >>> libmysqlclient.so.16 => /usr/local/lib/mysql/libmysqlclient.so.16 (0x280cf000)
            >>> libz.so.3 => /lib/libz.so.3 (0x28139000)
            >>> libm.so.4 => /lib/libm.so.4 (0x2814a000)
            >>> libssl.so.7 => /usr/local/lib/libssl.so.7 (0x28160000)
            >>> libcrypto.so.7 => /usr/local/lib/libcrypto.so.7 (0x281ad000)
            >>> libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x2830a000)
            >>> libpcre.so.0 => /usr/local/lib/libpcre.so.0 (0x28321000)
            >>> libc.so.6 => /lib/libc.so.6 (0x28354000)
            >>> libcrypt.so.3 => /lib/libcrypt.so.3 (0x2843b000)
            >>> # file /etc/postfix/virtual.db
            >>> /etc/postfix/virtual.db: Berkeley DB 1.85 (Hash, version 2, native byte-order)
            >>> So, postfix appears to be using Berkeley DB but is not linked against it?
            >>
            >> unlikely generated with the build from the ldd-output
            >
            > I don’t understand what you mean. That is the output of my mailserver running postfix 2.8

            i can not imagine that this file is created by the postfix
            of which you posted the ld-output because it is not linked
            against it

            >> libdb-5.3.so => /lib64/libdb-5.3.so (0x00007f28243c5000)
            >>
            >> rpm -q --file /lib64/libdb-5.3.so
            >> libdb-5.3.21-3.fc18.x86_64
            >
            > Well, I do have libdb.so:
            >
            > # locate libdb.so
            > /usr/local/lib/db42/libdb.so
            > /usr/local/lib/db44/libdb.so
            > /usr/local/lib/db48/libdb.so

            which doe snot matter because it depends how postfix was compiled

            >> libdb-5.3.so => /lib64/libdb-5.3.so (0x00007f28243c5000)
            >
            > And I was expecting a line like that, only "libdb.so => /usr/local/lib/db48/libdv.so", only it is not there.
            > Postfix seems to be using it anyway

            postconf -m
            btree (berkeley)
            cidr
            environ
            fail
            hash (berkeley)
            internal
            memcache
            mysql

            nis

            pcre
            proxy
            regexp
            socketmap
            static
            tcp
            texthash
            unix

            http://www.postfix.org/DB_README.html

            > though I am not sure which version of libdb corresponds to Berkeley DB 1.85. I’m pretty sure it is not 4.8

            the 1.85 is not the libdb version, the file command is generic
          • Sahil Tandon
            ... So, you did not explicitly link against a non-default DB library. ... As documented, Postfix uses the default Berkeley DB version that ships with your
            Message 5 of 9 , Apr 11 6:37 PM
            View Source
            • 0 Attachment
              On Thu, 2013-04-11 at 16:35:28 -0600, LuKreme wrote:

              > # ldd /usr/local/libexec/postfix/smtpd
              > /usr/local/libexec/postfix/smtpd:
              > libmysqlclient.so.16 => /usr/local/lib/mysql/libmysqlclient.so.16 (0x280cf000)
              > libz.so.3 => /lib/libz.so.3 (0x28139000)
              > libm.so.4 => /lib/libm.so.4 (0x2814a000)
              > libssl.so.7 => /usr/local/lib/libssl.so.7 (0x28160000)
              > libcrypto.so.7 => /usr/local/lib/libcrypto.so.7 (0x281ad000)
              > libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x2830a000)
              > libpcre.so.0 => /usr/local/lib/libpcre.so.0 (0x28321000)
              > libc.so.6 => /lib/libc.so.6 (0x28354000)
              > libcrypt.so.3 => /lib/libcrypt.so.3 (0x2843b000)

              So, you did not explicitly link against a non-default DB library.

              > # file /etc/postfix/virtual.db
              > /etc/postfix/virtual.db: Berkeley DB 1.85 (Hash, version 2, native byte-order)
              >
              > So, postfix appears to be using Berkeley DB but is not linked against it?

              As documented, Postfix uses the default Berkeley DB version that ships
              with your system, which I am assuming is FreeBSD. You can alter this
              behavior by explicitly linking against a different, non-default DB
              version, which would then appear in ldd(1) output. Or, you can disable
              Berkeley DB support entirely by including -DNO_DB in CCARGS.

              --
              Sahil Tandon
            • LuKreme
              ... I assure you it is. This is exactly why I am puzzled, though Sahil may have provided the answer (see below) I built postfix with: make -f Makefile.init
              Message 6 of 9 , Apr 12 4:10 AM
              View Source
              • 0 Attachment
                In our previous episode (Thursday, 11-Apr-2013), Reindl Harald said:
                > i can not imagine that this file is created by the postfix
                > of which you posted the ld-output because it is not linked
                > against it

                I assure you it is. This is exactly why I am puzzled, though Sahil may have provided the answer (see below)

                I built postfix with:

                make -f Makefile.init makefiles 'CCARGS=-DHAS_MYSQL -DUSE_TLS -DUSE_SASL_AUTH -DUSE_CYRUS_SASL -I/usr/local/include/mysql -I/usr/local/include/sasl' 'AUXLIBS=-L/usr/local/lib/mysql -lmysqlclient -lz -lm -lssl -lcrypto -L/usr/local/lib -lsasl2'

                # postconf -m
                btree
                cidr
                environ
                hash
                internal
                mysql
                pcre
                proxy
                regexp
                static
                tcp
                texthash
                unix

                In our previous episode (Thursday, 11-Apr-2013), Sahil Tandon said:
                > As documented, Postfix uses the default Berkeley DB version that ships
                > with your system, which I am assuming is FreeBSD.

                Yes, FreeBSD VeryOld-stable.

                Then which of the libdb.so files on the system is postfix using?

                # locate libdb.so
                /usr/local/lib/db42/libdb.so
                /usr/local/lib/db44/libdb.so
                /usr/local/lib/db48/libdb.so

                I can recompile linking against the db48 version, as I assume that is the best choice.

                --
                'And I promise you this,' he [Carrot] shouted, 'if we succeed, no-one
                will remember. And if we fail, no one will forget!'
              • Wietse Venema
                LuKreme: [ Charset windows-1252 unsupported, converting... ] ... Which on FreeBSD uses the system berkeley DB 1.85. ... Yes if Postfix has to inter-operate
                Message 7 of 9 , Apr 12 4:21 AM
                View Source
                • 0 Attachment
                  LuKreme:
                  [ Charset windows-1252 unsupported, converting... ]
                  > In our previous episode (Thursday, 11-Apr-2013), Reindl Harald said:
                  > > i can not imagine that this file is created by the postfix
                  > > of which you posted the ld-output because it is not linked
                  > > against it
                  >
                  > I assure you it is. This is exactly why I am puzzled, though Sahil may have provided the answer (see below)
                  >
                  > I built postfix with:
                  >
                  > make -f Makefile.init makefiles 'CCARGS=-DHAS_MYSQL -DUSE_TLS -DUSE_SASL_AUTH -DUSE_CYRUS_SASL -I/usr/local/include/mysql -I/usr/local/include/sasl' 'AUXLIBS=-L/usr/local/lib/mysql -lmysqlclient -lz -lm -lssl -lcrypto -L/usr/local/lib -lsasl2'
                  >

                  Which on FreeBSD uses the system berkeley DB 1.85.

                  > Then which of the libdb.so files on the system is postfix using?
                  >
                  > # locate libdb.so
                  > /usr/local/lib/db42/libdb.so
                  > /usr/local/lib/db44/libdb.so
                  > /usr/local/lib/db48/libdb.so
                  >
                  > I can recompile linking against the db48 version, as I assume that is the best choice.
                  >

                  Yes if Postfix has to inter-operate with programs that insist on db48.

                  FreeBSD supports multiple Berkeley DB versions in the same program
                  (each version uses distinct function names internally, so there are
                  no DLL hell problems).

                  Wietse
                • Sahil Tandon
                  ... None. Postfix is using libc, which appears in your ldd(1) output, and contains the Berkeley DB 1.85 routines. ... These were installed via ports; not part
                  Message 8 of 9 , Apr 13 8:29 AM
                  View Source
                  • 0 Attachment
                    On Fri, 2013-04-12 at 05:10:09 -0600, LuKreme wrote:

                    > ...
                    > In our previous episode (Thursday, 11-Apr-2013), Sahil Tandon said:
                    > > As documented, Postfix uses the default Berkeley DB version that ships
                    > > with your system, which I am assuming is FreeBSD.
                    >
                    > Yes, FreeBSD VeryOld-stable.
                    >
                    > Then which of the libdb.so files on the system is postfix using?

                    None. Postfix is using libc, which appears in your ldd(1) output, and
                    contains the Berkeley DB 1.85 routines.

                    > # locate libdb.so
                    > /usr/local/lib/db42/libdb.so
                    > /usr/local/lib/db44/libdb.so
                    > /usr/local/lib/db48/libdb.so

                    These were installed via ports; not part of base system, and irrelevant
                    given the way you built Postfix.

                    --
                    Sahil Tandon
                  • LuKreme
                    ... Ah-hah, thank you for that. --
                    Message 9 of 9 , Apr 15 3:56 AM
                    View Source
                    • 0 Attachment
                      On 13 Apr 2013, at 09:29 , Sahil Tandon <sahil+postfix@...> wrote:

                      > None. Postfix is using libc, which appears in your ldd(1) output, and
                      > contains the Berkeley DB 1.85 routines.

                      Ah-hah, thank you for that.


                      --
                    Your message has been successfully submitted and would be delivered to recipients shortly.