Select Page

NETWAYS Blog

Icinga Web 2 Modul fileshipper imports im Director

by | Jul 21, 2017 |

Es werden viele Importe im Icinga Web 2 Modul Director via Ldap / SQL-Ressource getätigt, aber viele übesehen eine einfache Möglichkeit bestehende Dateien mittels Icinga 2 Modul “fileshipper” in den Icinga Web 2 Director zu importieren. Wie man dieses umsetzt werde ich an einem einfachen Beispiel, einer CSV-Datei hier beschreiben.
Zuerst muss man sich das Fileshipper-Modul von Github per “git clone” oder .zip-Datei herunterladen und in dem Verzeichnis '/usr/share/icingaweb2/modules/' ablegen und anschießend das Verzeichnis in “fileshipper” umbennen, denn sonst erkennt es Icinga Web 2 als Modul nicht an.
# cd /usr/share/icingaweb2/modules/ && git clone https://github.com/Icinga/icingaweb2-module-fileshipper.git
oder
# cd /usr/share/icingaweb2/modules/ && unzip master.zip
Anschließend muss das neu installierte Modul noch aktiviert werden,  mit dem icingacli Kommando:
# icingacli module enable fileshipper
icingacli module list
MODULE VERSION STATE DESCRIPTION
director 1.3.1 enabled Director - Config tool for Icinga 2
doc 2.4.1 enabled Documentation module
fileshipper 1.0.0 enabled Fileshipper for Icinga Director
monitoring 2.4.1 enabled Icinga monitoring module
Es geht aber aber auch über die Icinga Web 2 –  Oberfläche siehe Screenshot:

Nachdem das Modul installiert und aktiviert ist kann es losgehen. Zuerst erstellt man das Verzeichnis “fileshipper” unter # mkdir /etc/icingaweb2/modules/fileshipper und erstellt eine import.ini Datei in der das Verzeichnis angeben wird, wo sich die zu importierenden Dateien (.csv) liegen.
[fileshipper files]
basedir = "/usr/local/share/"
Dann wird im Icinga Web 2 => Director => Automation => Add Import Source

ein Name des zukünftigen Imports z.B fileshipper-import-hosts vergeben und bei Source “Import from files (fileshipper) ausgewählt.
Jetzt muss die neue Import-Quelle noch modifiziert werden z.B. so:

Ich denke das Bild ist selbsterklärend und Bedarf keiner weiteren Erklärung.
Jetzt kann man einen Import run starten in dem man auf die Import-Source fileshipper-import-hosts und Trigger Import Run auswählt.
Nun sollte in der Voransicht (Preview) die importierten Hosts sichtbar werden.

Um jetzt aus diesen RAW-Daten Icinga 2 konforme Objekte werden zu lassen brauchen wir eine Sync-Rule die man z.B.so anlegt:

Hier wird in der Maske angeben, welcher Typ (Host-Objekt) daraus werden soll und ob bereits existierende Daten ersetzt (replace) oder zusammengeführt (merge) werden sollen.
Mit Purge können bereits existierende Daten gelöscht werde, JA oder NEIN.
Im Kartei-Reiter “Properties/Eigenschaften” werden die Felder vom Import (Source/Quelle) den Icinga 2 konformen Zielen (Destination) zugeordnet:

Danach kann der Sync-Run der erstellten Sync-Rule gestartet werden und bei erfolgreichen Lauf, werden Konfigurations-Dateien erstellt und sind bereit für den Director zu deployen.

Im Activity-Log kann der Vorgang nochmals überprüft werden, bevor man die Konfiguration per Director deploy übernehmen kann.
So jetzt sollten nach erfolgreichem Deployment die Hosts im Icinga Web 2 unter Hosts sichtbar sein.
 
Im Rahmen einer Icinga 2 Fundamentals Schulung, die wir anbieten, werden auch noch weitere Import-Quellen besprochen und praktisch vollzogen.
Unter anderem haben wir noch weitere Schulungen zu Open Source Themen im Portofolio, einen Überblick bekommen Sie hier bei NETWAYS-Schulungen.

Johannes Carraro
Johannes Carraro
Senior Systems Engineer
Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Team Operations als Senior Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren.
Read more from Johannes and meet the Team

PNP4Nagios RRD Single/Multiple Storage

by | Sep 21, 2016 | , , ,

pnp4nagiosFür alle die das Nagios Plugin PNP4Nagios mit Icinga2 einsetzen, werden eventuell schon über folgende Fehlermeldung gestolpert sein,
oder noch stolpern:

