Beiträge von mbo

Der Fehler sorgte bei mir auch dazu, dass Sieve-Scripte nicht aufrufbar waren.

Warning: sieve: file storage: Active sieve script symlink /var/mail/xxx/1/dovecot.sieve is broken: Invalid/unknown path to storage (points to /var/mail/xxx/1/sieve).

Die Unterschiede in der passwd hatte ich auch gefunden (/var/mail vs /var/mail/xxx/1) und nach einer Prüfung der dovecot.lua-Datei bin ich dazu übergegangen, die Config für die betroffenen Dateien neu schreiben zu lassen:

UPDATE MAILBOXES SET mb_status=0 WHERE MB_DOMAIN='xxx';

Danach LiveConfig neustarten und ein paar Sekunden warten. Danach waren die passwd-Einträge korrigiert.

Beim weiteren Testen mit Debian 13 ist mir aufgefallen, dass der Name des Symlinks nun standardmäßig .dovecot.sieve ist. In der von LiveConfig erstellten passwd-Datei ist der volle Pfad nicht als Dotfile.

Daher ist noch eine zusätzliche Anpassung via dovecot.local.conf notwendig, damit Filterregeln funktionieren.

sieve_script personal {

type = personal

path = ~/sieve

active_path = ~/dovecot.sieve

}

Oder übersehe ich etwas?

Wenn die Rahmenbedingungen stimmen, ist der Umzug keine große Sache. Innerhalb eines LiveConfig Multiserver Setups reichen wenige SQL-Queries, um ein Hosting-Paket an einen anderen Server zu hängen.

Besonders charmant ist es, einen kompletten Server mit einem anderen Server zu mergen - das dauert dann prinzipiell genauso lange, wie einen einzelnen Kunden zu verschieben.

Aber die Rahmenbedingungen sind vielfältig...

- Ist die TTL der Domains auf ein Minimum reduzierbar oder brauche ich einen Proxy-Lösung, um Webseite und Mails noch über alte IPs temporär zuzulassen

- Kenne ich alle Konfigurationsdateien, die neben dem reinen Dateisync + Anpassungen in LiveConfig notwendig sind. Sei es die /etc/passwd/, die jeweiligen Apache / Nginx Configs, Teile der Postfix Virtual Users, SSL Zertifikate etc.

Downtime von max. 60 Sekunden sollte das Ziel sein und mit den passenden CLI-Kommandos auch machbar.

Schöner wäre natürlich eine vollintegrierte Lösung in LiveConfig, aber es geht auch mit Linux Boardmitteln.

Zitat von Systemhaus-EHST

an der Konfiguration wurde nichts angepasst, wenn LiveConfig/Dovecot den Pfad ändert, bin ich bisdato davon ausgegangen das die komplette Konfiguration auch angepasst wird.

Ganz ohne automatische Migration wird das bei vielen zu Problemen führen. Wenn die Mails nach dem Umziehen nach $/Maildir wieder erreichhbar waren und zusätzlich (danach) der Parameter in der /etc/dovecot/passwd angepasst wurde, klingt eher danach, dass der Parameter in der passwd gar nicht mehr benutzt wird.

Da gab es sicherlich mit Dovecot 2.4 noch eine Umstellung die bislang übersehen wurde. Und das sollte schnellstmöglich aufgeräumt werden, sonst wird es hinterher komplizierter den alten Standard wiederherzustellen.

kk

Zitat von Systemhaus-EHST

Statt wie bisher

var/mail/kunde/1 z.B.

nun:

var/mail/kunde/1/Maildir/

Das klingt aber eher nach einem Thema mit der Konfiguration? Sind denn die maildirs in /etc/dovecot/passwd angepasst? Oder greift ggf. eine mail_location warum auch immer (doveconf | grep mail_location)?

Zitat von antondollmaier

- ungesichertes Kontaktformular auf dem Webserver (fällt hier aber weg, wenn "howtomeasurecobb.com" nicht bei euch liegt...)

Das kommt leider vor, wenn die Absenderadresse als FROM der Mail verwendet wird. Das ist vor allem dann ein Problem, wenn - wie hier - die Mails nicht lokal zugestellt werden, sondern extern. Fehlgeschlagene SPF-Tests lassen grüßen.

Wenn man nach der Mailadresse der Konditorei sucht, findet man die entsprechende Webseite, die auf der IP aus dem Log liegt.

Danke für die Nennung von pfqueue - kannte ich noch gar nicht

Hallo,

bitte als erstes die Mailadressen aus dem Log unkenntlich machen!!

Sicher, dass es LiveConfig war? Könnte auch ein schlecht gesichertes Kontaktformular sein. Am besten einmal die Logfiles nach der Quelle durchsuchen, ggf. auch mal mit postcat die Header anschauen. Sicherlich findet man sogar schon über Zeitstempel-Check die passenden POST-Requests gegen das Formular...

Hallo,

wer vorher postsrsd (v1) schon installiert hatte sstolpert ggf. darüber, dass die v2 aus dem LC Repository nicht startet.

postsrsd: error: cannot read '/etc/postsrsd/postsrsd.conf': Permission denied

Bei mir auf Debian 12 ist Apparmor aktiv. Also entweder das Profil auf die neuen Pfade anpassen oder nach eigenem Sicherheits-Ermessen deaktivieren.

sudo aa-complain /etc/apparmor.d/usr.sbin.postsrsd

Hallo,

ich bin heute auch auf diesen Anbieter aufmerksam geworden und finde es als Fallback / Alternative für Let's Encrypt sehr gut. Doch leider scheint LiveConfig nicht so ganz damit zurecht zu kommen. Mit dem ersten angeforderten Cert kommen Log-Einträge:

