montées en système trop rapides

Dev
#1

Suite du sujet Mise à jour de maintenance : sortie de SPIP 4.1.1 & SPIP 4.0.6 :

bonjour,
je suis un utilisateur de Spip de longue date. je réagis par rapport à l’instabilité montante de cet outil.
D’abord je ne connaissais pas ce site de discussion : il y en a déjà beaucoup de sites en Spip (je crois avoir 4 ou 5 logins finissant par .spip.net) : on s’y perd. Matthieu me l’a indiqué car j’ai réussi à trouver un lien vers son email …heureusement, en cherchant le lien sur le log des changements offert par la 4.0.5 que je n’ai pas encore vus (le lieu à changé encore par rapport à la dernière fois) .

Je vois que dans la même version 4 on change de version de PHP entre la 4.0 et 4.1. Suite à changement de Juin de l’an dernier, j’ai changé serveur (pour 2 ans en Deb 10 avec php7.3) en aout 21 et mis 2 mois à mettre au point squelette sur la spip 4.0. et je n’ai pas que cela sur ce serveur, surtout que PhP est difficile à installer et maitriser sur des machines multi serveurs. Je trouve Nginx et Node plus faciles personnellement (cela se discute), moins besoin de place mémoire.

Tant qu’à changer et moderniser : pourquoi restez-vous sur Apache alors ?

N’avez-vous pas peur de perdre votre communauté avec de si nombreux changements rapides ? (suivre quand on fait autre chose n’est pas facile du tout) . Merci de votre attention .

#2

Le 03/04/2022 à 13:34, William Piedfort via Discuter de SPIP a écrit :

N’avez-vous pas peur de perdre votre communauté avec de si nombreux changements rapides ? (suivre quand on fait autre chose n’est pas facile du tout) . Merci de votre attention .

Les annonces sont toujours sur le Blog, et les détails complets des versions majeures sur le site central spip.net. Et cela depuis… un bon moment. :slight_smile:

Au contraire : après débat, il s’est avéré que tout le monde était bien d’accord qu’il fallait suivre les versions de PHP au plus proche, qui justement change bien bien plus souvent. Et que c’est ça qui permet de pas s’éloigner de la communauté PHP (dans la commu JS, node, etc, ça les versions majeurs bougent très souvent aussi).

Tout est expliqué il y a un an justement au moment de la 4.0 finale dans « Le cycle des sorties » :

Cette version 4.0 entame un changement dans nos habitudes de versions : les versions majeures seront compatibles uniquement avec les versions de PHP maintenues. Auparavant nous tentions de maintenir une compatibilité très large avec des anciennes versions de PHP.

De fait, SPIP fournira une release majeure plus souvent, au minimum 1 fois par an après chaque version majeure de PHP.

Ce cycle est désormais bien plus prévisible qu’avant, ce qui doit t’aider, et la majorité des gens, à mieux organiser les mises à jour. Prévisible et public ! puisque tout est en permanence ici :

aussi bien pour les sorties de SPIP lui-même, que pour quelles versions PHP chacune, ce qui permet de prévoir aussi d’avance les mises à jour serveur le cas échéant.

En espérant que tout soit plus lisible pour que chacun puisse s’organiser au mieux. :slight_smile:

–
RastaPopoulos

#3

