From c8da0d60905411b07e2df69026abf9945589aa7a Mon Sep 17 00:00:00 2001 From: ebner Date: Thu, 24 Jul 2025 15:46:49 +0200 Subject: [PATCH] fixed some typos --- services/gitea/gitea-faq.md | 60 +++++++++++++++++++++++++------------ 1 file changed, 41 insertions(+), 19 deletions(-) diff --git a/services/gitea/gitea-faq.md b/services/gitea/gitea-faq.md index d23c0aaa..df3623ff 100644 --- a/services/gitea/gitea-faq.md +++ b/services/gitea/gitea-faq.md @@ -1,70 +1,88 @@ # FAQ + Most frequently asked questions about the Gitea migration and guides to get started. -If you are missing something here please contact [Gitea Project](mailto:gitea@psi.ch) +If you are missing something here please contact [Gitea admins](mailto:gitea@psi.ch) + ## What Services are available? + - [GIT](https://gitea.psi.ch) - [Pages](https://linux.psi.ch/services/user-guide/gitea/gitea-pages.html) - [Snippets](https://linux.psi.ch/services/user-guide/gitea/gitea-snippets.html) - [Runners](https://linux.psi.ch/services/user-guide/gitea/gitea-runner.html) + ## 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 automaticaly. ## Are there sub-organisations like subgroups in gitlab? -No. Gitea is a GitHub fork and supports a flat hirarchy. But there are several things you could do to organize you and your group. +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! 1. Access specific organisations -- Create orgs according to the access priviledges. 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. +- Create organizations according to the access priviledges. 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. -2. Simulate hirarchy -- Create organisations with "sub" names, like core-linux, os-linux, rhel-linux etc. +2. Simulate hierarchy +- Create organisations and/or repositories with "sub" names separated by `-` or `_`. Examples: core-linux, os-linux, rhel-linux etc. 3. User visibility -- Usage of least privilege is always prefered. Keep the access and therefore visibility of repos tight as needed to reduce the clutter for your users +- Usage of least privilege is always prefered. 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: -1. You create a access token in your account settings and use it as password -2. You can use [git-credential-oauth](https://github.com/hickford/git-credential-oauth) -3. You start using SSH keys which we would suggest you to do - - https://git-scm.com/book/en/v2/Git-on-the-Server-Generating-Your-SSH-Public-Key -[!NOTE] +This is a small drawback we have to accept when having MFA enforced. + +There are two ways to work around that: +1. You create an access token in your account settings and use it as password +2. You can use [git-credential-oauth](https://github.com/hickford/git-credential-oauth) +3. 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 explicedly. `git lfs push --all git@gitea.psi.ch:{org}/{repo}.git` +When you change the remote you have to re-push your LFS files explicedly. + +```bash +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 AD Team](mailto:winservsupport@psi.ch) +If you are missing a user and you are sure it has a PSI account, message the [ActiveDirectory team](mailto:winservsupport@psi.ch) + ## 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 [Gitea Project](mailto:gitea@psi.ch) with your request. +Since local login is disabled the user has to be created on the gitea console. Please contact the [Gitea admins](mailto:gitea@psi.ch) 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-bot - Username (usually org-gitea) - Scope the User needs access to (for example read:repository,write:packages) - A valid E-Mail that is not registred yet in Gitea + ### Challenges of using PAT on a external collaboration platform and its alternatives + User access tokens acting like a password to all ressources the user has access to. This can be dangerous. (The reason MFA login is enforced) + Therefore we offer two alternatives: 1. Like described above, we can create bot users that have no access permissions besides the ones explicetly given. (To respect least privilege) + 2. 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. 3. Since the solutions above might not be feasable to you for reasons, there is the possiblity 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 responisble for repo access. -This can be done by the Gitea [Gitea Admins](mailto:gitea@psi.ch) +This can be done by the Gitea [Gitea admins](mailto:gitea@psi.ch) ## My Project was migrated -``` +```bash remote: remote: ======================================================================== remote: @@ -91,6 +109,7 @@ Ask the responsible person for this Project, where the Repositoy has been moved More information about archived projects can be found here: - https://docs.gitlab.com/user/project/working_with_projects/#archive-a-project + ### 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 @@ -99,10 +118,13 @@ What will be offered is a static site that points the user in the right directio 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. + ## Miscellanious + ### I use Firefox and SSO does not work Try adding following options to your firefox config. -``` + +```bash network.negotiate-auth.delegation-uris=.psi.ch network.negotiate-auth.trusted-uris=.psi.ch ```