Beiträge von antondollmaier

Zitat von Mogwais

Das ist eine Serververwaltung wo mehrheitlich schon vorhandene Programme angesteuert wird(Apache, Postfix und co).

Weil manche Features in der Form, in der LiveConfig die integriert, noch gar nicht existieren: für den Message-Quota-Dienst sind bisher nur Integrationen über Milter oder Policy-Services (CBPolicyd!) vorhanden. Die "üblichen Verdächtigen" bei HowTos gehen aber nicht auf Quota-Einschränkungen bei sendmail (mail()-Funktion) ein. Also hinsetzen und selber in Postfix rausbekommen, wie das am besten läuft, so dass der Kunde auch eine saubere Rückmeldung bekommt.

Zitat

Ich muss dazu sagen das ich immernoch zufrieden bin, ich schaue mir regelmässig die Konkurrenz an aber unübersichtliche Blackboxen wie Plesk oder OS Frickeleien wie ISPConfig sind auch nicht der Weisheit letzter Schluß.

Sehe ich genauso.

Zitat

Solange bis das irgendwie mal komplett passt werde ich halt einige Sachen selber implementieren müssen. Was schade ist denn ich habe mehr als genug anderes zu tun.

Dito.

Zitat von andreas

Wenn die Kommunikation der(s) Entwickler(s) eben so dürftig ist, dann passieren solche sachen eben, die sich ganz schnell in eine Negative Richtung drehen.

Und wie genau verbesserst du dadurch die Motivation im Entwickler-Team, die Probleme schneller zu lösen?

Zitat von lebenszeit

Nun, die Meldung deutet auf ein DAtenbankproblem hin, was sagt
show full processlist;

Bei einer SQLite-Datei nicht möglich.

Rate dazu, eventuell doppelt laufende Prozesse zu prüfen.

Eine Umstellung auf mySQL schadet auch nicht.

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.