Beiträge von HBO

Ist der obige Auszug aus der Master oder Slave zones.liveconfig? Sind auf dem Master in keys.liveconfig beide Keys enthalten? Wir haben mittlerweile 2 Slave DNS mit LC im Einsatz und keine Probleme vorhanden.

https://www.liveconfig.com/de/partner-werden

Wäre es nicht generell einfach Benutzer und angelegte Datenbanken zu trennen?
So hätte man diesen doch nützlichen Vorschlag direkt inbegriffen.

Beispiel:
User 1 anlegen
User 2 angelen
DB 1,2,3,4 anlegen aber 1-3 User 1 zuweisen und DB 4 dem User 2.

So bleibt das System übersichtlich und auf Kundenwunsch doch individuell.

Das Ganze einfach wieder mit Auswahlfeldern .htaccess like erstellen. Ohne erstellten DB User kann man keine DB erstellen. Bei erstellten Usern gibts bei DB Erstellung die entsprechende Auswahl für die Zuweisung.

Den Bind entsprechend so konfigurieren, dass Zonen an den externen DNS per AXFR gehen. Und ja, das ist noch Handarbeit ohne GUI.

BIND installieren, hidden primary setzen und mit den externen DNS syncen.

Wir nutzen zwar nicht die acme.sh sondern letsencrypt.sh aber so schwer isses doch nicht per "echo" die Parts in die liveconfig.pem zu schreiben.

Und aus welchem Grund sollte man Key von CA und CERT trennen? Was hat man davon?

Moin,

die Frage wurde doch bereits schon bei Fragestellung bearbeitet. HTTP aktivieren und per 301 auf HTTPS weiterleiten.

Zitat von antondollmaier

- Let's Encrypt erfordert eine Validierung per HTTP.

Falsch! Validierung per DNS ist auch möglich, setzen wir mittlerweile auf allen Systemen ein die nur per VPN erreichbar sind und damit nicht offen am Netz hängen.

Hier zu finden: https://github.com/lukas2511/letsencrypt.sh/

Und ja, man kann damit sogar Zertifikate holen bei Domains die per Liveconfig im DNS (BIND) verwaltet werden (TransferKey ist das Stichwort).

Wer kein Geld hat darf sich nicht beschweren, wenn es bei einer kostenlosen alternative nicht genau das gibt was man sich wünscht...

Dann verwende dafür nicht LetsEncrypt, denn die sind genau dafür nicht gemacht: LetsEncrypt Zertifikate sind reine (Sub)Domain basierende Zertifikate. Wenn du mit einem Zertifikat mehrere Subdomains absichern möchtest so kaufe dir ein Wildcard Zertifikat, klappt wunderbar.

Das ist eigentlich auch soweit die vorgehensweise die in diversen Foren mitgeteilt wird sobald man nach dem Cronjob bzw Spamassassin bayes.lock Fehler aus den Logs googelt.

Hat wenig mit Liveconfig zu tun sondern einer schlecht gemachten Portierung der Distris von Spamassassin, CentOS hat die gleiche Problematik.

Sollte aber eigentlich gehen, wir haben da keine Probleme: https://letsencrypt.org/docs/rate-limits/
Arbeiten aber auch auf diversen anderen Systemen mit Scripten die sich Zertifikate holen und verteilen.

Wir hatten nur den Fehler, dass in der /etc/default/spamassassin bei -u "spamd" stand anstatt "debian-spamd". Alle Ordner hatten die Rechte debian-spamd:debian-spamd. Damit funktionierte dann auch der Cronjob ohne Probleme (Ubuntu 14.04 LTS).

Oder aber man macht es richtig und konfiguriert in /etc/default/spamassassin den "OPTIONS" Part korrekt, spart ein "chown" und lässt spamassassin korrekt laufen.

Ubuntu 16.04 wird laut Liste nicht unterstützt. Die entsprechenden Pakete kann man aber manuell installieren, diese werden von LC erkannt.

Dann doch bitte eine vernünftige Maillinglisten Software nutzen und nicht so einen "Schmuh" unterstützen.

Nachdem wir unseren anfragenden Kunden die Lage erklärten haben wir den Spieß umgedreht. Wieso also zu GMX und Co. weiterleiten? Die Kunden bezahlen bereits für eine Leistung, nun werden die Mails von GMX und Co. auf die bezahlten von uns gehosteten Adressen weiter geleitet.

Man muss sich nicht immer den "Großen" beugen...

Ich hatte vor einigen Wochen telefonisch hierzu angefragt, es wird daran gearbeitet.
Ist aber ein sehr komplexes Thema zBsp lokales Backup, entferntes Backup, Methoden, Vorhaltungen, Dateiformate, etc pp

Die Backup Funktion wird kommen, in welchem Umfang und wann ist offen.

Die Frage die man sich hier stellen möchte wäre doch ob man wirklich die Emails umschreiben möchte nur weil GMX und Co. (die verständlicherweise möchten, dass man deren Dienste nutzt und sonst kein Geld damit verdient) nun Weiterleitungen blockieren.

Das sollte man wie Herr Keppler sagte tatsächlich über Liveconfig in den PHP Einstellungen aktivieren (muss man ja nicht für den Kunden anzeigen lassen). Wichtig ist hier nur die Reihenfolge.

Ioncube sollte tatsächlich als erste Extension geladen werden, ansonsten die Angaben von Herrn Keppler nutzen. Wir haben zBsp für Ioncube die Ladereihenfolge Nummern 1-10 reserviert (aktuell 4 PHP Versionen im Einsatz).