Beiträge von clickpress

Zitat von kk

Wie wäre es, wenn LiveConfig ein Umschalten der CLI-PHP-Version per GUI ermöglicht?

Das wäre eine Premium-Lösung 😄

Zitat von antondollmaier

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:

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:

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.

Zitat von antondollmaier

Code

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

Das hab ich auch schon probiert. Gab aber schonmal einen Fehler, da in irgendwelchen Sub-Abhängikeiten /usr/bin/php hart reingecodet wurde.

Zitat von kk

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.

Zitat von TCRserver

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:

# 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:

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:

PHPMAJOR=`echo $PHPVERSION | cut -c1`

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

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:

#!/bin/sh
#  _    _          ___           __ _     (R)
# | |  (_)_ _____ / __|___ _ _  / _(_)__ _
# | |__| \ V / -_) (__/ _ \ ' \|  _| / _` |
# |____|_|\_/\___|\___\___/_||_|_| |_\__, |
#                                    |___/
# Copyright (c) 2009-2017 Keppler IT GmbH.
# ----------------------------------------------------------------------------
# common/tools/cron.php.sh
# $Id: cron.php.sh 4773 2017-11-29 08:39:13Z kk $
#
# Shell script to remove expired PHP session files (via cron)
# Inspired by Debian's /usr/lib/php5/maxlifetime and /etc/cron.d/php5
# ----------------------------------------------------------------------------


set -e


. /etc/liveconfig/sysconfig || exit 0


# Default expire time: 1440 seconds = 24 minutes
EXPIRE=1440


if which php >/dev/null 2>&1 && [ -d '$LC_WEBROOT' ]; then
  # detect version of default PHP-CLI binary:
  PHPVERSION=`php -r 'echo phpversion();' | sed -e 's/\.//g' | cut -c1-2`
  if [ '$PHPVERSION' = '70' ]; then
    PHPVERSION="7"
  fi


  PHPMAJOR=`echo $PHPVERSION | cut -c1`


  for cust in $LC_WEBROOT/*; do
  [ -d '$cust' -a -d '$cust/tmp' ] || continue
      # get session.gc_maxlifetime
      max=$EXPIRE
      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
        cur=$(php -c "$cust/.php5/php.ini" -d "error_reporting='E_ALL & ~E_DEPRECATED'" -r 'print ini_get("session.gc_maxlifetime");')
      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");')
      fi
      [ -z '$cur' ] && cur=0
      [ '$cur' -gt '$max' ] && max=$cur
      max=$(($max/60))
      find "$cust/tmp" -type f -cmin +$max -regex ".*/sess_[a-z0-9]*" -delete
    done
fi


exit 0

Zitat von antondollmaier

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

Zitat von aziegler

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

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

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

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.

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:

systemctl unmask lcpolicyd
systemctl enable lcpolicyd
systemctl restart lcpolicyd


systemctl unmask lcsam
systemctl enable lcsam
systemctl restart lcsam

Wie kann ich denn nginx beibringen, http2 zu nutzen? In die vhosts reinschreiben wäre ja unsinnig, da LC diese ggf. überschreibt.

Zitat von kk

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:

Zitat

[2017/02/17 19:03:54.988935] [15729|17416] ACME: sceduling renewal of SSL certificate for 'mail.clickpress.biz'
[2017/02/17 19:03:55.615879] [15729|17416] ACME: newCert() failed. Status=429, response={
"type": "urn:acme:error:rateLimited",
"detail": "Error creating new cert :: Too many certificates already issued for exact set of domains: mail.clickpress.biz",
"status": 429
}
[2017/02/17 19:03:55.615955] [15729|17416] ACME: can't get certificate for 'mail.clickpress.biz': Error creating new cert :: Too many certificates already issued for exact set of domains: mail.clickpress.biz

Alles anzeigen

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':

Ich habe das selbe Problem auf einem unserer Server. Irgendwann läuft das ganze dann in die Rate Limitierung.

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)

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

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

Grüße

Ich bin auch dafür!

Hiermit kannst du das Directory Listing aufhübschen:
http://adamwhitcroft.com/apaxy/

SSL ja, Let's Encrypt nein

Mit dem Update heute habe ich auch neue Hinweise zu meinem nicht funktionierenden Zertifikaten:

Zitat

[2016/02/02 10:55:38.413204] [14450|14452] [LUA] LC.exec(/etc/init.d/apache2 reload): program output: Reloading web server config: apache2.
[2016/02/02 10:56:21.027900] [14449|14715] ACME: newCert(): unexpected content-type '(null)'
[2016/02/02 10:56:21.027962] [14449|14715] ACME: newCert() failed. Status=0, response=(null)
[2016/02/02 10:56:21.027998] [14449|14715] ACME: can't get certificate for 'admin.clickpress.biz':

Liegt das jetzt daran, dass ich zuviele Tests gemacht habe?
https://crt.sh/?q=admin.clickpress.biz