Seite wählen

NETWAYS Blog

Icinga mit IcingaDB auf Ubuntu 20.04 / 22.04 installieren

Wer nach einer Open Source Monitoring Lösung zur System- und Netzwerküberwachung sucht, kommt an Icinga (auch als Icinga 2 bekannt) nicht vorbei. Es hilft dir dabei Verfügbarkeit, Leistung und Trends der gesamten IT-Infrastruktur zu überwachen. Dank individualisierbarer Benachrichtigungseinstellungen kommen die Informationen immer genau an der gewünschten Stelle an.

Mit diesem Guide wollen wir dir dabei helfen, einen leichten Einstieg ins Icinga Monitoring zu finden und Icinga, Icinga DB und Redis erfolgreich installierst.
In diesem Guide spielt die IDO keine Rolle mehr, da diese von Icinga DB als Datenbackend abgelöst wurde. Die neue Komponente sorgt für eine bessere Performance und Skalierbarkeit von Icinga.

Voraussetzungen für die Icinga und Icinga DB Installation

Damit dieser Guide erfolgreich umgesetzt werden kann, gibt es einige wichtige Voraussetzungen:

  • Einen Ubuntu 20.04 / 22.04 Server mit mindestens 2 GB RAM und 20 GB freiem Speicherplatz
  • Der sudo – Benutzer ist auf dem Server eingerichtet und du hast das Recht, ihn zu nutzen
  • Zugriff auf eine SQL-Datenbank (in diesem Guide wird MariaDB verwendet)
  • Die aktuellste PHP-Version ist auf dem Server installiert
  • Eine Internetverbindung auf den Server
  • Optional: Ein Webserver (Apache, Nginx, etc.) ist auf dem Server installiert (als Teil des LAMP-Stack)

Du kannst hinter alle diese Punkte einen Haken setzen? Dann legen wir los!

Anmerkung: Alle nachfolgende Schritte werden als root-User durchgeführt. Überprüfe, ob du den richtigen Benutzer verwendest!

Schritt 1: Icinga Repository hinzufügen

Um die aktuelle Version von Icinga zu installieren, wird das offizielle Icinga-Repository zu unserem System hinzugefügt. Dazu führst du in deinem Terminal die folgenden Befehle aus:

apt update 
apt -y install apt-transport-https wget gnupg 
wget -O - https://packages.icinga.com/icinga.key | gpg --dearmor -o /usr/share/keyrings/icinga-archive-keyring.gpg
. /etc/os-release; if [ ! -z ${UBUNTU_CODENAME+x} ]; then DIST="${UBUNTU_CODENAME}"; else DIST="$(lsb_release -c| awk '{print $2}')"; fi; \
 echo "deb [signed-by=/usr/share/keyrings/icinga-archive-keyring.gpg] https://packages.icinga.com/ubuntu icinga-${DIST} main" > \
 /etc/apt/sources.list.d/${DIST}-icinga.list  
echo "deb-src [signed-by=/usr/share/keyrings/icinga-archive-keyring.gpg] https://packages.icinga.com/ubuntu icinga-${DIST} main" >> \
 /etc/apt/sources.list.d/${DIST}-icinga.list
apt update

Sobald dieser Befehlsblock erfolgreich durchgelaufen ist, siehst du in deinem Terminal, dass die neuen Repos nun in deiner Liste zu finden sind. Es sollte in etwa so aussehen:

Screenshot eines Ubuntu Terminals, bei dem eine Auflistung aller dem System hinzugefügten Repositories zu sehen ist. Der Screenshot soll verdeutlichen wie es aussieht, wenn die offiziellen Icinga Repositores zum System hinzugefügt wurden

Schritt 2: Icinga-Paket auf Ubuntu 20.04 oder Ubuntu 22.04 installieren

Da du nun Zugriff auf das Icinga-Repository hast, kannst du direkt damit weiter machen und das Icinga Paket installieren. Dafür nutzt du:

apt install -y icinga2

Dieses Paket ist die Basis der gesamten Icinga 2 Monitoring Installation. Um zu überprüfen, ob die Installation erfolgreich war, nutzt du

icinga2 daemon -C

Mithilfe dieses Befehls kannst zukünftige Konfigurationsanpassungen mit einem Terminalbefehl überprüfen.

Screenshot eines Ubuntu Terminals, bei dem das Kommando icinga2 daemon -C inklusive seiner Ausgabe zu sehen ist. Der Screenshot soll verdeutlichen wie die Ausgabe dieses Befehls im Terminal visualisiert wird

