Beiträge von kk

Hallo,

die URL bleibt die selbe, nur sollte dann im Hintergrund eben AWStats die Statistiken erzeugen.
Bitte öffnen Sie die aktuelle Statistik und drücken dann im Browser mal die F5-Taste (oder <Strg>+<R>), um die Anzeige zu aktualisieren.
Werden die Werte von Webalizer derzeit noch aktualisiert (sprich: Sie haben vor zwei Tagen umgestellt - sind trotzdem noch die Zahlen von gestern im Webalizer zu sehen?) Falls nicht, dann ist eventuell "awstats" nicht auf dem Server installiert - bitte klären Sie das dann mit Ihrem Anbieter ab.

Viele Grüße

-Klaus Keppler

Zitat von Jim

Der Kunde hat nicht ein Passwort geändert sondern eine seiner Datenbanken gelöscht.
Da nach einem Import von Confixx ja alle Datenbanken den gleichen Datenbank-Benutzer haben ist dies ein Problem, da dem Anschein nach durch das Löschen einer Datenbank auch der Datenbank-Benutzer gelöscht wird obwohl dem Benutzer noch mehr Datenbanken gehören.

Das Problem wurde mit v1.6.2-r2236 beseitigt; LiveConfig prüft dabei noch mal unabhängig direkt in den MySQL-Benutzertabellen, ob einem Benutzer evtl. noch weitere Datenbanken gehören, und löscht diesen dann ggf. nicht.

Viele Grüße

-Klaus Keppler

Zitat

database is locked

Wie viele Kunden haben Sie in der LiveConfig-Installation angelegt?
Offenbar verwenden Sie als Datenbank-Backend "SQLite" (siehe /etc/liveconfig/liveconfig.conf) - am besten stellen Sie das auf MySQL um: http://www.liveconfig.com/de/kb/15

Die o.g. Meldung deutet darauf hin, dass ziemlich hohe I/O-Last vorliegt - das kommt bei LiveConfig höchstens dann vor, wenn Sie mehrere hundert Webspaces mit SQLite verwalten.

Wir können das hier leider nicht nachvollziehen bzw. reproduzieren.
Melden Sie sich bitte bei Gelegenheit als root-Benutzer bei MySQL an und führen vor der Passwortänderung folgende Abfragen aus:

SELECT Host, User, Password FROM mysql.user WHERE User='web123';
SELECT Host, User, Db FROM mysql.db WHERE User='web123';

Ändern Sie anschließend bitte über LiveConfig das Passwort für diesen Benutzer und führen anschließend noch mal die selben SQL-Abfragen aus.
Die Ergebnisse der Abfragen können Sie hier entweder posten (dann aber bitte beim Passwort-Hash nur die letzten Zeichen durch irgendwas ersetzen), oder uns per PM oder an support@liveconfig.com senden.

Viele Grüße

-Klaus Keppler

Kurz gesagt: eigentlich sollte eine neue Datenbank sofort angelegt werden. Wenn das nicht passiert, dann ist entweder die Verbindung zum MySQL-Server nicht möglich oder bei einem der LiveConfig-Prozesse hat sich etwas aufgehängt.
So oder so sollte dann die Datei /var/log/liveconfig/liveconfig.log mehr Aufschluss geben. Wenn Sie möchten, schicken Sie uns diese Datei gerne mal per Mail an support@liveconfig.com - wir schauen uns das dann gerne mal an.

Viele Grüße

-Klaus Keppler

Wir haben den Mailversand mit den uns zugesendeten Test-Zugangsdaten ausprobiert. Von unserem Büroanschluss aus (Standleitung) mit Thunderbird klappte der Versand problemlos binnen weniger Sekunden.

Es handelt sich höchstwahrscheinlich um ein Anbindungsproblem des Servers und/oder des Kunden, wenn der Versand mal bei 30%, mal bei 87% abbricht...

Viele Grüße

-Klaus Keppler

Welche LiveConfig-Version setzen Sie ein?

Hallo,

vielen Dank für die Rückmeldung - der Fehler ist nun beseitigt (zumindest haben wir das nun erfolgreich reproduzieren und testen können). Das Update steht im Lab-Repository bereit (v1.6.2-r2245).

Unsere automatisierten Tests werden wir gleich anpassen, um solche Fehler künftig direkt erkennen zu können.
Entschuldigen Sie bitte die Umstände.

Viele Grüße

-Klaus Keppler

