PHP 7.3.19-1 .....

Mise à jour de PHP

Pour mettre à jour votre version de PHP, il faut suivre les premières étapes suivantes :

Téléchargement et ajout de la clé gpg pour le dépôt PPA de PHP :

sudo apt -y install lsb-release apt-transport-https ca-certificates 
sudo wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg
echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/php.list

Ensuite installons PHP 7.4 depuis ce ppa fraîchement configuré :

sudo apt update
sudo apt -y install php7.4

A ce moment là si vous faites php -v vous devriez avoir un retour comme celui-ci :

PHP 7.4.9 ...

On peut donc en conclure que PHP a bien été mis à jour.

Cependant si vous mettez un fichier PHP avec un phpinfo(); à l’intérieur est que vous l’appelez à travers votre apache, la réponse sera que la version utilisé de PHP est la 7.3.

Deux versions de PHP en parallèle

Vous avez à ce moment là 2 versions de PHP installer en parallèle, la 7.3 et la 7.4, si vous n’avez plus besoin de la version 7.3 vous vous dites que vous pouvez la désinstaller sans souci avec sudo apt purge php7.3 suivi ou non par un sudo apt autoremove pour faire le ménage. Oui et non si vous faites cela à l’instant vous allez vous retrouver avec vos fichiers php qui ne seront plus interprété par apache (si ce n’est pas un serveur de prod vous pouvez faire le test).

Pourquoi mes fichiers PHP ne sont plus interprétés par apache

La réponse est logique mais pas évidente, comme je vous le mentionnais en début d’article, l’installation du méta paquet php installe aussi apache2 et le module libapache2-mod-php. Tout ceci fonctionne bien ensemble, php 7.3 compatible avec libapache2-mod-php développé pour la version spécifique de php 7.3, donc lorsque l’on purge php7.3 il désinstalle le module apache associé et vos fichiers php ne sont plus interprétés par apache2.

Ok mais j’ai installé php7.4, ne m’a t-il pas installé libapache2-mod-php pour la version php 7.4 ? Vous avez raison le méta paquet php7.4 installe bien libapache2-mod-php pour la version php 7.4 mais ce derniers n’est pas automatiquement activé car il existait à ce moment là encore le module libapache2-mod-php pour la version php 7.3 et ces 2 modules sont incompatibles ensemble c’est pourquoi vous devez lancer les 2 commandes suivantes :

sudo a2dismod php7.3
sudo a2enmod php7.4

La première commande va désactiver le module libapache2-mod-php pour la version php 7.3 s’il est encore présent et la seconde va activer le module libapache2-mod-php pour la version php 7.4 enfin après systemctl restart apache2, vous pouvez vérifier votre fichier php contenant le phpinfo(); qui devrait maintenant vous indiquez PHP 7.4

Vous avez retrouver l’interprétation de vos fichiers PHP, la mise à jour est terminée, sauf s’il vous manque des extensions php à installer avec par exemple pour l’extension common :

sudo apt install php7.4-common

Vous pouvez aussi si vous le souhaitez purger les extensions php7.3 comme ceci sudo apt purge php7.3-common pour l’extension common.

Sources : https://geekmag.fr/blog/2020/01/25/installer-php-7-4-sur-debian-10-ou-debian-9/

Image par simplu27 de Pixabay

Contexte

J’utilise au quotidien des outils et logiciels libres comme Ubuntu, debian pour les systèmes d’exploitation, Python (Django), Ruby (Ruby On Rails), PHP (WordPress) pour les langages de programmation / frameworks / Content Management System, MariaDB, PostgreSql, Mysql, Sqlite pour les bases de données, Apache2, Nginx pour les serveurs web et Vim, GtimeLog, Gitlab, Framagenda (NextCloud), Tmux, Firefox, Brave, Zsh (Oh My Zsh), KeepassXC, Androïd, Mattermost, Jitsi pour les outils divers et variés… Et celui dont je vais vous parler aujourd’hui Kanboard pour la gestion de projets de développement logiciel.

Pour redonner à la communauté libre un peu de ce qu’elle m’apporte quotidiennement je réalise ce blog avec des articles afin de promouvoir les logiciels libres notamment dans leur utilisation et leur complémentarité afin de réaliser des projets de développements logiciels comme par exemple en python, j’essaie alors de vulgariser l’accès à ces technologies qui demandent bien souvent de comprendre un peu plus en profondeur les concepts qu’il y a derrière plutôt que de faire du « clickodrome » sur un logiciel propriétaire.

Je donne aussi quelques conférences sur des retours d’expériences d’utilisation de logiciels libres et de méthodologies orientées vers le développement « craft » et comment ils peuvent se pratiquer au quotidien.

Bien mais pas suffisant

