Hi Axel, Sorry, scrap my previous email. I realized too late you only encounter this issue with the HTTPS listener, not the plain HTTP one. It seems the Orthanc code throws this exception in an else clause, so possibly it's not always an accurate error message: if (isSslError) { throw OrthancException(ErrorCode_SslInitialization); } else { throw OrthancException(ErrorCode_HttpPortInUse, " (port = " + boost::lexical_caststd::string(port_) + ")"); } } Running Orthanc with HTTPS enabled through strace seems to make it stutter with libcrypto: openat(AT_FDCWD, "/lib64/libcrypto.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/lib64/libcrypto.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) munmap(0x7fb5940ea000, 24027) = 0 write(2, "E0429 15:38:53.847614 OrthancExc"..., 47) = 47 write(2, "The TCP port of the HTTP server "..., 63) = 63 Manually linking either of our available libcrypto libraries makes it continue, but eventually segfaults in an OpenSSL FIPS Self Check. I think this is an issue with the libraries the package is build against - but I'm not too sure. Originally I wanted to suggest raising an issue with the packager - but now I realize you are the packager! :-) I'm not sure if any of the above is helpful, but possibly you could try checking if it needs any specific setup of libcrypto/openssl and compare it to the libraries installed on Debian? Sorry for not being more helpful, but kudos for maintaining this! Best, Georg On 4/29/22 15:20, Georg Pfuetzenreuter wrote:

Hi,

I installed the Orthanc package from the official repositories on Tumbleweed, and am able to start the server in its default configuration with no issues - I do not see any significant differences between to the Leap version, hence assume it should behave the same:

georg@host ~> sudo systemctl start orthanc

georg@host ~> sudo journalctl -fu orthanc Apr 29 15:11:37 dracutdev01.home.lysergic.dev orthanc[7983]: W0429 15:11:37.210265 LuaContext.cpp:94] Lua says: Lua toolbox installed Apr 29 15:11:37 dracutdev01.home.lysergic.dev orthanc[7983]: W0429 15:11:37.210470 ServerContext.cpp:476] Disk compression is disabled Apr 29 15:11:37 dracutdev01.home.lysergic.dev orthanc[7983]: W0429 15:11:37.210482 ServerIndex.cpp:380] No limit on the number of stored patients Apr 29 15:11:37 dracutdev01.home.lysergic.dev orthanc[7983]: W0429 15:11:37.210504 ServerIndex.cpp:400] No limit on the size of the storage area Apr 29 15:11:37 dracutdev01.home.lysergic.dev orthanc[7983]: W0429 15:11:37.211006 JobsEngine.cpp:272] The jobs engine has started with 2 threads Apr 29 15:11:37 dracutdev01.home.lysergic.dev orthanc[7983]: W0429 15:11:37.212252 main.cpp:1302] DICOM server listening with AET ORTHANC on port: 4242 Apr 29 15:11:37 dracutdev01.home.lysergic.dev orthanc[7983]: W0429 15:11:37.212297 HttpServer.cpp:1998] HTTP compression is enabled Apr 29 15:11:37 dracutdev01.home.lysergic.dev orthanc[7983]: W0429 15:11:37.212311 main.cpp:1169] Remote LUA script execution is disabled Apr 29 15:11:37 dracutdev01.home.lysergic.dev orthanc[7983]: W0429 15:11:37.213715 HttpServer.cpp:1775] HTTP server listening on port: 8042 (HTTPS encryption is disabled, remote access is not allowed) Apr 29 15:11:37 dracutdev01.home.lysergic.dev orthanc[7983]: W0429 15:11:37.213741 main.cpp:921] Orthanc has started