/var/log/messages:
NPCD[65119]: ERROR: Executed command exits with return code '7'
/var/log/pnp4nagios/perfdata.log:
2016-09-15 13:53:55 [19510] [0] *** TIMEOUT: Timeout after 15 secs. ***
2016-09-15 13:53:55 [19510] [0] *** TIMEOUT: Deleting current file to avoid NPCD loops
2016-09-15 13:53:55 [19510] [0] *** TIMEOUT: Please check your process_perfdata.cfg
Einstellung:
'/etc/pnp4nagios/process_perfdata.cfg'
Option
RRD_STORAGE_TYPE = SINGLE

Ab der PNP-Version 0.6 ist es möglich, die Performance-Daten nicht in einer einzelnen RRD-Datenbank (SINGLE), sondern in mehreren RRD Datenbanken (MULTIPLE) zu speichern.
Diese Einstellung in der Konfigurations-Datei sollte NICHT global verändert werden, da PNP4Nagios nach dieser Umstellung auf MULTIPLE sofort beginnt, neue RRD-Files anzulegen. Alte Daten gehen damit sofort verloren!
Auf Grund der Performance ist es nicht sinnvoll, global mit RRD_STORAGE_TYPE = MULTIPLE zu arbeiten, da die Anzahl der RRD-Datenbanken und somit auch der Disk-I/O während der Updates sich vervielfachen würde. Deshalb sollte man überlegen, welche Nagios Checks mit dieser Einstellung gefahren werden.
Bestehende RRD-Datenbanken können über einen Konverter (Perl-Skript) '/usr/libexec/pnp4nagios/rrd_convert.pl' konvertiert werden.
Folgende Ausgabe bekommt man bei Ausführung des Perl-Skriptes:

Usage: /usr/libexec/pnp4nagios/rrd_convert.pl --check_command=
--cfg_dir= [ --list_commands ]
[ --dry-run ]
[ --tmp_dir= ]
[ --no_structure_check ]

Schaut dann so in etwa aus:
rrd-convert

# sudo -su icinga /usr/libexec/pnp4nagios/rrd_convert.pl --cfg_dir=/etc/pnp4nagios/ --check_command=disk --dry-run
Search pattern disk
XML Files analyzed 129
XML Files found 7
XML Files without RRD 0
Old XML Files ignored 0
Number of unique check_commands 15
Dry run? [YES]
Temp Directory /tmp/rrd_convert
This is only a 'dry run'. The new RRD Files are stored in '/tmp/rrd_convert'
Start Converter [n|y]?:y
File 1/7
RRDtool dump to /tmp/rrd_convert/icinga2-disk__.dump
Manipulating /tmp/rrd_convert/icinga2-disk__.dump
............ done 47999 lines
Restoring File
/tmp/rrd_convert/icinga2/disk____.rrd
... done
File 2/7
RRDtool dump to /tmp/rrd_convert/icinga2-disk.dump
Manipulating /tmp/rrd_convert/icinga2-disk.dump
............ done 48424 lines
Restoring File
/tmp/rrd_convert/icinga2/disk__tmp_vagrant-puppet_manifests-a11d1078b1b1f2e3bdea27312f6ba513.rrd
/tmp/rrd_convert/icinga2/disk__vagrant.rrd
/tmp/rrd_convert/icinga2/disk__.rrd
/tmp/rrd_convert/icinga2/disk__boot.rrd
/tmp/rrd_convert/icinga2/disk__home.rrd
/tmp/rrd_convert/icinga2/disk__tmp_vagrant-puppet_modules-41d422e93c9413f221fcbaa64a7964b7.rrd
... done
DONE

Schauen Sie doch einfach mal auf unserer Webseite vorbei, wir biete Schulungen zu vielen interessanten OpenSource-Themen an.

Johannes Carraro
Johannes Carraro
Senior Systems Engineer
Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Team Operations als Senior Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren.
Read more from Johannes and meet the Team

Vagrant-Box mit Icinga2 mit Icingaweb2 aufsetzen

by | Jun 15, 2016 |

Vagrant-Box mit Icinga2 mit Icingaweb2 aufsetzen

virtualboxAls Entwickler und Systemadministrator kommt man öfters nicht um eine Testmöglichkeit herum.
Eine VM mit einem Hypervisor seiner Wahl aufzusetzen ist meistens sehr zeitaufwendig um kleinere Tests nachzustellen.
Eine einfache und schnelle Möglichkeit bietet hier sich eine Vagrant-Box vom Internet herunter zu laden oder sich ein Git-Repositoriy mit einem vorgefertigten Image zu clonen.
Wie man sich so eine Vagrant-Box per Git cloned werde ich hier beschreiben.
 
