This week we added a handful of open-source apps as one-click templates on our platform: Gitea, Wiki.js, HedgeDoc, Etherpad and Mattermost, each with its own PostgreSQL (our preferred db). All official images, nothing patched.
Four of them broke in ways I couldn't find in any of their docs. None of this is specific to us so we thought we would share so that anyone else running or planning to run any of these in containers will not lose an afternoon, loads of hair and send the coffee bill through the roof.
1. Wiki.js: SQLITE_CANTOPEN, over and over
The container starts, the health check is happy, and the log says this ten times before it gives up:
Loading configuration from /wiki/config.yml... OK
[MASTER] info: Connecting to database...
[MASTER] error: Database Connection Error: SQLITE_CANTOPEN undefined:undefined
[MASTER] warn: Will retry in 3 seconds... [Attempt 1 of 10]
The image runs as the user node, not root. When you mount a brand new named volume on a folder that doesn't exist in the image, like /data, Docker creates it owned by root. So node can't create the SQLite file.
This is the compose that breaks (it's the one from an unanswered GitHub question, and it was ours too):
services:
wiki:
image: ghcr.io/requarks/wiki:2.5
environment:
DB_TYPE: sqlite
DB_FILEPATH: /data/db.sqlite3
volumes:
- wiki-data:/data
volumes:
wiki-data:
And this one works. /wiki/data already exists in the image and belongs to node, and Docker gives a new volume the same owner:
services:
wiki:
image: ghcr.io/requarks/wiki:2.5
environment:
DB_TYPE: sqlite
DB_FILEPATH: /wiki/data/db.sqlite3
volumes:
- wiki-data:/wiki/data
volumes:
wiki-data:
If you already created the volume on /data, remove it first, or it stays owned by root:
docker volume rm <project>_wiki-data
Running the container as root also works, but was really not an option for us and you really don't need to. And for anything beyond trying it out, Wiki.js recommends PostgreSQL anyway, which is what we use now. (I answered the GitHub question here: requarks/wiki#7106.)
2. HedgeDoc 1.12 won't start if DATABASE_URL is set
This one is just a plain bug. If you give HedgeDoc a DATABASE_URL variable, even with CMD_DB_URL set as well, it dies at once:
error: uncaughtException: Cannot read properties of undefined (reading 'dbURL')
TypeError: Cannot read properties of undefined (reading 'dbURL')
at Object.<anonymous> (/hedgedoc/lib/config/index.js:153:15)
One line reproduces it:
docker run --rm -e CMD_DB_URL=sqlite:///tmp/db.sqlite -e CMD_SESSION_SECRET=test -e DATABASE_URL=postgres://u:p@localhost:5432/db quay.io/hedgedoc/hedgedoc:latest
Take out DATABASE_URL and the same command starts fine.
What happens is the image ships an empty config.json. DATABASE_URL is read as an old-style setting, and the code that merges the old and new settings then tries to find something in the file config that is not there.
Why it matters: lots of hosts give every app a DATABASE_URL (Heroku-style platforms do, and so do we), and on those HedgeDoc can't start at all. Until it's fixed, give the container CMD_DB_URL only. I reported it with the repro: hedgedoc/hedgedoc#6905.
3. Gitea's setup page 'guesses' the wrong address
On first start, Gitea shows its install page with everything pre-filled, including "Gitea Website URL". It guesses that from whatever address the first request came in on. Ours sits behind a login proxy, so it picked up the proxy's redirect, with a ?_gate_... parameter on the end. Click Install like that and every clone link and every email carries the wrong address.
Our preferred option is to set it before the first start instead, so in the gitea container's environment somethign like this:
GITEA__server__ROOT_URL: https://git.example.com/
GITEA__server__DOMAIN: git.example.com
Two small things from the same day:
GITEA____APP_NAME: My Git # top-level settings take FOUR underscores; GITEA__APP_NAME is silently ignored
GITEA__server__DISABLE_SSH: "true" # if only HTTPS reaches the server, or the clone box offers SSH links that can't work
4. Mattermost: "This invite link is invalid"
Invite people, Copy invite link, send it, and the new person gets:
This invite link is invalid
Please speak with your Administrator to receive an invitation.
Looking at Mattermost's API about the same link explains it:
{"id":"api.team.get_invite_info.not_open_team","message":"Invite is invalid because this is not an open team."}
Our test team was created using the API with type I (invite only). The Public/Private choice in Team settings doesn't change that type, so the link never worked. A new team created in Mattermost's own screens gets type O and its link works straight away. If you create teams through the API, send "type": "O".
Two more traps from the same afternoon:
- Test the link in a private window. In a browser that's already signed in, it just opens the team as you, so it looks broken when it isn't.
- If the app sits behind a login (ours does while it's set to Private), the people you invite hit that login first.
That's it
Those four cost us most of a day. We've built the fixes into our templates now, so this is how we run them: each app with its own PostgreSQL wired in, on its own HTTPS address. If you'd rather not deal with any of this yourself: Gitea, Wiki.js, HedgeDoc, Etherpad, Mattermost.
Which app would you want next?
