Die Extrawurst

Icinga Web 2 bietet eine Reihe von Möglichkeiten, Gruppen-Mitgliedschaften zuzuweisen. Am häufigsten werden Gruppenmitgliedschaften entweder via Web angelegt oder aus einem LDAP-Verzeichnis gezogen. Der bekannteste Vertreter dabei ist Microsofts Active Directory.

Weniger bekannt ist, dass man in eigenen Modulen Benutzer- sowie Gruppenmitgliedschafts-Backends bereitstellen kann. Manchmal braucht man aber gar nicht ein volles Backend, sondern nur ein paar kleine Korrekturen. Aus einem solchen Grund entstand diese Woche in einem Kundenprojekt ein neues Icinga Web 2 Modul: Extragroups.

Zusätzliche Gruppen für jeden

Einmal installiert, lassen sich in der config.ini des Moduls flexible Regeln definieren.

[Jeder ist ein Mimimi]
add_groups = "Mimimi"

Das allein hat erst mal keinen Effekt, also hinterlegen wir in der /etc/icingaweb2/roles.ini eine Rolle, welche unseren Usern eine entsprechende Einschränkung verpasst:

[Mimimi Demo]
groups = "Mimimi"
monitoring/filter/objects = "host_name=*mi*"

Sobald wir uns neu anmelden sind wir Mitglied der Gruppe “Mimimi” und sehen nur noch Hosts welche “mi” enthalten. Dabei ist nebensächlich, ob eine Benutzergruppe namens “Mimimi” existiert oder nicht.

Mustervergleich mit Benutzernamen

Lasst uns das Ganze ein wenig einschränken:

[Alle Heuler sollen Mimimis werden]
user_filter = "username=*heul*"
add_groups = "Mimimi"

Was hier passiert dürfte klar sein, wir machen nur noch unsere Heuler zu Mimimis.

Regeln basierend auf Umgebungsvariablen

Ihr möchtet alle Benutzer mit ein paar Ausnahmen in eine spezielle Gruppe geben, aber nur wenn diese remote arbeiten? Erstellt einfache eine auf deren IP-Range basierende Regel:

[Einschränkung wenn via VPN verbunden]
env_filter = "REMOTE_ADDR=192.0.2.*"
user_filter = "username!=tom&username!=admin"
add_groups = "Via VPN verbunden"

Ähnlich wie REMOTE_ADDR in diesem Beispiel können alle vom Web-Server bereitgestellten Umgebungsvariablen benutzt werden. Im nächsten Beispiel zeigen wir Netzwerk-Admins welche via Nagstamon angemeldet sind lediglich wirklich wichtige Hosts und Services:

[Filter für Nagstamon]
env_filter = "HTTP_USER_AGENT=Nagstamon*"
user_filter = "group=Network Admin"
add_groups = "VIP objects filter"

VORSICHT: Der User-Agent kann einfachst gefälscht werden. Dieses Beispiel dient dem Komfort unserer Benutzer: sie wollen in Nagstamon nicht mit allen Problemen belästigt werden. Für sicherheitskritische Regeln taugt der User-Agent nicht.

Mehrere Gruppen zuweisen

Manchmal will man mehrere Gruppen auf einmal zuweisen, ohne die ganze Regel zu klonen. Das lässt sich einfach bewerkstelligen, denn add_groups akzeptiert eine Komma-getrennte Liste:

[VPN-Benutzer einschränken]
; ..
add_groups = "Eingeschränkte Benutzer, Spezielle Dashboards, Business-Prozesse"

Soll die Gruppenliste noch dynamischer sein? Vorausgesetzt dass ein Webserver-Modul oder dessen Konfiguration diese Information bereitstellt, lässt sich jede Umgebungsvariable via {VARIABLE_NAME} nutzen:

[Gruppen des SSO-Moduls zuweisen]
add_groups = "{HTTP_AUTHZ_GROUPS}"

Auch in Strings die aus Umgebungsvariablen kommen funktioniert das Komma (,) als Trennzeichen. Und man kann natürlich Variablen-Platzhalter mit statischen Werten kombinieren:

[Eine Reihe von Gruppen]
add_groups = "Spezial-Gruppe, {REMOTE_GROUPS}, {HTTP_AUTHZ_GROUPS}"

Auf Gruppenmitgliedschaften basierende Regeln

Der user_filter erlaubt auch Regeln basierend auf bereits zugewiesene Gruppen. In unserem umfangreicheren letzten Beispiel erhalten alle Benutzer zusätzliche Gruppenmitgliedschaften via HTTP_AUTHZ_GROUPS. Na gut, jeder außer der guest und der admin-Benutzer.

