Beiträge von kk

Danke für den Hinweis, ist ein Doku-Fehler - es ist wirklich "-m" zu verwenden.

Wir haben das Problem nach dem Neustart auf einigen Testsystemen auch schon beobachtet; letztendlich scheint es eine Timing-Sache zu sein: der "start-stop-daemon" kehrt zu schnell zurück bzw. beendet den laufenden LiveConfig-Prozess nicht wirklich; der anschließende Neustart schlägt dann natürlich fehl. Ich weiß nicht ob Sie das nun noch prüfen können, aber stand in der Spalte "nattch" (number of attached processes) wirklich "0"? Wenn LC korrekt beendet wurde (also nicht mit einem SEGFAULT abgestürzt ist) wird der Shared Memory nämlich immer freigegeben. Eventuell finden Sie auch noch Hinweise in der LiveConfig-Logdatei.

Wir werden das Init-Script morgen noch mal entsprechend überarbeiten, um an dieser Stelle etwas "robuster" zu sein.

Viele Grüße

-Klaus Keppler

Hallo Herr Niebergall,

ja, die Beschreibung hilft weiter
Im Grunde ist das auch jetzt schon ganz einfach möglich: richten Sie für den Exchange-Server einen DNS-Eintrag ein (z.B. exchange.example.org) und lassen dann die E-Mails durch LiveConfig an diese Adresse weiterleiten (z.B. in LiveConfig das Postfach info@example.org weiterleiten an info@exchange.example.org).
Der Exchange-Server sollte idealerweise mit einer Firewall so geschützt werden, dass eintreffende SMTP-Verbindungen nur von dem LiveConfig-Server aus erlaubt sind.

Viele Grüße

-Klaus Keppler

Hallo Herr Niebergall,

ich verstehe die Frage nicht so ganz - wie meinen Sie das mit dem SMTP-Relay? Könnten Sie vielleicht ein Beispiel nennen?

Viele Grüße

-Klaus Keppler

Wir freuen uns bekannt geben zu dürfen, dass LiveConfig ab Version 1.5.1 (r1751) (derzeit im Lab-Bereich verfügbar) auch den beliebten Webserver NGINX unterstützt.
Derzeit gilt die Unterstützung von NGINX noch als experimentell, ab der kommenden Version (1.5.2) soll auch ein Produktiveinsatz möglich sein.

Die Marketing-Floskeln spare ich mir an dieser Stelle (die werden noch für die Pressemitteilung gespart) - wer NGINX kennt, weiß um was es hier geht.

Im Gegensatz zu "anderen" Controlpanels konfiguriert LiveConfig NGINX nicht als Reverse-Proxy vor einen normalen Apache httpd, sondern erlaubt die native (direkte) Verwendung von NGINX als "echten" Webserver! Gerade bei Hochlast-Websites entfällt somit der "Apache-Flaschenhals".

In der LiveConfig-Oberfläche können sowohl Apache als auch NGINX parallel genutzt werden. Für jede einzelne Subdomain kann der Benutzer entscheiden, ob diese über NGINX oder über Apache laufen soll. Die Dokumentation wird derzeit noch entsprechend überarbeitet und sollte ab morgen Mittag hier online sein (Referenzhandbuch).

Derzeit gelten bei der Nutzung von NGINX noch folgende Einschränkungen:

• es werden noch keine access-Logs für NGINX-Zugriffe erzeugt, ebenso wird der Traffic derzeit noch nicht berücksichtigt (wir arbeiten noch daran, die access-Logs von Apache und NGINX im Parallelbetrieb in Echtzeit zusammenzuführen)
• die Installation von Anwendungen über den Application Installer ist prinzipiell auch auf NGINX-Subdomains möglich, allerdings werden die meisten Apps vorerst nicht richtig funktionieren (viele Anwendungen brauchen RewriteRules; wir arbeiten bereits daran diese entsprechend auf NGINX abzubilden)

Alle weiteren Funktionen (SSL-Unterstützung, passwortgeschützte Zugriffsstatistiken, etc.) sollten soweit komplett funktionieren.

