Beiträge von kk

In der aktuellen Preview ist das bereits enthalten (siehe https://www.liveconfig.com/dev/issues/69) - wurde am 13.12. umgesetzt, offenbar aber nicht ins Changelog aufgenommen. Damit sollten sich die Limits entsprechend steuern lassen.

Viele Grüße

-Klaus Keppler

Sie sind nicht der erste, der darüber stolpert - wir werden das nun erst mal besser dokumentieren und mal schauen, wiefern sich die Usability hier insgesamt verbessern lässt.

Viele Grüße

-Klaus Keppler

Hmm, das ist merkwürdig. Finden sich auffällige Meldungen in /var/log/liveconfig/liveconfig.log ?

Wenn Sie in dem Kunden-Account eine Subdomain anklicken - haben Sie da prinzipiell die Möglichkeit, HTTPS zu konfigurieren (also erscheint schlicht nur kein Zertifikat in der Dropdown-Liste)?

Zitat

dies ist schon im Paket "libapache2-mod-php5" enthalten und wird meist gleich mit php5 installiert

Exakt.
Im Zweifelsfall erstellen Sie einfach mal eine phpinfo()-Datei - dann sehen Sie ja gleich auf einen Blick, welche Extensions bereits verfügbar sind.

Viele Grüße

-Klaus Keppler

Welche LiveConfig-Version und welche Linux-Distribution setzen Sie aktuell ein?
Wenn ich das richtig verstehe wurde also der Kunden-Webspace (/var/www/user1) gelöscht, aber die Apache-Konfiguration (/etc/apache2/sites-available/user1.conf) nicht?

Viele Grüße

-Klaus Keppler

Nein, bei Aliasen sind nur bis zu 10 Einträge möglich (steht dann auch im Handbuch. ;))

Es können maximal 25 Weiterleitungs-Ziele angegeben werden.
Ich habe das eben ins Handbuch mit aufgenommen (Kapitel 4.10, "Erste Schritte" -> "E-Mail-Postfächer"), ist also mit dem nächsten Update auch dokumentiert.

Viele Grüße

-Klaus Keppler

Schicken Sie uns bitte kurz an support@liveconfig.com die "echten" E-Mail-Adressen sowie die IP-Adresse des LiveConfig-Servers, dann schauen wir mal ob die DNS-Einträge etc. alle passen und senden eine eigene Testmail.
Da eine lokale Zustellung offenbar klappt, tippe ich derzeit auf eine fehlerhafte oder noch falsch gecachte DNS-Einstellung.

Viele Grüße

-Klaus Keppler

Hallo,

Zitat von KLMMedien

Jetzt habe ich noch zusätzlich PHPMyAdmin manuell installiert (in var/www/). Der Ordner lautet phpmyadmin.

Wenn ich jetzt die Adresse wh01.xyz.de/phpmyadmin aufrufe, bekomme ich den Hinweis, dass die Domain wh01.xyz.de nicht existiert.

Ja, das ist klar - die Domain "wh01.xyz.de" ist ja noch keinem Vertrag zugeordnet worden, wenn ich das richtig verstanden habe.
In diesem Fall wird eben die "nicht verfügbar"-Fehlermeldung angezeigt - ohne LiveConfig würden in diesem Fall zwar normalerweise die Inhalte aus /var/www/ abgerufen werden, was allerdings im Shared-Hosting-Betrieb eher problematisch ist.

Das als Debian-Package bereitgestellte phpMyAdmin läuft übrigens nicht mit suPHP/FastCGI und ist daher in den meisten Fällen auf einem mit LiveConfig verwalteten Server unbrauchbar.
Die einfachste Lösung wäre, wenn Sie z.B. eine (Sub-)Domain "phpmyadmin.xyz.de" in einem Hostingvertrag einrichten und dort über den Application Installer dann phpMyAdmin installieren.
Alternativ fügen Sie die Domain "wh01.xyz.de" einfach einem Hostingvertrag hinzu (zB. "web1") und installieren phpMyAdmin dann innerhalb dieses Vertrags (/var/www/web1/htdocs/phpMyAdmin).

Zitat

Dann noch eine allgemeine Frage: Kann man die Defaultseiten abändern?

Ja; diese liegt unter /usr/share/liveconfig/html/ (not-available.(s)html und coming-soon.html); diese können aber bei LiveConfig-Updates ersetzt werden - erzeugen Sie daher noch eine Kopie, wenn Sie diese bearbeiten sollten. Mit einem der nächsten Updates wird es eine Möglichkeit geben, die Dateien "update-sicher" abzuändern.

Viele Grüße

-Klaus Keppler

Ja, mit OpenSUSE 12.2 haben wir das noch nicht getestet; ich schätze, dass dort noch eine kleine Anpassung am einen oder anderen Lua-Script notwendig sein wird. Wir kümmern uns gleich mal darum, Update wird kurzfristig bereitgestellt.

