CLI tool does not work when SSHing into the container due to missing env vars

[j-sacra]

Shlink version

3.7.3

PHP version

8.2.13

How do you serve Shlink

Docker image

Database engine

MicrosoftSQL

Database version

18_18.1.1.1

Current behavior

I deployed Shlink on Azure using the docker image on a Linux alpine-based container.
Using a Microsoft SQL Server production database.

When trying to use the cli tool, no db objects are found:
An exception occurred while executing a query: SQLSTATE[HY000]: General error: 1 no such table: api_keys

The same image does not have this problem when running locally with the same environment variables.
Also the REST API works perfectly too, it's just the cli which is unable to find objects in db.

I think it's worth noting that I had to extend the base image of shlink to add SSH support since the selected stack did not support SSH out of the box.

Expected behavior

Using cli tool commands works.

How to reproduce

Set up shlink on an Azure app service on a Linux based image, with a production MSSQL database.
SSH into the container.
Run shlink commands, e.g. shlink api-key:generate or shlink short-url:list

[acelaya]

Very likely related to your custom docker image.

Please, provide a docker compose config which uses that image where this can be reproduced. I don't have an Azure account.

[j-sacra]

Thanks for the quick reply!

I completely understand that not everyone will be able to reproduce the exact scenario. The custom image also works well locally though.

Dockerfile for the image:

FROM shlinkio/shlink:3.7.3

RUN apk update
RUN apk add --no-cache openssh-server
RUN echo "root:Docker!" | chpasswd
RUN mkdir -p /var/run/sshd
    
COPY sshd_config /etc/ssh/
RUN mkdir -p /tmp
COPY ssh_setup.sh /tmp
RUN chmod +x /tmp/ssh_setup.sh \
    && (sleep 1;/tmp/ssh_setup.sh 2>&1 > /dev/null)

COPY start.sh /usr/local/bin/
RUN chmod +x /usr/local/bin/start.sh

EXPOSE 8080 2222

ENTRYPOINT ["/usr/local/bin/start.sh"]

contents of ssh_setup.sh

#!/bin/sh
ssh-keygen -A

if [ ! -d "/var/run/sshd" ]; then
    mkdir -p /var/run/sshd
fi

sshd_config

Port 			2222
ListenAddress 		0.0.0.0
LoginGraceTime 		180
X11Forwarding 		yes
Ciphers aes128-cbc,3des-cbc,aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr
MACs hmac-sha1,hmac-sha1-96
StrictModes 		yes
SyslogFacility 		DAEMON
PasswordAuthentication 	yes
PermitEmptyPasswords 	no
PermitRootLogin 	yes
Subsystem sftp internal-sftp

start.sh then starts the ssh service, followed by shlink.

#!/bin/sh
/usr/sbin/sshd
exec /bin/sh ./docker-entrypoint.sh

And, finally, the docker-compose to run it locally

version: "3"
services:
  shlink:
    image: 
    container_name: 
    restart: always
    environment:
      - DB_DRIVER=mssql
      - DB_HOST=
      - DB_NAME=
      - DB_USER=
      - DB_PASSWORD=
      - DB_PORT=1433
      - DEFAULT_SHORT_CODES_LENGTH=8
      - INITIAL_API_KEY=
      - IS_HTTPS_ENABLED=true
      - SHELL_VERBOSITY=3
      - GEOLITE_LICENSE_KEY=
    ports:
      - 8080:8080
      - 2222:2222

So when testing locally, I open a cli in the folder where all these files are, and run:

1. docker build -t shlinktest .
2. docker-compose up -d
3. docker exec -it shlinktest /bin/sh

[acelaya]

So when testing locally, I open a cli in the folder where all these files are, and run:

1. docker build -t shlinktest .
2. docker-compose up -d
3. docker exec -it shlinktest /bin/sh

You are stating that this works locally, but in there you are neither using all the SSH stuff, nor running any Shlink command, so you are not doing the same locally and in Azure. That difference is where the problem is.

If I have to blindly guess, by SSHing into the container, the working directory gets messed up somehow and Shlink cannot load its configuration, but as mentioned, in those three steps you are not using SSH.

[j-sacra]

