Um eine automatische Replikation des prim\u00e4ren Kerberos KDC mit dem sekund\u00e4ren zu erzielen, m\u00fcssen auf beiden Rechner systemd service units eingerichtet werden. Zumindest unter Ubuntu 16.04 LTS sind diese in keinster Weise vorhanden, weswegen hier auf die Einrichtung eingangen wird.<\/p>\n
Service Unit auf dem sekund\u00e4ren (slave) KDC<\/strong><\/p>\n Auf dem slave KDC muss eigentlich lediglich der kpropd service als stand-alone Instanz gestartet werden. Urspr\u00fcnglich war der kpropd service auf den (x)inetd<\/em> master-daemon ausgelegt. Da dieser mittlerweile fast obsolet wurde benutzen wir den stand-alone service, der ab Version 1.11 des kpropd automatisch erkannt wird. [Service] Ein Verifikation mit dem systemd hauseigenen Tool sollte keine syntaktischen Fehler ergeben. Das Netzwerk ist „irgendwie“ schon vorhanden, aber es scheint der resolver Mechanismus (getaddrinfo) noch nicht richtig zu Arbeiten. Service Unit auf dem prim\u00e4ren (master) KDC<\/strong><\/p>\n Auf dem primary KDC muss kontinuierlich ein aktueller Dump dem secondary geschickt werden. Das erzeugen des dumps sowie der transmit Befehl sind in folgenden script (kprop.sh) verpackt: # starts the krb5kdc propagation to the secondary KDC dumpfile=\/var\/lib\/krb5kdc\/kdb_repldata kdb5_util dump $dumpfile [Timer] Um eine automatische Replikation des prim\u00e4ren Kerberos KDC mit dem sekund\u00e4ren zu erzielen, m\u00fcssen auf beiden Rechner systemd service units eingerichtet werden. Zumindest unter Ubuntu 16.04 LTS sind diese in keinster Weise vorhanden, weswegen hier auf die Einrichtung eingangen wird. Service Unit auf dem sekund\u00e4ren (slave) KDC Auf dem slave KDC muss eigentlich lediglich der … Kerberos KDC replication mit systemd units<\/span> weiterlesen<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[9,7],"tags":[],"class_list":["post-633","post","type-post","status-publish","format-standard","hentry","category-linux","category-unix"],"_links":{"self":[{"href":"https:\/\/www.instruyete.org\/index.php?rest_route=\/wp\/v2\/posts\/633","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.instruyete.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.instruyete.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.instruyete.org\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.instruyete.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=633"}],"version-history":[{"count":1,"href":"https:\/\/www.instruyete.org\/index.php?rest_route=\/wp\/v2\/posts\/633\/revisions"}],"predecessor-version":[{"id":743,"href":"https:\/\/www.instruyete.org\/index.php?rest_route=\/wp\/v2\/posts\/633\/revisions\/743"}],"wp:attachment":[{"href":"https:\/\/www.instruyete.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=633"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.instruyete.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=633"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.instruyete.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=633"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\nF\u00fcr das automatische Starten w\u00e4hrend des Boot-Vorgangs ben\u00f6tigt man mittlerweile ein systemd service unit file<\/em>, das in unserem Fall folgenderma\u00dfen aussieht.<\/p>\n
\n[Unit]
\nDescription=Krb5-KDC replication service
\nRequires=krb5-kdc.service
\nAfter=network-online.target
\nWants=network-online.target<\/code><\/p>\n<\/code><\/code><\/p>\n
\nExecStart=\/usr\/sbin\/kpropd
\nType=forking
\nReadOnlyDirectories=\/
\nReadWriteDirectories=\/var\/tmp \/tmp \/var\/lib\/krb5kdc \/var\/run \/run \/var\/log<\/p>\n
\n<\/code><\/p>\n[Install]
\nWantedBy=multi-user.target
\n<\/code><\/p>\n
\n
\nsystemd-analyze verify kpropd.service
\n<\/code>
\nAuf dem Weg zu der hier abgebildeten service unit<\/em>, gab es zwei gro\u00dfe Stolpersteine, welche syntaktisch aber einwandfrei waren, weswegen das verificiation Tool hierbei keine Hilfestellung leisten konnte.
\nDer erste war die Direktive
\nType=forking<\/code>
\nNur damit kann der systemd<\/em> erkennen, dass es ein typischer geforkter UNIX daemon ist, der nicht sofort als dead<\/em> (vom Startprozess her) markiert wird. Die Alternative w\u00e4re das Setzen des -d<\/strong> (debug) flags, der den Startprozess permanent als ein foreground<\/em> Prozess beh\u00e4lt.
\nDer zweite, noch gr\u00f6\u00dfere Stolperstein, kommt von den unterschiedlichen After<\/em>\/Wants<\/em> Direktiven. In den meisten Tutorials \u00fcber systemd wird immer auf
\nAfter=network.target<\/code>
\nverwiesen, was in diesem Fall zu einem gescheiterten Start von kpropd f\u00fchrt, beispielhaft ausgef\u00fchrt an folgendem syslog Eintrag.<\/p>\n
\nMar 18 21:57:30 aurora systemd[1]: Started Light Display Manager.
\nMar 18 21:57:30 aurora systemd[1]: Started Raise network interfaces.
\nMar 18 21:57:30 aurora systemd[1]: Reached target Network.
\nMar 18 21:57:30 aurora systemd[1]: Started Unattended Upgrades Shutdown.
\nMar 18 21:57:30 aurora systemd[1]: Started Krb5-KDC replication service.
\nMar 18 21:57:30 aurora systemd[1]: Started BIND Domain Name Server.
\nMar 18 21:57:30 aurora kpropd[1073]: ready
\nMar 18 21:57:30 aurora systemd[1]: Reached target Host and Network Name Lookups.
\nMar 18 21:57:30 aurora kpropd[1073]: getaddrinfo: Der Name oder der Dienst ist nicht bekannt
\nMar 18 21:57:30 aurora systemd[1]: Starting OpenBSD Secure Shell server...
\nMar 18 21:57:30 aurora systemd[1]: kpropd.service: Main process exited, code=exited, status=1\/FAILURE
\nMar 18 21:57:30 aurora systemd[1]: kpropd.service: Unit entered failed state.
\nMar 18 21:57:30 aurora systemd[1]: kpropd.service: Failed with result 'exit-code'.
\n<\/code><\/p>\n
\nDie L\u00f6sung h\u00e4lt dieser systemd Eintrag von freedesktop.org<\/a> bereit. Entscheidend ist die \u00c4nderung in:
\nAfter=network-online.target<\/code>
\nPikanterweise gab es unter Ubuntu aber auch hier wohl einige Zeit eine Unstimmigkeit, bzgl. des resolver Mechanismus unter diesem (passiven) Target, wie man hier<\/a> nachlesen kann.
\nErw\u00e4hnenswert ist noch, dass man den Dienst theoretisch auch ohne root-Rechte starten k\u00f6nnte, wenn man das Capability Feature von Linux nutzt. Dazu setzt man im [Service]<\/strong> Block des unit files folgende Direktive – in diesem Fall handelt es sich im das Portbinding, welches beim kpropd \u00fcbrigens auf TCP-Port 754 stattfindet.
\n
\nCapabilityBoundingSet=CAP_NET_BIND_SERVICE
\n<\/code><\/p>\n
\n
\n#!\/bin\/bash <\/code><\/p>\n<\/code><\/code><\/p>\n
\n# location of dumpfile and secondary KDC are taken from the
\n# following variables<\/p>\n<\/code><\/code><\/p>\n
\nkdcslave=aurora<\/p>\n<\/code><\/code><\/p>\n
\nif [ $? == 0 ]; then
\nkprop -f $dumpfile $kdcslave
\nfi<\/p>\n
\n<\/code><\/p>\nexit $?
\n<\/code>
\nUm diese Aktion frequentiert aufzurufen, kann man nat\u00fcrlich die globale crontab bem\u00fchen. Es geht aber auch mit kleinen Vorteilen im systemd \u00d6kosystem. Dazu braucht man allerdings dann 2 files.
\nWieder ein systemd service file (kprop.service<\/strong>)
\n
\n[Unit]
\nDescription=kprop KDC propagation <\/code><\/p>\n
\n<\/code><\/p>\n[Service]
\nType=simple
\nExecStart=\/root\/bin\/kprop.sh
\n<\/code>
\nund ein systemd timer file (kprop.timer<\/strong>)…
\n
\n[Unit]
\nDescription=Run kprop daily <\/code><\/p>\n<\/code><\/code><\/p>\n
\nOnCalendar=4:50
\nPersistent=true<\/p>\n
\n<\/code><\/p>\n[Install]
\nWantedBy=timers.target
\n<\/code>
\n..welches in unserem File t\u00e4glich um 04:50 aufgerufen wird.
\nBeide files landen in \/etc\/systemd\/system. Aber nur das timer file wird via
\nsudo systemctl enable kprop.timer<\/code>
\naktiviert.
\nVorteil dieser L\u00f6sung ist, dass man einerseits mit systemctl auch manuell die Synchronisation ansto\u00dfen kann, aber auch schnell eine \u00fcbersichtliche Darstellung der Logeintr\u00e4ge bekommt, welches man mit
\njournalctl -u kprop<\/code>
\nauf dem primary KDC, bzw.
\njournalctl -u kpropd<\/code>
\nauf dem secondary KDC abfr\u00e4gt.<\/p>\n","protected":false},"excerpt":{"rendered":"