Beiträge von WebService4U

  • Benutzerhandbuch Fehlanzeige??

    Liebes Keppler-Team,


    DAS ist ja wohl nicht euer Ernst! Wo bitte ist das Benutzerhandbuch hin?? Die Inhalte auf hostinghandbuch.de haben damit ja wohl nichts zu tun. Das ist bereits seit Wochen so. Wie kann man auf so eine Idee kommen, ein halbwegs aktuelles Handbuch - das ja mal da war - offline zu nehmen und dafür so einen Schrott anzubieten. Ich habe wirklich SO EINEN HALS grad. Das ist unprofessionell.

  • Vertrag zerschossen

    Sven_67 Solange, wie die Handbücher in einem derart erbärmlichen Zustand sind, kann man wohl schon erwarten, dass das Entwicklerteam fachliche Fragen in Bezug auf LiveConfig beantwortet - niemand erwartet dabei eine Grundlagenschulung. Dass das Kepplerteam nichts für Fehler der Kundensoftware kann, versteht sich wohl von selbst.


    Aber zurück zum Thema: ich stehe regelmässig vor demselben Problem. Vertrag versehentlich gelöscht und muss wiederhergestellt werden. Ein Backup habe ich, auch der LiveConfig-Datenbank. Doch wie bekomme ich nun die in der LiveConfig-Datenbanksicherung Daten dieses EINEN gelöschten Vertrages oder Kunden wieder in die Produktivdatenbank. Mein derzeitiges Vorgehen ist so: Sicherungsdatenbank in einem extra Liveconfig-Server einspielen, die Konfiguration dann händisch ansehen und alles manuell auf dem Produktionsserver anlegen. Mach Spaß, wenn der Kunde 500 Mailkonten hat. Wie geht das besser? Mir wäre da ja schon mit simplen SQL-Statements geholfen, die die Daten eines Vertrages aus der LC-Sicherung holen und in die ursprüngliche Datenbank wieder einfügen. Ich bin auch durchaus in der Lage, diese Statements selbst zu schreiben, nur habe ich kein Datenbankmodell. Kann so etwas nicht mal von LiveConfig bereit gestellt werden? Oder gleich eine Export-Import-Funktion für einzelne Verträge und oder Kunden direkt in LiveConfig? Vllt. über xml? Ich hatte erst kürzlich den Fall, einen einzelnen Vertrag auf einen eigenen Server bringen zu müssen.

  • mod_filter.c text/css in .htacess - Internal Server Error

    Debian Jessie
    LC 2.8.4-r5653


    Hallo liebe Wissende,


    folgendes Problem:


    DomainA mit PHP 7.1.33 liefert einen 500er und hat folgende .htaccess


    Ursache:

    Code
    [[core:alert] ...... /.htaccess: Invalid command
'text/css', perhaps misspelled or defined by a module not
included in the server configuration


    Kommentiert man 'text/css' aus, läuft die Seite.


    DomainB mit PHP 7.0.33 hat dieselbe .htaccess und erzeugt auch mit 'text/css' keinen 500er.


    Stellt man Domain B auf PHP 7.0.33 um, darf man auch 'text/css' benutzen.


    Ich nutze die PHP-Pakete von Keppler-IT.


    Kennt jemand die Ursache für dieses Verhalten?

  • Apache Restart schlägt fehl: zu langes Weiterleitungsziel

    Guten Morgen,


    Debian Jessi
    LC-Version: 2.8.4-r5653


    Aktuell lassen sich in LC Weiterleitungziele an der Domain einstellen, die zu lang sind und beim Apache restart des Webservers verhindern.


    Beispiel aus der /etc/apache2/sites-available/schuldiger_kundenvertrag.conf:
    ProxyPass "/" "http://education.ti.com/XXXXXXXX/en/ed-tech/XXXXXXXXXXF44D55B9BBF65E5A62E7F1/3136434A5B2D4E8C84E09DCB582FD59C/TI-XXXXXXXXXX-4.0.0.218.exe"
    ProxyPassReverse "/" "http://education.ti.com/XXXXXXXX/en/ed-tech/XXXXXXXXXXF44D55B9BBF65E5A62E7F1/3136434A5B2D4E8C84E09DCB582FD59C/TI-XXXXXXXXXX-4.0.0.218.exe"


    (Über Sinn oder Unsinn dieser Proxy-Weiterleitung bitte nicht diskutieren, das hat ein Kunde so eingestellt.)


    Fehlermeldung:
    Nov 20 06:20:35 serverxyz apache2[10159]: AH00526: Syntax error on line 50 of /etc/apache2/sites-enabled/schuldiger_kundenvertrag.conf:
    Nov 20 06:20:35 serverxyz apache2[10159]: ProxyPass worker name (http://education.ti.com/XXXXXX…BF65E5A62E7F1/3136434A5B2...) too long
    Nov 20 06:20:35 serverxyz apache2[10159]: Action 'configtest' failed.


    LC sollte hier vielleicht DRINGEND die Stringlänge überprüfen im GUI und so etwas abfangen. Das bedeutet ja immer, manuell in die /etc/apache2/sites-available/schuldiger_kundenvertrag.conf eingreifen um den Quatsch händisch auskommentieren zu müssen und den Indianer neu zu starten. Solange warten alle Kunden auf dem Server brav, denn nichts geht mehr.

  • Error 500 nach Umstellung auf FastCGI

    Ich muss das Thema auch noch einmal hochholen. In Vorbereitung eines Betriebssystemupgrades habe ich alle Verträge von suphp auf fastcgi umgestellt:


    Dazu habe ich in der LC-Datenbank die entsprechenden Werte in HOSTINGPLANS und HOSTINGCONTRACTS geändert:
    mysql -u<USERNAME> -p<PASSWORT> -B -N -e "UPDATE LIVECONFIG.HOSTINGPLANS SET HP_PHP=2;"
    mysql -u<USERNAME> -p<PASSWORT> -B -N -e "UPDATE LIVECONFIG.HOSTINGCONTRACTS SET HC_PHP=2;"
    mysql -u<USERNAME> -p<PASSWORT> -B -N -e "UPDATE LIVECONFIG.HOSTINGCONTRACTS SET HC_REFRESHCFG=1;"
    Danach mit einem beherzten service liveconfig restart die Änderungen durchschreiben lassen und die vhosts neu erstellt.


    Danach hatte ich genau das beschriebene Problem, dass der Indianer bei einigen Kunden plötzlich 500er feuerte mit Log-Einträgen:
    (104)connection reset by peer: mod_fcgid: error reading data from fastcgi server
    Premature end of script headers ... index.php


    Die Ursache lage letztlich darin, dass die php-ini-Verzeichnisse unter /var/www/<vertrag>/conf falsche Rechte hatten. Das aber auch nicht durchgehend: einige hatten 0777er Rechte, andere die korrekten 0555er Rechte. Dazu kam, dass bei einigen dieser Verzeichnisse das immutable flag gesetzt war, bei anderen nicht. Alles sehr verworren, zumal ich dort händisch nie eingegriffen habe, sondern LiveConfig immer ganz normal upgegraded habe. Die Lösung war letztlich das immutable flag durchgehend zu entfernen und die Rechte neu zu setzen:


    chattr -i /var/www/*/conf/php5
    chattr -i /var/www/*/conf/php53
    chattr -i /var/www/*/conf/php55
    chattr -i /var/www/*/conf/php56
    chattr -i /var/www/*/conf/php70
    chattr -i /var/www/*/conf/php71
    chattr -i /var/www/*/conf/php72
    chmod 0555 /var/www/*/conf/php53
    chmod 0555 /var/www/*/conf/php55
    chmod 0555 /var/www/*/conf/php56
    chmod 0555 /var/www/*/conf/php70
    chmod 0555 /var/www/*/conf/php71
    chmod 0555 /var/www/*/conf/php72
    service liveconfig restart

  • Installation Owncloud 10.0.9 schlägt fehl

    Bei der Installation von Owncloud 10.0.9 über den App-Installer erhält man eine Fehlermeldung:


    Error while downloading web application installer - please contact your administrator.


    LC-Version ist 2.6.3 auf Debian.


    Error while downloading web application installer - please contact your administrator.


    Es scheint, als ob die Datei
    /var/cache/liveconfig/installer/wai-owncloud-10.0.9-1.php
    fehlt.


    Erzeuge ich diese als Kopie von /var/cache/liveconfig/installer/wai-owncloud-10.0.7-1.php läuft die Installation durch.

  • Anmeldesperre abschalten?

    Deine Frage kann ich leider nicht beantworten, aber Du kannst Dich recht einfach selbst "entsperren": Lösche einfache die Einträge in der Tabelle IPBLOCK der LC-Datenbank. Dann funktioniert die Anmeldung wieder.

  • LC-Installation Debian 9.4 - Fehler /usr/bin/a2enmod: not found

    Guten Morgen,


    ich setze gerade einen neuen LC-Server auf.


    Zunächst

    Code
    apt-get update
apt-get upgrade


    Danach quota installiert und aktiviert.



    Dann

    Code
    wget -O - https://www.liveconfig.com/liveconfig.key | apt-key add -
cd /etc/apt/sources.list.d
wget http://repo.liveconfig.com/debian/liveconfig.list
aptitude update
aptitude install liveconfig-meta


    Die Installation bricht mit Fehlermeldung ab:


  • Fehler im Drupal-Installationsscript Version 7.59

    Aktuell ist das Drupal-Installationsscript unbrauchbar. Die Installation bricht ab:


    Drupal
    Name: xyz
    Verzeichnis: /apps/xyz
    Datenbank: xyz
    Status: Fehler: failed to open dir!
    Domains: xyz.xy


    Der Fehler läßt sich wie folgt beheben:


    In der Datei /var/cache/liveconfig/installer/wai-drupal-7.59-1.php alle "7.58" durch "7.59" ersetzen.

  • Löschung eines Wiederverkäufers hinterlässt Datenmüll in Tabelle USERS

    Version: LiveConfig 2.5.3-r4805


    Der Vertrag eines Wiederverkäufers, der Kunden und Verträge angelegt hatte, soll gelöscht werden.


    Das Löschen schlägt zunächst fehl, wenn noch Verträge, die der Wiederverkäufer selbst angelegt hatte, vorhanden sind - was schon mal EXTREM suboptimal ist. Löscht man die dann einzeln in einer Klick-Orgie, kann man den Wiederverkäufer-Vertrag und auch den Wiederverkäufer selbst löschen.


    Leider beiben jedoch die Kunden, die der Wiederverkäufer angelegt hat, als Datenmüll in der LiveConfig-Datenbank in der Tabelle USERS als Datenmüll liegen. Diese müssten auch mit gelöscht werden.


    Vorschlag: Beim Löschen eines Kunden, sollten generell nach entsprechendem "Sind sie sicher - Sie löschen damit folgende Verträge die folgende Domains enthalten" gelöscht werden:
    alle Verträge des Kunden (Mein Hosting)
    alle Kunden des Kunden
    alle Verträge von Kunden des Kunden

  • Postfix Whitelist smtpd_client_restrictions

    Ich muss Anton vom Ansatz her Recht geben - es mag tatsächlich LC-User geben, die solche Ausnahmen unkompliziert setzen möchten. In der Sache an sich bin ich jedoch - gerade auch bei T-Offline - knallhart: da würde ich niemals und unter keinen Umständen eine Ausnahme machen, denn das tun die Großen für uns "Kleine" auch nicht. Ganz im Gegenteil - die agieren oft so, als wären sie die Hüter von Recht und Ordnung des Internet. Und wenn ich da noch an die schöne Option "Liste der sicheren E-Mail-Server" im Speedport von T-Offline denke (hab ich quasi jede Woche Anfragen von Neukunden, die keine Mails versenden können, weil unsere Mailserver da natürlich nicht in der Liste stehen), dann bestärkt mich das nur in meiner Meinung. Sollen denen ihre Kunden mal schön Dampf machen, wenn Sie geblacklistet wurden. Wir müssen schließlich auch selbst handeln, wenn uns das passiert und die "Großen" kommen uns auch nicht entgegen. Auch das musste mal raus ;)