IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Schlagwort: Sysadmin (Seite 8 von 12)

IPv6 – Neighbor Discovery – Openindiana – Solaris 11 – Opensolaris

Veraltet: Dieser Beitrag bezieht sich auf IPv6 Neighbor Discovery unter Solaris/OpenIndiana. Das Konzept (NDP statt ARP) gilt weiterhin, die gezeigten Befehle sind aber Solaris-spezifisch. Unter Linux: ip -6 neigh show.

Damit IPv4 im Ethernet funktioniert braucht man das ARP (Address Resolution Protocol) als Unterbau. Denn sonst würden die IPv4 Pakete ja ihren Weg nicht zur richtigen Netzwerkkarte finden. ARP und IPv4 sind dabei völlig unabhängige Protokolle, sie arbeiten nur seit Jahrzenhten Hand in Hand. Das vergessen viele schnell.

Möchte man also nun herausfinden welche MAC Adresse das System (im gleichen Ethernet-Netzwerk) hat, mit welchem man sich gerade unterhält… Ja, dann bemüht man das ARP.

Unter Linux:

$ arp
Address                  HWtype  HWaddress           Flags Mask            Iface
errorgrab.kernel-error.  ether   00:ff:c9:05:01:c7   C                     enp2s0
wurstsuppe.kernel-error. ether   50:ff:5d:85:73:48   C                     enp2s0

Unter Openindiana/Solaris 11:

$ arp -a
Net to Media Table: IPv4
Device   IP Address               Mask      Flags      Phys Addr
------ -------------------- --------------- -------- ---------------
rge0   router.kernel-error      255.255.255.255          00:ff:42:72:2b:a6
rge0   192.168.1.31         255.255.255.255          00:ff:b0:ae:0b:eb
rge0   sebastian-solaris.kernel-error 255.255.255.255 SPLA     80:ff:73:4a:38:c7
rge0   all-routers.mcast.net 255.255.255.255 S        01:ff:5e:00:00:02

Bei IPv6 schaut es nun etwas anders aus. Man könnte sagen, hier wurde ARP direkt mit in IPv6 integriert. Es findet sich im Neighbor Discovery wieder. Möchte man hier seine „Nachbarn“ sehen klappt es so:

Unter Linux:

$ ip -6 neigh show
fe80::1 dev enp2s0 lladdr 50:ff:5d:85:73:48 router STALE
fe80::2ff:c9ff:fe05:1c7 dev enp2s0 lladdr 00:ff:c9:05:01:c7 router REACHABLE

Unter Openindiana/Solaris 11:

$ netstat -pf inet6

Net to Media Table: IPv6
 If   Physical Address    Type      State      Destination/Mask
----- -----------------  ------- ------------ ---------------------------
rge0  33:33:ff:00:00:01  other   REACHABLE    ff02::1:ff00:1             
rge0  00:ff:42:72:2b:a6  dynamic REACHABLE    router.kernel-error
rge0  33:33:00:00:00:01  other   REACHABLE    ff02::1                    
rge0  33:33:00:01:00:02  other   REACHABLE    ff02::1:2                  
rge0  33:33:ff:00:00:06  other   REACHABLE    ff02::1:ff00:6             
rge0  33:33:ff:10:98:82  other   REACHABLE    ff02::1:ff10:9882          
rge0  33:33:ff:ad:7a:dd  other   REACHABLE    ff02::1:ffad:7add          
rge0  33:33:ff:00:00:11  other   REACHABLE    ff02::1:ff00:11            
rge0  33:33:00:00:00:16  other   REACHABLE    ff02::16                   
rge0  46:ff:91:30:98:3d  dynamic REACHABLE    2001:7d8:8001:0:ffff:bdb9:6810:9882
rge0  80:ff:73:4a:38:c7  local   REACHABLE    sebastian-solaris.kernel-error
rge0  80:ff:73:4a:38:c7  local   REACHABLE    fe80::ffff:73ff:fe4a:38c7  
rge0  00:ff:42:72:2b:a6  dynamic REACHABLE    fe80::fff:42ff:fe72:2ba6   
rge0  33:33:ff:4a:38:c7  other   REACHABLE    ff02::1:ff4a:38c7

