Beiträge von fx998

Hallo,

bei mir ist die Darstellung der Suchergebnisse dieses Forums fehlerhaft. Die Betreffzeilen der Beiträge sind nur zur Hälfte dargestellt und somit nur schwer lesbar.

Screenshot:

http://www.megabert.de/downloa…iveconfig_forum_suche.png

getestete Browser/OS-Kombinationen:

Debian 10/Firefox 91
Debian 10/Chromium 90
Windows 10/Firefox 86
Windows 10/Edge 92

Kaputtes CSS?

Nachtrag:

CSS-Klasse: "searchtitle" Eigenschaft "height" Wert von 17.22px auf 25px ändern. Das macht das Ganze schon mal viel besser.

Ich habe das gleiche Problem soeben hier gehabt. DKIM war auf diesem Server bereits in Verwendung. Es wurde nur eine weitere Domain mit DKIM konfiguriert. Es handelt sich um die erste neue Domain, die seit dem Upgrade auf Debian 9 mit DKIM konfiguriert wurde.

Folgendes hat geholfen:

• Postfix manuell neu starten
• OpenDKIM manuell neu starten

Bin mir nicht sicher ob beides notwendig war. Danach war die korrekte DKIM-Signatur in der Mail vorhanden.

Hallo,

gibt es irgend eine Möglichkeit Postfächer per API zu löschen?

Ich habe hier mehrere 100 die ich gerne löschen möchte. Laut
API-Dokumentation gibt es keine Möglichkeit.

Grüße,
fx

Ok. Gut zu wissen.

Dann also vielleicht eher so:

1. Liveconfig Nutzdaten vorab auf das Zielsystem syncen.(rsync/lsyncd)
2. DNS TTL heruntersetzen
3. Maildienste abschalten
4. Nutzdaten verschieben(so dass die Nutzdaten nicht mehr an der ursprünglichen Stelle liegen und sie bei einem Backup nicht mitgesichert werden)
5. LiveConfig Backup erstellen (mit leeren Nutzdatenverzeichnissen)
6. LiveConfig Backup auf das Zielsystem(Multiserver) einspielen
7. Nutzdaten per rsync auf das Zielsystem bringen
8. DNS Änderungen durchführen, damit die Einträge auf das neue System zeigen
9. Maildienste wieder aktivieren

Mir ist jetzt selbst noch ein Weg eingefallen, wie man die Migration beschleunigt durchführen kann, auch ohne die Trennung zwischen Nutzdaten und Metadaten beim Backup:

In einem Wartungszeitraum verschiebt man kurzzeitig die Nutzdaten, so dass alle E-Mail und Webverzeichnisse leer sind. Damit erstellt man das Backup und anschließend verschiebt man die Daten wieder zurück.

Damit hat man ein mehr oder weniger leeres Backup, dass man mit erwähntem rsync dann wieder synchronisieren kann.

Dabei sind zwar noch ein paar Sachen zu beachten, aber das dürfte beherrschbar sein.

Zitat von antondollmaier

Was ebenfalls verkürzt werden kann:

- initialer RSync im laufenden Betrieb
- Dienste abschalten, ab jetzt Ausfall
- neuer Rsync, der nur die Änderungen überträgt
- Dienste wieder einschalten

Somit wird die Downtime minimiert.

Alles anzeigen

Dafür verwende ich gerne lsyncd. Der synchronisiert kontinuierlich nur die Änderungen nach, die via Inotify registriert werden. D. h. nach abschalten der Dienste hat man nicht einen komplett neuen rsync, der schon je nach Datenmenge ein paar Minuten oder länger dauern kann, auch wenn nur Änderungen übertragen werden.

Gerade bei mehreren Millionen Dateien(Maildir), braucht das seine Zeit. lsyncd synchronisiert nur nach(z. B. nach dem mysql shutdown, die geänderten DB-Dateien). Mit lsyncd wird die Downtime meist auf Sekunden reduziert. (Das nutze ich gerne bei der Migration von VMs, die sich aufgrund von Rahmenbedingungen der Virtualisierungstechnik nicht live migrieren lassen.)

Zitat

Sie verwenden zwischenzeitlich auch nicht mehr "mail.example.com" oder "imap.example.com", da das Probleme mit dem SSL-Zertifikat gibt.

Das kann ich ja durch Verwendung eines LE-Multi-Domainzertifikates umgehen, dass alle benötigten Servernamen enthält. Das ist nicht die Schwierigkeit dabei.

---

Man kann natürlich auch DNS ändern statt IPs migrieren. Das ist aber auch nicht die Schwierigkeit dabei. Die Schwierigkeit, die ich da sehe ist, die LC-Metadaten und Nutzdaten in einem überschaubarer Zeit migrieren zu können. Hier ist wie schon gesagt das kommende Backup-/Restore-Feature, die einzige Möglichkeit, die ich sehe. Und die LC-Metadaten kann ich nicht einfach kopieren, sondern die müssen aus dem Quellsystem herausgeholt werden und in das Zielsystem eingebunden werden.

