Beiträge von antondollmaier

  • Angezeigte Datenbanken

    Zitat von besterwosgibt

    Führt das nicht dazu, dass ich für jede Datenbank die User/Password-Kombination neu vergeben muss? Die User existieren bereits, genau wie die Datenbanken.


    SOAP-API-Calls verwenden, wenn es zu viel ist.


    Aber ohne User/Passwort anzugeben wird es nicht klappen.



    Mit ein Grund, warum wir hier auch IMMER anraten, ALLE Datenbanken/FTP-Accounts/... auf einem Server mit dem Control Panel zu verwalten, sobald ein Control Panel da ist. Bei anschließender Migration vergisst man entweder die Hälfte, oder hat einen massiven Aufwand, diese "externen" Daten nachträglich zu migrieren. Mal von den Nachteilen bei der aktuellen Nutzung abgesehen...

  • LiveConfig - Migration bestehender Multiserver-LCCLIENTS in anderes RZ

    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.

  • Individuelles Passwort 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...

  • Backup MX

    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

  • Backup MX

    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.

  • Verwendung von Composer in einer LiveConfig Shared Hosting Umgebung?

    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.

  • Installation

    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.