Lokale Time Machine Snapshots blockieren Speicherplatz

Kürzlich hatte ich den Plan, ein ca. 100GB iPhone Backup zwischenzeitlich auf dem Mac anzufertigen. Meinem Plan stand nach einem kurzen Blick auf den freien Diskspace des Finders eigentlich nichts im Wege, denn dieser zeigte noch 120 GB freien Speicherplatz an. Nachdem sich das Backup aber mit einem bisher unbekannten Fehler verabschiedete, machte ich mich einmal auf die Suche, was mein Mac denn so eigentlich macht.

Ein Kurzer Blick im Terminal bestätigte mir allerdings viel weniger freien Platz auf der Platte, als der Finder es tat. So waren hier nur noch 55 GB frei. Wie kann das sein?

Zunächst einmal öffnet ihr euer Terminal im Mac und gebt folgendes Kommando ein

df -h

Der Mac zeigt nun in aller Regel in der ersten Zeile die Informationen der Mac-Festplatte (Gegenkontrolle Anhand der Size-Spalte) an. In der Spalte Available steht der noch zur Verfügung stehende Speicherplatz. Sollten sich diese Werte im Finder und im Terminal erheblich unterscheiden, macht es Sinn, die Snapshots unter die Lupe zu nehmen.

Warum Snapshots?

Sollte das Time Machine Backup Volume (z. B. wenn man im Urlaub ist) nicht verfügbar sein, fertigt der Mac lokale Snapshots an. Ein solcher Snapshot schützt zwar nicht vor Datenverlust bei einem Hardwareschaden, wohl aber bei unbeabsichtigten Löschen – also die haben schon Ihre Daseinsberechtigung und fertigen zuverlässig auch ohne Backupvolume im Hintergrund eine Art Sicherung an. Normaler Weise gibt der Mac nach und nach die Snapshots frei, wenn er merkt, dass der Platz benötigt wird. Das ist wahrscheinlich auch der Grund, warum der Finder die Snapshots von der Kalkulation des freien Speicherplatzes excludiert.

Habe ich auch Snapshots?

Sofern ein Time Machine Backup läuft, wird diese Funktion aktiviert. Allerdings tritt sie nur in Kraft, wenn das Backup-Volume nicht verfügbar ist. Am besten prüft man das kurz über das Mac-Terminal mittels Eingabe des folgenden Kommandos. Es listet alle vorhandenen Snapshots der Primärplatte auf.

tmutil listlocalsnapshots /

Möchte man nun einmal solche Snapshots entsorgen, so lässt sich das mit folgendem Kommando erledigen

sudo tmutil thinLocalSnapshots / 10000000000 4

Kurze Erklärung hierzu: / Bezieht sich wieder auf das soeben ermittelte Volume (also die primäre Festplatte, das braucht man in aller Regel nicht ändern), 10000000000 bezieht sich auf den “purgeamount” also die Menge, in diesem Beispiel sind das 10 GB. Um mehr freizugeben, Zahl auf beliebigen Wert in Byte erhöhen, oder Kommando mehrfach ausführen. Die 4 steht für die “urgency”, also die Dringlichkeit. 1 ist hier die höchste, aber 4 reicht eigentlich auch zum Löschen.

Nachhaltig verhindern, lassen sich lokale Snapshots auf den Apple-Geräten mit folgendem Kommando:

sudo tmutil disablelocal

Alternativ Time Machine nicht mehr nutzen, oder dafür sorgen, dass die Backupvolumes immer verfügbar sind.

Georg Mimietz

Autor: Georg Mimietz

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

SNMP Netzwerk Monitoring

Huhu!

Heute möchte ich euch ein wenig in die Welt von SNMP Monitoring mit Icinga 2 entführen. Da man leider nicht immer einen Switch mit SNMP zur Hand hat, verwende ich eine GNS3 Netzwerk Umgebung sowie eine CentOS 7 Maschine für Icinga 2.

