Der Puppet File Server
Dieses Handbuch behandelt die Verwendung der Dateiserving-Funktionen von Puppet.
Der Puppet Master Service enthält einen Dateiserver zum Übertragen statischer Dateien. Wenn eine Dateiressourcendeklaration einen Puppet: URI in ihrem Quellattribut enthält, rufen Knoten diese Datei vom Dateiserver des Masters ab:
# Kopieren Sie eine Remote-Datei nach / etc / sudoers
Datei {"/ etc / sudoers":
Modus => 440,
Besitzer => root,
Gruppe => Wurzel,
source => "Marionette: /// modules / module_name / sudoers"
}}
Alle Puppet-Dateiserver-URIs sind wie folgt strukturiert:
puppet://{server hostname (optional)}/{mount point}/{remainder of path}
Wenn ein Server-Hostname weggelassen wird (dh puppet:///{mount point}/{path}der dreifache Schrägstrich beachten), wird der URI auf den Server aufgelöst, den der auswertende Knoten als seinen Master betrachtet. Da dies Manifest-Code portabler und wiederverwendbarer macht, sollten Hostnamen nach Möglichkeit weggelassen werden.
Der Rest der Marionette: URI wird auf zwei Arten dem Dateisystem des Servers zugeordnet, je nachdem, ob die Dateien von a bereitgestellt moduleoder über a verfügbar gemacht werden custom mount point.
Moduldateien bereitstellen
Da die überwiegende Mehrheit der Dateiservierung über Module erfolgen sollte, bietet der Puppet-Dateiserver einen speziellen und halbmagischen Einhängepunkt namens Module, der standardmäßig verfügbar ist. Wenn der Mount-Punkt eines URI Module sind, führt Puppet Folgendes aus:
- Interpretieren Sie das nächste Segment des Pfades als den Namen eines Moduls…
- ... suchen Sie dieses Modul im Modulpfad des Servers (wie hier unter "Modul-Suche" beschrieben ...)
- ... und lösen Sie den Rest des Pfads auf, der in den Dateien / im Verzeichnis dieses Moduls beginnt.
Das heißt, wenn ein Modul mit dem Namen test_module im /etc/puppet/modulesVerzeichnis des zentralen Servers installiert ist , wird die folgende Marionette angezeigt : URI ...
puppet:///modules/test_module/testfile.txt
... wird in den folgenden absoluten Pfad aufgelöst:
/etc/puppet/modules/test_module/files/testfile.txt
Wenn test_moduleinstalliert /usr/share/puppet/modules, würde derselbe URI stattdessen aufgelöst in:
/usr/share/puppet/modules/test_module/files/testfile.txt
Obwohl für die Verwendung des Modul-Einhängepunkts keine zusätzliche Konfiguration erforderlich ist, können einige Zugriffssteuerungen in der Dateiserverkonfiguration durch Hinzufügen eines [modules]Konfigurationsblocks angegeben werden. Siehe Sicherheit.
Bereitstellen von Dateien von benutzerdefinierten Einhängepunkten
Puppet kann auch Dateien von beliebigen Mountpunkten bereitstellen, die in der Dateiserverkonfiguration des Servers angegeben sind (siehe unten). Beim Bereitstellen von Dateien von einem benutzerdefinierten Bereitstellungspunkt aus führt Puppet die zusätzliche URI-Abstraktion, die beim Bereitstellen des Moduls verwendet wird, nicht durch und löst den Pfad nach dem Bereitstellungsnamen als einfache Verzeichnisstruktur auf.
Dateiserverkonfiguration
Der Standardpfad für die Konfigurationsdaten des Dateiservers ist /etc/puppet/fileserver.conf; Dies kann geändert werden, indem die --fsconfigFlagge an den Puppenmeister übergeben wird.
Das Format der fileserver.confDatei entspricht fast genau dem von rsyncund ähnelt in etwa einer INI-Datei:
[mount_point]
path /path/to/files
allow *.domain.com
deny *.wireless.domain.com
Die folgenden Optionen können derzeit für einen bestimmten Einhängepunkt angegeben werden:
- Der Pfad zum Speicherort des Mount auf der Festplatte
- Beliebig viele Zulassungsanweisungen
- Beliebig viele Verweigerungsanweisungen
Pfad ist die einzige erforderliche Option. Da die Standardsicherheitskonfiguration jedoch darin besteht, jeglichen Zugriff zu verweigern, steht keinem Knoten ein Mount-Punkt ohne Zulassungsanweisungen zur Verfügung.
Der Pfad kann eine oder alle enthalten %h, %Hund %d, die von der Client-Host - Namen dynamisch ersetzt werden, seinen vollqualifizierten Domain - Namen und den Domänennamen auf. Alle werden aus dem SSL-Zertifikat des Clients übernommen (seien Sie also vorsichtig, wenn Hostname / Zertifikatname nicht übereinstimmen). Dies ist nützlich beim Erstellen von Modulen, in denen Dateien für jeden Client vollständig separat aufbewahrt werden, z. B. für private SSH-Hostschlüssel. Zum Beispiel mit der Konfiguration
[private]
path /data/private/%h
allow *
Die Anforderung einer Datei /private/file.txtvom Client client1.example.com sucht nach einer Datei /data/private/client1/file.txt, während dieselbe Anforderung von client2.example.comversucht, die Datei /data/private/client2/file.txt auf dem Dateiserver abzurufen.
Derzeit dürfen Pfade keine abschließenden Schrägstriche enthalten, da sonst ein Fehler auftritt. Achten Sie auch darauf, dass puppet.confSie keine Verzeichnispositionen mit abschließenden Schrägstrichen angeben.
Sicherheit
Das Sichern des Puppet-Dateiservers besteht darin, den Zugriff (mit unterschiedlichen Spezifitätsstufen) pro Mountpunkt zuzulassen und zu verweigern. Gruppen von Knoten können auf drei Arten zur Berechtigung oder Verweigerung identifiziert werden: anhand der IP-Adresse, des Namens oder eines einzelnen globalen Platzhalters (*). Benutzerdefinierte Einhängepunkte verweigern standardmäßig jeglichen Zugriff.
Zusätzlich zu benutzerdefinierten Einhängepunkten gibt es zwei spezielle Einhängepunkte, die verwaltet werden können fileserver.conf: modulesund plugins. Für keinen dieser Einhängepunkte sollte eine Pfadoption angegeben werden. Das Verhalten des Mount-Punkts des Moduls wird oben unter Serving Files From Custom Mount Points beschrieben. Der Plugins-Mount ist kein echter Mount-Punkt, sondern ein Hook, mit dem fileserver.conf angeben kann, welche Knoten Plugins vom Puppet Master synchronisieren dürfen. Diese beiden Einhängepunkte sind standardmäßig vorhanden, und beide erlauben standardmäßig den gesamten Zugriff. Wenn für eine dieser speziellen Bereitstellungen Zulassungs- oder Verweigerungsanweisungen festgelegt sind, verhalten sich die Sicherheitseinstellungen wie bei einer normalen Bereitstellung (dh standardmäßig wird der gesamte Zugriff verweigert). Beachten Sie, dass dies die einzigen Einhängepunkte sind, für die die Verweigerung * nicht redundant ist.
Wenn Knoten keine direkte Verbindung zum Puppet-Dateiserver herstellen, z. B. über einen Reverse-Proxy und Mongrel (siehe Verwenden von Mongrel), werden auf dem Dateiserver alle Verbindungen von der IP-Adresse des Proxyservers und nicht von der des Puppet-Agent-Knotens angezeigt . In diesem Fall ist es am besten, den Zugriff basierend auf dem Hostnamen einzuschränken. Darüber hinaus müssen die Maschinen, die als Reverse-Proxy fungieren (normalerweise 127.0.0.0/8), Zugriff auf die entsprechenden Einhängepunkte haben.
Priorität
Spezifischere Ablehnungs- und Zulassungsanweisungen haben Vorrang vor weniger spezifischen Anweisungen. Das heißt, eine allow-Anweisung für node.domain.com würde eine Verbindung trotz einer verweigerenden Anweisung für * .domain.com ermöglichen. Bei einer bestimmten Spezifität haben Verweigerungsanweisungen Vorrang vor Zulassungsanweisungen.
Unvorhersehbares Verhalten kann durch das Mischen von IP-Adressanweisungen mit Hostnamen- und Domänennamenanweisungen entstehen. Versuchen Sie daher, dies zu vermeiden. (Wenn derzeit die IP-Adresse von node.domain.com 192.168.1.80 lautet und fileserver.conf allow 192.168.1.80 enthält und node.domain.com verweigert, hat die IP-basierte Anweisung allow tatsächlich Vorrang. Dieses Verhalten kann in der Zukunft und sollte nicht verlassen werden.)
Hostnamen
Hostnamen können entweder mit einem vollständigen Hostnamen oder mit dem Platzhalter * angegeben werden:
[export]
path /export
allow host.domain1.com
allow *.domain2.com
deny badhost.domain2.com
IP-Adressen
Die IP-Adresse kann ähnlich wie die Hostnamen angegeben werden, wobei entweder vollständige IP-Adressen oder Platzhalteradressen verwendet werden. Sie können auch die CIDR-Notation verwenden:
[export]
path /export
allow 127.0.0.1
allow 192.168.0.*
allow 192.168.1.0/24
Globale Erlaubnis
Durch Angabe eines einzelnen Platzhalters kann jeder Knoten auf einen Einhängepunkt zugreifen:
[export]
path /export
allow *
Beachten Sie, dass das Standardverhalten für benutzerdefinierte Einhängepunkte dem Verweigern * entspricht.