PHP wird bei NGINX über FastCGI ausgeführt; es gibt ein neues init-Script /etc/init.d/nginx-php-fcgi, welches die entsprechenden Prozesse startet bzw. stoppt.

Unser Ziel ist es, NGINX zu 100% als Alternative zu Apache httpd im Shared Hosting nutzbar zu machen.

Feedback, Fragen, Fehlermeldungen und Verbesserungsvorschläge sind herzlich willkommen.

Viele Grüße

-Klaus Keppler

KURZANLEITUNG:

• Paket "nginx" installieren
• eine weitere IP-Adresse auf dem Server einrichten (NGINX kann natürlich nicht die selbe IP nutzen wie Apache)
• LiveConfig neu starten
• in LiveConfig unter Serververwaltung -> Web die Verwaltung von NGINX aktivieren, entsprechende IP(s) aktivieren. Eine neue IP-Gruppe für NGINX wird automatisch erzeugt.
• ggf. IP-Gruppe anpassen
• ab sofort kann im Menü unter Hosting -> Domains bei jeder (Sub-)Domain der gewünschte Webserver ausgewählt werden. Bitte auf korrekte IP-Konfiguration im DNS achten. (Die DNS-Verwaltung durch LiveConfig ist ab der nächsten Version möglich)

So, letztes Update der Preview-Version (v1.5.1-r1751) - es laufen noch letzte Tests, dann wird diese Version voraussichtlich am Donnerstag (23.08.) freigegeben:

• Unterstützung für NGINX-Webserver hinzugefügt (vorerst noch experimentell)
• Fehler beseitigt, wenn Hosting-Angebote/-Verträge ohne E-Mail-Postfächer erstellt werden sollten
• Lua-API ist nun fehlertoleranter wenn ein Script abstürzt das Mutex-Sperren hatte (keine Deadlocks mehr)
• Button zum Laden eines anderen Captcha-Codes hinzugefügt
• Code zur Captcha-Erzeugung aktualisiert

Zur neuen NGINX-Unterstützung gibt es gleich noch einen gesonderten Thread in diesem Forum.

Viele Grüße

-Klaus Keppler

Ich denke das heißt dann "Canonical URL".
Ist eine gute Idee und keine große Sache, wird also gleich in einem der nächsten Updates mit drin sein.
Den "canonical hostname" kann man dann in der Konfigurationsdatei (/etc/liveconfig/liveconfig.conf) einstellen. Über die Oberfläche wäre zwar etwas bequemer, aber führt dann zu Problemen, wenn sich der Servername geändert hat (dann würde man die Oberfläche ja nicht mehr erreichen).

Zitat

https://kundendomain.com:8443 --->redirect---> https://isp-mit-ssl.com:8443

Der Benutzer wird trotzdem eine Browserwarnung bekommen, da das SSL-Zertifikat auf einen anderen Namen als auf die ursprünglich aufgerufene Domain ausgestellt ist. Immerhin wird der Benutzer nach Bestätigung der Warnung dann auf die "richtige" Domain weitergeleitet.

Viele Grüße

-Klaus Keppler

Hallo,

bei der Apache-Konfiguration kommt es darauf an in welche Datei Sie das schreiben würden; die vHost-Konfigurationen werden von LiveConfig ohne Rückfrage überschrieben. Sie können aber im Benutzerverzeichnis eine Datei namens ".httpd.conf" anlegen, die dann per Include in die vHost-Konfiguration aufgenommen wird (zB. /var/www/web1/.httpd.conf). Dort könnten Sie die entsprechenden Proxy-Einträge einstellen.

Ich habe die Idee aber mal in die Wunschliste aufgenommen; wäre ja eigentlich auch ganz nett, das direkt über die Oberfläche konfigurieren zu können (dann müsste die Liste der Proxy-Domains auch nicht von Hand gepflegt werden)

Viele Grüße

-Klaus Keppler

