puppet-deploy/README.md

Puppet-deploy
=============


Ovvero della centralizzazione, automazione delle configurazioni per indivia/ortiche. 

### Requisiti

#### Puppet
 - [Puppet](https://puppetlabs.com/)
 - [Puppet modules](https://docs.puppetlabs.com/puppet/latest/reference/modules_fundamentals.html)
 - **puppet masterless**
  - [puppet masterless server automation on a very small scale](https://www.tiredpixel.com/2014/02/23/puppet-masterless-server-automation-on-a-very-small-scale/)

#### Git
 - [Git](http://www.git-scm.com/)
 - **git submodules**
  - [Pro Git book](http://git-scm.com/book/en/v2/Git-Tools-Submodules)

#### Riseup shared puppet modules
 - [Shared puppet modules](https://labs.riseup.net/code/projects/sharedpuppetmodules)

#### Gogs
 - [Gogs](http://gogs.io/)
 - **http://gogs.lattuga.net**

#### Presupposti
 - Semplificare l'installazione l'installazione di un nuovo server
 - Semplificare la reinstallazione di un server esistente
 - Mantenere tutte le configurazioni in un'unico repository, con history
 - Poter collaborare facilmente al mantenimento dei server e servizi
 - Evitare Single Point of Failure
 - Usare tool standard diffusi e minimamente conosciuti anche da noi
 - Collaborare con gli altri collettivi/server/reti

#### Architettura

##### Gogs
 - **Organizzazione [opuppet](http://git.lattuga.net/org/opuppet)**
  A questa fanno riferimento tutti i repository. I permessi sui repository di un'organizzazione non vengono definiti per utente, bensi' per team. In opuppet ne sono definiti tre: 
  - *Owners* possono creare nuovi repository e chiaramente leggere e scrivere. Di questa fanno parte tutti gli sviluppatori
  - *Developers* ha permessi di lettura/scrittura sui repository esistenti.
  - *Deploy* ha i permessi di lettura sui repository. A questo team appartengono tutti i server. 

##### Progetti Git
 - **[puppet-deploy](http://git.lattuga.net/opuppet/puppet-deploy)**
  - E' il progetto principale in cui viene mantenuta tutta la configurazione di puppet;
  - Ogni sviluppatore ha un account read-write sul repository centrale di questo progetto;
  - Una copia del repository e' distribuita su ogni server, con account read-only, nella directory `/etc/puppet` (su Debian);
  - **NON** contiene dati sensibili (chiavi e password); 
  - **NON** contiene tabelle utenti; 
  - Il file `manifests/site.pp` contiene tutte le associazioni server/servizio e quindi le dichiarazioni delle classi (**PER ORA**: bisogna valutare se implemntare un semplice [External Node Classifier](https://docs.puppetlabs.com/guides/external_nodes.html) )
  - Tutte le funzionalita', i [moduli puppet](https://docs.puppetlabs.com/puppet/latest/reference/modules_fundamentals.html), sono sottomoduli (`git submodule`) del progetto e **obbligatoriamente** ospitati su un nostro repository.  

 - **module-$name**
  - Ogni modulo ha un suo repository con la convenzione `http://git.lattuga.net/opuppet/module-$name`; 
  - Quando possibile il clone iniziale avviene da gli shared puppet module di riseup **NON** dai 'moduli personali' ne' di riseup, ne' dei collettivi. Esempio: `https://labs.riseup.net/git/shared-apt.git` e' il modulo **shared** mentre `https://labs.riseup.net/git/module-apt.git` e' il modulo privato di riseup, `https://git.puppet.immerda.ch/module-apt/` e' il modulo di quelli di immerda;
  - Quando nel progetto principale viene eseguito un `git submodule add` questo **DEVE** puntare ad un url ospitata dal nostro repository.

#### Workflow
 - Aggiungere uno sviluppatore a opuppet su Gogs
  1. Creare l'utente <developer> dalla pagina di [registrazione](http://git.lattuga.net/user/sign_up). L'indirizzo email deve essere valido per procedere all'attivazione dell'utente;
  2. Aggiungere l'utente <developer> al team "Developer" dell'organizzazione opuppet. 

 - Aggiungere un server a opuppet su Gogs
  1. Creare un indirizzo email da associare all'utente. Per esempio, su indivia, `php vmail.php -na <hostname>@ortiche.net gestione@posta.indivia.net` ;
  2. Se non esiste gia', generare sul server <hostname> una nuova coppia di chiavi ssh per l'utente root (`ssh-keygen -b 4096 -t rsa`). Se i filename delle chiavi non vengono modificati allora e' sufficiente questo passo, altrimenti sara' necessario aggiungere le entry corrispondenti in `/root/.ssh/config` ;
  3. Creare l'utente <hostname> dalla pagina di [registrazione](http://git.lattuga.net/user/sign_up). L'indirizzo email deve essere valido per procedere all'attivazione dell'utente;
  4. Associare la chiave ssh generata, all'utente <hostname> su gogs;
  5. Aggiungere l'utente <hostname> al team "Deploy" dell'organizzazione opuppet. 
  6. Testare eseguendo `git clone --recursive gogs@lattuga.net:opuppet/puppet-deploy.git` sul server <hostname>

 - Installare un nuovo server e configurare Git/puppet
  1. Da root `apt-get install puppet git`
  2. Eliminare i file esistenti per puppet: `rm -rf /etc/puppet`
  3. Aggiungere l'utente specifico del server sulla piattaforma Gogs (vedi piu' in alto) 
  4. Clonare il repository puppet-deploy al punto della configurazione di puppet: `cd /etc && git clone --recursive gogs@lattuga.net:opuppet/puppet-deploy.git`

 - Aggiungere la configurazione di un nuovo server in puppet-deploy
 - Aggiungere un submodule a puppet-deploy


#### Appunti 
 - **module naming convention**
   Dalla [documentazione di puppet](https://docs.puppetlabs.com/puppet/latest/reference/modules_fundamentals.html#manifests): *`init.pp` is special and always contains a class with the same name as the module. You may not have a class named init.*
 - **riseup clone workaround**
   Invece di eseguire `git clone https://labs.riseup.net/git/shared-$name.git` e' necessario modificare l'url in modo che diventi `git clone https://labs.riseup.net/code/shared-$name.git`