Schritt 3: Aktivieren der Icinga API und Installieren der Monitoring Plugins

Ein Monitoringsystem ist nur so gut wie die Daten, die es sammelt und die Checks, die ausgeführt werden.
Für moderne, aus Nagios hervorgegangene Open Source Monitoring Systeme haben sich die bereits am Anfang angesprochenen Monitoring Plugins etabliert. Diese installierst du im nächsten Schritt.

Damit kannst du direkt nach Abschluss dieses Icinga Installationsguides die ersten Checks anlegen und mit deinem System Monitoring oder Netzwerk Monitoring starten. Dafür nutzt du im Terminal den folgenden Befehl:

apt install monitoring-plugins

 

Um die Ergebnisse der Check Plugins abzurufen oder mit Icinga zu interagieren, muss die Icinga API eingerichtet werden. Das machst du ganz einfach mit diesen beiden Befehlen:

icinga2 api setup
systemctl restart icinga2

Damit legst du in der Konfigurationsdatei /etc/icinga2/conf.d/api-users.conf einen API-User (inkl. zufallsgeneriertem Passwort) an.
(Die hier erzeugten Zugangsdaten benötigst du im weiteren Verlauf bei der Einrichtung von Icinga Web. Du wirst im entsprechenden Schritt noch einmal darauf hingewiesen!)

Falls du bestimmte Vorgaben erfüllen musst oder generell mehr über die Icinga API erfahren willst, lege ich dir entsprechende Seite in den Icinga Docs ans Herz.

Weiter geht es mit der Einrichtung von Icinga DB.

Schritt 4: Icinga DB einrichten

Icinga DB ist keine, wie der Name vielleicht vermuten lässt, eigenständige Datenbank.
Vielmehr handelt es sich hierbei um eine Sammlung von Komponenten zur Veröffentlichung, Synchronisierung und Visualisierung von Überwachungsdaten im Icinga-Ökosystem. Dazu gehören Redis, das IcingaDB-Feature des Icinga Core und der Icinga DB-Daemon.

Schritt 4.1: Redis Server installieren

Um Icinga DB zu nutzen, benötigst du einen Redis Server. Für einen reibungslosen Installations- und Konfigurationsprozess bietet das Icinga Team ein eigenes Redis-Paket an, das speziell auf Icinga zugeschnitten ist.
icindadb-redis umfasst deshalb eine aktuelle Version von Redis und kommt out of the box mit Anpassungen der Freigabe auf Port 6380 statt dem sonst für Redis üblichen Port 6379.
Das Paket installierst du mit:

apt install icingadb-redis

Hinweis: Der Redis Server kann grundsätzlich überall in deiner Icinga Umgebung installiert werden. Es ist jedoch sinnvoll, diesen auf dem zentralen Icinga-Node zu installieren, um die Latenz so niedrig wie möglich zu halten.
Ein bereits vorhandener und selbst konfigurierter Redis Server kann ebenso verwendet werden. Hier sind jedoch entsprechende Anpassungen notwendig, weshalb die Nutzung des entsprechenden Icinga-Pakets empfohlen wird.

Schritt 4.2: Aktivieren von Redis

Die Installation von icingadb-redis installiert automatisch alle systemd Dateien, die Icinga DB Redis braucht. Der Service kann also direkt aktiviert und gestartet werden:

systemctl enable --now icingadb-redis-server

Standardmäßig lauscht icingadb-redis nur auf 127.0.0.1, also deinem localhost. Wenn Icinga Web 2 oder Icinga 2 auf einer anderen Node laufen als Redis, dann muss das in der Konfigurationsdatei

/etc/icingadb-redis/icingadb-redis.conf

angepasst werden.

Auch wenn in diesem Guide alle Schritte auf einer Icinga-Node durchgeführt werden, wird die Konfigurationsdatei so angepasst, dass das Aufsetzen weiterer Nodes in der Zukunft kein Problem darstellen.
Dafür sind innerhalb der Konfigurationsdatei zwei kleine Anpassungen notwendig:

  • protected-mode von yes auf no
  • bind von 127.0.0.1 auf 0.0.0.0 –> Dadurch können alle Interfaces auf Redis zugreifen

Um die Änderungen zu aktivieren, muss der Service neu gestartet werden:

systemctl restart icingadb-redis

