Ja, das ist so beabsichtigt; diese Absenderadresse wird jetzt bereits verwendet wenn ein Benutzer sein Passwort vergessen hat und eine Mail zum Zurücksetzen erhält - künftig wird es noch weitere System-Mails geben.
Ohne eine Einstellung wird als Absender der Standardwert (meist liveconfig@<hostname>) verwendet, was i.d.R. ungültig ist bzw. keinen Sinn macht.
Ist das ein Problem?
Viele Grüße
-Klaus Keppler
Hallo,
ich schätze mal dass die Postfächer angelegt wurden noch bevor man für den Vertrag auch ein "Gesamt-Quota" für alle Postfächer angeben konnte.
Bitte bearbeiten Sie das Angebot des Vertrags (oder den Vertrag selbst) und stellen dort als Mail-Quota z.B. 20 GB ein - dann sollte wieder alles klappen.
Viele Grüße
-Klaus Keppler
Steht nun mit auf der Wunschliste.
Bis dahin: geben Sie den gesuchten Domainnamen einfach links in dem Suchfeld ein (Schnellsuche), dort werden dann alle passenden Domains und deren dazugehöriger Vertrag angezeigt. Gerade Reseller können somit schnell einen Kunden bzw. Vertrag lokalisieren.
Wurde auch bereits zur aktuellen Version (1.5.1-r1762) berücksichtigt. 
Wir haben uns lange Gedanken gemacht wie wir das am effizientesten lösen, da man mit LiveConfig auch von der selben Bildschirmmaske mehrere Instanzen (z.B. bei mehreren Kunden-Sessions) offen halten kann; Ansätze über serverseitige Speicherung oder Cookies sind damit ausgeschieden; auch möchte man normalerweise wieder ab Seite 1 starten, wenn man von einer anderen Seite kommt. Die nun umgesetzte Variante sollte hoffentlich den maximalen Komfort bieten.
Viele Grüße
-Klaus Keppler
Hallo,
vielen Dank für den Hinweis - das war tatsächlich ein Fehler im WSDL. Dieser wurde kurzfristig beseitigt, mit der gestern freigegebenen Version (1.5.1-r1762) sollte es also klappen.
Zum Bugtracker: wir setzen intern bereits einen Bugtracker ein (JIRA), planen aber mittelfristig auch einen "öffentlichen" Dienst anzubieten (voraussichtlich Bugzilla).
Viele Grüße
-Klaus Keppler
Danke für den Hinweis, wurde eben korrigiert (ab v1.5.1-r1765 enthalten).
Der Bugfix berücksichtigt dabei auch früher gelöschte Verträge (wenn das Programm nun einen Eintrag in der Logrotate-Konfiguration findet, zu dem kein Webspace mehr existiert, wird der Eintrag gelöscht).
Viele Grüße
-Klaus Keppler
Ab sofort steht LiveConfig 1.5.1 (r1763) zum Download bereit:
http://www.liveconfig.com/de/downloads
Das Handbuch wurde umfangreich erweitert: http://www.liveconfig.com/de/handbuch
Außerdem ist dieses auch als PDF-Datei (136 Seiten) erhältlich.
Die Änderungen zur Vorversion sind:
Die Online-Demo wurde auch schon aktualisiert, so dass dort Apache und NGINX im Parallelbetrieb zu sehen sind.
Viele Grüße vom LiveConfig-Team!
-Klaus Keppler
Hallo,
das sollte eigentlich nach wie vor dabei sein (wir haben es jedenfalls nicht entfernt). Beim Client-Paket (lcclient) ist es nicht dabei, ansonsten sollte es unter /usr/lib/liveconfig/ liegen.
Welche Distribution & LC-Revision exakt nutzen Sie?
Viele Grüße
-Klaus Keppler
Hallo,
danke für den Hinweis, hier hatte sich in einem der letzten Zwischenupdates ein Fehler eingeschlichen. Im Test-Repo ist nun r1756 erhältlich, das dieses Problem beseitigt.
In LiveConfig müssten Sie in der Serververwaltung -> Web bei NGINX die IPs noch mal neu zuweisen (also "IP-Einstellungen bearbeiten", dort die Checkboxen deaktivieren, speichern, wieder bearbeiten, IPs aktivieren, speichern). Somit wird die Haupt-Konfiguration für nginx noch mal neu erzeugt.
Viele Grüße
-Klaus Keppler
Hallo,
so wie es aussieht werden nach Änderungen an den SSL-Zertifikaten die entsprechenden Dateien nicht automatisch auf dem Server aktualisiert (werden wir mal im Code prüfen).
Kurzfristiges Workaround: öffnen Sie einfach die Domaineinstellungen der mit SSL konfigurierten (Sub-)Domain und klicken dort einfach noch mal auf "speichern" (ohne irgendeine Einstellung zu ändern). Dabei wird automatisch die SSL-Zertifikatsdatei neu geschrieben.
Der o.g. Fehler hängt aber vielleicht nicht mit der Reihenfolge im CA-Cert zusammen, sondern eher an fehlenden CA-Zertifikaten auf dem "Client"-Server (also dort wo Sie den git-Befehl eingeben). Führen Sie dort bitte einfach mal "aptitude install ca-certificates" aus.
Viele Grüße
-Klaus Keppler
Diesem Log-Auszug und der Beschreibung nach zu urteilen lief noch ein Child-Prozess* von LiveConfig der nicht ordentlich beendet war - das erklärt, warum der Shared Memory noch vorhanden war.
Der Grund für den hängenden Child-Prozess wiederum war vermutlich irgendwann mal ein Fehler/Abbruch in einem der Lua-Scripte, was zu einem Deadlock in einem der Lua-Threads führte - durch eine Änderung sollte dieses nun auch nicht mehr auftreten (wenn ein Lua-Script abbricht, werden künftig alle Ressourcen automatisch wieder freigegeben)
Falls noch mal irgendwas "Merkwürdiges" passiert geben Sie bitte Bescheid - LiveConfig soll eigentlich möglichst robust sein.
Viele Grüße
-Klaus Keppler
*) LiveConfig startet drei Prozesse: einen Watchdog, einen Server-Prozess für die GUI (als User "liveconfig") und einen Client-Prozess für die Konfigurationsarbeiten. Der LiveConfig-Client (lcclient) enthält praktisch nur den Watchdog und den Client-Prozess.
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:
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:
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:
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).
Zitathttps://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
