Ubuntu bietet meistens "aktuellere" Kernel, Software als zb Debian oder Centos.
Kernel? Interessiert doch nicht wirklich, oder?
PHP oder MySQL lasse ich gelten.
Abhilfe: Backports oder offizielle Repositories der Hersteller.
ZitatAber auch ich bin kein Fan von Ubuntu
- Debian
"find" ist für solche Zwecke verwendbar.
Nein, ist es nicht. Dadurch werden nämlich die Indexes von Dovecot zerstört.
Was man machen will:
Dann doch bitte eine vernünftige Maillinglisten Software nutzen und nicht so einen "Schmuh" unterstützen.
Den Vorteil sehen leider nicht viele. Auch ist der Aufwand, Mailman wegen 5 Empfängern (vorstand@...) aufzusetzen/zu konfigurieren, zu groß.
Hier verstehe ich leider die Kunden - auch wenn mir Poll oder Mailman lieber wäre.
Oder gibt es die Möglichkeit sich in diesen Prozess (Zone anlegen/löschen) einzuhaken und ein eigenes Lua-Script auszuführen, welches den API-Aufruf übernimmt ?
custom.lua, dns.update überschreiben.
Da hat offenbar GMX SPF scharf geschalten.
Neben dem LDA-Plugin muss managesieve noch zusätzlich aktiviert werden.
Aber Vorsicht: IIRC konfiguriert LiveConfig die Autoresponder etc auch via Sieve. Wenn der Kunde da also reinpfuscht, kann das alles an LC vorbei wieder zurückgesetzt werden.
Bei der Bearbeitung von E-Mailproblemen wäre es viel leichter, wenn die Hauptverzeichnisse mit der E-Mailadresse des Postfaches benannt wären.
Was zu Nichte gemacht wird, sobald der Benutzer sein Prefix ändert. Dann muss auch im Dateisystem verschoben werden.
Die Lösung mit der ID finde ich sogar ziemlich angenehm.
ZitatIm Moment führt der einfachste Weg ja über die /etc/dovecot/passwd.
Fast:
# doveadm user -f mail info@example.com
maildir:/var/mail/example/6/Nein.
*10 Zeichen*
dovecot.local.conf:
namespace inbox {
mailbox Drafts {
special_use = \Drafts
auto = subscribe
}
mailbox Junk {
special_use = \Junk
auto = subscribe
}
mailbox Sent {
special_use = \Sent
auto = subscribe
}
mailbox Trash {
special_use = \Trash
auto = subscribe
}
}Benutzer anschließend bearbeiten, nix ändern, direkt speichern. Dann wird "//priv/" daraus.
SOAP-API = Zugangspass zur API überhaupt
und
// check checksum 'LiNk-PaSsWoRd' = das generierte Passwort für den Link.
genau
ZitatIch danke für Deinen Klapps auf mein Haupt. Schönen Abend noch.
Keine Ursache - viel Erfolg!
Denn wenn ich das in der example richtig ersehe, ist dies erforderlich um die Userdaten ausgeben zu lassen. Z.B. Kundennummer oder persönliche Anrede.
In dem verlinkten Text wird nur auf das SOAP-Passwort eingegangen
Nö:
ZitatPasswort: das Passwort welches zur Erzeugung der Prüfsumme beim Aufruf der Zieladresse verwendet wird (siehe Abschnitt 8.3.2, „Programmierung eigener Inhalte“).
Vereinfacht: ein Menü-Eintrag bei "eigene Links" wird ein Passwort angegeben, welches dann bei "checkSession()" als Parameter übergeben werden muss. Welches, ist egal - muss nur zweimal das gleiche sein.
Dabei finde ich keine Info wie oder wo ich das 'LiNk-PaSsWoRd') erzeuge !
zufällig
ZitatKann mir da jemand mal einen Link angeben wo das Thema beschrieben ist?
also ist es (aktuell) nicht möglich z.B. 5 bestehende Confixx Systeme erst zu migrieren und dann zusammen zufassen? Gibt es andere Wege?
Gleich direkt ins LC Business migrieren. Beim Import-Vorgang kann der Zielserver angegeben werden.
Setzt natürlich voraus, dass jeder Confixx-Benutzer entweder umbenannt wird oder schon jetzt nur einmal vorkommt.
Das ist auch mit MySQL 5.7 noch nicht möglich.
Zitat von https://dev.mysql.com/doc/refman/5.7/en/account-names.htmlThe following netmask will not work because it masks 28 bits, and 28 is not a multiple of 8:
192.168.0.1/255.255.255.240
Wie kann ich den Benutzernamen bei einer Migration beinflussen?
Aus der Hilfe (--help):
* -i Interaktiv: beim Anlegen eines neuen Kunden/Vertrags
* nach der neuen Kunden-/Vertragsnummer fragenDas klappt auch - MySQL/FTp-Benutzer werden auch umbenannt, Datenbanken nicht. Dafür den Code anpassen:
# OPTIONAL: Datenbank beim Import umbenennen:
$dbase['name']=preg_replace('/^usr_web\d+_(.*)$/', "${subscriptionname}db$1", $dbase['name']);Zitat2) Nach der Migration muss ich aktuell manuell für alle Kunden Webapps und weiteres aktivieren. Kann man dies global für alle Kunden aktivieren? Bei über 100 Kunden je System ist dies sonst sehr aufwendig.
Eigentlich müssen nur die Angebote abgeändert werden.
Workaround
oder direkt ersetzen durch:
$command = preg_replace('/\/var\/www\/([^\/]+)\/html(\/.*)?$/g', '/var/www/$1/' . $OPTS['htdocs'] . '$2', $command);(neu: modifier /g. Ersetzt global)
Wenn das "html"-Verzeichnis gleich bleibt, kann der preg_replace aber natürlich auch weggelassen werden.
allerdings sehe ich für Verbindungen zu localhost keinen Vorteil darin(?).
Wenn im Code aber HTTPS verwendet wird, wäre der HTTPS-Port doch von Vorteil:
$lc_url = 'https://'. $lc_host .':'. $lc_port .'/liveconfig/hosting/mailpwd';8080 sieht nach HTTP-Port aus. Mal den HTTPS-Port getestet?
Wie bekomme ich das LC nun vom 2. Rootserver in den Hauptserver eingebunden? Das also die Verwaltung über ein Panel geht.
Wenn auf dem zweiten non-Business Server schon Kunden/Verträge/Accounts angelegt sind: gar nicht.
Ein "Import" von Standard-Servern ins LC ist aktuell nicht möglich.
Wenn der zweite Server leer ist: LC Server deinstallieren, LC Client installieren, im LC Business einbinden.