Der rsync alleine bringt mir rein gar nichts, wenn die Vertragsdaten, Passworthashes, ... nicht da sind oder ich die Liveconfig-Metadaten eines Multi-Server-Setup mit denen eines Single-Server-Setups überbügele(z. B. in dem ich die SQLite-DB einfach überschreibe).

Hallo,

gemäß dem gerade geführten Gespräch ist der grundsätzlich empfohlene Migrationspfad von einem Single- in ein Multi-Server-Setup das exportieren der Daten aus dem Single-Server-Altsystem und dem importieren der Daten in das Multi-Server-Neusystem. (Die dazu notwendige Backup/Restore-Funktionalität ist lt. Herrn Keppler aktuell mit Hochdruck in Entwicklung).

Grundsätzlich sollte das ja so sein, dass sich IP-Adressen nicht ändern, oder alle Nutzer müssen Ihre E-Mailprogramme neu konfigurieren. Das würde ich, wenn irgend möglich gerne vermeiden. Auch längere Downtimes würde ich gerne vermeiden.

Eine mögliche Idee zum Vorgehen wäre für mich folgende:

1. Metadaten migrieren(E-Mailadressen, Weiterleitungen, Passworthashes, Vertragsdaten, Liveconfig-Verwaltungsdaten,... Grösse: Wenige MB)
2. IP-Adresse des Mailsystems auf das neue System umziehen
3. Nutzdaten im Hintergrund migrieren(per rsync(unterschiedliche UIDs!), Tatsächliche E-Maildaten, Grösse: Viele GB)

Auf die Art und Weise könnte man den E-Maildienst relativ unterbrechungsfrei migrieren. Die Nutzer hätten nur vorübergehend keinen Zugriff auf die vorhandenen E-Mails Ihrer Postfächer, bis der Hintergrund-sync abgeschlossen ist.

Dazu müsste allerdings die kommende Backup- und Restorefunktionalität einen Nur-Metadaten-Modus unterstützen.

Wie telefonisch angefragt, hatte ich gerade einen Anwendungsfall, bei dem ich für eine Kunden alle Passwörter aller Postfächer ändern musste.

Die Funktionalität, die Postfächer eines Vertrages oder einer Domain/Subdomain auszulesen wünsche ich mir zugreifbar über die API.

Im Moment muss ich mir dass aus der Datenbank ziehen(hier: alle Postfächer aus SQLITE-DB):

SELECT MB_NAME || "@" || MB_DOMAIN 
FROM MAILBOXES,HOSTINGCONTRACTS
WHERE 
        HC_ID   = MB_CONTRACTID
    AND HC_NAME = "web912" 
    AND MB_TYPE = 1;

In der Standardkonfiguration von vsftpd wird Transfereinstellung
des ascii - Modus nicht erlaubt. Das wären die Serveroptionen:

ascii_upload_enable
ascii_download_enable

Vom vsftpd-Team wird das als Sicherheitslücke eingestuft, die
man ausnutzen kann....

# ... /etc/vsftpd.conf ...
#
# By default the server will pretend to allow ASCII mode but in fact ignore
# the request. Turn on the below options to have the server actually do ASCII
# mangling on files when in ASCII mode.
# Beware that on some FTP servers, ASCII support allows a denial of service
# attack (DoS) via the command "SIZE /big/file" in ASCII mode. vsftpd
# predicted this attack and has always been safe, reporting the size of the
# raw file.
# ASCII mangling is a horrible feature of the protocol.

Aber so grundsätzlich ist das ja blöd, wenn damit für den Nutzer von Windows-Systemen die Möglichkeit wegfällt Scripte per FTP auf den Server hochzuladen.

Ich denke, es ist schon gut dass so zu lassen wie es ist. Sobald es einem auffällt bzw. stört, kann man es aktivieren. Ich habe das hier mal geschrieben, damit es vielleicht per Google gefunden wird.

Ich habe das über einen lua-Hook gelöst, um bei mir die zwei Einstellungen zu aktivieren:

https://www.liveconfig.com/de/…ua-Script-Hooks-einbinden

Danke! Habe nicht gesehen!

Hallo,

ich fände es gut, wenn der Accountinhaber eine Warnung bekommt,
falls ein Zertifikat ausläuft.

Bei Let's Encrypt kann das vorkommen, wenn neue Nutzungsbedingungen
rauskommen, die der Nutzer erst wieder bestätigen muss oder bei
herkömmlichen Zertifikaten, die halt ablaufen.

Viele Grüße,
Tobias

Hallo Reiko,

der Tip ist doch super. Danke!
Problem gelöst.

Viele Grüße

Hi,

ich bin gerade am testen mit der API und teste auch Fehler, z. B. Anmeldefehler.

