Linux Notizen

Puppet 5 unterstützt jetzt offiziell hiera-eyaml direkt ohne, dass zusätzliche Rubygems installiert werden müssen. Grundsätzlich funktioniert hiera-eyaml in etwa so: Der Puppet Coder verschlüsselt die geheimen Daten mit dem öffentlichen Schlüssel und speichert dies mit den Hiera Daten Der Puppet-Server entschlüsselt diese Daten dann transparent via Lookup/hiera mit dem privaten Schlüssel beim Kompilieren vom Katalog  Tönt auf die schnelle gut. Aber ich sehe folgende Probleme: in der Doku habe ich keine Hinweise gefunden, wie z.B. im Falle dass der private Schlüssel nicht mehr sicher ist alle Daten auf einfache Art und weise neu verschlüsselt werden können. Unklar auch, wie man den privaten Schüssel regelmässig austauschen könnte. Die Daten werden auf dem Puppet-Server entschlüsselt und im Katalog unverschlüsselt gespeichert und so an den Puppet-Agent übermittelt. Der Puppet-Agent speichert den Katalog standardmässig auf dem System - inklusive den unverschlüsselten Date...

Folgende Situation: Du hast einen Daemon unter User x mit UID 13001 . Dieser muss auf einen NFSv4 Share mit aktivierter Kerberos-Authentifizierung zugreifen. Der Dienst weiss aber nichts von Kerberos. Lösung bis RHEL6: basteln Bisher hätte ich vermutlich irgendwie etwas mit Umgebungsvariabeln + Credential-Cache-Renew Cronjobs oder kstart gebastelt. Lösung ab RHEL7: gssproxy Zumindest im Fall von Zugriff auf den NFS Share lässt sich das ohne irgendwelche Änderungen am betreffenden Dienst lösen: der NFS-Client routet GSS anfragen standardmässig über gssproxy und dieser ist standardmässig dafür konfiguriert (siehe /etc/gssproxy/gssproxy.conf oder /etc/gssproxy/*.conf in neueren Fedora Versionen). cp user-x.keytab /var/lib/gssproxy/clients/ 13001 .keytab Das wars! Der User x kann jetzt auf einen NFS Share mit Kerberos-Authentifizierung zugreifen. mod_auth_kerb -> mod_auth_gssapi Auch für den Apache HTTPD gibt es ein neues Modul für die Kerberos-Authentifizierung: mod_auth...