Damit Icinga über Icinga DB später Daten an Redis weitergibt, muss das entsprechende Feature aktiviert und Icinga anschließend neu gestartet werden:

icinga2 feature enable icingadb 
systemctl restart icinga2

Sicherheitshinweis:
Redis hat standardmäßig KEINE Authentifizierung aktiviert!
Mit der Änderung von bind auf 0.0.0.0 wird dringend, um unbefugten Zugriff zu verhindern, empfohlen, einige Sicherheitsmaßnahmen durchzuführen. Dazu gehören: Einrichten eines Passworts, Aufstellen von Firewall-Regeln oder Einrichten von TLS.
Zur einfacheren Installation wird in diesem Guide jedoch auf diese Schritte verzichtet! Diese Anpassungen lassen sich ebenfalls nachträglich durchführen.

Schritt 4.3: Installieren von Icinga DB und einrichten der Datenbank

Nachdem im gerade abgeschlossenen Schritt die Schnittstelle von Icinga 2 zu Icinga DB aktiviert wurde, wird nun Icinga DB selbst installiert:

apt-get install icingadb

Damit das gerade installierte Paket die verarbeiteten Daten auch speichern kann, muss eine Datenbank für Icinga DB angelegt und Zugriff dazu gewährt werden. (In diesem Guide wird MariaDB 10.6.12 verwendet. Die Einrichtung von MySQL ist mit den gleichen Befehlen möglich. Nutzt du PostgreSQL findest du die entsprechenden Befehle in den offiziellen Icinga Docs.)

mysql -u root -p 
CREATE DATABASE icingadb; 
CREATE USER 'icingadb'@'localhost' IDENTIFIED BY 'SAFEPASSWORDINHERE'; 
GRANT ALL ON icingadb.* TO 'icingadb'@'localhost';

Damit hast du die Datenbank und den Datenbank-Nutzer erfolgreich angelegt. Icinga DB stellt zudem ein Datenbankschema zur Verfügung, dass nun importiert wird:

mysql -u root -p icingadb </usr/share/icingadb/schema/mysql/schema.sql

Schritt 4.3: Zugriffsberechtigungen anpassen

Während der Installation von Icinga DB wird unter /etc/icingadb/config.yml eine Konfigurationsdatei angelegt, die mit Standardwerten gefüllt ist. Damit die Verbindung von Icinga DB zu Redis und MariaDB erfolgreich stattfinden kann, müssen diese Werte überprüft und gegebenenfalls angepasst werden.

Öffne also den Pfad mit einem Texteditor deiner Wahl und passe die folgenden Parameter gegebenenfalls an.

Für die Datenbank:
host mit dem entsprechenden Hostname/Host-IP deiner Datenbank, database mit dem Namen deiner Datenbank (in diesem Guide icingadb), user mit dem Namen deines Datenbanknutzers und password mit dem Passwort, dass du für deine Datenbank vergeben hast.

Für Redis:
host mit dem entsprechenden Hostname/Host-IP deiner Redis Instanz. Wenn du während der Installation deines Redis-Servers den port geändert oder ein password gesetzt hast, musst du dies hier ebenfalls eintragen.

Sobald diese Änderungen abgeschlossen sind, kann der Icinga DB Service aktiviert werden:

systemctl enable --now icingadb

Schritt 5: Icinga Node Wizard ausführen

Nachdem die Grundkomponenten für die Nutzung von Icinga installiert und konfiguriert wurden, muss noch er Node Wizard ausgeführt werden. Dieses interaktive Skript hilft dir dabei, Zonen einzustellen und die Endpunkte deines Icinga Monitoring festzulegen.

Dafür gibst du im Terminal diesen Befehl ein:

icinga2 node wizard

Da hier einige wichtige Einstellungen vorgenommen werden, hier eine Übersicht der einzelnen Punkte:

  • Is this agent/satellite setup? –> Hier ’n‘ eingeben und mit Enter bestätigen
  • Specifiy common name (FQDN of your master) –> Nichts eingeben und mit Enter bestätigen
  • Master zone name –> Nichts eingeben und mit Enter bestätigen
  • Specify additional global zones –> Nichts eingeben und mit Enter bestätigen
  • Specify API bind host/port –> Nichts eingeben und mit Enter bestätigen
  • Bind Host –> Nichts eingeben und mit Enter bestätigen
  • Bind Port –> Nichts eingeben und mit Enter bestätigen
  • Disable inclusion of conf.d directory –> Nichts eingeben und mit Enter bestätigen

