Recently I described, how to keep in sync with GitLab latest releases on the Raspberry Pi. And of course it lead me to a problem after unsuccessful update to version 8.17-rc3. This release has the PostgreSQL 9.6.2 embedded and apparently everything got broken in the middle of the upgrade process. After all my tries to revert to previous GitLab version, lots of time wasted (yes, each call to apt-get upgrade or install specified GitLab version was taking several hours!), I still stayed with totally unresponsive instance.

Then again I came back to basics.

  1. I rebooted the device
    sudo shutdown –r now
  2. Installed latest GitLab-CE
    sudo apt-get upgrade
  3. Asked it to revert PostgreSQL to previous version
    sudo gitlab-ctl revert-pg-upgrade
  4. At this stage, it was showing some strange errors about inability to connect to psql service via TCP/IP, that was pretty strange.
    So I checked the status.
    sudo gitlab-ctl status

    run: gitlab-workhorse: (pid 3099) 7362s; run: log: (pid 604) 1487541047s
    run: logrotate: (pid 11405) 160s; run: log: (pid 602) 1487541047s
    run: nginx: (pid 1917) 7686s; run: log: (pid 608) 1487541047s
    down: postgresql: 1s
    run: redis: (pid 1930) 7685s; run: log: (pid 603) 1487541047s
    run: sidekiq: (pid 3079) 7364s; run: log: (pid 607) 1487541047s
    run: unicorn: (pid 3257) 7282s; run: log: (pid 606) 1487541047s
  5. And then logs!
    sudo gitlab-ctl tail postgresql
  6. And it was continuously repeating an error, while parsing line 210 of the configuration file, what was all the time stopping the service.
    sudo vi /var/opt/gitlab/postgresql/data/postgresql.con
  7. Since it was about replication, I commented it out and service started normally.
  8. Then manually upgraded PostgreSQL
    sudo gitlab-ctl pg-upgrade
  9. This time all went OK.


I recently noticed that my GitLab installed on Raspberry Pi (running Jessy) stopped updating and stick to version 8.7.9, however the latest one as of today is 8.16.4.

Normally apt-get updateand apt-get upgradeshould do the trick. But it turned out there was a change in the build system and newer packages don’t get uploaded into ‘raspbian’ version of repository. For details - take a look on issue #1303. Although quick patch is following and short:


Edit configuration file located at: /etc/apt/sources.list.d/gitlab_raspberry-pi2.list

And redirect the repository path from ‘raspbian/’ to ‘debian/’.



EDIT: 2017-03-12:

The broken repository for 'raspbian' was fixed and this trick is no more required to install latest version of GitLab.


I wasted far more time than originally expected on simple email-notifications configuration for GitLab. I use Webio hosting and somehow following part of config file (at “/etc/gitlab/gitlab.rb”) is the only one that works. Hopefully it will be useful to you, too.


gitlab_rails['smtp_enable'] =true
gitlab_rails['smtp_address'] ="poczta.webio.pl"
gitlab_rails['smtp_port'] = 465
gitlab_rails['smtp_user_name'] ="xyz@codetitans.pl"
gitlab_rails['smtp_password'] ="xyz"
gitlab_rails['smtp_domain'] ="codetitans.pl"
gitlab_rails['smtp_authentication'] ="login"
gitlab_rails['smtp_enable_starttls_auto'] =true
gitlab_rails['smtp_tls'] =true
gitlab_rails['smtp_openssl_verify_mode'] ='peer'
gitlab_rails['smtp_ca_path'] ="/etc/ssl/certs"
gitlab_rails['smtp_ca_file'] ="/etc/ssl/certs/ca-certificates.crt"

gitlab_rails['gitlab_email_display_name'] ='CodeTitans'
gitlab_rails['gitlab_email_from'] ='xyz@codetitans.pl'
gitlab_rails['gitlab_email_reply_to'] ='xyz@codetitans.pl'


Setting up GitLab was pretty easy on a Raspberry PI 3. The installation process is straightforward, it only took very long time to unpack (prepare for several hours!). And once running, its a brilliant combination comparing to all those noisy servers (aka my old PCs) I should have kept running. For the most Pi uses SD card, giving an immediate access at any time of day and doesn’t need to awake and start to spin its disks.


Moving to HTTPS configuration.
I have installed letsencrypt-auto successfully, created a config file with webroot authenticator and inside listed my domain. The real problem appeared, when I actually failed to pass the authentication challenge. Since I use the Synology NAS at the same domain, which occupies the port 80, the required web folder ‘/.well-known’ was unavailable. This unit I can’t just throw away, I wish to make both devices running smoothly together. Luckily Synology DSM 6.0 uses Let’s Encrypt too, so its nginx server is already preconfigured. What I did was to tweak a bit the config.


On the NAS side:

  1. Create shared Samba folder /volume1/acme(it might be hidden and only one user could have rights to write there)
  2. Make sure the path exists: /volume1/acme/letsencrypt/
  3. Edit /etc/nginx/nginx.conf and for location “/.well-known/acme-challenge” redefine the root from “/var/lib/letsencrypt” to “/volume1/acme/letsencrypt”


Now on the Raspberry PI

  1. Mount the folder
    sudo mount -t cifs //<nas_ip>/acme /var/www/acme -o username=<user_name>,password=<password>
  2. Retry certificate generation, it should pass this time
    ./letsencrypt-auto renew
  3. Update GitLab config (“sudo vi /etc/gitlab/gitlab.rb”) adding following lines into:

    nginx['ssl_client_certificate'] = "/etc/gitlab/ssl/ca.crt" # Most root CA's are included by default
    nginx['ssl_certificate'] = "/etc/letsencrypt/live/<domain>/fullchain.pem"
    nginx['ssl_certificate_key'] = "/etc/letsencrypt/live/<domain>/privkey.pem"

  4. Finally run “gitlab-ctl reconfigure” to refresh running instance (or only “sudo gitlab-ctl restart nginx” to restart nginx, if you renew certificate 3 months later…)



To remember, try first against acme-staging servers before switching to production one to generate real certificate.