Postgres plugin fails to initialize when EnableSSL is set to true

[athome withagroovebox]

Hello all,

For some reason, the postgres plugin segfaults when I set EnableSsl to true.  I know the rest of my config is good, because everything works as long as EnableSsl is set to false. And I know my postgres instance is good, because I've been able to connect to it over SSL using pg_admin.  Currently using the jodogne/orthanc-plugins:latest docker image.  My postgres instance is hosted in AWS, using RDS.  

This is my config :

  "PostgreSQL" : {

    "EnableIndex" : true,

    "EnableStorage" : false,

    "Host" : "[MY HOST ADDRESS]",

    "Port" : 5432,

    "Database" : "[MY DATABASE]",

    "Username" : "[MY USERNAME]",

    "Password" : "[MY PASSWORD]",

    "EnableSsl" : true

  },

When I start up Orthanc, it gets to the part where it tries to initialize the postgres connection, and I get this :

W0216 20:56:34.725411 main.cpp:1533] Using a custom database from plugins

W0216 20:56:34.725444 OrthancInitialization.cpp:406] Storage directory: "/var/lib/orthanc/db"

Segmentation fault

And then it just dies and doesn't give me any more information.  I don't know how to go about troubleshooting this.

Has anybody been able to get SSL to work for the postgres plugin?  If so, can you please tell me how you got it to work?

--Jeremy

[Sébastien Jodogne]

Hello,

There indeed seems to be an incompatibility between OpenSSL and LSB (Linux Standard Base) precompiled binaries of the PostgreSQL plugin.

You can use the "osimis/orthanc" image (that don't use LSB) instead of the "jodogne/orthanc" image:

https://book.orthanc-server.com/users/docker-osimis.html

For future reference, here is how to start a Docker container running PostgreSQL with SSL enabled onto local TCP port 5000 (the Docker image includes a self-signed certificate for test purpose):

$ docker run --rm -t -i -p 5000:5432 -e POSTGRES_PASSWORD=password postgres:12 -c ssl=on -c ssl_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem -c ssl_key_file=/etc/ssl/private/ssl-cert-snakeoil.key

Then, here is how to start Orthanc against this PostgreSQL server (replace "192.168.0.1" by your IP address):

$ PGPASSWORD='password' psql -h localhost -p 5000 -U postgres -c "CREATE DATABASE orthanc"

$ docker run --rm -t -i -p 8042:8042 -p 4242:4242 -e POSTGRESQL_PLUGIN_ENABLED=true -e ORTHANC__POSTGRESQL__HOST=192.168.0.1 -e ORTHANC__POSTGRESQL__ENABLE_SSL=true -e ORTHANC__POSTGRESQL__PORT=5000 -e ORTHANC__POSTGRESQL__PASSWORD=password -e ORTHANC__POSTGRESQL__DATABASE=orthanc osimis/orthanc:21.1.7

Under this configuration, Orthanc starts fine.

HTH,

Sébastien-

[athome withagroovebox]

Thank you so much, Sébastien!  I'm now using the osimis/orthanc image, and the SSL connection to Postgres is working great!

I am curious, though -- how should I make the decision of which docker image to use?  Right now it seems like a good idea to use osimis/orthanc, since it works with Postgres SSL, and it also allows me to configure Orthanc using environment variables.  Is it generally recommended that people use the osimis/orthanc image?  Or are there situations where someone would want to use the jodogne/orthanc image instead?

--Jeremy

[Sébastien Jodogne]

Hello Jeremy,

The differences between the two sets of Docker images are explained in the Orthanc Book:

https://book.orthanc-server.com/users/docker.html

https://book.orthanc-server.com/users/docker-osimis.html

Summarizing, the "jodogne/orthanc" image is used by the core developer of Orthanc to test the cross-distribution binaries (compiled using LSB), and to test the raw configuration file of Orthanc. This is a "dev" image. The "osimis/orthanc" is typically aimed at "ops" teams.

In either case, the LSB binaries should *not* crash with PostgreSQL+SSL: This is a bug for which there is a known workaround (use "osimis/orthanc").

The problem is that I'm currently overwhelmed with way too many requests (this forum has received 353 messages since January 2021), so I can't fix such an issue by now. I have introduced a bug to keep track of this:

https://bugs.orthanc-server.com/show_bug.cgi?id=193

Sébastien-

[Sébastien Jodogne]

Hello,

This issue seems to be fixed by the following changeset in the Orthanc framework:

https://hg.orthanc-server.com/orthanc/rev/9a9118406484

Sébastien-