Beiträge von kk

Nein, sobald der Datenbankserver einmal zugewiesen wurde kann er (aktuell) nicht mehr geändert werden.
Wäre natürlich prinzipiell eine Idee, Änderungen zu ermöglichen (für neu anzulegende Datenbanken) - ich nehme das mal in die Wunschliste auf.

Wenn Sie in diesem Fall die Datenbank noch mal neu setzen möchten, müssen Sie per SQLite/MySQL in die LiveConfig-Datenbank eingreifen (wie immer: auf eigene Gefahr!):

UPDATE HOSTINGCONTRACTS SET HC_DBSERVERID=NULL WHERE HC_NAME="web123";

Viele Grüße

-Klaus Keppler

Zitat

Weiter wäre es toll wenn unter "Kunden" -> "Verträge" eine deutliche Kennzeichnung vorhanden wäre das hier abweichende Leistungen vorhanden sind.

Ist ab v1.5.2-r1843 enthalten.

Eine Liste der Verträge mit abweichenden Leistungen macht auch Sinn, folgt also noch irgendwann.

Ist inzwischen auch schon mit drin (ich glaube auch ab r1830).
Falls bestehende Kunden noch kein Log sehen können, müsste der betroffene Hostingvertrag einfach noch mal neu gespeichert werden, dann wird die Berechtigung gesetzt.
Mit Version 1.5.2-r1842 wird diese Berechtigung auch automatisch allen bestehenden Hostingverträgen hinzugefügt. In Kürze sind Vertragseigenschaften detaillierter bearbeitbar, da soll das als eigene Option verwaltbar sein.

Viele Grüße

-Klaus Keppler

Erledigt ab v1.5.2-r1841.

Die Meldung "Ungültiger Benutzername" erscheint, weil ein zu langer Name dann nicht mehr dem regulären Ausdruck entspricht, der beim betroffenen Eingabefeld hinterlegt ist; die Maximallänge wird nicht gesondert geprüft.
Nun wird aber die "maxlength"-Option im zugehörigen <input>-Feld korrekt gesetzt, so dass eine zu lange Eingabe nicht möglich ist.

Ist ab 1.5.2-r1830 enthalten (aktuell schon als Preview verfügbar). Kann pro Hosting-Angebot und pro -Vertrag eingestellt werden.
Wichtig ist, dass das Apache-Modul mod_fcgid installiert und aktiviert ist (erfolgt bei Installation mittels liveconfig-meta automatisch)

Viele Grüße

-Klaus Keppler

Welche Distribution nutzen Sie denn?
Auf den ersten Blick sollte das awstats_buildstaticpages.pl von Debian 7 diese Einstellung berücksichtigen.

Ah, ok - diese Statistik gibt's erst seit AWStats 7.0.
Nehmen Sie in die o.g. Liste bitte noch

ShowDownloadsStats=HB

mit auf.

Ja, diese Seiten wurden nicht generiert. Die AWStats-Konfiguration wurde nun entsprechend erweitert (ab LiveConfig r1835).
Um das zu korrigieren, löschen Sie dann einfach die Datei /etc/awstats/liveconfig/awstats.conf.liveconfig und speichern irgendeine Einstellung eines Webhosting-Kunden erneut ab, der AWStats nutzt (somit wird diese Konfigurationsdatei neu angelegt).

Alternativ fügen Sie folgende Befehle mit in die o.g. Datei ein:

ShowMenu=1
ShowSummary=UVPHB
ShowMonthStats=UVPHB
ShowDaysOfMonthStats=VPHB
ShowDaysOfWeekStats=PHB
ShowHoursStats=PHB
ShowDomainsStats=PHB
ShowHostsStats=PHBL
ShowAuthenticatedUsers=0
ShowRobotsStats=HBL
ShowWormsStats=0
ShowEMailSenders=0
ShowEMailReceivers=0
ShowSessionsStats=1
ShowPagesStats=PBEX
ShowFileTypesStats=HB
ShowFileSizesStats=0
ShowOSStats=1
ShowBrowsersStats=1
ShowScreenSizeStats=0
ShowOriginStats=PH
ShowKeyphrasesStats=1
ShowKeywordsStats=1
ShowMiscStats=a
ShowHTTPErrorsStats=1
ShowSMTPErrorsStats=0
ShowClusterStats=0
ShowFlagLinks=""
ShowLinksOnUrl=1

Zitat

Webserver not found or not permitted

Merkwürdig... wir werden morgen auch mal ein Multi-Server-Setup vorbereiten und das da testen.

Zitat

No reseller settings found - can't create customer ID automatically.

Ok... bitte melden Sie sich mal unter "res1" an, und füllen dort unter Einstellungen -> Wiederverkäufer-Einstellungen die entsprechenden Felder aus.
Das Import-Script braucht u.a. die Infos zur automatischen Erzeugung von Kundennummern.

Viele Grüße

-Klaus Keppler

