Manual intervention required when updating Gitea to v1.20.0 on Void

2023-08-01

My local Gitea instance runs on a Raspberry Pi 4 running Void Linux. I'm quite happy with Void itself. It's been totally rock solid and reliable since I got all of the kinks worked out about a week after the initial install. Gitea, however, has been a bit of a PITA on a few occasions prior to moving to Void, and the latest package upgrade I ran managed to break a few things. It's all back up and running now, but not without some frustration.

After some troubleshooting, I found an obsolete setting in the config file, which once removed at least allowed the daemon to start. However, connecting to the machine with the `git` user failed with a nice cryptic error message:

PTY allocation request failed on channel 0
2023/07/31 23:53:42 ...s/setting/setting.go:109:LoadCommonSettings() [F] Unable to load settings from config: unable to create chunked upload directory: /usr/bin/data/tmp/package-upload (mkdir /usr/bin/data: permission denied)

As it turns out, Gitea cannot run without certain files and directories existing, which it attempts to create on launch if they aren't there. They're supposed to be created in the home directory of the user running Gitea, in this case `git`, but if Gitea is run without having $HOME set then it will look for those paths relative to the binary, which is definitely not the desired behavior. More accurately, it needs the variable GITEA_WORK_DIRECTORY, but it derives that value from $HOME.

What does this have to do with ssh? Gitea attempts to automatically manage the .ssh directory of it's user, and sets itself as a custom command to handle keys in .ssh/authorized_keys.

command="/usr/bin/gitea --config=/etc/gitea/app.ini serv key-2",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,no-user-rc,restrict ssh-ed25519 <redacted>

Now, since we've established that Gitea won't start without $GITEA_WORK_DIR being set, ssh can't authorize the git user using pubkey authentication because Gitea chokes, even though Gitea is running away happily as a daemon, having gotten the vars set correctly in the `run` script which runit uses to start it up. I'm not thrilled with this design, but there's the bug. And the fix is to change .ssh/authorized keys so that the handler is run with the environment var set:

command="env GITEA_WORK_DIR=/var/lib/gitea /usr/bin/gitea --config=/etc/gitea/app.ini serv key-2",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,no-user-rc,restrict ssh-ed25519 <redacted>

Here's hoping that an upcoming release makes this all less brittle. I don't like that it's overwriting .ssh/authorized_keys. I get the reason, but messing with configs is why I hate "user friendly distros" and prefer to work with FreeBSD or Linux distros which follow the KISS principle like Void. Once I've written a config, I expect it to never change unless I edit it myself. As for getting configuration from environment vars, that's kind of stupid and redundant when your application actually has a config file.

Tags for this page

All content for this site is licensed as CC BY-SA.

Finger

Contact

-- Response ended

-- Page fetched on Mon May 20 11:41:08 2024