Natürlich kann man da was machen

Prinzipiell ist es jedenfalls schon mal sehr merkwürdig/verdächtig/unsauber, in einem Bilder-Verzeichnis ("images") CGI-Scripte ausführen zu wollen - CGIs gehören eigentlich ausnahmslos ins /cgi-bin/-Verzeichnis.
Unabhängig davon erlaubt die von LiveConfig erzeugte Konfiguration derzeit nicht die Verwendung der ExecCGI-Option, selbst wenn ein Vertrag CGI-Berechtigung besitzt.
Mit dem nächsten Update (ab r2092) wird das aber künftig berücksichtigt (d.h. Verträge mit CGI-Recht können auch "Options ExecCGI" verwenden).
Um das kurzfristig zu patchen, ersetzen Sie bitte die Datei /usr/lib/liveconfig/lua/apache.lua durch http://download.liveconfig.com/tmp/apache.lua, starten Sie dann LiveConfig neu und lassen die vHost-Konfiguration der betreffenden Domain neu erstellen (klicken Sie in LiveConfig unter "Domains" einfach irgendeine Subdomain an und dort in dem Popup-Fenster direkt wieder auf "speichern").
In der Konfigurationsdatei unter /etc/apache2/sites-available/[...].conf sollte dann bei "AllowOverride" am Ende auch "ExecCGI" mit aufgeführt sein.

Viele Grüße

Klaus Keppler

Es gibt ein neues Tool namens "lcdbdump" - siehe http://www.liveconfig.com/de/f…=3079&viewfull=1#post3079

Hallo,

wie immer - der Teufel steckt(e) im Detail. Der von SQLite erzeugte Dump enthielt keine Spaltennamen in den INSERT-Befehlen, wodurch bei einem Import in MySQL zwangsweise alle Spalten in der selben "Reihenfolge" vorliegen müssten. Dies ist aber - je nach Update-Verlauf einer LiveConfig-Installation - nicht immer der Fall.

Lange Rede, kurzer Sinn: es gibt ab sofort ein neues Tool namens lcdbdump, welches einen MySQL-kompatiblen Dump einer SQLite-Datenbank erzeugt. Die Schritte für eine Migration auf MySQL sehen somit wie folgt aus:

• erzeugen Sie eine neue, leere MySQL-Datenbank samt Benutzer und Passwort (siehe Handbuch)
• importieren Sie die Standard-MySQL-Datenbank (ebenfalls siehe Handbuch)
• laden Sie das lcdbdump-Tool herunter und erzeugen einen Dump:
  
  
  Code

  wget http://download.liveconfig.com/tools/lcdbdump
  ./lcdbdump /var/lib/liveconfig/liveconfig.db dump.sql

  
  

• importieren Sie den Dump in die MySQL-Datenbank

In unseren ersten Tests hier hatte alles geklappt, wir sind aber für weitere Rückmeldungen dankbar. Wenn alles passt, wird die entsprechende Anleitung kurzfristig aktualisiert.

Viele Grüße

-Klaus Keppler

Hallo Herr Groh,

Zitat

Kann ich nun problemlos den LiveConfig-Server neu installieren, die Lizenzdaten einspielen und anschließend die LiveConfig-Datenbank gegen die aus der Sicherung ersetzen, die Daten aus /var/www zurückspielen, LiveConfig starten und gut ist?

Wenn ich das richtig verstanden habe, wurden die Daten aus /etc/ (zB. /etc/apache2, /etc/proftpd, etc.) nicht aus dem Backup wiederhergestellt?
In diesem Fall gehen Sie bitte wie folgt vor:

• installieren Sie LiveConfig und aktivieren Sie die Lizenz
• gehen Sie dann auf "Serververwaltung" und aktivieren auf dem Server der Reihe nach die Verwaltung der gewünschten Dienste (Apache, FTP-, Mailserver, ...) - somit werden deren Konfigurationsdateien durch LiveConfig ersetzt/verwaltet
• stoppen Sie danach LiveConfig, ersetzen die Datenbank durch die aus dem Backup und starten LiveConfig anschließend neu
• öffnen Sie dann wieder LiveConfig, gehen auf "Serververwaltung" und klicken bei allen Diensten irgendwo auf "ändern" (zB. Apache: default-Gruppe bearbeiten, IP entfernen, speichern, IP wieder hinzufügen, wieder speichern) -> somit werden die Konfigurationsdateien jeweils neu erzeugt.
• um die vHost-Konfigurationen neu zu erzeugen, öffnen Sie jeweils irgendeine Subdomain jedes Vertrags und klicken dort einfach auch wieder auf "speichern".

