This guide will show you how to get GitLab running on a new Fedora 26 VM using your internal PKI for SSL access.
- In PowerShell on your Hyper-V Hypervisor:
New-VHD -Path "E:\Hyper-V\Virtual Hard Disks\gitlabServer.vhdx" -SizeBytes 500GB -Dynamic -BlockSizeBytes 1MB - After Fedora 26 is installed:
dnf install hyperv-daemons hypervvssd hyperv-tools - Disable network manager (because it usually ruins your life later):
systemctl stop NetworkManager.service
systemctl disable NetworkManager.service
systemctl enable network.service
reboot now - Install ability to use semanage:
dnf install policycoreutils-python-utils - Install full cockpit:
dnf install cockpit - Make sure all is up to date:
dnf upgrade - Make all space available, resize… easy to do in Cockpit.
- Install GitLab dependencies (may already be installed) depending on your OS install:
dnf install -y curl openssh-server openssh-clients cronie - Open firewall/selinux:
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --reload
semanage permissive -a httpd_t - More dependencies (I don’t think these are needed, but if they are):
dnf install -y pygpgme yum-utils - Install GitLab:
wget https://packages.gitlab.com/gitlab/gitlab-ce/packages/el/7/gitlab-ce-9.4.5-ce.0.el7.x86_64.rpm/download
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 - Config and start GitLab (may take about 2 minutes):
gitlab-ctl reconfigure - 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@example.com'
gitlab_rails['gitlab_email_reply_to'] = 'noreply@example.com'
gitlab-ctl reconfigure - Send email test:
gitlab-rails console
Notify.test_email('yourEmail@domain.com', 'GitLab Test Email', 'This is a test.').deliver_now - 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 - Create ssl directory for gitlab (extra info – https://docs.gitlab.com/omnibus/settings/nginx.html):
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 - 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 - Now you should be able to access your gitlab via https.
I commented out the following line and ran the reconfigure again and it worked for me:
113: restorecon -v -i ‘#{gitlab_shell_secret_file}’
to
113: # restorecon -v -i ‘#{gitlab_shell_secret_file}’
then ran it again it worked fine since the directory existed on the next round
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
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.
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]’
Mixlib::ShellOut::ShellCommandFailed
————————————
Expected process to exit with [0], but received ‘255’
—- Begin output of “bash” “/tmp/chef-script20180301-4996-1r8q8bg” —-
STDOUT:
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'
Thanks!