georg@host ~> sudo ss -tulpn Netid   State    Recv-Q   Send-Q     Local Address:Port     Peer Address:Port  Process tcp     LISTEN   0        200              0.0.0.0:8042 0.0.0.0:* users:(("orthanc",pid=7983,fd=6)) tcp     LISTEN   0        50               0.0.0.0:4242 0.0.0.0:* users:(("orthanc",pid=7983,fd=5)

Can you confirm you do not have another instance of Orthanc running, possibly the systemd serviced one, while you try to run it manually? `ps aux |grep orthanc`

Can you attempt changing the default ports to some arbitrary ones, and try with those? In /etc/orthanc/Configuration.json: "HttpPort" : 12345 "DicomPort" : 54321,

georg@host ~> sudo ss -tulpn Netid  State    Recv-Q   Send-Q     Local Address:Port      Peer Address:Port  Process tcp    LISTEN   0        200              0.0.0.0:12345 0.0.0.0:* users:(("orthanc",pid=8369,fd=7)) tcp    LISTEN   0        50               0.0.0.0:54321 0.0.0.0:* users:(("orthanc",pid=8369,fd=6))

Best, Georg

On 4/29/22 14:34, Axel Braun wrote:

...

Hi,

I run into the above error message when I want to start an Orthanc Server in https mode. I had already contacted the author of Orthanc, and he could not reproduce this (with my config files and certificates) on Debian. So the assumption is that it is a distribution (Leap 15.3) specific issue.

Log of the (manual )start as root using /usr/sbin/orthanc --verbose --trace-http --logfile=http_orthanc.log /etc/ orthanc/

https://paste.opensuse.org/92992870

What I tried: ss -tulpen does not show the port being used

switch off apache (reverse proxy)

switch off AppArmor

Is there any openSUSE specific configuration that prevents using high ports?

Cheers Axel

Great input Marcus - thank you very much! Installing libopenssl-devel makes it work immediately: Apr 29 16:34:41 dracutdev01.home.lysergic.dev orthanc[23899]: W0429 16:34:41.640477 HttpServer.cpp:1775] HTTP server listening on port: 8042 (HTTPS encryption is enabled, remote access is not allowed) I hope Axel can incorporate that into the package (or, even better, check with the developers if this can be solved upstream). Best, Georg On 4/29/22 16:25, Marcus Meissner wrote:

On Fri, Apr 29, 2022 at 04:08:31PM +0200, Georg Pfuetzenreuter wrote:

...

Hi Axel,

Sorry, scrap my previous email. I realized too late you only encounter this issue with the HTTPS listener, not the plain HTTP one.

It seems the Orthanc code throws this exception in an else clause, so possibly it's not always an accurate error message: if (isSslError) { throw OrthancException(ErrorCode_SslInitialization); } else { throw OrthancException(ErrorCode_HttpPortInUse, " (port = " + boost::lexical_caststd::string(port_) + ")"); } }

Running Orthanc with HTTPS enabled through strace seems to make it stutter with libcrypto:

openat(AT_FDCWD, "/lib64/libcrypto.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/lib64/libcrypto.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) munmap(0x7fb5940ea000, 24027) = 0 write(2, "E0429 15:38:53.847614 OrthancExc"..., 47) = 47 write(2, "The TCP port of the HTTP server "..., 63) = 63

Manually linking either of our available libcrypto libraries makes it continue, but eventually segfaults in an OpenSSL FIPS Self Check.

I think this is an issue with the libraries the package is build against - but I'm not too sure.

Originally I wanted to suggest raising an issue with the packager - but now I realize you are the packager! :-)

I'm not sure if any of the above is helpful, but possibly you could try checking if it needs any specific setup of libcrypto/openssl and compare it to the libraries installed on Debian?

It should not open libcrypto.so usually, but libcrypto.so.<major>

Install libopenssl-devel to see if that makes it work (as that contains libcrypto.so)

Ciao, Marcus

Am Freitag, 29. April 2022, 16:50:13 CEST schrieb Axel Braun:

H Gents,

Am Freitag, 29. April 2022, 16:36:01 CEST schrieb Georg Pfuetzenreuter:

...

Great input Marcus - thank you very much!

...

Installing libopenssl-devel makes it work immediately: Confirmed! Here as well. However, a -devel package should not be needed after compilation.

...

Apr 29 16:34:41 dracutdev01.home.lysergic.dev orthanc[23899]: W0429 16:34:41.640477 HttpServer.cpp:1775] HTTP server listening on port: 8042 (HTTPS encryption is enabled, remote access is not allowed)

I hope Axel can incorporate that into the package (or, even better, check with the developers if this can be solved upstream).

Yes, I will report this upstream.

I just wonder why Debian uses libcrypto.so instead of libcrypto.so.<major> - or maybe they create a symlink?

