Beiträge von kk

    Welche Distribution nutzen Sie denn?
    Bei einer normalen Installation sollten alle Berechtigungen stimmen - so lange Sie nicht manuell die Rechte für z.B. /var/www/ ändern.


    Sie können folgendes Script ausführen, um die Dateirechte und -Besitzer korrigieren zu lassen:

    Code
    /usr/lib/liveconfig/lcservice.sh fix-permissions


    Viele Grüße


    -Klaus Keppler

    Wir kennen die Hostnamen nicht einmal - lediglich der Lizenzserver weiß, von welcher IP aus zuletzt eine Aktivierung/Verlängerung stattgefunden hat (BDSG: nur die Daten speichern, die wirklich gebraucht werden).


    Das Lizenzsystem unterstützt aber frei definierbare Bemerkungen zu jeder Lizenz (können derzeit nur LC-Partner bei der Bestellung angeben). Wir werden das bei der anstehenden Überarbeitung im Online-Shop gerne berücksichtigen.


    Viele Grüße


    -Klaus Keppler

    Danke für die Rückmeldung, die Ursache ist gefunden: Ubuntu 13.10 :(
    Bislang unterstützen wir "nur" Ubuntu 13.04, mit dem Upgrade zur 13.10 haben die Jungs von Ubuntu teils massive Änderungen an einigen Konfigurationen vorgenommen (u.a. wird nun Apache 2.4 mit einem neuen Config-Layout verwendet; statt "conf.d" gibt's nun "conf-available").
    Morgen werden wir LiveConfig v1.7.1 freigeben, mit welcher dann auch Ubuntu 13.10 unterstützt wird.

    Äh, wir können da leider auch nicht viel machen, wenn Sie irgendwelche php.ini-Einstellungen vornehmen.


    Ich tippe (mittels meiner Glaskugel) darauf, dass Sie in einigen Webspaces in der php.ini nun einen Eintrag "zend_extension=" stehen haben (also ohne Dateinamen dabei).


    Entfernen Sie am besten die zend_extension-Einstellung aus der php.ini-Verwaltung im LiveConfig, und legen Sie eine Datei /etc/php5/conf.d/zendguard.ini an, in welche Sie die gewünschte Einstellung schreiben. Fertig.

    Die Sprachpakete wurden inzwischen integriert und sind in der nächsten Preview-Version (voraussichtlich am Donnerstag) enthalten. Ich schreibe Ihnen dann noch kurz eine E-Mail.


    Viele Grüße


    -Klaus Keppler

    Hallo,


    ab sofort steht die erste Preview für LiveConfig 1.7.1 zum Download bereit:
    http://www.liveconfig.com/de/lab


    In diesem Update sind größtenteils Bugfixes und kleinere Verbesserungen enthalten; ein paar Features werden derzeit noch abgeschlossen (wird dann hier jeweils bekannt gegeben).
    Die Freigabe soll in ca. 10-14 Tagen erfolgen.


    WICHTIG: aufgrund einer wichtigen Änderung im internen LCCP-Protokoll kann LiveConfig ab v1.7.1 nicht mit "älteren" Clients (<= 1.7.0) kommunizieren. Multi-Server-Umgebungen müssen also komplett aktualisiert werden; ob man beim Upgrade mit dem Server oder mit den Clients beginnt spielt dabei keine Rolle.


    Viele Grüße


    -Klaus Keppler

    Für Extensions wird es nun eine eigenen "Datentyp" in der Verwaltung der php.ini-Einstellungen geben.
    Als Name gibt man dann einen Freitext-Namen für die Extension an (z.B. "IonCube Loader"), als Wert den Namen der .so-Datei. Über einen Ein/Aus-Schalter kann diese Extension dann für die jeweilige php.ini aktiviert/deaktiviert werden.
    Ist in Arbeit, wird es evtl nicht mehr in das Update bis morgen Abend schaffen.


    Viele Grüße


    -Klaus Keppler

    Ich muss mal nachfragen ob diese Anzeige nicht doch mal eine Idee wäre. Jedes mal ein Postfach anzuklicken um zu sehen wie groß die Quota des Postfaches ist, ist irgendwie nervig.
    Ich wenn wahrscheinlich keine Antwort kommen wird wäre es toll diese kosmetische Erweiterung in den nächsten Versionen zu sehen.


    Hmm, derzeit wird die tatsächliche Postfachgröße angezeigt, nicht das Quota. Gleichzeitig visualisiert der Balken im Hintergrund den "Füllstand" des Postfachs (per Tooltip bekommt man dann auch noch den Füllstand in Zahlen angezeigt).
    Ich denke auch dass es sinnvoller ist, den Quota-Wert anzuzeigen (wie "voll" das Postfach ist sieht man ja anhand des Füllstandsbalkens).


    Wird gleich übernommen. In den Release-Notes werden wir dann entsprechend auf die veränderte Bedeutung der Zahlen in der "Größe"-Spalte hinweisen.

    Nein - wurde er nicht. :)
    Unter OpenSUSE wurde uns bisher schon häufiger (naja, relativ - von 2 weiteren Kunden) berichtet, dass es beim Prozess-Neustart zu dem o.g. Verhalten kommt. Das Ganze ist nicht einfach, wir arbeiten daran.*
    Die Frage wäre höchstens, wie sich das "einfach abstützt" im Detail äußert - gibt es irgendwelche Einträge im LiveConfig-Log? Erscheint zumindest noch die Anmelde-Seite?


    *) um genau zu sein wird derzeit das komplette Event-Handling von LiveConfig umgestellt, um einerseits flexibler zu sein, und andererseits zuverlässiger. Die Entwicklung findet in einem eigenen Branch statt und wird noch einige Wochen dauern.
    Dass der Neustart unter OpenSUSE häufiger mal nicht klappt liegt in der SuSE-eigenen Verwaltung von Prozesszuständen in einer eigenen "Datenbank" - OpenSUSE glaubt bisweilen, dass ein Prozess erfolgreich beendet wurde, obwohl er das nicht war -> Peng, kein Neustart möglich.

    Das ist eher ein Feature, führt aber zu vielen Mißverständnissen.
    LiveConfig unterscheidet nämlich ganz genau zwischen einer "Domain" und einer "Subdomain".
    Wird also beispielsweise die Domain "neu.com" angelegt, dann existiert erst mal noch keine Subdomain dazu. Legt man nun die Subdomain "www" darunter an, dann ist dies die erste Subdomain; der bisherige Platzhalter-Eintrag "neu.de" verschwindet aus der Anzeige. Genauso kann man nun noch eine Subdomain mit leerem Hostnamen (-> "neu.de") anlegen, dann hat man "neu.de" und "www.neu.de" zur Verfügung.


    Alleine schon bei dem Versuch das zu beschreiben merke ich, wie kompliziert das ist - dabei ist die Idee dahinter eigentlich ganz einfach. Ich schätze mal, dass wir das vereinfachen müssen (ist an anderen Stellen im Forum auch schon aufgetaucht).

    Ja, diese Seiten können natürlich beliebig geändert werden:
    /usr/share/liveconfig/html/ - dort die "not-available.(s)html", "coming-soon.html" etc.


    Bei Updates werden diese Seiten derzeit noch überschrieben (also bitte nach Änderungen noch eine Kopie anlegen); es ist aber bereits geplant diese "update-sicher" zu machen.

    MySQL bietet da von Haus aus keine weiteren Möglichkeiten. Am besten mal per SSH eine MySQL-Session öffnen und dort als root "show processlist" ausführen - in den meisten Fällen reicht das dann schon, um den Bösewicht zu entdecken.

    Die Last ist komplett MySQL geschuldet (244% ist schon heftig...).
    Um herauszufinden was da passiert, unbedingt das slow query log aktivieren.
    Die langsamen SQLs kann man anschließend mit dem Befehl "EXPLAIN <SQL>" analysieren lassen. Meiner Erfahrung nach lassen sich so fast alle SQL-Anfragen mindestens um den Faktor 50 beschleunigen. Fortgeschrittene SQL-Kenntnisse vorausgesetzt.