Quelques réponses rapides

  • Sur discuter.spip.net : le site est en lien sur la boussole (la barre en haut de presque tous les sites *.spip.net) sauf… celui-ci même je crois bien. Il a été introduit à la place des listes de discussions (et de forum.spip.net qui a vocation à disparaitre à terme). Et évoqué là Les listes de diffusion évoluent : Mailman -> Discourse - SPIP Blog l’année dernière et sur les listes aussi.

  • Il y a effectivement beaucoup de sites *.spip.net qui reflètent un peu la diversité des participant·es et aussi un peu l’histoire de SPIP. Au fil du temps certains de ces sites sont retirés pour avoir une vue plus claire et actuelle. Mais si tu as mieux à proposer et à participer, n’hésites pas.

  • oui, il y a un saut de version de PHP entre SPIP 4.0 et 4.1. C’était une décision pas si simple à prendre, mais actuellement nous essayons de suivre également les versions maintenues de PHP lui-même : les contraintes de sécurité sur la sphère informatique est telle qu’il semble nécessaire que les serveurs soient à jour eux-mêmes. Pour rappel, PHP 7.3 n’est déjà plus maintenu par PHP (PHP: Supported Versions). Enfin la transition entre PHP 7.3 et 7.4 est relativement facile à faire pour les sites SPIP.

  • Sur Apache vs Nginx : non on ne « reste » pas particulièrement sur apache : on fournit juste un fichier htaccess qui permet de fonctionner sous Apache, mais il existe aussi des gens qui ont proposé des règles pour Nginx (je ne sais pas où, ni si elles sont à jour actuellement). De mémoire il n’y a pas de fichier .ngnix ou équivalent que nous pourrions fournir ? Si ?

#4

on fournit l’url de la recette nginx « de base » dans la page Configuration requise - SPIP

#5

Le wiki fournit les liens vers d’autres configurations : Nginx et Spip

#6

Ceci dit, il m’est arrivé de chercher les news de la dernière release sur spip.net, et d’être déçu de ne rien y trouver.
Dans la grande et longue partie de déséparpillement des différents sites, il me semble qu’un mouvement relativement simple serait de fusionner le blog dans un secteur de spip.net et présenter la dernière news bien en évidence sur l’accueil. Ou les 3 dernières news. Ou de syndiquer le blog et là aussi présenter ces news sur l’accueil de spip.net

#7

Bonsoir,

merci de toutes ces infos et mises à jour.

Je vais donc essayer de bosser le passage de php 7.3 à 7.4 sur ma machine sans erreur , sous Virtualmin…

mon serveur marche avec Nginx depuis Aout 2021 sur spip 4.0 : voici la config pour mon domaine : si cela peut en aider :

server {
server_name mondomaine ; listen xx.xx.xxx.xxx; #IP listen xx.xx.xxx.xxx:443 ssl; keepalive_timeout 70; root /home/rootdomaine/www; index index.php index.htm index.html; access_log /var/log/virtualmin/mondomaine_access_log; error_log /var/log/virtualmin/mondomaine_error_log; ssl_certificate /home/mondomaine/ssl.combined; ssl_certificate_key /home/mondomaine/ssl.key; # redirection vers site en www et https permanent if ($host = mondomaine) { return 301 ; } # redirection vers https if ($scheme = http) { rewrite ^/(?!.well-known)(.*) break; } location ~* \.(css|js|jpg|jpeg|png|gif|ico|woff2)$ { expires 30d; add_header Cache-Control "public"; } ## Interdire l'accès aux fichiers temporaires et à la config (sécurité) location ~^/(tmp|stats|config|awstats)/{ deny all; } ## Passer par SPIP si la requête ne correspond pas à un élément existant location / { # try_files $uri $uri/ /spip.php?q=$uri&$args; # this is the usual way, but careful because all non-existing content will display home page with code 200 try_files $uri $uri/ /spip.php?$args /index.php?q=$uri&$args;

#cela c un peu special à mon squelette
rewrite ^/groupe_mots(\d+).html$ /spip.php?page=groupe_mots&groupe=$1 last;
rewrite ^/sitemap\.xml$ /spip.php?page=sitemap.xml last;
}

# .well-known doit resté accessible pour Lets Encrypt
location ~ /\.well-known/acme-challenge {
allow all;
}

# On interdit habituellement l'accès au dotfiles
location ~ /\. { deny all; access_log off; log_not_found off; }

# Gzip Settings voir /etc/nginx/nginx.conf

# ajouts de client_max_body_size 10m; # config initiale de mondomaine: location ~ \.php$ { fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_pass localhost:8003; fastcgi_buffers 16 16k; fastcgi_buffer_size 32k; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; # limit_req zone=name [burst=number] [nodelay], meme 20 pose pb pour les temps acces # limit_req zone=one burst=20; } }
···

www.mondomaine

https://www.mondomaine$request_uri

https://mondomaine/$1

https://www.nginx.com/resources/wiki/start/topics/recipes/spip/