I suspected it could be due to the SSH setup.
But I thought the docker exec -it shlinktest-container /bin/sh shell would be equivalent to the ssh session as we did see that the shlink tool is available in both shells.

[acelaya]

But I thought the docker exec -it shlinktest-container /bin/sh shell would be equivalent to the ssh session

Nop, that approach works, both locally and in any cloud provider. When SSHing into the container you are at the very least, using a different system user, which is also likely related with the problem.

You need to provide some steps to do the exact same thing you do in Azure, but locally, otherwise I won't be able to debug what's going on.

[j-sacra]

I will try to do that and comment here when I am able.

[j-sacra]

1. docker build -t shlinktest .
2. docker-compose up -d
3. ssh root@localhost:2222 

pwd is "Docker!"
You were right! It doesn't work when I ssh like this.

[acelaya]

The problem is that when logging-in as root via SSH, it does not inherit the environment variables passed to the container, which makes the shlink CLI tool use default options. That makes Shlink try to work with an SQLite empty database, hence the General error: 1 no such table: api_keys.

You can use this for testing:

version: "3"
services:
  shlink:
    image: shlinktest
    restart: always
    environment:
      - DB_DRIVER=mssql
      - DB_HOST=ms_database
      - DB_USER=sa
      - DB_PASSWORD=Passw0rd!
      - DB_PORT=1433
      - DEFAULT_SHORT_CODES_LENGTH=8
      - IS_HTTPS_ENABLED=false
      - SHELL_VERBOSITY=3
      - DEFAULT_DOMAIN=localhost:9999
      - INITIAL_API_KEY=12345
    ports:
      - 9999:8080
      - 2223:2222
    links:
      - ms_database
  ms_database:
    image: mcr.microsoft.com/mssql/server:2019-latest
    environment:
      ACCEPT_EULA: Y
      SA_PASSWORD: "Passw0rd!"

Once you SSH into the container with ssh root@localhost -p 2223 with password Docker!, you'll notice running echo $DB_DRIVER, echo $DB_PASSWORD, etc. just prints empty.

On the other hand, if you open a shell in the container via docker, those will print the expected values.

[j-sacra]

Adding the required env vars to /.profile seems to work!
Looks like I do need to force it to load by running source /root/.profile once in the ssh session. But after that a printenv shows that all exported vars are loaded correctly. Testing on Azure it also looks like these are persisted for the user which is nice as I don't need to run it everytime I want to use the CLI.

# Specify the path to the profile script you want to modify
PROFILE_SCRIPT="/root/.profile"

# Append export statements to the profile script
echo "export DB_DRIVER='${DB_DRIVER:-}'" >> "$PROFILE_SCRIPT"
echo "export DB_HOST='${DB_HOST:-}'" >> "$PROFILE_SCRIPT"
echo "export DB_NAME='${DB_NAME:-}'" >> "$PROFILE_SCRIPT"
echo "export DB_PASSWORD='${DB_PASSWORD:-}'" >> "$PROFILE_SCRIPT"
echo "export DB_PORT='${DB_PORT:-}'" >> "$PROFILE_SCRIPT"
echo "export DB_USER='${DB_USER:-}'" >> "$PROFILE_SCRIPT"
echo "export DEFAULT_DOMAIN='${DEFAULT_DOMAIN:-}'" >> "$PROFILE_SCRIPT"
echo "export DEFAULT_SHORT_CODES_LENGTH='${DEFAULT_SHORT_CODES_LENGTH:-}'" >> "$PROFILE_SCRIPT"
echo "export GEOLITE_LICENSE_KEY='${GEOLITE_LICENSE_KEY:-}'" >> "$PROFILE_SCRIPT"
echo "export INITIAL_API_KEY='${INITIAL_API_KEY:-}'" >> "$PROFILE_SCRIPT"
echo "export IS_HTTPS_ENABLED='${IS_HTTPS_ENABLED:-}'" >> "$PROFILE_SCRIPT"
echo "export MULTI_SEGMENT_SLUGS_ENABLED='${MULTI_SEGMENT_SLUGS_ENABLED:-}'" >> "$PROFILE_SCRIPT"
echo "export SHELL_VERBOSITY='${SHELL_VERBOSITY:-}'" >> "$PROFILE_SCRIPT"

Thanks for your availability and help in troubleshooting!