Früher war es mit dem ARP „einfacher“. Zumindest musste man sich nur einen Befehl merken und dann halt die für das jeweilige Betriebsystem nötigen Schalter herausfinden. Mit IPv6 ist es nun mit in die jeweiligen IP-Tools gewandert. Ich halte es für sauberer auch wenn man sich nun nicht mehr mit den Befehlt „arp“ behelfen kann.

BSD und ihre Ableger nutzen „ndp„.
Bei Linux verschwindet alles in den iproute2-Tools mit dem Befehl: „ip“ (ifconfig, route, usw. usw…. alles im Tool ip)
Microsoft wirft alles in „netsh„.
Unixbasierendes hält sich ans gute alte „netstat„.

Also bis dahin…

Openindiana / Solaris 11 MAC Adresse der Netzwerkkarte anzeigen

Veraltet: Solaris und OpenIndiana werden kaum noch eingesetzt. Unter Linux: ip link show, unter FreeBSD: ifconfig.

Es ändert sich im Laufe der Zeit ja mal immer wieder etwas. So auch der Weg mit Netzwerkkarten umzugehen unter Solaris.
Wer also gerade versucht die MAC Adresse seiner lokalen Netzwerkkarte / NIC herauszufinden, dem wird folgender Command helfen:

$ pfexec dladm show-phys -m
LINK         SLOT     ADDRESS            INUSE CLIENT
rge0         primary  80:ee:73:4a:38:c7  yes  rge0

Citrix XenServer: VM fährt nicht herunter – Force Shutdown erzwingen

Veraltet: Citrix XenServer wird seit 2024 nicht mehr in dieser Form angeboten. Alternativen: Proxmox VE oder XCP-ng.

Hin und wieder bleibt beim Herunterfahren eine VM irgendwie hängen. Dann hat man über das XenCenter keine Möglichkeit mehr diese VM zum Leben zu erwecken. Damit man nun nicht den kompletten VM-Host dom0 neustarten muss, kann man erst folgenden Weg probieren.

Als erstes kann man einen force shutdown der vm probieren:

$ xe vm-shutdown –force vm=“VM-NAME“

Wenn es nicht hilft, kann man versuchen die “wartenden” pending Prozesse am XenServer zu killen:

$ xe task-list

 Dann die Prozesse abbrechen welche den Shutdown zu verhindern scheinen:

$ xe task-cancel uuid=“TASK-UUID“

 Bringt das alles nichts kann man als letztes noch folgendes probieren:

$ xe-toolstack-restart

 Nun kann man noch einmal einen force shutdown probieren. Klappt es auch nicht, muss man wohl doch den VM-Host durchstarten!

Siehe auch: Citrix XenServer Updates manuell über Bash installieren, Citrix XenServer Kernel Module automatisch beim Booten starten

Citrix XenServer local storage größer >2TB

Veraltet: Citrix XenServer wird seit 2024 nicht mehr in dieser Form angeboten. Die Storage-Konfiguration hat sich grundlegend geändert. Alternativen: Proxmox VE oder XCP-ng.

