Beiträge von antondollmaier

Empfehlung:

RewriteEngine on
RewriteRule ^(\.)\.html $1.php

HTML-Dateien von PHP parsen lassen ist dezent suboptimal, Stichwort "User darf HTML-Dateien hochladen".

Zitat von lebenszeit

It might be possible to use one ID within different users.

No, there's a unique constraint on Let's Encrypt Login Keys.

Zitat von hermann

Meine Frage:
Anscheinend hat die Löschung des Cronjob über die LiveConfig-Oberfläche nicht richtig geklappt - wo kann ich nachschauen, ob da noch etwas rumliegt, was gelöscht werden muss - die /etc/cron* habe ich durch, da ist nichts drin?

crontab. ("-e -u xxx")

Berechtigungen des LC-Benutzers prüfen.

Zitat von Lite

Dort ist das ganze auch dokumentiert und stimmt mit dem was kk geschrieben hat überein: Klick

*sign*

Chroots erzeugen mehr Aufwand und größere Probleme, als sie letztendlich nützen.

Zumal, wie Herr Keppler schon schrieb, man über PHP/Python/CGI sowieso genau das auch ausführen kann, was man über SSH machen könnte.
"Einsperren" mag über open_basedir und den safe_mode mit PHP 5.x noch funktionieren, wird mit PHP7 aber schwer und mit Python gar unmöglich.

Ganz abgesehen davon, dass open_basedir von PHP zwar einen Call von fopen() oder file_get_contents() verifiziert. Den identischen Aufruf von "system('cat ...');" hingegen nicht.

Warum also den Benutzer bei SSH künstlich einschränken und den Aufwand bei der Pflege erhöhen, gleichzeitig aber die Webserver-Umgebung weiterhin "offen" lassen?

Zitat von t.maffert

Ok das Fazit ist also: PHP kompilieren und alles ist gut!

Oder die richtigen Pakete verwenden.

Zitat von t.maffert

Wie macht ihr das denn mit den Modulen? Ihr habt doch sicherlich nicht nur ein Ordner für die Module, für alle PHP-Versionen oder?

Jede PHP-Version hat ein eigenes Scan-Dir und somit eigene Module etc, alles getrennt.

Welche RPM hast du denn da genau runtergeladen? Das sieht nämlich nicht danach aus, dass du die Daten so verwendest, wie das vom RPM vorgesehen ist/war.

Zitat von t.maffert

Ne, ich habe nur die RPM's entpackt .. Aber das sollte ja auch funktionieren ;D

Nö, sollte es nicht.
Die PHP-Versionen wurden offenbar so compiliert, dass sie in /etc/php.d noch nach zusätzlichen ini-Dateien suchen.

Also diesen Ordner aufräumen und alle Extensions (warum man das auch immer will) direkt in LiveConfig verwalten, wodurch die Anweisungen mit in die Kunden-php.ini aufgenommen werden.

Zitat von Aybee

Der Reseller Bug den ich vor Monaten schon bemängelt habe, ist immer noch offen, sowas ist ein absolute no-go einfach wenn der Reseller nutzen kann soviel er will die Funktion ist völlig nutzlos so.

Wir haben unseren Resellern schlichtweg dedizierte Maschinen hingestellt. Erspart viele andere Probleme.

Aber ja, das ist schon länger offen.

Zitat

Das LC immer noch das Olle FastCGI nutzt und warum nicht endlich mal auf php-fpm => Wenn du schon mit Kleinigkeiten wie Docroot ändern kommst

Docroot ändern ist Webserver-unabhängig, PHP-FPM hingegen nur für Nginx. Dort gibt es übrigens auch Probleme (APC-Cache ist global für alle Pools!).

Zitat

Man darf auch nicht vergessen das ISPC nichts kostet im gegensatz zu LC wo ich gewisse dinge auch erwarte wenn es Gebühren Kostet.

Korrekt.

Zitat

Umzüge mit LC auf andere Server sind grausam, ich/wir haben das nun 3 mal gemacht und jedes mal lief was anderes schief

Dann macht ihr die Umzüge anders als wir.

Rsync des gesamten Servers - anschließend Anpassung der Netzwerk-Konfiguration sowie der IPs etc. in LiveConfig. Läuft.

Zitat

sowas ist mir bei Plesk nicht einmal passiert.

Die letzten Umzüge, die ich mit dem Plesk-Migrations-Tool (Backup/Restore) gemacht habe, liefen alles andere als "problemlos". Ist aber auch ein Weilchen her.

Letztendlich: Plesk gibt es nicht erst seit gestern. Hat mit Parallels/Ingram/Odin/Yippie-Yeah GmbH aber auch etwas mehr Kapital und damit auch Manpower zur Verfügung.

Wenn dir Plesk besser gefällt - bitte, es hindert dich keiner, nur noch das einzusetzen.

Ich habe mit Plesk meine Probleme und daher weiterhin die Hoffnung, dass die bestehenden Probleme gelöst werden. Ein produktiver Einsatz von LiveConfig ist problemlos möglich. Das Setup geht deutlich schneller als Plesk oder ISPConfig, preislich empfinde ich es auch attraktiver.

Und zum Thema "SSL so schön einfach": die Nachteile bei der Umsetzung habe ich oben schon skizziert.
Ich bin gespannt, wie die Dialog-Box dazu bei LC ausfallen wird.

Zitat von Aybee

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.

Offenbar läuft der dazugehörige FastCGI-Prozess (nginx-php-fcgi) nicht oder öffnet nicht diesen Socket.

Zitat von a-s

Wenn das nicht unterstützt wird, welches wird dann von LiveConfig unterstützt, damit HTTP/2 läuft.

Aktuell schreibt LiveConfig nur den "ssl"-Paramter mit bei der "Server"-Anweisung dazu. HTTP2 fehlt also.

Serververwaltung -> Web. HTTPS für die IP-Gruppe aktiviert und "gemeinsam"/SNI gewählt?

Zitat von Maxx

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.

Zitat von thopoh

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.

Zitat von kk

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:

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

Wurde der ProFTPd-Server schon mal über LiveConfig "neu konfiguriert"?
Was sagt das Proftpd-Log?

Zitat von thomas16

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.