Wenn sie Nagstamon nutzen während sie via VPN verbunden sind, sollen sie zusätzlich in die Gruppe Nagstamon Remote kommen.

Wird Nagstamon ohne VPN benutzt, sollen Mitglieder der Gruppen “Linux Benutzer” und/oder “Unix Benutzer” in die Gruppe “Nagstamon Lokal” kommen. Alle außer dem admin:

[Gruppen des SSO-Moduls zuweisen]
add_groups = "{HTTP_AUTHZ_GROUPS}"
user_filter = "user_name!=guest&username!=admin"

[Nagstamon via VPN]
env_filter = "REMOTE_ADDR=192.0.2.*&HTTP_USER_AGENT=Nagstamon*"
add_groups = "Nagstamon Remote"

[Nagstamon ohne VPN]
env_filter = "REMOTE_ADDR!=192.0.2.*&HTTP_USER_AGENT=Nagstamon*"
user_filter = "username!=admin&(group=Linux Benutzer|group=Unix Benutzer)"
add_groups = "Nagstamon Local"

Dabei gilt es zu beachten, dass der Filter basierend auf die group-Eigenschaft nur Gruppen sieht, welche von vorhergehenden Regeln zugewiesen wurden. Von anderen Backends bereitgestellte Gruppenmitgliedschaften sind nicht zugänglich.

Das war’s auch schon, viel Spaß!

Thomas Gelf

Autor: Thomas Gelf

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.

Change Your AD Password easily via OWA

In many environments, Microsoft Active Directory is used to manage users, their roles and permissions and of course their passwords.

When you have set up an  Exchange Server as well, you may want to provide your users with the Outlook Web App. Here also users without Microsoft Windows are able to tune their mail settings and their Active Directory passwords, too.

Sometimes the method may not be completely clear, so please feel free to use this following guide whenever you need to.

Disclaimer: The screenshots display a German OWA and my GIMP skills are, well, improvable.

First you need to login. Please don’t forget to add your domain name.

Then find the small gear and click it.

Use the drop down and navigate to “change password”

You’ll now be prompted to enter your old (1) and your new password twice (2,3). Hit “Save”(4) for using your new password and you’re done!

Tim Albert

Autor: Tim Albert

Tim kommt aus einem kleinen Ort zwischen Nürnberg und Ansbach, an der malerischen B14 gelegen. Er hat in Erlangen Lehramt und in Koblenz Informationsmanagement studiert, wobei seine Tätigkeit als Werkstudent bei IDS Scheer seinen Schwenk von Lehramt zur IT erheblich beeinflusst hat. Neben dem Studium hat Tim sich außerdem noch bei einer Werkskundendienstfirma im User-Support verdingt. Blerim und Sebastian haben ihn Anfang 2016 zu uns ins Managed Services Team geholt, wo er sich nun insbesondere um Infrastrukturthemen kümmert. In seiner Freizeit engagiert sich Tim in der Freiwilligen Feuerwehr - als Maschinist und Atemschutzgeräteträger -, spielt im Laientheater Bauernschwänke und ist auch handwerklich ein absolutes Allroundtalent. Angefangen von Mauern hochziehen bis hin zur KNX-Verkabelung ist er jederzeit einsatzbereit. Ansonsten kocht er sehr gerne – alles außer Hase!

Be a speaker at the OS Monitoring Conference this year!

 

We have some strong points for you to be a speaker at the Open Source Monitoring Conference 2018.

  1. Add new research to your list – Talk about your newest findings in development at the OSMC.
  2. Increase your productivity –  Writing a paper with your findings, tips, tricks and skills increases your number of activities.
  3. Be the OS Monitoring Agent of Change! – Do you think your ideas and thoughts can bring positive change to the OS community? If you do, the Open Source Monitoring Conference is the perfect platform for you to share your ideas with the community.
  4. Monitor your social life – Meet up with fellow experts and enjoy the opportunity to exchange and reflect with other OS monitoring enthusiasts.

Let’s do this! Submit your talk here. 

Keya Kher

Autor: Keya Kher

Keya hat im Oktober ihr Praktikum im Marketing bei NETWAYS gestartet. Letzten Dezember startete Sie gemeinsam mit Ihrem Mann das “Abenteuer Deutschland”. Seitdem lernt Sie fleißig deutsch und fühlt sich bei NETWAYS schon jetzt pudelwohl. Sie hat schon viele Erfahrungen im Social Media Marketing und ist gerade dabei auch im Grafikdesign ein Profi zu werden. Wenn sie nicht gerade dabei ist, sich kreativ auszuleben, entdeckt sie die Stadt und schmökert gerne im ein oder anderen Büchlein. Ihr Favorit ist hierbei “The Shiva Trilogy”.

