Der einzige Grund, wann bzw. warum LiveConfig ein Restart des Apache httpd durchführt ist tatsächlich nur, wenn Änderungen an der Konfiguration stattgefunden haben (also wenn eine (Sub)Domain hinzugefügt/bearbeitet/gelöscht wird)
Bislang ist mir persönlich dieses Phänomen noch nicht bekannt geworden, ich lasse morgen mal unsere LiveConfig-Server diesbzgl prüfen. Falls andere LiveConfig-Nutzer diese Fehlermeldungen auch finden, bitte ich um kurze Information.
Viele Grüße
-Klaus Keppler
Hallo Herr Knick,
ein anderer Kunde hat uns heute von einem ähnlichen Problem berichtet. Der Fehlerbeschreibung nach zu urteilen vermute ich, dass der Vertrag nicht vollständig gelöscht ist.
Könnten Sie bitte prüfen, ob der Systemaccount (webxyz) vielleicht noch existiert?
Falls ja, gibt es evtl. Hinweise im LiveConfig-Log? Falls ein Fehler vorliegt, ggf. mal einen LiveConfig-Neustart ausführen ("hängende" Verträge werden dabei erneut gelöscht).
Während unserer Tests mit dem Migrationstool haben wir ebenfalls sehr häufig bestimmte Accounts importiert, dann gelöscht und später wieder erneut importiert, bislang jedoch ohne Probleme. Verwenden Sie auch Debian 6?
Viele Grüße
-Klaus Keppler
Danke für den Hinweis - ist ab r1934 enthalten.
Viele Grüße
-Klaus Keppler
Hallo Herr Krüger,
ein Website-Update steht Mitte nächster Woche an (die Startseite wird etwas aufpoliert, viele weitere Partner in die Liste aufgenommen, u.v.m.).
Mittelfristig werden wir die "statische" Roadmap aber durch den neuen Issue Tracker ersetzen:
https://www.liveconfig.com/dev/projects/lc/roadmap
Viele Grüße
-Klaus Keppler
php.ini-Einstellungen sind definitiv Bestandteil der nächsten Version (1.6.0).
Siehe nun auch hier: https://www.liveconfig.com/dev/issues/28
Die Liste der verwaltbaren PHP-Einstellungen wird bearbeitbar sein (also nix hardcodiert), außerdem werden auch verschiedene PHP-Versionen berücksichtigt (z.B. gibt es ab PHP 5.4 kein register_globals mehr).
Sobald erste Funktionen in der Preview-Version auftauchen, geben wir hier noch mal Bescheid.
Viele Grüße
-Klaus Keppler
Die Idee mit der "Iframe API" ist nett aber nur ein Tropfen auf dem heissen Stein, da gibts durchaus bessere Lösungen bei anderen Paneln
Für konkrete Vorschläge sind wir immer offen.
Mir sind (auch wenn das vielleicht aus Herstellersicht etwas doof klingt) keine besseren Lösungen bekannt.
Bei der IFRAME-API handelt es sich um mehr als nur das blinde Einbinden von einem Link. Letzteres wäre nämlich auch keine wirkliche Erweiterung der Funktionalität (API = Application Programming Interface), sondern würde den Benutzer bei völligem Verlust der Authorisierungsinformationen auf eine externe Seite schicken.
Falls Sie so etwas machen möchten, binden Sie einfach (ähnlich wie auf den Demo-Seiten) eine statische Seite ein, auf der Sie die entsprechenden externen Links bereitstellen.
Nur bei Verwendung des JavaScript-Codes besteht die Möglichkeit, seitens des eingebundenen Scripts herauszufinden, welcher User gerade am LiveConfig angemeldet ist und ob die Session noch gültig ist.
phpMyAdmin sollte über den phpMyAdmin-Link (Serververwaltung -> Datenbanken -> ...) hinterlegt werden - dann wird dieser bei den Kunden in der Datenbank-Liste mit eingeblendet.
Viele Grüße
-Klaus Keppler
ZitatCan't get system informations: open(/dev/mem)
Diese Meldung hat nichts mit dem Arbeitsspeicher zu tun (auch wenn das "mem" darauf hindeutet). Dieser Fehler tritt auf, wenn auf einigen Virtualisierungsplattformen wie z.B. Xen versucht wird, auf's BIOS zuzugreifen.
Wenn das so verwirrend ist, werden wir das künftig besser unterdrücken. 
Zum eigentlichen Problem: wir testen das mal durch - ich gebe dann noch mal Bescheid.
Viele Grüße
-Klaus Keppler
Hallo Herr Groh,
das klingt ja nicht gut... Könnten Sie uns einfach mal anrufen? 09131/691-480
Viele Grüße
-Klaus Keppler
Hallo Herr Knick,
ja, das ist nicht ganz so einfach... 
Es ist wirklich wichtig, dass die per IFRAME eingebundene Seite die bei der API-Dokumentation bereitgestellte JavaScript-Datei lc-api.js verwendet - siehe Handbuch:
Zitat
Verwendung von lc-api.jsDamit die Größe des IFRAMEs automatisch angepasst werden kann ist der Aufruf einer bestimmten JavaScript-Funktion notwendig sobald der Inhalt vollständig geladen wurde. Die Datei lc-api.js enthält den dazu notwendigen Code.
Aus Sicherheitsgründen erlaubt der Browser es dem Hauptfenster nämlich nicht, die tatsächliche Größe eines eingebetteten IFRAME-Inhalts auszulesen. Genau das muss LiveConfig aber machen, um die Größe des IFRAMES so anzupassen, dass der komplette Inhalt dargestellt werden kann, ohne innerhalb des Frames scrollen zu müssen.
Also: it's not a bug, it's a (security) feature.
Ah ja... :confused:
Dann muss es irgendwo eine .htaccess-Datei geben, welche die Dateiendung .html auf den Typ application/x-httpd-php mapped.
In der von LiveConfig erzeugten Konfiguration werden jedenfalls keine HTML-Dateien "angefasst".
Ich habe hier auf einem Debian6-Testsystem auch eben mal PHP auf FastCGI umgestellt - HTML-Dateien werden ganz normal angezeigt (mit Content-Type: text/html).
Viele Grüße
-Klaus Keppler
Hallo,
werden HTML-Seiten oder PHP-Scripte heruntergeladen? Dem Header nach zu urteilen tippe ich auf PHP - so wie es aussieht werden PHP-Scripte nicht durch FastCGI ausgeführt.
Welche Distribution setzen Sie ein?
Viele Grüße
-Klaus Keppler
Hallo Herr Groh,
es tut mir leid, aber ich kann Ihnen leider keinen verbindlichen Termin für dieses Feature nennen.
(würde ich das machen, und dieser Termin könnte nicht eingehalten werden, wäre wir auch nicht besser dran...)
Es steht aber ziemlich weit oben auf der aktuellen ToDo-Liste und sollte (falls nichts dazwischen kommt) in der kommenden Version (1.6.0) enthalten sein - geplant für etwa Anfang November.
Viele Grüße
-Klaus Keppler
Hmm, dann könnte das eventuell ein Problem beim Datenbankzugriff sein.
Bitte prüfen Sie, ob die Daten vom Traffic- oder CPU-Graph des Servers aktuell sind -> falls nicht, starten Sie bitte LiveConfig neu und werfen einen Blick in /var/log/liveconfig/liveconfig.log.
Viele Grüße & einen schönen Abend
-Klaus Keppler
Sind die Daten vielleicht inzwischen da?
Der Speicher wird auch über RRD-Tabellen verwaltet, da kann es ein paar Minuten dauern bis erste Daten verfügbar sind.
Der Hinweis im Handbuch bezieht sich auf eine andere Fehlermeldung (die tritt beim Auslesen von DMI-Daten des BIOS auf manchen Virtualisierungsplattformen auf)
Was zeigt denn "liveconfig --diag" an?
Viele Grüße
-Klaus Keppler
ZitatBzw. würde mir auch die Möglichkeit genügen, alle Endkunden dem Admin zuordnen zu können.
Ja, die gibt es inzwischen. Mit der Option "--newreseller=admin" werden alle importierten Kunden dem Admin zugeordnet.
Wenn Sie außerdem "--importplans" angeben, werden die Hosting-Angebote der Reseller auch importiert und dem Admin zugeordnet.
Ein kompletter Import aller Endkunden würde also mit folgendem Aufruf stattfinden:
php cfximport.php --importplans --newreseller=admin --allIn dem Knowledgebase-Artikel zum Import-Script steht inzwischen außerdem auch ein Shell-Befehl, mit dem die Postfachinhalte mittels rsync vom Confixx- auf den LiveConfig-Server übertragen werden können.
Sowohl das Importscript (cfximport.php) als auch LiveConfig wurden eben aktualisiert - bitte laden Sie diese ggf. neu herunter.
<?php phpinfo() ?>
Teilen Sie uns diese URL bitte per PN an mich oder per Mail an info@liveconfig.com mit - dann schauen wir mal, ob dort irgendwie Einfluss auf "include" genommen wird
Viele Grüße
-Klaus Keppler
Hallo Herr Groh,
also, sofern ich gerade kein Brett vor dem Kopf habe glaube ich zu wissen, dass PHP unter FastCGI die Dateirechte herzlich egal sind. Wichtig ist das unter suPHP - dort prüft der suPHP-Wrapper vor Ausführung des Scripts, ob die Berechtigungen den Anforderungen entsprechen (die man wiederum in der /etc/suphp/suphp.conf modifizieren kann).
FastCGI bedeutet "nur", dass ein PHP-Prozess mehr oder weniger dauerhaft im Speicher verbleibt und somit für mehrere Zugriffe zur Verfügung steht. Das FastCGI-Starter-Script muss zwar einige Anforderungen erfüllen um vom suEXEC-Wrapper gestartet zu werden, aber das ist eine andere Baustelle.
Viele Grüße
-Klaus Keppler
Die genauen Lizenzbedingungen (und vor allem die Ausnahmen!) sind hier genau beschrieben:
http://www.spamhaus.org/organization/dnsblusage/
Wir werden auf diesen Punkt aber auch deutlich in der Dokumentation zur Verwaltung der DNSBL-Server hinweisen.
Wir haben uns für Redmine entschieden.
Bislang läuft alles über JIRA, das wir aber aus verschiedenen Gründen nicht "extern" nutzbar machen möchten.
Viele Grüße
-Klaus Keppler