Beiträge von antondollmaier

Zitat

wo man zig neue Domains zur Registrierung eingeben kann -> eine Vorlage auswählt und schwups alles automatisch erfolgt von der Registrierung bis zur DNS-Vergabe etc.!
=> In LiveConfig nur noch die Domains alle eingeben dann -> Vorlage aktivieren -> alles wird entsprechend eingerichtet (wäre so schön)!

Baue ich dir mit SOAP-API in ca. 2 Stunden (Python-CLI-Script, das als Parameter die neuen Domains bekommt).

Wie gesagt, bei LiveConfig seh ich noch größere Baustellen mit höherer Priorität, gerade bei "Reseller".

Zitat von Johnny

=> Warum soll man für jede neue Domain die man anlegt zig mal den gleichen Vorgang durchführen - wenn es auch mit einer Vorlage komplett automatisiert geht -> siehe www. Konfiguration und auch SSL-Konfiguration, was ja auch völlig automatisiert geht! Sehr große Zeitersparnis!

Persönliche Meinung:

- "webmaster@" und ähnliche Mailadressen haben keinerlei Relevanz. Hatten sie noch nie.
- Wer Domains in dieser Anzahl verwaltet, muss automatisieren. Nachdem LiveConfig die Abrechnung und auch die Domain-Registrierung/Verwaltung nicht mitbringt, muss beides extern erfolgen.
Wenn dort eine neue Domain hinterlegt wird, kann dann direkt über SOAP die Domain in LiveConfig angelegt werden.

Der Vorgang lässt sich dann problemlos um Mailadressen erweitern.

Zitat

=> Ich sehe hier auch sehr großes Potenzial LiveConfig für Reseller als top Tool zu etablieren!

Dafür sind ehrlich gesagt noch ganz andere Schritte, mit höherer Priorität, notwendig.

(schon mal versucht, einem Reseller nur 5 Datenbanken zu erlauben?)

Das kann bequem über die SOAP-API realisiert werden, wenn die Domain angelegt wird.

Außerdem stellt sich mir die Frage, welche Relevanz die "webmaster"-Mailadresse hat. Für SSL-Validierungen kann zwischenzeitlich auf DNS-Einträge oder HTTP-Validierung zurückgegriffen werden.

Zitat von BMK-Media

da ist ein Wildcard Zertifikat einfacher als für alle 8000 Subdomains ein Zertifikat zu erstellen bzw. erstellen zu lassen.

8.000 SSL-Zertifikate unter der selben Subdomain funktionieren nicht - da greifen die Rate-Limits von Let's Encrypt.

Zitat von kk

Weder POP3 noch IMAP unterstützen eine Zwei-Faktor-Authentifikation im Protokoll

Möglich wäre es aber, "App-Passwörter" zu vergeben: jede Anwendung hat ihr eigenes Passwort und kann dann bei Missbrauch gezielt als Quelle identifiziert werden.

Ist zwar kein 2FA, aber ein zusätzlicher Sicherheits-Feature.

Zitat von Mogwais

Das Problem mit den nicht umziehen können ohne viele Endgeräte anzufassen bleibt so aber trotzdem.

Wo genau soll "Kunde nutzt mail.example.com als IMAP-Server" helfen?

- Office365 hat gar kein IMAP, zumindest nicht per Default. Den tatsächlichen IMAP-Server gibt's nur via Autodiscover.
- GMail nutzt immer "imap.gmail.com". Egal, welche Kunden-Domain das ist.
- die Migration auf einen lokalen Exchange-Server sieht nochmal komplett anders aus.

"White-Label-Reselling" endet spätestens beim Netzwerk (WHOIS!), meistens schon früher (VM-Host, ReverseDNS).

Komisch auch, dass solche Feature-Requests nur an uns "kleine" rangetragen werden. Oder hat sich schon mal jemand bei Microsoft beschwert, warum "autodiscover.outlook.com" nicht als Whitelabel existiert?

Zitat von BMK-Media

Das liegt daran, das ich den max_score bzw. (required) nicht Vernünftig filtern konnte für meinen filter.