Wenn ich das zu oft mache, wird durch mein Script die Anmeldesperre ausgelöst
und ich kann erst mal nicht mehr weiterarbeiten.

Ich bin mir nicht sicher, ob API-Aufruffehler die Sperre auch auslösen.

Kann man die Sperre irgendwie zeitweise ausschalten?

Grüße,
fx

Hi,

Benno ist bei uns noch nicht produktiv. Allerdings habe ich schon ein Webinterface zur Benutzerverwaltung geschrieben(als Alternative zur Kommandozeile), das derzeit zumindest funktioniert. Aufgrund mangelnder Nachfrage, liegt das im Moment allerdings brach.

Grüße,
fx

Keine Antwort ist auch eine Antwort: In dem Fall: Das Feature gibt's nicht! Noch Fragen?

Das ist ganz schön nervig, wenn 3-buchstabige Wörter bei der Suche nicht gehen:

• api
• ssl
• cgi
• php
• ...

Ich gehe mal nicht davon aus, dass der Server gleich zusammenbricht, wenn man das aktiviert.

Dafür müsste man wohl im MySQL-Server die minimale Länge für die Volltextsuche ändern. Siehe hier:

https://www.vbulletin.com/foru…ers?p=1640497#post1640497

Ich habe hier mit einer PHP-Klasse für die Liveconfig-SOAP-API angefangen, um die eigene Administration zu erleichtern(Viele Benutzer anlegen, Passwörter massenhaft zurücksetzen).

Es geht im Moment:

• EMailbenutzer anlegen
• EMailbenutzer Passwort zurücksetzen

Hier ist das bisherige Script:
https://github.com/megabert/sc…ree/master/php-liveconfig

Ich habe mir jetzt mit einem Script als workaround beholfen, dass prüft, ob eine angemeckerte Datei ein LE-Zert ist, ob es auch tatsächlich abläuft und ob es wirklich nicht mehr in Verwendung ist(in /etc) und anschliessend löscht.

#!/bin/bash


export    SELF="$(basename $0)"
export    CERT="$1"
export OPENSSL=/usr/bin/openssl


my_flock() {


        exec 200>/tmp/lock.$SELF
        flock --wait 10 200
}


my_log() {
        local MSG="$*"
        /usr/bin/logger -t "$SELF" -p local7.info "$MSG"
}


check_and_remove_cert() {


        local CERT="$1"
        local cert_expiration_date


        [ -n '$CERT' ] || { my_log "Usage: $(basename $0) <certfile-to-purge>"                  ; exit 1 ; }
        [ -f '$CERT' ] || { my_log "No file >>$CERT<< found, exiting"                           ; exit 2 ; }
        my_flock       || { my_log "Another Instance of this program already running, exiting"  ; exit 3 ; }


        # 1. check if the certificate is a letsencrypt certificate
        if $OPENSSL x509 -in "$CERT" -text 2>/dev/null| grep -qiE "CA .*letsencrypt" ; then


                # check if the certificate is near expiration
                cert_expiration_date="$(openssl x509  -in "$CERT" -dates -noout 2>/dev/null | grep notAfter | cut -d= -f2)"
                cert_expiration_date=$"$(date --date="$cert_expiration_date" +"%s")"
                if [ '$cert_expiration_date' -lt '$(date --date='now + 14 days' +'%s')' ] ;then


                        # search for cert in all small files in /etc if still in use(expensive command)
                        if ! find 2>/dev/null /etc -mtime -180 -type f -size -100k -exec fgrep -lR "$CERT" "{}" +  | fgrep -q "$CERT" ; then 
                                # cert not found -> delete
                                my_log "removing unused, expiring letsencrypt-certificate $CERT"
                                rm -f "$CERT"
                        fi
                fi
        fi
}


trap "" 1 15


check_and_remove_cert "$CERT" >/tmp/$SELF.log 2>&1 &

Zertifikate liegen in /etc/ssl/certs. Das ist einfach implementiert, braucht wenig resourcen und geht sehr schnell.

Wenn Du einen einfacheren Ansatz hast, wie ich alle Zertifikate mit allen SNI-Hostnamen für alle möglichen Anwendungen (mailserver, webserver, was-weiss-ich-server,...) auf einem Server(unabhängig ob jetzt liveconfig drauf ist oder nicht) prüfen kann: Immer her damit.

Nachtrag

Für die höheren SLA wird das Zertifikat natürlich online geprüft.

Mit "altes Zertifikat" meine ich die crt - Datei.

Hier liegen z. B. schon 3 davon mit dem gleichen CN rum, 2 abgelaufene:

/etc/ssl/certs/31e01e675a1f17ca.crt 1503855420 meinedomain.de
/etc/ssl/certs/80b15bd20bd7324b.crt 1509059340 meinedomain.de
/etc/ssl/certs/f84d325ead282b9f.crt 1503855900 meinedomain.de