Come si modifica l'URL di un'installazione GitLab funzionante?


89

Ho configurato e stiamo eseguendo un'installazione predefinita di GitLab v6.0.1 (stiamo per aggiornare anche noi). Si trattava di un setup di "Produzione", seguendo questa guida proprio alla lettera:

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

Ora, come si modifica in sicurezza l'URL di un'installazione funzionante?

Apparentemente il nostro URL è molto lungo e abbiamo creato un nuovo URL. Ho modificato una serie di file di configurazione e il report "Application Status Checks" è tutto OK. Ho riavviato il server per assicurarmi che le cose funzionino ancora.

Posso accedere a Nginx senza problemi, tramite il nostro SSL originale. Posso navigare nel sito GitLab, creare un repository, ecc. Posso fare fork e commit senza problemi.

Sembra tutto a posto; ma, poiché questo non è un ambiente nativo per me, volevo ricontrollare di aver fatto di tutto per rinominare un sito GitLab.

I file che ho modificato sono:

/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

9
Utenti di installazione Omnibus: il processo è diverso .
Jonathon Reinhart

Risposte:


29

Hai fatto tutto correttamente!

È inoltre possibile modificare la configurazione della posta elettronica, a seconda che il server di posta elettronica sia anche lo stesso server. La configurazione dell'email è in gitlab.yml per le email inviate da GitLab e anche per l'email di amministrazione.


Mi stavo chiedendo questo, perché ho impostato l'email Da (e l'altra email) da inviare dall'alias email del nostro gruppo di sviluppatori globale che si trova su un dominio diverso. Ad esempio: devs@domain-2.com. Il motivo è consentire agli sviluppatori di premere Rispondi per inserire commenti su richieste pull o altre email generali.
eduncan911

2
Sono tornato per contrassegnare questo come una risposta poiché GitLab ha funzionato bene da quando ho apportato queste modifiche sopra.
eduncan911

159

GitLab Omnibus

Per un'installazione Omnibus, è leggermente diverso.

La posizione corretta in un'installazione Omnibus è:

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

Infine, dovrai eseguire sudo gitlab-ctl reconfiguree sudo gitlab-ctl restartquindi le modifiche verranno applicate.


Stavo apportando modifiche nei posti sbagliati e sono stati spazzati via.

I percorsi errati sono:

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

Presta attenzione a quegli avvisi che leggono:

# 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`.

Ho GitLab Omnibus su un server interno, ma accessibile da Internet da un URL diverso. L' external_urlopzione in /etc/gitlab/gitlab.rbera la posizione corretta per impostare l'URL in modo che gli URL Git / HTTP del progetto fossero corretti.
Matthew Clark

Inoltre, dopo questa modifica e dopo aver eseguito gitlab-ctl reconfigure, è necessario riavviare il server affinché la riconfigurazione di nginx abbia luogo.
Dejv

Hai ragione, questo è l'unico e il miglior posto per modificare queste impostazioni. Il resto viene generato.
pericolo89

4
@Dejv non dovresti dover riavviare. Il riavvio del servizio nginx dovrebbe essere sufficiente.
Jonathon Reinhart

Grazie @JonathonReinhart questo lavoro per me, ma prima non dimenticare di farlo sudo gitlab-ctl stop unicornesudo gitlab-ctl stop sidekiq
Cyberguille

7

In realtà, questo NON è del tutto corretto. Sono arrivato a questa pagina, cercando di rispondere a questa domanda da solo, poiché stiamo trasferendo il server GitLab di produzione da http://a https://e la maggior parte delle cose funziona come descritto sopra, ma quando accedi a https://servere tutto sembra a posto ... tranne quando navighi su un progetto o repository e visualizza le istruzioni SSH e HTTP ... Dice "http" e le istruzioni che visualizza dicono anche "http".

Tuttavia, ho trovato altre cose da modificare:

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

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

e

/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;

...

Grazie Edward per il tuo commento (hai pubblicato una risposta a questa domanda, quando in realtà è un commento a una risposta diversa di @Razer sopra). Potresti voler modificare la tua risposta (commento) per indicare quale versione sei per gli altri. Ma abbiamo utilizzato con successo GitLab solo con queste modifiche da quando ho pubblicato questa domanda. possiamo sfogliare repository e progetti in tutto il team, interamente su SSL esclusivamente nella nostra rete aziendale.
eduncan911

2
Lo so, ma l'altra risposta è contrassegnata come risposta accettata. Quindi volutamente non volevo commentarlo, poiché non attira l'attenzione. Pubblicare un'altra risposta è un po 'più pronunciato. Sono sull'ultimo gitlab-shell 1.8.0 e gitlab 6.4 stabile. Siamo anche in grado di lavorare, interamente tramite https e ssh. Ma dobbiamo ricordarci di sostituire http con https ogni volta che copiamo e incolliamo istruzioni o URL dall'interfaccia web al client git.
Edward Ned Harvey

Mi sembra che tu abbia perso un URL in uno dei file di configurazione. Usiamo solo HTTPS e HTTP appositamente disabilitato prima dello "spostamento" nella mia domanda / descrizione originale qui. Quindi averlo esclusivamente come HTTPS ci ha permesso di muoverci secondo le istruzioni pubblicate apparentemente. Ma, se stai eseguendo un ambiente http / https in modalità mista, molto probabilmente ci sono alcune righe aggiuntive che devi modificare.
eduncan911

Grazie per il commento, ma (a) ho ricontrollato di aver apportato le modifiche a cui si fa riferimento nella risposta sopra. (b) Ho installato la seguente procedura e ho seguito quella procedura per assicurarmi di aver cambiato ogni posizione dell'URL. (c) Non solo abbiamo cambiato http in https, ma abbiamo anche cambiato il nome host. La modifica del nome host ha funzionato, il che significa che le modifiche al file di configurazione hanno avuto successo. (d) Sono scettico riguardo alla tua configurazione. Puoi sfogliare un progetto nel tuo gitlab e nella parte superiore dove ti mostra l'URL SSH e HTTP, passare da ssh a http e vedere se l'URL visualizzato ha "http" o "https?"
Edward Ned Harvey,

1
Questa risposta è ora ambigua. Affermi "In realtà, questo NON è del tutto corretto". ma cos'è "questo"? Ti riferisci a qualcosa nella domanda? Una delle altre risposte?
Jonathon Reinhart

1

Ci sono note dettagliate su questo che mi hanno aiutato completamente, trovano qui .

Jonathon Reinhart ha già risposto con il bit chiave, per modificare /etc/gitlab/gitlab.rb , alterare external_url e quindi eseguiresudo gitlab-ctl reconfigure; sudo gitlab-ctl restart

Tuttavia avevo bisogno di andare un po 'oltre e i documenti che ho collegato sopra lo spiegavano. Quindi quello che ho finito con sembra:

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"
}

Sopra, ho dichiarato esplicitamente dove si trovano i miei gadget SSL su questo server. E questo ovviamente è seguito da

sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

Inoltre, quando si cambia il pacchetto omnibus su https, nginx in bundle servirà solo sulla porta 443. Poiché tutto il mio materiale viene raggiunto tramite proxy inverso, questa parte era potenzialmente significativa.

Mentre lo facevo, ho sbagliato qualcosa ed è stato utile trovare i registri di nginx effettivi, questo mi ha portato lì:

sudo gitlab-ctl tail nginx
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.