Beiträge von kk

Die einfachste Lösung wäre, am kommenden Dienstag die 1.5-preview zu installieren (die räumt dann auf). Der direkte Zugriff auf die interne Datenbank ist nicht ganz so einfach, da einige Abhängigkeiten innerhalb der Datenbank bestehen (es reicht also nicht, einfach nur einen Eintrag in der Tabelle APPS zu löschen, sondern 1-2 weitere Datensätze müssen noch mit angepasst werden). Bei Bedarf geben Sie bitte kurz Bescheid, dann suche ich die entsprechenden SQL-Befehle heraus.

Das "Problem" mit der v1.5 waren die umfangreichen Änderungen im Kern von LiveConfig, um die flexible Verwaltung der IP-Adressen (u.a. für SSL) zu ermöglichen. Die Abhängigkeiten bei einer automatisierten Serverkonfiguration sind enorm und müssen alle in jeder Eingabemaske geprüft werden, um keine inkonsistente Konfiguration zu erzeugen. Und da wir keinen "Copy&Paste-Code" erzeugen (der sich dann irgendwann nicht mehr pflegen lässt) dauerte das leider länger als erwartet.
Um zu zeigen, dass sich in den letzten Wochen viel getan hat, werden wir am Dienstag (26.06.) die "Preview" für die v1.5 freigeben; es gibt dort noch ein paar kleinere Schönheitsfehler, aber im Grunde sind alle wichtigen Änderungen drin. Bis zur produktiven Freigabe dauert es dann nur noch "wenige Tage"™.

Viele Grüße

-Klaus Keppler

Hallo,

Zitat

Datenbankname existiert bereits.

Das ist ziemlich merkwürdig, weil während der App-Installation eine eigene Datenbank pro Anwendung angelegt wird. Ich könnte mir nur vorstellen, dass der automatisch erzeugte Name mit einem bestehenden Datenbanknamen kollidiert ist; vermutlich wird das noch nicht abgefangen. Wir werden das morgen gleich mal prüfen; sollte das so der Fall sein, rutscht der Bugfix auch gleich noch in die v1.5.0 mit hinein.

Dass die Anwendung nun nicht gelöscht werden kann dürfte vermutlich damit zusammenhängen, dass diese gar nicht vollständig installiert wurde. In v1.5 können auch solche "halben" Installationen entfernt werden; ein Eingriff in die interne Datenbank sollte optimalerweise nie notwendig sein.

Viele Grüße

-Klaus Keppler

Klar, kein Problem. LiveConfig Server und Clients können auch über private Adressen oder VLAN-IPs miteinander kommunizieren. In der Client-Configuration (lcclient.conf) gibt man die IP-Adresse des Servers an, zu dem die Verbindung aufgebaut werden soll. In welchem Netz diese liegt ist dem Cliet völlig egal, so lange er diese erreichen kann. Nach "außen" hin spielt diese IP wiederum keine Rolle. Bei der Service-Konfiguration (z.B. Apache) kann man auswählen, auf welchen IPs der Dienst erreichbar sein soll - und dort wiederum die "interne" IP nicht nutzen.

Viele Grüße

-Klaus Keppler

Wir haben uns inzwischen Gedanken dazu gemacht. Für Version 1.5.2* ist geplant, "zentrale Anwendungen" wie eben phpMyAdmin, Roundcube usw. über die LiveConfig-Oberfläche konfigurieren zu können. Somit können auch wieder die (gemanagten) Pakete der Distribution genutzt werden, alternativ wird es einen Mechanismus geben um selber (ggf. aktuellere) Anwendungen bereitzustellen.
Nähere Details hierzu dann in etwa zwei Wochen.

*) v1.5.0 ist gerade in der Schlußphase, v1.5.1 wird rund 2 Wochen danach herauskommen (hier ist bereits der "Feature Freeze" erfolgt). Mit v1.5.2 kann dann (ganz vorsichtig gesagt) in etwa 4-6 Wochen gerechnet werden.
Bei Bedarf können wir hier vorab die notwendigen Konfigurationsschritte beschreiben, um diese "zentralen Anwendungen" bis dahin noch manuell einzurichten.

webby: Welche Distribution verwenden Sie?
Wurde vom Installer unter /var/www/web26/apps/ das Verzeichnis für Wordpress angelegt, und evtl. Wordpress darin schon entpackt?

