Admins Log

Ein Kollege kam heute zu mir und meinte, der Datendurchsatz von einem Server sei grottenlahm.
Ich also in den Serverraum und nach dem Server geguckt, weil ich dachte, der würde an einen lahmen 100MBit-Switch hängen. Tat die Kiste aber nicht. War ein GBit-Switch.
Also zum Rack gegangen, wo unsere Hauptswitches sind und siehe da: Die Verbindung von dem Rack, wo der "lahme" Server eingebaut ist, zum Hauptswitch endete in einem 100MBit-Switch (die sind bei uns im Hauptrack alle gestapelt). Eine typische Altlast!
Also Kabel gezogen und in den GBit-Switch gestöpselt.

Als Test ein paar große Dateien von dem Server runtergeladen und siehe da: Keine Datenlandstrasse mehr, sondern mit Vollgas über die Datenautobahn!

Den Kollegen (und die anderen auch) wird es freuen!

Von Servern der Bundespolizei wurden einige interessante Daten heruntergeladen und im WWW veröffentlicht. Das ist jetzt erst mal eigentlich keine Schlagzeile wert, aber interessant ist, wieso von Behördenservern Daten runtergeladen werden konnten. Der Schlüssel: XAMPP!

Zur Erklärung:

XAMPP ist eine Distribution von Apache, MySQL, PHP und Perl, die es
ermöglicht diese Programme auf sehr einfache Weise zu installieren.

So geschrieben auf der Webseite zu XAMPP. Ich habe mir XAMPP nicht angesehen, aber wenn bei der Bundespolizei inkompetente Vollidioten rumbasteln, dann steht da bestimmt alles offen, wie ein Scheunentor.
Wenn also die Bundespolizei jetzt rumheult, dann sollte ein Richter da mal aufräumen, denn schliesslich bekommt man ja auch grossen Ärger, wenn man seine Haustür offen lässt!
Aber wie so oft hat keiner die Eier und gesteht einen Fehler ein. Und Lehren werden bestimmt auch nicht gezogen, die machen weiter wie bisher. Streng nach Vorschrift.

Weil es mir auf den Keks ging, bei neuen Mailusern in meinem Mailsystem, bestehend aus Postfix und Cyrus, zunächst die User in der saslauthdb und im System anzulegen, dann zum Cyrus zu wechseln, um dort die Mailboxen zu erzeugen, habe ich mein Mailsystem in den letzten Tagen umgebaut.
Jetzt werkelt eine PostgreSQL Datenbank zur Benutzerverwaltung. Dazu habe ich dem saslauthd dann PAM beigebracht und in /etc/pam.d/ die Dateien imap, pop und smtp angelegt, die zunächst gucken, ob der User im System vorhanden ist und dann in der DB nachguckt, sollte PAM im System nicht fündig werden. Die Dateien sehen alle so aus:

#  First we look in the system database
auth    sufficient pam_unix.so
account sufficient pam_unix.so

# Then we look in the database
auth required pam_pgsql.so user=dbuser passwd=secret host=localhost db=dbtable table=accountuser usercolumn=username passwdcolumn=password crypt=1 logtable=log logmsgcolumn=msg logusercolumn=user loghostcolumn=host logpidcolumn=pid logtimecolumn=time
account sufficient pam_pgsql.so user=dbuser passwd=secret host=localhost db=dbtable table=accountuser usercolumn=username passwdcolumn=password crypt=1 logtable=log logmsgcolumn=msg logusercolumn=user loghostcolumn=host logpidcolumn=pid logtimecolumn=time

Der Umstand, dass zuerst im System nachgeguckt wird, liegt in der Vergangenheit. Es war zunächst ein privates System, was sich aber inzwischen geändert hat.

Als Verwaltungswerkzeug für Maildomains und Mailadressen, nutze ich web-cyradm.
Das muss ich mir noch ein wenig anpassen, da ich als Webmailer Roundcubemail einsetze und es gerne hätte, wenn bei den Benutzern der richtige Name erscheint.

So langsam jedenfalls wird die Arbeit einfacher.

