The TCP port of the HTTP server is privileged or already in use: (port = 8042)
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
On 2022-04-29 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?
maybe systemd listening on a .socket file? I looked on my /etc/systemd/ and /usr/lib/systemd/ directories and did not find it. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
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
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_cast<std::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
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_cast<std::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
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_cast<std::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
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? Thanks for your help, Georg and Marcus! Axel
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
Hi Axel, I attempted the manual symlink route before, and it made the program segfault during the OpenSSL FIPS self check. 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? Best, Georg On 5/5/22 11:30, Axel Braun wrote:
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
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. Did you also install libopenssl1_1-hmac ? Also I tried finding the code piece in "orthanc" package which loads libcrypto.so with dlopen, (SharedLibrary class?), but i can't find it. orthanc seems to link directly to libcrypto.so.1.1 though. Ciao, Marcus
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 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.
https://groups.google.com/g/orthanc-users/c/H3Sqe3Ql8eI/m/phjZpKssAwAJ
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 5, 2022 at 4:39 PM Marcus Meissner <meissner@suse.de> 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
On Thu, May 05, 2022 at 05:16:22PM +0300, Andrei Borzenkov wrote:
On Thu, May 5, 2022 at 4:39 PM Marcus Meissner <meissner@suse.de> 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
On 05.05.2022 17:40, Marcus Meissner wrote:
On Thu, May 05, 2022 at 05:16:22PM +0300, Andrei Borzenkov wrote:
On Thu, May 5, 2022 at 4:39 PM Marcus Meissner <meissner@suse.de> 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
I tested orthanc startup with modified library and it works. I have no idea what this program does and how to use it further. I0505 17:47:12.037009 HttpServer.cpp:1585] (http) This Orthanc server uses CivetWeb as its embedded HTTP server I0505 17:47:12.037112 HttpServer.cpp:2074] (http) The embedded HTTP server will use 50 threads I0505 17:47:12.037273 HttpServer.cpp:1934] (http) HTTP keep alive is enabled W0505 17:47:12.037400 HttpServer.cpp:1998] HTTP compression is enabled I0505 17:47:12.037562 HttpServer.cpp:2087] (http) TCP_NODELAY for the HTTP sockets is set to true I0505 17:47:12.037691 HttpServer.cpp:2107] (http) Request timeout in the HTTP server is set to 30 seconds I0505 17:47:12.037820 HttpServer.cpp:1896] (http) Minimal accepted version of SSL/TLS protocol: TLS1.2 I0505 17:47:12.037874 main.cpp:1122] (http) No configuration option "SslCiphersAccepted", will accept the FIPS 140-2 ciphers I0505 17:47:12.037931 HttpServer.cpp:1922] (http) List of accepted SSL ciphers: ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:AES256-SHA:AES128-SHA I0505 17:47:12.037985 main.cpp:1158] Version of Lua: Lua 5.1 W0505 17:47:12.038037 main.cpp:1169] Remote LUA script execution is disabled I0505 17:47:12.038062 HttpServer.cpp:2154] (http) Branching WebDAV bucket at: /webdav I0505 17:47:12.038115 HttpServer.cpp:1630] (http) Starting embedded Web server using Civetweb I0505 17:47:12.040298 OrthancWebDav.cpp:1694] Starting the WebDAV upload thread W0505 17:47:12.040496 HttpServer.cpp:1775] HTTP server listening on port: 8042 (HTTPS encryption is enabled, remote access is allowed) W0505 17:47:12.040804 main.cpp:921] Orthanc has started
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
participants (6)
-
Andrei Borzenkov -
Axel Braun -
Axel Braun -
Carlos E. R. -
Georg Pfuetzenreuter -
Marcus Meissner