Zitat

X-Powered-By: PHP/5.2.6-1+lenny13
Content-type: text/html

Geben Sie bitte den LiveConfig Server an (localhost oder IP):

Öh, offenbar haben Sie das Migrationsscript nicht über die Kommandozeile, sondern via CGI ausgeführt?
So ist das nicht gedacht, da alle notwendigen Eingaben über die Konsole abgefragt werden. Auch in der Anleitung ist der Aufruf via CLI beschrieben:

Zitat

/usr/bin/php5 cfximport.php --config

Zu den einzelnen Problemen:

Zitat

weder unter Angebote, noch unter mein Hosting waren Angaben zu erkennen

Wenn Sie im Confixx unter "res1" Angebote angelegt hatten, sollten diese auch im LiveConfig innerhalb des "res1"-Benutzers zu finden sein. In Confixx hat der "root"-Account ja schließlich auch keine eigenen Hosting-Angebote, da dies Sache der Reseller ist.

Zitat

Beim Aufruf des Kunden ist das Register Domains leer, unter Verträge gibt es nur res1 - hier sind aber keine Details aufrufbar.

Ja, das ist auch so beabsichtigt. Die Domains sind schließlich den Endkunden (web1, web2 usw.) zugeordnet, daher sieht man diese auch nicht als "admin" in LiveConfig. Wenn Sie sich in LC als "res1" anmelden (bzw eine Verbindung damit starten), sollten Sie unter "Kunden" alle Kunden sehen, sowie bei diesen jeweils einen Vertrag (web1, web2, ...) und die dazugehörigen Domains.

Wir bereiten für das Handbuch derzeit eine Zeichnung vor, welche die Struktur vom Admin, Resellern und Endkunden etwas verdeutlichen soll (ich prüfe mal wie weit das ist und schaue ob wir die hier vorab schon mal bereitstellen können)

Zitat

Wenn ich mit "res1" eingeloggt bin (über Verbindung starten) wird nichts angezeigt, außer den Menupunkten Übersicht und Einstellungen, d.h. ich kann die Verträge nicht bearbeiten.

Das schaut eher nach einem Bug aus. Bei unseren Import-Tests hatte das zwar funktioniert, aber wir werden das gerne noch mal genauer unter die Lupe nehmen.

Zitat

Die Daten von web1 und web4 wurden zusammen unter web4 importiert, für web1 ist kein Login möglich

Welche Daten genau meinen Sie, die "gemeinsam" importiert wurden? Wenn web1 und web4 die selben Personendaten im Confixx hinterlegt hatte, dann kann es sein, dass diese beim Import in LiveConfig als ein einzelner Kunde mit zwei Verträgen (web1/web4) angelegt wurden. Könnten Sie das bitte kurz prüfen?

Zu Ihrer älteren Frage:

Zitat

Als einen der Pluspunkte möchte ich natürlich ein zentrales Login nutzen, was passiert aber mit den importierten Daten? Auf jedem Server habe ich bisher einen web1, web2, web3, etc. Identisch sieht es dann mit den Postfächern, Datenbanken, usw. aus.
Was wird das Migrationsscript aus diesen Daten machen, da ja alles auf dem Server mit der Business-Lizenz importiert werden muss. Schafft das Script das, oder sollte ich doch lieber eine Alternative zum importieren finden?

Kollissionen in den Namen kann LiveConfig natürlich nicht automatisch auflösen. Der Name für Webspace-Verträge (zB. "web4") muss auch bei einer Multi-Server-Installation systemweit eindeutig sein. Ich könnte mir spontan vorstellen, dafür Präfixe beim Import einzuführen, so dass alle vom Server1 importierten Kunden das Präfix "s1" erhalten (s1web1, s1web2, ...), von Server2 "s2" (s2web1, s2web2, ...) usw.
Alternativ könnte man ein "Offset" definieren, um das alle Vertragsnamen automatisch erhöht werden: bei Server1 Offset=1000 (web1 -> web1001, web2 -> web1002, ...), Server2 Offset=2000 (web1-> web2001, web2 -> web2002, ...).
Beide Varianten können wir als Kommandozeilen-Option in das Import-Script mit aufnehmen. Würde Ihnen das weiterhelfen?

