Creare siteconf-site e moudule-site

.gitignore

@@ -0,0 +1 @@
+site-conf/

README.md

@@ -1,8 +1,7 @@
 Puppet-deploy
 =============
 
-
-Ovvero della centralizzazione, automazione delle configurazioni per indivia/ortiche. 
+Ovvero della centralizzazione, automazione e documentazione delle configurazioni di un server autogestito
 
 ### Requisiti
 
@@ -14,65 +13,164 @@ Ovvero della centralizzazione, automazione delle configurazioni per indivia/orti
 
 #### Git
  - [Git](http://www.git-scm.com/)
- - **git submodules**
-  - [Pro Git book](http://git-scm.com/book/en/v2/Git-Tools-Submodules)
+
+#### gcrypt
+ - [Github](https://github.com/joeyh/git-remote-gcrypt)
+ - In Debian 7.x Wheezy si installa da backports
+
+#### MyRepos
+ - https://myrepos.branchable.com/
 
 #### Riseup shared puppet modules
- - [Shared puppet modules](https://labs.riseup.net/code/projects/sharedpuppetmodules)
+ - [Shared puppet modules](https://gitlab.com/groups/shared-puppet-modules-group)
 
-#### 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
+ - Mantenere logica, dati e configurazioni separati
+ - Avere un versioning delle confgiurazioni
+ - Facilitare la collaborazione degli amministratori nel mantenimento dei server/servizi
+ - Facilitare la collaborazione nello sviluppo degli strumenti
  - Collaborare con gli altri collettivi/server/reti
+ - Evitare Single Point of Failure
+ - Non creare tool nuovi, utilizzare l'esistente (soprattutto se conosciuto)
 
 #### 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. 
+##### MyRepos
+ - Tutto parte dalla configurazione di mr, che elenca quali repository scaricare e mantenere aggiornati.
+ - **/root/.mrconfig** elenca i repository ed e' parametrizzato in funzione di SITE, HOSTNAME e REPO_ROOT
+<pre>
+[DEFAULT]
+lib = SITE="nome_site" && \
+  HOSTFQDN="$(hostname --fqdn)" && HOSTNAME="$(hostname)" && \
+  REPO_ROOT="git@gitlab.com:organization/"
+[/etc/puppet]
+checkout = git clone ${REPO_ROOT}/puppet-deploy.git puppet
+order = 1
+[/etc/puppet/site-conf]
+checkout = git clone gcrypt::${REPO_ROOT}/siteconf-${SITE}.git site-conf
+order = 2
+chain = true
+[/etc/puppet/site-conf/host-conf]
+checkout = git clone gcrypt::${REPO_ROOT}/hostconf-${HOSTNAME}.git host-conf
+order = 3
+chain = true
+[/etc/puppet/modules/common]
+checkout = git clone ${REPO_ROOT}/module-common.git common
+order = 4
+[/etc/puppet/modules/stdlib]
+checkout = git clone ${REPO_ROOT}/puppetlabs-stdlib.git stdlib
+        cd stdlib && git checkout tags/4.5.1
+order = 4
+[/etc/puppet/modules/apt]
+checkout = git clone ${REPO_ROOT}/module-apt.git apt
+order = 4
+[/etc/puppet/modules/concat]
+checkout = git clone ${REPO_ROOT}/module-concat.git concat
+order = 4
+[/etc/puppet/modules/lsb]
+checkout = git clone ${REPO_ROOT}/module-lsb.git lsb
+order = 4
+[/etc/puppet/modules/postfix]
+checkout = git clone ${REPO_ROOT}/module-postfix.git postfix
+order = 4
+</pre>
+ - **/root/.mrtrust** istruisce myrepos per fidarsi dei file .mrconfig inclusi nei repository di configurazione del sito e dell'host
+<pre>
+/etc/puppet/site-conf/.mrconfig
+/etc/puppet/site-conf/host-conf/.mrconfig
+</pre>
 
-##### Progetti Git
- - **[puppet-deploy](http://git.lattuga.net/opuppet/puppet-deploy)**
-  - E' il progetto principale in cui viene mantenuta tutta la configurazione di puppet;
+##### Repository Git
+ - **[<font color="yellow">conf</font>, <font color="red">world-wide</font>, <font color="red">clear</font>]** **[puppet-deploy](http://git.lattuga.net/opuppet/puppet-deploy)**
+  - E' il progetto principale in cui viene mantenuta tutta e sola la configurazione di puppet e hiera;
   - 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.  
+  - **NON** contiene dati o tabelle utenti; 
+  - Il file `manifests/site.pp` contiene la dichiarazione di default per i nodi, che include i ruoli definiti nella configurazione [`hiera_include('host-roles')`]
 
- - **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.
+ - **[<font color="cyan">logic</font>, <font color="red">world-wide</font>, <font color="red">clear</font>]** **module-$(prog-name)** 
+  - Quando disponibile il clone iniziale deriva da gli [shared puppet module](https://gitlab.com/groups/shared-puppet-modules-group)
+  - Sono i moduli puppet responsabili di una singola funzionalita'/programma
+  - Rappresentano il principale luogo di collaborazione nella comunita'. Committare sui moduli upstream significa sviluppare la logica su cui tutti i siti si basano. 
+  - Es: module-postfix, module-apt, etc. 
 
-#### 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. 
+ - **[<font color="yellow">conf</font>, <font color="orange">site-wide</font>, <font color="green">gcrypt</font>]** **siteconf-$(site-name)** 
+  - Contiene principalmente (solo?) due file:
+   - site.yaml: file utilizzato da hiera per determinare le proprieta' e le configurazioni specifiche di un sito
+   - .mrconfig: configurazione di myrepos per includere i moduli (repository git) specifici per un sito
 
- - 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>
+ - **[<font color="cyan">logic</font>, <font color="orange">site-wide</font>, <font color="green">gcrypt</font>]** **module-$(site-name)** 
+  - Modulo (o moduli) specifici del sito (es. ortiche), che contiene funzionalita' utili solo per uno specifico gruppo di server; 
+  - Esistono due differenti filosofie da valurare
+   - O questo modulo non dovrebbe esistere e tutte le funzionalita' utili dovrebbero essere portate upstream in un modulo condiviso oppure, se sono specifiche di un server, incluse in un modulo module-$(server-name).
+   - Oppure posso utilizzarlo per distribuire le chiavi, file, configurazioni comuni ai server di uno stesso sito
+  - Es: module-ortiche
 
- - Installare un nuovo server Debian wheezy e configurare Git/puppet 
-  1. `wget https://apt.puppetlabs.com/puppetlabs-release-wheezy.deb && dpkg -i puppetlabs-release-wheezy.deb && apt-get update`
-  2. Creare il file `/etc/apt/preferences.d/00-puppet.pref` con le seguente configurazione:
+ - **[<font color="yellow">conf</font>, <font color="green">host-wide</font>, <font color="green">gcrypt</font>]** **hostconf-$(server-name)**
+  - Contiene principalmente (solo?) due file:
+   - host.yaml: file utilizzato da hiera per determinare le proprieta' e le configurazioni specifiche del server
+   - .mrconfig: configurazione di myrepos per includere i moduli (repository git) specifici per il server
+
+ - **[<font color="cyan">logic</font>, <font color="green">host-wide</font>, <font color="green">gcrypt</font>]** **module-$(server-name)** 
+  - Modulo che contiene la logica specifica per un unico server
+  - Includo qui i file sensibili per un unico server?
+
+
+### Installare e configurare un nuovo server
+
+#### Creare un nuovo $(site-name)
+##### Configurazione siteconf-$(sitename)
+  1. Creare il repository git per la configurazione del site 
+	`git init siteconf-$(sitename)`
+  2. (Opzionale) Creare il repositori bare remoto
+  3. Configurare il nuovo repository per usare un remote crittato con gcrypt: <pre>cd siteconf-$(sitename)/
+git remote add $(gcrypt_remote) gcrypt::<repo_location>/siteconf-$(site-name).git
+git config remote.$(gcrypt_remote).gcrypt-participants "$(sysadm1-key-fingerprint) $(sysadm2-key-fingerprint) $(server1-key-fingerprint) $(server2-key-fingerprint)"
+git config remote.$(gcrypt_remote).gcrypt-publish-participants true
+touch README
+git add .
+git commit -m "Initial gcrypt commit"
+git push --set-upstream $(gcrypt_remote) master</pre>
+
+**E' importante importare le chiavi pubbliche di TUTTI i sysadmin e TUTTI i servers elencati in `gcrypt-participants` prima di continuare oltre**
+
+
+##### Configurazione module-$(sitename)
+  0. Creare un file .mrconfig nel repository siteconf-$(sitename) contenente i dettagli del repository di module-$(sitename)
+<pre>[DEFAULT]
+lib = SITE="$(sitename)" && \
+	HOSTFQDN="$(hostname --fqdn)" && HOSTNAME="$(hostname)" && \
+        REPO_ROOT="git@gitlab.com:organization/"
+
+[/etc/puppet/modules/$(modulename)]
+checkout = git clone gcrypt::${REPO_ROOT}/module-${SITE}.git $(modulename)]
+order=3</pre>
+  2. Committare/pushare/aggiornare siteconf-$(modulename)
+  1. Creare il repository git per la configurazione del site 
+	`git init module-$(sitename)`
+  2. (Opzionale) Creare il repositori bare remoto
+  3. Configurare il nuovo repository per usare un remote crittato con gcrypt: <pre>cd module-$(sitename)/
+git remote add $(gcrypt_remote) gcrypt::<repo_location>/module-$(site-name).git
+git config remote.$(gcrypt_remote).gcrypt-participants "$(sysadm1-key-fingerprint) $(sysadm2-key-fingerprint) $(server1-key-fingerprint) $(server2-key-fingerprint)"
+git config remote.$(gcrypt_remote).gcrypt-publish-participants true
+touch README
+git add .
+git commit -m "Initial gcrypt commit"
+git push --set-upstream $(gcrypt_remote) master</pre>
+
+**E' importante importare le chiavi pubbliche di TUTTI i sysadmin e TUTTI i servers elencati in `gcrypt-participants` prima di continuare oltre**
+
+#### Configurazione di un server base, senza moduli specifici per site o host
+  1. Installare un nuovo server Debian Wheezy
+  2. Abilitare i backports (necessari per `git-remote-gcrypt`) 
+     `echo "deb http://http.debian.net/debian wheezy-backports main" >> /etc/apt/sources.list`
+  3. Aggiungere i repository dei PuppetLabs (per le versioni aggiornate di puppet)
+     `wget https://apt.puppetlabs.com/puppetlabs-release-wheezy.deb && dpkg -i puppetlabs-release-wheezy.deb
+  4. Creare il file `/etc/apt/preferences.d/00-puppet.pref` con le seguente configurazione:
      `Package: puppet puppet-common
       Pin: version 3.7*
       Pin-Priority: 999
@@ -80,19 +178,21 @@ Ovvero della centralizzazione, automazione delle configurazioni per indivia/orti
       Package: facter
       Pin: version 2.3*
       Pin-Priority: 999`
-  3. Aggiungere la linea `echo "deb http://http.debian.net/debian wheezy-backports main" >> /etc/apt/sources.list && apt-get update`
-  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`
+  5. Aggiornare la lista dei pacchetti disponibili
+     `apt-get update`
+  6. Da root `apt-get install puppet git git-remote-gcrypt myrepos`
+  7. Eliminare i file esistenti per puppet `rm -rf /etc/puppet`
+  8. Generare una nuova coppia di chiavi gpg `gpg --gen-key`
+  9. Configurare sul repository git l'account e i permessi per il nuovo server. Questo passo potrebbe non essere indispensabile, dipende dal repository configurato.
+  10. (Opzionale) Configurare l'agent gpg
+  10. Copiare i file `.mrconfig` e `.mrtrust` forniti sopra in `/root` e configurare le variabili `SITE` e `REPO_ROOT` in `.mrconfig`.
+  11. Eseguire l'update di tutti i moduli `mr -d /etc/ update`
+  12. Lanciare l'esecuzione di puppet  `puppet apply -v /etc/puppet/manifests/site.pp`
+
 
- - 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`
 

hiera.yaml

@@ -1,7 +1,7 @@
 :hierarchy:
-    - ortiche-host/host
-    - defaults
+    - host-conf/host
+    - site
 :backends:
     - yaml
 :yaml:
-    :datadir: '/etc/ortiche-conf/hiera/'
+    :datadir: '/etc/puppet/site-conf/'

manifests/site.pp

@@ -1,6 +1,12 @@
-$admin=hiera('ortiche-admin')
+# Main manifest, contains default definition
+# Setup is configured to be masterless and nameless [0]
+# By now configuration is hiera-based [1], but it could be fact-driven
+# [0] http://www.vmdoh.com/blog/why-you-should-be-using-nodeless-masterless-puppet
+# [1] https://docs.puppetlabs.com/hiera/1/puppet.html#assigning-classes-to-nodes-with-hiera-hierainclude
+
+$admin=hiera('host-admin',"root@$::fqdn")
 notify{"This node is mantained by ${::admin}": }
 
 node default {
-  hiera_include('ortiche-roles')
+  hiera_include('host-roles', '')
 }