Linux Notizen

oscap-docker will nur RHEL container prüfen. Mit oscap-chroot kann man aber eine beliebige Chroot-Umgebung prüfen. Mit  dem atomic mount Befehl kann ich einfach einen Container oder ein Image mounten. Die OVAL Files von RHEL passen eigentlich auf CentOS - bedürfen aber einer kleinen Modifikation: RPM GPG Signing Key ist ein anderer Release Package ist centos-release und die Version von centos-release ist einfach 7 und nicht 7.x Howto dnf install openscap-utils atomic curl curl --silent https://www.redhat.com/security/data/oval/com.redhat.rhsa-RHEL7.xml.bz2 | \   bunzip2 - | \   sed 's/redhat-release-server/centos-release/g;s/199e2f91fd431d51/24c6a8a7f4a80eb5/g;s/7\[\^\\d\]/7\$/g' \   >/tmp/com.redhat.rhsa-CENTOS7.xml   atomic mount $centos-7-image-oder-container-id /mnt   oscap-chroot /mnt oval eval --report /tmp/report.html --results /tmp/results.xml /tmp/com.redhat.rhsa-CENTOS7.xml

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...

Die Java Links in /usr/bin sind alles Symlinks verwaltet vom alternatives Tool. Auch das Oracle Java RPM klinkt sich da ein. Nun kann es passieren, dass z.B. OpenJDK 1.8 der Standard sein soll, aber ein anderes Tool evt. OpenJDK 1.9 braucht. Diese neuere Version würde dann automatisch zum Standard. Auf RHEL/CentOS kann ich das mit dem --family Feature auf OpenJDK 1.8 fixieren: alternatives --set java java-1.8.0-openjdk.x86_64 Eigentlich lauten die Parameter der --set Aktion: alternatives  --set $name $path Anstatt $path kann aber auch der Wert vom --family Parameter von der --install Aktion verwendet werden. Auszug aus der alternatives Manpage zur --install Aktion : --family can be used to group similar alternatives. If the group is in manual mode and the alternative currently used is removed, alternatives will try to change links to different one with same family and highest priority. NOTE: --family is a Red Hat Linux specific option.   ...

Ein Reminder was alles gemacht werden muss damit das puppetlabs/postgresql PostgreSQL 9.5 aus dem Software-Collections Channel installiert. Ob default_connect_settings der richtige Ort für LD_LIBRARY_PATH ist, weiss ich nicht. Es hat aber auch nichts passenderes gehabt. Zusätzlich musste noch manifests/server/service.pp erweitert werden: validate_db_connection muss den Parameter c onnect_settings => $::postgresql::globals::default_connect_settings bekommen. class { '::postgresql::globals': version => '9.5', bindir => '/opt/rh/rh-postgresql95/root/usr/bin', service_name => 'rh-postgresql95-postgresql', server_package_name => 'rh-postgresql95-postgresql-server', client_package_name => 'rh-postgresql95-postgresql', contrib_package_name => 'rh-postgresql95-postgresql-contrib', devel_package_name => 'rh-postgresql95-postgresql-devel', docs_package_name => 'rh-postgresql95-...

Beim Versuch festzustellen, wieso Method = static, nsswitch in /etc/idmapd.conf nicht funkioniert. Als erstes mal nfs4_disable_idmapping Parameter auf N gesetzt (defaults: EL7: Y, EL6: N, EL5: nicht verfügbar), damit das idmapping tatsächlich stattfindet. Danach zeigen die Dateien obwohl die User auf Client und Server unterschiedliche UID+GID haben korrekte Werte an. Irgendwann bin ich darauf gestossen: ... static: This method works only for translating GSS authenticated names to local names ... (/usr/share/doc/libnfsidmap-0.25/README) Ok, geht also nicht mit sec=sys sondern nur mit sec=krb5 und Co. Der Hinweis hätte gerne schon in den idmapd.conf Kommentaren stehen dürfen. Was dann aber schon sehr verwunderlich war, dass obwohl ls -l anzeigt, dass ich Zugriff habe, dann der Zugriff nicht so funktioniert hat. Der Ubuntu Bug nfs4+idmap does not map uids correctly when using AUTH_SYS beschreibt wahrscheinlich das Problem. Angezeigt wird es wie erwartet: Server schick...

Du versuchst ein SELinux Modul zu laden, aber das schlägt fehl. Mit ungefähr so einer Meldung: semodule -i meinmodul.pp Failed to resolve typeattributeset statement at /etc/selinux/targeted/tmp/modules/400/meinmodul/cil:42 semodule: Failed! Du versuchst dann diese Zeile 42 anzuschauen. Die Datei /etc/selinux/targeted/tmp/modules/400/meinmodul/cil existiert aber nicht mehr. Wie kann man also diese *.pp Datei ins CIL umwandeln? Die Doku ist spärlich! Der Befehl auf EL7 lautet: /usr/libexec/selinux/hll/pp meinmodul.pp Der produziert den CIL Text aus dem Modul. Danke Sven Vermeulen für den aufschlussreichen Blog-Post! Links Where does CIL play in the SELinux system?