Beiträge von kk

Zitat von dicker

Can't open any socket for address 0.0.0.0, port 8443

Das deutet darauf hin, dass LiveConfig noch läuft.
Bitte stoppen Sie LiveConfig (/etc/init.d/liveconfig stop), prüfen ob es wirklich nicht mehr läuft (ps aux | grep liveconfig) und starten es dann noch mal neu (/etc/init.d/liveconfig start).

Falls es sich nicht vollständig beenden lässt: "killall -9 liveconfig", danach mit "ipcs" suchen ob es noch Shared-Memory-Segmente von LiveConfig gibt (siehe Handbuch).

Zitat

Dem Reseller stört es, dass da mein Servername steht, weil seine Kunden das ja sehen.

Wenn Server für Reselling genutzt werden, dann tragen diese üblicherweise auch "neutrale" Hostnamen. Auch wenn der Hostname nicht in LiveConfig angezeigt werden würde - er würde dennoch z.B. im SSL-Zertifikat für die LiveConfig-Oberfläche und ggf. im Reverse-DNS-Eintrag der Server-IP stehen.

Viele Grüße

-Klaus Keppler

Äh - so wie das aussieht sollten Sie sich unbedingt mit der Bedeutung von /etc/passwd auseinander setzen. Diese Zahlen darin sind extrem wichtig (User- und Group-IDs) und dürfen unter keinen Umständen geändert werden! (außer man weiß genau was man da macht).
Die "zusätzlichen" (virtuellen) FTP-Benutzer wie z.B. web1p1 werden nicht als Systemaccounts angelegt und sind daher auch nicht in /etc/passwd zu finden, sondern (je nach Software) in /etc/proftpd/passwd oder /etc/vsftpd/passwd.db. Auch da kann bzw. soll nichts manuell eingegriffen werden.

Insgesamt lese ich zwischen den Zeilen heraus, dass Sie LiveConfig auf einem Server aufgesetzt haben, auf dem bereits Confixx läuft? Ich befürchte, daß das nicht gutgehen wird, da sich nun zwei Control-Panels um die Konfigurationsdateien "streiten". Bitte setzen Sie für LiveConfig einen neuen ("leeren") Server auf und migrieren ggf. die Confixx-Accounts (siehe KB#5).

Viele Grüße

-Klaus Keppler

Ist ab v1.6.1-r2107 korrigiert.

Danke für den Hinweis, das ist im Stable-Release (1.6.1) dann auch berücksichtigt; die Bedingung wurde einfach so korrigiert, dass diese immer "positiv" ist:

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

Viele Grüße

-Klaus Keppler

Hmm, wenn ich das richtig sehen sollte der Milter-Socket unter CentOS 6 unter /var/run/clamav/clamav-milter.ctl liegen.
Im kommenden Stable-Release (1.6.1) dürfte das dann bereits korrigiert sein - ich lasse das morgen aber dennoch noch mal durchtesten.

Also, ich kenne da viel niedrigere Straßenpreise (eher um die <300 EUR).

Diese sollen natürlich auch exportier-/importierbar sein - in Form einer XML-Datei. Hier ist aber bislang noch nichts implementiert (da stehen noch ein paar wichtigere Dinge an).

Hmm, das sind eher interne Daten, die auch noch nicht konsequent aktualisiert werden. Hiermit soll jedenfalls die Version einer Konfigurationsdatei zurückverfolgt (versioniert) werden. Ich schätze mal, wir werden diese Anzeige vorübergehend eher mal entfernen, bis da verlässliche Daten drin stehen.

Auf unserer ToDo-Liste steht eine "Panic Button"-Funktion, mit der alle (bzw. alle gewünschten) Konfigurationsdateien neu erzeugt werden - damit dürfte das dann möglich sein.

Äh - das ist ein Mißverständnis; hier wird lediglich die Domain ausgewählt, unter welcher die Zugriffsstatistiken erreichbar sind. Berücksichtigt werden aber die Zugriffe auf alle Domains.

Dieser Punkt befindet sich noch in Arbeit - darüber werden künftig php.ini-Einstellungen individuell verwaltet.

Da gibt es auch eine Lösung: mit einem der nächsten Updates wird es möglich sein, Verträge neu zuzuordnen (also anderen Resellern - oder eben auch dem Admin). Damit könnten Sie den Import mittels einer Standard-Lizenz (Testlizenz) durchführen, dann die importierten Verträge dem "admin" zuordnen und zuletzt auf eine Basic-Lizenz umstellen.
Zum genauen Zeitplan kann ich noch nichts Verbindliches sagen - steht jedenfalls für das kommende Release auf unserer ToDo-Liste (der Issue-Tracker wird voraussichtlich morgen entsprechend überarbeitet).

Viele Grüße

-Klaus Keppler

PS: preislich liegt die Standard-Lizenz von LiveConfig durchaus in der Nähe der Confixx-Standard-Lizenz.

Wenn Sie einen ungültigen Angebotsnamen angeben, dann gibt es einen Fehler (in Form einer SoapException).
Am sichersten wäre also vorab die Anfrage mit HostingPlanGet (so macht es das Migrationsscript auch).

Sollte eigentlich nicht passieren...
Handelt es sich eventuell um gesperrte FTP-Benutzer, die nicht importiert wurden?
Ansonsten wenden Sie sich bitte per Mail an support@liveconfig.com, dann müssten wir das mal im Detail untersuchen.
Im Migrationsscript finden Sie den verantwortlichen Code ca. in Zeile 865ff.

Viele Grüße

-Klaus Keppler

Reden Sie von Domains oder Verträgen?
Wenn für einen Vertrag die Zugriffsstatistiken aktiviert werden, dann gilt das für alle darin enthaltenen Domains (schließlich wird ja die komplette access.log des Vertrags ausgewertet).

Unter Serververwaltung -> Web -> Webstatistik-Einstellungen kann eingestellt werden, welche Software (AWStats/Webalizer) ggf. automatisch für neue Verträge aktiviert werden soll.

Viele Grüße

-Klaus Keppler

Von alleine passiert mit den Konfigurationsdateien normalerweise nichts - erst wenn irgendeine Änderung vorgenommen wird, wird die jeweilige Datei neu geschrieben.
Falls LiveConfig übrigens beim Start feststellt, dass es sich um eine "ältere" Datenbank handelt, werden eventuell notwendige Schema-Updates automatisch ausgeführt (soll heißen, das Restore einer älteren Datenbank ist - wenn nötig - jederzeit möglich).

Das Bearbeiten von E-Mail-Adressen steht schon in den Startlöchern, kommt mit dem nächsten Preview-Update Anfang der Woche (erst erfolgt noch die Freigabe der nächsten Stable-Version am Montag).

Ansonsten ist ein Bearbeiten von Einstellungen jeglicher Art außerhalb von LiveConfig weder vorgesehen noch empfohlen. Dafür gibt es die SOAP-API - sollte ein API-Befehl "fehlen", einfach Bescheid geben, damit wir das aufnehmen können.

Viele Grüße

-Klaus Keppler

Nein; weitere Lizenz-Varianten sind nicht geplant. Es wird aber eine Kaufversion geben, die sich preislich an den üblichen AfA-Zeiträumen orientiert (Details folgen noch).

In dem o.g. Fall würde die Basic-Lizenz vielleicht schon genügen. Sie müssten die Webspaces aber "manuell" importieren: legen Sie als "admin" einfach die 8 Webspaces sowie 8 weitere Benutzer an. Jedem Benutzer können Sie individuell die Berechtigungen so einschränken, dass er nur auf "seinen" Vertrag zugreifen kann.
Probieren Sie das am besten mit einer Testlizenz mal aus (bestellen Sie hierzu direkt eine Basic-Testlizenz).

Viele Grüße

-Klaus Keppler

Ich skizziere mal kurz, was gerade in Arbeit ist - weitere Anregungen sind (wie immer) herzlich willkommen.
Wie an anderer Stelle schon beschrieben sollen Kunden die Möglichkeit haben, ein "dynamisch erzeugtes" Backup herunterzuladen. Es wird also nicht erst ein .tgz auf dem Server erzeugt, welches dann später irgendwann per FTP abgeholt werden kann, sondern mit Klick auf einen speziellen Download-Link stellt LiveConfig alle relevanten Daten in einem .ZIP- oder .tar.gz-Stream bereit.
Aktuell werden für Webspace und Datenbanken (sowie später für E-Mails) jeweils separate Download-Links erzeugt, da sich diese Inhalte prinzipiell auf verschiedenen Servern befinden können.
Womit wir schon beim nächsten Problem wären: in einer Multi-Server-Umgebung klickt der Kunde zwar auf dem "Hauptserver" herum, sein Webspace kann sich aber auf einem anderen Server befinden. Ein Download müsste also - um "sauber" stattzufinden - vom Webspace-Server über den LiveConfig-Hauptserver zum Browser gesendet werden. In den meisten Setups befinden sich alle mit LiveConfig verwalteten Server ja im selben Subnetz am selben Standort, was also keine Traffickosten verursachen sollte - dennoch ist es eigentlich unnötiger Traffic. Eleganter wäre es, wenn der Download direkt vom jeweiligen Quellserver stattfände. Ein LiveConfig-Client kann durchaus einen temporären Server-Socket öffnen, von dem ein Browser dann den Download starten kann. Damit das halbwegs sicher ist (schließlich können ja auch vertrauliche Daten dabei sein) sollte diese Verbindung aber SSL-gesichert sein. Tjo - und da wären wir wieder beim Zertifikats-Problem - sofern man nicht wirlich für jeden Server ein eigenes, "offizielles" SSL-Zertifikat besitzt, würde also eine Sicherheitswarnung erscheinen.

Ich hoffe, ein wenig Licht in unsere Überlegungen gebracht zu haben.
Die erste Implementierung sieht nun vor, dass der Stream vorerst ggf. über den Hauptserver geleitet wird, damit Besucher keine Zertifikatswarnung bekommen. Im nächsten Schritt sollen "statische" Download-Links generiert werden können, mit denen man dann z.B. mit wget einen Backup-Download automatisieren könnte.
Eine weitere Idee ist, dass Benutzer einen SSH-Key hinterlegen können, mit dem ein rsync-Zugriff möglich wäre (mit entsprechender Einschränkung der Key-Verwendung).

Viele Grüße

-Klaus Keppler

Wenn es darum geht, den kompletten Server zu sichern, ist TAR & FTP die absolut ungünstigste und ressourcenlastigste Lösung (nur weil andere Control-Panels das so machen heißt nicht, dass das gut ist...).

Die meisten unserer Kunden sichern komplette Server über Lösungen auf Basis von rsync (eigene Scripts oder BackupPC) oder erzeugen gleich Images über virtualisierte Storage (also Snapshots).

Wir planen für Endkunden ein bequemes Backup einzelner Webspaces (Download des Webspaces & Datenbank-Dumps als .tar.gz/.zip-Datei, die on-the-fly erzeugt werden). Außerdem gibt es noch ein paar Ideen in Richtung Cloud Storage (ownCloud, Dropbox, ...) - mal schauen

Viele Grüße

-Klaus Keppler