Bien cordialement

W. Piedfort

On 03/04/2022 19:45, JLuc via Discuter de SPIP wrote:

JLuc
Avril 3

Ceci dit, il m’est arrivé de chercher les news de la dernière release sur spip.net, et d’être déçu de ne rien y trouver.
Dans la grande et longue partie de déséparpillement des différents sites, il me semble qu’un mouvement relativement simple serait de fusionner le blog dans un secteur de spip.net et présenter la dernière news bien en évidence sur l’accueil. Ou les 3 dernières news. Ou de syndiquer le blog et là aussi présenter ces news sur l’accueil de spip.net

Voir le sujet ou répondre à ce courriel pour répondre.

Pour vous désabonner de ces courriels, cliquez ici.

#8

Perso je pense qu’une bonne politique de sécurité est de conserver la version PHP de la distribution, donc 7.3 pour Debian 10. Plus de 8 mois après la sortie de Debian 11 (qui n’apporte malheureusement que 7.4, même pas 8.0 ou 8.1), Virtualmin, gestionnaire de serveurs largement utilisé n’est toujours pas compatible Debian 11 …

Je comprends parfaitement que la communauté Spip ne peut pas faire autrement que de suivre les versions de PHP, je pense néanmoins que c’est PHP qui est devenu disons … zinzin … aucun client (en tous cas aucun des miens) n’a les moyens de suivre ces changements incessants. J’ai commencé pour ma part à installer du Ubuntu 20.04 pour avoir PHP 7.4 (et je constate que Ubuntu me donne 2 fois plus de travail que Debian, 2 à 3 fois plus de mises à jour), bref on vit une époque formidable.

Après relativisons l’arrêt du support 7.3, d’après ce que je comprends, Debian continue à faire des mises à jour de sécurité sur ce produit.

#9

Parfois ça gonfle un peu ces débats.
Ca fait 2 ans que j’ai restructuré et nettoyé Contrib (où il reste encore du travail que personne ne fera jamais si je m’y attèle pas) et lancé la fusion de Contrib et Plugins SPIP.
Avec b_b on a propôsé de virer le site de la Boussole pour ne plus avoir à le maintenir sachant qu’il suffit qu’un site quelconque serve la boussole.

Et bien c’est marrant, on a toujours ces sites en ligne.
Il ne se sont pas magiquement transformés.
Dingue non ?

Je me rappelle aussi d’une époque où on nous fustigeait car les versions sortaient au compte-gouttes et on ne pouvait que le déplorer nous mêmes.
Rigolo non ?

#10

À titre tout à fait personnel, je suis admiratif et reconnaissant du travail fourni par l’ensemble de la communauté :slight_smile:
Et pas plus tard que ce week-end, j’évoquais un point sur IRC : la possibilité d’avoir pour chaque plugin un README qui pourrait servir de documentation de base, et vers lequel pourrait renvoyer Plugins (et que Contrib pourrait intégrer automatiquement comme nouveaux articles, si Contrib est conservé). Si l’on a besoin d’un complément de documentation, soit on crée des articles sur Contrib, soit on ajoute des .md dans un répertoire doc du dépôt ?

À ce jour, mes contributions à SPIP ne peuvent pas véritablement concerner le code (j’espère que cela viendra) , si ce n’est marginalement, mais je peux travailler à d’autres chantiers. Au plaisir donc d’en discuter :slight_smile:

#11

Le 03/04/2022 à 23:20, Pierr0t via Discuter de SPIP a écrit :

Perso je pense qu’une bonne politique de sécurité est de conserver la version PHP de la distribution, donc 7.3 pour Debian 10.

Peut-être qu’il faut plutôt s’interroger sur la pertinence du modèle Debian de « sortie lente » (trèèèèèèèès lente) pour faire du web, si on ne garde que les trucs de base de la distribution ? (Je ne parle pas de forcément aller sur autre distrib, mais de pouvoir installer des paquets plus récents ensuite)