looks like that ends up in a ping-pong between upstream and openSUSE :-( As solution I could add the -devel pacakge as runtime dependency, what i not really like, or determine the libcrypto.so.<version> and create a symlink without <version> during build. Can anyone tell me how to determine the lib version during build? ldconfig -v | grep libcrypto.so did not work... Thanks Axel

Hello Georg, Am Donnerstag, 5. Mai 2022, 11:40:56 CEST schrieb Georg Pfuetzenreuter:

I attempted the manual symlink route before, and it made the program segfault during the OpenSSL FIPS self check.

Oh, thats not good.....

I'm not sure the package is supposed to touch on libraries either, as it may cause conflicts. Does upstream not agree that the devel version should not be required?

Upstream arguments that it works under Debian, and Debian seems to create a symlink: https://groups.google.com/g/orthanc-users/c/H3Sqe3Ql8eI/m/phjZpKssAwAJ Cheers Axel

Am Donnerstag, 5. Mai 2022, 13:16:01 CEST schrieb Marcus Meissner:

On Thu, May 05, 2022 at 12:53:09PM +0200, Axel Braun wrote:

...

Hello Georg,

Am Donnerstag, 5. Mai 2022, 11:40:56 CEST schrieb Georg Pfuetzenreuter:

...

I attempted the manual symlink route before, and it made the program segfault during the OpenSSL FIPS self check.

Oh, thats not good.....

...

I'm not sure the package is supposed to touch on libraries either, as it may cause conflicts. Does upstream not agree that the devel version should not be required?

Upstream arguments that it works under Debian, and Debian seems to create a symlink: https://groups.google.com/g/orthanc-users/c/H3Sqe3Ql8eI/m/phjZpKssAwAJ

Did you install libopenssl-1_1-devel.

yes (to make it worl and to get a symlink)

Did you also install libopenssl1_1-hmac ?

no Cheers Axel

On Thu, May 05, 2022 at 04:10:15PM +0300, Andrei Borzenkov wrote:

On 05.05.2022 13:53, Axel Braun wrote:

...

Hello Georg,

Am Donnerstag, 5. Mai 2022, 11:40:56 CEST schrieb Georg Pfuetzenreuter:

...

I attempted the manual symlink route before, and it made the program segfault during the OpenSSL FIPS self check.

Oh, thats not good.....

...

I'm not sure the package is supposed to touch on libraries either, as it may cause conflicts. Does upstream not agree that the devel version should not be required?

Upstream arguments that it works under Debian, and Debian seems to create a symlink:

Exactly as openSUSE - symlink is created by devel package

bor@bor-Latitude-E5450:~/obs$ dpkg-query -S /usr/lib/x86_64-linux-gnu/libcrypto.so

libssl-dev:amd64: /usr/lib/x86_64-linux-gnu/libcrypto.so

bor@bor-Latitude-E5450:~/obs$

Anyway, as I commented in bug report, libcrypto.so is opened by embedded web server library libcivetweb, so it is not your package bug.

I submitted a fix for civetweb. SR#975205 I have not tested it, would be good if someone could test it if it works without libopenssl-1_1-devel installed. Ciao, Marcus

On Thu, May 05, 2022 at 05:16:22PM +0300, Andrei Borzenkov wrote:

On Thu, May 5, 2022 at 4:39 PM Marcus Meissner wrote:

...

...

Anyway, as I commented in bug report, libcrypto.so is opened by embedded web server library libcivetweb, so it is not your package bug.

I submitted a fix for civetweb.

SR#975205

I have not tested it, would be good if someone could test it if it works without libopenssl-1_1-devel installed.

Ouch! Why do not you simply disable dynamic loading?

[ 29s] Requires: libc.so.6()(64bit) libc.so.6(GLIBC_2.14)(64bit) libc.so.6(GLIBC_2.17)(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.28)(64bit) libc.so.6(GLIBC_2.3)(64bit) libc.so.6(GLIBC_2.3.2)(64bit) libc.so.6(GLIBC_2.3.4)(64bit) libc.so.6(GLIBC_2.33)(64bit) libc.so.6(GLIBC_2.34)(64bit) libc.so.6(GLIBC_2.4)(64bit) libc.so.6(GLIBC_2.7)(64bit) libcrypto.so.1.1()(64bit) libcrypto.so.1.1(OPENSSL_1_1_0)(64bit) libssl.so.1.1()(64bit) libssl.so.1.1(OPENSSL_1_1_0)(64bit)

%cmake -DWITH_ALL=1 \ -DCIVETWEB_BUILD_TESTING=OFF \ -DCIVETWEB_ENABLE_CXX=ON \ -DCIVETWEB_ENABLE_SSL_DYNAMIC_LOADING=OFF

Good thing, this is much better, will redo. Ciao, Marcus

Am Donnerstag, 5. Mai 2022, 16:51:57 CEST schrieb Andrei Borzenkov:

...

...

%cmake -DWITH_ALL=1 \ -DCIVETWEB_BUILD_TESTING=OFF \ -DCIVETWEB_ENABLE_CXX=ON \ -DCIVETWEB_ENABLE_SSL_DYNAMIC_LOADING=OFF

Good thing, this is much better, will redo.

Ciao, Marcus

I tested orthanc startup with modified library and it works. I have no idea what this program does and how to use it further.

Did a test with the compiler options as well, and can confirm that it works Thanks guys! Not sure what you mean with 'what this program does and how to use it further'? This program = orthanc? Or civetweb? Cheers Axel