Von gestern Abend, ca. 18:15, bis heute Vormittag 10 Uhr war der Server down. Pings gingen zwar noch, aber es konnte kein Daemon auf der Kiste erreicht werden.
Der Rechner hatte schon vorher Probleme mit dem RAM gehabt und bis jetzt hat der Hoster immer nur den Rechner neu gestartet. Heute Abend werde ich mal schauen, was in den Tickets steht.

Schlecht fand ich die Kommunikation zwischen Support und mir als Kunden. Ich wurde zwar informiert, dass das Ticket an die "Fachabteilung" weitergegeben wurde, danach war aber Funkstille. Zumindest eine kurze Wasserstandsmeldung hätte der Support durchgeben können.

Nun ja, der Rechner läuft ja wieder. Vorerst

So langsam gehen mir die Chinesen auf den Sack!
Heute hat so ein chinesischer Vollhorst versucht, den Telefonserver lahmzulegen. Der Rechner wurde mit massig SIP-Requests bombardiert, sodass der Server kaum noch erreichbar war. Quelladresse war die IP-Adresse 120.193.1.229, die zur China Mobile Communications Corporation gehört.
Das Skript, das der Schwachkopf eingesetzt hat, muss aber recht dumm sein, denn mit Hilfe eines Rubyskriptes, dass ich hier gefunden habe, war der Spuk schnell wieder vorbei. Generell scheint es aber bei meinem Serverbetreiber im Moment so zu sein, dass viele Anfragen durch die Router laufen, denn der Server ist immer noch sehr langsam erreichbar, obgleich auf dem Interface kaum Daten ankommen oder abgehen.

Ich mache da jetzt erst mal kein weiteres Fass auf, denn pünktlich zum Haiespiel war der Telefonserver ja wieder erreichbar.

Vergangene Woche ist mir ein Server mit einer Datenbank gecrasht.

Die Daten habe ich zunächst extern auf eine andere Festplatte geschrieben und dann habe ich nach und nach die Daten wieder restauriert. Heute nachmittag hatte ich dann etwa 95% der Daten wieder hergestellt. Den Rest gebe ich verloren, was aber nicht weiter tragisch ist, da es alte, archivierte Daten waren.

Uih! Heute sind bei einem Backupsystem zwei Festplatten gecrasht! Da über mehrere Platten ein LVM lag, hat es wohl eine Menge Daten zerlegt. Das Backup war jetzt nicht so übermässig wichtig (sonst hätten wir keine Platten verwendet), aber ärgerlich ist es doch.

Mal gucken was ich von den Daten noch retten kann.

Einen neuen Server in Betrieb zu nehmen, ist eigentlich bei uns nichts weltbewegendes, aber die Aufgabe dieses Servers ist eine besondere: Er gehört zu einer (noch kleinen) Gruppe von Servern, die mit OpenVZ, bzw. Proxmox laufen.
Der neue Server nutzt aber das sog. "Bonding", d.h. die Bündelung mehrerer Netzwerkinterfaces. Eigentlich wollte ich Round Robin verwenden, aber als ich der Bridge von OpenVZ eine IPv6-Adresse zugewiesen hatte, konnte ich eben jene nicht anpingen. Per IPv4 lief alles wunderbar. Nach einiger Zeit kam ich dann darauf, einen anderen Modus zu verwenden und als ich mit dem Modus "balance-alb" unterwegs war, lief alles wunderbar.
Der Grund ist wohl im Switch zu suchen, der mit dem Round-Robin-Modus nicht klar kam.

Es ist merkwürdig: Etwa alle 100 Tage hängt sich dieser Server einfach auf. Ich glaube, ich werde per Cronjob alle 3 Monate diesen Rechner einfach mal neu starten lassen.

Das habe ich noch nie erlebt:
Ein Kollege von mir jagt so viele Daten durch das Netzwerkinterface eines unserer Server, dass sogar ssh Timeouts wirft, während man versucht, auf dem Server was zu machen.

Vielleicht sollte ich Gigabit überspringen und direkt Glasfaserkabel verlegen

[Update]
Das Netzwerkinterface war auf 10 MBit und half duplex eingestellt. Mit 100 MBit und full duplex lässt es die Kiste wieder richtig krachen.