Beiträge von kk

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).

Die Funktion gibt es schon seit einer ganzen Weile, offenbar ist das aber noch nicht im Handbuch dokumentiert

Sie müssen eine custom.lua anlegen und dort folgenden Befehl einbauen:

apache.CONFIGMODE='rewrite'

(siehe Kopf-Bereich in der apache.lua - dort ist das grob beschrieben)

Viele Grüße

-Klaus Keppler

Zitat

Niemals auf Terminangaben von kk verlassen.

Wo oder für wann genau war noch mal das WHMCS-Plugin versprochen? Ich weiß dass ein paar Nutzer ungeduldig darauf warten, wir hatten jedoch auch einige Kommunikationsprobleme mit den Jungs von WHMCS (längere Geschichte, inzwischen sind die wichtigsten Fragen geklärt).

Wenn wir ein Feature zu einem bestimmten Termin versprechen, dann wird das auch zu diesem geliefert (von minimalen Verzögerungen mal abgesehen).

Zitat von noez

Es geht hier aber auch teilweise um ganz simple einfache Mails, die im Oktober verschickt wurden, telefonisch als "offen Bestätigt wurden" und dann bis heute niemals beantwortet wurden.

Ich habe mir Ihre Mails eben noch mal hergeholt. Welche Probleme sind bei Ihnen noch ganz konkret offen?
Seit dem 20.10.2012 gab es keine einzelne weitere Mail von Ihnen - daher bin ich von diesem Posting und der plötzlichen Dringlichkeit doch etwas überrascht.

Zitat

Würde ich, wenn ich könnte wieder von LiveConfig weg ziehen? Ja.

Warum können Sie denn nicht von LiveConfig wegziehen? Die meisten Daten können problemlos über die SOAP-API ausgelesen werden, die Eingriffe in die Serverkonfiguration sind äußerst zurückhaltend und vollständig umkehrbar. Wir möchten, dass LiveConfig-Kunden aus Überzeugung bei uns bleiben, und nicht weil es "nicht anders geht" (das wäre eine ziemlich schlechte Basis).

Und: zu welcher Software möchten Sie denn wechseln, und aus welchem Grund? (rein interessenhalber).

Zitat

Was bringt mir die tollste Software, wenn mich der Chef anlügt? Nein Danke.

Das finde ich schon eine ziemlich dreiste und heftige Unterstellung.
Vielleicht darf ich Sie an den Support am 02.-04. Oktober erinnern, wo wir Sie mit aller Energie bei der Lösung eines Problems binnen kürzester Zeit und völlig unbürokratisch unterstützt haben.

Inwiefern habe ich Sie belogen?

Mit freundlichen Grüßen

-Klaus Keppler

Das Problem ist weniger die SQL-Abfrage als vielmehr die Tatsache, dass Verträge nicht direkt was mit den Kunden zu tun haben, die in der Liste angezeigt werden (und das Suchfeld bezieht sich eigentlich nur auf die in der Liste angezeigten Daten).

Was spricht gegen die Nutzung der Schnellsuche? Die ist genau für sowas gedacht...

Ach so... Geben Sie den Suchbegriff einfach links (unterhalb des Navigationsbereichs) in das Suchfeld ein - so wird auch der Vertrag gefunden.
Eine Suche nach Vertragsnamen in der Kundenliste ist bislang nicht vorgesehen, da ein Kunde ja auch mehrere Verträge haben kann.

Öh - nicht dass wir da nun aneinander vorbei reden: was im Bericht "Kunden-Verträge" in der ersten Spalte ("Vertrag") angezeigt wird, das kann auch in der Schnellsuche gesucht werden.
Falls das bei Ihnen nicht klappt, schicken Sie mir bitte eine genauere Beschreibung, wie bei Ihnen der betroffene Vertrag angelegt ist (also welchem Reseller der ggf. gehört, mit welchem Account Sie suchen, usw.), damit wir das hier evtl. reproduzieren können.

Was genau meinen Sie mit "Vertrags-ID"? Den Vertragsnamen?
Nach dem kann bereits gesucht werden.

Jepp, macht Sinn, wird kurzfristig umgesetzt (voraussichtlich morgen Vormittag).

Viele Grüße

-Klaus Keppler