Beiträge von antondollmaier

http://www.liveconfig.com/de/h…advanced.lcdefaults.xhtml

*.minscore

gidf:

https://wiki.ubuntuusers.de/Upgrade/

Quota voll.

Zitat von ManDal

Und ob das ein Vorteil hat genau dann wen der Exchange der Haupt-MXer ist...

Wir drehen uns im Kreis.

Die Gründe, warum kein Backup-MX notwendig ist, hat Herr Keppler genannt (Auto-Retry durch die Absender-Mailserver, bis zu 4 Tage lang).

Zitat

alles andere mit POP3 Connector ist nur für kleine Umgebungen wirklich nutzbar... bei 100 Mailboxen aufwärts kannst du so etwas vergessen und genau da macht es sinn wen ein externer Backup MX da ist...

Der POP3-Connector ist seit mindestens Exchange 2012 nicht mehr vorgesehen, es wird die Einrichtung des Exchange-Servers als direkter Mailserver empfohlen.

Noch eine Ergänzung:

Zitat

Ich betreibe zurzeit bei einigen Kunden einen Backup MXer nur mag ich nicht das die komplette Domain erlaubt ist sondern nur die Mail Adressen die es auch pro Domain gibt.

Die Lösung existiert: http://www.postfix.org/postcon…ject_unverified_recipient

Zitat von ManDal

Naja gibt durchaus Einsatzmöglichkeiten für Backup MXer die meisten die ich betreibe sind nicht mit LC verbunden sondern eher bei Exchange Server die im internen Firmennetzwerk stehen. Da kann oder kommt es leider immer mal wider vor das die Anbindung Probleme macht und der Server zwischenzeitlich nicht erreichbar ist...

In beiden Fällen bringt der Backup-MX keinen Vorteil.

Wie Herr Keppler schon geschrieben hat:

Zitat

Jeder halbwegs vernünftige Mailserver versucht zudem bei Nichterreichbarkeit des Zielsystems eine erneute Zustellung in einem dynamischen Intervall (z.B. erstmals nach 5 Minuten, dann 4x alle 15 Minuten, dann stündlich, usw...).

Letztendliche Empfehlung: Mails immer über den "Haupt"-MX abwickeln, welcher einen Transport zum Exchange-Server konfiguriert hat (damit ist auch DynDNS kein Problem mehr!) und gleichzeitig als Relayhost für ausgehende Mails fungiert.

Das widerrum könnte man in LiveConfig noch relativ einfach hinterlegen. Zusätzliches Attribut bei einer Domain, woraufhin dann ein Transport in Postfix hinterlegt wird. Antispam und Antivirus sowie Queueing durch den LC-Server gibt's gratis oben drauf.

Was hat Composer mit SSH und/oder LiveConfig zu tun?

Respektive warum sollte gerade Composer in der genannten Konstellation ein Sicherheitsrisiko darstellen?

Antwort: ob nun PHP, Composer oder Perl - aus dem Setup sollte regulär nicht ausgebrochen werden können.

Sicherheitslücken im Linux-Kernel, dem SSHd oder anderen Anwendungen mal ausgeschlossen. LiveConfig hat da noch am wenigsten damit zu tun.

Den "/" bei den Conditions sowie der Rewrite-Rule rauslassen.

Zitat von Umbriel

Mir ist nicht ganz klar, wie ich den LE client mit LiveConfig in Einklang bringen kann.

Idee:

- SSL-Zertifikat regulär in LC erstellen
- Selbst-Signiert
- Domain(s) konfigurieren
- Zertifikat mittels LE-Client und Webroot-Methode validieren/abholen
- in den Apache-Configs die Einträge zum SSLCertificateFile finden
- die dort angegebenen Dateien gegen Symlinks auf die LE-Zertifikate im "live"-Verzeichnis ersetzen
- dem LE-Client einen Apache-Reload folgen lassen

Klappt aber nur, wenn LiveConfig die SSL-Zertifikate nicht nochmal ersetzt.

custom.lua:

postfix.LOCALCONFIG = {}
postfix.LOCALCONFIG['relayhost'] = "[$YOURRELAYHOST]"

Wird die korrekte g*Sales-Version für PHP 5.6 verwendet? Ist das überhaupt der korrekte Zend Guard Loader?

Was sagt der Zend-Guard-Test für PHP 5.6?

a2dismod php5_cgi; service apache2 restart;

Ein Upgrade auf Debian Jessie wäre außerdem auch anzuraten.

Zitat von ManDal

Alternativ kann auch mit dem Apache Module mod_proxy gearbeitet werden ist aber etwas unschön und würde ich so nicht machen... (auch ungetestet!)

Und wo soll jetzt da der Unterschied zur Proxy-Methode via LiveConfig sein? Mod_rewrite nutzt mit "[P]" auch mod_proxy(_http).

Was steht im Log dazu?

mod_proxy sowie mod_proxy_http aktiviert?

Achtung außerdem: LiveConfig sendet https-only-Cookies.

Thunderbird verwendet die AutoConfig, so dass diese DNS-Einträge überhaupt gar nicht notwendig sind.

Zitat von RB-Media-Group

entweder auf Root

Was ist mit Redirects (non-)www nach www?
Was ist mit Webapps?

Zitat

oder die Einstellungen von http direkt übernehmen, weil man ja nach der SSL Installation kaum ein anderen Verzeichnis als vorher verwenden wird.

Sicherlich:

HTTP: Redirect nach HTTPS
HTTPS: Ordner "example.com"

Zitat von RB-Media-Group

und zusätzlich sollte gleich Webspace aktiviert werden!

Mit welchem Zielordner? Identisch zu HTTP oder doch anders?

Die Auswahl sollte man dem Kunden schon noch überlassen.

custom.lua, Postfix Localconfig:

http://www.liveconfig.com/de/h…tml#advanced.mail.postfix

liveconfig-meta weglassen und stattdessen die benötigten Pakete manuell installieren.

Postfix unterstützt kein SNI, womit für jedes Zertifikat eine eigene IP benötigt werden würde. (quelle)

Dovecot könnte SNI (Quelle). Die Zertifikate müssten lediglich in die Config eingebunden werden.