Screenshot der Ubuntu Terminalausgabe, bei dem das Kommando icinga2 node wizard inklusive seiner Ausgabe zu sehen ist. Der Screenshot soll verdeutlichen wie die Ausgabe dieses Befehls im Terminal visualisiert wird

Im Anschluss verifizierst du die getätigte Konfiguration und lädst Icinga 2 neu:

icinga2 daemon -C 
systemctl reload icinga2

Damit hast alle wichtigen Schritte zur Icinga und Icinga DB abgeschlossen!

Wie gehts es nun weiter?

Herzlichen Glückwunsch, du hast erfolgreich ein lokales Icinga installiert und konfiguriert! Damit könntest du nun direkt loslegen und über die Icinga2 API deine ersten Objekte anlegen, Actions triggern oder Templates bauen. Welche API-Calls dir dafür zur Verfügung stehen, kannst du übersichtlich in den Icinga Docs nachlesen.

Grundsätzlich ist die Icinga Installation nun einsatzbereit. Damit eine Open Source Monitoring Lösung wie Icinga aber produktiv genutzt werden kann, müssen die gesammelten Daten noch visualisiert werden.
Dabei helfen Icinga Web und Icinga DB Web. Wie diesen beiden Tools installiert und mit der hier aufgesetzten Basis verbunden werden erfährst du im Installationsguide zu Icinga Web und Icinga DB Web auf Ubuntu 20.04 / 22.04.

LUKS LVM Resizing

Ever tried to create a Dual Boot Ubuntu AFTER you encrypted your whole hard drive already?
Well don’t worry we got you covered!

My Problem:

I want to shrink my encrypted Ubuntu installation to make room for another OS, which I need for my video editing.
For that I have a SSD 512GB, which is encrypted with LUKS, uses LVM and ist partitioned in ext 4 fs.
But I also have an encrypted LUKS Swap called „vgubuntu-swap_1“, who also uses LVM and is formated in swap fs.

My partition had a size around 475 GiB before shrinking. The swap volume helps to demonstrate that shrinking may lead to gaps between logical LVM volumes.
The plan is to shrink the file system, its volume, the volume group and also the encrypted partition.
I used a Live Ubuntu System from a USB stick, since I could not just take the hard drive out. If you have just one computer available, use either a Live System from a USB stick or a DVD.

Disclaimer: PLEASE MAKE A BACKUP of the whole disk first.
Please read carefully through the steps first before you do anything.
If you are unsure about the commands and what they mean or what consequences they have, do some research on the Internet ahead. Likewise in case of trouble or error messages. It definitely helps to be familiar with partitioning, LVM, dm-crypt and LUKS.

My Solution:

Resizing was a sequence of 14 steps – following the disk layout in reverse order, I started resizing from the filesystem to the LVM structure down to the partition.
You open an encrypted partition with LVM on LUKS just as any dm-crypt/LUKS-partition by:

cryptsetup open /dev/Disk-MAPPING-Name cryptdisk

For the mapping name I used „cryptdisk„. Note that closing the encrypted device requires to deactivate the volume groups in the kernel first; in our case:

vgchange -a n vg1;

cryptsetup close cryptdisk

Otherwise you may not be able to close your device.

 

Step 1: Take a look at your Block Devices

With lsblk you take a look at you partitions

lsblk

For instance for me the disk appeared as „/dev/nvme0n1“ – the encrypted partition was located on „/dev/nvme0n1p3“.

 

Step 2: Opening the encrypted partition

ubuntu@ubuntu:~$ cryptsetup open /dev/nvme0n1p3 cryptdisk

Review it so you know the mapping is done correctly by „ls -la /dev/mapper“
Take a look at the „cryptdisk“-device, but keep a close eye on the LVM-volumes inside the encrypted partition. They should appear automatically as distinct devices.

 

Step 3: Let’s take a look at the LVM Structure

Next up we have:

pvdisplay
vgdisplay
lvdisplay

Pvdisplay and vgdisplay show you the PV device:  “/dev/mapper/cryptdisk” and the volume group, like in my case “vgubuntu”.
With lvdisplay you can take a look at the logical volumes, so the path to the devices and LV Size. In this case it was: “/dev/vgubuntu/root” and “/dev/vgubuntu/swap_1”

 

Step 4: Filesystem Integrity check

With fsck we can make sure the filesystem is clean:

ubuntu@ubuntu:~$ sudo fsck /dev/vgubuntu/root
fsck from util-linux 2.36.1
e2fsck 1.46.3 (27-Jul-2021)
/dev/mapper/vgubuntu-root: clean, 530426/13107200 files, 14946582/52428800 blocks

That seems fine, let’s move on!

 

Step 5: Review  filesystem physical block size and used space

Since we need to take a look at the phyisical block size, we can use “fdisk -l”.
There were also a lot of loop devices in my case, but the last entry showed my encrypted drive.

ubuntu@ubuntu:~$ sudo fdisk -l

Disk /dev/mapper/cryptdisk: 475.71 GiB, 510787584000 bytes, 997632000 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Inode count:              13107200
Block count:              52428800
Reserved block count:     2621439
Free blocks:              37482218
Free inodes:              12576774

 

Step 6: Reducing the Volume and filesystem size

For the reduced filesystem I went with 210G, since it should be about 200GiB size at the end.
With lvreduce we work with GiB, so the filesystem size should be 5-10% smaller than the logical volume size. Then we would get 200 * 1024 * 1024 * 1024 Bytes = 214.748.364.800 Bytes.

 

Step 7: Actually shrinking the filesystem

Please check first if the filesystem is mounted somewhere and then proceed with:

ubuntu@ubuntu:~$ sudo resize2fs /dev/mapper/vgubuntu-root 210G
resize2fs 1.46.3 (22-Dez-2021)
Resizing the filesystem on /dev/mapper/vgubuntu-root to <pre style="padding:8px;"> (4k) blocks.
The filesystem on /dev/mapper/vgubuntu-root is now 52428800 (4k) blocks long.

 

Step 8: Shrink the logical volume

With “lvreduce” we can resize the LVM volume, the option parameter „L“ together with a „size“ determines how big the volume will become.

ubuntu@ubuntu:~$  lvreduce -L 200G /dev/vgubuntu/root
WARNING: Reducing active logical volume to 200 GiB.
THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce vgubuntu/root? [y/n]: y
Size of logical volume vgubuntu/root changed from 210 GiB (20480 extents) to 200.00 GiB (15360 extents).
Logical volume vgubuntu/root successfully resized.

Since we got the confirmation that it worked, we can now proceed.

 

Step 9: Check for gaps between the volumes of your LVM volume group

That was the trickiest part for me at least since I had a swap with my Ubuntu. The first thing I did was to scan for the Swap, on which Blocks it was located.

I then used “pvmove” to get the swap from the last blocks to the ones after my root volume.

As you can see, my swap moved over and my free space had no further volumes in between.

 

Step 10: Resize/reduce the physical LVM

Next I had to resize and reduce the physical LVM to 200G

ubuntu@ubuntu:~$ sudo pvresize --setphysicalvolumesize 200.96G /dev/mapper/cryptdisk
/dev/mapper/cryptdisk: Requested size <200.96 GiB is less than real size <475.71 GiB. Proceed?  [y/n]: y
WARNING: /dev/mapper/cryptdisk: Pretending size is 421443665 not 997632000 sectors.
Physical volume "/dev/mapper/cryptdisk" changed
1 physical volume(s) resized or updated / 0 physical volume(s) not resized

Since the resize worked, I wanted to make sure everything was fine.

ubuntu@ubuntu:~$ sudo pvdisplay
--- Physical volume ---
PV Name               /dev/mapper/cryptdisk
VG Name               vgubuntu
PV Size               <200.96 GiB / not usable <2.04 MiB
Allocatable           yes (but full)
PE Size               4.00 MiB
Total PE              51445
Free PE               0
Allocated PE          51445
PV UUID               KpzZm…

 

Step 11: Setting up the encrypted regions size

First make sure which Block Size the current drive has:

ubuntu@ubuntu:~$ sudo cryptsetup status cryptdisk
/dev/mapper/cryptdisk is active and is in use.
type:    LUKS2
cipher:  aes-xts-plain64
keysize: 512 bits
key location: keyring
device:  /dev/nvme0n1p3
sector size:  512
offset:  32768 sectors
size:    997632000 sectors
mode:    read/write

Then I had to calculate the new blocksize for the encrypted disk, I used the formula on the Arch Wiki: NEW_LUKS_SECTOR_COUNT = PV_EXTENT_COUNT * PV_EXTENT_SIZE / LUKS_SECTOR_SIZE

From Step 10 (pvdisplay) and the cryptdisk status you can gather all the information needed to get:
(53880 extent + 1 unusable extent) * 4 MiB/extent /512 B/sector = 441393152 sectors