Hat man in seinem Citrix XenServer eine Festplatte welche größer ist als 2 Terabyte, egal ob logisch durch RAID oder physikalisch als echte Hardware. So wird diese vom XenServer nicht vollständig genutzt. Das liegt daran, dass der XenServer noch aufs alte Pferd MBR setzt. Der eingesetzte Kernel kann aber bereits mit GUID Partition Table (GPT) partitionierten Speichern umgehen. Alleine die mitgelieferten Boardmittel (fdisk….) können es auch nicht. Zusammengefasst bedeutet es: –    Ich kann am Citrix XenServer einen lokalen Speicher der größer ist als 2TB einbinden und benutzen. –    Ich kann diesen Speicher aber nicht anlegen 🙁 Damit wäre also nur das Problem des Anlegens zu lösen! Voraussetzung ist dass es sich dabei um eine weitere HDD handelt, also nicht die Platte auf welcher das eigentliche Hostsystem Dom0 installiert wurde. Diesen weitern Speicher schraubt man nun also in seinen XenServer. Nun bootet man diesen mit der Hilfe von Parted Magic. Dieses Livesystem ist darauf ausgelegt mit Platten und Partitionen umzugehen. Daher ist es selbst kein Problem auf ein bereits eingerichtetes Linux Sofwareraid zuzugreifen und es bringt das Programm gparted mit. Gparted wird nun die Hauptarbeit übernehmen, denn es ist schon länger in der Lage GUID Partition Tables (GPT) anzulegen.   Festhalten, es geht los… –    gparted öffnen –    den >2TB Datenspeicher auswählen Cirtix Xen Server local Storage lokaler Speicher bigger 2TB groesser 2TB GUID GPT –    über den Menüpunkt Device den Unterpunkt Create Partition Table auswählen  Cirtix Xen Server local Storage lokaler Speicher bigger 2TB groesser 2TB GUID GPT –    unter Advanced den Type der neuen Partitionstabelle auf gpt setzten und (Warnung beachten) anwenden –    den neuen unallocated Speicher markieren Cirtix Xen Server local Storage lokaler Speicher bigger 2TB groesser 2TB GUID GPT –    über den Menüpunkt Partition den Unterpunkt New auswählen Cirtix Xen Server local Storage lokaler Speicher bigger 2TB groesser 2TB GUID GPT –    nun den File system Type auf lvm2 pv setzten und Hinzufügen Cirtix Xen Server local Storage lokaler Speicher bigger 2TB groesser 2TB GUID GPT –    Abschließend noch diese Änderungen anwenden über den Button Apply Jetzt haben wir eine GUID Partitionstabelle auf der großen Festplatte mit einer Partition größer 2TB und diese bereits mit dem Dateisystem Logical Volume Manager (LVM). Nun können wir wieder den Citrix XenServer booten und ihn mit seinem neuen 3TB oder 4TB oder was weiß ich Storage bekannt machen. Nachdem der XenServer hochgefahren ist melden wir uns als Root auf der Shell an. Um den Speicher nutzbar zu machen genügen nun zwei kleine Befehle:
$ pvcreate /dev/sda1
$ xe sr-create type=lvm content-type=user device-config:device=/dev/sda1 name-label="4TB-SPEICHER"
 Ab jetzt ist der Store wie jeder andere nutzbar.
* U-P-D-A-T-E * Zusammen mit gdisk lassen sich nun auch GPT Partitionen anlegen.

Siehe auch: Citrix XenServer Updates manuell über Bash installieren, XenServer mit Nagios überwachen, XenServer Linux Softwareraid

Windows Server Backup mit Nagios überwachen

Die Windows Server-Sicherung (ab Server 2008) lässt sich über die Management Console bequem einsehen. Aber wer schaut da täglich rein? Ich wollte das über Nagios überwachen und habe dafür ein PowerShell-Script geschrieben.

Die Idee

Auf den zu überwachenden Systemen ist jeweils eine Vollsicherung (Bare Metal) eingerichtet, die ein- bis mehrmals am Tag startet. Mich interessiert nur eine Frage: Wann war die letzte erfolgreiche Sicherung, und ist diese älter als drei Tage? Warum, weshalb, wo, wie, was — ist mir im ersten Schritt egal. Ich will nur informiert sein, wenn es keine aktuelle Datensicherung gibt.

Windows Server-Sicherung in der Management Console

Das Script

Das PowerShell-SnapIn Windows.ServerBackup liefert über Get-WBSummary eine Zusammenfassung der Sicherungen. Unter LastSuccessfulBackupTime steht das Datum der letzten erfolgreichen Sicherung.

Das Script vergleicht dieses Datum mit dem aktuellen: Ist die Sicherung von heute oder gestern, gibt es OK zurück. Bei zwei bis drei Tagen eine Warnung. Älter als drei Tage bedeutet CRITICAL. Zusätzlich erkennt es, ob die Befehlszeilentools nicht installiert sind und ob eine Sicherung über einen Tageswechsel hinweg noch läuft.

Download: backuptest.ps1 (aktuelle Version 0.3)

Voraussetzungen

Über den Server-Manager muss unter Windows Server-Sicherungsfeatures das Feature Befehlszeilentools installiert sein. Ohne das SnapIn gibt es beim Start des Scripts eine Fehlermeldung. Außerdem muss die Execution Policy angepasst werden:

Set-ExecutionPolicy RemoteSigned
Server-Manager: Windows Server-Sicherungsfeatures mit Befehlszeilentools

NSClient++ einrichten

Das Script nach C:\scripte\ legen. Im NSClient++ die NRPE-Konfiguration erweitern. Der Aufruf eines PowerShell-Scripts über NSClient++ sieht beim ersten Hinschauen etwas seltsam aus:

