Sorry for the bother, but is there any way to poke or prod or query dovecot so that it will reveal what version of SSL it is currently using?
dovecot --build-options
tells me that openssl is there, but not the version.
ldd on any of the binaries in libexec comes up empty.
I can get the version and what directory it is looking at by:
strings ssl-params | grep -i ssl
but that is kludgy.
CentOS 5, dovecot 2.2.13.
Thanks for any help.
Cheers, Zube
You can use ldd.
ldd /usr/lib64/dovecot/libdovecot-ssl.soIt works.
On 2014-06-12, 12:34 PM, Zube wrote:
Sorry for the bother, but is there any way to poke or prod or query dovecot so that it will reveal what version of SSL it is currently using?
dovecot --build-options
tells me that openssl is there, but not the version.
ldd on any of the binaries in libexec comes up empty.
I can get the version and what directory it is looking at by:
strings ssl-params | grep -i ssl
but that is kludgy.
CentOS 5, dovecot 2.2.13.
Thanks for any help.
Cheers, Zube
--
Pressure creates diamonds.
On Thu Jun 12 12:47:06 PM, Andrew Ho wrote:
You can use ldd.
ldd /usr/lib64/dovecot/libdovecot-ssl.soIt works.
I should have mentioned (drat) that I built both OpenSSL and dovecot from scratch and both are in their own directories under /usr/local. ldd on any file I've tried so far comes up without any ssl bits, (probably a side effect of the way I built it).
In the dovecot lib directory, I don't even have a libdovecot-ssl.so. :)
Cheers, Zube
Am 12.06.2014 19:24, schrieb Zube:
On Thu Jun 12 12:47:06 PM, Andrew Ho wrote:
You can use ldd.
ldd /usr/lib64/dovecot/libdovecot-ssl.soIt works.
I should have mentioned (drat) that I built both OpenSSL and dovecot from scratch and both are in their own directories under /usr/local. ldd on any file I've tried so far comes up without any ssl bits, (probably a side effect of the way I built it).
In the dovecot lib directory, I don't even have a libdovecot-ssl.so. :)
but you have %prefix/libexec/dovecot/imap-login and if you even managed to link it static why do you need to look what version - you should know and avoid static linking in general
On Thu Jun 12 07:28:57 PM, Reindl Harald wrote:
but you have %prefix/libexec/dovecot/imap-login and if you even managed to link it static
Hmm. I do feel like an idiot now. I don't think it's statically linked.
prompt> file imap-login imap-login: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), not stripped
I certainly wasn't able to build dovecot until I rebuilt ssl with -fPIC.
why do you need to look what version - you should know and avoid static linking in general
It's a sanity check to make sure what I think is running is running.
I can get sshd to tell me it's running:
"OpenSSH_6.6p1, OpenSSL 1.0.1h 5 Jun 2014"
by passing it an unknown option on the command line (there is probably a better way).
Similarly, I can query apache with curl and it will tell me:
OpenSSL/1.0.1h
I was just curious if there was an easy way with my current dovecot environment. Thanks for the feedback.
Cheers, Zube
Am 12.06.2014 20:32, schrieb Zube:
On Thu Jun 12 07:28:57 PM, Reindl Harald wrote:
but you have %prefix/libexec/dovecot/imap-login and if you even managed to link it static
Hmm. I do feel like an idiot now. I don't think it's statically linked.
why do you need to think? you configured how it is built
prompt> file imap-login imap-login: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), not stripped
and what says "ldd" on that file?
[harry@srv-rhsoft:~]$ ldd /usr/libexec/dovecot/imap-login linux-vdso.so.1 => (0x00007fff51f21000) libdovecot-login.so.0 => /usr/lib64/dovecot/libdovecot-login.so.0 (0x00007fe5363a4000) libdovecot.so.0 => /usr/lib64/dovecot/libdovecot.so.0 (0x00007fe5360c2000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fe535ea5000) libc.so.6 => /lib64/libc.so.6 (0x00007fe535ae6000) libssl.so.10 => /lib64/libssl.so.10 (0x00007fe535878000) libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007fe535486000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fe535282000) /lib64/ld-linux-x86-64.so.2 (0x00007fe5367e4000) libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007fe535037000) libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007fe534d57000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007fe534b53000) libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007fe53491d000) libz.so.1 => /lib64/libz.so.1 (0x00007fe534704000) libgomp.so.1 => /lib64/libgomp.so.1 (0x00007fe5344f5000) libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007fe5342e6000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007fe5340e2000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fe533ec8000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fe533ca3000) libpcre.so.1 => /lib64/libpcre.so.1 (0x00007fe533a3d000) liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fe533811000)
On Thu Jun 12 08:36:28 PM, Reindl Harald wrote:
prompt> file imap-login imap-login: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), not stripped
and what says "ldd" on that file?
prompt> ldd imap-login linux-vdso.so.1 => (0x00007fffd03fd000) libdovecot-login.so.0 => /usr/local/dovecot/lib/dovecot/libdovecot-login.so.0 (0x00002b5798753000) libdovecot.so.0 => /usr/local/dovecot/lib/dovecot/libdovecot.so.0 (0x00002b5798b73000) libc.so.6 => /lib64/libc.so.6 (0x00000037f0e00000) libdl.so.2 => /lib64/libdl.so.2 (0x00000037f1600000) libz.so.1 => /lib64/libz.so.1 (0x00000037f1a00000) librt.so.1 => /lib64/librt.so.1 (0x00000037f5600000) /lib64/ld-linux-x86-64.so.2 (0x00000037f0a00000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00000037f1e00000)
Cheers, Zube
Am 12.06.2014 22:49, schrieb Zube:
On Thu Jun 12 08:36:28 PM, Reindl Harald wrote:
prompt> file imap-login imap-login: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), not stripped
and what says "ldd" on that file?
prompt> ldd imap-login linux-vdso.so.1 => (0x00007fffd03fd000) libdovecot-login.so.0 => /usr/local/dovecot/lib/dovecot/libdovecot-login.so.0 (0x00002b5798753000) libdovecot.so.0 => /usr/local/dovecot/lib/dovecot/libdovecot.so.0 (0x00002b5798b73000) libc.so.6 => /lib64/libc.so.6 (0x00000037f0e00000) libdl.so.2 => /lib64/libdl.so.2 (0x00000037f1600000) libz.so.1 => /lib64/libz.so.1 (0x00000037f1a00000) librt.so.1 => /lib64/librt.so.1 (0x00000037f5600000) /lib64/ld-linux-x86-64.so.2 (0x00000037f0a00000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00000037f1e00000)
so you have no ssl support or linked openssl statically what let you come to the conclusion your build has ssl support? why not using a package manager and if you build yourself why don#t you read the output of ./configure?
"uses shared libs" in the file commands don't say anything useful ______________________________-
my ffmpeg build uses x264 also static but a lot of other libs dynamically
[harry@srv-rhsoft:~]$ file /usr/local/bin/ffmpeg /usr/local/bin/ffmpeg: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=a3197740ffc6c0532de9c4f39eb6682b6c0259fc, stripped
[harry@srv-rhsoft:~]$ ldd /usr/local/bin/ffmpeg linux-vdso.so.1 => (0x00007fff33f27000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f6ce07b2000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f6ce0595000) libvpx.so.1 => /lib64/libvpx.so.1 (0x00007f6ce01eb000) libtheoraenc.so.1 => /lib64/libtheoraenc.so.1 (0x00007f6cdffbe000) libtheoradec.so.1 => /lib64/libtheoradec.so.1 (0x00007f6cdfdae000) libmp3lame.so.0 => /lib64/libmp3lame.so.0 (0x00007f6cdfb33000) libm.so.6 => /lib64/libm.so.6 (0x00007f6cdf82c000) libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f6cdf61c000) libz.so.1 => /lib64/libz.so.1 (0x00007f6cdf402000) libc.so.6 => /lib64/libc.so.6 (0x00007f6cdf043000) /lib64/ld-linux-x86-64.so.2 (0x00007f6ce09d1000) libogg.so.0 => /lib64/libogg.so.0 (0x00007f6cdee3c000) libgomp.so.1 => /lib64/libgomp.so.1 (0x00007f6cdec2c000)
oh no x264 - well, yes because it's linked statically to offer use the latest upstream without break other dependencies
On Thu, 12 Jun 2014, Zube wrote:
prompt> ldd imap-login linux-vdso.so.1 => (0x00007fffd03fd000) libdovecot-login.so.0 => /usr/local/dovecot/lib/dovecot/libdovecot-login.so.0 (0x00002b5798753000) libdovecot.so.0 => /usr/local/dovecot/lib/dovecot/libdovecot.so.0 (0x00002b5798b73000) libc.so.6 => /lib64/libc.so.6 (0x00000037f0e00000) libdl.so.2 => /lib64/libdl.so.2 (0x00000037f1600000) libz.so.1 => /lib64/libz.so.1 (0x00000037f1a00000) librt.so.1 => /lib64/librt.so.1 (0x00000037f5600000) /lib64/ld-linux-x86-64.so.2 (0x00000037f0a00000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00000037f1e00000)
If OpenSSL is linked statically this will be successful:
$ strings imap-login | grep OpenSSL
- Michael
On Thu Jun 12 05:19:02 PM, Michael Hocke wrote:
$ strings imap-login | grep OpenSSL
Yes, this is what I get on something like sshd, which I know points to a non-shared OpenSSL install. It also appears, as previously mentioned, on ssl-params, but not on anything else, like imap-login.
ssl is most certainly there.
Maybe this is a side-effect of setting LD_RUN_PATH when building. Hmm.
Zube
participants (4)
-
Andrew Ho
-
Michael Hocke
-
Reindl Harald
-
Zube