101

I have set up and we are running a default install of GitLab v6.0.1 (we're about to upgrade as well). It was a "Production" setup, following this guide precisely to the letter:

https://github.com/gitlabhq/gitlabhq/blob/master/doc/install/installation.md

Now, how do we safely change the URL of a working install?

Apparently our URL is very long and we've come up with a new URL. I've edited a number of configuration files and the "Application Status Checks" report everything is OK. I've rebooted the server to ensure things are still working.

I can access Nginx just fine, over our original SSL. I can browse the GitLab site, create a repository, etc. I can fork and commit just fine.

It all seems to be OK; but, since this is not a native environment for me, I wanted to double check that I have done everything to rename a GitLab site.

The files I've edited are:

/etc/hosts
  127.0.0.1  localhost
  10.0.0.10  wake.domain.com    wake
  10.0.0.10  git.domain.com     git

/home/git/gitlab/config/gitlab.yml
  production: &base
    gitlab:
      host: git.domain.com

/home/git/gitlab-shell/config.yml
  gitlab_url: "https://git.domain.com"
  ^- yes, we are on SSL and that is working, even on a new URL

/etc/nginx/sites-available/gitlab
  server {
    server_name git.domain.com
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
eduncan911
  • 17,165
  • 13
  • 68
  • 104

5 Answers5

170

GitLab Omnibus

For an Omnibus install, it is a little different.

The correct place in an Omnibus install is:

/etc/gitlab/gitlab.rb
    external_url 'http://gitlab.example.com'

Finally, you'll need to execute sudo gitlab-ctl reconfigure and sudo gitlab-ctl restart so the changes apply.

I was making changes in the wrong places and they were getting blown away.

The incorrect paths are:

/opt/gitlab/embedded/service/gitlab-rails/config/gitlab.yml
/var/opt/gitlab/.gitconfig
/var/opt/gitlab/nginx/conf/gitlab-http.conf

Pay attention to those warnings that read:

# This file is managed by gitlab-ctl. Manual changes will be
# erased! To change the contents below, edit /etc/gitlab/gitlab.rb
# and run `sudo gitlab-ctl reconfigure`.
Jonathon Reinhart
  • 132,704
  • 33
  • 254
  • 328
  • I have GitLab Omnibus on an internal server, but accessible from the Internet from a different URL. The `external_url` option in `/etc/gitlab/gitlab.rb` was the correct place to set the URL so that project Git/HTTP URLs would be correct. – Matthew Clark Mar 17 '15 at 18:02
  • Also, after this change and after running gitlab-ctl reconfigure, you have to reboot server for nginx reconfiguration to take place. – Dejv Apr 29 '15 at 08:58
  • You are right, this is the only and best place to change these settings. The rest is generated. – Melroy van den Berg Jul 06 '15 at 22:28
  • 4
    @Dejv you shouldn't have to restart. Restarting the nginx service should be sufficient. – Jonathon Reinhart Jul 07 '15 at 00:50
  • Thanks @JonathonReinhart this work for me, but first don't forget do `sudo gitlab-ctl stop unicorn` and `sudo gitlab-ctl stop sidekiq` – Cyberguille Feb 13 '17 at 19:46
  • @Cyberguille Not strictly necessary. – Jonathon Reinhart Feb 13 '17 at 21:37
  • editing the said file and then `sudo gitlab-ctl reconfigure` and `sudo gitlab-ctl restart` should take care of all. nothing else required. – Fr0zenFyr May 24 '18 at 12:26
29

You did everything correctly!

You might also change the email configuration, depending on if the email server is also the same server. The email configuration is in gitlab.yml for the mails sent by GitLab and also the admin-email.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Razer
  • 7,843
  • 16
  • 55
  • 103
  • I was wondering about this, because I set the From email (and the other email) to be sent from our global developer group email alias that is on a different domain. Like: devs@domain-2.com. The reason is to allow devs to hit Reply to make comments on Pull requests or other general emails. – eduncan911 Oct 19 '13 at 15:54
  • 2
    Came back to mark this as an answer as GitLab has been working fine since I made these changes above. – eduncan911 Jan 15 '14 at 16:32
12

Do not forget to clear the cache after updating the external_url param in /etc/gitlab/gitlab.rb, otherwise your existing project clone URLs will still be showing your old host name.

A simple 3 step process to change the hostname is as follows

  • update the external_url param in /etc/gitlab/gitlab.rb
  • sudo gitlab-ctl reconfigure
  • sudo gitlab-ctl restart
  • sudo gitlab-rake cache:clear

Ref:

https://forum.gitlab.com/t/clone-url-wont-change/21692/6

user728650
  • 1,828
  • 12
  • 13
8

Actually, this is NOT totally correct. I arrived at this page, trying to answer this question myself, as we are transitioning production GitLab server from http:// to https:// and most stuff is working as described above, but when you login to https://server and everything looks fine ... except when you browse to a project or repository, and it displays the SSH and HTTP instructions... It says "http" and the instructions it displays also say "http".

I found some more things to edit though:

/home/git/gitlab/config/gitlab.yml
  production: &base
    gitlab:
      host: git.domain.com

      # Also edit these:
      port: 443
      https: true
...

and

/etc/nginx/sites-available/gitlab
  server {
    server_name git.domain.com;

    # Also edit these:
    listen 443 ssl;
    ssl_certificate     /etc/ssl/certs/somecert.crt;
    ssl_certificate_key /etc/ssl/private/somekey.key;

...
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Edward Ned Harvey
  • 6,525
  • 5
  • 36
  • 45
  • Thank you Edward for your comment (you posted an Answer to this question, when it's actually a comment to a different answer by @Razer above). You may want to edit your answer (comment) to state what version you are on for others. But, we have been successfully using GitLab with only these changes since I posted this question. we can browse repos and projects across the team - entirely over SSL exclusively in our corporate network. – eduncan911 Jan 15 '14 at 16:32
  • 2
    I know, but the other answer is marked as an accepted answer. So I purposely didn't want to comment on it, as that doesn't get attention. Posting another answer is a little bit more pronounced. I'm on the latest gitlab-shell 1.8.0 and gitlab 6.4 stable. We are also able to work, entirely via https and ssh. But we have to remember to replace http by https every time we copy & paste instructions or URL from the web interface to git client. – Edward Ned Harvey Jan 16 '14 at 00:28
  • That sounds to me that you missed an URL in one of the configuration files. We only use HTTPS and purposely disabled HTTP prior to the "move" in my original question/description here. So having it exclusively as HTTPS allowed us to move per the posted instructions seemlessly. But, if you are running a mixed-mode http/https environment, there most likely are a few additional lines you need to edit. – eduncan911 Jan 16 '14 at 04:52
  • Thanks for the comment, but (a) I double checked that I made the changes referenced in the above answer. (b) I installed following procedure, and I re-followed that procedure to make sure I changed every place the URL is. (c) We not only changed http to https, we also changed hostname. The hostname change worked, which means the config file modifications were successful. (d) I am skeptical about your setup. Can you browse to a project in your gitlab, and at the top where it shows you the SSH and HTTP URL, toggle between ssh and http, and see if the URL it displays has "http" or "https?" – Edward Ned Harvey Jan 16 '14 at 13:37
  • 2
    This answer is now ambigous. You state *"Actually, this is NOT totally correct."* but what is "this"? Are you referring to something in the question? One of the other answers? – Jonathon Reinhart Oct 20 '16 at 18:45
1

There are detailed notes on this that helped me completely, located here.

Jonathon Reinhart has already answered with the key bit, to edit /etc/gitlab/gitlab.rb, alter the external_url and then run sudo gitlab-ctl reconfigure; sudo gitlab-ctl restart

However I needed to go a bit further and docs I linked above explained it. So what I ended up with looks like:

external_url 'https://gitlab.toilethumor.com'
nginx['ssl_certificate'] = "/www/ssl/star_toilethumor.com-chained.crt"
nginx['ssl_certificate_key'] = "/www/ssl/star_toilethumor.com.key"
nginx['proxy_set_headers'] = {
 "X-Forwarded-Proto" => "http",
 "CUSTOM_HEADER" => "VALUE"
}

Above, I've explicitly declared where my SSL goodies are on this server. And that's of course followed by 

sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

Also, when you switch the omnibus package to https, the bundled nginx will only serve on port 443. Since all my stuff is reached via reverse proxy, this part was potentially significant.

As I went through this, I screwed something up and it helpful to find the actual nginx logs, this lead me there:

sudo gitlab-ctl tail nginx
James T Snell
  • 1,588
  • 1
  • 15
  • 28