Doch was ist den dieses SNMP überhaupt, was kann das? Zunächst SNMP steht für Simple Network Message Protocol (RFC 1157) und wurde mit dem Gedanken entwickelt Netzwerkgeräte wie Drucker, Router, Switche und vermutlich irgendwann auch Toaster per IoT von einem Zentralen Punkt im Netzwerk aus überwachen bzw. steuern zu können. SNMP an sich besitzt nicht wirklich viel Magie es beschreibt im Endeffekt wie Datenpakete aussehen können. Damit Icinga 2 (Managmentstation) den Switch (Agent) fragen kann, wie es ihm den heute so geht. Die eigentliche Magie ist die sogenannten Managment Information Base, umgangssprachlich auch MIB genannt.

Die MIB kann man sich wie einen großen Baum vorstellen, dessen Äste und Blätter mit Hilfe von eindeutigen OIDs gebildet werden. Die Blätter die an unseren Ästen hängen sind Objekte wie ein Lüfter, oder eine Festplatte und können als als OID so aussehen: 1.3.6.1.4.1.1.4.

Nach viel Techbabbel kommt nun wenig Kaboom (Practical Examples). An Hand des Beispiel möchte ich euch ein Grundgerüst an die Hand geben, wie man bequem und ohne Geräte spezifisches Plugin ein SNMP Monitoring unter Icinga 2 einfach realisieren kann.

Im ersten Schritt holen wir uns alle OIDs samt Beschreibung vom Gerät, in meinem Fall von einem VyOS Router:

snmpwalk -Os -v 1 -c public 192.168.174.131 >> /tmp/snmpwalk_desc
snmpwalk -v 1 -c public 192.168.174.131 >> /tmp/snmpwalk_oid

Für das Beispiel wähle ich drei OIDs aus:

.1.3.6.1.2.1.2.2.1.2.1
.1.3.6.1.2.1.2.2.1.2.2
.1.3.6.1.2.1.2.2.1.2.3

Mit dem Director hab ich ein Template und Service angelegt, welches auf das Check_Plugin/Kommando check_snmp zurückgreift. Die ausgewälten OIDs werden Kommasepariert per Costume Attribut “snmp_oid” mitgegeben:

template Service "snmp" {
    check_command = "snmp"
    max_check_attempts = "3"
    check_interval = 1m
    retry_interval = 20s
}
object Service "Interfaces" {
    host_name = "vyos"
    import "snmp"
    vars.snmp_label = "Interfaces"
    vars.snmp_oid = ".1.3.6.1.2.1.2.2.1.2.1,.1.3.6.1.2.1.2.2.1.2.2,.1.3.6.1.2.1.2.2.1.2.3"
}

Nach dem ausbringen der Konfiguration sollte das ganze folgendermaßen aussehen:

 

Tipp am Rande:
Falls euer Gerät nicht auf Öffentlichen MIBs aufbauen sollte, wie hier im Beispiel, bekommt ihr die im Regelfall vom Hersteller bereitgestellt. Die MIB wird einfach zu den bereits existierenden hinzugefügt und dann ist alles wie gehabt! 🙂

Damit verabschiede ich mich und wünsche wie immer viel Spass beim Implementieren!

Max Deparade

Autor: Max Deparade

Max ist seit Januar als Consultant bei NETWAYS und unterstützt tatkräftig unser Professional Services Team. Zuvor hat er seine Ausbildung zum Fachinformatiker für Systemintegration bei der Stadtverwaltung in Regensburg erfolgreich absolviert. Danach hat der gebürtige Schwabe, der einen Teil seiner Zeit auch in der Oberpfalz aufgewachsen ist ein halbes Jahr bei einem Managed Hosting Provider in Regensburg gearbeitet, ehe es ihn zu NETWAYS verschlagen hat. In seiner Freizeit genießt Max vor allem die Ruhe, wenn er nicht gerade fieberhaft auf sein neues Macbook wartet.

MySQL-Datenbanken verwalten mit Sequel Pro

MySQL-Datenbanken verwalten mit Sequel Pro

Eines meiner meist genutzten Apps am Mac ist Sequel Pro. Das kann man kennen, muss man aber nicht. Daher liest man – wenn man möchte – in den folgenden Zeilen eine kurze Vorstellung.

(more…)

Florian Strohmaier

Autor: Florian Strohmaier

