Update wieder rückgängig machen???

gpi

New Member
Hallo NG,

ich habe heute versehentlich ein Update auf die aktuelle SVN-Version gemacht und kann seitdem keine Email verschicken. Kann man das Update wieder rückgängig machen?

Vielen Dank

Mit freundlichen Grüßen

Günter
 

Till

Administrator
Jein, da die Datenbankstruktur an die SVN Version angepasst wurde. Du kannst es nur rückgängig machen, wenn Du ein Backup der ISPConfig Datenbank hast sowie backups von /usr/local/ispconfig, so wie im update tutorial beschrieben:

http://www.faqforge.com/linux/controlpanels/ispconfig3/how-to-update-ispconfig-3/

Eine Alternative ist es bare einfach mal zu scahuen, warum mail bei Dir nicht mehr geht. Also sieh doch mal ins mail log und poste die Fehlermeldungen.
 

gpi

New Member
Hallo Til,

leider habe ich das Verzeichnis \user\local\ispconfig nicht mitgesichtert. Von den anderen Datein/DB habe ich Sicherungen.

Welche Log-Dateien werden von Ihnen benötigt? \var\log\mail.err

Gruß

Günter
 
Zuletzt bearbeitet:

Till

Administrator
Scahu mal in die mail.log und mail.err Datei, dort müssen Fehler drin stehen wenn eine Mail ankommt und nicht zugestellt werden kann.
 

gpi

New Member
Hallo Til,


habe vor kein mailman installiert gehabt!


Hier mail.err


Jan 12 15:51:13 MyServer postfix/smtpd[5223]: fatal: open database /var/lib/mailman/data/aliases.db: No such file or directory
Jan 12 15:52:13 MyServer postfix/cleanup[5274]: fatal: open database /var/lib/mailman/data/virtual-mailman.db: No such file or directory
Jan 12 15:52:14 MyServer postfix/smtpd[5278]: fatal: open database /var/lib/mailman/data/aliases.db: No such file or directory
Jan 12 15:53:14 MyServer postfix/cleanup[5353]: fatal: open database /var/lib/mailman/data/virtual-mailman.db: No such file or directory
Jan 12 15:53:15 MyServer postfix/smtpd[5360]: fatal: open database /var/lib/mailman/data/aliases.db: No such file or directory
Jan 12 15:54:15 MyServer postfix/cleanup[5405]: fatal: open database
.......




mail.warn