Danke für die Rückmeldung. Ich habe mir den zuständigen Codeabschnitt eben angesehen und ein mögliches Problem identifiziert (für die neue/bessere Sortierung von Verträgen werden die Vertragsnamen nun zusätzlich "zerlegt" und in den Spalten HOSTINGCONTRACTS.HC_SORT1 und HC_SORT2 gespeichert - da liegt eventuell der Hund begraben).
Aus Interesse: wie lautete denn der Name von dem Vertrag? (subscriptionname)

Ich habe ein korrigiertes Update bereitgestellt - könnten Sie das bitte einspielen und es damit noch einmal versuchen?
liveconfig_1.6.2-r2244_amd64.deb (falls Sie eine andere Distri/Plattform brauchen, geben Sie bitte Bescheid)

Besten Dank & viele Grüße

-Klaus Keppler

Zitat

Entschuldigen Sie bitte Herr Keppler, aber mehr wie schreiben, dass es damit auch nicht ging, kann ich leider nicht.

Doch. Schreiben Sie bitte statt "Nein es geht auch damit nicht." etwas wie "Nein, mit Thunderbird klappt es auch nicht, die maximale Maigröße auf 25 MB zu setzen hat auch nicht geholfen, und auch nach einem Neustart des Postfix-Services hat sich keine Änderung ergeben".
Je ungenauer Sie Ihr Problem formulieren, desto mehr kann falsch interpretiert werden, und desto schwieriger wird es, Ihnen zu helfen.

Wie oft soll ich noch danach fragen, ob es auch mit Thunderbird nicht funktioniert?
Richten Sie uns ggf. mal einen Testaccount (E-Mail) ein, dann probieren wir das gerne mal durch (die Daten bitte an support@liveconfig.com schicken).

Derzeit kann jeder Benutzer den externen MySQL-Zugriff aktivieren (vorausgesetzt natürlich, dass MySQL selbst von außen erreichbar ist, z.B. per "bind-address=0.0.0.0"). Leider kann LiveConfig nicht automatisch herausfinden, ob das der Fall ist (die Status-Variable "bind-address" wird erst in den allerneuesten MySQL-Versionen per "show variables" bereitgestellt).

Wir könnten aber prinzipiell die externe Erreichbarkeit auch pro Server (in der Serververwaltung) oder ggf sogar pro Vertrag steuerbar machen. In letzterem Fall möchten wir jedoch vermeiden, langfristig eine exorbitant komplexe Vertrags-Maske zu produzieren...

Die Frage war vielmehr, warum in diesem konkreten Fall von der Lab- zurück auf die Stable-Version gewechselt werden soll (also ob ein akutes Problem besteht).

Für die Freigabe von v1.6.2-stable fehlt nur noch der Abschluss der php.ini-Verwaltung, das dauert also nicht mehr lange.

Viele Grüße

-Klaus Keppler

Noch mal: geht es mit anderen E-Mail-Programmen (Thunderbird) auch nicht?
Wurde Postfix neu gestartet?
Setzen Sie das Limit ggf. mal auf einen sinnvolleren Wert herunter (50MB).

Eine weitere häufige Fehlerquelle sind auch lokale Virenscanner, welche sich beim Mailversand quasi zwischen das Mailprogramm und den Mailserver klemmen. Wenn in der Log-Datei (mail.log) beim Sendeversuch überhaupt nichts auftaucht, dann sitzt der Fehler schon viel weiter vorne.

Ab sofort steht die Preview-Version v1.6.2-r2243 zum Download zur Verfügung.

Die wichtigsten Neuerungen sind:

• Deaktivierung aller Websites wenn ein Kunde deaktiviert wird (bei Resellern gilt das rekursiv für all deren Kunden)
• Sortierung von Hostingvertrags-Namen verbessert (web1, web10, web2, web20 -> web1, web2, web10, web20, ...)
• Benutzer können nun externen MySQL-Zugriff verwalten
  (falls SSL für MySQL aktiviert ist, kann der externe Zugriff sogar auf SSL-Verbindungen beschränkt werden)
• Verwaltung von Bemerkungen für MySQL-Datenbanken
• kleinere Anpassungen in SOAP-Funktionen (UserGet() hinzugefügt, HostingSubscriptionGet() erweitert, ...) - weitere Funktionen sind noch in Arbeit.

Außerdem wurde noch einiges an der php.ini-Verwaltung getan; dieser Bereich wird in Kürze abgeschlossen, womit der Freigabe von v1.6.2-"stable" dann nichts mehr im Wege steht.

Viele Grüße

-Klaus Keppler

Hallo,

