Beiträge von antondollmaier

Zitat von Roman

Es ist durchaus mittelfristig möglich, dass ein LCCLIENT von Rechenzentrum A zu B wechselt, während der LiveConfig-Master an der alten Stelle verbleibt.

Wie nun könnte ich ein Mitglied einer Multiserverumgebung auf diese Weise migrieren, ohne dass die Nutzerprofile verloren gehen? Könnte die IP eines Webservers dann beispielsweise einfach ersetzt werden?

Ungetestet:

Den alten Server 1:1 (rsync, ...) umziehen und danach nur die IP etc ändern.

Anschließend die IP-Gruppen anpassen, so dass statt der bisherigen IPs die dortigen neuen IPs verwendet werden.

Ein Suchen&Ersetzen wie bei Confixx ist nicht mehr notwendig.

Die Übernahme der Profile erfolgt unabhängig von LiveConfig, da ja das gesamte OS migriert wird!

Zitat

Ebenfalls wichtig: Wie können Nutzer bzw deren Veträge einzeln bei Bedarf migriert werden?

Derzeit ist keine Migration möglich.

Zitat von HBO

Das waren die häufigsten Ursachen für Spamversand auf unseren Altsystemen.

War hier eher das Problem von Trojaner-verseuchten Windows-PCs. Da ist die Passwort-Stärke dann egal, wird ja alles mitgesnifft...

Ansonsten: jo, mit Verletzung der Sorgfaltspflichten ist da genug zu tun. Im Zweifelsfall sperren, informieren und fertig. Die "Abrechnung von Aufwand für Säuberung" muss der Kunde dann ja sowieso beauftragen - oder er kümmert sich selber drum...

Zitat von HBO

Es ist für den Kunden doch etwas verwirrend als MySQL Host hier mail.xyz.de einzutragen.

db.xyz.de IN CNAME mail.xyz.de

Zitat von kenny_g

antondollmaier, danke für den Link. Muss man es global , kann man dies nicht individuell setzen, so dass nur auf Wunsch ein einfacheres Passwort erstellt werden kann?

Nur global.

Man kann an der LC-GUI "vorbei" immer alternative Passwörter setzen. Aber das kann der Kunde nicht ...

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"