Jan 12 16:28:17 MyServer postfix/master[6108]: warning: /usr/lib/postfix/smtpd: bad command startup -- throttling
Jan 12 16:29:15 MyServer postfix/cleanup[9208]: fatal: open database /var/lib/mailman/data/virtual-mailman.db: No such file or directory
Jan 12 16:29:16 MyServer postfix/master[6108]: warning: process /usr/lib/postfix/cleanup pid 9208 exit status 1
Jan 12 16:29:16 MyServer postfix/master[6108]: warning: /usr/lib/postfix/cleanup: bad command startup -- throttling
Jan 12 16:29:17 MyServer postfix/smtpd[9210]: fatal: open database /var/lib/mailman/data/aliases.db: No such file or directory
Jan 12 16:29:18 MyServer postfix/master[6108]: warning: process /usr/lib/postfix/smtpd pid 9210 exit status 1
Jan 12 16:29:18 MyServer postfix/master[6108]: warning: /usr/lib/postfix/smtpd: bad command startup -- throttling
Jan 12 16:29:59 MyServer postfix/pickup[8693]: fatal: watchdog timeout
Jan 12 16:30:00 MyServer postfix/master[6108]: warning: process /usr/lib/postfix/pickup pid 8693 exit status 1
Jan 12 16:30:00 MyServer postfix/master[6108]: warning: /usr/lib/postfix/pickup: bad command startup -- throttling
Jan 12 16:30:16 MyServer postfix/cleanup[9256]: fatal: open database /var/lib/mailman/data/virtual-mailman.db: No such file or directory
Jan 12 16:30:17 MyServer postfix/master[6108]: warning: process /usr/lib/postfix/cleanup pid 9256 exit status 1
Jan 12 16:30:17 MyServer postfix/master[6108]: warning: /usr/lib/postfix/cleanup: bad command startup -- throttling
Jan 12 16:30:18 MyServer postfix/smtpd[9258]: fatal: open database /var/lib/mailman/data/aliases.db: No such file or directory
Jan 12 16:30:19 MyServer postfix/master[6108]: warning: process /usr/lib/postfix/smtpd pid 9258 exit status 1
Jan 12 16:30:19 MyServer postfix/master[6108]: warning: /usr/lib/postfix/smtpd: bad command startup -- throttling
Jan 12 16:31:17 MyServer postfix/cleanup[9317]: fatal: open database /var/lib/mailman/data/virtual-mailman.db: No such file or directory
Jan 12 16:31:18 MyServer postfix/master[6108]: warning: process /usr/lib/postfix/cleanup pid 9317 exit status 1
Jan 12 16:31:18 MyServer postfix/master[6108]: warning: /usr/lib/postfix/cleanup: bad command startup -- throttling
Jan 12 16:31:19 MyServer postfix/smtpd[9320]: fatal: open database /var/lib/mailman/data/aliases.db: No such file or directory
Jan 12 16:31:20 MyServer postfix/master[6108]: warning: process /usr/lib/postfix/smtpd pid 9320 exit status 1
Jan 12 16:31:20 MyServer postfix/master[6108]: warning: /usr/lib/postfix/smtpd: bad command startup -- throttling
Jan 12 16:32:18 MyServer postfix/cleanup[9331]: fatal: open database /var/lib/mailman/data/virtual-mailman.db: No such file or directory
Jan 12 16:32:19 MyServer postfix/master[6108]: warning: process /usr/lib/postfix/cleanup pid 9331 exit status 1
Jan 12 16:32:19 MyServer postfix/master[6108]: warning: /usr/lib/postfix/cleanup: bad command startup -- throttling
Jan 12 16:32:20 MyServer postfix/smtpd[9333]: fatal: open database /var/lib/mailman/data/aliases.db: No such file or directory
Jan 12 16:32:21 MyServer postfix/master[6108]: warning: process /usr/lib/postfix/smtpd pid 9333 exit status 1
Jan 12 16:32:21 MyServer postfix/master[6108]: warning: /usr/lib/postfix/smtpd: bad command startup -- throttling
Jan 12 16:33:19 MyServer postfix/cleanup[9351]: fatal: open database /var/lib/mailman/data/virtual-mailman.db: No such file or directory
Jan 12 16:33:20 MyServer postfix/master[6108]: warning: process /usr/lib/postfix/cleanup pid 9351 exit status 1
Jan 12 16:33:20 MyServer postfix/master[6108]: warning: /usr/lib/postfix/cleanup: bad command startup -- throttle





Gruß


Günter
 
Zuletzt bearbeitet:

gpi

New Member

Das letzte ispconfig-Update habe ich am 30. Juli 2010 gemacht.
Das Backup der dbispconfig enthält

INSERT INTO `sys_config` VALUES (1,'db','db_version','3.0.1.3');

Was wohl bedeuten dürfte, dass vorher noch die Version 3.0.1.3 installiert war.

Leider habe ich von dem Verzeichnis:

/usr/local/ispconfig

kein Backup!

Ich habe zur Rücksicherung folgende Frage:

wenn ich am Server ein ispconfig neu installiere, indem ich die aktuelle
Version vom Server lade, sie auspacke und "php -q install.php" ausführe, sollte ja wieder eine Grundinstallation da sein, die in der Version gemischt ist.

Da würde ich die /usr/local/ispconfig sichern.

Wenn ich dann das Backup von der Datenbank und vom etc-Verzeichnis einspiele, habe ich eine etwas ältere Version einerseits und eine aktuelle stable-Version der /usr/local/ispconfig andererseits.

Dann würde ich ein ispconfig-update.sh machen und die /usr/local/ispconfig zur Sicherheit wieder aus dem Backup herstellen.

Wäre das eine Möglichkeit, wieder ein konsistenes System zu erhalten? Oder soll ich überhaupt alles neu installieren?

Vielen Dank

Günter
 
Zuletzt bearbeitet:

gpi

New Member
Ich habe das etc-Verzeichnis auf die Version vom Backup zurückgesetzt und habe jetzt natürlich die alte Datei nicht mehr, weil ich es verabsäumt habe, das Verzeichnis nach dem Update zu sichern.

Jetzt funktioniert wieder alles tadellos, aber ich habe noch die dbispconfig sowie die /usr/local/ispconfig in der svn-Version installiert. Ich schätze ich werde um auf Nummer sicher zu gehen einen neuen Server installieren und dann dort die Version 3.0.1.3 installieren, falls ich sie noch wo auftreiben kann. dann werde ich das Verzeichnis /usr/local/ispconfig auf den richtigen Server kopieren und das Backup der Datenbank einspielen. Danach sollte ich wohl wieder normal updaten können.

