Translated using DeepL

Machine-translated page for increased accessibility for English questioners.

Page in original, Czech language.

GitLab FI

GitLab is a web-based Git repository manager, similar to the well-known GitHub service. As well as managing repositories (which are referred to here as projects), GitLab also offers, in particular, a wiki and issue tracking.

Terms of use

  • It is forbidden to change the group path.
  • Repositories are not intended for storing very large files.
  • There is a hard limit of 3 GiB on the size of a single repository; once the total size exceeds 2 GiB, an email notification will be sent automatically.
    The size of individual repositories can be reduced via Project → Settings → Housekeeping.
  • There is a global limit of 100 repositories per user. This limit can be increased on request.
  • Please ensure you comply with the operating rules.

Log in

If you have an active account at the Faculty of Informatics, you can log in using LDAP authentication at the following URL:

https://gitlab.fi.muni.cz/

Enter your faculty login and password; your account will be created automatically after you log in for the first time.

Other login options

without having to enter a password

SSH key
Kerberos SPNEGO

External accounts

GitLab allows you to create a type of account that cannot own or create projects. They can only contribute to projects to which they are explicitly granted access. These accounts are referred to as external accounts. They can be used to grant access to projects for researchers and colleagues from other institutions, examiners or consultants for final theses, etc.

Managing external accounts

It is not possible to create external accounts directly in GitLab FI; however, staff and PhD students at FI (members of the ‘ fi-int ’ group) can create, manage and block external accounts via the external account management application in the Faculty Administration system. Documentation and help are available directly within the application.

Account Validity

A GitLab account linked to a faculty account is only valid if the faculty account is active and not suspended. If the faculty account is suspended or deactivated, access to GitLab, including SSH keys, will also be blocked.

SSH key

If you wish to work with a repository from your computer without having to enter your password every time, you can upload a public SSH key to your profile. Please follow the instructions; here we will only provide tips, particularly for Linux systems.

Creating an SSH key

ssh-keygen may ask you to enter a password whilst generating the key. This is not mandatory – using a key without a password is simpler – but a key with a password is more secure.

Using a key without a password

You can test whether the key is working by using the command 

ssh -i $cesta_k_PRIVATNIMU_klici git@gitlab.fi.muni.cz

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 (the file may not exist yet): 

Host gitlab gitlab.fi.muni.cz
    HostName gitlab.fi.muni.cz
    IdentityFile cesta_k_PRIVATNIMU_klici

For an explanation of each line, see ssh_config(5). Check that the command ` ssh git@gitlab ` produces the same output as above even without explicitly specifying the key.

Using a key with a password

If you use this type of key as if it had no password, every operation with GitLab will require the key’s password, which offers almost no advantages over standard login. With the help of an SSH agent, the key can be unlocked just once and then used repeatedly: 

ssh-agent $SHELL
ssh-add ~/.ssh/id_gitlab

The first command starts the agent, which then launches a new shell using the ` $SHELL` variable. If your shell does not set this variable, enter the path to the programme instead (e.g. ` /bin/sh`). Exiting the shell will also terminate the agent. For more information on the commands, see the man pages for ssh-agent(1) a ssh-add(1).

Please note that in older versions of this documentation and on various discussion forums, you may find instructions that use the command ` eval $(ssh-agent -c) ` or something similar. We do not recommend using this method, as it does not guarantee that the agent will terminate correctly.

Kerberos

GitLab allows you to log in to the interface and clone repositories using Kerberos tickets.

Use on Nymfe and Musa workstations

After logging into the graphical environment on the computers nymfe* nebo musa* , the user automatically receives a Kerberos ticket, which can be verified using the command klist: 

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

  • Log in

    When logging in via Mozilla Firefox and Google Chrome (or Chromium) browsers, you can use the ‘Kerberos Spnego’ button with a valid ticket instead of entering a password.
    GitLab Spnego

  • Cloning

    When cloning a repository, use the address from ‘Clone with KRB5’.
    GitLab KRB5 clone

  • Synchronisation

    The commands ` git pull ` and ` git push ` will also work without a password if you have a valid ticket.

Tip
You can explicitly request a ticket using the command ` kinit`. This may be useful when accessing a system remotely via SSH with SSH key authentication (e.g. on Aisu), where a ticket is not generated automatically.

Use from the Aisa, Anxur, Aura or Arachne servers

