Rules of use
- it is forbidden to change your name even though GitLab allows it
- it is forbidden to change the group path
- repositories are not intended for embedding very large files
- size of one repository has a hard limit of 3 GiB, after exceeding 2 GiB in total, an e-mail alert will be sent automatically
( Project → Settings → Housekeeping can reduce the size of individual repositories)
- observe adherence operating rules
If you have an active account at the Faculty of Informatics, you can log in using LDAP authentication at the following URL:
Enter your faculty login and password, the account will be created automatically after the first login.
GitLab allows you to create account types that cannot be owned or created by projects. They can only contribute to projects to which they have explicit access. These accounts are called external accounts. They can be used to make projects accessible to researchers and colleagues from other institutions, reviewers or final thesis consultants, etc.
It is not possible to create external accounts directly in GitLab FI, FI employees (group members)
fi-int ), but can create, manage, and block external accounts in
external account management application in the Faculty Administration. You can find documentation and help directly in the application.
A GitLab account associated with a faculty account is valid only if the faculty account is active and unlocked. If a faculty account is blocked or terminated, access to GitLab, including SSH keys , will also be blocked.
If you want to work with a repository from your computer without having to enter a password every time, you can upload a public SSH key to your profile. Follow instructions , here are only tips for UN * X systems.
Creating SSH keys
ssh-keygen may ask for a password when creating a key. It is not mandatory, it is easier to use the key without a password, but the password key is safer.
Using a key without a password
You can test the functionality of the key with the command
ssh -i $cesta_k_PRIVATNIMU_klici firstname.lastname@example.org
The output of the command should be similar to the following:
Welcome to GitLab, (Jmeno, Prijmeni) Connection to gitlab.fi.muni.cz closed.
Add the following lines to
~/.ssh/config (file may not exist yet):
Host gitlab gitlab.fi.muni.cz HostName gitlab.fi.muni.cz IdentityFile cesta_k_PRIVATNIMU_klici
For the meaning of each line see
ssh_config(5) . Try that command
ssh git@gitlab has the same output as above without explicit keying.
Using a password key
If you use this type of key as if it were without a password, every operation with GitLab will require a password for the key, which offers almost no advantages over normal login. Using the SSH agent, the key can be unlocked only once and then reused:
ssh-agent $SHELL ssh-add ~/.ssh/id_gitlab
The first command starts the agent, which then starts a
new shell from the variable
$SHELL . If your shell does not set this variable, enter the path to the program instead (e.g.
/bin/sh ). Exiting the shell also exits the agent. For more information on commands, see the man page for
Note that in the older version of this documentation and in various discussion forums you can find the procedure that uses the command
eval $(ssh-agent -c) or similar to him. We do not recommend using this procedure as it does not guarantee a proper termination of the agent.
GitLab allows you to log into the interface and clone repositories using Kerberos tickets .
Use at Nymfe stations
After logging into the computer's graphical environment
nymfe* the user automatically receives a Kerberos ticket, which can be verified by command
login@nymfe01:~$ klist Ticket cache: FILE:/tmp/krb5cc_15291 Default principal: login@FI.MUNI.CZ Valid starting Expires Service principal 12/17/2019 16:16:56 12/18/2019 16:16:51 krbtgt/FI.MUNI.CZ@FI.MUNI.CZ
LoginWhen signing in Mozilla Firefox and Google Chrome (or Chromium), you can use the Kerberos Spnego button instead of entering a password with a valid ticket.
CloningUse the Clone with KRB5 address to clone the repository .
git pushthey will also work without a password with a valid ticket.
You can explicitly request a ticket by order
kinit . This can be useful for remote SSH access with SSH key authentication (eg Aisu) where the ticket is not automatically created.
Set up your own computer
KerberosTo use Kerberos authentication on your own computer, you must have tools for this authentication mechanism installed, eg from packages
krb5-user(Ubuntu, Debian) or
krb5-workstation(RHEL, CentOS, Fedora). Use the command to get a ticket:
user@machine:~$ kinit login@FI.MUNI.CZ
GitGit may require you to enter a password when cloning and synchronizing, which will result in an error when Kerberos are authenticated
HTTP Basic: Access denied.
This can be solved by the following command:
# nastavení pro uživatele user@machine:~$ git config --global http.emptyAuth true # nastavení pro celý systém user@machine:~$ sudo git config --system http.emptyAuth true
Mozilla FirefoxType in the address bar
about:config. Locate the key in the configuration
network.negotiate-auth.trusted-urisand add a value
ChromiumStart the browser with the parameter
--auth-server-whitelist=*.fi.muni.cz. It may be helpful to create your own script that will run Chromium with this parameter and place it in
Basics of use
For documentation on GitLab features, see help . Especially recommended
Share a repository
If you want to access the repository to other people beyond the "visibility" project (Private, Public or Internal), you can set them as members (members) of the project, see adding members .
If you want to make a private or internal project available to a person without a faculty account and you only need access to download the project (ie does not need access to Issues, wiki, etc.), you can use Deploy keys (basically read-only access to the project using the SSH key). If access to additional services or the ability to contribute to the project is required, the project must be published or an external account must be created for the person (ask administrators).
Faculty GitLab has the Reply by E-mail feature, which allows you to reply to comments, "issues" and "milestones" directly by e-mail. However, it is important to adhere to a few rules for proper operation:
- reply directly to the email you received using the feature
Reply, do not write a new email
- write your answer only above the quote or best delete the quote, as GitLab may not remove the quote correctly
- if you digitally sign your emails, don't include your signature in GitLab
You can use Markdown in the email and add attachments, which will then appear as attachments in the GitLab reply.