Skip to content

Conversation

@TiTidom-RC
Copy link
Contributor

Description

Adapt the install scripts and some core functions to ensure Jeedom can be installed on Debian 13, while maintaining backward compatibility with Debian 11 and 12.

Updated the Docker installation files and scripts too.

Suggested changelog entry

All changes are detailed in the _trixie_migrationcheck.md and _trixie_retrocheck.md files. These files are located at the root of the repository.

In summary, here are the key changes :

Replaced Debian Packages :

  • ntp → chrony
  • ntpdate → removed (included in chrony)
  • locate → plocate (modern version with alternative)
  • espeak + mbrola → espeak-ng
  • libcurl3-gnutls → libcurl4 (for Debian 13+)

Removed Debian packages :

  • telnet
  • apt-transport-https (inluded by default since Debian 10)
  • cutycapt
  • dos2unix (replaced by "sed")
  • libav-tools (replaced by "ffmpeg")
  • software-properties-common (Ubuntu package, not available in Debian)

Migrate to PHP-FPM :

  • proxy_fcgi
  • setenvif

Update MariaDB parameters :

Removed parameters (deprecated) :

  • query_cache_type, query_cache_size, query_cache_limit, query_cache_min_res_unit (query cache no more available)
  • innodb_large_prefix (active by default)

Support for custom fork repository (for the install script) :

Add "-r" parameter (R like repository) in install's script :

sudo ./install.sh -r owner/repo -v branche

Updated all references from 'apt' to 'apt-get', adding options to handle conflicts and interactions with shell.

Related issues/external references

Fixes #

Types of changes

  • Bug fix (non-breaking change which fixes)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
    • This change is only breaking for integrators, not for external standards or end-users.
  • Documentation improvement

PR checklist

Copy link
Contributor

@zoic21 zoic21 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Beaucoup de changement que je ne comprends pas vraiment

$cmd = "set -x\n";
$cmd .= system::checkInstallationLog();
$cmd .= system::getCmdSudo() . " apt update\n";
$cmd .= system::getCmdSudo() . " apt-get update\n";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pourquoi revenir sur l'ancienne syntaxe apt ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"apt" est prévu pour une utilisation "interactive" (par des humains) sous Linux, et "apt-get" est la version préconisée pour le mode "script", outil plus prédictible, sans barre de progression, sans message interactif etc..., C'est pour cela que je l'ai utilisé ici.

De mes connaissances, ce n'est pas une "ancienne syntaxe" (même s'il est plus ancien que "apt" il est vrai), mais une syntaxe orientée scripting.

Cela permet également d'éviter les messages de type WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

if (!file_exists(__DIR__ . '/../../cache.tar.gz')) {
$cmd = 'mkdir ' . $cache_dir . ';';
$cmd .= 'chmod -R 777 ' . $cache_dir . ';';
$cmd = system::getCmdSudo() . 'mkdir -p ' . $cache_dir . ';';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Normalement tout le cache est sous www-data avec ce changement il passe en root ce qui n'est pas top

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Effectivement, le sudo mkdir va créer le dossier en root, mais aux lignes 402 et 403 (juste en dessous) je gère le owner du dossier en le réattribuant à "www-data" (user et groupe d'ailleurs).

J'ai utilisé le "sudo" par "sécurité", au cas où il y aurait des problèmes de droits existants sur le répertoire parent, et j'ai surtout utilisé le paramètre "-p" pour créer l'arborescence si elle n'existe pas.

Par les lignes d'en dessous, je m'assure que le répertoire appartient bien à "www-data" et ainsi ne pas gêner Jeedom dans son fonctionnement.

echo "ServerName localhost" >> /etc/apache2/apache2.conf

echo 'Start PHP-FPM'
PHP_VERSION=$(php -r "echo PHP_MAJOR_VERSION.'.'.PHP_MINOR_VERSION;")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Je veux bien plus de détails la dessus

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oui bien sûr.

J'ai basculé le script d'install pour utiliser le module PHP "FPM" couplé à "mod_proxy_fcgi" côté Apache. A l'install, le paquet linux "fpm" n'a pas d'appellation / alias "générique" sous Linux, mais est du style "php8.3-fpm" (donc contient la version php dans son nom). Pour que le script d'init reste valide pour n'importe quelle version qui sera installée maintenant mais également à l'avenir, je le passe en mode dynamique, en calculant la version PHP qui est installée, et en appelant donc le service "fpm" correspondant (ligne 157).

Si la question était pour le fait de démarrer le service, le module fpm ne démarre pas tout seul après son install, et dans un docker, il n'y a pas systématiquement de "systemd", donc je force le démarrage du service (ligne 157) avec son nom complet (incluant donc la version de PHP).

elif [[ "${GITHUB_REF_NAME}" == "beta" ]]; then
JEEDOM_TAGS="${REPO}/jeedom:beta"; # ${REPO}/jeedom:$JEEDOM_SHORT_VERSION";
GITHUB_BRANCH=${GITHUB_REF_NAME};
elif [[ "${GITHUB_REF_NAME}" == "trixie" ]]; then
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pour moi on devrait pas avoir une branche trixie....

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dans le principe, je suis tout à fait d'accord avec toi, mais il me fallait bien le moyen de tester le script d'install de bout en bout, et la branche "trixie" était son nom actuel 👍

De la même manière, j'imagine qu'à terme, les lignes 19 et 20 (parlant de la branche alpha) devraient disparaitre également, non ?

echo "thread_cache_size = 16" >> /etc/mysql/conf.d/jeedom_my.cnf
echo "tmp_table_size = 48M" >> /etc/mysql/conf.d/jeedom_my.cnf
echo "max_heap_table_size = 48M" >> /etc/mysql/conf.d/jeedom_my.cnf
echo "query_cache_type =1" >> /etc/mysql/conf.d/jeedom_my.cnf
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pourquoi toute ces suppressions ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

je comprend que cela puisse surprendre. Sous Debian 13, lors de mes premiers tests j'avais des messages d'erreurs concernant "innodb_large_prefix", qui (je l'ai appris à cette occasion) est dépécié depuis MariaDB 10.3.

Du coup j'ai approfondi mes recherches, et concernant le "Query Cache", il est mal optimisé pour des architectures processeurs récentes, et est désactivé ou déprécié par défaut depuis plusieurs versions de MariaDB (incluant celles sous les OS Debian 11, 12, 13, et paramètre supprimé de MySQL 8) et il est donc conseillé de ne plus forcer ces valeurs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants