migrate database if app.ini found

[pciavald]

Hi,

For my installation of gitea, I needed unattended initial config. @techknowlogick told me on Discord that it could be done using then new migrate command, gitea migrate -c /data/gitea/conf/app.ini.

I've added in the Docker entrypoint:

• check if /data/gitea/conf/app.ini exists
• change mode and owner
• migrate database

It works correctly on my machine, in my docker-compose the data volume is mapped with only the config file and the platform auto-inits. However I can see in the logs this error which does not affect behaviour:

migrate: /data/gitea/conf/app.ini: Permission denied

[codecov-io]

Codecov Report

❗ No coverage uploaded for pull request base (master@cbc14df). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master    #5290   +/-   ##
=========================================
  Coverage          ?   37.83%           
=========================================
  Files             ?      322           
  Lines             ?    47489           
  Branches          ?        0           
=========================================
  Hits              ?    17968           
  Misses            ?    26935           
  Partials          ?     2586

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cbc14df...81be951. Read the comment docs.

[techknowlogick]

Please use ${USER}, ${USER_UID}, and ${USER_GID} variables instead of hardcoding them.

[pciavald]

${USER_UID}, ${USER_GID}, $UID and $GID are undefined, i'll use $USER:$USER is that ok ?

[pciavald]

I see these variables (USER_UID and USER_GID) should be defined by default to 1000 if not specified by the docker-compose environment key, and they're not defined in my docker-compose.

So I don't understand why they are undefined, i've echoed them in the entrypoint and only USER was defined. Using $USER:$USER in the chown may create problems if a developer defines the USER_UID and USER_GID in their env.

[zeripath]

The original entry point script just checks for the variables and if they're there does something. That's why they're undefined.

You may have to adjust it to define the variables if they're not there or empty.

if [ -z "${USER_GID}" ]; then
  USER_GID="`id -g ${USER}`"
fi

And similarly for UID. Otherwise I'd be suspicious that the chown could choose the wrong UID and GID in cases were they were set explicitly - but I'd happily defer to more expert opinion on this.

[techknowlogick]

Ah yes. You are right @pciavald, I missed that they were undefined. I think that @zeripath's approach of setting a default for the values is a good one.

[apricote]

I think there is a small security issue caused by this PR

[apricote]

This will allow anyone with access to the server to read the app.ini, exposing any credentials (database, metrics, smtp).

[zeripath]

Hmm... I guess you're right. I guess this should be 600. In some ways this is not so bad because this for docker - you shouldn't have other users on it in any case, that's not the docker way.

[apricote]

Is there any reason to change the file permissions?

[zeripath]

Possibly not. If you've not set the INSTALL_LOCK setting in your app.ini and you've got the wrong mode then you won't be able to use /install. However I guess we shouldn't be being preventing people from shooting themselves in the foot like that. Pop a PR on if you're able otherwise I can when I'm next at a dev box. @techknowlogick do you agree that perhaps we shouldn't changing the mode here?

[zeripath]

@pciavald What was your reasoning for changing the mode?

[zeripath]

@techknowlogick I think unfortunately there may still be problems with this.

The correct place for automigration is likely within the gitea script within the s6 folder. That would require a little refactoring of that to make it work.

However a simple improvement is that we should change the migrate line to:

(cd /app/gitea; exec su-exec $USER /app/gitea/gitea migrate)

as per my comment:

#5688 (comment)

Then this will more closely match how docker starts Gitea so if people have used relative paths etc in their app.ini we're not affected by these.

I won't have a chance to write a pr for this for several days so if you can or get a friendly minion please do.