Beiträge von kk

  • Aktualisierung des GPG-Schlüssels (Paketsignatur)

    Das Stable-Repo ist nun auch wieder korrekt signiert.


    Vorschlag:
    Um das Key-Rollout bei größeren Installationen zu vereinfachen, könnten wir vorübergehend die Signatur der Repositories entfernen und mit dem nächsten LiveConfig-Update gleichzeitig den Key aktualisieren lassen.
    Kommentare/Meinungen dazu?

  • Aktualisierung des GPG-Schlüssels (Paketsignatur)

    Für alle, die LiveConfig über eines unserer Repositories installiert haben:


    Der GPG-Schlüssel, der für die Signatur der Pakete und Repositories verwendet wird (pkgadmin@liveconfig.com) wurde ausgetauscht, da der alte Schlüssel zum 06.11.2014 abgelaufen ist.
    Key-ID ALT: 649BE239
    Key-ID NEU: 08708961


    Um den aktualisierten Key zu importieren, ist folgender Befehl notwendig:

    Code
    # Debian:
wget -O - https://www.liveconfig.com/liveconfig.key | apt-key add -


# CentOS/OpenSUSE:
rpm --import https://www.liveconfig.com/liveconfig.key


    Das sind die selben Befehle, die auch auf der Download-Seite bei den Installationshinweisen jeweils angegeben sind.


    Wer den Schlüssel nicht aktualisiert, erhält sonst z.B. unter Debian die folgende Fehlermeldung beim nächsten "aptitude update":

    Zitat

    W: A error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://repo.liveconfig.com main Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 1059DFB908708961


    Wir planen, für den LiveConfig-Key künftig ein eigenes Paket bereitzustellen, welches dann (vor dem Ablauf des Schlüssels ;)) automatisch mit aktualisiert werden kann.


    Viele Grüße


    -Klaus Keppler

  • Webserver Apache + NGINX verbuggt

    Der bisherige Key (649BE239) wurde nun ersetzt (neu: 08708961) und zusätzlich mit dem alten Key unterzeichnet.
    Sorry für die Unannehmlichkeiten - vor drei Jahren hatten wir das Key-Rollover noch nicht wirklich auf dem Radar. :(
    Ein eigenes Key-Paket ("liveconfig-key") dürfte vermutlich wirklich die einfachste Lösung sein.


    Viele Grüße


    -Klaus Keppler

  • Webserver Apache + NGINX verbuggt

    Zitat von hEAVEN

    Komisch ist, dass nach einer Änderung einer Domain oder sonstiges, die ports.conf wieder neu erstellt wird ..


    Das wird sie aber sicher nicht durch LiveConfig.
    LC verschiebt die ports.conf in ports.conf.lcbak, wenn die Verwaltung vom Apache aktiviert wird. Danach wird diese Datei nie wieder durch LC angefasst.


    Im übrigen sieht die durch LiveConfig erstellte ports.conf dann so aus:

  • Webserver Apache + NGINX verbuggt

    Die ports.conf die Sie da zeigen ist nicht von LiveConfig. Für mich sieht das so aus, als ob Apache nach der Aktivierung im LiveConfig noch mal neu installiert wurde. Und das hat bestimmt nicht LiveConfig gemacht...

  • Webserver Apache + NGINX verbuggt

    Zitat von hEAVEN

    Thema Apache:


    Die Config werden falsch erstellt, womit mehrer Listen und Namevirtualhost einträge gemacht werden (ports.conf, 000-default)


    Welche Distribution genau setzen Sie ein? Zumindest mit allen offiziell unterstützten Distributionen (Debian 5-7, CentOS 5-7, Ubuntu 11-14, OpenSUSE 12-13, Gentoo) sind mir da keine Fehler bekannt.


    Zitat

    Ich weiß, dass die Entwickler auch mal Reallife haben


    Unser "Reallife" ist LiveConfig. ;)


    Viele Grüße


    -Klaus Keppler

  • Kunde als Reseller kann angelegte Kunden nicht Löschen!

    Vermutlich auch hier das Problem, dass der Vertrag des Kunden nicht vollständig gelöscht wurde.
    Welche Distribution setzen Sie denn ein?


    Zur Lösung: führen Sie folgenden SQL-Befehl in der LiveConfig-Datenbank aus (wenn SQLite, dann mit dem Tool "sqlite3 /var/lib/liveconfig/liveconfig.db")

    SQL
    UPDATE HOSTINGCONTRACTS SET HC_DELETED=0 WHERE HC_DELETED=1;


    (mit ".quit" kann man sqlite3 dann wieder beenden)


    Danach sollte der Vertrag wieder im LiveConfig auftauchen - dort bitte erneut löschen. Falls Probleme auftreten, sollte es Log-Meldungen in /var/log/liveconfig/liveconfig.log geben.


    Viele Grüße


    -Klaus Keppler

  • Convertierung von MySQL zu DB

    Zitat von hchristo

    hab ma ne Frage gibt es ne Funktionierende Methode eine MySQL Database zu DB zu Convertieren?


    Was soll eine "DB" sein? Ich schätze Sie möchten wissen, ob man eine MySQL-Datenbank in eine SQLite-Datenbank konvertieren kann?


    Zitat

    hab seit einiger zeit Liveconfig wie alles andere über MySQL am laufen mit der wunderbar Funktionierenden Anleitung im Liveconfig Forum. Jetzt da ich von meinem Altem Server zu einem neuem Wechseln will brauche ich dringend (auch wegen backup gründen) eine Funktionierende "liveconfig.db"


    Warum brauchen Sie da eine liveconfig.db? Wenn Sie LiveConfig umziehen möchten, machen Sie auf dem alten Server einen mysqldump der LiveConfig-Datenbank und spielen diesen auf dem neuen Server einfach ein...
    Der Zwischenschritt über SQLite ist völlig überflüssig.

  • Charset Problem

    Welche MySQL-Version (exakt) setzen Sie ein?


    LiveConfig nimmt überhaupt keine Zeichensatzkonvertierung vor, sondern gibt 1:1 die Daten aus, die es von MySQL bekommt. Der Fehler wird also entweder im MySQL-Client liegen der in LC enthalten ist (/usr/lib/liveconfig/libmysqlclient_r.so), oder im MySQL-Server.
    Wenn innerhalb der selben Seite die Zeichen einmal falsch und einmal richtig codiert sind, kann es auch kein Problem von falschen HTML-Headern (Content-Type... charset=...) sein.



    • Tauchen in /var/log/liveconfig/liveconfig.log irgendwelche Meldungen auf?
    • Oder im MySQL-Log?
    • Sind irgendwelche Partitionen vielleicht voll gelaufen?
    • MySQL mal neu gestartet?

  • falsche Anzeige PHP Version

    Zitat von dicker

    Failed loading /usr/local/ioncube/ZendGuardLoader.so: /usr/local/ioncube/ZendGu ardLoader.so: cannot open shared object file: No such file or directory


    Sieht danach aus als ob der ZendGuardLoader geladen werden soll, das aber nicht klappt. Vermutlich deshalb, weil für jede PHP-Version ein separater Loader notwendig ist...

  • CentOS 6.5 und weitere PHP Versionen

    Zitat von ManDal
    Code
    [Wed Oct 15 09:45:18 2014] [warn] [client 10.40.10.1] (104)Connection reset by peer: mod_fcgid: error reading data from FastCGI server