[2024/11/11 07:42:35.649028] [39081|39090] Invalid date: ''

Die Domain bleibt auf "Pending"...

Es geht ja auch darum, dass Kunde A nicht im Namen von Kunde B schreibt...oder Kunde C nicht im Namen von einer x-beliebigen Drittdomain

Hallo,

steht es vielleicht schon auf der Pipeline?

Ich würde gerne ausgehende Mails "FROM" bzw. Envelope-Adresse nur erlauben, was auch an Mail-Adressen konfiguriert ist, also im Idealfall das Mailpostfach selbst, aber auch Weiterleitungen von lokal eingerichteten Adressen.

Ja, das mit der Passkey-Verwaltung habe ich auch erst zu spät gesehen. Ich habe gestern dann auch noch einen USB-C Yubikey bestellt. Wenn ich das mit dem Titan später nochmal testen soll, einfach Bescheid geben.

Hallo,

da mein alter Yubikey noch mit "USB-A" Anschluss ist, habe ich mir als neuen Key den Google Titan in der USB-C Variante bestellt. Diesen kann ich wunderbar als Webauthn-Gerät hinzufügen. Beim Login unter Firefox und Chromium am Linux-PC als auch Chrome am Android Handy kann ich mich nicht in LiveConfig einloggen.

Chromium meldet "Du verwendest einen Sicherheitsschlüssel, der nicht auf diesr Website registriert ist".

Im Firefox erscheint die LiveConfig-Fehlermeldung "Unexpected server answer. Login not possible: NotAllowedError: The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission."

Fehlt dem Titan etwas aus dem FIDO2-Standard? Ein paar andere Webdienste funktionieren.

Hat jemand eine Idee?

Ich gehe den neuen Preis auch nicht mit, v.a. da meine Wunsch-Fixes nicht umgesetzt wurden (u.a. wäre es ja toll, wenn die Passwörter nicht als MD5 gespeichert würden). Beim Kundenfrontend-Passwort, nicht mal als Salted Hash. 2FA? Nein...OK, bleiben nur Firewall und entsprechende Mod-Security Regeln.

Ich wäre ja bereit gewesen, für die Software zu zahlen, aber beim "Ist"-Stand über Jahre bleiben ist Rückschritt. Oder werden z.B. die Passwörter jetzt sicherer in der DB abgelegt?

Bei mir gingen die g*Sales Rechnungen schon lange per API zu Lexoffice. Nun generiert Lexoffice die Rechnungen und sie gehen von dort ins Kundenfrontend.

Lexoffice erhöht zwar auch regelmäßig die Preise um ein paar Prozent, aber man bekommt beim Support ordentliche lösungsorientierte Antworten - und nicht nur pampige Mails. Der Leistungsumfang bei Lexoffice stimmt einfach, vor allem, da man alle Arten von Belegen verbuchen kann und nicht "nur" Rechnungen schreiben.

Und hey, ab nächstem Jahr is Lexoffice sogar im größten Paket günstiger als gSales

Hallo,

taucht die dovecot.local.conf als include in der dovecot.conf auf?

Zitat

# local configuration options
!include_try /etc/dovecot/dovecot.local.conf

Ich meinte mich erinnern zu können, dass die Datei nicht automatisch angelegt wird und nur dann inkludiert wird, wenn sie beim letzten Schreiben der Dovecot-Config aus LiveConfig heraus auch existiert.

Update ist nun mit dem Hochsetzen der Schema-Version durchgelaufen

Ich bin schon immer im Stable-Pfad. Was ich noch ergänzen kann, der o.g. Fehler war ein Folgefehler von

Zitat

/usr/sbin/liveconfig: Database connection failed: Duplicate entry '0-mysql' for key 'DBS_CODE_IDX'

Leider gibt es schon wieder Probleme beim Datenbank-Upgrade...

Zitat

/usr/sbin/liveconfig: Upgrading database schema (r214041 -> 2.14.4-2)
/usr/sbin/liveconfig: Database connection failed: Duplicate column name 'DBS_CODE'

Zitat

ALTER TABLE DBSERVERS ADD COLUMN DBS_CODE VARCHAR( 20)

Bei den Datenmengen ist eine Sub-Query nicht so schlimm. Schöner wäre ein Delete-Join

Bei der Gelegenheit ist mir aufgefallen, dass es in der IPS-Tabelle Duplikate gibt (mehrere identische IP-Adressen auf einem Server). Ggf. kam das mal durch ein Umbenennen der Netzwerk-Devices (?) Es wäre vermutlich auch praktisch, wenn dies aufgeräumt wurde. Sichtbar sind die doppelten und zum Teil auch dreifachen IPs in der Webserver-Verwaltung.

Schade...

- /usr/sbin/liveconfig: Database connection failed: Cannot add or update a child row: a foreign key constraint fails (`LIVECONFIG`.`WEBSERVERIPS_new`, CONSTRAINT `WEBSERVERIPS_new_ibfk_2` FOREIGN KEY (`WI_IPID`) REFERENCES `IPS` (`IP_ID`) ON DELETE CASCADE)
dpkg: error processing package liveconfig (--configure):

OK...Irgendwann im Laufe der letzten Jahre haben sich wohl IPs eingeschlichen, die bei einem Serverwechsel zwar noch in der WEBSERVERIPS Tabelle enthalten waren, nicht aber mehr in der IPS...

DELETE FROM WEBSERVERIPS WHERE WI_IPID NOT IN (SELECT IPS.IP_ID FROM IPS);

hat Abhilfe geschafft.