Top Menu

Jump to content
Home
    Modules
      • Projects
      • Activity
      • Work packages
      • Gantt charts
      • Calendars
      • Team planners
      • Boards
      • News
    • Getting started
    • Introduction video
      Welcome to OpenProject Community
      Get a quick overview of project management and team collaboration with OpenProject. You can restart this video from the help menu.

    • Help and support
    • Upgrade to Enterprise edition
    • User guides
    • Videos
    • Shortcuts
    • Community forum
    • Enterprise support

    • Additional resources
    • Data privacy and security policy
    • Digital accessibility (DE)
    • OpenProject website
    • Security alerts / Newsletter
    • OpenProject blog
    • Release notes
    • Report a bug
    • Development roadmap
    • Add and edit translations
    • API documentation
  • Sign in
      Forgot your password?

      or sign in with your existing account

      Google

Side Menu

  • Overview
  • Activity
    Activity
  • Roadmap
  • Work packages
    Work packages
  • Gantt charts
    Gantt charts
  • Calendars
    Calendars
  • Team planners
    Team planners
  • Boards
    Boards
  • News
  • Forums

Content

General discussion
  1. OpenProject
  2. Forums
  3. General discussion
  4. Set up Managed Repository

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)

RE: Set up Managed Repository - Added by Christopher Bonitz 14 days ago

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.

# This fixes COPY for webdav over https
#RequestHeader edit Destination ^https: http: early

ProxyPass /git !

  # see https://www.kernel.org/pub/software/scm/git/docs/git-http-backend.html for details
  # needs mod_cgi to work -> a2enmod cgi
  SetEnv GIT_PROJECT_ROOT /var/db/openproject/git
  SetEnv GIT_HTTP_EXPORT_ALL
  ScriptAlias /git/ /usr/lib/git-core/git-http-backend/
  <Location /git>
    Order allow,deny
    Allow from all

    AuthType Basic
    AuthName "OpenProject GIT"
    Require valid-user

    #Docs are wrong, this in incorrect
    #PerlAccessHandler Apache::Authn::OpenProject::access_handler
    #PerlAuthenHandler Apache::Authn::OpenProject::authen_handler

    #Looked inside the perl script, this is the actual method to call
    PerlAccessHandler Apache::OpenProjectAuthentication::access_handler
    PerlAuthenHandler Apache::OpenProjectAuthentication::authen_handler

    OpenProjectGitSmartHttp yes
    OpenProjectUrl 'http://127.0.0.1:6000'
    OpenProjectApiKey '...redacted...'
  </Location>

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)

[Fri Apr 25 08:07:00.764879 2025] [:error] [pid 34603:tid 34603] Failed authorization for christopher.bonitz on http://127.0.0.1:6000/sys/repo_auth: 422 Unprocessable Content

The command "openproject logs" initially gave me nothing, but enabling debug did eventually give a stacktrace.

Apr 25 08:08:37 Info-Matic openproject[36208]: F, [2025-04-25T08:08:37.360522 #36208] FATAL -- : [2ae17fb9-42da-4ac0-891b-f846ac7bc581]
Apr 25 08:08:37 Info-Matic openproject[36208]: [2ae17fb9-42da-4ac0-891b-f846ac7bc581] ActionController::InvalidAuthenticityToken (Can't verify CSRF token authenticity.):
Apr 25 08:08:37 Info-Matic openproject[36208]: [2ae17fb9-42da-4ac0-891b-f846ac7bc581]
... long 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 :-)


RE: RE: Set up Managed Repository - Added by Christopher Bonitz 14 days ago

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.

/opt/openproject/vendor/bundle/ruby/3.4.0/gems/actionpack-8.0.2/lib/action_controller/metal/request_forgery_protection.rb    

self.allow_forgery_protection = true

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.

  • (1 - 2/2)
Loading...