[Wed Oct 15 09:45:18 2014] [error] [client 10.40.10.1] Premature end of script headers: test.php


    Diese Meldung deutet darauf hin, dass der PHP-Interpreter an sich nicht gestartet werden kann. Die Fehlermöglichkeiten sind fast unbegrenzt :(
    Am besten aktivieren Sie im betroffenen Webspace erst mal das Apache-Errorlog (LiveConfig: "Hosting" -> "Webspace" -> Fehlerprotokoll aktivieren), sowie in den php.ini-Einstellungen log_errors=ON (Hosting -> Webspace -> PHP Einstellungen bearbeiten). Danach sollten in den entsprechenden Logs hoffentlich mehr Hinweise auftauchen.
    Interessant wäre auch die Ausgabe von "/usr/sbin/liveconfig --diag" (der Abschnitt zu Apache & PHP).


    In unserer CentOS-Testumgebung hier funktioniert das prinzipiell einwandfrei (allerdings mit selbst compiliertem PHP).


    Viele Grüße


    -Klaus Keppler

  • Supportanfragen via PN

    Immer wieder erhalten wir Supportanfragen im Forum als private Nachricht (PN). Teilweise ganz unverblümt gleich mit root-Zugangsdaten zum Server.


    An dieser Stelle möchte ich also noch mal klar stellen: Support-Anfragen per PN werden nicht bearbeitet. root-Zugangsdaten haben in einem Forum ohnehin nichts verloren.
    Wir helfen gerne weiter, aber:


    Die Gründe sollten klar sein: zum einen gilt eine Forum-Software grundsätzlich als unsicher - alle darin gespeicherten Daten könnten früher oder später durch irgendeine Sicherheitslücke ausgenutzt werden. Zum anderen ist eine strukturierte Kommunikation mit mehreren Support-Mitarbeitern nur über's Ticket-System möglich, nicht aber über persönliche Foren-Accounts.


    Viele Grüße


    -Klaus Keppler