This login mechanism can generally also be used from other UNIX machines on which Kerberos is configured for the FI.MUNI.CZ domain.

  • Log in

    1. Logging in with a password

    If you enter a password when logging in to the server, you should have a ticket available immediately. Try the command: 

    login@aisa$ klist

    2. Logging in without a password

    Logging in without a password (e.g. using an SSH key) does not generate a ticket. If you do not have one, enter the command: 

    login@aisa$ kinit

    After entering your password, check at klist to ensure that you have a ticket.

  • Working with Git

    You can now use Git operations that rely on Kerberos authentication ( Cloning and Synchronisation as described above).

  • Restoring a ticket

    If the ticket expires, these operations will stop working. For security reasons, GitLab reports a non-existent repository for any unauthorised access (even if it actually exists), so the error message may be a little unexpected.

    In any case, check using klist that you have a valid ticket, and if not, generate a new one using the command kinit.

Configuring your own computer

This option can only be used for machines on the FI network. See also Restrictions on access to the FI network.

  • Kerberos

    To use Kerberos authentication on your own computer, you must have the tools for this authentication mechanism installed, e.g. from the packages krb5-user (Ubuntu, Debian) or krb5-workstation (RHEL, CentOS, Fedora). To obtain a ticket, use the command: 
    user@machine:~$ kinit login@FI.MUNI.CZ

  • Git

    Git may prompt for a password during cloning and synchronisation, which, when using Kerberos authentication, will result in the error ‘ HTTP Basic: Access denied ’.
    This can be resolved with 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 Firefox

    Enter about:config into the address bar. In the configuration, locate the key network.negotiate-auth.trusted-uris and add the value fi.muni.cz.

  • Chromium

    Launch the browser with the parameter --auth-server-whitelist=*.fi.muni.cz. It may be useful to create your own script that launches Chromium with this parameter, and place it in /usr/local/bin.

Documentation of services and functions

Documentation on GitLab’s features can be found on the help page. In particular, we recommend

Sharing a repository

If you want to make a repository accessible to other people beyond the project’s ‘visibility’ settings ( Private, Internal or Public), you can add them as members of the project; see adding members.

If you wish to grant access to a private or internal project to someone without a faculty account, and that person only needs access to download the project (i.e. they do not need access to Issues, the wiki, etc.), you can use Deploy keys (essentially read-only access to the project via an SSH key). If access to other services or the ability to contribute to the project is required, the project must be made public or an external account must be created for that person (please contact the administrators).

Email replies

The Faculty GitLab has the ‘Reply by Email’ feature enabled, which allows you to reply to comments, ‘issues’ and ‘milestones’ directly via email. However, for this to work correctly, it is important to follow a few rules:

  • reply directly to the email you have received using the ‘ Reply ’ function; do not write a new email
  • write your reply only above the quote, or preferably delete the quote, as GitLab may not remove it correctly
  • if you digitally sign your emails, it is best not to include your signature in replies to GitLab

You can use Markdown in your email and add attachments; these will then appear as attachments in your reply on GitLab.

Backup

Git Repositories

Both user and group repositories are automatically backed up on a regular basis as git bundles . Backups are performed early every morning. To request the restoration of a repository that has been accidentally deleted, please contact .

It is not usually possible to restore a repository directly to GitLab, but we will provide a bundle containing a full backup and, where applicable, additional files containing an incremental backup. This backup can be restored as follows:

  • Files

    Let us assume there is a full backup in the file repo.9RhwIP.0.bundle and two incremental backups in the files repo.9RhwIP.1.bundle and repo.9RhwIP.2.bundle.

  • Restoring a full backup

    Create a clone of the repository from the full backup into the directory repo: 
    git clone --mirror repo.9RhwIP.0.bundle repo

  • Incremental backups

    Move the full backup so that you can use the cycle: 
    mv -i repo.9RhwIP.0.bundle repo.9RhwIP.bundle
    Restore the incremental backups: 
    for bundle in repo.9RhwIP.*.bundle; do
    git -C repo remote set-url origin "${PWD}/${bundle}"
    git -C repo remote update
done

  • Restore to GitLab FI

    If you wish to return the repository to GitLab FI, create a new project for it and run the following commands: 
    git -C repo remote set-url origin ${url_repozitáře}
git -C repo push --all
git -C repo push --tags
Project wiki pages are also stored as Git repositories and can therefore be restored from backups in a similar way.

Issues, Milestones, …

Other project components (e.g. Issues) are backed up alongside the GitLab database. However, restoring these backups is complex and only the overall state of the database can be restored.

For this reason, these backups are intended solely for recovery in the event of a total outage. A complete recovery of individual projects (excluding repositories, see above) is not possible.

For information on backing up other systems, see the document Backing up at FI.

Other useful features

The Faculty of Informatics holds a licence for GitLab Ultimate, which includes all features, including those of the Starter and Premium versions. You will find a list and comparison of the versions on the linked page. Of these, the following may be of interest to users at the Faculty of Informatics:

Further links and guides