ubuntu@ubuntu:~$  sudo cryptsetup -b 441393152 resize cryptdisk
Enter passphrase for /dev/nvme0n1p3:
ubuntu@ubuntu:~$ sudo cryptsetup status cryptdisk
/dev/mapper/cryptdisk is active and is in use.
type:    LUKS2
cipher:  aes-xts-plain64
keysize: 512 bits
key location: keyring
device:  /dev/nvme0n1p3
sector size:  512
offset:  32768 sectors
size:    441393152 sectors
mode:    read/write

And now we have a smaller LUKS Partition. You came this far, now don’t stop!

 

Step 12: Reduce the size of the physical partition

Here I used parted to get an overview of my drives and resize it to the desired size:

ubuntu@ubuntu:~$ sudo parted /dev/nvme0n1
GNU Parted 3.4
Using /dev/nvme0n1
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Model: PM9A1 NVMe Samsung 512GB (nvme)
Disk /dev/nvme0n1: 512GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number  Start   End     Size   File system  Name                  Flags
1      1049kB  538MB   537MB  fat32        EFI System Partition  boot, esp
2      538MB   1305MB  768MB  ext4
3      1305MB  512GB   511GB

(parted) resizepart

Partition number? 3
End?  [512GB]? 211GB
Warning: Shrinking a partition can cause data loss, are you sure you want to continue?
Yes/No? y
(parted) print
Model: PM9A1 NVMe Samsung 512GB (nvme)
Disk /dev/nvme0n1: 512GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number  Start   End     Size   File system  Name                  Flags
1      1049kB  538MB   537MB  fat32        EFI System Partition  boot, esp
2      538MB   1305MB  768MB  ext4
3      1305MB  211GB   210GB

(parted) q

Information: You may need to update /etc/fstab.

I checked with print in between, to see if the parted resize worked.

 

Step 13: Set new size of the encrypted region

Now we just need to make sure we also have use the full partition size:

ubuntu@ubuntu:~$ sudo cryptsetup resize cryptdisk
ubuntu@ubuntu:~$ sudo cryptsetup status cryptdisk
/dev/mapper/cryptdisk is active.
type:    LUKS2
cipher:  aes-xts-plain64
keysize: 512 bits
key location: keyring

device:  /dev/nvme0n1p3
sector size:  512
offset:  32768 sectors
size:    409526848 sectors
mode:    read/write

 

Step 14: Reset the PV size to the full partition size

Next up we have to use pvresize so the cryptdisk gets also adjusted and then we can take a look at the volumes.

ubuntu@ubuntu:~$ pvresize  /dev/mapper/cryptdisk
Physical volume "/dev/mapper/cryptdisk" changed
1 physical volume(s) resized / 0 physical volume(s) not resized
ubuntu@ubuntu:~$ sudo pvdisplay
--- Physical volume ---
PV Name               /dev/mapper/cryptdisk
VG Name               vgubuntu
PV Size               210.47 GiB / not usable 2.00 MiB
Allocatable           yes
PE Size               4.00 MiB
Total PE              53880
Free PE               2435
Allocated PE          51445
PV UUID               Kpz...

ubuntu@ubuntu:~$ sudo vgdisplay
--- Volume group ---
VG Name               vgubuntu
System ID
Format                lvm2
...
VG Size               <210.47 GiB
PE Size               4.00 MiB
Total PE              53880
Alloc PE / Size       51445 / <200.96 GiB
Free  PE / Size       2435 / 9.51 GiB
VG UUID               dz0...

That’s it!

You can also do a checkup with gparted/disks, but apart from that I was just happy that I had more space for a second OS while also maintaining the encryption for Ubuntu!
(Now I will create another backup, just in case I break something with the new OS Installation.)

 

 

Monitoring-Plugins Software-Repository von NETWAYS

Ab sofort bieten wir unter https://packages.netways.de/plugins, die von uns meist genutzten Monitoring-Plugins als Pakete für RHEL 8 und 7, Debian Buster und Stretch, sowie Ubuntu Bionic Beaver und Focal Fossa zum Download an.

Zur Zeit überwiegen die RPM Pakete in der Anzahl, wir hoffen dies in den kommenden Wochen auszugleichen. Wir werden auch bemüht sein, das Angebot in den kommenden Wochen sukzessive zu erweitern. Gerne verfolgen wir dies auch innerhalb von Kundenprojekten, um diesen und allen anderen einen Zugang zu regelmäßig aktualisierten Plugin-Paketen anzubieten.

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Landscape – On-Premise

