Beiträge von clickpress

    Wie wäre es, wenn LiveConfig ein Umschalten der CLI-PHP-Version per GUI ermöglicht?
    Dazu würden wir dann /usr/bin/php durch ein (äußerst schlankes) Wrapper-Programm ersetzen, welches dann an den für den jeweiligen Vertrag/Benutzer ausgewählten Interpreter übergibt. :D


    Eine andere (sauberere) Lösung sehe ich gerade nicht.


    Vor allem wäre das zukunftssicher, da immer mehr Systeme auf Symfony/Composer setzen. U.a Drupal, Shopware (in naher Zukunft) und Contao


    Außerdem ist damit LC vielen anderen voraus. Plesk z.B. schlägt auch nur Aliase vor, was für einen server-unbedarften Reseller quasi garnicht zu bewerkstelligen ist.
    https://support.plesk.com/hc/e…I-version-for-subscriber-

    Code
    echo "alias php=/opt/php71/bin/php" >> ~/.bashrc



    Gerade nochmal genauso auf einem anderen Server, der global noch php7.0 als cli und beim Benutzer jetzt php7.1 hat, getestet.


    php -v ergibt:

    Code
    benutzerxyz@srvnet:~/htdocs/contao4$ php -v
    PHP 7.1.14 (cli) (built: Feb  1 2018 16:53:19) ( NTS )
    Copyright (c) 1997-2018 The PHP Group
    Zend Engine v3.1.0, Copyright (c) 1998-2018 Zend Technologies
        with Zend OPcache v7.1.14, Copyright (c) 1999-2018, by Zend Technologies


    beim composer update passiert das:

    Code
    benutzerxyz@srvnet:~/htdocs/contao4$ composer update
    Loading composer repositories with package information
    Updating dependencies (including require-dev)
    Your requirements could not be resolved to an installable set of packages.
    
    
      Problem 1
        - This package requires php ^7.1 but your PHP version (7.0.27) does not satisfy that requirement.
      Problem 2
        - contao/manager-bundle 4.5.4 requires php ^7.1 -> your PHP version (7.0.27) does not satisfy that requirement.


    Das war der Grund, warum ich die CLI global umgestellt habe.


    Wer also manuell die /usr/bin/php umbiegt, wird zwangsläufig auch das cron.php.sh-Script anpassen oder ersetzen müssen.


    Danke für die ausführliche Antwort. Das bestätigt ja mein Handeln. Bleibt die cron.php.sh bei Minor-Updates von LC unberührt?


    Ich musste übrigens die php-cli umbiegen, weil ich sehr viele Symfony-Installationen habe und viele Pakete mindestens 7.1 erfordern (die werden über Composer per CLI installiert/geupdatet). Klar, ich kann jedesmal /opt/php71/... schreiben, aber das ist auf Dauer lästig.

    Allerdings scheint der Patch das obige Problem nicht (korrekt) zu lösen.


    Weil ich den Part mit PHP 5 komplett außer acht gelassen habe.


    Du hast ioncube scheinbar nicht über die PHP-Einstellungen in LC eingebunden, oder? Bzw. mit dem Hinweis, dass /usr/local/ioncube/ioncube_loader_lin_5.6.so nur für PHP >= 5.6 und <7 gilt.


    Bei mir sind drei ioncube Versionen eingebunden, jeweils passend zur PHP-Version.

    Naja, aber scheinbar werden die in Liveconfig angelegten Cronjobs über cron.php.sh aufgerufen, oder nicht? Jedenfalls hatte ich, nachdem die PHP-CLI umgestellt wurde, diese E-Mail in der Mailbox:
    https://imgur.com/a/LTq9J
    Kunde hat php7.1. Das Script lädt aber die ini der 7.0


    Ich habe dann in cronjob.php.sh ein paar Variablen ausgeben lassen, um sicherzugehen, was da passiert. Und dadurch bin ich auf dieses Problem gestoßen.


    Edit: würde im Cronjob ein absoluter PHP-Pfad, statt einfach nur php, bzw. /usr/bin/php angegeben, dann würde er ja trotzdem die php.ini der 7.0 laden

    Ich hab die cron.php.sh mal angepasst. So würde die immer die richtige php.ini laden. Es sei denn, wir bekommen PHP 8. Aber dafür sollte das Script komplett überarbeitet werden, und ggf. die PHP-Conf-Ordner immer mit zweistelligen Versionsnummer angegeben werden: also 70, statt 7.


    Zunächst habe ich die Suche anpasst:

    Code
    # detect version of default PHP-CLI binary:
      PHPVERSION=`php -r 'echo phpversion();' | sed -e 's/\.//g' | cut -c1-2`


    ergibt z.b. 56, 70, 71 etc.
    Den Ordner /var/www/kunde/conf/php70/ gibt es nicht, der heißt schlicht php7. Von daher muss das gefiltert werden:

    Code
    if [ '$PHPVERSION' = '70' ]; then
        PHPVERSION="7"
      fi


    Für die Abfrage, ob es sich um 5 oder 7 handelt, brauchen wir noch die Major-Version:

    Code
    PHPMAJOR=`echo $PHPVERSION | cut -c1`


    Dann könnte die ini dynamischer als bisher geladen werden:

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


    Den PHP 5-Block hab ich absichtlich unangetastet gelassen. Da ist scheinbar eine Rückwärtskompatibilität eingebaut worden.


    Das ganze Script sieht so bei mir aus:


    Die Cronjobs der Kunden/Nutzer müssen schon auch die richtige CLI-PHP-Version verwenden. LiveConfig ändert den Cron-Befehl nicht ab.


    Das ist das Problem: die "richtige" CLI-PHP-Version ist entweder 5.6 oder 7.0. Weil nur eine der beiden dazugehörigen INIs geladen wird.


    Nochmal zu Verdeutlichung. Das Problem entsteht, wenn man seine Standard-PHP-CLI ändert.
    Spätestens mit der nächsten Debian-Version, in der dann PHP 7.2 als CLI Standard sein wird, muss die cron.php.sh angepasst werden. Ich hab es jetzt einfach hard da reingecodet (was vermutlich mit dem nächsten LC-Update wieder hinfällig ist).

    Wie bitte? Bitte genauer beschreiben, was wo wie eingebunden wird, danke!


    Also: als CLI ist z.B PHP 7.1 oder 7.2 eingebunden.
    cron.php.sh interessiert es aber nicht, ob standardmäßig 7.0, 7.1 oder was auch immer läuft. Es wird nur die Major-Version abgefragt, siehe

    Code
    PHPVERSION=`php -r 'echo phpversion();' | cut -d '.' -f 1`


    und dementsprechend auch nur die php.ini der 7.0 geladen:

    Code
    php -c "$cust/conf/php7/php.ini" ...


    hast du standardmäßig 7.1 als CLI laufen, dann wird also trotzdem "$cust/conf/php7/php.ini" und nicht "$cust/conf/php71/php.ini" beim Durchlaufen der Cronjobs eingebunden. Und das führt in Einzelfällen zu Fehlern -> z.B wenn man Ioncube über das Kundeninterface eingebunden hat.

    Ich muss mich auch mal hier reinhängen. Warum wird in dem Cronscript nicht zwischen PHP 7.0 und 7.1 etc. unterschieden? Es wird grundsätzlich die 7.0 php.ini geladen.
    Das führt zu Fehlern, sobald man 7.1 als CLI eingebunden hat -> gerade mit ioncube.

    Vielen Dank :) HTTP/2 klappt super!
    zur Info: ich habe letzte Woche einen neuen Testserver (Debian Stretch) mit der liveconfig-meta aufgebaut. Ich hatte Probleme mit lcsam und lcpolicyd.


    Code
    Sep 28 18:20:28 srvnet postfix/smtps/smtpd[5505]: warning: connect to Milter service unix:/var/run/lcsam.sock: No such file or direc
    tory
    Sep 28 18:20:28 srvnet postfix/smtps/smtpd[5505]: warning: connect to private/lcpolicyd: No such file or directory


    Das Problem wurde folgendermaßen behoben:

    Code
    systemctl unmask lcpolicyd
    systemctl enable lcpolicyd
    systemctl restart lcpolicyd
    
    
    systemctl unmask lcsam
    systemctl enable lcsam
    systemctl restart lcsam


    Jedenfalls sollte ab v2.3.0-r4510 bei der Kommunkation mit Let's Encrypt nun kein Fehler mehr auftreten.


    Im LC die Zertifikatsanfrage gelöscht und neuangelegt -> klappt! Super, danke.


    Jetzt habe ich noch eine kleine Fehlermeldung:


    Das wundert mich, da ich ein bis Ende Mai gültiges Zertifikat für diese Domain habe. Gibt es irgendwo eine Datei, wo eine ältere Anfrage noch festhängt? Ich hab schon bei meinen Kundenverträgen geschaut, aber nichts gefunden.

    Ich habe gerade mal die neueste 2.3.0 auf dem betroffendem Server (Debian Wheezy) installiert. Die Fehler bleiben:

    Zitat


    [2017/02/13 15:05:54.721982] [22319|23685] HTTPClient: state != READ_DATA (5)
    [2017/02/13 15:05:54.722143] [22319|23685] ACME: newCert(): unexpected content-type '(null)'
    [2017/02/13 15:05:54.722171] [22319|23685] ACME: newCert() failed. Status=0, response=(null)
    [2017/02/13 15:05:54.722203] [22319|23685] ACME: can't get certificate for 'sgv-oberhundem.de':

    Hallo,


    seit neuestem gibt es ein Problem bei der Account-Erstellung mit Telefonnummern bei Let's Encrypt. Ich habe als Telefonnummer das Format +49 1234 1234-4 und +49123412344 probiert.
    Folgender Fehler kommt in Liveconfig selbst (nicht im log)

    Code
    Error creating new registration :: Contact method tel is not supported


    Ohne Telefonnummer klappt es natürlich. Daher ist das nicht so dringend.


    Grüße