Vorraussetzung: Virtualbox-Pakete + GIT sollten installiert sein (Virtualbox wird hier als Provider benutzt):
~ # rpm -qa | grep virtualbox
virtualbox-5.0.18-216.2.x86_64
virtualbox-guest-tools-5.0.18-216.2.x86_64
virtualbox-host-kmp-default-5.0.18_k4.1.12_1-216.2.x86_64
virtualbox-qt-5.0.18-216.2.x86_64
virtualbox-guest-kmp-default-5.0.18_k4.1.12_1-216.2.x86_64
git-2.6.6-7.1.x86_64
Info: Die Version kann von den verschiedenen Distributionen variieren.
Als nächsten müssen wir das Git-Repository lokal clonen
Dazu ins home – Verzeichnis in der Shell seiner Wahl wechseln
Ein Verzeichnis seiner Wahl anlegen:
mkdir git z.B
und in diesem Verzeichnis folgendes Kommando ausführen als user versteht sich:
~ # git clone https://github.com/Icinga/icinga-vagrant
Klone nach 'icinga-vagrant' ...
remote: Counting objects: 5172, done.
remote: Total 5172 (delta 0), reused 0 (delta 0), pack-reused 5172
Empfange Objekte: 100% (5172/5172), 1.53 MiB | 569.00 KiB/s, Fertig.
Löse Unterschiede auf: 100% (1929/1929), Fertig.
Prüfe Konnektivität ... Fertig.
So das wars auch fast schon 🙂
Jetzt z.B in das Verzeichnis Icinga2x-cluster wechseln
~ # cd icinga-vagrant/icinga2x-cluster/
Anschließend nur noch die Vagrant-Box starten:
~ # vagrant up
Nun kann es eine Weile dauernd bis die Box gebaut wird, wenn keine Fehler aufgetreten sind kann man sich per ssh connecten.
~ # vagrant ssh
[vagrant@icinga2 ~]$
Weitere vagrant Kommandos:

vagrant help    -> Listet weitere Kommandos von vagrant auf
vagrant halt  -> fährt  die Vagrant-Box herunter  (shutdown)
vagrant reload -> starten die Vagrant-Box neu (reboot)

Login-Information bekommt man direkt auf:
https://github.com/Icinga/icinga-vagrant/
Icingaweb2 nach erfolgreichen Login:
Screenshot_20160603_105621
Viel Spaß beim testen, basteln und herumspielen 🙂
Es lohnt sich auch immer mal unser Schulungsangebot sich anzuschauen.

Johannes Carraro
Johannes Carraro
Senior Systems Engineer
Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Team Operations als Senior Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren.
Read more from Johannes and meet the Team

Btrfs / snapper und Tools

by | Apr 6, 2016 |