Der Reject innerhalb von Sieve verursacht effektiv einen Bounce, was tunlichst zu vermeiden ist (vgl. http://www.backscatterer.org/).

Die identische Funktion, nämlich eine Mail ab einem gewissen SA-Score gar nicht anzunehmen, wird im Übrigen genau von LCSam realisiert: der Score in LiveConfig zu "Schwellwert bei Ablehnung" realisiert genau das.

Zitat von kk

die Energie für solche Kunden sollte man lieber in AutoConfigure/AutoDiscover investieren

Sehe ich persönlich auch so.

Insbesondere erhöhen die eigenen Subdomains dann auch den Support-Aufwand ("bei Kollege A geht's - ich erhalte komische Fehler!" "du hast auch Eudora Mail von 2006 im Einsatz, der Kollege nutzt den neuesten Thunderbird, der SNI unterstützt").

Läuft Spamassassin? (systemctl status spamassassin) Vermutlich aber nicht.

Zwei Vorschläge:

- statt über "find" zu gehen, "doveadm search" sowie "doveadm fetch" verwenden. Weniger Bash-Foo und somit weniger fehleranfällig.
- Dovecot hat Plugins für diesen Zweck: https://wiki2.dovecot.org/Plugins/Antispam

Ungetestet: was spricht dagegen, den Eintrag in die conf-enabled global zu aktivieren? Muss es wirklich bei jedem VHost aufgenommen werden?

("deny from all" ist Apache 2.2-Syntax. Bitte bei Apache 2.4 "require all denied" verwenden)

Zitat von kk

In unserem Test-Repository sind ab sofort die PHP-Version 5.6, 7.0, 7.1, 7.2 und 7.3 für Debian Buster enthalten (inklusive der üblichen Extensions wie bislang auch für Debian Stretch etc).

:heart:

Zitat

Derzeit planen wir nicht, auch noch ältere PHP-Versionen bereitzustellen (PHP 5.6 und 7.0 sind ja auch schon End-of-Life).

sehr schön.

Zitat von informant

Eigener DNSBL WhitelistServer wäre ja schwachsin dafür, das wäre so die einzige Idee von uns, wie man das umgehen könnte, da Whitelist DNSBL ja den normalen DNSBL deaktiviert, was eigentlich eine Whitelist auch tun sollte. => rbldnsd <=

rbldnsd ist die sinnvollste Lösung, falls die dnswl.org nicht nutzbar wäre.

Nutzer-spezifische Domain-Whitelists können, wie schon mehrfach geschrieben wurde, zum Zeitpunkt der Blacklist(!)-Prüfung nicht realisiert werden.

Zitat von BMK-Media

Version 2.7.4 (r5214)

Ah ok, dann muss ich wohl warten, dachte es wäre drin, weil im return vom wsdl folgendes steht

Stimmt, mein Fehler.

Die Funktion ist bereits da, nur noch nicht im Handbuch.

Aber die Möglichkeit, Weiterleitung o.ä. zu setzen, wie bei HostingSubdomainAdd, gibt es trotzdem nicht - damit bleibt mein Hinweis trotzdem bestehen: "aktuell nicht möglich".

Zitat von BMK-Media

Kann mir da einer helfen?

Zur not auch, mit Subdomain löschen und neu anlegen.

"HostingSubdomainEdit" gibt es in Version 2.7 nicht, genausowenig wie "HostingSubdomainDelete". Somit ist das geplante Vorhaben aktuell gar nicht realisierbar.

Mit Version 2.8 soll es wohl möglich werden:

Zitat von https://www.liveconfig.com/de/lab

Bearbeiten des SSL-Zertifikats einer Subdomain nun mittels SOAP-Funktion HostingSubdomainEdit() möglich

Zitat von kk

Ab v2.8 prüft LiveConfig übrigens selbst die IPs der Domains (mittels integriertem DNS-Resolver). Wenn einzelne IPs nicht stimmen oder es z.B. ein DNSSEC-Problem gibt, wird gar nicht erst eine Bestellung ausgelöst, sondern eine entsprechende Fehlermeldung angezeigt.

:heart_eyes:

Zitat von hchristo

kk Wie Sie sehen wollen wir alle eine Backup Lösung haben, wie schauts aus? Ist da schon was in Planung

Schaut mal

Zitat von https://www.liveconfig.com/de/forum/threads/2994-Preview-v2-8-0?p=17146&viewfull=1#post17146

der neue Backup-Service (lcbackup) ist noch nicht in die GUI integriert

Es gibt den Backup-Service also schon.

Zitat von ewuewu

Ich würde ihn nun gerne sukzessive bis zur aktuellen Ubuntu Version upgraden.

Weiss jemand, wo hier evtl. Stolperfallen lauern. Gibt es ein HOWTO oder 'best practices' für das Upgrade?

Für LiveConfig sind hier keine Besonderheiten nötig. "Einfach" an die regulären Update-Anweisungen (14.04 LTS -> 16.04 LTS -> 18.04 LTS) halten.

Zitat von dicker

In den Logs kann ich nichts finden.
Wie gesagt, es betrifft 3 Server gleichzeitig. Das ist schon eigenartig.

Die alle aus der gleichen JoomISP-Installation gepflegt werden?

Zitat

Wenn ich curl -XPOST https://meinedomain:8443/liveconfig/soap?wsdl

dann kommt -bash: curl: command not found

curl ist installiert.

PHP-CURL möglicherweise ja, "curl" in der Shell offenbar nicht.

Zitat von dicker

Jetzt kommt auf allen Liveconfig-Servern folgende Fehlermeldung.

Es ist ein Fehler aufgetreten
0 SOAP-ERROR: Parsing WSDL: Couldn't load from 'https://meinedomain:8443/liveconfig/soap?wsdl&l=admin&p=meinpasswort' : failed to load external entity "https://meinedomain:8443/liveconfig/soap?wsdl&l=admin&p=meinpasswort"

Wurde PHP-Fehler-Log geprüft?

Was passiert beim Aufruf der URL via CURL als POST? (curl -XPOST https://....?wsdl)