Beiträge von Febas

  • cron.php.sh verwendet alte php.ini

    Hier was ähnliches:


    Seit dem Upgrade auf Debian 9 (mit liveconfig-meta) ist /usr/bin/php ja in der Version 7.. (Wogegen /usr/bin/php-cgi weiterhin in der 5.6 geblieben ist)


    In der Datei /usr/lib/liveconfig/cron.php.sh wird dann folgender Befehl ausgeführt:


    Code
    elif [ -e '$cust/conf/php5/php.ini' ]; then
      cur=$(php -c "$cust/conf/php5/php.ini" -d "error_reporting='E_ALL & ~E_DEPRECATED'" -r 'print ini_get("session.gc_maxlifetime");')


    Wenn nun in der php.ini (PHP 5.6) z.B. der IonCube-Loader eingebunden ist, kommt es zu der Fehlermeldung:


    Code
    Failed loading ../ioncube_loader_lin_5.6.so:  ../ioncube_loader_lin_5.6.so: undefined symbol: zval_update_constant_inline_change


    Warum ist wohl klar..

  • App-Installer Magento

    Beim installieren von Magento durch den App-Installer erhält man folgende Fehlermeldung:


    Zitat

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


    Im LiveConfig-Log kommt:


    Zitat

    [2017/06/08 14:44:51.700719] [27014|27015] Downloading app installer from 'https://update.liveconfig.com/repo-v3.json'
    [2017/06/08 14:44:51.716318] [27014|27015] Requesting installer file '/wai-magento-1.9.3.2-1.php.gz'...
    [2017/06/08 14:44:51.719980] [27014|27015] => Error: Server status returned '404'


    Die Datei scheint nicht zu existieren. Problem bekannt? Danke.

  • LiveConfig v2.2.3 freigegeben

    Ich finde Plesk um einiges unübersichtlicher. Aber wie immer ist sowas Gewöhnungssache. Einer der mit Plesk bereits gearbeitet hat, wird LiveConfig unübersichtlich finden und andersrum aber genau so.


    Die Preview wird ja fast wöchentlich mit Updates versorgt. Die Liste ist echt lang geworden, ich gehe davon aus, dass die Stable mit dem neuen Updates bald veröffentlicht wird.

  • Keine Reaktion von der Buchhaltung

    Ticket: [LC#2017032134000021]


    Folgender Sachverhalt:


    Die Buchhaltung per Ticket am 7.2.17 über neue Bankverbindung zwecks Lastschrifteinzug benachrichtigt. Bis heute keine Reaktion, obwohl die Bestätigung über den Eingang der E-Mail vom Ticket-System gekommen ist.


    Am 20.3.17 erhalte ich eine E-Mail:


    Zitat

    leider konnten wir die Lastschrift vom 16.03.2017 über X EUR nicht einlösen. Gründe hierfür können eine mangelnde Deckung des Kontos, ein Widerspruch bei Ihrer Bank oder eine fehlerhafte Bankverbindung sein..


    Bitte überweisen Sie den offenen Betrag innerhalb der nächsten 7 Tage (bis 27.03.2017) auf folgendes Konto..


    Die von den Banken erhobenen Rücklastschriftgebühren in Höhe von 5.84 EUR wurden dem Rechnungsbetrag hinzugefügt..


    Die Buchhaltung über den Fehler mit der Bitte die Rücklastschriftgebühren entsprechend zu entfernen am 21.03.17 10:21 benachrichtigt... Wieder keine Reaktion?

  • LiveConfig bringt Apache zum Absturz

    Wir konnten das Problem bei unseren Servern auch oft erleben, wenn Kunden ein Let's Encrypt Zertifikat erstellt haben. Vermutlich haben hier die Kunden - während der Zertifizierung und Abholung des Zertifikats durch LC - im Tab "Details" entsprechend Buttons gedrückt und den generellen Ablauf gestört.


    Gut wäre es, wenn nach Anforderung des Let's Encrypt Zertifikats die Buttons im Tab "Details" deaktiviert wären.

  • Passwort-Geschütztes Verzeichnis & Fail2Ban --> keine Funktion

    Wir haben für die xmlrpc.php Attacken auch fail2ban im Einsatz. Lassen allerdings alle Kundenlogs durchsuchen:


    logpath = /var/www/*/logs/access.log


    Bisher kein Problem damit. Man sollte am besten alle Logs vor dem Start von f2b leeren, sonst läuft der Prozess mit 100% ..



    Kein Wunder.. Es muss auch "logs" heißen und nicht "log" :p

  • Multi-Server-Setup?

    Ist ja schon ziemlich interessant. Bringt es den viel, den MySQL-Server auf einen extra System auszulagern? Merkt man was von der erhöhten Latenz? Würde mich da über paar Details freuen. Vielen Dank.

  • keine apache.log und other_vhosts_access.log

    Schau mal ob in der apache.conf folgendes noch drin steht:


    Zitat

    # Include generic snippets of statements
    Include conf.d/


    # Include the virtual host configurations:
    Include sites-enabled/


    Das funktioniert so unter Debian 8 / Apache 2.4 nicht mehr. Stattdessen muss das stehen:


    Zitat

    # Include generic snippets of statements
    IncludeOptional conf-enabled/*.conf


    # Include the virtual host configurations:
    IncludeOptional sites-enabled/*.conf


    Oder einfach die apache2.conf.dpkg-dist in apache2.conf umbenennen. Die alte apache2.conf sichern..


    Der Tipp kommt von thomas16 ;)


    In der Anleitung zum Upgrade von Debian 7 auf Debian 8 (http://www.liveconfig.com/de/f…8-(Jessie)-mit-LiveConfig) steht:


    Zitat

    Immer wenn Sie während des Upgrades gefragt werden, ob Sie bestehende Konfigurationsdateien beibehalten oder durch eine neuere Version überschreiben wollen, dann entscheiden Sie sich für beibehalten ("N" - NICHT überschreiben).


    Das würde dazu führen, dass die access.log nicht mehr gefüllt wird, auch andere Probleme mit .htaccess können auftreten. Ein Hinweiß wäre vlt. angebracht.

  • Probleme nach Apache Update

    Nach dem ein System von wheezy auf jessie geupgradet wurde, gibt es nun mit Apache 2.4 ein Problem bei folgender Konstellation:


    Doman xy.de mit dem Ziel: /htdocs/ordnera/ordnerb


    Wenn sich nun im Ordner ordnera eine .htaccess befindet, kommt es zu einem 500 Error mit folgender Meldung: [core:alert] [pid 29220] [client 180.76.xxx /var/www/xxx/htdocs/ordnera/.htaccess: <IfModule not allowed here

  • Upgrade von Debian 7 (Wheezy) auf Debian 8 (Jessie) mit LiveConfig

    Ich bekomme auch ein Problem ab Schritt 6:



    Ist es nötig, hier zuzustimmen?


    Wenn ich auf nein gehe, kommt folgendes:


    Zitat

    Accept this solution? [Y/n/q/?] n
    The following actions will resolve these dependencies:


    Install the following packages:
    1) libperl4-corelibs-perl [0.003-1 (stable)]


    EDIT:


    Lösung: Den Vorschlag nicht akzeptieren (q). Dann manuell suphp löschen. Und aptitude upgrade ausführen. Danach geht es weiter :)

  • Einzel-System -> Multi-Server

    Noch eine Frage zur Anleitung:


    Zitat

    Kopieren/rsyncen Sie alle Daten auf die neuen Server (/var/lib/mysql, /var/mail, /etc/dovecot).


    Sicher, dass dies ausreicht? Was ist mit dem postfix-Ordner?