OSDC 2018 Countdown – 6 weeks until Berlin

OSDC Countdown 2018 : Taming the Modern Data Center by Seth Vargo

 

OSDC 2018 | Simplifying complex IT infrastructures with Open Source | June 12-13 Berlin

In 2017, Seth Vargo went through all the questions around the modern data center. Should our machines be virtual or physical? Should we use containers or Docker? Is a public or a private cloud provider better? Which configuration management tool is best to use? What about IaaS, PaaS, and SaaS?

Join us in Berlin and take part in 10th internationally recognized Open Source Datacenter Conference 2018. Where you will experience experts report on the latest development trend in Datacenter solutions and best practices with pro administrators and architects.

It is best time to know-how and add-on into your knowledge with world-wide Open Source Community members.

For more information and to register visit osdc.de

See you in Berlin!

Keya Kher

Autor: Keya Kher

Keya hat im Oktober ihr Praktikum im Marketing bei NETWAYS gestartet. Letzten Dezember startete Sie gemeinsam mit Ihrem Mann das “Abenteuer Deutschland”. Seitdem lernt Sie fleißig deutsch und fühlt sich bei NETWAYS schon jetzt pudelwohl. Sie hat schon viele Erfahrungen im Social Media Marketing und ist gerade dabei auch im Grafikdesign ein Profi zu werden. Wenn sie nicht gerade dabei ist, sich kreativ auszuleben, entdeckt sie die Stadt und schmökert gerne im ein oder anderen Büchlein. Ihr Favorit ist hierbei “The Shiva Trilogy”.

Rundum updaten mit Ansible

Nachdem wir ja nun auch alle möglichen Dienstleistungen rund um Ansible anbieten, dachte ich mir, es kann nicht schaden, es mir auch mal zu Gemüte zu führen. Kurzum: Ich bin bisher begeistert davon, wie einfach man damit auch komplexe Aufgaben lösen kann und werde sicherlich mein Wissen in dieser Richtung noch vertiefen.

Meine ersten Gehversuche haben mir dann auch gleich geholfen, ein Problem zu lösen, das mich schon länger geplagt hat. IT’ler neigen ja dazu, auch selber eine umfangereiche Infrastruktur zu betreiben und dabei wird der Aufwand üblicherweise mit der Zeit nicht weniger. Ich habe durchaus einige ähnliche Systeme im Einsatz und kann getrost sagen, wenn ich bei ein paar repräsentativen Systemen geprüft habe, ob ich anstehende Updates sofort einspielen oder lieber warten sollte, kann ich sie für die restlichen Rechner auch gleich machen. Aber wie, ohne ständig von System zu System hüpfen zu müssen. Es gibt dafür natürlich Lösungen, aber die meisten, die ich gefunden habe, brauchen einfach deutlich zu viele Ressourcen und rentieren sich auch für meine mittlere zweistellige Anzahl an Rechnern nicht.

Also habe ich versucht, das Problem mit Ansible zu erschlagen und war auch in erstaunlich kurzer Zeit fertig. Inzwischen weiss ich, dass meine Lösung nicht sonderlich elegant ist und man noch einiges daran verbessern kann, aber ich denke, sie ist eingängig und deshalb möchte ich sie hier vorstellen.

Zuerst lege ich mir die Datei ~/ansible/hosts an, in der sämtliche Hosts namentlich aufgelistet werden. Ich habe sie anonymisiert und stark gekürzt, um den Blogartikel nicht unnötig in die Länge zu ziehen. z.B. ist hier nur ein NAT mit Hosts dargestellt, in meiner “echten” Liste sind es mehr, was “händische” Updates nicht einfacher macht.

[centos:children]
centos6
centos7

[debian:children]
debian-jessie
raspbian-stretch
debian-stretch

[centos6]
odin.example.com
kvasir.example.com

[centos7]
balder.example.com
heimdall.example.com
tyr.example.com

[raspbian-stretch]
rerun.asgard.example.com

[debian-jessie]
gullveig.example.com
[debian-stretch]
freyr.example.com

[solaris11]
surtur.asgard.example.com
[special-centos]
loki.asgard.example.com

[asgard]
loki.asgard.example.com
rerun.asgard.example.com
surtur.asgard.example.com

Zuerst werden hier Gruppen definiert, die andere Gruppen zusammenfassen. So sind die Gruppen centos6 und centos7 Teil von centos und alle Hosts in den Untergruppen auch gleichzeitig Mitglied in den Übergruppen. Bei genauem Hinsehen erkennt man auch, dass loki.asgard.example.com Mitglied in zwei Gruppen ist, was durchaus so beabsichtigt ist.

