Beiträge von kk

Sorry, wird auch so kommen dass der Kunde die entsprechend ausgewählten PHP-Einstellungen selbst bearbeiten kann. Die Maske dazu ist derzeit nur noch nicht im LC vorhanden.

Mit dem aktuellen Preview-Update (v1.7.0-r2658) sollte der Fehler behoben sein.

Viele Grüße

-Klaus Keppler

Die Preview wurde eben auf v1.7.0-r2658 aktualisiert - mit vielen Bugfixes und Verbesserungen.
Wir haben nun nur noch drei offene "Showstopper" vor dem Release. Einer davon - die DNS-Verwaltung - dürfte morgen soweit abgeschlossen werden, so dass wir danach dann auch die Builds für OpenSUSE, CentOS und Gentoo bereitstellen können.

Viele Grüße

-Klaus Keppler

Das hat mit SSL-Chiffren absolut nichts zu tun. Das Zertifikat wird einfach nur auf www.blablub.de ausgestellt sein und nicht auf blablub.de.
Das mit "PCI-konformen Chiffres" ist im Handbuch beschrieben:

Zitat

SSL-Server-Chiffres:

Zitat

hier können Sie festlegen, welche Methoden zur SSL-Verschlüsselung vom Server unterstützt werden. Die Einstellung „kompatibel“ unterstützt die meisten (auch älteren) Endgeräte. Falls Sie eine Zertifizierung nach dem PCI-DSS-Standard benötigen, stellen Sie „PCI-konform“ ein. (Diese Einstellung ist nicht in der LiveConfig-Basic-Version verfügbar)

Danke für den Stackdump, der Fehler ist bereits beseitigt.
Darf ich fragen, mit welchem Browser Sie auf LiveConfig zugreifen? (Hintergrund: hier wird ein HTTP-Request-Header etwas "merkwürdig" angeliefert, so dass es zu dem Fehler kommt; ich möchte mir das gerne mal etwas näher anschauen)

Ich tippe darauf, dass es tatsächlich "nur" ein Problem mit der Uhr-Synchronisation gibt. Die Uhrzeit auf dem Server (bzw. im LiveConfig) muss mit der Zeit auf dem Tokengenerator (Handy) ziemlich genau übereinstimmen (+/- 30 Sekunden).

Wenn Sie die LiveConfig-Login-Seite im Browser öffnen, wird eine Logzeile in /var/log/liveconfig/access.log geschrieben. Stimmen Datum/Uhrzeit in dieser Logzeile mit der Uhrzeit in Ihrem Handy überein?

Hallo Herr Strausmann,

danke für den interessanten Hinweis.
Wir sehen hier allerdings ein grundsätzliches Sicherheitsproblem: ein lokaler Benutzer (z.B. böswilliger Webspace-User) kann sich ja problemlos mit Port 10023 verbinden (egal ob über IPv4 oder IPv6). Schafft er es nun aufgrund eines Fehlers in Postgrey, diesen Prozess zum Absturz zu bringen, so kann er selber ein eigenes Programm starten, welches auf Port 10023 lauscht und somit alle E-Mails erhält. Implementiert man dann noch die Milter-API, bekommt Postfix davon gar nichts mit.

Eine bessere Lösung ist es daher, Postgrey mit einem Unix-Socket zu starten (--unix=/var/run/postgrey.sock) und in der Postfix-Konfiguration auf diesen zu verweisen (check_policy_service unix:/var/run/postgrey.sock).

Wir lassen uns etwas einfallen, wie LiveConfig erkennen kann auf welchem IP- oder Unix-Socket nun Postgrey erreichbar ist, und Postfix entsprechend einrichtet.

Viele Grüße

-Klaus Keppler

Danke für den Hinweis!
Da gehört noch ein Backslash vor den Punkt:

location ~ /[B]\[/B].ht {
  deny all;
}

Ist mit dem nächsten Update behoben.

Zitat von arnoldB

Reseller kann neuen Kunden nicht anlegen, wenn Kontakt (owner-c) gleich dem des (eigenen) Reseller-Vertrags entspricht. Das Klicken auf den Submit-Button ist erfolglos, es ist keine Aktion/ Hinweismeldung bemerkbar.

Ab v1.7.0-r2644 werden die eigenen Kontaktdaten eines Resellers nicht mehr zur Auswahl angezeigt (da diese ja auch nicht verwendet werden können). "Eigene" Verträge sollte man ohnehin unter "Mein Hosting" anlegen; dort werden keine weiteren Kontaktdaten benötigt.

Hallo Herr Fritz,

Zitat von isphttp.de

Im Resellerbereich kann ich nur unter „Mein Hosting“ die Verwaltung der zugewiesenen IP-Adresse finden. Hier kann ich wieder zwischen 'exklusiv' und 'gemeinsam' wählen. Bei Auswahl 'exclusiv' wird mir aber kein Vertrag angezeigt und es steht nur „nicht zugeteilt“ da.

Mit der aktuellen LiveConfig-Version (1.6.4) kann man als Reseller auch hier die IP auf "exklusiv" setzen und dann einen seiner Verträge auswählen, für den diese IP genutzt werden soll (habe ich eben noch mal erfolgreich getestet). Haben Sie evtl. noch eine ältere LiveConfig-Version im Einsatz?

Zitat

Bei längerem Arbeiten im Backend setzt das System unregelmäßig nach manchmal 3/5/10 Minuten für ca. 15-20 Sekunden aus.

