Gitlab – Raspberry Pi
install / checks

Installation

https://docs.gitlab.com/omnibus/settings/rpi.html

Running on a Raspberry Pi

Debian Buster support was added in Omnibus GitLab 13.1.

In order to run GitLab Community Edition on a Raspberry Pi, you need the newest Pi 4 with at least 4GB of RAM for best results. You might be able to run GitLab on lower resources, like a Pi 2 or newer, but it is not recommended. We do not package for older Pis, as their CPU and RAM are insufficient.

The only supported architecture is armhf. For arm64 support, see this epic.

Configure Swap

Even with a newer Pi, the first setting you will want to change is to ensure the device has enough memory available by expanding the swap space to 4GB.

On Raspbian, swap can be configured in /etc/dphys-swapfile. See the manpage for available settings.

Install GitLab

The recommended and supported way to install GitLab is by using the GitLab official repository.

Only the official Raspberry Pi distribution is supported.

Install GitLab via the official repository

Visit the installation page, choose Raspberry Pi OS, and follow the instructions to install GitLab.

Manually download GitLab

If your distribution of choice is other than Raspbian, but Debian-based, you can manually download GitLab and install it.

Reduce running processes

If you find that your Pi is struggling to run GitLab, you can reduce some running processes:

1. Open /etc/gitlab/gitlab.rb and change the following settings:

   # Reduce the number of running workers to the minimum in order to reduce memory usage
   puma['worker_processes'] = 2
   sidekiq['concurrency'] = 9
   # Turn off monitoring to reduce idle cpu and disk usage
   prometheus_monitoring['enable'] = false
   

2. Reconfigure GitLab:

   sudo gitlab-ctl reconfigure
   

Additional recommendations

You can boost GitLab performance with a few settings.

Use a proper harddrive

GitLab will perform best if you mount /var/opt/gitlab and the swapfile from a hard drive rather than the SD card. You can attach an external hard drive to the Pi using the USB interface.

Use external services

You can improve the GitLab performance on the Pi by connecting GitLab to external database and Redis instances.

 

 

---

 

https://about.gitlab.com/install/#raspberry-pi-os

 

Raspberry Pi 4 with at least 4GB is recommended. Only 32bit (armhf) is supported at this point. 64 bit (aarch64) is on its way.

1. Install and configure the necessary dependencies

 

sudo apt-get install curl openssh-server ca-certificates apt-transport-https
curl https://packages.gitlab.com/gpg.key | sudo apt-key add -

Next, install Postfix to send notification emails. If you want to use another solution to send emails please skip this step and configure an external SMTP server after GitLab has been installed.

sudo apt-get install -y postfix

During Postfix installation a configuration screen may appear. Select 'Internet Site' and press enter. Use your server's external DNS for 'mail name' and press enter. If additional screens appear, continue to press enter to accept the defaults.

2. Add the GitLab package repository and install the package

Add the GitLab package repository.

sudo curl -sS https://packages.gitlab.com/install/repositories/gitlab/raspberry-pi2/script.deb.sh | sudo bash

 

Next, install the GitLab package. Make sure you have correctly set up your DNS, and change https://gitlab.example.com to the URL at which you want to access your GitLab instance. Installation will automatically configure and start GitLab at that URL.

For https:// URLs GitLab will automatically request a certificate with Let's Encrypt, which requires inbound HTTP access and a valid hostname. You can also use your own certificate or just use http://.

sudo EXTERNAL_URL="https://gitlab.example.com" apt-get install gitlab-ce

3. Browse to the hostname and login

On your first visit, you'll be redirected to a password reset screen. Provide the password for the initial administrator account and you will be redirected back to the login screen. Use the default account's username root to login.

See our documentation for detailed instructions on installing and configuration.

4. Set up your communication preferences

Visit our email subscription preference center to let us know when to communicate with you. We have an explicit email opt-in policy so you have complete control over what and how often we send you emails.

Twice a month, we send out the GitLab news you need to know, including new features, integrations, docs, and behind the scenes stories from our dev teams. For critical security updates related to bugs and system performance, sign up for our dedicated security newsletter.

Important note: If you do not opt-in to the security newsletter, you will not receive security alerts.

5. Recommended next steps

 

After completing your installation, consider the recommended next steps, including authentication options and sign-up restrictions.

 

Securing your GitLab installation

Consider access control features like Sign up restrictions and Authentication options to harden your GitLab instance and minimize the risk of unwanted user account creation.

 

Sign-up restrictionsCORE

You can enforce the following restrictions on sign ups:

