EL9 stands for Enterprise Linux 9, it’s our way of describing RHEL, RockyLinux, AlmaLinux in their 9 flavor. It’s production ready since a while but there was still a blocking migration point for fellow users with EL7 deployment: Subversion. If you don’t use SVN, don’t read further and migrate!
For the SVN users, Tuleap with EL9 comes with a new Subversion version : 1.14, which is the version of Subversion on EL9. To make it short, Subversion 1.10, change the way it handles permission definitions. Unfortunately, there is not much we can do with that, Subversion administrators will have to review their permission scheme to ensure it’s still consistent after upgrade.
We strongly advise making this review BEFORE the EL9 migration in order to avoid unpleasant surprises such as impossible access or wide open access to your repositories.
So, what should I do now?
Step 1 : If I am Tuleap site administrator, I’m going to list all the repositories containing duplicated sections or groups (available from Tuleap 15.6) with the following command to be executed on the Tuleap server:
tuleap svn:repositories-with-duplicated-sections-access-file
This command will provide a list of all repositories that must be modified with its identifier, the project name and the SVN repository name. You could then contact the project administrators and explain them what to do.
Step 2 : If I am SVN administrator or project administrator, I go to the « Access Control » tab of the incriminated repository.
Even if those changes can’t be automated, a feature lets us catch the issues. You will find a warning message at the top of the page indicating some problems that have to be solved:
Now, it’s time to update the access control file.
What should I update?
Case 1 : One or several sections are duplicated
If one section is defined several times within the access file, an error will be raised and no more access will be possible for the section.
In the example below, no access will be possible for the section [/some/path]:
[/some/path]
@groupA= r
[/some/path]
@groupB = rw
The access control file must have only one section [/some/path] to work :
[/some/path]
@groupA= r
@groupB = rw
To help you, we have integrated a system letting the subversion administrators decide if they want default permissions (on repository root) managed by Tuleap or not.
The default permissions activation will generate a section [/] with permissions for project members depending on the project visibility.
If you do not want this section being handled by Tuleap, uncheck it. In this way, you could define your own permissions for the section [/].
Now, check on the other sections. Only one of each must be defined.
Case 2 : One or several groups are defined several times
In the previous SVN versions, if one group was defined several times, the last rule was applied. In the example below, @group had only read access:
[/some/path]
@group = rw
@group = r
Now, the duplicated groups will generate an error. Permissions on a group would have to be defined only one.
You will have to choose between:
[/some/path]
@group = rw
or
[/some/path]
@group = r
It will be probably the second solution in order to keep the current behavior.
Now, you probably better understand why this can’t be automated!