Ich vermute mal, dass Sie LiveConfig noch mit der standardmäßig eingestellten SQLite-Datenbank verwenden? Ab ca. 100-200 Webspace-Verträgen empfehlen wir, LiveConfig auf MySQL umzustellen, da so die ganzen Statistikdaten (Traffic pro Webspace etc.) effizienter verwaltet werden können. Eine Anleitung zur Umstellung finden Sie in der Wissensdatenbank.

Zitat

3. Nach einem Update kann ein Kunde via FTP sein php5.ini nicht mehr selbstständig bearbeiten. [...] Hat sich hierbei etwas geändert?

Ja, da hat sich etwas geändert: inzwischen setzt LiveConfig bei der php.ini-Datei das "Immutable"-Flag. Eine direkte Änderung dieser Datei sollte auf klassischen Shared-Hosting-Systemen nicht erlaubt sein, da Kunden somit jegliche Sicherheitsbeschränkungen (open_basedir, max_execution_time, memory_limit, etc.) aushebeln können.
Mit dem kommenden Update (v1.7.0) können die php.ini-Einstellungen auch pro Vertrag direkt im LiveConfig verwaltet werden.

Viele Grüße

-Klaus Keppler

You only need an internet connection for license activation and - every four weeks - for license renewal. Aside from this, LiveConfig does not talk with a license server. If renewal should fail (eg. because the license server is not reachable), you still have a "grace period" of one week. After that time, LiveConfig falls back to demo mode ("read only").

As long as you don't travel to mars, this should be enough for most cases.

Something like a dedicated "developer version" is not planned, this can easily be realized using a trial key. If you have special requirements, just drop us a note at support@liveconfig.com, in individual cases we can issue trial keys for longer terms (eg. 3 months).

Der Fehler wurde mit v1.7.0-r2638 behoben (siehe #95). In der Aggregierungsfunktion in der die Werte zusammengefasst werden (z.B. von minütlichen Meßwerten in stündliche/tägliche Daten) steckte ein Fehler in einem SQL-Befehl, der dazu führte das die Werte mehrfach gezählt wurden. Je nach Aggregierungsstufe potenzierte sich der Fehler entsprechend.

Alle Meßwerte ab der zweiten Aggregierungsstufe (i.d.R. stündliche Daten) sind somit im Grunde fehlerhaft. Mit dem Update werden diese Daten aus den RRD-Tabellen herausgelöscht (das betrifft i.d.R. alle Werte die älter als 8 Tage sind), damit die Zahlen wieder stimmen.

Ja, vermutlich wurde nach einer erfolgten Lizenzverlängerung eine ältere liveconfig.key wiederhergestellt.

In so einem Fall hilft es übrigens, die Lizenz neu zu aktivieren: liveconfig.key löschen, und "liveconfig --activate" ausführen.

Viele Grüße

-Klaus Keppler

Ein sauberer Neustart sollte das tatsächlich beseitigen (von Datenbankeingriffen raten wir dringend ab!).
Gab es Fehlermeldungen in /var/log/liveconfig/liveconfig.log?

Ich persönlich kenne nur den "alten" Sitebuilder; dort wurden FTP-Zugangsdaten hinterlegt, mit denen die Website dann veröffentlicht wurde. Somit funktioniert(e) das also auch mit LiveConfig.

In v1.7.0 wird bei den Vertrags-Berichten nun auch der Traffic angezeigt (wird man im nächsten Preview-Update bereits testen können).
Unter bestimmten Umständen enthielten die tageweise aufaggregierten Daten allerdings falsche Werte (konkret: wenn LiveConfig eine Zeit lang hing oder nicht lief, wurden die Daten mehrfach gezählt und somit falsch nachberechnet). Ab dem Update werden die Daten dann natürlich richtig bewertet.

Zitat von Febas

Den Schritt kann man eigentlich rauslassen? Die Konfiguration wird eh neuerstellt.

Nein, den kann man nicht weglassen. Die Konfigurationsdateien werden zwar teilweise neu erstellt, aber z.B. die Benutzerliste in /etc/dovecot/passwd nicht. Daher: alles sichern. Und ja, auch wir haben die Anleitung getestet bevor wir diese veröffentlicht haben.

Zitat von solidius

ich habe das Update r2636 installiert und habe noch immer die gleiche Maske bei der Bearbeitung von PHP.ini Einstellung für einzelne Verträge.

Äh - Mist... da steckte noch eine falsche Option vom Debugging drin; das Popup erscheint nur korrekt, wenn man Verträge unter "Mein Hosting" bearbeitet. Ich kümmere mich gleich mal darum...
(das passiert, wenn die Tests noch nicht vollständig sind... :()

Das sieht so aus, als ob LiveConfig nicht vollständig auf dem neuen Server installiert wurde - konkret scheinen die Ressourcen-Dateien unter /usr/share/liveconfig/ zu fehlen.
Erstellen Sie einfach eine Sicherung der aktuellen LiveConfig-Datenbank (/var/lib/liveconfig/liveconfig.db) und installieren das LiveConfig-Paket dann noch mal erneut - fehlende Dateien werden dabei automatisch hinzugefügt.

Viele Grüße

-Klaus Keppler

Die Preview wurde eben wieder aktualisiert (nun: v1.7.0-r2636). Diese enthält einige Bugfixes für zwischenzeitlich gemeldete Fehler, einige kleinere Erweiterungen/Verbesserungen und insbes. nun die Verwaltung von php.ini-Einstellungen pro Vertrag.
Bis Mitte kommender Woche möchten wir die Erweiterungen der Modultests soweit abgeschlossen haben, damit dann auch Builds für die restlichen Plattformen wieder automatisch erzeugt werden können.
Das nächste Update ist bereits für morgen Abend geplant (noch rechtzeitig vor dem Wochenende ;-))

Viele Grüße

-Klaus Keppler