I’d like to migrate a gitlab installation from RH6 to RH7.
the installation is using a DNS alias “git.example.com”.
I have the saem gitlab version in both servers (8.16.5-ce.1 omnibus install) and I’ve restored a backup from the old server to the new one. So far so good.
In order to check that everything looks the same in the new server I’ve changed the external_url in the new server (/etc/gitlab/gitlab.rb) so it matches the server hostname:
old:
I would request you to take output of the below commands and post it here for better understanding of your problem.
These commands can be run on your production environment: (run as root)
to check hostname of machine: hostname
to verify hostname of machine: cat /etc/hosts
to check DNS on your machine and the machines you are testing your URL: nslookup your domain name
to check all gitlab component are working or not: gitlab-ctl status
to check url for GitLab: cat /gitlab/gitlab.rb | grep external_url
to check port is open for GitLab or not: netstat -tlpn
to check selinux status: sestatus
to check any firewall enabled or not: iptables --list
After running all the above command please follow below steps to use the new server external_url on your browser because sometime gitlab start misbehaving after the upgradation to new version of gitlab :
Step 1:
Please enter the external_url on /etc/gitlab/gitlab.rb file as you have already given the external_url so there is no need.
to reconfigure gitlab after giving external_url gitlab-ctl reconfigure
Step 2:
After that run the restart command to restart each commonent of gitlab gitlab-ctl restart
I hope all the above command will help you.
Please feel free and share the output of the above command and also reply if you have any query.
The hostname and network from the server is properly set. Selinux is disabled and the firewall stopped.
I’ve also followed the general documentation about external_url in gitlab.rb + reconfigure (and extra restart/ reboot). Nothing helps.
The relevant logs when accessing http://new_hostname show the redirect:
==> /var/log/gitlab/gitlab-rails/production.log <==
Started GET “/” for X.Y.Z at 2018-03-16 09:36:33 +0100
Processing by RootController#index as HTML
Redirected to https://git.example.com
Filter chain halted as :redirect_unlogged_user rendered or redirected
Completed 302 Found in 4ms (ActiveRecord: 0.0ms)
==> /var/log/gitlab/gitlab-rails/production_json.log <==
{“method”:“GET”,“path”:“/”,“format”:“html”,“controller”:“RootController”,“action”:“index”,“status”:302,“duration”:5.06,“view”:0.0,“db”:0.0,“location”:“https://git. example.com”,“time”:“2018-03-16T08:36:33.350Z”,“params”:,“remote_ip”:“X.Y.Z”,“user_id”:null,“username”:null}
==> /var/log/gitlab/gitlab-workhorse/current <==
2018-03-16_08:36:33.35611 new_hostname @ - - [2018-03-16 09:36:33.3411427 +0100 CET m=+2788.063608676] “GET / HTTP/1.1” 302 95 “” “Mozilla/5.0 (Win
dows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36” 0.014898
The behavior you describe in a “normal bug”, affecting every Gitlab version.
That is because the “settings” tab of the admin is taking over : more precisely, in your /admin/application_settings page, the “Home page URL” and “After sign out path” are applied.
Two workarounds :
Empty the parameters before your migration
After migration : log in through https://new_server/users/sign_in ; you are redirected to the old url. Go back to https://new_server/admin/application_settings and change the parameters.
This seriously has saved my day. Thank you very very much.
And I agree, this should has been mentioned somewhere in gitlab documentation related to migrating gitlab instance from one server to another or domain change.
This is an absolutely common standard use case and should definitely be mentioned in the docs, resp. the gitlab backup/restore section - i actually can not believe that this is missing under the dozens of topics there.
Thanks for saving me a lot of trouble (and time) by pointing this out here!
For those like me who’ve wasted hours trying to find the relevant setting in 13.5, it’s under Admin / Settings / General / Sign-in restrictions / Home page url.