[NRPE Handlers]
command[check_windowsbackup]=cmd /c echo C:\scripte\backuptest.ps1 | powershell.exe -command -

Dazu muss NSClient++ natürlich als NRPE-Server konfiguriert sein:

[modules]
NRPEListener.dll
NRPEClient.dll

[NRPE]
port=5666
command_timeout=120
allowed_hosts=1.2.3.4
socket_timeout=120

Testen

Nach einem Neustart des NSClient++-Dienstes kann man vom Nagios-System aus testen:

$ check_nrpe -H 4.3.2.1 -p 5666 -t 120 -c check_windowsbackup
OK: Backup von gestern
Nagios-Webinterface: Windows Server Backup Check zeigt OK

Die restliche Einrichtung in Nagios (Service, Host, Command) ist Standard.

Fragen? Einfach melden.

MOTDstat

Habe ich überhaupt schon von meinem neusten Lieblingsgimmik berichtet? Nein? Nö nö nö….. Es nennt sich MOTDstat und „ersetzt“ die bekannte Message of the Day.

Im Grunde ist es ein kleines bash Script welches einem ausgewählte Systeminformationen beim Login anzeigt. Es hat sogar die Möglichkeit einem im Fall der Fälle eine E-Mail zu schicken, dieses überlasse ich dann aber doch lieber Nagios.

Nach dem Download installiert sich alles fast von allein.

$ make install

Damit alles regelmässig aktualisiert wird folgt man am besten dem Vorschlag der README und wird den folgenden Aufruf in seine crontab.

$ crontab -e
*/5 * * * * root /usr/bin/motdstat --generate 1>/dev/null 2>/dev/null

Damit wird der Zustand alle 5 Minuten aktualisiert und alle Infos zum CronJob landen im Nirwana!

Bei einem motdstat -g schiebt MOTDstat die eigentliche Datei /etc/motd in /etc/motd.ori und wirft den generierten Systemzustand in /etc/motd. Bei einem neuen Login wird diese nun gefolgt von der /etc/motd.ori augegeben. Testen lässt sich dieses mit einem:

$ motdstat -s

Einstellungen zum Script lassen sich unter /etc/motdstat vorneheme. Da ich meine Message of the Day so oder so immer anfasse um dort möglichst auffällig den Systemnamen erscheinen zu lassen (ich komme sonst mal schnell durcheinander), passt es ganz gut dazu. Es kann natürlich keine echte Überwachung ersetzten,ist aus meiner Sicht denn noch ein ganz nettes „Programm“.

So long…..

 

 

Fragen? Einfach melden.

Linux und die UUID

Ich bin inzwischen ja von ZFS schon sehr verwöhnt… Vor allem was so Dinge angeht sich Kombinationen aus Laufwerk, Partition, Mountpunkt und SATA-Port zu merken. Man denkt einfach nicht mehr darüber nach 🙁 Heute bin ich damit mal wieder auf die Nase gefallen. Ok ok…. Natürlich kann man zur Konfiguration auch einfach die UUID nutzen, diese ist dann eindeutig und man kann ähnlich wie bei ZFS die ganzen Zusammenhänge „vergessen“….. Ich finde die UUID-Geschichte aber anstrengend. Diese viel zu lange Nummer zu tippen geht überhaupt nicht, sich diese erst in Konfigurationsfiles zu schieben und dann…. bäääähhhh. Dann kann ich mir die Nummer auch nur wieder schlecht merken.

Wie auch immer. Der Ansatz ist gut und wenn es Konfiguriert ist, geht es ja auch. Um mir nicht noch ein Komando mehr merken zu müssen friemel ich die Zuordnung UUID ==> Devicename immer wie folgt heraus:

ls -Al /dev/disk/by-uuid/
insgesamt 0
lrwxrwxrwx 1 root root 10 17. Sep 11:26 0e6894c5-1dfd-4fcb-8cc4-12290c28c3dc -> ../../sdb3
lrwxrwxrwx 1 root root 10 17. Sep 11:26 11cc385c-7fcc-4b87-88b9-ebe05af67df8 -> ../../sda1
lrwxrwxrwx 1 root root 10 17. Sep 11:26 2fc86b49-ad36-4755-bd72-aba0ec54f2e4 -> ../../sdb2
lrwxrwxrwx 1 root root 10 17. Sep 11:26 ca266482-0623-43a1-8741-70f8de485023 -> ../../sdb1

