Content
Set up Managed Repository
Added by Michael J over 1 year ago
Hello.
I am looking to set up a managed git repository inside of a new installation of OpenProject 13.1.2 running on Ubuntu 22.04.3. Following the repository integration documentation here: https://www.openproject.org/docs/installation-and-operations/configuration/repositories/, it seems like this should be possible. This article warns that it is a good bit out of date, so using the advanced configuration guide https://www.openproject.org/docs/installation-and-operations/configuration/ to fill in some of the blanks, here is what I have tried:
The repository documentation says that managed repositories have to be manually enabled by adding an entry to the configuration.yml
file. The advanced config article warns that this file has been deprecated, so I have not attempted to make any changes there. Instead, looking at the contents of configuration.yml
, I can see that the setting I'm looking for references a GIT_REPOSITORIES
environment variable. Following the configuration article, using the command openproject config
I see that this variable is not set. I then created the /srv/repositories/git
directory and set the variable using sudo openproject config:set GIT_REPOSITORIES=/srv/repositories/git
. (I doubt that there's anything special about this particular file path, I just thought it made the most sense to use the same path that was used in the example). After that, running openproject config
again, I can see that this variable has indeed been updated. So far, so good.
Then the advanced config article says that after changing a variable, the sudo openproject configure
command must be run, so I do that. Looking through the output of this command, I see No repositories have been configured. Skipping configuration.
Afterwards, running openproject config
shows that the GIT_REPOSITORIES
variable has been reset back to its original blank value. And of course, there was no noticeable change inside the application.
I'm sure there must be something I'm missing here, but I've gone through all of the documentation I can find, and I have not found any solution. Any insight that someone more familiar with this process might be able to provide to help me out would be greatly appreciated.
Thank you.
Replies (2)
I found your insight in the configuration.yml to be of some help, but have not had any luck either.
Just migrated a old OpenProject installation (5 years old) that had a working GIT managed repository, but after wasting 1.5 workdays on trying to revive the service, I'm beginning to loose hope.
I was able to deduce something though, and wanted to share the insight.
Running with a mostly default installation, I answered yes to the repository in the configuration phase.
Followed this article as well: https://www.openproject.org/docs/installation-and-operations/configuration/repositories/
Once I dived into it and realized we need to apply some apache magic on top, I mostly used the guides from the official links.
However I found a fault, that got me "one step" closer.
To enable the authentication, we need to enable a perl script, both before the actual vhost, much like this.
PerlSwitches -I/srv/www/perl-lib -T
PerlLoadModule Apache::OpenProjectAuthentication
And then afterward in the vhost.
Now the fault I fixed was around the PerlAccessHandler and PerAuthenHandler, it seems they didn't reach the desired method. (I'm not a perl guy though)
So changing that made my error logs happier, although now I'm left with this when I log in. (apache error log)
The command "openproject logs" initially gave me nothing, but enabling debug did eventually give a stacktrace.
I'm still hunting the bug, but the way I see it, it would be more honest to put a banner on top of managed repositories letting users know, this feature is unsupported.
It used to work great, but someone forgot to do their maintenance :-)
Finally fixed my installation, after two full workdays.
In the end, something during the migration had failed to update the local git include scripts, eventually the in-built did work out.
I'll leave the adaption to hint a future troubleshooter, since there is not a lot of material on the subject.
In the end, once I got to the phase where authentication did "attempt" to log in, it failed with "Can't verify CSFR token authenticity"
This in turn was not easy to fix, I ended up doing a "no-no", modified the ruby code causing issue.
I may not be an expert on CORS, but I'm sure my git enabled visual studio won't get hacked by man-in-the-middle attack.
Really don't appreciate the CORS bs.