Mit seinen Spezialgebieten UI-Konzeption, Prototyping und Frontendentwicklung unterstützt Florian das Dev-Team bei NETWAYS. Trotz seines Design-Backgrounds fühlt er sich auch in der Technik zuhause. Gerade die Kombination aus beidem hat für ihn einen besonderen Reiz.

Konfiguration mit Lsyncd synchronisieren

Hallo!

Heute möchte ich euch ein Tool vorstellen mit dem man relativ einfach, sicher und in nahezu realzeit Konfiguration auf andere Systeme und umgekehrt synchronisieren kann. Das Tool hoert auf den Namen Live Syncing (Mirror) Daemon, oder kurz gefasst Lsyncd.

Als erstes möchte ich etwas auf die Magie von Lsyncd eingehen, damit man einen Eindruck bekommt wie das Tool arbeitet und was für Möglichkeiten sich ergeben. Lsyncd verwendet unter Linux inotify und unter MacOS FSEvents um Änderungen am Verzeichnissbaum zu beobachten. Anhand dieses “Monitorings” kann Lsyncd feststellen, ob Änderungen im zur synchronisation bestimmten Verzeichnis passiert sind. Ist dies der Fall, startet Lsyncd die synchronisation mit den zuvor entsprechend gesetzten Parametern. Die Parameter sind z.B. welches Verzeichniss von soll wohin repliziert werden und welches Protokoll soll dafür genutzt werden z.B. rsync.

Kommen wir zum interessanteren Teil die Installation und Konfiguration von Lsyncd. In den meisten Distributionen ist Lsyncd bereits als fertiges Paket vorzufinden. Für die demonstration verwende ich eine CentOS 7.x Maschine in VirtualBox auf einem Laptop.

Vorbereitung/Installation (CentOS 7.x)

Zunächst installieren wir das lsyncd Paket mittels YUM und generieren bzw. verteilen anschließend unseren SSH-Key den wir später für Lsyncd nutzen.

[root@lsyncdemo ~]# yum install lsyncd
[root@lsyncdemo ~]# ssh-keygen -t ed25519
Generating public/private ed25519 key pair.
Enter file in which to save the key (/root/.ssh/id_ed25519): /root/.ssh/id_lsync
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_lsyync.
Your public key has been saved in /root/.ssh/id_lsyync.pub.
The key fingerprint is:
SHA256:ntsHfyqPkwffQ3IPMUkZ6kIOMdSBqVhREwgag7V1TgI root@lsyncdemo
The key's randomart image is:
+--[ED25519 256]--+
| oE.+.+=B=.. .o |
|. * =o o+. .o |
| o o... . .. . |
| . . + . + |
| S o . o |
| . .o.. + |
| o * = o |
| o+.= + .|
| . o*oo . |
+----[SHA256]-----+
[root@lsyncdemo ~]# ssh-copy-id -i /root/.ssh/id_lsync i2node01

Konfiguration

Nun kommen wir zur Konfiguration unseres Lsyncd, hierfür existiert genau eine Konfigurationsdatei unter /etc/ (equivalenter pfad osx) mit dem Namen lsyncd.conf. Für unser Beispiel synchronisiere ich Verzeichnis mit Konfiguration auf meinen Icinga2 Master (i2node01).

[root@lsyncdemo ~]# vi /etc/lsyncd.conf
<...
- sync{default.rsyncssh, source="/var/www/html", host="localhost", targetdir="/tmp/htmlcopy/"} //Beispiel Konfiguration entfernen

+ sync{ //Icinga Configuration
+  default.rsync, //Wir nutzen rsync zum Synchronisieren
+  source="/home/mdeparade/icinga2/scripts", //Das Quellverzeichnis
+  target="i2node01:/etc/icinga2/scripts", //Das Zielverzeichnis
+  rsync={rsh ="/usr/bin/ssh -l root -i /root/.ssh/id_lsync", owner = true, perms = true,}
+ }
...>

Kurze Erläuterung: Die letzte Zeile unserer Konfiguration gibt rsync noch ein paar Informationen mit: Wir bauen einen SSH-Tunnel als Benutzer root auf, mit dem SSH-Key “id_lsync”, anschließend sagen wir noch das alle Berechtigungen der Dateien/Verzeichnisse erhalten bleiben sollen.

Abschluss