Viele Grüße

-Klaus Keppler

Zitat

Ein Quota ist ja auch nicht installiert, da das unter Virtuozzo nicht geht.

Quota funktioniert unter Virtuozzo und OpenVZ durchaus - das nennt sich dort "Second Level Quota":
* Quota mit Virtuozzo
* Quota mit OpenVZ

LiveConfig liest auch bei "unbegrenzten" Quotas die Anzahl & Größe der verwendeten Dateien ausschließlich über das Quota-System aus. Ein "Counterscript" ist I/O-technisch irrsinnig. Die Quotas und Statistiken sind somit auch "in Echtzeit" aktuell.

Zitat

Wie kann ich diese Logeinträge unterbinden?

Wir werden eine Änderung in die entsprechende Routine einbauen, so dass diese Meldung nur ein mal pro LiveConfig-Start erfolgt. Quotas können dann trotzdem im laufenden Betrieb aktiviert werden, ohne LiveConfig neu starten zu müssen. Dieser Fix ist auch gleich im nächsten Update (v1.5.0) enthalten.

Viele Grüße

-Klaus Keppler

Zitat

LiveConfig legt den Kunden mit DocRoot /var/www/webXXX/htdocs an, erstellt die App (z.B. WordPress) jedoch im Verzeichnis /var/www/webXXX/apps/DIR -> die App liegt somit nicht unterhalb des eingestellten DocRoot

Ja, das ist so beabsichtigt. In der /etc/suphp/suphp.conf muss daher die Einstellung check_vhost_docroot=false gesetzt werden. Hier handelt es sich im Grunde noch um einen "Documentation Bug" - das gehört noch mit in die Anleitung. Die neuesten Versionen der LiveConfig-Meta-Packages setzen diese Einstellung automatisch richtig.

Zitat

Beim Löschen der App wird die Rewrite Regel unter /etc/apache2/sites-available/webXXX.conf nicht gelöscht

Danke für den Hinweis - dieser Fehler wird gleich mit dem kommenden Update beseitigt.

Viele Grüße

-Klaus Keppler

Hallo,

wenn diese Fehlermeldung erscheint, werfen Sie bitte einen Blick in /var/log/apache2/error.log - dort gibt es weitere Informationen.

Viele Grüße

-Klaus Keppler

Wir bekommen derzeit eine ganze Menge Anfragen, wann die nächste Version (1.5.0) fertig ist. Daher möchte ich an dieser Stelle kurz ein paar Infos zum nächsten Release geben.

Das größte neue Feature in v1.5.0 ist die Verwaltung von SSL-Zertifikaten (zur Konfiguration von HTTPS-Webspace). Die komplette Zertifikatsverwaltung ist abgeschlossen:
forum.liveconfig.com/cms/attachment/4/

Auch die Konfiguration der (Sub-)Domains ist bereits fertig:
forum.liveconfig.com/cms/attachment/5/
Derzeit arbeiten wir noch am "letzten Schliff" für die IP-Verwaltung (daher die Platzhalter im vorigen Screenshot). Nach wie vor ist es ratsam, Domains mit einem SSL-Zertifikat auf einer eigenen ("exklusiven") IP-Adresse zu betreiben, da nach wie vor der Internet Explorer (egal welche Version) unter Windows XP kein SNI unterstützt.
Wir haben uns sehr lange und sehr gründlich Gedanken gemacht, wie LiveConfig die Verwaltung der IPs möglichst elegant lösen kann. Mit dem Ergebnis sind wir recht zufrieden, und hoffen auch seitens der LiveConfig-User auf Zustimmung
Kurz gesagt, werden IP-Adressen in Gruppen verwaltet. Eine IP-Gruppe kann eine oder auch mehrere IPs enthalten - Domains werden dann z.B. im Apache jeweils auf allen IPs einer Gruppe konfiguriert (so sind Multihomed- und IPv4/IPv6-Dualstack-Adressen ein Kinderspiel). Gruppen können dann jeweils gemeinsam ("shared") oder exklusiv genutzt werden. Eine exklusiv einem Reseller zugeteilte IP kann dieser selber so konfigurieren wie er diese benötigt (also z.B. als Shared-IP für seine Kunden, oder wiederum exklusiv für einen bestimmten Kunden usw...).
Wir haben uns auch alle derzeitigen Ansätze anderer Control-Panels angeschaut und nichts vergleichbares finden können. Gerade die Verwaltung mehrerer IPs für verschiedene Reseller und Endkunden läuft meist recht unübersichtlich ab und/oder bedarf einiger manueller Bastelei.