Steht ebenfalls für v1.5.2 auf der Featureliste, wird also in Kürze verfügbar sein.
Hier fehlt v.a. noch die Eingabemaske zur Verwaltung des SOAP-Passworts (ist derzeit als Admin auch nur über die Kommandozeile (--init / LCINITSOAP) möglich)

Viele Grüße

-Klaus Keppler

Hmm, ist völlig legitim.
Derzeit gibt es diese Möglichkeit noch nicht, über das Berechtigungssystem können wir das aber recht bequem abbilden. Zur nächsten Version (1.5.2) wird es hierzu erweiterte Einstellungsmöglichkeiten bei den Hostingangeboten und -Verträgen geben (v.a. zur individuellen php.ini-Konfiguration); dort werden wir dann auch die Einschränkung für SSL-Zertifikate mit integrieren.

Steht also hiermit ganz weit oben auf der ToDo-Liste.

Viele Grüße

-Klaus Keppler

Ja... das ist so eine Sache. Steht auch bei uns schon länger ganz oben auf der ToDo-Liste.
Das Problem ist weniger, diesen einen Datenbankeintrag zu löschen damit der Server aus der Liste verschwindet, sondern vielmehr die ganzen Abhängigkeiten aufzulösen wenn auf einem Server schon irgendwelche Dienste/Kunden/Verträge provisioniert wurden.
Ich denke mal wir werden kurzfristig die Möglichkeit einbauen, noch "ungenutzte" Server zu löschen, alle komplexeren Fälle kommen dann schrittweise später dazu.

Viele Grüße

-Klaus Keppler

PS: ist also leider in v1.5.1 (morgen) auch noch nicht möglich - ich versuche aber das hier noch kurzfristig in einem der nächsten Updates unterzubekommen.

Gute Idee; wir haben ja in manchen anderen Anzeigen (z.B. bei den Berichten) auch schon die nötigen GUI-Elemente für eine "Füllstandsanzeige" in der Tabelle.
Dürfte in einem der nächsten kleineren Updates schon mit reinrutschen.

Viele Grüße

-Klaus Keppler

Ist eine gute Idee; das Handbuch wird ohnehin automatisiert erzeugt (Docbook XML), da stellt es auch kein Problem dar mal nur einzelne Kapitel zu extrahieren.
Wir haben vor einigen Jahren auch mal ein eigenes "Webhosting-Handbuch" auf Basis von Docbook XML erstellt, bei dem auch der Umgang mit den gängigsten FTP-Programmen, die Interpretation von Webalizer-Statistiken usw. erklärt wurde - ich werde das die nächsten Tage mal heraussuchen, vielleicht können wir das auch direkt mit berücksichtigen

Viele Grüße

-Klaus Keppler

Hallo Herr Groh,

Dropdown/Select wäre schon eine ziemliche Einschränkung, bzw. würde die Maske sehr unübersichtlich machen wenn man gleichzeitig auch "freie" E-Mail-Adressen eingeben möchte.
Ein vernünftiger Kompromiss wäre wohl eine AJAX-unterstützte "Vorschlagliste" (wie z.B. auch im Google-Suchfeld), welches passende Mailadressen aus dem selben Vertrag vorschlägt. Ich hab's mal in die Wunschliste aufgenommen, vielleicht können wir das bei der nächsten schwerpunktmäßigen GUI-Optimierung schon berücksichtigen.

Viele Grüße

-Klaus Keppler

Zur Firewall: die Idee ist naheliegend, steht aber im "unteren Drittel" der "Wunschliste". Derzeit gibt es schlicht noch wichtigere Funktionen; wer IPTables nutzen möchte, dem stehen bei jeder Distribution hauseigene Firewall-Scripte zur Verfügung.
Aber wie gesagt - es steht auf der Wunschliste und wird mittelfristig auch umgesetzt werden. Unserer Vorstellung nach auch so, dass z.B. auf einem OpenSUSE-System einfach die entsprechenden Regeln mittels der SUSE-Firewall (bzw. YAST) kommuniziert werden und wir so keine weitere Insellösung aufsetzen. Da gibt's aber noch viele Details zu klären...