Nachdem wir Lsyncd mit Konfiguration versorgt haben, können wir diesen direkt starten und Überprüfen ob unser Synchronisation auch ordnungsgemaess funktioniert:

[root@lsyncdemo ~]# cat /etc/lsyncd.conf
----
-- User configuration file for lsyncd.
--
-- Simple example for default rsync, but executing moves through on the target.
--
-- For more examples, see /usr/share/doc/lsyncd*/examples/
--
sync{
default.rsync,
source="/home/mdeparade/icinga2/scripts",
target="i2node01:/etc/icinga2/scripts",
rsync={rsh ="/usr/bin/ssh -l root -i /root/.ssh/id_lsync", owner = true, perms = true,} 
}
[root@lsyncdemo ~]# systemctl enable lsyncd --now
[root@lsyncdemo ~]# systemctl status lsyncd
● lsyncd.service - Live Syncing (Mirror) Daemon
 Loaded: loaded (/usr/lib/systemd/system/lsyncd.service; enabled; vendor preset: disabled)
 Active: active (running) since Fri 2018-04-09 10:49:36 BST; 1s ago
 Main PID: 1477 (lsyncd)
 CGroup: /system.slice/lsyncd.service
 └─1477 /usr/bin/lsyncd -nodaemon /etc/lsyncd.conf

Apr 09 10:49:36 lsyncdemo systemd[1]: Started Live Syncing (Mirror) Daemon.
Apr 09 10:49:36 lsyncdemo systemd[1]: Starting Live Syncing (Mirror) Daemon...
[root@lsyncdemo ~]# ll /home/mdeparade/icinga2/scripts
total 4
-rw-r--r--. 1 root root 5 Apr 09 10:52 test.conf
[root@lsyncdemo ~]# ssh -i /root/.ssh/id_lsync -l root 192.168.56.11 ls /etc/icinga2/scripts
test.conf
[root@lsyncdemo ~]# exit
logout
Connection to blog.netways.de closed.

Eindrücke aus Bayern: Die Alpen

Max Deparade

Autor: Max Deparade

Max ist seit Januar als Consultant bei NETWAYS und unterstützt tatkräftig unser Professional Services Team. Zuvor hat er seine Ausbildung zum Fachinformatiker für Systemintegration bei der Stadtverwaltung in Regensburg erfolgreich absolviert. Danach hat der gebürtige Schwabe, der einen Teil seiner Zeit auch in der Oberpfalz aufgewachsen ist ein halbes Jahr bei einem Managed Hosting Provider in Regensburg gearbeitet, ehe es ihn zu NETWAYS verschlagen hat. In seiner Freizeit genießt Max vor allem die Ruhe, wenn er nicht gerade fieberhaft auf sein neues Macbook wartet.

Philips Brilliance 258B6 and macOS

With Apples policy to get rid of established connection methods and switching entirely to USB-C, we faced the need for keeping hardware connected to the new Apple devices.

As there are many offers for adapting USB-C to any other connectors, we looked thoroughly through these possibilities.

In the end we found a charming solution, Philips’ Brilliance 258B6 (Review)

It provides USB-A, HDMI, DSUB, DVI, Audio connectivity, Ethernet, Display Connection and Power Supply via one single USB-C Slot so other devices could still be connected directly at the MacBooks USB-C ports.

While this setup has been runnig smoothly with mostly Dell Notebooks with Windows and Fedora, macOS was sometimes having issues.

The most annoying one has been intermittend Network connection loss. We have discussed this topic at length and could determine, that there is no fault at our network setup.

After a lot of testing, Philips came up with a solution: Installing the correct driver! You may find version 1.0.17 here.

Having installed this specific version, the monitors started to act as expected.

Another issue some users had to face, was a random vertical shift by one pixel.

Using the OSD you might want to switch off “Pixel Orbiting” and this strange behaviour stopped.

So if you’re thinking about buying a new monitor for your new devices, this monitor might be a very good choice.

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!

Apple Pi – einfach und sicher

Eigentlich hatte ich (wie im letzten Blogpost angekündigt) vor, es dieses mal so richtig unnötig kompliziert zu machen… aber nein: Apple lässt mich einfach nicht. Um genau zu sein: dieser Konzern trägt mir mittels seiner Geräte so ziemlich alles hinterher.