Unabhängig davon gibt es noch eine ganze Menge Detailverbesserungen und anderer neuer Features in der nächsten Version, die wir dann zum Release ausführlicher vorstellen werden.
Wir möchten uns nicht auf einen genauen Termin festnageln lassen, da dieses Update auch noch ausführlicher getestet werden muss als bisher - aber es sollte sich nur noch um wenige Tage handeln (idealerweise noch vor dem World IPv6 Launch)

Viele Grüße

-Klaus Keppler

v1.5 kommt in den nächsten Tagen (bis Ende nächster Woche) heraus, falls nichts mehr dazwischen kommt. Wir schließen derzeit nur noch die Verwaltung der IP-Adressen für Reseller ab.
Eine Neuinstallation ist nicht notwendig - eines der wichtigsten Features von LiveConfig ist ein reibungsloses Upgrade von jeder Version.

Wir bieten direkt keine Rabatte für andere Zahlungsräume an - aber vielleicht finden Sie einen LiveConfig-Partner der Ihnen das anbieten kann.

Viele Grüße

-Klaus Keppler

Wir haben uns die entsprechenden Masken mal vorgenommen. Ihre Anmerkungen sind nachvollziehbar und berechtigt, eine Lösung ist aber etwas kniffliger.

Das Mailbox-Quota wird in LiveConfig direkt als Maildir-Quota realisiert, d.h. jedes Postfach braucht quasi irgendeinen Quota-Wert. Daher ist es technisch nicht möglich, mehrere Postfächer zu haben, die gleichzeitig das "restliche" maximale Quota nutzen können. (einzige Ausnahme wäre, wenn der Kunde unbegrenzten Mailspace bekommen würde)

Theoretisch könnten wir ein Postfach so konfigurieren, dass es automatisch "alles übrige Quota" bekommt (wird dann eben immer aktualisiert, wenn irgendein anderes Postfach angelegt/gelöscht wurde). Hierfür wäre es aber Sinnvoll, auch ein "Mindest-Quota" dafür festlegen zu können (damit das Postfach nicht "zu klein" werden kann).
Eine weitere Idee wäre ein automatisches Aufteilen der Gesamt-Quota auf alle eingerichteten Postfächer. Hier kann es dann aber auch unübersichtlich bzw. problematisch werden, wenn ein neues Postfach angelegt wird, und der neue "Quota-pro-Postfach"-Wert für einzelne Postfächer nicht mehr reicht.

Beim Anlegen eines Postfachs haben wir das Problem, dass die dafür maximal noch verfürbare Quota nicht angezeigt werden kann, da das davon abhängt, mit welcher Domain (also in welchem Vertrag) das Postfach angelegt werden wird. Wir könnten aber nach Auswahl der Domain den maximal möglichen Quota-Wert per Ajax abholen und anzeigen (dann sieht man diesen nicht erst in der Fehlermeldung beim Speichern).

Wie würden Sie sich denn die Quota-Verwaltung wünschen?
Wären die Varianten mit dem "Mindest-Quota + Rest" sowie dem "Quota automatisch aufteilen" eine Hilfe?

Äh, sorry, hat etwas gebraucht bis ich das richtig reproduziert hatte. Auf einem der Testsysteme hier wird der Graph nämlich ganz normal angezeigt. Der Fehler tritt aber tatsächlich dann auf, wenn man auf den Graphen klick (zum "zoomen").
Hier liegt ein kleiner Javascript-Fehler vor, der mit dem nächsten Update (v1.5.0) behoben sein wird.

Die Graphen werden in den nächsten 2-3 Monaten übrigens noch etwas "aufgebohrt", um darin auch zoomen und navigieren zu können. Aber eins nach dem anderen.

Danke für den Hinweis & viele Grüße

-Klaus Keppler