nein, wenn in der "neuen" Datenbank schon Daten angelegt wurden (neue Kunden etc.), dann kann nicht zurück gewechselt werden (LiveConfig ist zwar jeweils "abwärtskompatibel", kann also jede noch so alte LiveConfig-Datenbank auf den aktuellen Stand bringen, nur anders herum geht das eben nicht).

Das Repository selbst können Sie dennoch auf das Stable-Repo zurück stellen, dann erhalten Sie das nächste LiveConfig-Update automatisch wieder aus "stable". Gibt es ansonsten einen bestimmten Grund, warum Sie von der Lab- auf die Stable-Version wechseln möchten? (das nächste Lab-Update steht unmittelbar bevor)

Viele Grüße

-Klaus Keppler

- Klappt das nur mit Outlook nicht?
- Was sagt die Log-Datei nach einem Abbruch? (/var/log/mail.log)

Naja, "ohne Rücksicht" klingt schon etwa hart... Schließlich fragt LiveConfig ja eingangs nach, ob es die Verwaltung der jeweiligen Konfigurationsdateien übernehmen darf/soll.
Aber im Grunde stimmt das: LiveConfig überschreibt Konfigurationsdateien meistens (Ausnahmen bestätigen die Regel... s.u.). Der Grund dafür ist, dass ein Parsen der ggf. vom Benutzer manuell hinzugefügten Einstellungen sowie eine Prüfung auf Verträglichkeit mit von LiveConfig vorzunehmenden Einstellungen in den meisten Fällen unverhältnismäßig kompliziert ist.

Wichtig ist aber:LiveConfig aktualisiert prinzpiell keine Konfigurationsdatei selbständig - auch nicht bei einem Upgrade. Tut der Benutzer nichts, dann bleibt im o.g. Fall auch nach einem Upgrade die "alte" (manuell bearbeitete) Konfigurationsdatei aktiv. Erst wenn man in der Serververwaltung etwas an einer Dienstkonfiguration ändert, wird diese neu geschrieben.

Und da sind wir schon beim zweiten wichtigen Punkt: für die meisten Konfigurationsdateien gibt es inzwischen Sperr-Mechanismen, mit denen ein Überschreiben durch LiveConfig verhindert werden kann. Im Handbuch werden diese nun schrittweise erfasst (z.B. für Postfix).

Viele Grüße

-Klaus Keppler

Hallo,

während dem Update müsste in diesem Fall die alte liveconfig.conf als liveconfig.conf.rpmsave gesichert worden sein.
Es stimmt aber, dass dieses Vorgehen nicht optimal ist. Ab v1.6.2-r2233 enthält die RPM-Konfiguration eine Anweisung, dass die vorhandene Konfigurationsdatei beibehalten und die ggf. neue Konfigurationsdatei mit dem Suffix .rpmnew gespeichert wird (wen die technischen Details interessieren: siehe hier).

Viele Grüße

-Klaus Keppler

Zitat

Eine kurze Frage. Wird die liveconfig.log eigentlich direkt von Liveconfig verwaltet bzw. rotiert?

Nein, diese Logdatei wird nicht rotiert. Ist auch nicht gaaanz trivial: die Logdatei wird beim Start mit root-Rechten geöffnet, später verwirft der GUI-Prozess von LiveConfig seine Rechte und schreibt weiter in diese Datei. Für eine Log-Rotation müsste die Datei geschlossen und neu geöffnet werden - das würde einen Neustart zumindest des Client-Prozesses innerhalb LiveConfigs erfordern.

Lange Rede, kurzer Sinn: eigentlich sollte in diesem Log ohnehin nicht sehr viel drin stehen (die aktuellen Update-Meldungen fürs Repository werden künftig auch auf einen anderen Loglevel gesetzt), so dass die Datei im Laufe ihres Lebens gar nicht großartig anwachsen sollte.

Zur Rotation von Apache access.logs (ein völlig anderes Thema): unser Tool "lclogsplit" (welches die access.logs in den Kundenverzeichnissen live erzeugt) unterstützt intern seit r2163 bereits die Anonymisierung von IP-Adressen (v4 und v6). In der Logrotate-Konfiguration steht zudem jeweils ein eigener Eintrag pro Kunden-Log-Datei - technisch haben wir also alle Voraussetzungen geschaffen, um individuell pro Vertrag die Log-Rotation und IP-Anonymisierung verwalten zu können. Es fehlt schlicht noch an der notwendigen Eingabemaske, um diese Einstellungen zu ändern. Diese wird aber mit einem der nächsten Updates kommen (unverbindlich: ca. v1.7.1, gegen Mai/Juni).

Viele Grüße

-Klaus Keppler