Grundsätzlich sollte somit ein kompletter Restore möglich sein.
Berücksichtigen Sie künftig für Backups bitte auch die Verzeichnisse /etc/ und /var/lib/liveconfig.
Auf unserer Ideenliste steht auch schon der Wunsch nach einem "Desaster-Recovery-Modus", bei dem alle Konfigurationsdateien komplett neu erzeugt werden - das ist aufgrund der LiveConfig-Architektur nicht ganz trivial, aber wird definitiv irgendwann kommen.

Viele Grüße & viel Erfolg

Klaus Keppler

In der aktuellen Preview (1.6.1-r2091) liefer die Funktion HostingSubscriptionGet() neuerdings auch noch ein Array mit den einem Hostingvertrag zugeordneten Domains zurück (ist noch nicht in der Doku erfasst, einfach mal mit print_r() das SOAP-Ergebnis ausgeben lassen um die Details zu sehen); sieht etwa so aus:

<HostingSubscriptionGetResponse>
[...]
<domains>
  <HostingSubscriptionDomain>
    <name>example.org</name>
  </HostingSubscriptionDomain>
  <HostingSubscriptionDomain>
    <name>example.net</name>
  </HostingSubscriptionDomain>
</domains>
</HostingSubscriptionGetResponse>

Im nächsten Schritt soll innerhalb der Domain-Struktur auch noch ein Array mit den Subdomains und deren Konfiguration zurückgegeben werden, so dass man quasi die komplette Konfiguration eines Webspace auch per SOAP abrufen kann. Dabei wäre denkbar, auch die konfigurierten IPs der Subdomains mit auszugeben (wir möchten bloß vermeiden dass das SOAP-Ergebnis zu komplex wird).

So eine Art "Events" gibt es derzeit noch nicht; die Idee steht auf der Wunschliste, wird aber wohl noch etwas dauern. Die Lua-API selbst bekommt auch nicht direkt etwas davon mit, wenn ein Kunde eine neue Subdomain anlegt. Die "ordentliche" Lösung sieht vor, dass LiveConfig selbst einen primären DNS verwaltet, in dem es dann alle Resource-Records korrekt verwaltet. Die DNS des Domainanbieters können dann meist als Secondary DNS genutzt werden.
DNS-Verwaltung ist hier aktiv in Arbeit, alle weiteren Details dann in Kürze.

Viele Grüße

-Klaus Keppler

Die Installation von MediaWiki dauert ziemlich lange (großer Download von vergleichsweise "langsamen" Server, Entpacken des großen Archivs, ...) - unserer Erfahrung nach wird daher meist das PHP-Script vorzeitig beendet, weil die max_execution_time aus der Standard-PHP.INI überschritten wird.
Wir arbeiten bereits an einer Lösung (sieht dann so aus, dass diverse Limits wie zB. max_execution_time und memory_limit explizit auf höhere Werte eingestellt werden, wenn das Installations-Script aufgerufen wird).
Das Löschen nicht erfolgreich installierter Anwendungen ist hier in einer Testumgebung schon behoben, wir werden diese Funktion in den nächsten Tagen in die Preview-Version übernehmen (anders gesagt: voraussichtlich am Montag gibt es ein Update, mit dem das dann möglich sein sollte)

Viele Grüße

-Klaus Keppler

Das Joomla-Team hatte offenbar ein Update der deutschen Version (2.5.8-2) herausgebracht und dabei den Download-Link der "alten" Version gelöscht. Daher konnte der Application-Installer die benötigte Datei gar nicht erst herunterladen.
Wir haben den Installer entsprechend aktualisiert; nach einem LiveConfig-Neustart oder nach max. 24 Stunden ist das neue App-Repository verfügbar.

Viele Grüße

-Klaus Keppler

Ebenfalls ein fröhliches und gesundes Neues Jahr!

In der Tat ist "nur" Urlaubszeit - nacheinander waren/sind alle Leute von uns im wohlverdienten Urlaub, ab Montag (07.01.) ist wieder Normalbetrieb.
Ich selbst bin aus familiären Gründen (es gab Nachwuchs :)) noch einige Zeit tagsüber nur eingeschränkt erreichbar, auf die Entwicklung hat das aber keine Auswirkungen.

Das nächste Update (Preview) mit den neuesten Funktionen ist bereits für Ende kommender Woche eingeplant (u.a. Warn-Mails bei Erreichen der Postfach-Quota, viele Detailverbesserungen und einige Bugfixes) - es geht also stetig voran.

Viele Grüße & einen tollen Start ins neue Jahr!

-Klaus Keppler

Zitat von dicker

Ausgabe auf dem Master mit repquota -ag
[...]

Bitte führen Sie "repquota -ag" auf dem Slave (also dem virtuellen Container) aus, nicht auf dem Master (dort spielt das keine Rolle).