Ja, ist bereits fix für die nächste größere Version (v1.6, etwa Ende Juni) eingeplant. Dort kann dann über die Maske zur Verwaltung von Postfix & Dovecot allerhand zusätzlicher Einstellungen vorgenommen werden. Dabei wird LiveConfig individuelle Spam/Virenfiltereinstellungen pro Postfach ermöglichen, sowie ein individuelles Training vom SpamAssassin.
Bis dahin kann man gerne auch selbst Spamassassin und/oder ClamAV in die Postfix-Konfiguration (/etc/postfix/master.cf) aufnehmen - LiveConfig wird diese Einstellungen bis dahin nicht überschreiben.

Viele Grüße

-Klaus Keppler

Das wäre prima, dann schaue ich mir das gerne mal eben im Debugger an. Die Kombination Debian6/openVZ wird eigentlich recht häufig genutzt, bislang sind (zumindest mir) da keine Fehler bekannt.
Zugangsdaten gerne per PM oder Mail an info@liveconfig.com - ich gebe dann kurz Bescheid sobald Sie das Passwort wieder zurück ändern können.

Das muss nicht unbedingt ein Fehler sein: das Popup-Fenster zeigt nur die Verzeichnisse an, die unterhalb von ~/htdocs/ existieren.
Falls der Browser tatsächlich in einer Lade-Animation hängen bleibt müssten wir wissen, ob denn der Webspace erfolgreich eingerichtet wurde (sprich: können Sie sich per FTP anmelden?) und welche Distribution Sie verwenden.

Viele Grüße

-Klaus Keppler

Zitat von mars-vie

Benötige ich für v1 überhaupt eine Lizenz?

"Kommt drauf an"™
Ab der kommenden Version (1.5) unterstützt LiveConfig auch die Verwaltung von Nameservern. Wenn Sie dann eine Zone auf dem Primary DNS (v3) via LiveConfig anlegen, muss der Secondary DNS (v1) ja auch darüber informiert werden, dass er für diese Zone Slave-Server ist.
Wird Server "v1" auch über LiveConfig verwaltet, so wird die Zone dort automatisch angelegt. Alternativ (also ohne LiveConfig-Lizenz) können Sie v1 trotzdem als "externen" Slave-DNS nutzen - müssen dann aber die Slave-Zonen manuell auf diesem Server hinzufügen bzw. entfernen. Der Zonentransfer selbst (AXFR/IXFR) findet so oder so natürlich automatisch statt.

Viele Grüße

-Klaus Keppler

suPHP kann ruhig aktiviert bleiben; das wird dann standardmäßig für PHP verwendet (also für Webspaces, für die man noch kein FastCGI aktiviert hat).

Im Grunde fehlt für die FastCGI-Konfiguration durch LiveConfig nicht mehr viel - die aktuell in Entwicklung befindliche Version liest bereits die Liste der verfügbaren Apache-Module aus, und stellt auf deren Basis dann eine Auswahl für die Ausführung von PHP-Scripts bereit.

Sie können bereits jetzt FastCGI für Webspaces einrichten, ohne dass LiveConfig da später in die Quere kommt. Voraussetzung ist lediglich, dass Sie das Apache-Modul fcgid (Debian-Package libapache2-mod-fcgid) installiert haben.

Hier die notwendigen Schritte (erfolgreich auf Debian 6 getestet). Den Vertragsnamen "web1" müssen Sie überall entsprechend anpassen:

Verzeichnis für FastCGI-Starter anlegen (wird später durch LiveConfig auch für php.ini's genutzt):

mkdir /var/www/web1/conf
chown web1:web1 /var/www/web1/conf
chmod 555 /var/www/web1/conf

FastCGI-Starter einrichten:

cat > /var/www/web1/conf/php-fcgi-starter << EOF
#!/bin/sh
export TMPDIR=/var/www/web1/tmp
exec /usr/bin/php5-cgi
EOF
chown web1:web1 /var/www/web1/conf/php-fcgi-starter
chmod 550 /var/www/web1/conf/php-fcgi-starter

.htaccess einrichten, damit FastCGI genutzt wird:

echo > /var/www/web1/.htaccess << EOF
<IfModule mod_fcgid.c>
 <Files ~ "\.php">
   Options +ExecCGI
 </Files>
 FCGIWrapper /var/www/web1/conf/php-fcgi-starter .php
 AddHandler fcgid-script .php
</IfModule>
EOF

Viele Grüße

-Klaus Keppler