+++
-title = "Git Setup Your Own Server"
+title = "Git: configura il tuo server personale."
date = "2021-06-13T12:07:49+02:00"
-
-type = "life"
-tags = ["git", "server", "setup", "howto", "do it yourself", "ssh"]
-image = "/uppies/2021/06/gitout.jpg"
+type = "tech"
+obsolete = true
author = "Danilo M."
-
+excerpt = "I'll show you how to setup your own git server easily"
+image = "/uppies/2021/06/gitout.jpg"
+tags = ["git", "linux", "server", "howto", "setup", "ssh", "do it yourself"]
+categories = [ "DIY", "Code"]
+++
-TODO: Tradurre questo articolo dall'inglese all'italiano.
+Ciao a tutti,
+
+Recentemente ho deciso di spostare tutto il mio codice su GIT. L'ho già usato in passato e ho utilizzato anche SVN, ma ritengo che GIT sia più intuitivo in alcuni aspetti.
+
+Per utilizzare Git, avevo bisogno di uno spazio online dove archiviare i miei progetti, e ho pensato che GitHub potesse essere una buona soluzione, ma il fatto che si debba pagare per mantenere un progetto privato non mi sembrava una scelta appropriata. Naturalmente, GitHub esiste per generare profitti (soprattutto ora che è stato acquistato da Microsoft), ma preferisco avere una configurazione più semplice e poter fare le cose a modo mio il più possibile.
+
+Quindi, ho iniziato a pianificare le caratteristiche che volevo per il mio server Git. Ecco una lista:
+
+* **Sicurezza**: ho deciso di farlo funzionare solo tramite SSH, in modo che solo chi possiede la chiave possa clonare o accedere al repository. Ho anche aggiunto un utente Git con privilegi limitati, che ha accesso solo a un numero molto ristretto di comandi, quindi anche se qualcuno riuscisse ad accedere tramite SSH, si troverebbe con solo poche opzioni disponibili.
+* **Notifiche**: il mio server mi comunica già molte cose, quindi volevo che il mio servizio Git facesse lo stesso. Ho implementato un servizio di posta elettronica che mi notifica ogni volta che viene aggiunto un nuovo repository o ogni volta che viene effettuato un push su un repository.
+* **Automazione**: volevo ridurre al minimo i passaggi tra la creazione del progetto e il deployment in produzione. Ora, in due passaggi, posso creare un repository e clonarlo sul mio computer locale, e una volta terminato, devo solo effettuare il push delle mie modifiche e il codice viene distribuito automaticamente.
+* **Visibilità**: non ho ancora deciso se voglio che il mio codice sia visibile, quindi non ho nemmeno iniziato a pensare a questa possibilità.
+
+## Installazione
+
+L'installazione di un server Git è piuttosto semplice una volta che si capisce come funziona. Sul mio server, si trattava di configurare un repository "bare", ma per ottenere il livello di sicurezza desiderato, sono stati necessari alcuni passaggi.
+
+> Una piccola precisazione: utilizzo Slackware64-14.2 sul mio server e Slackware64-current sul mio laptop, quindi tutti i comandi qui descritti hanno funzionato per me, ma non posso garantire che le procedure che ho seguito funzioneranno su distribuzioni diverse con configurazioni diverse. Se riscontri problemi nell'eseguire le operazioni descritte, fammelo sapere nei commenti e cercherò di aiutarti.
+
+Ho aggiunto un nuovo utente e gruppo al mio server, ma prima di farlo, ho aggiunto /usr/bin/git-shell a /etc/shells per poterlo utilizzare come shell di login per il mio utente Git.
+
+Ora l'utente è completamente configurato e pronto per essere utilizzato. Il prossimo passo sarà creare la directory .ssh e il file authorized\_keys per contenere le chiavi degli sviluppatori che devono accedere al server Git. Ecco come ho fatto:
+
+Ok, ora i file sono al loro posto e i permessi sono corretti per il corretto funzionamento di SSH.
+
+Torniamo ora al mio computer di lavoro. Ho creato una coppia di chiavi SSH per il mio utente abituale e ho copiato la chiave pubblica nel file authorized\_keys sul server. Non entrerò troppo nei dettagli su come farlo, ma un suggerimento: mantienila senza password, sarà molto più veloce da usare in seguito.
+
+Poiché ho accesso SSH allo stesso server per il mio utente normale, ho utilizzato il file ~/.ssh/config sul mio computer per impostare un nuovo host che faciliterà la mia routine di accesso per l'utente Git, nonché per il mio utente normale. Questa è la mia configurazione (più o meno):
+
+Ora, quando devo accedere al server con il mio utente normale, eseguirò semplicemente:
+
+e quando devo accedere come utente Git, eseguirò:
+
+e SSH si occuperà di tutte le opzioni e avvierà la connessione con le credenziali corrette. Ottimo!
+
+Ora che l'accesso per l'utente Git è configurato, dobbiamo fare un'ultima cosa prima di poterlo utilizzare. Gli daremo solo un numero limitato di comandi da utilizzare. In questo modo, l'utente Git avrà ancora più restrizioni e sarà molto più sicuro. Nella documentazione fornita con Git sono presenti molti script per aiutarti a iniziare, quindi li copieremo in una directory speciale chiamata git-shell-commands, come segue:
+
+Ora abbiamo due comandi all'interno della directory git-shell-commands: "list" e "help". Il primo mostrerà tutti i progetti all'interno della directory /var/git, mentre il secondo mostrerà un semplice testo di aiuto e un elenco di tutti i comandi disponibili. Ora, per darti un esempio di quanto sia facile aggiungere comandi a git-shell, creerò un semplice comando che funge da comando "clear", che pulirà lo schermo. Per farlo, all'interno della directory /var/git, ho eseguito:
+
+e ora ho un comando "clear" disponibile per il mio utente Git. Un altro comando utile sarà "create" per aggiungere un repository e "destroy" per rimuoverlo. Vediamoli nella pagina successiva.
+
+Nella prossima pagina ci concentreremo sui due script più importanti per il nostro server Git: lo script "create" e lo script "delete".
+
+### create
+
+Questo è lo script "create", come puoi vedere è un po' complesso perché farà diverse cose per me:
+
+* crea il repository "bare" utilizzando l'argomento fornito dalla riga di comando o chiedendo il nome del progetto;
+* verifica prima di creare il repository se esiste già un altro repository con lo stesso nome o se esiste una directory con file al suo interno. In questo modo, mi assicurerò di creare un repository solo all'interno di una directory vuota;
+* aggiunge una directory "custom-hooks" che conterrà un collegamento allo script multimail.py, nonché al mio script deploy.sh;
+* crea uno script "post-receive" che utilizza "pee" dal progetto [moreutils][1] per eseguire più script nello stesso hook;
+* assicura permessi corretti sull'intera directory del progetto;
+* presume sempre "no" (l'opzione più sicura) quando chiede all'utente quale azione intraprendere.
+
+Quindi, dopo aver salvato questo script come "create" all'interno della directory git-shell-commands, gli assegneremo i permessi di esecuzione e potremo passare allo script "delete".
+
+### delete
+
+Vediamo ora lo script "delete":
+
+Questo script è molto più semplice del precedente. Accetterà il nome del progetto come argomento dalla riga di comando o lo chiederà e lo eliminerà solo se si tratta di un repository Git valido, altrimenti si interromperà con un codice di errore.
+
+Ho migliorato il modo in cui questi script riconoscono un repository Git, passando dal semplice fatto di fare affidamento sul fatto che ci sia un file HEAD all'interno della directory che stanno controllando (che non era la soluzione migliore) all'utilizzo di Git stesso per verificare se la directory è un repository "bare". Molto meglio!
+
+Dato che siamo qui, modifichiamo il comando "help" in modo che mostri una breve descrizione di ogni comando disponibile.
+
+La cosa principale che ho aggiunto è il supporto per un argomento della riga di comando. Ora, posso eseguirlo da solo e visualizzare l'output abituale con un elenco dei comandi disponibili, oppure seguito dal nome di un comando per fornire una breve spiegazione, come questa:
+
+Abbastanza carino, vero? Ora è molto più facile da usare e, per mostrare la descrizione, ho utilizzato awk e cut per analizzare il commento all'inizio di ogni script che ho nella directory.
+
+Nella pagina successiva vedremo la routine abituale che seguo quando lavoro con questa nuova configurazione.
+
+## La mia routine Git
+
+Supponiamo di avere una nuova idea per un plugin di WordPress, non vedo l'ora di iniziare a scrivere, quindi la configurazione dell'ambiente Git dovrebbe essere il più rapida possibile. È qui che la mia configurazione sarà utile. Apriamo il terminale, andiamo nella mia directory di test e da lì eseguo:
+
+Il progetto è stato creato, ora devo solo clonarlo:
+
+E questo è tutto. Ora ho una copia locale e remota del mio repository Git pronta per essere utilizzata.
+
+Supponiamo di lavorare su questo plugin e di arrivare al punto in cui sento di poterlo utilizzare sul mio blog. Voglio che il deployment sia veloce come il resto del processo, quindi mi connetto tramite SSH come mio utente normale e modifico lo script nella directory per questo progetto per aggiungere la directory di lavoro e il branch che voglio utilizzare per il deployment (puoi usare "master", ma è meglio usare un branch diverso solo a questo scopo, in modo da poter mantenere il codice di produzione stabile e utilizzare "master" per sperimentare fino a quando non sarà pronto per il deployment).
+
+All'interno dello script deploy.sh, modificherò queste due righe:
+
+aggiungendo come e produzione come .
+
+Ora, sul mio sistema locale, aggiungerò un nuovo branch e lo utilizzerò prima di effettuare il commit del codice stabile.
+
+E questo è tutto. Ora il mio nuovo plugin è pronto per essere attivato nell'area di amministrazione di WordPress.
+
+## Conclusione
+
+Per ora è tutto. Aggiungerò a questo post non appena deciderò se voglio che il mio codice sia visibile o meno, ma per ora questa è la mia configurazione e finora sta funzionando alla grande.
+
+Se sei arrivato fin qui, spero che tu dedichi qualche minuto in più per farmi sapere cosa ne pensi di questa configurazione, se utilizzi qualcosa di simile o se hai avuto problemi a configurarla. Cercherò di aiutarti il più possibile.
+
+[1]: moreutils
\ No newline at end of file