Mich macht nur stutzig, dass im Juli 2010 (laut /var/log/ispconfig_install.log wurde dort das lezte Update vor gestern gemacht) bereits die Version 3.0.2.2 verfügbar gewesen wäre. Also lügt entweder die Log-Datei, oder die Datenbank oder update-Skript hat damals nicht die gerade aktuelle Version installiert.

Liebe Grüße

Günter
 

Till

Administrator
Ich habe das etc-Verzeichnis auf die Version vom Backup zurückgesetzt und habe jetzt natürlich die alte Datei nicht mehr, weil ich es verabsäumt habe, das Verzeichnis nach dem Update zu sichern.

Jetzt funktioniert wieder alles tadellos, aber ich habe noch die dbispconfig sowie die /usr/local/ispconfig in der svn-Version installiert. Ich schätze ich werde um auf Nummer sicher zu gehen einen neuen Server installieren und dann dort die Version 3.0.1.3 installieren, falls ich sie noch wo auftreiben kann. dann werde ich das Verzeichnis /usr/local/ispconfig auf den richtigen Server kopieren und das Backup der Datenbank einspielen. Danach sollte ich wohl wieder normal updaten können.

das würde ich nicht machen. Lass es am besten einfach so wie es jetzt ist und aktualisiere dann später auf 3.0.4 sobald sie erscheint.

Mich macht nur stutzig, dass im Juli 2010 (laut /var/log/ispconfig_install.log wurde dort das lezte Update vor gestern gemacht) bereits die Version 3.0.2.2 verfügbar gewesen wäre. Also lügt entweder die Log-Datei, oder die Datenbank oder update-Skript hat damals nicht die gerade aktuelle Version installiert.

Wieso soll das nicht korrekt sein? Die aktuelle Version ist 3.0.3.2, es kann also durchaus sein dass 3.0.2.2 im Juli veröffentlicht worden ist.
 

gpi

New Member
das würde ich nicht machen. Lass es am besten einfach so wie es jetzt ist und aktualisiere dann später auf 3.0.4 sobald sie erscheint.

Wenn ich nicht befürchten muss, dass ich durch Änderungen, die ich in ispconfig vornehme wie z.B. eine neue Domain oder Email-Adresse hinzufügen wieder Probleme bekomme, weil das etc-Verzeichnis für eine alte Version gedacht ist, und ich mir vorstellen kann, dass womöglich irgend etwas anders gehandhabt wird, kann ich es natürlich so lassen.

Wieso soll das nicht korrekt sein? Die aktuelle Version ist 3.0.3.2, es kann also durchaus sein dass 3.0.2.2 im Juli veröffentlicht worden ist.

Auf sourceforge steht bei Version 3.0.2.2 steht unter Modified 2010-06-21. Deshalb habe ich angenommen, dass das nicht passen dürfte, was bei mir aktualisiert wurde.

Vielen Dank für deine rasche Hilfe
 

gpi

New Member
Hallo noch einmal,

ich habe jetzt noch einmal ein svn-update durchgeführt, um zu sehen, ob der Fehler dann wieder aufteten würde. Und siehe da, die var/log/mail.err liefert wieder solche Einträge:

Code:
Jan 13 15:04:27 server postfix/smtpd[4188]: fatal: open database /var/lib/mailman/data/aliases.db: No such file or directory
Und diese Datei gibt es wirklich nicht.

Bei apt-get install mailman kommt übrigens die Fehlermeldung
Code:
WARNING: I/O error while trying to byte-compile /usr/lib/mailman/bin/postfix-to-mailman.py (2): No such file or directory
WARNING: I/O error while trying to byte-compile /usr/lib/mailman/bin/qmail-to-mailman.py (2): No such file or directory
Diesmal habe ich die main.cf gesichert, bevor ich das etc-Verzeichnis wieder zurückgesetzt habe.

Inhalt:

Code:
# See /usr/share/postfix/main.cf.dist for a commented, more complete version


# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = /usr/share/doc/postfix

# TLS parameters
smtpd_tls_cert_file = /etc/postfix/smtpd.cert
smtpd_tls_key_file = /etc/postfix/smtpd.key
#smtpd_tls_CAfile = /etc/postfix/cacert.pem
smtpd_use_tls = yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

