Content
View differences
Updated by Oliver Günther over 10 years ago
Concerning the upgrade path towards 5.0, we have several interconnected tasks and documentation to address to ease new installations and upgrades to OpenProject 5.0.
### Tasks in-progress
- Documentation regarding managed repositories
- Rake task to identify repositories without projects
### 1\. Extend Packager.
The [addon-svn plugin](https://github.com/finnlabs/addon-repositories) was extended to also configure and write Git Smart HTTP to the Apache vhosts.
Ideally, we need some kind of multi-select in the wizard to let the user decide whether he wants No repositories, SVN, Git, or both.
Relevant work package for other installations: \#21032 https://community.openproject.org/work\_packages/21032
### 2\. Upgrade path from reposman to managed repositories
With 5.0, OpenProject gains the ability to manage repositories on disk itself (‘managed’ repositories).
This change concerns both on-premise and packager-based installations, as they previously used a cron job (reposman) to asynchronously
create, but not delete repositories.
On the QA systems, we have already experienced problems when simply switching to managed repositories in the same folders that
were previously used for serving SVN repositories.
A prominent case: Creating a new repository on the frontend fails due to a pre-existing repository with the same identifier, for which no project
long exists (simply due to reposman not deleting these repositories on disk before 5.0).
Relevant Work package: \#21029 https://community.openproject.org/work\_packages/21029
Relevant PR to remove reposman: https://github.com/opf/openproject/pull/3380
This PR contains a rake task for changing existing projects with repositories to managed, when the underlying served SVN directory is identical.
### 3\. Permission requirements due the in-process repository management
This again concerns all installations. As the OpenProject user is unprivileged, it can only create and manage the served directory
IF it is the owner and has the permission to write to all subfolders.
Here, a problem occurs with serving SVN repositories through mod\_svn / Apache.
Apache will obviously write to the ‘dav’ folder of a repository with its own permissions, and given its default umask, does not allow the group
to write to that folder - Thus deleting a repository from OpenProject fails after the first commit.
We solved this by introducing ACLs on the QAs, which work fine. However, for the Telekom (at least for the QA systems ITE1/2),
repositories are mounted on NFSv3 and we have no option to use ACLs there (even if NFSv3 theoretically supports it).
In this case, we have to let Apache and OpenProject run under the same unprivileged user to avoid this error.
As for packaged installations, I’m not entirely sure how we can address this. We would need to figure out whether ACLs are supported,
or continue the previous operation mode (using asynchronous creation of repositories).
### Tasks in-progress
- Documentation regarding managed repositories
- Rake task to identify repositories without projects
### 1\. Extend Packager.
The [addon-svn plugin](https://github.com/finnlabs/addon-repositories) was extended to also configure and write Git Smart HTTP to the Apache vhosts.
Ideally, we need some kind of multi-select in the wizard to let the user decide whether he wants No repositories, SVN, Git, or both.
Relevant work package for other installations: \#21032
### 2\. Upgrade path from reposman to managed repositories
With 5.0, OpenProject gains the ability to manage repositories on disk itself (‘managed’ repositories).
This change concerns both on-premise and packager-based installations, as they previously used a cron job (reposman) to asynchronously
create, but not delete repositories.
On the QA systems, we have already experienced problems when simply switching to managed repositories in the same folders that
were previously used for serving SVN repositories.
A prominent case: Creating a new repository on the frontend fails due to a pre-existing repository with the same identifier, for which no project
long exists (simply due to reposman not deleting these repositories on disk before 5.0).
Relevant Work package: \#21029
Relevant PR to remove reposman: https://github.com/opf/openproject/pull/3380
This PR contains a rake task for changing existing projects with repositories to managed, when the underlying served SVN directory is identical.
### 3\. Permission requirements due the in-process repository management
This again concerns all installations. As the OpenProject user is unprivileged, it can only create and manage the served directory
IF it is the owner and has the permission to write to all subfolders.
Here, a problem occurs with serving SVN repositories through mod\_svn / Apache.
Apache will obviously write to the ‘dav’ folder of a repository with its own permissions, and given its default umask, does not allow the group
to write to that folder - Thus deleting a repository from OpenProject fails after the first commit.
We solved this by introducing ACLs on the QAs, which work fine. However, for the Telekom (at least for the QA systems ITE1/2),
repositories are mounted on NFSv3 and we have no option to use ACLs there (even if NFSv3 theoretically supports it).
In this case, we have to let Apache and OpenProject run under the same unprivileged user to avoid this error.
As for packaged installations, I’m not entirely sure how we can address this. We would need to figure out whether ACLs are supported,
or continue the previous operation mode (using asynchronous creation of repositories).