Autant cette stabilité peut se comprendre pour des logiciels qui bougent peu, des serveurs de fichiers, des trucs d’entreprise, etc. Mais au niveau des langages et logiciels web, ça bouge très vite (totalement pareil chez JS/Node hein), avec des améliorations aussi bien fonctionnelles que performance que sécurité. Du coup j’ai du mal à comprendre comment Debian pourrait s’arroger le droit de dire « nous on maintient quand même cette vieille version là » même si les créateurices elleux-mêmes de ce logiciel ont dit que c’était plus maintenu et plus sécurisé… On se retrouve finalement avec une sorte de fork patché par Debian, par des gens extérieur au projet, donc pas validé par la communauté d’origine du logiciel… Dit comme ça, ça ne me parait pas très sérieux en tout cas.

Ce n’est quand même pas compliqué d’installer des paquets récents avec les versions plus à jour.

Mon avis c’est que :

  • soit tu es chez un hébergeur sérieux qui fait déjà ce travail et qui propose facilement de switcher entre plusieurs versions de PHP, dont les récentes
  • soit tu maintiens toi-même un ou plusieurs serveurs dédiés et c’est toi le responsable, dans ce cas, c’est à toi d’être sérieux… si t’en es à être « admin sys de serveur dédié », c’est que tu sais ce que tu fais (perso c’est pas mon boulot et je délègue ça dès que je peux), et donc ya pas à se plaindre de devoir maintenir comme ci ou comme ça un serveur (vu que c’est le boulot des admins sys)
  • à partir du moment où on est un prestataire, qui vend du service, et qu’on décide de maintenir soi-même des dédiés, bah faut pas se plaindre de faire le boulot qu’on s’est assigné, et accuser les logiciels d’être responsables du trop de boulot, si finalement on n’est pas un gros pro d’admin sys. Je le redis, moi mes compétences principales c’est ergo et dév, et je ne m’improvise pas admin sys : même si je sais faire beaucoup de chose, je délègue ce travail à des pros de ça dans le cadre de mes prestations car ce n’est pas mon travail.

–
RastaPopoulos

#12

Oui, enfin ça a aussi ses limites : on a aussi vu ce que ça donne chez certain·es avec certains serveurs Infomaniak du coup, qui proposent un PHP récent sur une Debian 8 (toujours en LTS jusqu’au 2022-06-30), ce qui fait que libzip-dev reste dans une version lointaine, lib qui sert à PHP, qui fait que le comportement prévu par PHP lui-même buggue (en passant des heures vraiment à comprendre pourquoi mais donc ? d’où que ça vient ?!!) et qu’on doit patcher (cf fix infomaniak (extension zip récente compilée avec une vieille version de libzip-dev) · a08b23129b - archiviste - SPIP on GIT). Donc une version de PHP récente, ça va aussi avec un serveur derrière pas trop éloigné quand même… sinon on a vite des surprises…

On a vu aussi récemment PHP qui annonce dans sa doc que la lib Sodium est « activée par défaut » depuis PHP 7.2… or on vient de voir chez plein d’hébergeurs que ce n’est pas le cas :confused: … c’est difficile de savoir qui blâmer là…

#13

Salut,

je trouve le reproche du « trop rapide / instabilité » un peu raide car :

  • tout ça est fait dans la transparence et avec de la pédagogie
  • les sauts de version mineure 4.x sont prévus pour être le plus facile à faire
  • la 3.2 est en LTS donc pas pression pour passer à 4.x
  • ça va avec toutes les démarches entreprises depuis 2/3 ans pour rester dans un écosystème qui bouge (passage à git, transition vers Discuter/Discourse…)

@eric_tonton Ne pouvant contribuer sur le code, j’avais proposé d’aider à faire des trucs sur contrib (revue/validation des articles…) il y a qqs temps… ça tient toujours.

Et encore une fois, bravo et merci à celles et ceux qui prennent du temps pour que l’écosystème SPIP fonctionne aussi bien :slight_smile:

1 « J'aime »
#14

bonjour à tous,
mes excuses sur le « trop rapide / instabilité » : je n’ai pas vu les alertes sans doute car même ce support était absent de mes abonnements.
Je ne suis pas un administrateur pro mais par manque de budget, j’administre mon serveur avec un autre Spip gratuit pour une assoc d’éducation, et Dolibarr pour ma gestion aussi dessus : alors concilier les montées de versions décalées de l’un et de l’autre , des Debians, Vitualmin, des abonnements OVH 2 ans, …, c’est pas facile.

