Beiträge von kk

    Ab sofort steht noch ein Update bereit (r2353), welches insbes. ein Berechtigungsproblem beim AppInstaller behebt.


    Zitat

    könnten Sie uns noch die Dokumentation für die neue SOAP API zur Verfügung stellen ?


    Selbstverständlich - wir schreiben aber erst noch die Tests für die neuen Funktionen fertig; sobald das abgeschlossen ist, gibt's noch mal ein Update des Preview-Handbuchs (im WSDL sind die neuen Funktionen "CustomerUpdate()" und "HostingSubscriptionDelete()" schon zu sehen - aber wie gesagt: UNGETESTET!)


    Zitat

    kann mir vielleicht jemand die php.ini Einstellungen VOR der neuen ini Verwaltung nennen?
    Oder kam die gar nicht von liveconfig?


    Welche Einstellungen genau meinen Sie?
    LiveConfig nimmt als Grundlage immer die "zentrale" php.ini (/etc/php5/cgi.d/php.ini) und passt dann alle Werte gemäß der Einstellungen aus dem Menüpunkt "php.ini-Verwaltung" an.
    Weitere Informationen zur php.ini finden Sie in KB#19.

    Ab sofort steht ein Update bereit (r2353), welches das Problem beheben sollte. Mit r2347 wurden die Verzeichnisrechte modifiziert - in diesem Fall leider "zu" sicher. Die automatischen Tests sind in Bezug auf den AppInstaller leider nicht nicht vollständig genug, um diesen Fehler zu erkennen - künftig wird das aber auch geprüft.


    [Nachtrag] Ich habe zwei thematisch identische Threads zusammengefasst...

    Die Fehlerbeschreibung deutet darauf hin, dass beim betroffenen Server der Client-Teil von LiveConfig hing und keine Jobs mehr verarbeitet hat. Dessen Architektur wurde kürzlich überarbeitet (fließt in v1.7.0 mit ein), so dass "Hänger" automatisch erkannt und der Client automatisch neu gestartet wird.


    Haben Sie irgendwelche auffällige Meldungen im liveconfig.log (bzw. beim Multiserver-Setup im lcclient-Log des betroffenen Zielservers)?

    Sie können die "halb gelöschten" Verträge noch mal zurücksetzen indem Sie folgenden SQL-Befehl in der LiveConfig-Datenbank ausführen:

    SQL
    UPDATE HOSTINGCONTRACTS SET HC_DELETED=0 WHERE HC_DELETED=1;


    Anschließend sollten die betroffenen Verträge wieder "normal" im LiveConfig auftauchen - dort können Sie diese dann erneut löschen.


    Da ist ernsthaft etwas in der Datenbank korrupt. Die Spalten 2-4 (CUST_IDLEVEL, CUST_IDLEFT und CUST_IDRIGHT) dienen der Verwaltung der Struktur/Hierarchie der Kunden. Hier gibt es neben dem Admin (CUST_ID=1, CUST_IDLEVEL=1) nur noch Kunden mit der Ebene CUST_IDLEVEL=3 - da fehlt also was. Auch die Baumstruktur (Nested Set mit IDLEFT/IDRIGHT) ist fehlerhaft.


    Haben Sie eventuell mal manuell in die Tabelle CUSTOMERS eingegriffen?


    Falls nicht, wäre es natürlich hochinteressant, ob sich dieses Verhalten mit einer "frischen" Datenbank reproduzieren lässt.


    Welche Kunden/Reseller/Benutzer sollen denn am Ende noch übrig bleiben? Die überflüssigen Einträge könnten Sie durchaus direkt in der Datenbank löschen, allerdings muss dann noch die Baumstruktur in der CUSTOMERS-Tabelle korrigiert werden.
    Schicken Sie uns einfach nach dem Löschen noch mal die selben Tabellen-Dumps wie im obigen Forums-Beitrag an support@liveconfig.com, dann kann ich Ihnen die notwendigen Korrektur-SQLs zurück schicken.


    Viele Grüße


    -Klaus Keppler

    Falls Sie bereits die Preview r2349 installiert haben, machen Sie bitte noch mal ein Upgrade (auf r2350, steht ab sofort bereit). Nach einem LiveConfig-Neustart sollten die Verträge dann theoretisch automatisch vollständig gelöscht werden. Falls nicht, geben Sie dann bitte noch mal Bescheid.

    WICHTIG: in r2349 ist ein Fehler im Zusammenhang mit dem recht großen php.ini-Wert für "disable_functions" aufgetaucht. Die korrigierte Version (r2350) steht ab sofort bereit.
    Bitte entschuldigen Sie die Unannehmlichkeiten - der Fehler war recht hartnäckig, da er sich in den automatischen Tests nicht bemerkbar machte.

    Die in den letzten Tagen gemeldeten Fehler sind nun auch beseitigt, die Preview wurde eben noch mal aktualisiert.


    WICHTIG: die von LiveConfig nun standardmäßig voreingestellte php.ini-Konfiguration wurde noch mal deutlich verändert. Vor allem wurde "safe_mode" wieder auf "off" gesetzt und etliche Funktionen aus disable_functions entfernt, damit bei einem Upgrade keine plötzlichen Probleme durch eine überraschend restriktive php.ini auftreten.
    Gleichzeitig haben wir damit begonnen, die Einstellungen (und die jeweiligen Gründe dafür) ausführlich zu dokumentieren: KB#19 (noch nicht offiziell verlinkt!).


    Sollte es noch größere Einwände gegen die php.ini-Vorgaben geben, melden Sie diese bitte!


    Beim Upgrade werden die neuen php.ini-Einstellungen übrigens nicht automatisch angewendet, sondern erst wenn man in der php.ini-Verwaltung auf den Button "Vorlage anwenden..." klickt. (dieser wird übrigens noch umbenanntn in "Änderungen übernehmen", weil's da einige Unklarheiten gab)


    Schöne Pfingsten!


    -Klaus Keppler

    Für uns (als Softwarehersteller) ist der IT-Grundschutz-Katalog relevanter als die Firefox-Empfehlung, da dieser auch Grundlage für eine eventuelle BSI-Zertifizierung ist.
    Letztendlich ist es immer eine Frage, wohin man seine Schwachstelle verlagert. Was nutzt eine strenge Passwort-Policy (>12 Zeichen, Sonderzeichen, Zahlen usw.), wenn sich dann niemand mehr das Passwort merken kann, man es im Firefox/KeePass/... speichert, so dass es ggf über ein bösartiges Script ausgelesen werden kann? Oder der User vergisst es gleich und lässt sich dann über eine simple E-Mail einen Link zum Zurücksetzen des Passworts zuschicken...


    Meiner Meinung nach bietet eine Zwei-Faktor-Authentifizierung mit einem "merkbaren" Passwort und einem persönlichen Token-Generator (Token/Smartphone/...) weitaus mehr Sicherheit als ein Passwort, dass so komplex ist, dass man auf dessen Speicherung in irgendeiner Passwort-Datenbank angewiesen ist.


    [Jippiee... 1000stes Posting :)]

    Nur mal so als Zwischenmeldung ;) - mit v1.7.0 gibt es eine zusätzliche Verwaltungsmöglichkeit für "interne" Konfigurationseinstellungen von LiveConfig. Damit kann dann u.a. auch das AutoFill für die Anmeldung aktiviert werden (bleibt standardmäßig aber deaktiviert) oder die Länge/Komplexität von Passwörtern etc. definiert werden.


    Schöne Pfingsten!


    Nachtrag: die BSI-Empfehlung für's Sichere Surfen mit Firefox gibt's übrigens hier. AutoComplete wird auf Seite 9 erwähnt.
    Im eigentlich noch wichtigeren "IT-Grundschutz-Katalog" wird explizit empfohlen, AutoComplete=off zu setzen, siehe hier (Seite 97).

    Das wäre sehr gut, denn wir installieren auch nicht auf jedem Server php5-cgi, wenn es kein Multi-Website-Server ist...


    Mit r2348 wird alternativ noch nach /usr/bin/php gesucht (PHP-CLI). Es wird aber noch eine gesonderte Erkennung der Version von mod_php geben (kommt noch in die finale 1.6.2 mit hinein). Nun möchten wir aber noch den aktuellen Stand vor Pfingsten freigeben. :)

    Apache verwendet in diesem Fall eine sicherere umask, so dass die error.log mit den Rechten des Endkunden nicht lesbar ist (der Log-Viewer öffnet Dateien aus Sicherheitsgründen grundsätzlich mit den Berechtigungen des Endkunden).
    Mit v1.6.2-r2145 wurde das apache.lua-Script so aufgebohrt, dass die error.log mit entsprechend großzügigeren Rechten angelegt wird (das übergeordnete "logs"-Verzeichnis verbietet ja einen Zugriff durch Fremde).


    Update wird in ca. 3-4 Stunden im Preview-Bereich verfügbar sein.

    Unter Debian wheezy wurden beim mir heute bei Build 2334 keine Änderungen an der Apache-Konfiguration gespeichert. Der Configtest des lcclient hat folgendes Meldung ausgegeben:


    Hmm, interessant...
    Seit r2311 versucht LiveConfig die aktuelle PHP-Version automatisch zu erkennen, um diese bei der Erzeugung der php.ini-Dateien zu berücksichtigen.
    Könnten Sie bitte mal die Ausgabe von folgendem Befehl posten?

    Code
    dpkg -l | grep php


    Falls noch nicht geschehen, installieren Sie bitte das Paket "php-cgi" - dann sollte das eigentlich wieder funktionieren. Wir werden aber noch eine Lösung einbauen, um auch ohne PHP-CGI (z.B. wenn man nur mod_php nutzen möchte) die korrekte Version herauszufinden.

    Bitte testen Sie den AppInstaller noch mal mit der neuesten LiveConfig-Version (ab v1.6.2-r2334). Wir haben das Problem bei einem anderen Kunden reproduzieren können - in diesem Fall gab es zu restriktive Einstellungen in der globalen php.ini (für PHP-CLI), welche eine Ausführung des AppInstaller-Scripts verhindert hatten (u.a. safe_mode=on, register_argc_argv=off, ...).
    Mit der neuen Version werden diese php-Einstellungen explizit ignoriert - es ist dann also egal, was in der php.ini steht.


    Viele Grüße


    -Klaus Keppler

    Öffnen Sie bitte in LiveConfig eine Verbindung mit dem betroffenen Webspace (web18). Dann klicken Sie links im Menü auf "E-Mail". Oberhalb der Postfach-Liste sehen Sie nun eine Übersicht, wie viele Postfächer mit wie viel Speicherplatz angelegt sind, und wie groß das E-Mail-Quota insgesamt ist.
    Wenn Sie wirklich kein Mail-Quota wünschen, ändern Sie in allen Angeboten das Hosting-Quota auf "unbegrenzt".


    Viele Grüße


    -Klaus Keppler

    Dann liegt wohl irgendwo ein Fehler vor.


    - Welche Distribution verwenden Sie?
    - Versuchen Sie bitte mal, NGINX neu zu starten (/etc/init.d/nginx restart) - funkioniert es danach, oder gibt es beim Restart eine Fehlermeldung?
    - gibt es Fehlermeldungen in /var/log/liveconfig/liveconfig.log?


    Wenn das alles nicht hilft, schicken Sie bitte mal die Ausgabe von "liveconfig --diag" und den Inhalt von /etc/nginx/sites-available/web1.conf an support@liveconfig.com, dann schauen wir wo das Problem liegt.

    Wenn Sie nur die IP aufrufen landen Sie zwangsläufig auf dem mit "default" konfigurierten Webspace. Wenn Sie den mit web1 konfigurierten Webspace aufrufen möchten, dann müssen Sie das über eine Domain machen, welche Sie Ihrem Hostingvertrag ggf. noch hinzufügen müssen.


    Viele Grüße


    -Klaus Keppler