Issues with submitting ocular to umbrel-apps

[dennysubke]

Support guidelines

• [X] I've read the FAQs

Description

I'm encountering a recurring issue with my Docker setup where the backend service panics due to an invalid syntax error when attempting to parse an integer from an empty string. The .env file is skipped, which seems to be causing this issue. Below are the relevant details, including log excerpts, my Docker Compose configuration, and the .env file.

Error Logs:

2024-10-22T20:35:02.868Z    DEBUG    core/logger.go:37    .env file skipped
panic: strconv.ParseInt: parsing "": invalid syntax

goroutine 1 [running]:
github.com/simonwep/genesis/core.parseInt({0x0?, 0x1c?})
    /app/core/config.go:88 +0x65
github.com/simonwep/genesis/core.init.func2()
    /app/core/config.go:38 +0xd3
github.com/simonwep/genesis/core.init()
    /app/core/config.go:59 +0x47

Full Error Logfiles ...

The app is accessible. A password is also written into the .env file using gen-passwords.sh. Entering the generated password will then fail (See screenshot).

Environment

• Umbrel Home Server based on Debian
• Docker version: 20.x
• Backend Service: ghcr.io/simonwep/genesis

Expected behaviour

The .env file should be loaded correctly, and the backend service should not panic due to missing or invalid values.

The app will be made available via umbrel.local:3957.

Steps to reproduce

1. Run the provided Docker Compose setup.
2. Observe that the .env file is skipped during initialization.
3. The service panics when trying to parse an integer from an empty value.

Additional info

The .env file is skipped, causing the backend service to panic with a strconv.ParseInt error.

Here is the docker-compose.yml file I used and adapted to my environment:

services:
  backend:
    image: ghcr.io/simonwep/genesis:v1.3.1@sha256:57d3df842f9f877f200b8fa28ba9cbf0b9b4a126ee917da3d34f2a3679459958
    restart: on-failure
    volumes:
      - ${APP_DATA_DIR}/data:/app/.data:rw
    command: start
    environment:
      - GENESIS_PORT
      - GENESIS_DB_PATH
      - GENESIS_CREATE_USERS
      - GENESIS_AUTHORIZED_URIS
      - GENESIS_JWT_SECRET
      - GENESIS_JWT_TOKEN_EXPIRATION
      - GENESIS_JWT_COOKIE_ALLOW_HTTP
      - GENESIS_USERNAME_PATTERN
      - GENESIS_KEY_PATTERN
      - GENESIS_DATA_MAX_SIZE
      - GENESIS_KEYS_PER_USER
      - GENESIS_GIN_MODE
      - GENESIS_LOG_MODE

  frontend:
    image: ghcr.io/simonwep/ocular:v1.5@sha256:ee7a7a4272b37a1bc212a96c2057b3f5e66191f9c521296c8fd0a10373af77c6
    restart: on-failure

  nginx:
    image: nginx:1.24-alpine@sha256:77e5d4a6ad906c5d3793764085706577fa705b1dc6f244ea0241c4b5e2155385
    restart: on-failure
    ports:
      - "3957:80"
    volumes:
      - ${APP_DATA_DIR}/config/nginx.conf:/etc/nginx/nginx.conf
    depends_on:
      - backend
      - frontend

Attached is the corresponding .env file:

# Database location
GENESIS_DB_PATH=.data

# JWT secret known only to your token generator
GENESIS_JWT_SECRET=89b58a98c6927b455f750586668f6975

# JWT expiration in minutes
GENESIS_JWT_TOKEN_EXPIRATION=1440

# If the session cookie for the backend should be allowed to be sent over http
# Dangerous, it's best to run it behind a reverse proxy with https
GENESIS_JWT_COOKIE_ALLOW_HTTP=true

# Gin mode, either test, release or debug
GENESIS_GIN_MODE=release

# Zap logger, either production or development
GENESIS_LOG_MODE=production

# Port to listen on, leave it at 80 if you're using a reverse proxy
GENESIS_PORT=80

# Base url to listen for requests
GENESIS_BASE_URL=http://umbrel.local:3957/

# Use ! as suffix for the username to indicate that this user
# should be created as an admin. These can add, remove and edit users.
GENESIS_CREATE_USERS=admin!:c9b3f296397a079122fdf374e178bf27

# Allowed username pattern
GENESIS_USERNAME_PATTERN=^[\w]{0,32}$

# Allowed key pattern
GENESIS_KEY_PATTERN=^[\w]{0,32}$

# Maximum size of each key in kilobytes
GENESIS_DATA_MAX_SIZE=512

# Maximum amount of datasets per user
GENESIS_KEYS_PER_USER=5

The proxy configuration in the customized nginx.conf:

worker_processes 1;

events {
  worker_connections 1024;
}

http {
  server {
    listen 80;
    server_name umbrel.local;

    location /api/ {
      proxy_pass http://backend/;
    }

    location / {
      proxy_pass http://frontend;
    }
  }
}

[simonwep]

Thank you for the elaborate issue! I'm not sure how docker compose apps are deployed with/on umbrel (I'm not familiar with umbrel). Is it possible that their service skips loading the .env file? Usually, when you run docker compose up -d in the directory where the .env file is located it's values are loaded automatically. Maybe umbrel has a separate place where you configure env variables? For example on AWS you can specify it in the UI and not as a file somewhere.

I just took a quick glance at their docs where they explain how application based env variables are passed forwards, and it seems like they seem to be using APP_-prefixed variables for app specific values:

Keep in mind that things such as GENESIS_JWT_SECRET should be different on every individual deployment - if I'm seeing this correctly you want to submit it to an app-store, so GENESIS_JWT_SECRET is something that should be auto-generated on each deployment. Maybe even GENESIS_CREATE_USERS as if this app is public facing you can read the default login-credentials on GitHub.

[dennysubke]

Thank you for your comment and your quick answer. Can't I define the .env variables directly in the docker-compose file?

[simonwep]

That should be possible, however as I said for some (GENESIS_JWT_SECRET and GENESIS_CREATE_USERS) it should definitely be a secret and defined somewhere else / first on actual deployment.