search

jselbie / stunserver

Version 1.2. This is the source code to STUNTMAN - an open source STUN server and client code by john selbie. Compliant with the latest RFCs including 5389, 5769, and 5780. Also includes backwards compatibility for RFC 3489. Compiles on Linux, MacOS, BSD, Solaris, and Win32 with Cygwin. Windows binaries avaialble from www.stunprotocol.org.
http://www.stunprotocol.org
Apache License 2.0
1.44k stars 349 forks source link

Issues when porting STUNSERVER to other distros #22

Closed jamesrenaud closed 7 years ago

jamesrenaud commented 7 years ago

So I've got a situation where I'm using an AWS Code Pipeline to build and deploy the stun server. The code is being built within an Ubuntu container, and then deployed to an Amazon Linux EC2 instance.

The code builds fine, but when I port the stunserver executable over to the EC2 instance and attempt to run it, the server can't run because it can't find libcrypto.so.1.0.0 in the /usr/lib64 folder. If I build directly on the EC2 instance, everything runs fine. I do not want to do the building of the server on the production system.

LDD gives me the following: ldd /opt/stunserver/stunserver linux-vdso.so.1 => (0x00007ffddd3b6000) libcrypto.so.1.0.0 => not found libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f6f145e3000) libm.so.6 => /lib64/libm.so.6 (0x00007f6f142e1000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f6f140cb000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f6f13eae000) libc.so.6 => /lib64/libc.so.6 (0x00007f6f13aec000) /lib64/ld-linux-x86-64.so.2 (0x0000555a1b111000)

STRACE goes looking for the libcrypto.so.1.0.0 in /usr/lib64 but it doesn't exist (only libcrypto.so exists as a link).

Is there something obvious I'm missing here?

jamesrenaud commented 7 years ago

The LDD output of the stunserver executable when I build it on the system is as follows: ldd stunserver linux-vdso.so.1 => (0x00007ffd87fce000) libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f2868939000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f2868634000) libm.so.6 => /lib64/libm.so.6 (0x00007f2868331000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f286811b000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f2867eff000) libc.so.6 => /lib64/libc.so.6 (0x00007f2867b3c000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f2867938000) libz.so.1 => /lib64/libz.so.1 (0x00007f2867722000) /lib64/ld-linux-x86-64.so.2 (0x0000563dbe488000)

Even if I build, then go run the stunserver executable I brought over from the build server, it still fails.

jamesrenaud commented 7 years ago

So it seems if I build on the EC2 instance I end up with a dependency on libcrypto.so.10 instead of libcrypto.so.1.0.0.

How can I fix this without building on my production ec2 instance?

jamesrenaud commented 7 years ago

I solved this by retargeting my build to use an amazon standard linux container and do the build in that instead of the Ubuntu image provided by default.

jselbie commented 7 years ago

Hi James,

I've been busy today and have not been able to look at this until now. But it seems like you got unblocked, so I'm happy that you found a workaround.

This isn't a problem unique to the stunserver codebase, but pretty much any software compiled on one distro of Linux and attempting to run on another. In this case, there was a difference in the version of OpenSSL (libcrypto) you linked against and the version on the target machine. I suspect you built against OpenSSL 1.0, but the target machine only had OpenSSL 1.1. That's just a guess. Or it was just a missing symlink on the target machine.

Another option would have been be to update the Makefiles in "server" and "client" to use static linking. I think that's just passing -static as a compiler/linker flag. Binary would be bigger, but more likely to run on a different machine.

If you think there's a way to make the code better for these scenarios, please let me know.

jrs

On Mon, Jul 24, 2017 at 11:40 AM, James Renaud notifications@github.com wrote:

I solved this by retargeting my build to use an amazon standard linux container and do the build in that instead of the Ubuntu image provided by default.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jselbie/stunserver/issues/22#issuecomment-317516141, or mute the thread https://github.com/notifications/unsubscribe-auth/AA7ZFx7Ei4rcwvIlb33DDlzw3uKwnEnSks5sROUMgaJpZM4OhQUs .