Zum Brute-Force-Schutz: dieser ist im Code an den entsprechenden Stellen vorbereitet, bislang nur noch nicht umgesetzt. Das sollte keine große Sache sein, ist also voraussichtlich auch im nächsten Update (1.5.2) enthalten.
Wir speichern in diesem Fall das IP-Netz (IPv4: /24, IPv6: /64). Ab dem 3. erfolglosen Anmeldeversuch wird eine Warnung angezeigt und ein Hinweis auf die "Passwort-vergessen"-Funktion gegeben. Nach dem 5. erfolglosen Versuch wird dieses IP-Netz für 10 min geblockt (mit entsprechendem Hinweis). Beim ersten erfolgreichen Login bzw. nach 10 Minuten wird das IP-Netz aus der Blacklist wieder entfernt.
Wir planen jedoch keine Konfigurationsmöglichkeit für manuelle Blacklists/Whitelists auf IP-Ebene; das sollte Sache einer IP-Firewall sein.

Viele Grüße

-Klaus Keppler

Zitat

Ein kleiner unkomplizierter reload-Button würde da Abhilfe schaffen!

Ist seit einigen Tagen schon drin (irgendwo r174x), die neue Version ist ab morgen erhältlich. Der Captcha-Code wurde aktualisiert (sieht nun etwas anders aus, damit OCR-Software sich etwas schwerer tut), dafür ist nun auch ein Reload-Button dabei.

Viele Grüße

-Klaus Keppler

Zitat

Die Möglichkeit direkt aus Liveconfig einen Zugriffsschutz für ein Verzeichnis anzulegen (.htaccess).

Die Umsetzung dafür hat bereits begonnen, ist dann in der nächsten Version (1.5.2) enthalten.

Zitat

Confixx hat nämlich die fiese Eigenschaft die bestehende .htaccess einfach zu überschreiben

LiveConfig verwaltet die Passwortschutz-Einstellungen direkt in der vHost-Konfiguration, nicht über .htaccess-Dateien. So beißt sich das nicht mit Benutzereinstellungen. Und vor allem funktioniert das dann auch völlig transparent mit anderen Webservern (wie z.B. nginx). Mehr dazu morgen im Forum.

Viele Grüße

-Klaus Keppler

Ich vermute, dass Sie dem Kunden einen Reseller-Vertrag zugewiesen haben?
Domains können nur "Endkunden-Verträgen" zugeordnet werden. Ich schätze mal, das sollten wir auch etwas transparenter gestalten/dokumentieren...

Viele Grüße

-Klaus Keppler

Hallo,

haben Sie LiveConfig nach der Installation von ClamAV-Milter mal neu gestartet? Neue Pakete werden derzeit nur beim Start von LiveConfig erkannt.
Auf Squeeze wurde das gestern hier erfolgreich durchgetestet, werde mir das gleich mal auf Wheezy anschauen.

Viele Grüße

-Klaus Keppler

Dieser Fehler ist ab v1.5.1-r1739 (bereits als Preview verfügbar) beseitigt.

Und wieder ein Update der Preview-Version (v1.5.1-r1739

• Usability für Ajax-Tabellen-Pagination verbessert
• Usability beim "Abbruch" eines Popup-Fensters verbessert
• Fehler beseitigt: Admin konnte keine weiteren Benutzer anlegen wenn er unter "Mein Hosting" einen Vertrag mit nur einem erlaubten Benutzer hatte
• Apache wird neu gestartet (statt nur "reloaded") wenn es Änderungen an der IP/SSL-Konfiguration gab
• Virusscan für eintreffende E-Mails mit Postfix und ClamAV-Milter
• Maximale E-Mail-Größe in Postfix kann nun frei konfiguriert werden

Viele Grüße

-Klaus Keppler

[Nachtrag] Die meta-Pakete werden morgen (Freitag, 17.08.) im Test-Repository aktualisiert, so dass diese auch clamav(-milter) automatisch mit installieren.