: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.
: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.
Geht das irgendwie automatisiert, dass ich nicht alle Domain-Kunden nochmal einzeln einstellen muss???
Einfach das Angebot der Endkunden-Verträge ändern.
Erledigt/Lösung:
Der IPv6 Eintrag wurde rausgenommen und jetzt geht es.
Lag wirklich daran...
Dann aber schnell die IPv6-Connectivity wiederherstellen.
ZitatEr müsste normal ja den Code oben für alle Reseller/exklusiv IPs auch anlegen so wie als wenn es als gemeinsamme IP wäre?
Sieht so nach Bug aus - auch wenn die Zuteilung einer dedizierten IP für Reseller weder technisch noch organisatorisch notwendig ist: ServerNameIndication arbeitet ja trotzdem.
Hab aber irgendwie das Gefühl das er das total ignoriert. (Die Resellerdaten usw sind per Backup zurück gespielt worden nach der Anleitung hier im Forum)
Das lässt sich am leichtesten per "apache2ctl -S" verifizieren:
[2a02:74a0::1]:443 is a NameVirtualHost
default server default (/etc/apache2/sites-enabled/000-default.conf:71)
Existiert für einen Servernamen kein vHost, wird der Default verwendet. Das gilt für HTTP wie für HTTPS.
=> sicherstellen, dass das Default Certificate auch wirklich der Default ist.
=> ggf. die IP-Gruppe anpassen, damit die Konfiguration neu geschrieben wird.
Greifen jetzt beide Regeln oder nur die "letzte" vom Postfach? Würde eine E-Mail mit Wert 4 markiert werden oder nicht? Und was passiert mit einer Email, die den Wert 6 hat?
Es greift nur die erste.
Hab ich vergessen zu schreiben, die Umstellung der Lösch-Regeln erfolgte am Sonntag.
Nach dem Upgrade gingen bei uns bei einigen Servern die Logrotate-Regeln verloren, die Datei war schlichtweg leer.
Mit dem üblichen HC_REFRESHCFG wurden die Logrotate-Regeln wieder neu erstellt.