Bei Netways muss jeder Azubi jede Abteilung durchlaufen. Grund hierfür ist die Arbeit der anderen Mitarbeiter besser zu verstehen und zu respektieren. Derzeit bin ich bei Managed Services, genauer noch im Customer Hosting. Im Zuge dessen sollte ich mich mit alternativen Verwaltungstools auseinandersetzen im speziellen mit Landscape.

Was ist Landscape?

Landscape ist ein Management-Tool von Canonical. Des Weiteren bietet Landscape einige kleinere Kapazitäten hinsichtlich Monitoring, darunter Netzwerk- und Speicherauslastung, aber auch verbleibende Speicherkapazität, Netzwerkbelastung oder derzeitiger SWAP-Verbrauch.

Der Kern der Anwendung ist jedoch die einfache Ausführung von Updates/Upgrades, sowie Scripts auf Systemen, sowie die Möglichkeit diese zu limitieren und individuell anzuwenden. Eine Reihe an weiteren Features werden von Canonical für Landscape beworben, die ihr hier finden könnt.

Was kostet Landscape?

Landscape’s Kosten variieren stark anhand der Umgebung, die man damit verwalten möchte. Jedoch gibt es die Möglichkeit Landscape in einer kleineren Umgebung – bis zu 10 Vms und 50 Container – umsonst zuverwenden, dies nennt sich Landscape On-premises.

Wie installiere ich Landscape On-premises?

Die entsprechende Software Repository hinzufügen:

sudo add-apt-repository ppa:landscape/18.03

sudo apt-get update

Und daraufhin installieren:

sudo aptitude install landscape-server

sudo aptitude install landscape-server-quickstart

Die Quickstart-Variante installiert App-Server, Datenbank etc. alles auf das gleiche System.

Sollte das nicht gewünscht sein, gibt es ebenfalls eine ausführliche Dokumentation zur manuellen Installation hier.

Falls es zu Fehlern aufgrund von Package-Dependencys kommen sollte, dann kann dieses einfach mit aptitude anstelle von apt-get gelöst werden.

Jetzt können bereits Clients hinzugefügt werden. Eine ausführliche Anleitung dafür ist zwar auch im Webinterface unter <IP_of_APP-Server>/account/standalone/how-to-register zu finden. Dort wird auch automatisch ein Befehl generiert, der die entsprechenden Parameter setzt die zum hinzufügen relevant sind.

 

Alexander Stoll
Alexander Stoll
Consultant

Alex hat seine Ausbildung zum Fachinformatiker für Systemintegration bei NETWAYS Professional Services abgeschlossen und ist nun im Consulting tätig. Vereinzelt kommt es auch vor das er an Programmierprojekten mitarbeitet. Auch privat setzt er sich sehr viel mit Informationstechnologie auseinander, aber jenseits davon ist auch viel Zeit für Fußballabende, Handwerkerprojekte und das ein oder andere Buch.

DELL XPS13 – Ein anständiges Fliegengewicht mit kleinerer Klappe

Dies ist die Fortsetzung zum zickigen Leichtgewicht mit großer Klappe.
Nun war es mal wieder soweit. Nach Jahren als einiger der wenigen die bei Meetings kein Macbook vor sich stehen hatten, habe ich nun erneut ein DELL XPS13 erhalten. Diesmal ist es das Modell 9370 (vormals 9343) in der FHD Ausführung. Oh ja, was vorher ein QHD+ war ist nun kleiner. Aber dafür viel angenehmer. Seit Ubuntu 14.04 hat sich zwar einiges getan hinsichtlich HiDPI Unterstützung, jedoch scheitert es immer noch meist an einzelnen Applikationen. Aus diesem Grund habe ich seit langem schon nicht die native Auflösung von 3200×1600 Bildpunkten betrieben, sondern wie auch mein zweiter Bildschirm mit 1920×1080 Bildpunkten. Allerdings war eine gewisse Unschärfe nicht zu verhindern.
Nunja, das neue Modell hat nun FHD als native Auflösung und jegliche Probleme mit Unschärfe, zu kleiner Schrift oder schrägen Skalierungs-Artefakten sind nun Geschichte. Geschichte ist außerdem der Touchscreen, aber den hab ich eh nie gebraucht. Was hingegen vollkommen neu ist:

  • Es wirkt leichter. Ich habs nicht nachgewogen, aber es wirkt eindeutig leichter.
  • 3 (!) USB-C Ports (Das waren vorher 2 USB-A Ports)
  • 4 statt 2 CPU-Kerne. Power satt. (Aber auch Hitze, dazu später mehr)
  • Ganze 16 GB RAM. (Vorher mit 8GB kam ich schon hin und wieder an meine Grenzen)
  • Mit 512 GB SSD doppelter Speicherplatz als vorher. (Jetzt werd ich wohl weniger oft VMs löschen)
  • Eine Infrarot Kamera. (Ist wohl ein Überbleibsel aus der Windows Variante, könnte noch nützlich werden)
  • Oh, und das Tastatur Layout. Ich nutze gerne Home, End, PageUp und PageDown. Jetzt muss ich dafür keine akrobatischen Kunststücke mit dem Function-key mehr vollziehen!