Das folgende Playbook ( ~/ansible/playbooks/update-all.yml ) kann nun (fast) alle Systeme auf einen Schlag aktualisieren. Wenn mir also mein Icinga 2 meldet, dass Updates anstehen, suche ich mir einen repräsentativen Host jeder Gruppe aus und prüfe, welche Updates anstehen. Denke ich, dass ich sie gefahrlos einspielen kann, starte ich das folgende Playbook.

---
- hosts: centos*:!special-centos
  remote_user: alice
  become: yes
  tasks: 
    - name: update everything
      yum:
        name: "*"
        state: latest
        exclude: "owncloud*"
- hosts: special-centos
  remote_user: alice
  become: yes
  tasks: 
    - name: update everything
      yum:
        name: "*"
        state: latest
        skip_broken: yes
- hosts: debian*:raspbian*
  remote_user : alice
  become: yes
  tasks:
    - name: install dmidecode
      apt:
        name: dmidecode
        update_cache: yes
    - name: update package cache
      apt:
        update_cache: yes
    - name: upgrade packages
      apt:
        upgrade: dist
        force: yes
    - name: autoremove dependencies
      apt:
        autoremove: yes

Das erste Play verbindet sich zu allen centos Hosts, die nicht Teil der Gruppe centos-special sind und führt das Modul yum aus, das mit der Option latest alle Pakete aktualisiert. Explizit ausgeklammert ist dabei owncloud, da hier immer Nacharbeiten nötig sind. Dabei nutzt Ansible den User alice, für den ein SSH Key hinterlegt ist und wird per sudo zu root. Das muss natürlich vorher erlaubt werden, wobei Ansible auch ermöglicht, für sudo Passwörter mitzugeben. Ist dieses Play durchgelaufen, sind alle CentOS Maschinen, ausser loki aktualisiert. Dabei handelt es sich um eine “gewachsene Speziallösung” auf der diverse Pakete aus Drittrepositories installiert sind, die inzwischen in defekten Abhängigkeiten festhängen. Hier wird das yum Modul also mit der skip_broken Option aufgerufen, das diese verbogenen Pakete ausklammert.

Das Paket deltarpm um Gebrauch von deltarpms zu machen, habe ich über ein anderes Playbook installiert, könnte man aber prinzipiell auch noch hier vor den ersten Plays aufnehmen.

Nach den CentOS Hosts kommen die Debian Maschinen an die Reihe. Hier wird erst dmidecode installiert, das für den reibungslosen Ablauf nötig ist und z.B. bei raspbian nicht gleich installiert war. Ist das Paket bereits installiert, überspringt Ansible diesen Schritt nach einer Prüfung. Die Tasks für Debian haben alle das Update des package cache deaktiviert, was den Ablauf sehr beschleunigt. Der erste Task führt dieses Update durch und das reicht für alle weiteren. Zum Schluss werden noch nicht mehr benötigte Dependencies entfernt.

Damit Ansible sich auch in das NAT “asgard” verbinden kann, habe ich entsprechende Optionen in ~/ansible/hosts/group_vars/asgard hinterlegt.

ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q asgard.example.com" -o ConnectTimeout=800s'
ntp_server: 192.168.74.19

Damit wird festgelegt, dass ansible sich zu allen diesen Hosts über einen Jumphost verbinden muss. Dabei gibt der Name der Datei an, für welche Gruppe von Hosts die darin enthaltenen Optionen gelten. Die Adresse des NTP Servers hat keinen Einfluss auf dieses Playbook, soll aber zeigen, dass man hier auch einfach andere Variablen setzen kann.

Der Solaris Host bleibt hier aussen vor, da es dafür noch kein fertiges Modul für Updates gibt. Hier greife ich ggf. noch händisch ein.

Inzwischen weiss ich, dass man die verwendeten Module auch einfach abhängig vom Fact des Betriebssystems machen kann und noch den einen oder anderen Kniff. Aber in der aktuellen Version ist das Playbook wohl besser verständlich.

Wer mehr über Ansible wissen will, sollte unbedingt mal in einer unserer Schulungen vorbeischauen.

Thomas Widhalm

Autor: Thomas Widhalm

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem Netways Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei Netways und hält Schulungen und erstellt Schulungsunterlagen zu diesem faszinierenden Tool. Seit 2017 stellt er sich neuen Herausforderungen als Lead Support Engineer und versucht sein Wissen aus den vorgenannten Tätigkeiten im Produktsupport umzusetzen.