Jemand eine bessere Idee? In diesem Sinne….

Fragen? Einfach melden.

SSH Host Keys per SSHFP im DNS veröffentlichen

SSH-Host-Key-Prüfung per SSHFP im DNS mit DNSSEC-validiertem Fingerprint, OpenSSH-Client, Server-Host-Key und Schutz vor Man-in-the-Middle-Angriffen.

OpenSSH kann die Fingerprints seiner Host Keys als SSHFP-Records im DNS veröffentlichen. Beim Verbindungsaufbau prüft der Client dann automatisch, ob der Fingerprint des Servers mit dem DNS-Eintrag übereinstimmt, ein wirksamer Schutz gegen Man-in-the-Middle-Angriffe. Ist die Zone zusätzlich per DNSSEC gesichert, kann der DNS-Record selbst nicht gefälscht werden. Die Spezifikation steht in RFC 4255.

Client konfigurieren

Damit OpenSSH beim Verbindungsaufbau SSHFP-Records prüft, muss VerifyHostKeyDNS aktiviert werden. Global für alle Benutzer in /etc/ssh/ssh_config:

VerifyHostKeyDNS yes

Oder nur für die aktuelle Sitzung:

ssh -o "VerifyHostKeyDNS=yes" server.example.de

SSHFP-Records erzeugen

Am einfachsten direkt auf dem Server mit ssh-keygen, das erzeugt die fertigen DNS-Records für alle vorhandenen Host Keys:

ssh-keygen -r server.example.de.

Ausgabe (Beispiel mit RSA, ECDSA und Ed25519):

server.example.de. IN SSHFP 1 1 47890eecc9a2893061734b07b8f60caa1a856148
server.example.de. IN SSHFP 1 2 b2518ad49cc2adf517d3f6a9faaf4017abc2c3e3...
server.example.de. IN SSHFP 3 1 3dd9de0dcf1523341b45a53f1d57043609e26c62
server.example.de. IN SSHFP 3 2 e1c76bd66b5a0641789b0b37be5b80ae3f6395c1...
server.example.de. IN SSHFP 4 1 a1b2c3d4e5f6...
server.example.de. IN SSHFP 4 2 d4e5f6a7b8c9...

Aufbau des SSHFP-Records

Ein SSHFP-Record besteht aus zwei Zahlen und dem Fingerprint:

hostname IN SSHFP [Algorithmus] [Hash-Typ] [Fingerprint]

Algorithmus:

  • 1, RSA
  • 3, ECDSA
  • 4, Ed25519 (empfohlen, ab OpenSSH 6.7)

DSS (2) ist seit OpenSSH 7.0 standardmäßig deaktiviert und sollte nicht mehr verwendet werden.

Hash-Typ: 1 = SHA-1, 2 = SHA-256. Beide sollten veröffentlicht werden, ältere Clients verstehen nur SHA-1, neuere bevorzugen SHA-256.

Prüfen

Mit dig lässt sich prüfen, ob die Records im DNS angekommen sind:

dig +short server.example.de SSHFP
1 1 47890EECC9A2893061734B07B8F60CAA1A856148
1 2 B2518AD49CC2ADF517D3F6A9FAAF4017ABC2C3E3...
3 1 3DD9DE0DCF1523341B45A53F1D57043609E26C62
4 2 D4E5F6A7B8C9...

Wichtig: Bei der DNSSEC-validierten Abfrage muss das ad-Flag (Authenticated Data) gesetzt sein, sonst ist die Antwort nicht vertrauenswürdig:

dig +dnssec server.example.de SSHFP | grep flags
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

Verbindungsaufbau mit SSHFP

Ohne SSHFP-Records im DNS meldet OpenSSH:

DNS lookup error: data does not exist
No matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?

Mit SSHFP-Records und DNSSEC:

debug1: found 4 secure fingerprints in DNS
debug1: matching host key fingerprint found in DNS

secure bedeutet: Die DNS-Antwort wurde per DNSSEC validiert. Ohne DNSSEC steht dort insecure, der Fingerprint wurde zwar gefunden, aber der DNS-Antwort selbst kann nicht vertraut werden. Für echte Sicherheit braucht man beides: SSHFP-Records und DNSSEC.

