Dopo tanto tempo mi sono imbattuto nella necessità di fare la migrazione gitosis server su un nuovo server. Questo è avvenuto quando ho deciso di cambiare il provider del mio server di appoggio. Tra le tante cose che ci tenevo, mi sono imbattuto anche nella necessità di migrare anche la mia installazione di gitosis, dove gestisco alcuni dei miei progettini.
Prima di intervenire direttamente sul server ho deciso di fare qualche prova in locale su una installazione Vagrant, perchè l’installazione che voglio migrare ha 4 anni di vita. Ha funzionato senza alcuna necessità di intervento per un lungo tempo, l’unico problema è che a distanza di qualche anno non mi ricordo più cosa ho fatto inizialmente per configurarla. Quindi prima di pasticciare con il nuovo server di produzione, preparo qualche test su un ambiente adeguato. Questa volta segnando degli appunti per il futuro…
Setup Vagrant
Preparo la configurazione della mia postazione vagrant partendo e adattando una semplice che già utilizzavo, ecco la configurazione che utilizzerò:
# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure(2) do |config|
config.vm.box = "puphpet/centos65-x64"
config.vm.hostname = "gitosis"
config.vm.network :private_network, ip: "192.168.56.106"
#aggiungo una cartella condivisa esterna
config.vm.synced_folder "../data", "/vagrant_data"
#restringo le risorse della virtual machine
config.vm.provider "virtualbox" do |vb|
vb.customize ["modifyvm", :id,
"--cpuexecutioncap", "50",
"--memory", "1024",
"--cpus", "1"
]
end
config.vm.provision "shell", path: "provision.sh"
end
I punti salienti di questa configurazione sono pochi:
- [10] assegnazione ip per l’accesso al server
- [13] configurazione di una cartella in cui condivido i file tra le varie macchine vagrant, esterna alla cartella di configurazione della mia vagrant machine, per non finire nel repository git con cui gestisco questi mini test
- [24] uso un file di provisioning per eseguire una serie di comandi in automatico, come ad esempio installare i vari pacchetti che mi servono.
Faccio partire la mia vagrant e mi collego con la console ssh. Man mano che faccio qualche prova, installo qualche pacchetto necessario, provvederò ad aggiornare opportunamente il file di provisioning provision.sh, in modo da poter ricreare una situazione pulita del mio ambiente di test in ogni momento ripetendo solo quello che è strettamente necessario.
Step 1 – Tutto gira intorno a git
Seguendo le indicazioni della documentazione ufficiale mi rendo conto che i sorgenti di gitosis sono distribuiti tramite un repository git. Quindi serve git sulla macchina su cui opero.
Una semplice verifica mi conferma che non c’è già installato:
$ git bash: git: command not found
Partiamo quindi installando git:
$ sudo yum install git
Ecco che otteniamo anche la prima azione da inserire nel file di provisioning provision.sh:
yum -y install git 2>&1
In questo caso viene omesso sudo perchè vagrant esegue il provisioning con i permessi dell’utente root. Ho solo aggiunto: il parametro -y per rispondere con Yes a tutte le domande della procedura di installazione, ho aggiunto anche una limitazione delle stampe a video di tutta la noiosa procedura tramite 2>&1
Step 2 – Installazione sorgenti gitosis
Procediamo a recuperare i sorgenti. Per farlo ci serviamo di git, infatti andiamo a clonare il repository del sorgente di gitosis. Posiziono il tutto nella directory /usr/local/src che mi sembra proprio quella più indicata allo scopo
$ cd /usr/local/src $ sudo git clone git://eagain.net/gitosis.git gitosis $ sudo git clone https://github.com/tv42/gitosis.git gitosis
Ho riportato due repository diversi, trovati nella documentazione, da cui è possibile scaricare i sorgenti, uno non funzionava… O meglio il primo è l’originale, dove erano conservati i sorgenti, gestiti tramite gitosis stesso, poi lo sviluppatore ha deciso di avvalersi di github, ed ora forse sono disponibili solo tramite questa piattaforma, infatti questa funziona.
provision.sh: da aggiungere in coda al provisioning, ecco la precedente operazione adeguatamente rivisitata:
git clone https://github.com/tv42/gitosis.git /usr/local/src/gitosis
Step 3 – Installiamo…
Arrivati a questo punto diamo inizio alle danze ed eseguiamo l’installazione:
$ cd /usr/local/src/gitosis $ sudo python setup.py install Traceback (most recent call last): File "setup.py", line 2, infrom setuptools import setup, find_packages ImportError: No module named setuptools
Oh oh, manca ancora qualcosa da installare prima, ci servono i setuptools di phyton, aggiugiamo li subito:
$ sudo yum install python-setuptools
Rieseguiamo l’installazione incrociando le dita e questa volta funziona tutto correttamente.
provision.sh: da aggiungere in coda altre operazioni:
yum -y install python-setuptools 2>&1 cd /usr/local/src/gitosis python setup.py install
Step 4 – Creazione utente
Aggiungo l’utente destinato a git, che con modesta fantasia chiamerò git e gli imposto una password:
$ sudo useradd git $ sudo passwd git
provision.sh: da aggiungere in coda altre operazioni, ho fatto in modo di inserire anche la password in automatico, come vedi ne ho scelta una banalissima, probabilmente la prima che prova un hacker che tenta di bucare il sito. Negli ambienti di produzione anche per le utenze di test è d’obbligo scegliere password decisamente più robuste:
useradd git echo git:git12345 | chpasswd
Step 5 – configurazione delle chiavi e inizializzazione
Anche se lo scopo finale che mi sono prefisso è quello di spostare gitosis da un’altra installazione, prima di dedicarmi a questo, voglio che questa nuova installazione sia perfettamente funzionante, in pratica sarà a tutti gli effetti un server per repository git, poi una volta che tutto funziona proseguoo con le modifiche necessarie a completare la migrazione.
Per l’autenticazione ci serve una coppia di chiavi ssh, una pubblica e una privata. Gli scenari che possiamo avere sono i seguenti: non ho le chiavi e quindi le devo creare, oppure possiedo già le chiavi e voglio usare queste.
Scenario 1 – creazione delle chiavi
La chiave prima di tutto, se non ho una chiave la creo e la sposto sulla directory tmp. La creazione della chiave crea una coppia di files, la chiave pubblica e quella privata, ma non dilunghiamoci:
$ ssh-keygen -t rsa $ cp .ssh/id_rsa.pub /tmp/
Siamo pronti per inizializzare il server gitosis, facendogli caricare la chiave pubblica che abbiamo precedentemente creato:
sudo -H -u git gitosis-init < /tmp/id_rsa.pub
Scenario 2 - uso una chiave esistente
Nel mio caso invece, non ho bisogno di creare le chiavi, ne possiedo già una coppia. Posiziono la chiave pubblica nella directory condivisa e inizializzo il server git utilizzando questa, saltando anche la fase di creazione della chiave.
Inizializzimao il server gitosis, facendogli caricare la chiave pubblica dalla directory condivisa:
sudo -H -u git gitosis-init < /vagrant_data/id_rsa.pub
Step 6 - facciamo qualche test
Se controlliamo nella directory /home/git possiamo vedere che sono stati configurate tutte le directory necessarie. Non rimane ora che fare un test e verificare se funziona. Il test lo facciamo direttamente dalla macchina virtuale connessi come utente vagrant.
$ git clone git@127.0.0.1:gitosis-admin.git Initialized empty Git repository in /home/vagrant/gitosis-admin/.git/ remote: Counting objects: 5, done. remote: Compressing objects: 100% (5/5), done. remote: Total 5 (delta 0), reused 5 (delta 0) Receiving objects: 100% (5/5), done.
Quasi da non crederci, ha funzionato. Quello che abbiamo clonato è uno speciale repository di gitosis che consente di amministrare l'accesso ai repository dei vari proggetti che andremo a creare poi, ed in particolare tiene traccia delle chiavi di accesso degli utenti che andremo ad abilitare.
Fatto questo piccolo test proviamo ad accedere dalla macchina host, dovremmo essere in grado di clonare lo stesso repository di amministrazione precedente.
$ git clone git@192.168.56.106:gitosis-adimin.git ... Receiving objects: 100% (5/5), done.
In un caso ho ottenuto una richiesta di password
Non sempre i test sono cosi lineari, su una postazione avevo appena eseguito tutti i passaggi precedenti, era andato tutto a meraviglia che già pregustavo di finire presto l'installazione. Ma all'esecuzione del test locale qualcosa non tornava:
[root@xno ~]# git clone git@127.0.0.1:gitosis-admin.git Initialized empty Git repository in /root/gitosis-admin/.git/ The authenticity of host '127.0.0.1 (127.0.0.1)' can't be established. RSA key fingerprint is 4f:34:6b:86:1a:f4:ef:ca:23:e3:9c:91:bd:84:ce:e7. Are you sure you want to continue connecting (yes/no)? y Please type 'yes' or 'no': yes Warning: Permanently added '127.0.0.1' (RSA) to the list of known hosts. git@127.0.0.1's password:
Nell'ultima riga mi chiede una password di autenticazione, che non saprei nemmeno quale fornire. Ottengo lo stesso risultato eseguendo il test da una postazione remota, compare sempre la richiesta della password.
Fortunatamente è una questione semplice da risolvere, occorre abilitare l'utente git a ricevere connessioni tramite ssh. Occorre verificare nel file /etc/ssh/sshd_config che nella direttiva AllowUsers sia presente anche l'utente git, come segue:
AllowUsers user1 user2 git
Nel mio caso è stato sufficiente aggiungere l'utente git, e fare un restart del servizio sshd. Rifatti i test e tutto si comporta come ci aspettavamo al punto precedente.
Step 7 - recupero la vecchia installazione
Per copiare tutta l'installazione dal precedente server eseguo un backup, su un unico file:
$ cd /home/git $ tar -zcvf repositories-201511.tar.gz repositories
Una volta eseguito il backup, posso tramite ftp copiare il file sul server di destinazione.
Nella fase attuale, considerando che sto facendo delle prove in locale su una macchina vagrant, copio nella mia directory condivisa il file di backup.
Per eseguire l'operazione prima mi autentico con l'utente git, in modo da mantenere i permessi dei file evitando di impazzire. Scompattiamo ovviamente nella home dell'utente git:
$ tar -zxvf /vagrant_data/repositories-20151104.tar.gz
Non rimane che provare a clonare un repository puntando sul nuovo server e vedere che tutto funziona.
Concludiamo la migrazione gitosis server ultimo passo
Fatti tutti questi test con esito positivo, ora ho tutto quanto mi serve per eseguire l'installazione sul nuovo server.
In questo caso sono fiducioso che non serva nemmeno tenere le dita incrociate e che tutto vada per il meglio al primo colpo.
Gran finale
Installato il tutto sul nuovo server, occorre aggiornare opportunamente le copie di lavoro utilizzate, i vari cloni dei nostri repository.
Se il server git era raggiunto mediante un nome di domino configurato tramite dns, aggiornando il puntamento del dns tutto rimane trasparente.
Se invece i puntamenti al server erano fatti direttamente tramite indirizzo ip, allora occorre correggere l'indirizzo ip nella configurazione delle varie copie di lavoro, o cancellarle e clonarle nuovamente puntando al nuovo server. Attenzione che cancellando si perdono eventuali branch locali non condivisi sul server.
Disabilitare l'accesso al vecchio server
Non voglio ancora cancellare la vecchia configurazione, ma voglio forzare gli utenti a collegarsi al nuovo server, ad effettuare gli aggiornamenti necessari.
Agisco nel file /etc/ssh/sshd_config aggiungento la direttiva DenyUsers specificando l'utente git. In questo modo forzo la richiesta della password da parte del vecchio server impedendo di fatto che sia possibile operare pull e push sui branch dei vecchi repository.