Beiträge von antondollmaier

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.

Subdomain mit Typ Proxy auf https://localhost:8443/ anlegen.

Zitat von ManDal

Paradebeispiel ist der Firefox, mittlerweile in der aktuellsten Version lädt die Seite zwar aber das Zertifikat wird als unsicher gegenzeichnet... und das geht gar nicht.

Wenn Firefox einem Zertifikat nicht vertraut, gibt es eine fette Warnung. Die eigentliche Page wird dann nur nach expliziter Ausnahme-Bestätigung dargestellt.

Wenn das Schloß-Symbol durchgestrichen dargestellt wird, liegt es eher an inhaltlichen Problemen (Abruf von HTTP-Inhalten über HTTPS). Ein veraltetes SHA-1-Zertifikat schließe ich mal bei aktuellem LC aus.

Zitat von aziegler

der Vollständigkeit halber: ob das ein neuer Bug ist oder er schon ewig existiert kann ich nicht sagen.

Existiert schon länger.

Liegt vermutlich daran, dass mit jedem Webspace ein System-Account angelegt wird - und der ja auch als FTP-Account gilt.

Confirmed. *10z*