CQRLOG upload to LOTW missing SSL libs

[danieladams456]

It looks like on Raspberry pi, libssl-dev files get put in a different location than cqrlog is expecting. https://www.cqrlog.com/comment/7703#comment-7703

The reason for this is because on Rapsbian Buster libssl and libcrypto are at a different location than on other Linux releases. ( /usr/lib/arm-linux-gnueabihf ) Just copy from /usr/lib/arm-linux-gnueabihf to /usr/lib following files: libssl.so libcrypto.so

I'm not sure if this is something that you would consider an upstream bug and wait to be fixed, or if you'd want to copy those files over on image build. Copying the files fixed the immediate issue for me.

[dslotter]

Hi @danieladams456. Thanks for the report. I think there should be a couple ways to "fix" this. The simplest might be to export LDCONFIG to include /usr/lib/arm-linux-gnueabihf and see if CQRLog finds the libraries.

[danieladams456]

Export as in an environment variable? I'm not very familiar with ldconfig so did a bit of googling man pages. This is the current setup.

It looks like it is trying to include those directories.

pi@hampi:~ $ cat /etc/ld.so.conf
include /etc/ld.so.conf.d/*.conf

pi@hampi:~ $ cat /etc/ld.so.conf.d/arm-linux-gnueabihf.conf 
# Multiarch support
/usr/local/lib/arm-linux-gnueabihf
/lib/arm-linux-gnueabihf
/usr/lib/arm-linux-gnueabihf

A list of all loaded modules shows they were loaded from both places.

pi@hampi:~ $ ldconfig -p|grep libssl
    libssl3.so (libc6,hard-float) => /lib/arm-linux-gnueabihf/libssl3.so
    libssl.so.1.1 (libc6,hard-float) => /lib/arm-linux-gnueabihf/libssl.so.1.1
    libssl.so.1.1 (libc6,hard-float) => /lib/libssl.so.1.1
    libssl.so (libc6,hard-float) => /lib/arm-linux-gnueabihf/libssl.so
    libssl.so (libc6,hard-float) => /lib/libssl.so
pi@hampi:~ $ ldconfig -p|grep libcrypto
    libcrypto.so.1.1 (libc6,hard-float) => /lib/arm-linux-gnueabihf/libcrypto.so.1.1
    libcrypto.so.1.1 (libc6,hard-float) => /lib/libcrypto.so.1.1
    libcrypto.so (libc6,hard-float) => /lib/arm-linux-gnueabihf/libcrypto.so
    libcrypto.so (libc6,hard-float) => /lib/libcrypto.so

And seems like the loaded ones without numbers are symlinks to the version-specific ones.

pi@hampi:~ $ ll /lib/libssl.so
lrwxrwxrwx 1 root root 13 Jan 13 19:55 /lib/libssl.so -> libssl.so.1.1
pi@hampi:~ $ ll /lib/libcrypto.so
lrwxrwxrwx 1 root root 16 Jan 13 19:55 /lib/libcrypto.so -> libcrypto.so.1.1

[dslotter]

My apologies, I meant LD_LIBRARY_PATH. And that didn't work as I hoped. Either I did something wrong, or someone's not respecting that environment variable.

Also, /etc/ld.so.conf.d/* doesn't seem to be respected either. As I didn't modify this, I'm certain that I didn't do anything wrong here...

That said, when digging into CQRLog, I discovered that I'm installing version 2.3 and there is a release version of 2.5.1 which hasn't hit the repositories yet, so I'm going to install that instead... And the bonus of installing CQRLog 2.5.1, means that it has fixed the libssl/libcrypto issue you reported.

Thanks for bringing this to my attention! Your efforts are going to result in a better CQRLog experience for everyone!

[danieladams456]

Thanks @dslotter! This does bring up one question I had been wondering about. What is your recommended approach for software upgrades over time? Should I try to run these Ansible scripts on a live install, or just plan to reimage/reconfigure every year or two? Sorry to hijack the thread.

[dslotter]

@danieladams456 Excellent question, but this is better suited for the Ham-Pi group on groups.io or the HamPC group on groups.io . That said, there is no "one size fits all" approach to upgrading. That said, I did provide some help in the upgrade area. First, there is a "Howto" document on upgrading -- providing instructions to back up users' files so they could upgrade to a new version and not lose their files. Also, it was extremely apparent that a majority of users will use Fldigi and/or WSJT-X, so I provided an update script for both in the pi user's bin directory (/home/pi/bin) so users can keep Fldigi and WSJT-X up to date without needing to download a new version of HamPi or HamPC.

In at least 95% of cases, one could run the Ansible playbooks from git against a working install, and they would safely update the software. This is beyond my level of support, and for the other 5% of the time, there may be side-effects, such as duplicate configurations added to configuration files, etc. If you want to do that, then more power to you! 👍

Another process I can suggest is to look at the release notes for the latest quarterly release of HamPi / HamPC and see if the changes add a piece of software you're looking for, or update software you're using. The release notes provide insight as to whether you would benefit from a new version of HamPi and/or HamPC. At this point in time, HamPi and HamPC are very much in development, and I will continue to push to improve these distributions with adding new ham radio software applications and/or fixing defects, such as this SSL library issue you reported.

I hope this helps. I should probably copy this to the groups on groups.io for other people to benefit... "73" -djs

[danieladams456]

Thanks @dslotter, I appreciate all the work you have done on this project!