Beiträge von antondollmaier

    Also wenn der wechsel LC => Plesk oder ISPConfig 3 so ohne weiteres möglich wäre, würden wir das sofort machen.


    Andersrum aber genausowenig.


    Zitat

    Support bei LC ist mehr schlecht als recht.Update kommen kaum noch in den letzten Monaten


    Oh?


    "Preview-Version: 2.3.0 (r4541) (03.04.2017)"


    Zitat

    Ich hab es schon mal gesagt, an unseren Kunden würde ich LC derzeit nicht mehr empfehlen


    Sowohl Plesk als auch ISPConfig haben - in meinen Augen - massive konzeptuelle Probleme: beide Lösungen wurden um das Objekt "Domain" als Kern-Komponente, statt um "Vertrag"/"Kunde", aufgebaut.


    Das heißt:


    - Alias-Domains sind bei beiden nur stiefmütterlich behandelt worden. Diese sind aber relevant, wenn mehrere Domains auf das gleiche CMS / den gleichen Ordner zeigen sollen (WP-Netzwerk, Multishop, ...)
    - ISPConfig hat sich IMHO selbst ins Abseits geschossen, da Subdomains noch suboptimaler gelöst sind. mod_rewrite-Gefriemel, wenn das Docroot geändert werden soll, empfinde ich nicht als elegant (auch für den Kunden nicht)
    - SSL-Zertifikate sind gerade bei Alias-Domains schwierig: ISPConfig erlaubt für Alias-Domains gar keine (eigenen) SSL-Zertifikate. Mit der neue Let's Encrypt-Integration wird ein MUltiDomain-Zertifikat beantragt, was gerade bei WP-Netzwerk suboptimal ist. Ich will persönlich keinem Dritten verraten müssen, welche Domains sonst noch so auf dem Shop liegen. Plesk kann das inzwischen besser, ja.


    Somit stellt sich (mir!) die Frage, ob zurück zu ISPConfig oder Plesk, gar nicht erst: "Änderung DocRoot", "mehrere Domains in einem Account" und "unabhängige SSL-Zertifikate" sind drei Eigenheiten von LiveConfig, die die anderen beiden Panels nicht (in der Form wie LC) bieten.

    - Port 80 kann nicht durch Nginx belegt werden, weil vermutlich Apache schon darauf läuft. "netstat -tulpen" kann das bestätigen.
    - LiveConfig ersetzt Dateien, ja. Die sollten dann auch nicht mehr geändert werden
    - LiveCOnfig verwendet PHP-FCGI für Nginx, nicht PHP-FPM.


    Das ist jetzt aber nichts, was sich nicht auch durch Suche im Forum/Google rausfinden hätte lassen können.

    Nun ich gebe die Hoffnung nicht auf, dass LC doch noch ein Herz hat und für Basic-Lizenz bereitstellt (von mir aus auch mit gewissen Einschränkungen oder Bonus-Obulus).


    Der Bonus-Obulus liegt bei ~7€/Monat.



    Zitat

    Würde gerne SSL-Zertifikate für meine bescheidenen Zwecke nutzen.


    Hat jemand von Euch/Ihnen schon Erfahrungen mit LC in Kombination mit certbot von Let's Encrypt?


    Ich bevorzuge dehydrated, allerdings ohne LiveConfig.



    Grundsätzlich müsste Certbot/dehydrated die Datei, die von LC mit einem Self-Signed-Zertifikat gefüllt wurde, periodisch ersetzen.


    Dateiname rausfunden und diesen (via Symlink, Deploy-Hook, ...) an das Dritt-Tool füttern. Zuletzt hoffen, dass LC das Zertifikat nicht periodisch überschreibt.

    Die Updates die Regelmäßig kommen mache ich schon alle mit, das heißt aber doch nicht, das ich jedesmal den Server komplett neu starten muss? In den Updates sind ja auch die Kernel-Updates mit dabei.


    Und genau die werden nur dann aktiviert, wenn neu gebootet wird. Kexec außen vor gelassen.


    Zitat

    Ich denke doch das braucht man bei einem Linux System nur ganz selten. Jedenfalls was ich von Systemadministratoren so gesagt bekomme (Hetzner,Antagus,Host Europe, etc.). Bin ganz stolz das ein Server von mir schon 732 Tage läuft ohne Mukken und immer alle Updates mitgemacht :)


    Herzlichen Glückwunsch. Aus dem Stegreif liegen mir zwei Local Root Exploits dafür vor.



    Zum Rest:


    - die proftpd.delay liegt auf einer Ramdisk. Natürlich ist die nach einem Reboot wieder weg.
    - die Slices sind normal.
    - Webmin nicht.

    Was wird denn in den "üblichen" Logdateien (/var/log/messages|syslog|auth.log, proftpd.log etc.) protokolliert, wenn so eine Anmeldung stattfindet?


    mod_delay protokolliert leider nichts. Das Problem hatten wir auch schon ein paar mal.


    Der Delay-Vorgang ist nur im Debug-Modus ersichtlich.

    - lokale Firewall prüfen. Das sieht nach klassischen Filter-Regeln für ausgehenden Traffic aus, die nicht mit TLS klar kommen.
    - Scorefile von ProFTPd löschen und danach neu versuchen:

    Code
    rm /run/proftpd.delay; systemctl restart proftpd.service

    auch wenn mich das mit den separaten Usern auch nervt: hier wird kein Confixx nachgebaut.


    Das ist richtig: dementsprechend wäre ein n:m-Modell, wie von HBO skizziert, von Vorteil:


    * beliebige Anzahl Benutzer
    * beliebige Anzahl Datenbanken


    Freie Rechtevergabe (RO, RW) der Benutzer auf die Datenbanken.


    ISPConfig hat das bereits so - wenn auch weniger flexibel (nur ein Benutzer zur DB).


    Allerdings: gibt größere Baustellen als das hier, IMHO.