Install GitLab with SSL on Fedora 26

This guide will show you how to get GitLab running on a new Fedora 26 VM using your internal PKI for SSL access.

  1. In PowerShell on your Hyper-V Hypervisor:
    New-VHD -Path "E:\Hyper-V\Virtual Hard Disks\gitlabServer.vhdx" -SizeBytes 500GB -Dynamic -BlockSizeBytes 1MB
  2. After Fedora 26 is installed:
    dnf install hyperv-daemons hypervvssd hyperv-tools
  3. Disable network manager (because it usually ruins your life later):
    systemctl stop NetworkManager.service
    systemctl disable NetworkManager.service
    systemctl enable network.service
    reboot now
  4. Install ability to use semanage:
    dnf install policycoreutils-python-utils
  5. Install full cockpit:
    dnf install cockpit
  6. Make sure all is up to date:
    dnf upgrade
  7. Make all space available, resize… easy to do in Cockpit.
  8. Install GitLab dependencies (may already be installed) depending on your OS install:
    dnf install -y curl openssh-server openssh-clients cronie
  9. Open firewall/selinux:
    firewall-cmd --permanent --add-service=http
    firewall-cmd --permanent --add-service=https
    firewall-cmd --reload
    semanage permissive -a httpd_t
  10. More dependencies (I don’t think these are needed, but if they are):
    dnf install -y pygpgme yum-utils
  11. Install GitLab:
    mv download gitlab-ce-9.4.5-ce.0.el7.x86_64.rpm
    dnf install -y gitlab-ce-9.4.5-ce.0.el7.x86_64.rpm
  12. Config and start GitLab (may take about 2 minutes):
    gitlab-ctl reconfigure
  13. Add SMTP server config -> vi /etc/gitlab/gitlab.rb:
    gitlab_rails['smtp_enable'] = true
    gitlab_rails['smtp_address'] = "smtpServer.domain.local"
    gitlab_rails['smtp_port'] = 25
    gitlab_rails['smtp_authentication'] = false
    gitlab_rails['smtp_enable_starttls_auto'] = true
    gitlab_rails['gitlab_email_from'] = ''
    gitlab_rails['gitlab_email_reply_to'] = ''
    gitlab-ctl reconfigure
  14. Send email test:
    gitlab-rails console
    Notify.test_email('', 'GitLab Test Email', 'This is a test.').deliver_now
  15. Convert your AD CS wildcard cert.pfx to PEM and KEY for nginx:
    openssl pkcs12 -in domain_wildcard_cert.pfx -out domainwild-encrypted.key
    openssl pkcs12 -in domain_wildcard_cert.pfx -clcerts -nokeys -out domainwild-certificate.crt
    openssl rsa -in domainwild-encrypted.key -out domainwild-decrypted.key
    openssl pkcs12 -in domain_wildcard_cert.pfx -out domain-ca.crt -nodes -nokeys -cacerts
    cat domainwild-certificate.crt domain-ca.crt > full_cert.crt
  16. Create ssl directory for gitlab (extra info –
    mkdir -p /etc/gitlab/ssl
    chmod 0700 /etc/gitlab/ssl
    cp /mnt/domainwild-decrypted.key /etc/gitlab/ssl/gitlabServer.domain.local.key
    cp /mnt/full_cert.crt /etc/gitlab/ssl/gitlabServer.domain.local.crt
  17. Edit file to enable https and redirect to https -> vi /etc/gitlab/gitlab.rb:
    external_url "https://gitlabServer.domain.local"
    nginx['redirect_http_to_https'] = true
    sudo gitlab-ctl reconfigure
  18. Now you should be able to access your gitlab via https.


  1. I commented out the following line and ran the reconfigure again and it worked for me:

    113: restorecon -v -i ‘#{gitlab_shell_secret_file}’


    113: # restorecon -v -i ‘#{gitlab_shell_secret_file}’

    then ran it again it worked fine since the directory existed on the next round

  2. Create the folder /var/opt/gitlab/gitlab-rails/etc/ if it does not exists and re-run it should run fine. Make sure the folder owner is gitlab.root.
    I tested it on Fedora 28 gitlab-ee 10.8.3.

    • Confirmed, this worked for me. But I had to make sure the folder is owned by git.root. Tested on Fedora 28, Gitlab CE 11.1.4

  3. I solved my issue. The problem is the line:

    restorecon -v -i ‘#{gitlab_shell_secret_file}’

    The -i option will ignore missing files, however, if the directory is not found the SELinux: Could not get canonical path… error is generated, and that causes the script to crash.

    I simply commented out the line above and everything worked; a follow-on script created the missing directory and file so I can now insert the line back when running reconfigure in the future.

    Overall it could be a bug that the script doesn’t generate the directory for the secret file if it doesn’t exist.

  4. Hello! Thanks for these great notes! I’m trying to do this on a Fedora 26 install using the current GitLab (gitlab-ce-10.5.2-ce.0.el7.x86_64.rpm) but I am getting an error at Step 12:

    Error executing action `run` on resource ‘bash[Set proper security context on ssh files for selinux]’

    Expected process to exit with [0], but received ‘255’
    —- Begin output of “bash” “/tmp/chef-script20180301-4996-1r8q8bg” —-
    STDERR: ValueError: File context for /var/opt/gitlab/.ssh(/.*)? already defined
    ValueError: File context for /var/opt/gitlab/.ssh/authorized_keys already defined
    ValueError: File context for /var/opt/gitlab/gitlab-shell/config.yml already defined
    ValueError: File context for /var/opt/gitlab/gitlab-rails/etc/gitlab_shell_secret already defined
    restorecon: SELinux: Could not get canonical path for /var/opt/gitlab/gitlab-rails/etc/gitlab_shell_secret restorecon: No such file or directory.
    —- End output of “bash” “/tmp/chef-script20180301-4996-1r8q8bg” —-
    Ran “bash” “/tmp/chef-script20180301-4996-1r8q8bg” returned 255

    Resource Declaration:
    # In /opt/gitlab/embedded/cookbooks/cache/cookbooks/gitlab/recipes/gitlab-shell.rb

    103: bash “Set proper security context on ssh files for selinux” do
    104: code <<~EOS
    105: semanage fcontext -a -t ssh_home_t '#{ssh_dir}(/.*)?'
    106: semanage fcontext -a -t ssh_home_t '#{authorized_keys}'
    107: semanage fcontext -a -t ssh_home_t '#{gitlab_shell_config_file}'
    108: semanage fcontext -a -t ssh_home_t '#{gitlab_shell_secret_file}'
    109: restorecon -R -v '#{ssh_dir}'
    110: restorecon -v '#{authorized_keys}' '#{gitlab_shell_config_file}'
    111: # On new installs, the gitlab_shell_secret file may not exist until the
    112: # gitlab-rails recipe runs, so we can safely move along if the file doesn't exist.
    113: restorecon -v -i '#{gitlab_shell_secret_file}'
    114: EOS
    115: only_if "id -Z"
    116: end

    Overall I note:
    restorecon: SELinux: Could not get canonical path for /var/opt/gitlab/gitlab-rails/etc/gitlab_shell_secret restorecon: No such file or directory.

    So it looks like SELinux utility 'restorecon' is generating an error when it can't find the file gitlab_shell_secret_file. The comments point out that the file may not exist and thus 'restorecon' uses -i option to to ignore missing files.

    Oddly, it still crashes at this point. 🙁

    Any ideas why this is happening?

    BTW: I'm running 'sudo dnf gitlab-ctl reconfigure'


Leave a Reply

Your email address will not be published. Required fields are marked *