So beispielsweise auch im folgenden Fall:

Ich wollte für einen Test einen Raspberry Pi verwenden – dieser ist bekanntlich relativ “pflegeleicht”: Er fordert standardmäßig eine IP-Adresse via DHCP an und mit den Standart-Zugangsdaten (pi:raspberry) ist man da schneller drin als in so mancher Abo-Falle. Aber genau das habe ich als alter Sicherheits-Fanatiker nicht so gerne. Was wenn jemand anderes aus meinem Netz sich schnell genug mit genau diesen Zugangsdaten anmeldet und irgendeinen Blödsinn anstellt? Dann habe ich den Salat…

Um genau das einzudämmen, kann man den Pi per Netzwerkkabel direkt mit dem eigenen Rechner verbinden. Damit hat man sein eigenes “Netz”, in das niemand so schnell einbrechen kann.

Für die Kommunikation mit dem Pi benötigt dieser noch zumindest eine IP-Adresse – beispielsweise via DHCP. Also erstmal einen DHCP-Server auf dem MacBook einrichten… obwohl… geht das nicht auch einfacher?

Erste Hilfe: Die Internetfreigabe

Ja, es geht deutlich einfacher – mit der Internetfreigabe unter Systemeinstellungen / Freigaben. Diese ist eigentlich dafür gedacht, ein Netzwerk mit allen Rechnern in einem anderen Netzwerk zu teilen. Dafür bringt diese DHCP-Server, NAT-Router und DNS-Sever von Haus aus mit. Diesen Umstand nutzt man einfach aus und teilt eine beliebige Verbindung (am besten eine, über die das Internet erreichbar ist) “mit Computern über” den Anschluss, an dessen anderem Ende der Pi steht.

Nun verbindet man einfach den Pi mit der entsprechenden Schnittstelle und schließt ihn an die Stromversorgung an. Nach einigen Sekunden sollte er eine IP-Adresse anfragen – und sie auch bekommen:

Wer Wireshark nicht (rechtzeitig) gestartet hat – oder gar nicht erst installiert hat, kann auch auf Mac-Bordmittel zurückgreifen:

alexanders-mbp:~ aklimov$ arp -a
(...)
? (192.168.2.2) at ba:de:af:fe:d0:0f on bridge100 ifscope [bridge]
(...)

Mit der IP-Adresse kann man sich nun via SSH mit dem Pi verbinden und das Passwort ändern – und am besten gleich seinen öffentlichen SSH-Schlüssel hinterlegen.

alexanders-mbp:~ aklimov$ ssh pi@192.168.2.2
The authenticity of host '192.168.2.2 (192.168.2.2)' can't be established.
ECDSA key fingerprint is SHA256:KkfoOLDL8XsEUquBaSCjFVtzMCPG9mrOvFf8oS0KkHg.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.2.2' (ECDSA) to the list of known hosts.
pi@192.168.2.2's password:
Linux raspberrypi 4.9.59+ #1047 Sun Oct 29 11:47:10 GMT 2017 armv6l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu Dec 21 10:58:13 2017

SSH is enabled and the default password for the 'pi' user has not been changed.
This is a security risk - please login as the 'pi' user and type 'passwd' to set a new password.

pi@raspberrypi:~ $

Fazit

Als alter Linux-Nutzer bin ich immer wieder positiv überrascht. Mal schauen, wann Apple selbst-schälende Äpfel auf den Markt bringt…

Alexander Klimov

Autor: Alexander Klimov

Alexander hat 2017 seine Ausbildung zum Developer bei NETWAYS erfolgreich abgeschlossen. Als leidenschaftlicher Programmierer und begeisterter Anhänger der Idee freier Software, hat er sich dabei innerhalb kürzester Zeit in die Herzen seiner Kollegen im Development geschlichen. Wäre nicht ausgerechnet Gandhi sein Vorbild, würde er von dort aus daran arbeiten, seinen geheimen Plan, erst die Abteilung und dann die Weltherrschaft an sich zu reißen, zu realisieren - tut er aber nicht. Stattdessen beschreitet er mit der Arbeit an Icinga Web 2 bei uns friedliche Wege.