Seite wählen

NETWAYS Blog

Wie kann ich einen Teil meiner Arbeit loswerden? – Oder: LConf und ACL

Da ich persönlich eher zu den faulen Menschen gehöre und sich bestimmt jeder Admin auch dazu zählen kann, will ich in diesem Blogpost darauf eingehen wie man zumindest die Aufgabe Monitoring ein wenig auf fleißige Kollegen oder auch Azubis und Praktikanten verschieben kann. Natürlich möchte man sich im Nachhinein nicht mehr Arbeit gemacht haben, indem man Fehlersuche betreiben muss, daher ist mein Ansatz: graphische Administration und eingeschränkte Berechtigungen.
Unser Werkzeug für graphische Administration LConf dürfte mittlerweile wohl bekannt sein. Wem dieses gar nichts sagt kann sich ja mal das Webinar anschauen. Kurz zusammengefasst verwendet LConf ein LDAP-Backend, bietet Vererbung und Templates sowie ein hübsches Frontend.
Gebe ich nun dem Azubi eine kurze Einweisung und volle administrative Rechte, sehe ich mich schon statt beim Feierabend-Bier beim Restore und anschließendem „Hätte ich’s bloß gleich selbst gemacht“ und „Wenn etwas richtig gemacht werden soll, muss man es selber machen“. Und damit sich niemand diskriminiert fühlt, gilt das gleiche natürlich für alle anderen Kollegen wie Windows- oder Netzwerk-Admins. 😉
Diese Grundhaltung höre ich doch des öfteren bei Kunden und Schulungsteilnehmern, daher müssen also eingeschränkte Rechte her und dies ermöglicht LDAP zum Glück leicht mittels ACL. Voraussetzung hierfür ist ein Benutzer oder eine Gruppe innerhalb des LDAP. Da der LConf-Connection-Manager mir erlaubt eine Verbindung zu erstellen und dann einer Gruppe Zugriff auf diese zu erlauben, reicht mir ein Benutzer.
Diesen lege ich mir folgendermaßen an:

  1. Passwort-Hash generieren:
    # slappasswd
    New password: awesome
    Re-enter new password: awesome
    {SSHA}ZOmXcrADeKGkthMlJ3PZwKbyM8bnbP5t
  2. Datei user.ldif für den Import bauen:
    dn: cn=myuser,ou=users,dc=icinga,dc=lab
    objectClass: organizationalPerson
    cn: myuser
    sn: User
    description: My User
    userPassword: {SSHA}ZOmXcrADeKGkthMlJ3PZwKbyM8bnbP5t
  3. Benutzer mit administrativem Account einspielen:
    ldapadd -x -h localhost -D cn=admin,dc=icinga,dc=lab -W -f user.ldif

Nun muss ich mir überlegen wie meine Grundstruktur aussieht und worauf ich meinen Benutzer berechtigen will. Mein Ansatz ist hierbei dem Kollegen auf einen Teilbaum gemäß seiner Zuständigkeit schreibend zu berechtigen und Templates sowie grundlegende Objekte lesend zur Verfügung zu stellen. Hierfür müssen die Standard-Zugriffsregeln teilweise gelöscht werden bevor die neuen gesetzt werden, da diese in der gespeicherten Reihenfolge abgearbeitet werden.
Die Vorgehensweise ist hierbei:

  1. Datei access.xml für Import bauen:
    changetype: modify
    dn: olcDatabase={1}hdb,cn=config
    delete: olcAccess
    olcAccess: to dn.base="" by * read
    -
    delete: olcAccess
    olcAccess: to * by self write by dn="cn=admin,dc=icinga,dc=lab" write by * read
    -
    add: olcAccess
    olcAccess: to dn.base="dc=icinga,dc=lab" by users read
    -
    add: olcAccess
    olcAccess: to dn.base="ou=LConf,dc=icinga,dc=lab" by users read
    -
    add: olcAccess
    olcAccess: to dn.base="ou=IcingaConfig,ou=LConf,dc=icinga,dc=lab" by users read
    -
    add: olcAccess
    olcAccess: to dn.subtree="ou=global,ou=IcingaConfig,ou=LConf,dc=icinga,dc=lab" by users read
    -
    add: olcAccess
    olcAccess: to dn.subtree="ou=Templates,ou=LConf,dc=icinga,dc=lab" by users read
    -
    add: olcAccess
    olcAccess: to dn.subtree="ou=myconfig,ou=IcingaConfig,ou=LConf,dc=icinga,dc=lab" by dn="cn=myuser,ou=users,dc=icinga,dc=lab" write
    -
    add: olcAccess
    olcAccess: to * by self write by dn="cn=admin,dc=icinga,dc=lab" write
  2. Importieren unter Nutzung der ldapi-Schnittstelle:
    ldapmodify -Y EXTERNAL -H ldapi:/// -f access.ldif

Nun noch in dem Wissen, dass die Kollegen nicht so leicht was kaputt machen können, die Verbindung im LConf-Frontend angelegt, die Kollegen berechtigt und eine Einweisung im Wiki hinterlegt. Danach heißt es dann heim zum Feierabend-Bier während die fleißigen Kollegen mit den neuen Rechten Hosts und Services ins Monitoring aufnehmen! 😉
In diesem Sinne viel Erfolg beim Verteilen der Arbeit und natürlich Prost!

Dirk Götz
Dirk Götz
Principal Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

