Danke, guter Hinweis. Wir werden künftig beim Anlegen/Bearbeiten von Hostingverträgen gleichzeitig einen alias-Eintrag mit pflegen (ist nur eine Kleinigkeit in der Implementierung, also vermutlich schon im nächsten Update enthalten).
Viele Grüße
-Klaus Keppler
Das Limit ist hardcodiert in den regulären Ausdrücken, welche die CGI-Eingaben prüfen. Wir haben das aber nun auf 4KB verdoppelt und zeigen außerdem die Anzahl der noch verfügbaren Zeichen an (ab v1.5.1-r1729, aktuell im Lab-Bereich).
Ist das so ok?
Viele Grüße
-Klaus Keppler
Die Preview-Version wurde eben wieder aktualisiert (v1.5.1-r1729). Im Zusammenhang mit SQLite kam es in den vorherigen beiden Preview-Releases öfters zur Fehlermeldung "DATABASE LOCKED", woraufhin die SQLite-Datenbank bis zu einem Neustart von LiveConfig keine Schreibzugriffe mehr akzeptierte (das ist dem etwas "schwierigen" Verhalten von SQLite in Multithreading-Umgebungen zu verdanken).
Außerdem gab es noch kleinere Änderungen und Bugfixes - wenn alles passt werden wir diese Version in den nächsten Tagen produktiv freigeben (die nächsten Features warten schon in v1.5.2).
Viele Grüße
-Klaus Keppler
Hallo,
der Autoresponder-Text ist vermutlich zu lang (ich habe das eben im Code geprüft - erlaubt sind max. 2 KB = 2048 Zeichen).
Wir werden kurzfristig das Eingabefeld so erweitern, dass die Anzahl der noch verfügbaren Zeichen mit angezeigt wird (wie auch für die Länge der Mailsignatur bei den Reseller-Einstellungen).
Viele Grüße
-Klaus Keppler
Hallo Herr Linnemann,
dieser Fehler ist mit dem nächsten Update beseitigt; wenn Sie möchten können Sie einfach die im Lab-Bereich bereitgestellte Version installieren (diese Version ist soweit stabil und wird in Kürze offiziell freigegeben).
Eine nähere Beschreibung sowie einen Workaround finden Sie hier im Forum.
Viele Grüße
-Klaus Keppler
Hallo Herr Linnemann,
das tut mir leid dass LiveConfig nicht so reibungslos startet wie es das eigentlich sollte. Ihrer Beschreibung nach hat sich vermutlich ein interner Client-Prozess von LiveConfig aufgehängt (das würde erklären, warum sich LC nicht neu starten lässt und auch keine Änderungen am Server mehr durchführt).
Bitte beenden Sie LiveConfig (erst mit "/etc/init.d/liveconfig stop", ansonsten mit "killall -9 liveconfig"); sollte es sich anschließend nicht starten lassen, befolgen Sie bitte die Hinweise aus dem Handbuch unter http://www.liveconfig.com/de/h…oubleshooting.server.html (dort nach "Server already running" suchen).
Perfekt wäre es dann natürlich, wenn Sie uns bitte die Log-Datei /var/log/liveconfig/liveconfig.log an info@liveconfig.com schicken könnten, damit wir herausfinden können, wo das Problem lag.
Besten Dank & viele Grüße
-Klaus Keppler
PS: derzeit gibt es ja bereits einen Watchdog-Prozess, der sich darum kümmert eventuell abgestürzte Child-Prozesse neu zu starten; es ist geplant diesen so auszubauen, dass auch "hängende" Prozesse erkannt und ggf neu gestartet werden; das löst zwar nicht das eigentliche Problem (das wollen wir so oder so analysieren und beseitigen), aber es mindert die Symptome im Betrieb.
Hallo Herr Groh,
ZitatVorweg: Wir testen gerade LiveConfig in einer etwas komplexeren Konstellation und sind - ehrlich und ohne Übertreibung gesagt - am Rande der extatischen Begeisterung!
Vielen Dank, das freut uns! 
ZitatWird eine eMail-Adresse ohne Postfach und ohne Autoresponder eingerichtet, die nur auf bestehende eMail-Postfächer (der des gleichen Vertrags) weiterleitet auf der Autoresponder eingerichtet sind, gibt es keine Antwort. Das ist u. E. sinnvoll.
Das ist so beabsichtigt - die in der Mail enthaltene Zieladresse steht aufgrund der internen Weiterleitung nicht im To/Cc/Bcc-Feld und löst somit auch keine Meldung des Autoresponders aus.
ZitatWird eine eMail-Adresse ohne Postfach aber mit Autoresponder eingerichtet, die nur auf bestehende eMail-Adressen und/oder Postfächer weiterleiten soll, gibt es keine Antwort vom Autoresponder wenn man an diese Adresse(n) mailt. Das ist eher "suboptimal".
Ja, das ist mir auch kürzlich aufgefallen und fällt ganz klar in die Kategorie "Bug". Ein Workaround dafür ist bereits in Arbeit und leider nicht ganz trivial. Die Autoresponder der "normalen" Postfächer werden mit Sieve realisiert; bei einer reinen Weiterleitung läuft die Zustellung natürlich ohne Dovecot ab - und somit auch ohne der Möglichkeit von Sieve-Scripten. Wir werden für die Autoresponder an "reine" Weiterleitungen also eine zusätzliche Pseudo-Weiterleitung einrichten, welche dann über einen eigenen Postfix-Transport letztendlich das Programm "vacation" aufruft (das ist ein Standard-Tool, welches auch in jeder Distribution verfügbar ist). Bei der Gelegenheit ist mir wieder eingefallen, warum mir Exim deutlich sympathischer ist als Postfix. 
Die Weiterleitungs-Autoresponder müssten in ca. 1-2 Wochen verfügbar sein - ein Kollege arbeitet aktuell ohnehin schon an der Erweiterung der Postfix-Konfiguration.
Viele Grüße & ebenfalls ein schönes Wochenende
-Klaus Keppler
Hallo Herr Niebergall,
das war noch ein Fehler - die IFRAME-URL war zu Testzwecken noch hardcodiert im Code enthalten; die Adresse "www-kk.dev.liveconfig.com" befindet sich hier in unserem Intranet, daher haben die lokalen Tests hier auch nicht angeschlagen. 
Das Repository wurde eben aktualisiert (r1720) - nun sollte es klappen.
Wir werden auch gleich mal die Online-Demo aktualisieren, damit man sich auch dort einen Eindruck von der IFRAME-API machen kann.
Viele Grüße
-Klaus Keppler
Der erste (kleine) Beispielcode steht zum Download bereit, wird in den nächsten Tagen und Wochen natürlich noch weiter ausgebaut: KB#12 - Verwendung der IFRAME-API.
Hallo,
soeben wurde die erste Preview für LiveConfig 1.5.1 online gestellt - wie immer ist diese über die Test-Repositories oder direkte Downloads installier- und aktualisierbar: http://www.liveconfig.com/de/lab
Die wichtigsten Änderungen sind:
Die größte Neuigkeit ist die sogenannte IFRAME API, mit der eigene Inhalte in LiveConfig eingebunden werden können (über einen - na? - ja, einen IFRAME :))
Rein technisch läuft das so ab: als Admin (später auch als Reseller) kann man "eigene Links" konfigurieren (im Menü: Verwaltung -> LiveConfig -> Eigene Links). Für jeden Link wird neben einem Titel und der Ziel-URL auch ein eigenes Passwort hinterlegt.
Klickt in LiveConfig nun ein Besucher einen solchen Link an, so erstellt LiveConfig eine Seite mit einem IFRAME, in den die hinterlegte URL geladen wird. Als CGI-Parameter werden zusätzlich die Session-ID des Kunden, ein Zeitstempel und eine Prüfsumme übergeben. Die aufgerufene Seite kann mit Hilfe des konfigurierten Passworts und der Prüfsumme sicherstellen, dass der Aufruf zumindest schon mal "echt" ist. Um dann noch herauszufinden, ob die Session des Kunden auch noch gültig ist, macht z.B. ein PHP-Script einen SOAP-Aufruf an den LiveConfig-Server bei dem es die Session-ID übergibt. Wenn alles passt, werden alle weiteren Informationen über den aktuellen Benutzer zurückgegeben (Name, Login, etc.).
Die Funktionalität (einen IFRAME einbinden...) klingt vielleicht etwas banal, aber nur mit diesem Verfahren ist es möglich ein "Session Hijacking" zu unterbinden. Die eingebundenen Seiten unterliegen übrigens nicht der "Same-Domain-Policy" - ein Provider kann also zentral IFRAME-Seiten für alle seiner Serverkunden bereitstellen, den Möglichkeiten sind keine Grenzen gesetzt.
Eine kleine PHP-Klasse zur Prüfung der Session-Daten sowie CSS und Grafiken für eine nahtlose und einfache Integration eigener Seiten in LiveConfig stellen wir als .zip-Datei in der Wissensdatenbank bereit (aktuell noch in Arbeit, dürfte bis morgen Mittag online sein). Das Handbuch wird natürlich auch entsprechend erweitert. Wer auf die Prüfung der Session noch verzichten kann (zB. für statische Inhalte, Anleitungen etc.) kann jetzt schon entsprechende "eigene" Links anlegen.
Da nun sicher viele Lese-Zugriffe auf die SOAP-API benötigt werden, teilt uns bitte mit, auf welche Daten ihr eventuell zugreifen möchtet (derzeit sind Lese-Methoden noch recht spärlich vorhanden); wir bauen die benötigten SOAP-Funktionen dann umgehend ein. Unabhängig davon arbeiten wir derzeit am Auslesen und Bearbeiten aller vertragsrelevanten Daten (Verträge, Domains, Vertragseigenschaften, ...).
In den nächsten 2-3 Werktagen werden sich noch einige weitere Funktionen dazugesellen die aktuell noch fertig integriert werden - alle weiteren Infos dazu folgen in diesem Thread.
Viele Grüße
-Klaus Keppler
Hallo,
vielen Dank für die Info. Dieser Fehler ist auch bekannt uns seit r1709 beseitigt (ist also im nächsten Update mit drin).
Als "Workaround" aktivieren Sie bitte einfach den Webalizer unter Serververwaltung -> Web und starten LiveConfig anschließend neu (/etc/init.d/liveconfig restart).
Die betroffenen Postächer sollten mit dem Neustart vollständig gelöscht werden - falls da doch noch was hängen sollte, geben Sie bitte kurz Bescheid.
Besten Dank & viele Grüße
-Klaus Keppler
Hallo,
könnten Sie bitte die Fehlermeldung(en) aus /var/log/liveconfig/liveconfig.log posten?
Eigentlich wird Apache durchaus automatisch neu gestartet. In manchen Fällen (z.B. bei Änderungen an der IP-Konfiguration) kann es aber sein, dass ein "reload" für Apache nicht reicht, sondern ein "restart" notwendig ist. Ab Version 1.5.1 führt LiveConfig daher nach Änderungen an der Kern-Konfiguration (IPs, SSL etc.) entsprechend einen "restart" durch.
Viele Grüße
-Klaus Keppler
ZitatServer hat die Verbindung abgelehnt.
Das deutet darauf hin, dass der Apache-Webserver nicht läuft. Bitte prüfen Sie ob /var/log/apache2/error.log bzw. /var/log/liveconfig/liveconfig.log irgendwelche Fehler enthalten, und versuchen Sie den Apache einfach mal neu zu starten (/etc/init.d/apache2 restart)
Sollte das alles passen, prüfen Sie bitte, ob die IP-Adresse der Domain (A-Record) auch mit der des Servers übereinstimmt.
Viele Grüße
-Klaus Keppler
Danke für den Hinweis; die Repository-Metadaten wurden scheinbar nicht auf dem Repository-Server aktualisiert. Nun sollte es klappen.
(mal überlegen, wie wir das in Nagios aufnehmen können...)
Viele Grüße
-Klaus Keppler
Nach ausführlichen Überlegungen sind wir bzgl. der Postfach-Migration nun zu folgenden Ergebnissen gekommen:
1.) Benutzernamen
In Confixx lautet der Benutzername für ein Postfach einfach nur z.B. "web9p3" - in LiveConfig entspricht der Benutzername jeweils der E-Mail-Adresse (z.B. "info@example.org").
Beim Import muss also zwangweise eine Domain an den Benutzernamen angefügt werden - wird z.B. das Confixx-Postfach "web9p3" importiert, dann wird in LiveConfig das Postfach "web9p3@example.org" erzeugt.
Als Domainnamen verwendet LiveConfig hierfür den (alphabetisch) erstbesten Domainnamen des jeweiligen Vertrages, bei dem E-Mail-Empfang aktiviert ist.
Da sicher mit Änderungswünschen seitens der Benutzer zu rechnen ist, erweitern wir die Postfachverwaltung in LiveConfig dahingehend, dass sowohl Postfachname als auch Domainname von bereits erstellten Postfächern geändert werden können (das ist derzeit noch nicht möglich, da wir solche Änderungen auch auf dem betroffenen Mailserver ausführen müssen, und somit sowohl alte als auch "neue" Mailadresse eines zu bearbeitenden Postfachs intern speichern müssen)
Die ganzen Weiterleitungen etc. aus Confixx werden 1:1 in LiveConfig übernommen; hier sind eigentlich keine Schwierigkeiten zu erwarten. Die Passwörter (bei Confixx in der Datenbank als CRYPT-MD5 gespeichert) können ebenfalls 1:1 übernommen werden, allerdings sollte man hierfür dann in der Dovecot-Konfiguration den Authentifizierungsmechanismus "CRAM-MD5" deaktivieren, da es sonst zu Problemen bei der Anmeldung kommen kann.
2.) Umzug der Postfach-Inhalte
Das ist auch etwas "tricky". Während in Confixx die E-Mails z.B. in /var/email/web9p3/Maildir/ liegen, ist das in LiveConfig z.B. /var/mail/web9/1/ (also /var/mail/<Vertrag>/<LfdNr>/). Auf die laufende Nummer hat man beim Anlegen eines Postfachs keinen Einfluss.
Um nun die Inhalte z.B. per rsync umzuziehen muss man sowohl das alte (Confixx) als auch das neue (LiveConfig) Verzeichnis kennen. Aktuell wäre das so gelöst, dass LiveConfig beim Anlegen eines POP3-Postfachs den zugehörigen Verzeichnisnamen in eine eigene Logdatei schreibt, ebenso wie den Confixx-Postfachnamen (also dann zB. "web9p3 web9/1"). Mit einer eleganten sed-Konstruktion kann man sich so einen rsync-Befehl zusammenbauen, der dann die eigentlichen Postfachinhalte kopiert. Ein passendes Beispiel werden wir bereitstellen.
Wichtig ist auch, dass rsync erst nach dem Anlegen der ganzen Postfächer laufen kann (das Erzeugen der Postfach-Verzeichnisse durch LiveConfig läuft asynchron, daher kann es einen Moment dauern bis nach dem SOAP-Aufruf von HostingMailboxAdd() die Verzeichnisse vorhanden sind)
Fazit
Für die Endkunden kann das E-Mail-Passwort erhalten bleiben, nur ein Domainname muss an das Login angefügt werden.
In der LiveConfig-Oberfläche müssen wir noch die Änderung von Postfach- und Domainnamen ermöglichen (ca. 1-2 Tage Arbeit mit allem drum&dran). Damit sollte ein relativ reibungsloser Umstieg möglich sein.
Die wichtige Frage nun: wie sehen Sie (also unsere LiveConfig-Kunden/Interessenten/Administratoren) das? Haben Sie noch Wünsche oder Ideen für die Postfach-Migration?
Vielen Dank schon mal für Rückmeldungen & viele Grüße
-Klaus Keppler
ZitatIst zukünftig eine Backup & Restore Möglichkeit (für das ganze LC-System bzw. auch für einzelne Kunden) geplant?
Selbstverständlich.
Wir planen folgende Funktionen:
- On-the-Fly-Backup eines einzelnen Webspaces (der Kunde kann sich "on the fly" ein .zip oder .tgz mit seinem komplettem Webspace bzw. der MySQL-Datenbank erzeugen)
- Backup des Webspace auf einen FTP-Server (möglichst "intelligent", also ohne jedes Mal alle Daten übertragen zu müssen)
- Export/Import aller LiveConfig-Einstellungen eines Kunden (oder Vertrags) als XML (auch für Migrationen ganz praktisch)
- Unterstützung/Integration einer CDP-Software ("Continuous Data Protection", erste Gespräche laufen bereits)
Aus Providersicht dürfte es derzeit am einfachsten sein, das komplette System z.B. mit BackupPC zu sichern.
Vom Zeitplan her kann mit diesen Funktionen gegen Jahresende gerechnet werden (das "On-the-Fly"-Backup kommt als erstes, voraussichtlich im Oktober).
Viele Grüße
-Klaus Keppler
"Reloaden" Sie die Seite bitte im Browser - die alte Seite ist bei Ihnen vermutlich noch im Cache.
Viele Grüße
-Klaus Keppler
Hallo,
Zitatweb@debian:~# uname -a
Linux debian 2.6.32-5-686 #1 SMP Sun May 6 04:01:19 UTC 2012 i686 GNU/Linux
Das sagt leider nicht welche Distribution verwendet wird, sondern nur welcher Kernel.
Aber so wie es aussieht dürfte es ein 32bit Debian Squeeze (6.0) sein?
Zitat0648296fa5cba889f0ee853d12d55a9f default.tmpl
Diese Daten stimmen soweit - die Ressourcen an sich sind also vorhanden.
Was liefert bei Ihnen folgender Befehle? (###IP### bitte entsprechend ersetzen)
[EDIT] neue URLs:
curl -Ik https://###IP###:8443/res/t/default/style.css?r1700
curl -Ik https://###IP###:8443/res/t/default/style.css.gz?r1700ZitatGab zuvor ein Problem mit shared memory, habe den Server rebooted die Anleitung im Wiki war funktionslos.
So wie es aussieht lief wohl noch eine Instanz von LiveConfig (siehe "Server already running?").
Welches Wiki meinen Sie?
Viele Grüße
-Klaus Keppler
Hallo,
- welche Distribution nutzen Sie?
- prüfen Sie bitte, ob /usr/share/liveconfig/default.tmpl existiert (170.982 Bytes, MD5-Summe: e4e91afafe03654911a630bf940cc76b sein)
- gibt es Fehlermeldungen in /var/log/liveconfig/liveconfig.log ?
Viele Grüße
-Klaus Keppler