Hat jemand einen Tipp?
Firewall, Prozess-Status, ...
Beiträge von antondollmaier
-
-
Was steht denn in den Logs dazu?
-
Die Idee behalten wir mal im Hinterkopf, bei "normalem" Mass-Shared-Hosting schießt das eher über's Ziel hinaus.
Dort ergibt PHP-FPM aber IMHO - selbst mit "ondemand" - wenig Sinn.
-
Wer sich etwas tiefer mit Control Panels, Shared Hosting und FPM beschäftigt wird feststellen, dass FPM und insbesondere Caching (nicht nur Opcache, sondern auch APC) hierbei ein ernstzunehmendes Problem darstellen. Es gibt Control Panels, denen das völlig Schnuppe ist - LiveConfig zählt nicht dazu.
Die Alternative dazu ist, für jeden Benutzer einen komplett eigenen PHP-FPM-Prozess (und nicht nur einen eigenen Pool) zu erstellen.
Ob das den Aufwand Wert ist, sei dahingestellt.
Ansonsten - mal wieder - vielen Dank für die detailreichen Ausführungen!
-
Gilt dann halt nur für neu angelegte Accounts.
Oder über apache.configureVHost() und LC.fs.is_dir().
-
Muss kurz einhaken:
Ich dachte eigentlich dass LiveConfig das erledigt, werden wir prüfen...
Nope, da wird nicht aufgeräumt. Hier sind es auch SEHR viele Validierungs-Dateien, die noch rumliegen.
-
So - habe einen Fehler gefunden, der leider größere Auswirkungen hatte.
Mit 5.6.37 (den neuen Paketen) ist per Default suhosin aktiv, das zuvor deaktiviert war:
Code./php-5.6-opt_5.6.35-1+stretch1_amd64/opt/php-5.6/etc/conf.d/suhosin.ini.disabled ./php-5.6-opt_5.6.36-1+stretch1_amd64/opt/php-5.6/etc/conf.d/suhosin.ini.disabled ./php-5.6-opt_5.6.37-3+stretch1_amd64/opt/php-5.6/etc/conf.d/suhosin.ini ./php-5.6-opt_5.6.37-5+stretch1_amd64/opt/php-5.6/etc/conf.d/suhosin.iniDas hätte definitiv als "breaking change" ins Changelog müssen.
Wir haben die "max_input_vars" erhöht - durch das aktive Suhosin wurde der Wert zwar übernommen, Suhosin hat über "suhosin.post.max_vars" bzw "suhosin.request.max_vars" die Änderung effektiv blockiert.
Da auch keinerlei Logging aktiv ist, gab es keinerlei Hinweise auf die Änderung.
-
:o
Jetzt fehlt mir beim AutoDeploy nur noch das gleiche - aber für den Client, so dass der auch noch automatisch im Business-Server konfiguriert wird.
-
Da bin ich bei euch, bei mir Funktioniert der Externe ZUGRIFF gar nicht.
Das eine hat mit dem anderen wenig zu tun - bitte getrennten Thread aufmachen (und MySQL-Dokumentation zum Thema "bind address" befragen). -
Wenn's so einfach und wirtschaftlich wäre etwas wie LiveConfig selber zu entwickeln (Know-How wäre hier vorhanden) hätten wir's auch selber gemacht. Ist es aber eben nicht. Bin daher dankbar für den Ist-Zustand und gebe einfach die Hoffnung nicht auf, dass der "Rest" auch noch kommt.
Genau das unterschreibe ich hier mal genau so wie geschrieben.
-
XEN ... migriert doch einfach auf KVM?
Wenn wir aber schon das Thema haben: das Update auf Stretch 9.5 sollte man vermeiden, oder den Apache vorher von mpm_prefork auf worker/event umstellen. Andernfalls ist HTTP/2 nämlich auch weg:
Zitat von http://metadata.ftp-master.debian.org/changelogs/main/a/apache2/apache2_2.4.25-3+deb9u5_changelogAlles anzeigenapache2 (2.4.25-3+deb9u5) stretch; urgency=medium
* Upgrade mod_http and mod_proxy_http2 to the versions from 2.4.33. This
fixes
- CVE-2018-1302: mod_http2: Potential crash w/ mod_http2
- Segfaults in mod_http2 (Closes: #873945)
- mod_http2 issue with option "Indexes" and directive "HeaderName"
(Closes: #850947)
Unfortunately, this also removes support for http2 when running on
mpm_prefork.
* mod_http2: Avoid high memory usage with large files, causing crashes on
32bit archs. Closes: #897218
* Make the apache-htcacheclean init script actually look into
/etc/default/apache-htcacheclean for its config. Closes: #898563-- Stefan Fritsch <sf@debian.org> Sat, 02 Jun 2018 10:01:13 +0200
-
Die sichert aber nicht die Benutzeroberfläche selbst ab, oder? Dafür braucht man doch nach wie vor ein gekauftes Zertifikat, oder sehe ich das falsch?
Weiterleitung, Typ Proxy, https://localhost:8443.
-
der manuelle Aufwand ist enorm groß, wenn ein Zertifikat auf über 70 Servern abgelaufen ist und ersetzt werden muss
LC Business. Dann gibt es einen Login für alle.Ansonsten als Übergangslösung: Subdomain als Proxy anlegen und diese über Let's Encrypt absichern. Klappt wunderbar.
-
LiveConfig macht nur einen "adduser" (oder useradd?), somit reichen die normalen Linux-Tools dafür aus:
-
Mhh aber ich werde doch admin Zugang nicht für WHMCS Imports öffnen
Die SOAP-API hat ein getrenntes Passwort. Was spricht also dagegen?
-
Das ist aktuell nicht möglich. Die SOAP-API ist für Imports vorgesehen und nicht für Kunden oder Reseller.
-
Fakt ist, ist möchte meine Webseiten von Kunden Webseiten trennen. Ja ich könnte unter einen Web Account sämtliche Webseiten Hosten, dies würde jedoch nicht die Grund Problematik ändern.
Getrennte (virtuelle) Systeme lösen hier deutlich mehr Probleme als nur getrennte IPs. Bei Spam, DDoS oder ähnlichem ist bei Secondary IPs dein "Managed Hosting" (früher nannte man das schlichtweg "Shared Hosting") auch betroffen.
-
Es gibt keinen technischen Grund, Webseiten auf unterschiedlichen IP-Adressen abzulegen und dadurch die IP-Adress-Knappheit weiter zu verstärken.
-
proftpd-basic hat in Debian 8 die Version "1.3.5-1.1+deb8u2" - sind dort die aktuellen Patches noch immer nicht enthalten?
nein.ZitatWelche Lösungsvarianten hätten wir in der Sache, ausser einem Upgrade zu Debian 9
keine.Zitat(funktioniert dort denn FTP über TLS einwandfrei?)
ja.ZitatKennt jemand einen FTP-Client, welcher mit SSL und Debian 8 einwandfrei läuft?
Nachdem das ein Server-Problem ist, ist der Client irrelevant.
-
Was geht ist res1 --> Kunde (alle Webs werden gelistet)
Statt auf "Kunden" links auf "Angebote":
https://www.liveconfig.com/de/…torial.hostingplans.xhtml
Dort dann eben die Log-Konfiguration ändern.