Vous faites tous un gros boulot, j’en suis conscient.

Sans doute en comparaison des montées de versions de PHP Versions - Dolibarr ERP CRM Wiki : le 7.3 est adopté en 2019 sur Dolibarr et 7.4 en 2020 déjà, c’est sans doute pour cela que je ressent un « rattrapage » de version accéléré.
Bon travail à tous !

#15

Ah on a peut être une mission pour toi si tu veux :smiley: sur spip.net relatif à #5045 - WIP: Ticket #5042 : Homogénéiser les fichiers en proposant un Readme. - spip - SPIP on GIT . De source bretonne sûre il parait que tu installes souvent des SPIP et que tu serais à même de réfléchir / proposer avec les motivé·es une réécriture à jour de Installation - SPIP (les articles d’installation particulièrement) pour que ça soit succinct et joli :), que ça ne parle pas que de FTP (ssh aussi par exemple). Que ce qui concerne les vieux SPIP soient dans un sous-répertoire dédié ou je ne sais quoi… Il faudrait aussi mettre en avant quelque part la réécriture d’url plus clairement pour Apache / Nginx (et probablement revoir / actualiser les règles nginx — pas sûr qu’il y ait les .api dedans), etc…

#16

Attention aux sources bretonnes frelatées :laughing:

Mais oui, carrément, ça me dit bien de regarder ça !
Il y a d’autres motivé·es ? On se fait un wiki ?

#17

Frelaté toi même ! ^^

1 « J'aime »
#18

tu es sur notre discord ? y a un salon documentation :slight_smile:

#19

Ayé, je suis dessus, visiblement @marcimat m’avait invité à un moment (j’avais bouffé la feuille :no_mouth:).
C’est en plus d’IRC ?

#20

Sauf erreur je ne me suis pas plaint, j’ai clairement dit que Spip ne pouvait pas faire autrement … je me suis plaint de PHP et autres #BALISE_TOUS_LES_LANGAGES_EXISTANTS qui souffrent à mon avis du syndrôme du monde moderne, à savoir que plus est toujours mieux et qui vit dans l’illusion que la 8.1 sera plus sûre et aura moins de bug que la 7.3, j’entends ce discours depuis le début de PHP et malheureusement même si on a plus de fonctionnalités (utilisées à 20%) on a toujours autant de bugs et de problèmes. Le développeur de base rêve toujours du dernier langage et de la dernière technique à la mode, c’est très séduisant mais pas très eco-responsable au moment ou tout le monde devrait penser décroissance plutôt que course en avant, mais bon c’est un débat qui pourrait nous mener trop loin, je répète je suis content du travail de cette communauté et de spip 4 qui améliore bcp de choses pour pas mal de clients (en particulier le back responsive).

Pour ma part j’ai des serveurs en PHP 5.4, 5.6, 7.0, 7.3, 7.4, 8.0 et 8.1 donc même pas peur, par contre je maintiens que les clients eux n’arrivent pas à suivre et ne comprennent pas (et oui des spip 1.9, des 2.x, des WP 3.x, 4.x que personne ne veut changer malgré mes remontrances) … Quand j’ai besoin d’une nouvelle version de PHP pour un CMS je migre de serveur, ça me permet de maintenir comme je l’ai dit le PHP correspondant à la distribution et d’éviter les pbms (par ex. ce que signale marcimat).

Pour ce qui est des hébergeurs sérieux, je dois pas être loin de les avoir tous essayés (sans plaisanter, je fais ça depuis 25 ans) et si j’en avais vraiment trouvé un génial moi non plus je ne me serai pas lancé dans l’admin de systèmes en plus de faire des sites. Et switcher de version PHP sur une distribution fait partie pour moi du « pas très sérieux » justement (même si c’est « pas très grave »), c’est juste une optimisation économique des hébergements, oui ça fait moins de travail pour l’hébergeur c’est sûr …