Kategorie: IT

Veröffentlicht am

Synology – Dateisystemmigration ext4 zu Btrfs

Ich übernehme keine Verantwortung für diese Anleitung. Ihr handelt auf eigene Gefahr! Erstellt in jeden Fall vorher ein Backup der kompletten Synology.

Dies ist eine einfache Möglichkeit vom Dateisystem ext4 zu Btrfs zu wechseln, ohne Neustart durchführen zu müssen. Ich gehe von einer Diskstation mit zwei Festplatten aus welche als RAID-Typ SHR (Synology Hybrid RAID) eingerichtet sind. Folgende Schritte sind dazu notwendig:

  1. Datensicherung vom Synology mit „Hyper Backup“ erstellen (Alle Daten inkl. Anwendungen).
  2. Festplatte 1 ziehen und an einem PC formatieren.
  3. Festplatte 1 wieder einstecken und einen neuen Speicherpool mit RAID-Typ SHR und Dateisystem Btrfs auf dieser Festplatte erstellen.
  4. Nun die einzelnen Freigaben über die „Systemsteuerung“ -> „Gemeinsame Ornder“ einzeln von Volume1 auf Volume2 migrieren. Dies kann nur hintereinander pro Freigabe durchgeführt werden und dauert je nach Datenmenge eine Weile.
  5. Wenn alle Daten migriert sind, dann Festplatte 2 ziehen und an einem PC formatieren.
  6. Alle Anwendungen über das „Paket-Zentrum“ reparieren. Ich konnte meine installierten Anwendungen nacheinander reparieren (auch „Hyper Backup“ welche gleich benötigt wird) bis auf die „PhotoStation“ – dazu später mehr!
  7. Den alten als „abgestürzt“ angezeigten Speicherpool nun löschen. Seid hier vorsichtig und überlegt 2x ob Ihr auch den richtigen erwischt habt 🙂
  8. Festplatte 2 wieder einstecken und den Speicherpool vom RAID-Typ SHR und Dateisystem Btrfs auf diese Festplatte erweitern (Festplatte dem Speicherpool hinzufügen). Nun wird das RAID initialisiert und synchronisiert. Dieser Vorgang dauert…
  9. Ab diesem Zeitpunkt konnte ich auch die „PhotoStation“ ohne Probleme wieder installieren.
  10. Nun mittels „Hyper Backup“ die einzelnen Anwendungen wiederherstellen.
  11. Das wars… Das Synology NAS ist nun auf Btrfs migriert und die Vorteile wie z.B. Snapshots etc. können genutzt werden.

Ich habe auf diese Weise eine Migration durchgeführt, welche einwandfrei funktionierte.

Veröffentlicht am

Check_MK Windows Zertifikatsprüfung

Die immer häufigere Anbindung von LDAPS (siehe frühere Beiträge) führt unter anderem zu dem Problem, dass die exportierten Zertifikate unbemerkt nach einer Weile auslaufen.

Um dies zu verhindern, kann man mit Check_MK die Windows Zertifikate, welche für die LDAPS Anbindung verwendet werden, überwachen.

Folgendes Skript auf dem entsprechenden Domaincontroller im Pfad „C:\ProgramData\checkmk\agent\local\windows_zertifikate_pruefen.ps1“ speichern:

# Zertifikate in cert:\LocalMachine\My\ suchen welche in 14 Tagen auslaufen

$zertifikatsabfrage = Get-ChildItem cert:\LocalMachine\My\ -recurse -ExpiringInDays 14 | Select-Object -property Subject

if($zertifikatsabfrage){
	# Ausgabe falls Zertifikate ablaufen:
	Write-Host '1 DMC-Zertifikate - Zertifikat: ' $zertifikatsabfrage
}
else{
	 # Ausgabe falls keine Zertifikate ablaufen:
	 Write-Host '0 DMC-Zertifikate - Keine Zertifikate zum verlaengern.'
}

Danach den Server über Check_MK neu inventarisieren. Ab jetzt kann man sich rechtzeitig um die ablaufenden Zertifikate kümmern.

Veröffentlicht am

Check_MK LDAP Anbindung über SSL (LDAPS)

Es wird vorausgesetzt, dass eine funktionierende LDAP Verbindung besteht. Um diese zu bearbeiten, im WATO Menü zu folgendem Punkt navigieren: „Users“ → „LDAP connections“
Dann die gewünschte LDAP Verbindung auswählen.

Hier müssen folgende Punkte ergänzt werden:

  • LDAP Server: Vollständigen Servernamen eintragen (nicht die IP-Adresse, da sonst das Zertifikat nicht übereinstimmt)
    Tipp: Bei mehreren Servern entweder alle Zertifikate bekannt machen (s.u.) oder einen Server fix auswählen, von dem das Zertifikat bekannt gemacht wird. Hier muss jeder selbst die Ausfallsicherheit entscheiden.
  • TCP Port: 636
  • Use SSL: Haken setzen
  • Alle anderen Parameter bleiben gleich wie bei LDAP ohne Verschlüsselung.

Ein Windows-Zertifikatsexport habe ich bereits hier beschrieben.

Dieses Zertifikat muss auf dem Linuxserver bekannt gemacht werden:

mv dmc_certificate.cer /usr/local/share/ca-certificates/dmc_certificate.crt
update-ca-certificates
systemctl restart apache2

Nun sollte sich Check_MK per LDAPS mit dem Active Directory Server verbinden.

Veröffentlicht am

Nextcloud LDAP Plugin über SSL (LDAPS)

Damit Nextcloud mit dem Active Directory Server über LDAPS spricht, sind nur wenige Schritte durchzuführen.

Folgende Punkte vorausgesetzt:

  • Laufende Nextcloudinstanz
  • Paket „ldap-utils“ installiert.
  • Plugin „LDAP user and group backend “ installiert.
  • Nextcloud LDAP Verbindung bereits über LDAP (TCP Port 389) konfiguriert.

Als erstes muss sicher gestellt sein, dass der Nextcloudserver mit dem Active Directory Server über TCP Port 636 eine Verbindung herstellen kann.

telnet <DNS/IP-Adresse AD-Server> 636

Hier darf kein Verbindungsfehler entstehen.

Auf dem AD-Server wird nun eine MMC mit dem Snap-In „Zertifikate“ -> „Computerkonto“ -> „Lokalen Computer“ hinzugefügt.
Dort wird das öffentliche Serverzertifikat „Ausgestellt für“ -> „FQDN des Domaincontrollers“ unter „Eigene Zertifikate“ als Base-64 exportiert.

Das Zertifikat wird auf dem Nextcloudserver unter „/etc/ssl/certs/dmc_certificate.crt“ gespeichert.

In der „/etc/ldap/ldap.conf“ muss jetzt das Zertifikat eingetragen werden:

TLS_CACERT      /etc/ssl/certs/dmc_certificate.crt

Wenn mehrere Domaincontroller im Einsatz sind, kann man die Zertifikate aller einzeln exportieren und nacheinander in die „/etc/ssl/certs/dmc_certificate.crt“ eintragen.
Den nachfolgenden Schritt einfach für alle Domaincontroller wiederholen (jeweils die selben Einstellungen verwenden und nur den Hostnamen abändern).

Nun können in der Nextcloud Weboberfläche im LDAP Plugin folgende zwei Anpassungen durchgeführt werden:

  • Host: ldaps://<AD Server>
  • Port: 636

Jetzt sollte sich die Nextcloud per LDAPS mit dem Active Directory Server verbinden.