Il file server Puppet
Questa guida illustra l'uso della funzionalità di gestione dei file di Puppet.
Il servizio di burattinaio include un file server per il trasferimento di file statici. Se una dichiarazione di risorsa file contiene un pupazzo: URI nel suo attributo di origine, i nodi recupereranno quel file dal file server del master:
# copia un file remoto su / etc / sudoers
file {"/ etc / sudoers":
mode => 440,
proprietario => root,
gruppo => root,
source => "puppet: /// modules / module_name / sudoers"
}
Tutti gli URI del file server fantoccio sono strutturati come segue:
puppet://{server hostname (optional)}/{mount point}/{remainder of path}
Se viene omesso un nome host del server (ovvero puppet:///{mount point}/{path}; nota la barra tripla), l'URI si risolverà su qualsiasi server che il nodo di valutazione considera essere il suo master. Poiché ciò rende il codice manifest più portatile e riutilizzabile, i nomi host dovrebbero essere omessi ogni volta che è possibile.
Il resto del pupazzo: l'URI viene mappato al filesystem del server in due modi, a seconda che i file siano forniti da a moduleo esposti attraverso a custom mount point.
File dei moduli di servizio
Poiché la stragrande maggioranza dei file serviti dovrebbe essere eseguita tramite moduli, il file server Puppet fornisce un punto di montaggio speciale e semi-magico chiamato moduli, che è disponibile per impostazione predefinita. Se il punto di montaggio di un URI è costituito da moduli, Puppet:
- Interpreta il segmento successivo del percorso come il nome di un modulo ...
- ... trova quel modulo nel modulepath del server (come descritto qui sotto "Ricerca modulo" ...
- ... e risolvi il resto del percorso che inizia nella directory / file di quel modulo.
Vale a dire, se un modulo chiamato test_module è installato nella /etc/puppet/modulesdirectory del server centrale , il seguente pupazzo: URI ...
puppet:///modules/test_module/testfile.txt
... risolverà al seguente percorso assoluto:
/etc/puppet/modules/test_module/files/testfile.txt
Se test_modulefosse installato /usr/share/puppet/modules, lo stesso URI avrebbe invece risolto:
/usr/share/puppet/modules/test_module/files/testfile.txt
Sebbene non sia necessaria alcuna configurazione aggiuntiva per utilizzare il mount point dei moduli, è possibile specificare alcuni controlli di accesso nella configurazione del file server aggiungendo un [modules]blocco di configurazione; vedi Sicurezza.
Elaborazione di file da punti di montaggio personalizzati
Puppet può anche servire file da punti di montaggio arbitrari specificati nella configurazione del file server del server (vedi sotto). Quando si forniscono file da un punto di montaggio personalizzato, Puppet non esegue l'astrazione URI aggiuntiva utilizzata nel montaggio dei moduli e risolverà il percorso seguendo il nome di montaggio come una semplice struttura di directory.
Configurazione del file server
Il percorso predefinito per i dati di configurazione del file server è /etc/puppet/fileserver.conf; questo può essere cambiato passando la --fsconfigbandiera al burattinaio.
Il formato del fileserver.conffile è quasi identico a quello di rsynce assomiglia approssimativamente a un file INI:
[mount_point]
path /path/to/files
allow *.domain.com
deny *.wireless.domain.com
Al momento è possibile specificare le seguenti opzioni per un determinato punto di montaggio:
- Il percorso della posizione del mount sul disco
- Qualsiasi numero di direttive di autorizzazione
- Qualsiasi numero di direttive negate
path è l'unica opzione richiesta, ma poiché la configurazione di sicurezza predefinita prevede di negare qualsiasi accesso, un punto di montaggio senza direttive di autorizzazione non sarebbe disponibile per nessun nodo.
Il percorso può contenere uno o tutti %h, %He %d, che vengono dinamicamente sostituito con l'hostname del client, il suo nome di dominio completo e il suo nome di dominio, rispettivamente. Tutti sono presi dal certificato SSL del client (quindi fai attenzione se non hai corrispondenze di nome host / nome certificato). Ciò è utile nella creazione di moduli in cui i file per ciascun client sono tenuti completamente separatamente, ad esempio per le chiavi private dell'host ssh. Ad esempio, con la configurazione
[private]
path /data/private/%h
allow *
la richiesta di file /private/file.txtdal client client1.example.com cercherà un file /data/private/client1/file.txt, mentre la stessa richiesta client2.example.comproverà a recuperare il file /data/private/client2/file.txt sul file server.
Attualmente i percorsi non possono contenere barre finali o si verificherà un errore. Inoltre, accertati che in puppet.confte non si specifichino percorsi di directory che presentano barre finali.
Sicurezza
La protezione del file server Puppet consiste nel consentire e negare l'accesso (a vari livelli di specificità) per punto di montaggio. I gruppi di nodi possono essere identificati per l'autorizzazione o il rifiuto in tre modi: tramite indirizzo IP, nome o tramite un singolo carattere jolly globale (*). I punti di montaggio personalizzati non consentono l'accesso per impostazione predefinita.
Oltre ai punti di montaggio personalizzati, ci sono due punti di montaggio speciali che possono essere gestiti con fileserver.conf: modulese plugins. Nessuno di questi punti di montaggio dovrebbe avere un'opzione path specificata. Il comportamento del punto di montaggio dei moduli è descritto sopra in Elaborazione di file da punti di montaggio personalizzati. Il mount dei plugin non è un vero mount point, ma è piuttosto un hook per consentire a fileserver.conf di specificare quali nodi sono autorizzati a sincronizzare i plugin dal Puppet Master. Entrambi questi punti di montaggio esistono per impostazione predefinita ed entrambi consentono automaticamente l'accesso; se per uno di questi supporti speciali sono state impostate direttive di consenso o rifiuto, le sue impostazioni di sicurezza si comporteranno come quelle di un montaggio normale (ovvero, per impostazione predefinita, negherà qualsiasi accesso). Si noti che questi sono gli unici punti di montaggio per i quali negare * non è ridondante.
Se i nodi non si connettono direttamente al file server Puppet, ad esempio utilizzando un proxy inverso e Mongrel (consultare Uso di Mongrel), il file server vedrà tutte le connessioni come provenienti dall'indirizzo IP del server proxy anziché da quello del nodo Puppet Agent . In questo caso, è meglio limitare l'accesso in base al nome host. Inoltre, le macchine che agiscono come proxy inverso (di solito 127.0.0.0/8) dovranno poter accedere ai punti di montaggio applicabili.
Priorità
Dichiarazioni di rifiuto e autorizzazione più specifiche hanno la precedenza su dichiarazioni meno specifiche; vale a dire un'istruzione allow per node.domain.com consentirebbe la connessione nonostante un'istruzione deny per * .domain.com. A un determinato livello di specificità, le dichiarazioni di rifiuto hanno la precedenza sulle dichiarazioni di consenso.
Un comportamento imprevedibile può derivare dalla combinazione delle direttive sull'indirizzo IP con le direttive nome host e nome dominio, quindi cerca di evitare di farlo. (Attualmente, se l'indirizzo IP di node.domain.com è 192.168.1.80 e fileserver.conf contiene consentire 192.168.1.80 e negare node.domain.com, la direttiva di autorizzazione basata su IP avrà effettivamente la precedenza. Questo comportamento può essere modificato nella futuro e non dovrebbe essere invocato.)
Nomi host
I nomi host possono essere specificati utilizzando un nome host completo o specificando un intero dominio utilizzando il carattere jolly *:
[export]
path /export
allow host.domain1.com
allow *.domain2.com
deny badhost.domain2.com
Indirizzi IP
L'indirizzo IP può essere specificato in modo simile ai nomi host, utilizzando indirizzi IP completi o indirizzi jolly. Puoi anche usare la notazione in stile CIDR:
[export]
path /export
allow 127.0.0.1
allow 192.168.0.*
allow 192.168.1.0/24
Consenti globale
Se si specifica un carattere jolly singolo, qualsiasi nodo accederà a un punto di montaggio:
[export]
path /export
allow *
Si noti che il comportamento predefinito per i punti di montaggio personalizzati equivale a negare *.