Malgré cette contribution déjà intéressante, cela ne me satisfaisait pas complétement, je me suis donc dit qu’il serait intéressant d’utiliser mes capacités de technicien pour les mettre à profit d’un logiciel libre et j’ai choisi Kanboard.

Les raisons de ce choix

Lorsque l’on se lance dans la contribution de logiciels libres, il y a tout un monde à découvrir, avec ses règles, ses concepts et son écosystème. Il est donc plus aisé de commencer avec des éléments connus, et non avec que des inconnus, comme en développement logiciel on va éviter de faire un projet avec que des éléments non maitrisés il faut placer un curseur entre innovation et sérénité.

L’avantage sur le projet Kanboard est que je l’utilise depuis 3 ans tous les jours pour des besoins professionnels et personnels. Je l’ai déjà installé (en tant qu’administrateur et non développeur du logiciel) plusieurs fois, je l’ai utilisé dans de nombreux cas différents, je connais donc bien le fonctionnel ainsi que les limites du produit. De plus, je savais que la personne en charge du projet était quelqu’un de disponible, que le projet était vivant (une nouvelle version du produit sort très régulièrement) et enfin que si nécessaire il était possible d’échanger en français même si dans les faits nous n’avons échangé que en anglais. Dernier élément qui m’a fait choisir ce projet, il est en PHP, technologie que je ne maîtrise pas à 100% mais que j’ai largement pratiqué dans une vie antérieure et même plus récemment.

L’objet de cette première contribution

Passons sur le fond de cette première contribution qui comme je vous le conseille se doit d’être humble envers le logiciel choisi. Comme tout processus commencer petit permet d’avancer là où commencer trop gros peut être décourageant. Appliquant ce conseil, je me suis dis que j’allais commencer par suivre la documentation des contributeurs (avant de chercher une fonctionnalité à réaliser il faut mettre en place un environnement de développement et de tests), le projet tournait d’après la documentation via Vagrant et son Vagrantfile. Et à ma grande surprise (en fait non) la documentation n’était pas à jour sur cette partie qui concerne assez peu de personnes (seulement les nouveaux contributeurs du projets). J’ai donc dû dans un premier temps réussir à démarrer le projet en local avec les éléments de la documentation qui n’était plus à jour (cela s’apparente ici un peu à déboguer, se renseigner et remplacer les éléments bloquants) en modifiant le Vagrantfile. Une fois le projet lancé en local sur mon ordinateur j’ai pu lancer les tests automatiques afin de vérifier que rien ne manquait, ce fût le cas, j’en ai profité pour faire un peu de ménage sur ce Vagrantfile notamment dans la partie script. Voici donc ma première contribution libre faisant intervenir mes compétences de technicien afin de mettre à jour l’outil de démarrage du projet pour les contributeurs.

Cette notion est particulièrement importante pour un logiciel libre car c’est l’équivalent d’un installeur de logiciel pour un utilisateur non technicien, s’il faut savoir compiler le noyau linux pour installer un logiciel, il y a de fortes chances que les utilisateurs non techniciens passent leur chemin pour la plus part. Ici c’est un peu pareil si pour un projet libre les outils et la documentation pour le démarrer en local ne sont pas clairs et efficaces (« automatisés ») il se peut que certains contributeurs passent leur chemin.

Et après ?

Une fois la modification réalisée, je l’ai proposé suivant le processus défini par l’auteur du projet (en le suivant au maximum avec beaucoup d’humilité encore une fois, on collabore on se s’impose pas) une journée plus tard mon code était mergé dans la branche master du projet Kanboard. SUPER !

Oui mais maintenant la documentation n’était plus du tout cohérente avec le Vagrantfile modifié même si celui-ci fonctionné alors qu’avant la contribution il était cassé, j’ai donc de suite enchaîné avec une seconde contribution pour mettre à jour le dépôt dédié de la documentation afin de rendre la documentation représentative de la réalité du logiciel. Et voilà en moins de 3 jours 2 contributions libres réalisées et mergées dans les projets.

Conclusion

Cette contribution fût salvatrice pour moi elle m’a permis de démystifier un univers parfois fantasmé que peut être le logiciel libre. De plus, avec ces 2 contributions rapides et efficaces (utiles aux nouveaux contributeurs le cas échéant) le sentiment de retour à la communauté est très agréable et donne envie de continuer, ce qui se profil bien car même pour une modification mineure d’un article sur Ubuntu (par exemple sur la partie tmux à travers ssh), il est devenu automatique pour moi de participer sans crainte que cela ne soit trop difficile ou long. D’autres contributions sur des logiciels libres viendront sûrement dans les prochains mois et je ne manquerai pas de vous les faire partager afin de vous distiller au passage quelques conseils suite à ces expériences enrichissantes.

Image par Shri ram de Pixabay