6.6 KiB
FAQ
Most frequently asked questions about the Gitea migration and guides to get started. If you are missing something here please contact Gitea admins
What Services are available?
I am confused about the login button situation
Since MFA is a hard requirement for all services that are exposed to the internet, we decided to only allow login with PSI MFA. This will reduce the amount of tokens you have to care for and we can offer you SSO from PSI (Not yet another token). If you have an active login / session with PSI MFA and your browser is allowed to use that token, you will be logged in automatically.
For CLI access there are other solutions see -> https://linux.psi.ch/documentation/services/gitea/authentication
Are there sub-organisations like subgroups in gitlab?
No. Gitea like GitHub only supports a flat hierarchy. But there are several things you could do to organize yourself and your group.
As a side note: The GUI of a GIT service is used for a very limited set of work with code. You can organize the structure on your PC however you want!
- Access specific organisations
- Create organizations according to the access privileges. There is code you want to share with the world, have it in a public org. Want to have it shared with PSI, use an internal one. If its only for your team you can use a private org.
- Simulate hierarchy
- Create organisations and/or repositories with "sub" names separated by
-or_. Examples: core-linux, os-linux, rhel-linux etc.
- User visibility
- Usage of least privilege is always preferred. Keep the access and therefore visibility of repos as tight as needed to reduce the clutter for your users.
But I'm using GIT only with HTTPS!
This is a small drawback we have to accept when having MFA enforced.
There are two ways to work around that:
- You create an access token in your account settings and use it as password
- You can use git-credential-oauth
- You start using SSH keys (suggested solution) For more details see: https://git-scm.com/book/en/v2/Git-on-the-Server-Generating-Your-SSH-Public-Key
!!! note If you work with docker or want to interact with the API (https://gitea.psi.ch) you have to create an access token. https://gitea.psi.ch/user/settings/applications
My LFS files are not tracked correctly
When you change the remote you have to re-push your LFS files explicitly.
git lfs push --all git@gitea.psi.ch:{org}/{repo}.git
I had a collaboration with non PSI Users on gitlab.psi.ch
All "ext-" users have been imported as restricted users and must be explicitly added to a project. If you are missing a user and you are sure it has a PSI account, message the ActiveDirectory team
I need a service user/token for automation
Since local login is disabled the user has to be created on the gitea console. Please contact the Gitea admins with your request.
The gitea token will then be mailed to you. If you are searching for the user in gitea GUI it will be named {org}-gitea
- Username (usually
{org}-gitea) - Scope the User needs access to (for example read:repository,write:packages)
- A valid E-Mail (this can be an email address that does not exist in reality) that is not registered yet in Gitea
Challenges of using PAT on an external collaboration platform and its alternatives
User access tokens acting like a password to all resources the user has access to. This can be dangerous. (The reason MFA login is enforced)
Therefore we offer two alternatives:
-
Like described above, we can create bot users that have no access permissions besides the ones explicitly given. (To respect least privilege)
-
Deployment of runners. Runners can be installed by the system owners and can be configured to execute precise actions with code from multiple repos that is not accessible to the user.
We encourage teams to switch to deployments done by runners, as it goes along recent software engineering best practices.
- Since the solutions above might not be feasible to you for reasons, there is the possibility to map Teams (Permission groups inside Organisations) to AD Groups. A long established process at PSI is requesting access to certain AD group by a user with SNOW. (Service Now) This greatly reduces the manual labor done by development teams responsible for repo access.
This can be done by the Gitea Gitea admins
My Project was migrated
remote:
remote: ========================================================================
remote:
remote: You can't push code to an archived project.
remote:
remote: ========================================================================
remote:
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
This Project was archived and is now available on https://gitea.psi.ch Please use following commands to update your local git:
-
git remote -v -
If the output starts with "origin https..." use option 1 otherwise 2
git remote set-url origin https://gitea.psi.ch/{Org}/{Repo}.gitgit remote set-url origin git@gitea.psi.ch:/{Org}/{Repo}.git
Ask the responsible person for this Project, where the repository has been moved to or you can browse Repos on https://gitea.psi.ch
More information about archived projects can be found here:
My project was migrated and I have git.psi.ch and/or gitlab.psi.ch links in wikis and papers
There will likely be no redirect from gitlab or git to gitea. Reason is the structural change in organisations vs groups and subgroups. What will be offered is a static site that points the user in the right direction from said URL's. -> https://gitea.psi.ch
What happens to submodules?
https://gitea.psi.ch/bruhn_b/submodules-fix This is not production tested and needs a bit more love to fix all branches and tags.
Miscellaneous
I use Firefox and SSO does not work
Try adding following options to your firefox configuration.
network.negotiate-auth.delegation-uris=.psi.ch
network.negotiate-auth.trusted-uris=.psi.ch
Windows Git Bash
If you get following error message:
HTTP 403 curl 22 The requested URL returned error: 403
Increase your post buffer:
git config --global http.postBuffer 0