Über dieses Datei-System und seine Tools wird ja viel geredet und spekuliert, ich möchte heute ein bißchen Praktisches und Kommandos zeigen und was man im Alltag gut brauchen kann.
Vorraussetzung ist das das Paket btrfs-procs und Abhängigkeiten installiert sind, das ist auch schon alles.
man btrfs zeigt die Möglichkeiten von btrfs und die Optionen/Schalter die es gibt.
Partitionen und UUID’s kann man so anschauen:
root:~ # btrfs filesystem show /      -> oder  abgekürzt btrfs fi sh /
Label: none uuid: 957ad303-786f-4456-95b6-1942e5d1943d
Total devices 1 FS bytes used 23.90GiB
devid 1 size 40.00GiB used 26.63GiB path /dev/sda2
————————
Speicherplatz-Belegung:
root ~ # btrfs fi df /
Data, single: total=23.01GiB, used=22.75GiB
System, DUP: total=64.00MiB, used=16.00KiB
Metadata, DUP: total=1.75GiB, used=1.14GiB
GlobalReserve, single: total=400.00MiB, used=0.00B
————————
btrfs scrub start /
liest alle Daten vom Root Filesystem und verifiziert / prüft die Checksum der Dateien im Filesystem
btrfs scrub status /
gibt den derzeitigen Status von scrub ob es Fehler in den Checksums gibt z.B.
scrub status for 957ad303-786f-4456-95b6-1942e5d1943d
scrub started at Tue Apr 5 13:35:17 2016 and finished after 00:04:16<
total bytes scrubbed: 25.03GiB with 0 errors
————————
Es gibt noch mehr Schalter z.B subvolume mit dem Subvolumes aufgelistet erzeugt werden können.
root:~ # btrfs subvolume list /
ID 257 gen 115 top level 5 path @
ID 258 gen 13814 top level 257 path @/.snapshots
ID 259 gen 13839 top level 258 path @/.snapshots/1/snapshot
ID 260 gen 4138 top level 257 path @/boot/grub2/i386-pc
————————
So kommen wir jetzt mal zu Snapper (Snapshot-Tool)
http://snapper.io/
Snapper wird bei SLES (SUSE) oder openSUSE automatisch mit installiert fürs Root-Dateisystem aktiviert, so das sofortige Änderungen am System als neuer Snapshot gespeichert werden. Diese werden normalerweise unter „/.snapshots/0 angelegt.
Für andere Linux-Distributionen wie Debian und Fedora muss wahrscheinilich installiert werden.
root:~ # snapper list
Type | # | Pre # | Date | User | Cleanup | Description | Userdata
-------+-----+-------+--------------------------+------+---------+-----------------------+--------------
single | 0 | | | root | | current |
single | 1 | | Fri Mar 4 13:01:15 2016 | root | | first root filesystem |
single | 2 | | Fri Mar 4 13:14:12 2016 | root | number | after installation | important=yes
pre | 3 | | Fri Mar 4 13:25:06 2016 | root | number | zypp(zypper) | important=yes
post | 4 | 3 | Fri Mar 4 14:00:49 2016 | root | number | | important=yes
————————
Konfig anschauen:
root:~ # snapper get-config
Key | Value
-----------------------+------
ALLOW_GROUPS |
ALLOW_USERS |
BACKGROUND_COMPARISON | yes
EMPTY_PRE_POST_CLEANUP | yes
EMPTY_PRE_POST_MIN_AGE | 1800
FSTYPE | btrfs
NUMBER_CLEANUP | yes
NUMBER_LIMIT | 10
NUMBER_LIMIT_IMPORTANT | 10
NUMBER_MIN_AGE | 1800
SUBVOLUME | /
SYNC_ACL | no
TIMELINE_CLEANUP | yes
TIMELINE_CREATE | no
TIMELINE_LIMIT_DAILY | 10
TIMELINE_LIMIT_HOURLY | 10
TIMELINE_LIMIT_MONTHLY | 10
TIMELINE_LIMIT_WEEKLY | 0
TIMELINE_LIMIT_YEARLY | 10
TIMELINE_MIN_AGE | 1800
Eine tolle ausführliche Beschreibung zu weiteren Funktionen gibt’s auf:
https://en.opensuse.org/openSUSE:Snapper_Tutorial
————————
Schönste Funktion: ROLLBACK
mit snapper rollback snapshotnumber kann man das System auf einen älteren Stand zurücksetzen..
Falls ein Update oder andere System-Probleme z.b nach einer Paket-Installation  (Kernel) fehlschlägt oder das System nicht mehr  funktionstüchig ist, kann man auf den letzten Snapshot, das System wieder auf den Stand vor dem Fehler  zurückdrehen.
Es wird vor dem Rollback noch ein Snapshot von dem „aktuellen Stand”(defeketen) gemacht und dann auf dem gewünschten Snapshot zurückgerollt.
Diese Rollback-Funktion geht nur mit dem BTRFS Datei-System und nur beim Root-Filesystem.
Es ist auch möglich von einer anderen Partition z.B. /home einen Snapper -Config zu erstellen um so automatische Snappschüsse von Home-Verzeichnis zu erhalten.
snapper -c home create-config /home
Um Dateien von einem älteren Snapshot vom /home/.snapshots/1/.. zu bekommen, muss man sich den Snapshot mounten:

mount -o subvolid=XY /dev/sdXY /mnt/
Die subvolid bekommt man durch:
root:~ # btrfs subvolume list /
ID 257 gen 115 top level 5 path @
————————
Unterschiede von zwei Snapshots:
root:~ # snapper diff 3..4 | head
Binary files /.snapshots/3/snapshot/bin/tar and /.snapshots/4/snapshot/bin/tar differ
--- /.snapshots/3/snapshot/boot/.vmlinuz-4.1.15-8-default.hmac 1970-01-01 01:00:00.000000000 +0100
+++ /.snapshots/4/snapshot/boot/.vmlinuz-4.1.15-8-default.hmac 2016-01-21 10:52:47.000000000 +0100
@@ -0,0 +1 @@
+e8eaf8b2f82bb5549f9be63183feeb09ae6e5f87d737c56ee7d00d38cfa882d6
--- /.snapshots/3/snapshot/boot/System.map-4.1.15-8-default 1970-01-01 01:00:00.000000000 +0100
+++ /.snapshots/4/snapshot/boot/System.map-4.1.15-8-default 2016-01-21 10:03:17.000000000 +0100
@@ -0,0 +1,74925 @@
+0000000000000000 D __per_cpu_start
+0000000000000000 V irq_stack_union
Welche Dateien zwischen Snapshots hinzugekommen sind:
root:~ # snapper status 3..4 | head
c..... /bin/tar
+..... /boot/.vmlinuz-4.1.15-8-default.hmac
+..... /boot/System.map-4.1.15-8-default
+..... /boot/config-4.1.15-8-default
+..... /boot/do_purge_kernels
c..... /boot/grub2/grub.cfg
c..... /boot/initrd
c..... /boot/initrd-4.1.12-1-default
+..... /boot/initrd-4.1.15-8-default
+..... /boot/symvers-4.1.15-8-default.gz
————————
Löschen von Snapshots:
snapper delete 25
snapper delete  25-30  -> löscht snapshots 25 bis 30
Ich persönlich finde das Tool Klasse, es hat mir schon mal sehr wichtige Daten gerettet.
Giv’ em a try!!

Johannes Carraro
Johannes Carraro
Senior Systems Engineer
Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Team Operations als Senior Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren.
Read more from Johannes and meet the Team

Meine erste Woche bei NETWAYS

by | Feb 10, 2016 | , ,

meine ersten Tage bei NETWAYS waren sehr aufregend und boten einiges an Input.

Alles war neu und man weiß nicht was einem erwartet, zum Glück war ich nicht der einzige neue, mit mir waren es noch 4 weitere Kollegen aber in anderen Teams, die bei NETWAYS im Februar anfingen.

Woche KW05:
Uns wurden alle Bereiche in der Firma gezeigt, auch wo der Kaffeeautomat steht und wie der funktioniert (wichtig).

Sehr interessant war auch der Rundgang im Rechenzentrum (RZ), Kesselhaus, Dachterrasse und Lager. Vor allem das RZ war eine Sicht wert, viele Serverschränke aus denen viele LED blinkten mit ziemlich lauten Gebläse – das Ganze war schon beeindruckend.

Am Nachmittag zeigt Azubi Marius uns die Tools mit den wir in Zukunft arbeiten werden und wie man sie bedient und was man zu beachten hat. Jeder von den neuen Kollegen sollte über eins unserer Produkte ein 15 min. Referat ausarbeiten und das Produkt erklären, mein Part war OpenNebula, die Open Source Cloud, was mir sehr Spaß gemacht hat.

An den zwei restlichen Tagen der Woche rauchte uns der Kopf, denn Sebastian erklärte Tim und mir im groben die Netzwerk-Struktur von NETWAYS und einige Produkte (z.B. VLAN’s, Firewalls, Icinga, OpenNebula, Puppet, Foreman, Ceph), wie funktioniert was, viel Stoff und Input, aber sehr interessant.

Ich finde es Klasse, dass man bei NETWAYS als neuer Mitarbeiter Schulungen/Trainings bekommt, da könnte sich so manche Firma eine Scheibe abschneiden. Natürlich kann auch jeder andere Interessent auf unsere Schulungen kommen.

Woche KW06:
Anfang dieser Woche fand bei uns die Übergabe eines großen Kunden-Setups und ein Podium zu CoreOS in unserem Team statt.

Von Dienstag bis Donnerstag machen wir eine 3 tägige Puppet-Fundamentals Schulung. Dort bin ich natürlich auch dabei, ohne Puppet geht bei uns nichts 🙂

Ich bin im Support-Team und für technischen Anfragen unserer Kunden zuständig und befinde mich derzeit in der Einarbeitung. Schon bald werde ich auch die Anfragen unserer Kunden bearbeiten.

Übrigens – wir sind noch immer auf der Suche nach neuen Kollegen, vielleicht ist hier auch was dabei.

Johannes Carraro
Johannes Carraro
Senior Systems Engineer
Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Team Operations als Senior Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren.
Read more from Johannes and meet the Team

Trainings

Web Services

Events