Slave auf älteren Zustand zurückgesetzt - Ispconfig Slave Daten auf Master inkonsistent

[etron770]

Der Master vom Slave, hat, wenn ich einen Slave (VM Remove-> Restore) nach Änderung in IspConfig zurücksetze, inkonsitente (die neuen) Daten


Wie bekomme ich die Daten auf dem Master wieder auf den alten Stand des Slaves?

Gibt es nur die Möglichkeit den Slave aus dem Master zu löschen und wieder einzufügen?
Das wäre etwas umständlich.

 

[Till]

Gibt es nur die Möglichkeit den Slave aus dem Master zu löschen und wieder einzufügen?

Das würde ich keinesfalls machen. Ruf auf Einstellungen > Resync und lass die Daten neu vom master auf den Slave schreiben.

 

[etron770]

Was aber, wenn aber die Daten auf dem Master den Slave dann wieder in einen instabilen Zustand setzen, der genau mit der Rücksetzung behoben ist?

Was passiert, wenn Strukturen, die auf dem Master vorhanden sind, auf dem zurückgesetzten Slave fehlen?
z.b /var/www/clients/clientxyz/...
und/ oder Einträge in /etc/apache/... zu denen es dann kein Äquivalent auf der Festplatte gibt?

Und es kommen viele Fehlermeldungen mit z.B "07.05.2022-07:37 - WARNING - Falsche Anfrage / Wro..."