myhostname = myhost.com
alias_maps = hash:/etc/aliases, hash:/var/lib/mailman/data/aliases
alias_database = hash:/etc/aliases, hash:/var/lib/mailman/data/aliases
myorigin = /etc/mailname
mydestination = myhost.com, localhost, localhost.localdomain
relayhost = 
mynetworks = 127.0.0.0/8 [::1]/128
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
html_directory = /usr/share/doc/postfix/html
virtual_alias_domains = 
virtual_alias_maps = proxy:mysql:/etc/postfix/mysql-virtual_forwardings.cf, mysql:/etc/postfix/mysql-virtual_email2email.cf, hash:/var/lib/mailman/data/virtual-mailman
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql-virtual_domains.cf
virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql-virtual_mailboxes.cf
virtual_mailbox_base = /var/vmail
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000
smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes
smtpd_sasl_authenticated_header = yes
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, check_recipient_access mysql:/etc/postfix/mysql-virtual_recipient.cf, reject_unauth_destination
smtpd_tls_security_level = may
transport_maps = proxy:mysql:/etc/postfix/mysql-virtual_transports.cf
relay_domains = mysql:/etc/postfix/mysql-virtual_relaydomains.cf
virtual_create_maildirsize = yes
virtual_maildir_extended = yes
virtual_mailbox_limit_maps = proxy:mysql:/etc/postfix/mysql-virtual_mailbox_limit_maps.cf
virtual_mailbox_limit_override = yes
virtual_maildir_limit_message = "The user you are trying to reach is over quota."
virtual_overquota_bounce = yes
proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps $virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains $relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps $recipient_canonical_maps $relocated_maps $transport_maps $mynetworks $virtual_mailbox_limit_maps
smtpd_sender_restrictions = check_sender_access mysql:/etc/postfix/mysql-virtual_sender.cf
smtpd_client_restrictions = check_client_access mysql:/etc/postfix/mysql-virtual_client.cf
maildrop_destination_concurrency_limit = 1
maildrop_destination_recipient_limit = 1
virtual_transport = maildrop
header_checks = regexp:/etc/postfix/header_checks
mime_header_checks = regexp:/etc/postfix/mime_header_checks
nested_header_checks = regexp:/etc/postfix/nested_header_checks
body_checks = regexp:/etc/postfix/body_checks
content_filter = amavis:[127.0.0.1]:10024
receive_override_options = no_address_mappings
message_size_limit = 0
relay_recipient_maps = mysql:/etc/postfix/mysql-virtual_relayrecipientmaps.cf
owner_request_special = no
Gruß

Günter
 

Till

Administrator
Der Fehler wird am neu im svn hinzugefügten mailinglisten support liegen. Wie es aussieht werden die postfix hash dataienen dafür nicht bei der installation sondern erst beim anlegen der ersten mailingliste erstellt. Das wird auf jeden fall noch bis zum release der Funktionen im installer angepasst werden. SVN ist halt nur für entwickler gedacht, da sind die Funktionen noch nicht alle getestet.
 

ITSK

New Member
Benötige ebenfalls dringend Hilfe nach einem Update.

Meine Vertretung hat heute Nacht einige gravierende Fehler gemacht. Als ich den Hilferuf erhielt, konnte ich weder senden noch empfangen, leider sind alle Mailkonten betroffen. Offensichtlich kommen die Mails beim Server an, werden jedoch nicht richtig verarbeitet. Leider kenne ich mich mit ISPconfig fast nicht aus. Ich habe mich entschieden selbst nichts am Server zu verändern, um die Lage nicht zu verschlimmern.

Was ist passiert:
1. ein Update von ISPconfig 3.x auf 3.1.8p1 wurde durchgeführt, OHNE ein vorheriges Backup vom Server zu machen.
2. es wurde wärend des Updates angeblich ein Backup von ISPconfig angeboten und auch erstellt.
3. ein Update des Betriebssystems (CentOS 6) wurde durchgeführt, erneut OHNE ein vorheriges Backup vom Server zu machen.

Wer kann helfen? Teamviewer, TeamSpeak, oder telefonisch jederzeit möglich.
 

florian030

Well-Known Member
1. die aktuelle Version wäre besser gewesen
2. schau mal in /var/backup
3. das sollte nicht das Problem sein, wenn Du keinen Versionssprung hast.

schau mal nach, ob amavis und dovecot bzw. courier überhaupt laufen. Ggf. einmal die entsprechenden Dienste starten.
 

Werbung

Top