... aber in Zeile 974 steckt tatsächlich ein Fehler - es soll $res lauten (if (!$res) {...) - wird eben aktualisiert

Standardmäßig verwendet das Script für Web/Mail/DB-Server jeweils "localhost".
Rufen Sie es bitte mit den Parametern "--webserver", "--mailserver" und "--dbserver" auf, bei denen Sie jeweils die Server-ID des zuständigen Servers angeben - das sollte dann eigentlich funktionieren.
Alternativ können Sie auch tricksen und den Reseller manuell in LiveConfig anlegen (der Reseller-Vertrag muss dann nur genau so heißen wie auf dem zu migrierenden Confixx-Server, also zB. "res1").

Viele Grüße

-Klaus Keppler

Das Migrationsscript und die Anleitung wurden aktualisiert: http://www.liveconfig.com/de/kb/5

Nun werden auch MySQL-Datenbanken und E-Mail-Postfächer/Adressen umgezogen.

Wir haben das Script bislang nur auf einer relativ kleinen Zahl an Confixx-Installationen testen können, auf diesen wurden aber alle Accounts erfolgreich migriert.
Falls bei Ihnen Fragen oder Probleme auftauchen, wenden Sie sich bitte direkt an uns (per Forum oder info@liveconfig.com).

Viele Grüße

-Klaus Keppler

Die Preview wurde eben noch mal aktualisiert - es handelt sich dabei größtenteils um ein Bugfix-Release. Jeder Nutzer der bisherigen Preview (r1823) sollte das Update ausführen.
Außerdem enthält die neue Version einige Erweiterungen für das neue Confixx-Migrationsscript (wird in ca. 1 Std auf der Website aktualisiert).

Viele Grüße

-Klaus Keppler

Ja, wird nur bei Neukonfiguration/Neuinstallation erzeugt.

Und ja: Aaaargh! :-/

Ursache ist eine Änderung in postfix.lua, mit der künftig eine frei konfigurierbare Liste an RBLs selbst verwaltet werden kann.
Um so was künftig zu vermeiden erweitern wir unser Testsystem gleich so, dass auch automatisch eine E-Mail an ein neues Postfach gesendet und abgerufen wird - damit sollte der komplette Mail-Prozess vollständig durchgetestet werden.

Fehler ist in r1830 beseitigt, Update wird in den nächsten Stunden im Test-Repo bereitgestellt (die aktuelle "Stable"-Version ist davon nicht betroffen)

Viele Grüße

-Klaus Keppler

Danke für den Hinweis - hier fehlte eine Prüfung ob /etc/awstats/liveconfig überhaupt existiert.
Ist ab r1829 beseitigt, der Cron in /etc/cron.d/liveconfig sieht dann so aus:

32    03    * * *     root       [ -d /etc/awstats/liveconfig ] && /usr/lib/liveconfig/cron.awstats.sh

Ah ja, sehe ich nun auch auf einem Testsystem. Das ist so nicht beabsichtigt. In der aktuellen Version (r1823) gab es einige Änderungen in der apache.lua, um u.a. auch abweichende Verzeichnisse für Webspace konfigurieren zu können; ich schätze mal, dass da nicht ordentlich aufgeräumt wird.
Ist also vermutlich ein Fehler, wird kurzfristig beseitigt und auch in unser Testprotokoll mit aufgenommen (LiveConfig soll keine unnötigen Rückstände hinerlassen)

Viele Grüße

-Klaus Keppler

Meinen Sie z.B. für einen Vertrag "web1" die Konfigurationsdatei "/etc/apache2/sites-available/web1.conf"?
Diese sollte eigentlich schon gelöscht werden.
Was steht bei Ihnen denn noch in der Datei drin - oder ist sie 0 Bytes groß?
Gibt es eventuell Fehlermeldungen in /var/log/liveconfig/liveconfig.log ?

Viele Grüße

-Klaus Keppler

Ich habe das eben mal überflogen; das Problem liegt vermutlich darin, dass die betroffene Domain in einem Unterverzeichnis konfiguriert wird und daher die RewriteRules nicht mehr greifen.
In der vHost-Konfiguration (/etc/apache2/sites-available/###.conf) sehen Sie irgendwo etwa folgenden Eintrag:

# Don't rewrite /cgi-bin/ and /.errorFiles/ URLs:
RewriteRule ^/(cgi-bin)|(.errorFiles)/.* - [L]

Erweitern Sie diesen mal einfach testweise um "icons" und starten Apache dann neu:

RewriteRule ^/[B](icons)|[/B](cgi-bin)|(.errorFiles)/.* - [L]

Alternativ installieren Sie die aktuelle LiveConfig-Preview (r1823) und lassen die betroffene vHost-Konfiguration neu erstellen (z.B. durch das Speichern irgendeiner Domaineinstellung) - mit der neuen Version werden auch Subdomains standardmäßig mit eigenen <VirtualHost>-Abschnitten eingerichtet. (die bisherige RewriteRule-basierte Konfiguration kann optional natürlich weiterhin so erzeugt werden)

Viele Grüße

-Klaus Keppler

Ja, aber vorsicht - aktuell wird nur das LiveConfig-Login für den betroffenen Kunden gesperrt - FTP/EMail/Webspace bleiben nach wie vor aktiv. Diese Funktion wird aber auch in den nächsten Tagen abgeschlossen (so dass es zur v1.5.2 "final" enthalten ist).
Ist auch keine ganz triviale Angelegenheit - ausführliche Beschreibung folgt dann, sobald die Funktion fertig ist.

Ok, gefunden: mit r1508 gab es eine Änderung in der Protokollierung der Logins; diese wurde in der betroffenen Anzeige noch nicht berücksichtigt. War also nur ein Anzeigefehler - die Login-Informationen sind korrekt protokolliert. Ab r1826 ist das dann beseitigt.

Viele Grüße

-Klaus Keppler