Wieder einmal war auch Ubuntu vorinstalliert. Da ich allerdings diesmal FDE (Full Disk Encryption) einsetzen wollte musste das runter. Zuerst hatte ich versucht mit Dell Recovery neu zu installieren. Schließlich hat Dell einen eigenen Kernel mit Plattform spezifischen Verbesserungen entwickelt. Dummerweise jedoch ist scheinbar genau jener Kernel (oder irgendwas anderes in diesem Paket) inkompatibel mit LUKS (Quelle), denn egal welches Passwort ich gewählt hatte (zuletzt „test“), nach abgeschlossener Installation wurde keines von LUKS als richtig erkannt.
Gut, also hieß es nun das normale Ubuntu 18.04 mit dem generic Kernel zu installieren. Und siehe da, es lief perfekt. Und so läuft es auch jetzt noch. Kaum zu glauben, ist aber wahr. Okay, vielleicht nicht perfekt, aber immerhin gut genug für mich. Bisher sind mir keine Fehler aufgefallen. All die Probleme die ich initial mit dem vorherigen Modell (9343) hatte, traten nicht auf. Kein Tastatur-Lag. Kein Touchpad-Ghosting. Sound ging sofort. Nichts. Nicht einmal mit dmesg sind grobe Fehler oder Warnungen zu entdecken. Ja sogar der Philips Monitor mit USB-C Dock-Funktionalität wird mitsamt der an ihn angeschlossenen Peripherie anstandslos erkannt.
Der einzige Wermutstropfen, wie eingangs schon erwähnt, ist die Hitze-Entwicklung. Ich habe noch nicht nachgesehen ob ich im UEFI die Lüfter konfigurieren kann, aber im Werkszustand drehen die leider bereits bei knapp über 55° lautstark auf. Wie laut kann ich nicht messen, aber es übertönt die sonst üblichen Geräusche im Büro. (Tastatur Klackern, knarrende Stühle, etc) Und hab ich mal PhpStorm und eine Centos-7 VM mit Icinga 2 und Icinga Web 2 laufen, werden die 55° schon recht oft überschritten. Dann blasen die Lüfter erst einmal für einige Minuten, bis ~43° erreicht sind.
Zu guter letzt habe ich heute mal nachgesehen was ich mit dieser ominösen Infrarot Kamera machen kann. Dabei erfahre ich, hätte ich Windows könnte ich diese mit Windows Hello koppeln. Hm, hab ich aber nicht, ich habe Ubuntu. Gut, gibt es Windows Hello Alternativen für Linux? Ja! Howdy! Auch ich musste schmunzeln bei diesem Namen. Erste Versuche führten auch recht schnell zum Erfolg. Jetzt kann ich einfach in die Kamera grinsen wenn ich im Login-Screen oder Lock-Screen bin. Oder mit sudo Kommandos ausführe. Oder im Ubuntu Software-Center etwas installiere. Kurz, dank PAM geht das einfach überall.

Johannes Meyer
Johannes Meyer
Lead Developer

Johannes ist seit 2011 bei uns und inzwischen, seit er 2014 die Ausbildung abgeschlossen hat, als Lead Developer für Icinga Web 2, Icinga DB Web sowie alle möglichen anderen Module und Bibliotheken im Web Bereich zuständig. Arbeitet er gerade mal nicht, macht er es sich bei schlechtem Wetter am liebsten zum zocken oder Filme/Serien schauen auf dem Sofa gemütlich. Passt das Wetter, geht's auch mal auf eines seiner Zweiräder. Motorisiert oder nicht.