Aufzeichnung des LConf-Webinars ist online!

lconf_logo
Die Aufzeichnung unseres gestern geführten Webinars steht ab sofort zum Ansehen auf YouTube bereit. Vielen Dank nochmal an alle Teilnehmer für die Aufmerksamkeit. Im Webinar wurden folgende Punkte durchgesprochen:

  • Kurzvorstellung NETWAYS
  • Einführung LDAP
  • Vorteile/Funktionen LConf mit LDAP

natürlich wurde dann noch ausführlich eine Live-Demo gezeigt.

 
Nicht vergessen: Nächste Woche führen wir ein Webinar zum Thema Puppet. Ein Blick in unser Webinar-Archiv lohnt sich, dort gibt es auch die Präsentationsfolien zum Download!

NETWAYS Webinar für das Nagios/Icinga Konfigurationstool LConf

lconf_logo
Neben dem Bearbeiten von Nagios/Icinga Konfigurationsdateien über die Command-Line, gibt es noch Web-basierte Lösungen, welche die Konfiguration deutlich vereinfachen.
 
Eines dieser Tools ist der LConf. Ein aus dem Audi Projekt entstandenes Tool, welches die Nagios-Konfiguration über eine LDAP Struktur abbildet und an Nagios/Icinga zurück exportieren kann.
In diesem Webinar, werden wir näher auf die Möglichkeiten, die Vererbungslogik sowie den daraus resultierenden Vorteil eingehen.
Die Registrierung erfolgt wie immer über unser Webinar Center. Das Webinar startet am Mittwoch 09. Oktober um 14 Uhr.
Wir freuen uns auf eine rege Teilnahme!
Übrigens: nächste Woche Donnerstag (17.10.2013) halten wir ein Webinar über Puppet.

Weekly Snap: MCollective, CCache & Apache Tips

weekly snap15 – 19 July offered tips for Puppet users, developers and sys admins alike, as well as news from the event circuit.
Starting with events, Eva counted 99 days to the OSMC 2013 with Rihards Olups’ presentation on Zabbix 2.0 while Lennart reported from DevOps Days Down Under in Australia.
Thomas then recommended Puppet users to try the MCollective orchestration framework as Gunnar upped the speed on his builds with ccache.
Lastly, Dirk offered a handy tip for large environments by showing how to integrate multiple LDAP servers in Apache authentication.

Apache und viele, viele User

Kollege Lennart hat zwar schon dankenswerterweise einiges zu Apache, Openldap und Active Directory geschrieben trotzdem ist dieses Thema noch nicht völlig erschöpft. Ich möchte diesmal die Anleitung liefern wie man mehrere verschiedene LDAP-Server bei der Apache-Authentifizierung nutzt. Auch nutzbar ist diese Lösung um mehrere Einstiegspunkte in den gleichen Verzeichnisbaum zu bekommen.
Die einen fragen sich nun wo soll da bitte die Schwierigkeit sein, die anderen wozu sollte man so etwas brauchen. Die Schwierigkeit hierbei stellt der LDAP-Provider dar, der nur eine LdapAuthURL akzeptiert. Der Grund dafür mehrere zu brauchen können mehrere Verzeichnisdienste für verschiedene Anwendergruppen sein oder auch ein Struktur im Active Directory, bei der sonst neue Gruppen gebildet und gepflegt werden müssten oder ein Verschieben der Benutzer innerhalb des Baums aus organisatorischen oder gar technischen Gründen nicht möglich ist.
Die Lösung hierfür heißt mod_authn_alias (oder ab 2.4 mod_authn_core). Mit diesem Modul lässt sich ein Alias für einen Authentfizierungs-Provider erstellen, so dass es möglich wird diesen mehrfach zu verwenden. Die Konfiguration könnte dann folgendermaßen aussiehen:

<AuthnProviderAlias ldap admins>
   AuthLDAPBindDN "CN=serviceaccount,DC=netways,DC=de"
   AuthLDAPBindPassword strenggeheim
   AuthLDAPURL "ldap://server1.netways.de server2.netways.de/OU=admins,DC=netways,DC=de?samaccountname"
</AuthnProviderAlias>
<AuthnProviderAlias ldap entwickler>
   AuthLDAPBindDN "CN=serviceaccount,DC=netways,DC=de"
   AuthLDAPBindPassword strenggeheim
   AuthLDAPURL "ldap://server1.netways.de server2.netways.de/OU=entwickler,DC=netways,DC=de?samaccountname"
</AuthnProviderAlias> 

Diese Konfiguration muss einmalig und vor der Verwendung eingebunden werden. Daher bietet sich ein Dateiname wie 00provider.conf an mit dem die Konfiguration im Apache-Konfigurationsverzeichnis abgelegt wird.
Für die Verwendung bietet es sich dann eine Datei auth.inc anzulegen, die dann in den einzelnen Konfigurationsdateien für die Webanwendungen mit include eingebunden werden kann. Diese sieht dann beispielsweise so aus:

AuthName "Icinga Access"
AuthType Basic
AuthBasicProvider admins entwickler
Require valid-user

Wer zusätzlich noch einen Fallback für einen anderen Provider benötigt kann diesen einfach hinzufügen und je nach Apache-Version einen Blick auf AuthzLDAPAuthoritative (2.2) oder RequireAny (2.4) werfen.

Dirk Götz
Dirk Götz
Principal Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.