FS#70753 - [gitlab] RuntimeError: secrets.yml is a symlink
Attached to Project:
Community Packages
Opened by Caleb Maclennan (alerque) - Saturday, 08 May 2021, 08:29 GMT
Last edited by Doug Newgard (Scimmia) - Saturday, 08 May 2021, 12:22 GMT
Opened by Caleb Maclennan (alerque) - Saturday, 08 May 2021, 08:29 GMT
Last edited by Doug Newgard (Scimmia) - Saturday, 08 May 2021, 12:22 GMT
|
Details
The current arrangement with config files in `/etc` and
necessary links from the `/usr` directories makes perfect
sense to me, but Gitlab (at least as of a fresh install of
13.10.3) does not like this one:
> Unable to load application: RuntimeError: File \"/usr/share/webapps/gitlab/config/secrets.yml\" is a symlink that does not point to a valid file I can't figure out how to make GitLab read this from the `/etc/webapps/gitlab` directory instead of the symlink. |
This task depends upon
Closed by Doug Newgard (Scimmia)
Saturday, 08 May 2021, 12:22 GMT
Reason for closing: Duplicate
Additional comments about closing: FS#67173
Saturday, 08 May 2021, 12:22 GMT
Reason for closing: Duplicate
Additional comments about closing:
Comment by
Caleb Maclennan (alerque) -
Saturday, 08 May 2021, 09:46 GMT
This is a weird one. If I run `rake gitlab:backup:restore`, the
gitlab-puma service will fail to start with the error above. But
if I copy the file from /etc to /usr (overwriting the symlink),
then Puma starts fine. So far as expected given the error. But
then I can delete the copy of the config in /usr and put the
symlink back and everything still works fine! I think this symlink
check is only being run during some sort of first-run phase,
perhaps while it updates some database keys or something. It does
not attempt to write the config.yml file, my original one is fine.
Once it does whatever else it does, it no longer cares if the
config is symlinked.