07.05.2022-07:37 - WARNING - Falsche Anfrage / Wrong QuerySQL-Query = REPLACE INTO `client` (`client_id`,`sys_userid`,`sys_groupid`,`sys_perm_user`,`sys_perm_group`,`sys_perm_other`,`company_name`,`company_id`,`gender`,`contact_firstname`,`contact_name`,`customer_no`,`vat_id`,`street`,`zip`,`city`,`state`,`country`,`telephone`,`mobile`,`fax`,`email`,`internet`,`icq`,`notes`,`bank_account_owner`,`bank_account_number`,`bank_code`,`bank_name`,`bank_account_iban`,`bank_account_swift`,`paypal_email`,`default_mailserver`,`mail_servers`,`limit_maildomain`,`limit_mailbox`,`limit_mailalias`,`limit_mailaliasdomain`,`limit_mailforward`,`limit_mailcatchall`,`limit_mailrouting`,`limit_mail_wblist`,`limit_mailfilter`,`limit_fetchmail`,`limit_mailquota`,`limit_spamfilter_wblist`,`limit_spamfilter_user`,`limit_spamfilter_policy`,`limit_mail_backup`,`limit_relayhost`,`default_webserver`,`web_servers`,`limit_web_ip`,`limit_web_domain`,`limit_web_quota`,`web_php_options`,`limit_cgi`,`limit_ssi`,`limit_

Das sind Daten, die z.B eigentlich nur auf dem Mailserver sein sollten. Bei dem Resync habe ich mit absoluter Sichernheit nur den betroffenen Vserver ausgewählt:

07.05.2022-07:37 - WARNING - Falsche Anfrage / Wrong QuerySQL-Query = REPLACE INTO `spamfilter_policy` (`id`,`sys_userid`,`sys_groupid`,`sys_perm_user`,`sys_perm_group`,`sys_perm_other`,`policy_name`,`virus_lover`,`spam_lover`,`banned_files_lover`,`bad_header_lover`,`bypass_virus_checks`,`bypass_spam_checks`,`bypass_banned_checks`,`bypass_header_checks`,`spam_modifies_subj`,`virus_quarantine_to`,`spam_quarantine_to`,`banned_quarantine_to`,`bad_header_quarantine_to`,`clean_quarantine_to`,`other_quarantine_to`,`spam_tag_level`,`spam_tag2_level`,`spam_kill_level`,`spam_dsn_cutoff_level`,`spam_quarantine_cutoff_level`,`addr_extension_virus`,`addr_extension_spam`,`addr_extension_banned`,`addr_extension_bad_header`,`warnvirusrecip`,`warnbannedrecip`,`warnbadhrecip`,`newvirus_admin`,`virus_admin`,`banned_admin`,`bad_header_admin`,`spam_admin`,`spam_subject_tag`,`spam_subject_tag2`,`message_size_limit`,`banned_rulenames`,`policyd_quota_in`,`policyd_quota_in_period`,`policyd_quota_out`,`polic
 yd_quota_out_period`,`policyd_greylist`,`rspamd_greylisting`,`rspamd_spam_greylisting_level`,`rspamd_spam_tag_level`,`rspamd_spam_tag_method`,`rspamd_spam_kill_level`) VALUES ('3','1','0','riud','riud','r','Wants all spam','N','Y','N','N','N','N','N','N','Y',NULL,NULL,NULL,NULL,NULL,NULL,'3.00','999.00','999.00',NULL,NULL,NULL,NULL,NULL,NULL,'','','',NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,'-1','24','-1','24','N','n','999.00','999.00','rewrite_subject','999.00') -> 1265 (Data truncated for column 'warnvirusrecip' at row 1)

 

[Till]

Du musst sicherstellen dass auf allen systemen die selbe ISPConfig Version läuft, scheinbar ist der master neuer als der slave. Und Spamfilter policies wie auch clients werden auf alle nodes gespiegelt da sie nicht serverspezifisch sind, das ist also so ok.

 

[etron770]

Du musst sicherstellen dass auf allen systemen die selbe ISPConfig Version läuft, scheinbar ist der master neuer als der slave. Und Spamfilter policies wie auch clients werden auf alle nodes gespiegelt da sie nicht serverspezifisch sind, das ist also so ok.

Ach ja ... auf dem Zurückgesetzten ist ja dann eine ältere:
also erst IspConfig Update, dann Resync.
Das vergisst man leicht, wenn man ja allle Server auf dem neuesten Stand hatte ...

 

[etron770]

Ich mache mal einen neuen Tread auf, denn die SQL meldungen kommen icht von der zurückgesetzten VM.

 

[etron770]

Ich komme da einfach nicht weiter ...
Wenn ich die VM zurücksetze und einen Resync mache, dann kommt immerbei einer
subdomain.domain.de:specialport
und das mit Reverse Proxy auf subdomain.domain.de
Fehlercode: SSL_ERROR_RX_RECORD_TOO_LONG

Was nützt es mir dann den Slave vom Master zum Slave zu syncen wenn der Master dann wieder die Webseite zerschießt.
Genau deshalb setze ich ja die VM zurück
Ich finde den Fehler nicht, egal wo ich anfrage, kommt zu diesem Problem keine Hilfestellung
Zusätzlich kann ich nach einem Resync die alten Verzeichnisstrukturen (die vor dem resync die subdomain enthalten)
/var/www/clients/client1/web333/ nicht löschen
rm: das Entfernen von ' /var/www/clients/client1/web333/' ist nicht möglich: "Die Operation ist nicht erlaubt"

 

[Till]

Was nützt es mir dann den Slave vom Master zum Slave zu syncen wenn der Master dann wieder die Webseite zerschießt.

Naja, das heißt dann aber dass der Slave eben in Ordnung war und kein Zurücksetzen notwendig war. Wenn der fehler wieder auftritt, dann wird etwas mit den Einstellungen der Website, so wie Du sie auf dem matser gemacht hast, nicht stimmen.

Und SSL_ERROR_RX_RECORD_TOO_LONG ist ja ein SSL Fehler, der kommt meines Wissen nach dann wenn Du per http auf eine https resource zugreifst, oder anders herum. Möglicherweise versuchst Du ein prxying per https auf etwas, das nur http kann, oder anders herum.

 

[etron770]

Sorry das habe ich irgendwie falsch formuliert
1. Slave läuft auf IPV6 hat aber ein https Problem bei IPV4 zugriffen auf einen Reverse Proxy (falsches Zertifikat)
2. Änderungen über ISP config am über den Master auf dem Slave durchgeführt weder ipv4 noch IPv6Zugriffe funktionieren (SSL_ERROR_RX_RECORD_TOO_LONG)
3. ich weiß nicht mehr was ich alles probiert habe und bekomme den funktionierenden IPV6 Zustand nicht mehr über Änderungen am Master zurück
4. Rücksetzten des Slave (VM restore)
5. -> Zustand 1
6. Resync -> Zustand 2

Ich drehe mich also irgendwie im Kreis ...