Strenge Prüfung erzwingen

Optional: OpenSSH anweisen, die Verbindung nur aufzubauen, wenn der Host Key erfolgreich validiert wurde:

Host *
    VerifyHostKeyDNS yes
    StrictHostKeyChecking yes

Damit wird die Verbindung abgelehnt, wenn kein passender SSHFP-Record gefunden wird oder die DNSSEC-Validierung fehlschlägt. Das ist die sicherste Einstellung, setzt aber voraus, dass alle Zielserver SSHFP-Records haben.

Kleiner Aufwand, viel mehr Sicherheit. Fragen? Einfach melden.

ZFS Scrub: Integritätsprüfung starten, stoppen und überwachen

Ein Scrub ist die Integritätsprüfung von ZFS — jeder Block im Pool wird gelesen und seine Checksumme verifiziert. Beschädigte Blöcke werden automatisch aus der Redundanz repariert (Mirror oder RAID-Z). Ohne Redundanz erkennt ZFS den Fehler immerhin, kann ihn aber nicht korrigieren.

Empfehlung: Einmal pro Woche oder mindestens einmal im Monat. Auf Produktivsystemen am besten per Cronjob.

Scrub starten

zpool scrub backup

Fortschritt prüfen

zpool status backup
  pool: backup
 state: ONLINE
  scan: scrub in progress since Sun May 27 11:11:00 2012
        4.20G scanned out of 74.5G at 102M/s, 0h11m to go
        0 repaired, 5.64% done

Scrub abbrechen

Braucht man die I/O-Leistung gerade für etwas anderes:

zpool scrub -s backup

Im Status sieht man dann den Unterschied — stopped statt completed:

# Abgebrochen
scan: scrub stopped after 0h7m with 0 errors on Sun May 27 11:18:52 2012

# Normal beendet
scan: scrub completed after 0h7m with 0 errors on Sun May 26 10:52:13 2012

Ein abgebrochener Scrub setzt beim nächsten Start nicht dort fort, sondern beginnt von vorne.

Scrub per Cronjob

# Jeden Sonntag um 02:00 alle Pools scrubben
0 2 * * 0 /sbin/zpool scrub backup

Unter FreeBSD läuft der Scrub standardmäßig über periodic daily — dort muss man nichts extra einrichten. Unter Linux gibt es je nach Distribution einen systemd-Timer (zfs-scrub-weekly.timer) oder man legt den Cronjob selbst an.

Mehr zu ZFS: ZFS RAID: Mirror und RAID-Z und ZFS Snapshots. Fragen? Einfach melden.

DNS konfigurieren um die XMPP Information zu verteilen

Warum vergessen nur immer alle die DNS Informationen zu ihrem neuen Jabber-Server zu setzten? Ich bin heute sicher zum 12 mal nach einem Problem gefragt worden welches damit zusammen hing. Die Info fehlt aber auch in _fast_ jedem Howto. Kopieren denn wirklich alle nur noch Zeile für Zeile? Als Wikipedia mal einen Tag ausgesetzt hat, konnten tausende keine Hausaufgaben abgeben. Irgendwie habe ich dass Gefühl, wenn Google mal einen Tag aussetzten würde könnten tausende „Admins“ nichts installieren oder Probleme lösen ;-P

Also um es noch mal in Google zu werfen:

Damit die Kommunikation zwischen den Jabber-Server sauber läuft müssen die nötigen DNS Records vorhanden sein. Für meinen Bind schaut es so aus wie im folgenden Beispiel:

_jabber._tcp.jabber.kernel-error.de.       IN SRV   0 0 5269   jabber.kernel-error.de.
_xmpp-server._tcp.jabber.kernel-error.de.  IN SRV   0 0 5269   jabber.kernel-error.de.
_xmpp-client._tcp.jabber.kernel-error.de.  IN SRV   0 0 5222   jabber.kernel-error.de.

Testen lässt sich dieses am Ende natürlich mit dig:

$ dig SRV _xmpp-server._tcp.jabber.kernel-error.de +short
0 0 5269 jabber.kernel-error.de.

$ dig SRV _xmpp-client._tcp.jabber.kernel-error.de +short
0 0 5222 jabber.kernel-error.de.

Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