• Disable new sign ups.
• Require administrator approval for new sign ups.
• Require user email confirmation.
• Allow or deny sign ups using specific email domains.

Disable new sign ups

By default, any user visiting your GitLab domain can sign up for an account. For customers running public-facing GitLab instances, we highly recommend that you consider disabling new sign ups if you do not expect public users to sign up for an account.

To disable sign ups:

1. Go to Admin Area > Settings > General and expand Sign-up restrictions.
2. Clear the Sign-up enabled checkbox, then select Save changes.

Require administrator approval for new sign ups

Version history

When this setting is enabled, any user visiting your GitLab domain and signing up for a new account must be explicitly approved by an administrator before they can start using their account. This setting is enabled by default for newly created instances. This setting is only applicable if sign ups are enabled.

To require administrator approval for new sign ups:

1. Go to Admin Area > Settings > General and expand Sign-up restrictions.
2. Select the Require admin approval for new sign-ups checkbox, then select Save changes.

Require email confirmation

You can send confirmation emails during sign up and require that users confirm their email address before they are allowed to sign in.

To enforce confirmation of the email address used for new sign ups:

1. Go to Admin Area > Settings > General and expand Sign-up restrictions.
2. Select the Enable email restrictions for sign ups checkbox, then select Save changes.

User cap CORE

Introduced in GitLab 13.6.

When the number of billable users reaches the user cap, any user who is added or requests access must be approved by an administrator before they can start using their account.

If an administrator increases or removes the user cap, the users in pending approval state will be automatically approved in a background job.

Soft email confirmation

Version history

This feature might not be available to you. Check the version history note above for details.

The soft email confirmation improves the signup experience for new users by allowing them to sign in without an immediate confirmation when an email confirmation is required. GitLab shows the user a reminder to confirm their email address, and the user can’t create or update pipelines until their email address is confirmed.

Minimum password length limit

Introduced in GitLab 12.6

You can change the minimum number of characters a user must have in their password using the GitLab UI.

Allow or deny sign ups using specific email domains

You can specify an inclusive or exclusive list of email domains which can be used for user sign up.

These restrictions are only applied during sign up from an external user. An administrator can add a user through the admin panel with a disallowed domain. Also, note that the users can change their email addresses to disallowed domains after sign up.

Allowlist email domains

Introduced in GitLab 7.11.0

You can restrict users only to sign up using email addresses matching the given domains list.

Denylist email domains

Introduced in GitLab 8.10.

You can block users from signing up when using an email addresses of specific domains. This can reduce the risk of malicious users creating spam accounts with disposable email addresses.

Create email domain allowlist or denylist

To create an email domain allowlist or denylist:

1. Go to Admin Area > Settings > General and expand Sign-up restrictions.

2. For the allowlist, you must enter the list manually. For the denylist, you can enter the list manually or upload a .txt file that contains list entries.

   Both the allowlist and denylist accept wildcards. For example, you can use *.company.com to accept every company.com subdomain, or *.io to block all domains ending in .io. Domains must be separated by a whitespace, semicolon, comma, or a new line.

   

Enable or disable soft email confirmation

Soft email confirmation is under development but ready for production use. It is deployed behind a feature flag that is disabled by default. GitLab administrators with access to the GitLab Rails console can opt to disable it.

To enable it:

Feature.enable(:soft_email_confirmation)

To disable it:

Feature.disable(:soft_email_confirmation)

 

---

Authentication

This page gathers all the resources for the topic Authentication within GitLab.

GitLab users

• SSH

• Two-Factor Authentication (2FA)

• Why do I keep getting signed out?

• Articles:

  • Support for Universal 2nd Factor Authentication – YubiKeys
  • Security Webcast with Yubico

• Integrations:

  • GitLab as OAuth2 authentication service provider
  • GitLab as OpenID Connect identity provider

GitLab administrators

• LDAP

• Enforce Two-factor Authentication (2FA)

• Articles:

  • Feature Highlight: LDAP Integration
  • Debugging LDAP

• Integrations:

  • OmniAuth
  • Authentiq OmniAuth Provider
  • Atlassian Crowd OmniAuth Provider
  • CAS OmniAuth Provider
  • SAML OmniAuth Provider
  • SAML for GitLab.com Groups
  • SCIM user provisioning for GitLab.com Groups
  • Okta SSO provider
  • Kerberos integration (GitLab EE)

API

• OAuth 2 Tokens
• Personal access tokens
• Project access tokens
• Impersonation tokens
• GitLab as an OAuth2 provider

Third-party resources

• Kanboard Plugin GitLab Authentication
• Jenkins GitLab OAuth Plugin
• OKD – Configuring Authentication and User Agent