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. In addition to managing repositories (which are called projects here), GitLab can also do Wiki and Issue tracking.

Usage rules

  • It is forbidden to change the group path.
  • Repositories are not intended for uploading very large files.
  • The size of a single repository has a hard limit of 3 GiB, exceeding 2 GiB in total will automatically send a warning email.
    The size of individual repositories can be reduced by Project → Settings → Housekeeping.
  • There is a global limit of 100 repositories for users. The limit can be increased on request.
  • Make sure to follow the operating rules.

Login

If you have an active account with the School of Computer Science, you can log in using LDAP authentication at the following URL:

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

Enter your faculty login and password, the account will be created automatically after the first login.

Other login options

No password required

SSH key
Kerberos SPNEGO

External accounts

GitLab allows you to create a type of accounts that you cannot own or create projects. They can only contribute to projects to which they are given explicit access. These accounts are referred to as external accounts. They can be used to make projects available to researchers and colleagues from other institutions, thesis opponents or advisors, etc.

Managing external accounts

It is not possible to create external accounts directly in FI GitLab, but FI staff (members of the group fi-int) can create, manage and block external accounts in the external account management application in the Faculty Administration. Documentation and help can be found directly in the application.

Account validity

A GitLab account associated with a faculty account is only valid if the faculty account is active and unblocked. If the faculty account is blocked or terminated, access to GitLab , including SSH keys, will also be blocked.

SSH key

If you want to work with the repository from your own computer without having to enter a password each time, you can upload a public SSH key to your profile. Follow the instructions, here we only give tips especially for Linux systems.

Creating an SSH key

The ssh-keygen program may ask for a password during key creation. This is not mandatory, using a key without a password is easier then, however a key with a password is more secure.

Using a key without a password

You can test the functionality of the key with 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 the meaning of each line, see ssh_config(5). Test that the ssh git@gitlab command has the same output as above without explicitly specifying the key.

Using a key with a password

If you use this type of key as if it were without a password, every GitLab operation will require a password for the key, which offers almost no advantage over normal login. With the SSH agent, the key can only be unlocked once and then used repeatedly:

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

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

Note that in older versions of this documentation and on various discussion forums, you may find a procedure that uses the eval $(ssh-agent -c) command or a similar command. We do not recommend using this procedure because it does not guarantee correct agent termination.

Kerberos

GitLab allows logging into the interface and cloning repositories using Kerberos tickets.

Use on Nymfe and Musa stations

After logging into the graphical desktop environment nymfe* nebo musa* the user automatically receives a Kerberos ticket, which can be verified with 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

  • Login

    When logging in with Mozilla Firefox and Google Chrome (or Chromium), the Kerberos Spnego button can be used with a valid ticket instead of entering a password.
    GitLab Spnego

  • Cloning

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

  • Sync

    The commands git pull and git push will also work without a password with a valid ticket.

Tip
A ticket can be requested explicitly with the kinit command. This can be useful for remote SSH access with SSH key authentication (e.g. on Aisu), where a ticket is not automatically created.

Use from Aisa, Anxur or Aura servers

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

  • Login

    1. Password login

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

    login@aisa$ klist

    2. Login without password

    Logging in without a password (e.g. using an SSH key) will not create a ticket. If you don't have one, type the command:

    login@aisa$ kinit

    After entering your password, use klist to verify that you have a ticket.

  • Working with Git

    Now you can use operations in Git that work with Kerberos authentication (Clone and Sync above).

  • Renewing a ticket

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

    Anyway, check with klist that you have a valid ticket, and if not, create a new one with kinit.

Setting up your own computer

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

  • Kerberos

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

  • Git

    Git may require a password during cloning and synchronization, which will result in an error when using Kerberos authentication HTTP Basic: Access denied.
    This can be resolved by using 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

    Type about:config in the address bar . In the configuration, look for the key network.negotiate-auth.trusted-urisand add the value fi.muni.cz.

  • Chromium

    Run the browser with the parameter --auth-server-whitelist=*.fi.muni.cz. It may be useful to create a custom script that runs Chromium with this parameter and place it in /usr/local/bin.

Documentation of services and features

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

Repository sharing

If you want to make the repository available to other people beyond the "visibility" of the project (Private, Internal or Public), you can set them as 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 that person only needs access to download the project (i.e. does not need access to Issues, wiki, etc.), you can use Deploy keys (basically read-only access to the project using 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 the person (check with the maintainers).

Email replies

The Faculty GitLab has a Reply by Email feature enabled that allows you to reply to comments, "issues" and "milestones" directly by email. However, it is important to follow a few rules for proper functioning:

  • reply directly to the inbox 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 the quote correctly
  • if you digitally sign your emails, do not add a signature to your GitLab reply

Markdown can be used in the email and attachments can be added, these will then appear as attachments in the GitLab reply.

Backup

Git Repositories

User and group repositories are automatically backed up as git bundles on a regular basis. Backups take place early every day. To restore a repository that has been accidentally deleted, contact gitlab@fi.muni.cz.

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

  • Files

    Consider a full backup in the repo.9RhwIP.0.bundlefile and two incremental backups in the repo.9RhwIP.1.bundleand repo.9RhwIP.2.bundle files.

  • Restoration of full deposit

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

  • Incremental advances

    Move the full backup to use the loop: 
    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

    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
Wiki project 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 with the GitLab database. However, restoring these backups is difficult and only the overall state of the database can be restored.

For this reason, these backups are only for the purpose of restoring during a total outage. Complete restoration of individual projects (except for repositories, see above) is not possible.

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

Other interesting features

The Faculty of Informatics has licensed a version of GitLab Ultimate that includes all features including Starter and Premium versions. The linked page lists and compares the versions. Of these, the following might be of interest to users in the Faculty of Informatics:

Additional links and tutorials