Nachdem aufgrund eines 'unausgereiften' Backup Prozesses (ich hasse Plesk - hier noch 9.2.3 :-& ) die Platte übergelaufen ist (disk quota exceeded auf einem 1und1 vserver mit Suse 10.3 - ja ich weiss, update des Servers ist bestellt, den jetzigen bekommt man nicht mit einem anderen (Suse) Image..) werde ich die folgende Fehlermeldung in Postfix (/var/log/mail.warn) nicht mehr los:
/usr/sbin/cron[24547]: (root) CMD (/usr/lib64/plesk-9.0/postfix-poplockdb-clean)
poplock DB cleanup[32055]: started
poplock DB cleanup[32055]: fatal error: postmap: fatal: open database /var/spool/postfix/plesk/poplock.db: Bad file descriptor
Die Datei ist 0 byte gross und war zum Zeitpunkt des Plattenproblems geöffnet.
Postfix tut seinen Dienst und hätte ich kein Logfile, hätte ich wahrscheinlich auch kein Problem....hab ich nun aber.... 8-[
Ich kann mir leider meine Zeit nicht so frei einteilen und der Tag hat nur 24 Stunden daher wird das dann noch 6 bis 8 Wochen warten müssen aber prinzipiell hast Du natürlich Recht.
„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.
Die Reste sind beseitigt und selbst VPS hat gestern mittag wieder (allerdings unaufgefordert....) angefangen, ein neues Full Backup anzulegen (23GB Full in etwa 40 Min.) und ist diesmal nicht in einen timeout gelaufen (das hatte ich schon reklamiert da 1und1 die Container anscheinend default auf 3600 stehen hat).
Ich habe also wieder genug Platz, aber weil es eben nicht Windows ist, dachte ich noch nicht an einen Reboot des Servers. Einzig syslog habe ich nach dem Vorfall neu gestartet und alle anderen Services laufen ja auch wie sie sollen (selbst Postfix tut seinen Dienst, abgesehen von der Fehlermeldung im Log).
Aber natuerlich kann ich den Server neu booten. Der ist ja erst seit dem 01.11.09 up und insgesamt ist es der 2.te Reboot überhaupt.
Ich verbringe am Tag mehr als 30 Minuten mit meinem Server und logdigest ist mir ebenfalls ein Begriff. Ich denke, daß ich meinen root-Server mit der genügenden Sorgfalt betreibe aber auch ich mache das nicht hauptberuflich.
Ich will hier keine Grundsatz Diskussion anstossen. Nach Deinem Maßstab müsste man vermutlich 95% aller Rootserver abklemmen weil sich deren root nicht ausreichend kümmert (geschweige denn Ahnung hat) - und da würde ich Dir nicht widersprechen.
Es sind eher die Vorbereitungen den Umzug betreffend die mich im Moment davon abhalten heute Abend schon damit anzufangen. Genau wie Du sagst muss man vorher sehr genau prüfen, was in der neuen Umgebung angepasst werden muss und der Teufel steckt bekanntlich im Detail.
Wenn es bei 1und1 ein Image mit OpenSUSE 11 für den vserver geben würde, hätte ich den Server schon initialisiert. Seltsamerweise haben Sie für den vserver Bedenken -deswegen gibt es nur ein 10.3 Image-, beim Cloudserver bieten sie es allerdings an (11.1 glaube ich).
Muss ich das verstehen? Nein. Muss ich damit leben? Im Moment jedenfalls, ja. Bin ich damit zufrieden? Nein.
Ich versuche jedenfalls zu verstehen was mit Postfix falsch gelaufen ist und lasse das log nicht nach /dev/null schreiben.
An postmap habe ich auch gedacht aber es gibt keine poplock.irgendwas aus der die poplock.db erstellt wird (anders als bei transport, smtp_auth etc.). Aber ich werde mir mal die Admindoku vornehmen.
Bzgl: Image: Es gibt für keinen 1und1 vServer ein 11.x Image. Beim Cloudserver (was ja im Prinzip auch ein vserver ist) aber schon. Wahrscheinlich aus den eben von Dir genannten Gründen: Ein neues Produkt mit einem nicht mehr gepflegten BS auszustatten macht ja auch nicht wirklich Sinn.
Da ich von einem vServer Vertrag auf einen Opencloudserver umsteige, bekomme ich dabei automatisch ein 11.x Image.
Danke für die Info.
Last edited by m.m. on 2010-02-11 13:10, edited 1 time in total.
Feb 11 13:45:01 xxx poplock DB cleanup[18412]: started
Feb 11 13:45:02 xxx poplock DB cleanup[18412]: fatal error: postmap: fatal: open database /var/spool/postfix/plesk/poplock.db: Bad file descriptor
Hmm...ich würde ja fast /etc/postfix sichern und erst postfix über den autoinstaller deinstallieren und qmail installieren - dann wieder umgekehrt zurück.
Aber das ist irgendie Windows-alike....naja, Plesk halt :-#
Vielleicht boote ich den Server mal und schaue was dabei passiert....
Ich überlege noch ob ich wie hier http://kb.parallels.com/en/5801 beschrieben den MTA mit dem Plesk autoinstaller auf qmail ändere und danach wieder auf postfix zurück gehe oder ob ich wirklich schon jetzt den Cloud bestelle....wenn, dann kann auch gleich den konfigurieren.
Am Ende vielleicht besser als jetzt mit dem autoinstaller eine ansonsten intakte Installation zu gefährden. Wenn der sich verschluckt, hab ich am Ende mehr Stress und auch nicht weniger Arbeit.
Nachdem ich Plesk noch eine Chance gegeben habe und der verbleibende Platz nicht ausreicht, die gzip Archive zu erstellen bevor sie auf ein FTP repository ausgelagert werden hat es mir gereicht: Bevor die Platte wieder zuläuft Backup abgebrochen, aufgeräumt und abgehakt (ganz davon abgesehen, daß Plesk nichts von gpg weiß...).
Kurzum: Meine Backpups erledigt nun Duply (Anm.: Der Hinweis hier im Forum auf http://www.heise.de/security/artikel/Hi ... 70834.html war schon nicht schlecht aber das Script ist noch auf duplicity 0.4.11 ausgelegt, aktuell ist aber 0.6.06 => also Duply installiert, gpg key erstellt und cronjob eingerichtet.
Wenn das erste Full-Backup auf meinem externen FTP Space durch ist, gehe ich (vielleicht) an eine Neu-Konfiguration von Postfix via Plesk. Oder ich drehe den cronjob auf
Da ich es hasse wenn ich auf der Suche nach einer Problemlösung:
1. passende Einträge in einem Forum finde die aber
2. ohne eine Problemlösung oder noch besser mit einem 'Danke, ich hab das Problem gelöst'
aufhören, möchte ich euch meine Lösug nicht vorenthalten:
Ich habe zuerst mein /etc/postfix Verzeichnis gesichert und dann wie in http://kb.parallels.com/en/5801 beschrieben den MTA erst auf qmail geändert und sofort wieder auf postfix zurückgeändert.
Dabei wurde die poplock.db neu erstellt.
@matzewe01
Ich werde meinen Server trotzdem upgraden ;)
Last edited by m.m. on 2010-02-14 17:12, edited 1 time in total.
