Beiträge von kk

Eben wurde noch ein Fehler in der Preview-Version entdeckt und beseitigt, der sich mit r2337 (15.05.2013) eingeschlichen hatte. Beim Sperren von Kunden wurden in einigen Fällen zu viele Accounts gesperrt (statt nur den betroffenen Kunden wurden alle Kunden des ausführenden Benutzers gesperrt). Wer also mit einer Preview-Version ab r2337 mindestens einen Kunden gesperrt hat, sollte am besten mal mit "grep 'lock user' /var/log/auth.log" prüfen, ob unerwünscht auch weitere Accounts gesperrt wurden. Um das ggf rückgängig zu machen reicht es, in LiveConfig bis r2353 einfach den ursprünglich gesperrten Kunden wieder zu entsperren (dabei werden auch alle anderen fälschlicherweise gesperrten Kunden wieder entsperrt).

Mit r2354 ist der Fehler beseitigt. Sollten Sie von dem Fehler betroffen sein, bitten wir um Entschuldigung - falls Sie Unterstützung beim "Aufräumen" brauchen, melden Sie sich bitte einfach kurz unter support@liveconfig.com

Viele Grüße

-Klaus Keppler

Zitat von TropiaIT

Die Version ist noch nicht Offiziell herausgegeben worden von euch oder?

Nein, sonst würde diese ja auch auf den offiziellen Download-Seiten (http://www.liveconfig.com/de/downloads) auftauchen. Wir sind aber nur noch mit "Aufräumarbeiten" für dieses Release beschäftigt (einen Termin nenne ich mal lieber nicht, bevor ich wieder festgenagelt werde - es dauert aber nicht mehr lange)

Das bei Ihnen aufgetretene Problem mit dem AppInstaller sollte damit dann auch beseitigt sein, da LiveConfig nun zu restriktive php.ini-Einstellungen für die Installation ausdrücklich aufhebt.

Zitat von Screeny

Narf.

Kein Problem. Der Webserver ist eh so konfiguriert, dass auch HTML-Dateien mit einem Expire +3Days ausgeliefert werden - für kurzfristig geänderte Seiten kommt man um ein explizites "Reload" also auch nicht herum. Zort!

Ja, einfach mal Reload machen.

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:

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.

Zitat von bytewurm

sqlite> select * from customers;
1|1|1|14|0|0|1|1|1|0|...
4|3|1|14|3|1|6|6|6|0|...
5|3|1|4|2|1|4|4|4|0|...
7|3|5|14|6|1|7|7|7|0|...
10|3|7|14|9|1|8|8|8|0|...
12|3|9|14|11|1|10|10|10|0|...
14|3|11|14|13|1|11|11|11|0|...

Alles anzeigen

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

Zitat von suppenuser

Ich will Dein Stück Kuchen, wenn Du die Kerzen fertig ausgeblasen hast

Soll ich's am Mittwoch mitbringen? Vielleicht gibt der Zeitplan ja auch noch einen Abstecher bei uns im Büro her - Kaffee ist genug da.

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).

Zitat von aziegler

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.

Zitat von r00xster

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?

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