Matériel: Raspberry Pi3B+ at home Version de YunoHost:
yunohost:
repo: stable
version: 4.0.7
yunohost-admin:
repo: stable
version: 4.0.4
moulinette:
repo: stable
version: 4.0.3
ssowat:
repo: stable
version: 4.0.4.1 J’ai accès à mon serveur : En SSH Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : non
Description du problème
Depuis la mise à jour vers yunohost core 4.0.7, ssowat 4.0.4, admin 4.0.4 (4/09/2020) ainsi que la désinstallation de php7.0 (suite à un “sudo apt autoremove”), Rainloop et Baikal ne fonctionnent plus. Je pense que c’est plus lié à la désinstallation de php7.0.
Pour Rainloop j’ai droit au message “HTTP ERROR 500”
Pour Baikal : “Baïkal was not able to establish a connexion to the configured MySQL database (as configured in Specific/config.system.php).”
J’ai plusieurs idées :
relancer configuration des applis
désinstaller puis réinstaller les applis
réinstaller php_7.0 (mais sera-t-il bien configuré ?)
Mais soit je ne sais pas comment faire (1.), soit je ne les trouve pas forcément bien subtiles…
Des conseils ou meilleurs pistes à me suggérer ?
Merci !
À mon avis ça n’a pas de rapport (même si j’ai quand même une idée liée à ça indirectement). Yunohost fait automatiquement les changements qui vont bien dans la transition à Buster.
Pour vraiment comprendre il faudrait étudier les logs. Est-ce que tu peux par exemple partager les logs de php7-3-fpm (depuis ta webadmin, dans Services > php7.3-fpm > Partager les logs)
Moké pas grand chose correspondant aux erreurs de Rainloop et Baikal … Est-ce qu’on peut regarder du côté du service nginx plutot ? Notamment ptete dans le log “tondomaine.tld-error.log”
Ouipe et deux-trois autres infos privées alors je l’ai supprimé …
De ce que je peux voir le soucis pour rainloop c’est
PHP message: PHP Fatal error: Uncaught Error: Call to undefined function ldap_connect() in /var/www/rainloop/app/data/_data_/_default_/plugins/ynh-login-mapping/index.php
Mais ça me parrait bizarre dans la mesure où le plugin php-ldap devrait avoir été installé …
Est-ce qu’on peut confirmer que la migration php7.0 -> php7.3 a bien eu lieu (genre si tu vas dans Outils > Migrations, est-ce que y’a des choses en attente ?)
## Migrations en attente
Aucune migration en attente
## [ Migrations précédentes](https://XXXXX/yunohost/admin/#done_migrations)
### 18. Migrate old network traffic rules to the new nftable system
### 17. Migrate databases from PostgreSQL 9.6 to 11
### 16. Migrate php7.0-fpm 'pool' conf files to php7.3
### 15. Mise à niveau du système vers Debian Buster et YunoHost 4.x
Le paquet php-ldap a pourtant bien l’air d’être installé :
$ sudo apt show php-ldap
Package: php-ldap
Version: 2:7.3+69
Priority: optional
Section: php
Source: php-defaults (69)
Maintainer: Debian PHP Maintainers <team+pkg-php@tracker.debian.org>
Installed-Size: 12.3 kB
Depends: php-common, php7.3-ldap
Download-Size: 5,988 B
APT-Sources: http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages
Description: LDAP module for PHP [default]
This package provides a LDAP module for PHP.
.
PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used
open source general-purpose scripting language that is especially suited
for web development and can be embedded into HTML.
.
This package is a dependency package, which depends on Debian's default
PHP version (currently 7.3).
N: There is 1 additional record. Please use the '-a' switch to see it
(Je ne pense pas que apt show montre seulement les paquets installés … pour savoir si c’est vraiment installé, classiquement on fait “dpkg --list | grep php-ldap” … ceci dit en l’occurence le vrai paquet est php7.3-ldap)
2020-09-14 13:37:44,161: DEBUG - <p>[302] The following PHP extensions are not available in your PHP configuration!</p><ul><li>cURL</li></ul>+ ynh_exit_properly
Il dit qu"il manque l’extension php cURL
Or :
$ sudo dpkg --list | grep php7.3-curl
ii php7.3-curl 7.3.22-1+0~20200909.67+debian10~1.gbpdd7b72 armhf CURL module for PHP
Tant qu’on y est :
$ sudo dpkg --list | grep php7.3-
ii php7.3-bz2 7.3.22-1+0~20200909.67+debian10~1.gbpdd7b72 armhf
ii php7.3-cli 7.3.22-1+0~20200909.67+debian10~1.gbpdd7b72 armhf
ii php7.3-common 7.3.22-1+0~20200909.67+debian10~1.gbpdd7b72 armhf
ii php7.3-curl 7.3.22-1+0~20200909.67+debian10~1.gbpdd7b72 armhf
ii php7.3-fpm 7.3.22-1+0~20200909.67+debian10~1.gbpdd7b72 armhf
ii php7.3-gd 7.3.22-1+0~20200909.67+debian10~1.gbpdd7b72 armhf
ii php7.3-gmp 7.3.22-1+0~20200909.67+debian10~1.gbpdd7b72 armhf
ii php7.3-imap 7.3.22-1+0~20200909.67+debian10~1.gbpdd7b72 armhf
ii php7.3-intl 7.3.22-1+0~20200909.67+debian10~1.gbpdd7b72 armhf
ii php7.3-json 7.3.22-1+0~20200909.67+debian10~1.gbpdd7b72 armhf
ii php7.3-ldap 7.3.22-1+0~20200909.67+debian10~1.gbpdd7b72 armhf
ii php7.3-mbstring 7.3.22-1+0~20200909.67+debian10~1.gbpdd7b72 armhf
ii php7.3-mysql 7.3.22-1+0~20200909.67+debian10~1.gbpdd7b72 armhf
ii php7.3-opcache 7.3.22-1+0~20200909.67+debian10~1.gbpdd7b72 armhf
ii php7.3-readline 7.3.22-1+0~20200909.67+debian10~1.gbpdd7b72 armhf
ii php7.3-xml 7.3.22-1+0~20200909.67+debian10~1.gbpdd7b72 armhf
ii php7.3-zip 7.3.22-1+0~20200909.67+debian10~1.gbpdd7b72 armhf
… Est-ce qu’on peut regarder du côté du service nginx plutot ? Notamment ptete dans le log “tondomaine.tld-error.log”
