Beiträge von kk

Zitat von arnoldB

Mir geht die Entwicklung derzeit viel zu schleppend voran. Das muss sich endlich ändern..

Auch wenn's ganz klein geschrieben ist möchte ich doch kurz was dazu anmerken: auf unserer Seite tut sich ziemlich viel (was man vermutlich nur hier im Büro mitbekommt, da sich noch nicht alles in der Preview wiederspiegelt). Einige Funktionen bringen einen großen peripheren Aufwand mit sich (Anpassung der Tests, Einbindung neuer Testplattformen, weitreichende Änderungen im LiveConfig-Kern etc.). Sobald der aktuelle "Brocken" aber geschafft ist, geloben wir wieder Updates in kürzeren Intervallen bereitzustellen.

Welche Linux-Distribution & -Version setzen Sie ein?

Zitat

Antwort des Servers: 451 4.7.1 Service unavailable - try again later

Was steht unmittelbar nach so einer Fehlermeldung im Postfix-Log? (meist /var/log/mail.log)

Sie können in LiveConfig FTPS (via TLS) aktivieren, sobald ein SSL-Zertifikat konfiguriert ist.
SFTP kann jeder Benutzer mit SSH-Zugriff nutzen; wer das weiter einschränken möchte, müsste das ggf. in /etc/ssh/sshd_config konfigurieren.

Zitat von aci

Can't get group quota for 'aci1000' (path '/var/www/xxxx'): No such process

Die Fehlermeldung selbst stammt vom Betriebssystem und nicht von LiveConfig, daher ist die leider recht kryptisch. Übersetzt heißt das so viel wie "Group Quota ist nicht aktiviert".
(Führen Sie einfach mal den Befehl "repquota -ag" aus - vermutlich bekommen Sie da keine Werte angezeigt)

Zitat

Außerdem zeigt mit LC nicht an, das mod-suPHP installiert ist. Ist ein rotes X, obwohl es drauf ist.
Ich nutze Ubuntu 64 Bit 12.04

Bitte starten Sie LiveConfig neu, nachdem Sie zusätzliche Apache-Module installiert oder deinstalliert haben.

Viele Grüße

-Klaus Keppler

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.