Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nouveau serveur 2024, quelques questions pour planification #29

Open
biggrizzly opened this issue Feb 25, 2024 · 59 comments
Open

Nouveau serveur 2024, quelques questions pour planification #29

biggrizzly opened this issue Feb 25, 2024 · 59 comments

Comments

@biggrizzly
Copy link

biggrizzly commented Feb 25, 2024

Hello,

La nouvelle VM est enfin en cours d'installation.
J'ai quelques questions pour l'organisation de la chose.
Il s'agit d'une VM en Debian 12.
Le dépôt PHP seront celui de Sury, ce qui signifie que nous pouvons installer du PHP 7.1 comme sur la prod, et du PHP 8.2+ en même temps.
Le dépôt MariaDB sera l'officiel, je compte installer la version 10.11 LTS.
Pour le certificat, j'hésite encore entre certbot et acme, ça n'a pas beaucoup d'importance.

Les questions que je me pose :

  • Est-ce qu'on migre direct, sans autre action ? On reste en php7.1 par exemple, et on a de la sorte la possibilité de travailler à côté sur la migration vers des versions de SPIP diverses.
  • Comment dois-je envisager l'installation de Sphinx, et la reprise de ses données actuelles ? A priori, désormais, on installe directement les binaires.
  • Pour translateshell, j'ai des notes à ce sujet, j'espère que ça va fonctionner. Avez-vous des retours à ce sujet ?
  • Pour le répertoire "tmp" de SPIP, est-il nécessaire de garder quoi que ce soit de ce répertoire lors de la migration des données ? Les scripts de migration précédents ne suppriment que certains fichiers, bizarrement, quand de mon côté, je n'aurais pas une seconde d'hésitation pour nettoyer ce répertoire.

D'autres considérations :

  • J'ai utilisé une IP failover standard comme IP publique, ça évitera d'avoir un lien trop voyant par rapport aux IP Ripe, mais ça nécessitera un changement d'IP dans les DNS le jour de la migration (oui, par contre, ça va peut-être nous jouer des tours en termes de délivrabilité, nous verrons).
  • L'hôte physique est plus récent, meilleurs processeurs à priori, mais... disques SAS. Ça ne devrait pas trop se remarquer. Nous verrons. On pourra revenir sur l'hôte SSD si nécessaire, mais dans l'immédiat, je n'ai pas de place ailleurs.

Merci pour vos réponses aux différentes questions, dans l'immédiat.

Les volumes de données actuels (en Mo, uniquement ce qui dépasse le Go) :

1359 ./export
194849 ./IMG
27636 ./local
23588 ./tmp
247690 .
Base de données : 18Go.

@biggrizzly biggrizzly changed the title Nouveau serveur, quelques questions pour planification Nouveau serveur 2024, quelques questions pour planification Feb 25, 2024
@martinarnaud
Copy link
Member

  • Pour PHP, une étape intermédiaire est de passer en 7.4, qui est la version compatible à la fois avec SPIP 3.2 et SPIP 4.2. Je ne sais pas si c'est utile pour vous, perso c'est ce que je fais pour «lisser» la montée de version.
  • Pour /tmp, a priori c'est du temporaire, mais avec le cache SPIP.
  • Mais normalement, Seenthis fonctionne avec microcache, et en théorie ça se trouve dans /local/microcache. Si c'est bien le cas, c'est là que se trouve le cache «pérenne» des pages servies aux visiteurs, et là ça vaudrait le coup de les conserver.

Le reste, c'est au-dessus de mes compétences.

@brunob
Copy link
Member

brunob commented Feb 26, 2024

Hello,

La nouvelle VM est enfin en cours d'installation. J'ai quelques questions pour l'organisation de la chose. Il s'agit d'une VM en Debian 12. Le dépôt PHP seront celui de Sury, ce qui signifie que nous pouvons installer du PHP 7.1 comme sur la prod, et du PHP 8.2+ en même temps. Le dépôt MariaDB sera l'officiel, je compte installer la version 10.11 LTS. Pour le certificat, j'hésite encore entre certbot et acme, ça n'a pas beaucoup d'importance.

Pour MaraiDB, je pense qu'il faut rester sur du 10.5 max cf https://www.spip.net/fr_article4351.html peut-être même une 10.3 vu qu'on est encore en SPIP 3.2.

Les questions que je me pose :

* Est-ce qu'on migre direct, sans autre action ? On reste en php7.1 par exemple, et on a de la sorte la possibilité de travailler à côté sur la migration vers des versions de SPIP diverses.

Comme le disais déjà @martinarnaud on peut passer en PHP 7.4 sans problème.

* Comment dois-je envisager l'installation de Sphinx, et la reprise de ses données actuelles ? A priori, désormais, on installe directement les binaires.

Là dessus je laisse @rastapopougros et @Fil répondre, je n'ai jamais touché à Sphinx.

* Pour translateshell, j'ai des notes à ce sujet, j'espère que ça va fonctionner. Avez-vous des retours à ce sujet ?

Ça devrait passer sans pb cf https://github.com/seenthis/hebergement/wiki/Installation-de-translate-shell

* Pour le répertoire "tmp" de SPIP, est-il nécessaire de garder quoi que ce soit de ce répertoire lors de la migration des données ? Les scripts de migration précédents ne suppriment que certains fichiers, bizarrement, quand de mon côté, je n'aurais pas une seconde d'hésitation pour nettoyer ce répertoire.

Normalement on peut s'en passer, c'est le principe de tmp.

D'autres considérations :

* J'ai utilisé une IP failover standard comme IP publique, ça évitera d'avoir un lien trop voyant par rapport aux IP Ripe, mais ça nécessitera un changement d'IP dans les DNS le jour de la migration (oui, par contre, ça va peut-être nous jouer des tours en termes de délivrabilité, nous verrons).

No problemo.

* L'hôte physique est plus récent, meilleurs processeurs à priori, mais... disques SAS. Ça ne devrait pas trop se remarquer. Nous verrons. On pourra revenir sur l'hôte SSD si nécessaire, mais dans l'immédiat, je n'ai pas de place ailleurs.

Fais au mieux, on te fait confiance :)

Les volumes de données actuels (en Mo, uniquement ce qui dépasse le Go) :

1359 ./export

À voir si on garde tout ça, ce dossier contient certainement des données qui datent tellement qu'elle sont inutiles à ce jour. Tu en pense quoi @Fil

27636 ./local

Normalement on peut se passer de celui-ci aussi, mais certaines vignettes d'images distantes contenues dans le dossier risquent de ne pas se recréer si l'image en face a disparu. Vos avis ?

@rastapopougros
Copy link

Normalement on peut se passer de celui-ci aussi, mais certaines vignettes d'images distantes contenues dans le dossier risquent de ne pas se recréer si l'image en face a disparu. Vos avis ?

Du coup non si ya le cache de microcache qui contient le html final de quasiment tout si je comprends bien, de chaque seen déjà généré.

Comment dois-je envisager l'installation de Sphinx, et la reprise de ses données actuelles ? A priori, désormais, on installe directement les binaires.

Tu peux remplacer quasi tel quel par Manticore qui est le fork plus mieux libre. Je l'ai fait sur plusieurs machines sans problème. Ça permet ensuite d'avoir des paquets maintenus vraiment à jour et de monter de version.
https://manual.manticoresearch.com/Installation/Migration_from_Sphinx#Sphinx-2.x--%3E-Manticore-2.x

@biggrizzly
Copy link
Author

Merci 1000 fois pour vos réponses et suggestions à tous trois.

En résumé :

  • J'installe PHP7.4 car il va permettre de basculer de l'ancien SPIP au nouveau ; j'installe et configure aussi le 8.2 pour plus tard.
  • J'installe MariaDB 10.3 pour la même raison, avec regret, car cela signifie que nous devrons gérer une future migration
  • Je peux nettoyer le répertoire tmp, parfait
  • Je conserve le répertoire local, pas de soucis
  • Pour ces histoires de "je conserve, je nettoie", c'est surtout pour accélérer la synchronisation, car pour l'espace, sur ce serveur, nous pouvons nous considérer comme au large.
  • translateshell, merci pour le lien, je teste
  • sphinx, ok pour manticore, je teste et je vous dis

Il ne me reste plus qu'à avancer sur la suite de ma recette de configuration.

@biggrizzly
Copy link
Author

C'est amusant les contraintes. Là, par exemple, on est sur Debian 12, pour avoir un système récent, et installer un MariaDB 10.3 sur un Debian 12, ce n'est pas naturel. Heureusement, on n'est pas les seuls avec ce genre de besoins, et en fait on a de la chance, vraiment.
https://olvy.net/blog/olvy-ported-mariadb103-to-debian12-and-ubuntu2204/
La migration de la base de données devrait être automatisée ce soir. Ouf.

@brunob
Copy link
Member

brunob commented Feb 29, 2024

Heureusement, on n'est pas les seuls avec ce genre de besoins, et en fait on a de la chance, vraiment.

Ouf, on pourra basculer en 10.5 une fois seenthis passé en SPIP 4 !

@biggrizzly
Copy link
Author

biggrizzly commented Feb 29, 2024

On est bien d'accord que l'objectif, c'est 10.11 ? Parce que 10.5, ce n'est pas supporté, non plus, nativement, sur Debian 12 :-))
https://mariadb.com/kb/en/installing-mariadb-10-5-in-debian-12-bookworm/
(installer docker pour avoir MariaDB... pourquoi pas...)

@brunob
Copy link
Member

brunob commented Feb 29, 2024

Rien de certain pour 10.11, à ce jour SPIP est annoncé compatible 10.5 max.

@biggrizzly
Copy link
Author

Soit on est conservateur, et on reste en 10.5 (via docker). Soit on est aventuriers, et on démontre que SPIP4 fonctionne avec MariaDB 10.11. :-)

@biggrizzly
Copy link
Author

Je viens de revoir le processus d'installation en installant docker, comme ça c'est fait, et en installant mariabd 10.3 pour la partie serveur dans docker.

Mais alors que je me disais "chouette, ça fonctionne", je me souviens qu'il faut aussi une partie cliente. Et là, pas possible de l'installer avec docker. La partie cliente, ce sont des binaires, pas simplement un port TCP à partager.

Donc, je réinstalle mariadb10.3 pour la partie cliente via APT et le référentiel Olvy. Mais je ne le pourrais pas plus tard quand on passera à 10.5.

J'ai un petit peu l'impression de tourner en rond.

Il y a vraiment des incompatibilités sévères de SPIP3 avec les versions avancées de MariaDB ? J'avoue ne pas avoir spécialement envie de ne migrer "que" sur Debian 11.

(...)

On restera en client 10.3 autant que nécessaire. On pourra passer en server 10.5 si ça nous chante.

@benchti
Copy link

benchti commented Mar 3, 2024

Hello, désolé j'arrive peut être un peu après la bataille, mais pour info on a une machine en debian 12 qui fait tourner des SPIP ( SPIP 3 et 4 ) et rien à signaler

mariadb --version
mariadb  Ver 15.1 Distrib 10.11.6-MariaDB, for debian-linux-gnu (x86_64) using  EditLine wrapper

@brunob
Copy link
Member

brunob commented Mar 3, 2024

Merci pour le signalement @benchti j'en causais justement hier avec marcimat, et donc @biggrizzly on peut passer sans pb en mariadb 10.11 (désolé pour le délai, c'est le we tout ça...).

@biggrizzly
Copy link
Author

Hu hu... On dira que j'ai passé ce temps à parfaire ma connaissance de docker, mariadb et seenthis... :-)
Je vire Docker et Olvy, et je passe sur les dépôts officiels.
Merci pour vos retours.

@biggrizzly
Copy link
Author

biggrizzly commented Mar 6, 2024

Avancement:

  • VM Debian 12
  • mariadb
  • nginx
  • let's encrypt
  • rsync des données
  • backup-restore mariadb
  • site accessible
  • publication fonctionnelle
  • y compris la génération des vignettes
  • translateshell
  • manticore
  • reprise de l'index sphinx existant
  • validations tierces
  • accès SSH aux autres contributeurs
  • duplication sur stdev
  • mails sortants

@biggrizzly
Copy link
Author

Je tombe sur un nouvel os. Installer manticore, facile, ça installe la version 6.
Convertir l'index en version 2.x de sphinx vers manticore, je tombe sur index_converter qui me parle de "segmentation fault". Apparemment, passer de 2 à 6, c'est trop. J'ai au moins une référence qui dit "installe manticore 3 d'abord":
https://forum.manticoresearch.com/t/help-me-to-retrieve-data-from-the-old-index/1189
Y-a-t-il plus pratique que de recompiler depuis les sources ?

@biggrizzly
Copy link
Author

Go pour un conteneur docker... Il existe un conteneur en version 3.

@rastapopougros
Copy link

Là tout de suite j'ai la V6 en local mais c'est bien possible que j'ai d'abord migré petit à petit oui. Je suppose que tu as lu cette page : https://manual.manticoresearch.com/Installation/Migration_from_Sphinx

Mais il est possible aussi que j'ai migré la partie logicielle et config (que les index soient bien définis comme avant) MAIS que j'ai ensuite tout réindexé à zéro depuis le SPIP (avec la commande spip-cli "indexer:indexer").

@biggrizzly
Copy link
Author

biggrizzly commented Mar 10, 2024

Les conteneurs manticore ne contiennent pas le convertisseur :-/

J'ai tenté de lancer une réindexation. spip-cli n'est pas présente de ce que je crois détecter sur le seenthis de prod'. Et le nouveau non-plus, je n'ai rien fait pour l'installer. Je ne suis pas familier de ces outils.

Et donc, j'ai tenté de copier-coller la déclaration d'index de seenthis. Quand je le fais, le démon refuse de démarrer.

J'ai consulté le site spip : https://contrib.spip.net/Indexer-Installation-et-Configuration#Installation-de-Sphinx sans y trouver de mention de manticore et des différences qu'il convient de gérer.

Comment puis-je obtenir de l'aide ?

  • En premier objectif, il faut valider qu'on a un chemin de migration vers une solution pleinement fonctionnelle sur le SPIP3 actuel
  • En second objectif, il faut que je parvienne à automatiser un minimum ce chemin pour le jour J

Je constate que sphinx existe en docker aussi. Peut-être qu'il s'agit d'une solution potentielle ?

Merci pour vos retours.

@rastapopougros
Copy link

La diff c'est surtout le binaire :
vim /etc/manticoresearch/manticore.conf

#!/usr/bin/env php
<?php
# Correction bug paquet debian / ubuntu
if (!is_dir('/var/run/manticore')) {
        mkdir('/var/run/manticore');
}

# Recherche et inclusions des configurations
foreach (glob(__DIR__ . '/conf.d-enabled/*.conf') as $conf) {
    include $conf;
}

vim /etc/manticoresearch/conf.d-enabled/searchd.conf

common {
        plugin_dir = /usr/local/lib/manticore
}
searchd
{
        # Lister les ports autorisés
        listen          = 9306:mysql41

        # Stockage du PID obligatoire
        pid_file        = /var/run/manticore/searchd.pid

        # logs
        log             = /var/log/manticore/searchd.log
        query_log       = /var/log/manticore/query.log
        binlog_path     = /var/lib/manticore/data/

        # pour les index RT
        #workers                = threads
}

Pour l'index j'ai pareil que dans la doc SPIP à part le path=
path = /var/lib/manticore/data/monindex (je sais pas comment il s'appelle pour seenthis, "spip", "seenthis" ou autre)

Même si ya pas spip-cli on peut lancer la réindexation complète depuis l'admin du SPIP, c'est juste plus chiant et long qu'en cli. Et sinon faut installer spip-cli. :p https://contrib.spip.net/SPIP-Cli#Installation

@biggrizzly
Copy link
Author

@rastapopougros : puis-je te demander ton assistance ? J'ai créé ton compte, ajouté ta clef. J'ai mis ton mot de passe par défaut dans un fichier caché facile à trouver dans ton répertoire, ce qui doit te permettre de le modifier. Tu es dans le groupe des sudoers.
Le serveur est seenthis2.zoo-logique.org
L'utilisateur est rastapopoulos
Manticore est installé depuis les paquets Debian du projet.
J'ai installé spip-cli dans /opt/spip-cli comme la doc le dit.
L'instance en cours d'installation est dans /var/www/stprod/public_html
Les fichiers de config' de Manticore sont dans /etc/manticore
Je n'ai aucune opinion sur la façon d'installer l'indexation. J'ai proposé de faire ça dans /var/local/manticore/seenthis, à la façon dont ça fonctionne sur le serveur actuel, mais ce n'est pas obligatoire non plus.
J'ai l'intention, une fois que ce sera fonctionnel, de monter ce répertoire sur un disque SSD.

Je créerai les comptes des autres habitués dans le courant du WE.

@biggrizzly
Copy link
Author

@brunob : j'ai créé ton compte avec la clef que j'ai trouvé sur la prod.

N'hésitez pas à me biper si ça fonctionne ou pas.

Qui d'autre est volontaire pour aider et avoir un accès ? :-)

@brunob
Copy link
Member

brunob commented Mar 18, 2024

@biggrizzly je viens de tenter de me connecter et ça tourne dans le vide sans aller plus loin que ça :

bb@tybook:~$ ssh -v seenthis2.zoo-logique.org
OpenSSH_8.2p1 Ubuntu-4ubuntu0.11, OpenSSL 1.1.1j  16 Feb 2021
debug1: Reading configuration data /home/bb/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to seenthis2.zoo-logique.org [87.98.137.226] port 22.

Pas d'urgence hein :)

@biggrizzly
Copy link
Author

Forcément, si j'ouvre pas le pare-feu... :-/
C'est normalement corrigé.

@brunob
Copy link
Member

brunob commented Mar 18, 2024

Ok j'y suis, j'ai personnalisé mon pass et viré le fichier qui contenait le pass temporaire :)

@rastapopougros
Copy link

Je me suis connecté et changé le pass aussi.

$ sudo service manticore status
Active: active (running) since Sat 2024-03-16 14:18:24 CET; 2 days ago

MAIS…

WARNING: table 'seenthis': prealloc: failed to open /var/local/manticore/seenthis.lock: Permission denied - NOT SERVING

Du coup :

$ ls -l /var/local/
total 8
drwxr-sr-x 3 root staff 4096 16 mars  14:10 manticore
drwxr-xr-x 8  114 adm   4096  9 mars  18:33 sphinx

Est-ce qu'il faudrait pas que le dossier "manticore" ait des droits permettant au logiciel/service "manticore" d'écrire dedans (pas juste dans les sous-dossiers qui sont dedans) ?

@biggrizzly
Copy link
Author

biggrizzly commented Mar 18, 2024

J'étions persuadé d'avoir veillé à cela. Manticore tournait quand j'ai fait les tests. Mais peut-être que depuis il s'est passé d'autres choses...

Merci en tout cas de m'avoir rejoint ;-)

J'avais chowné le répertoire seenthis dans manticore, mais pas manticore.
En corrigeant, ça tombe en marche :-/ J'ai merdé ce WE, en quelque sorte.

Apparemment, ça indexe les nouveaux posts.

Y-aurait plus qu'à relancer l'indexation de zéro en fait ?

Je tente à l'instant, et ça sort avec erreur :

root@seenthis2:$ cd /var/www/stprod/public_html/
root@seenthis2:/var/www/stprod/public_html$ spip "indexer:indexer"
<h2>Analyse de Spip\Indexer\Sources\HierarchieRubriques :</h2>
<p><strong>Temps pour indexer 1 hierarchie_rubriques (ids 1 à 1001)</strong>
<br />Documents: 0.617 ms
<br />Enregistrement dans l'index: 2.026 ms
</p><p class='success'><strong>Temps pour Spip\Indexer\Sources\HierarchieRubriques :</strong><br />2.683 ms</p><hr /><h2>Analyse de Spip\Indexer\Sources\HierarchieMots :</h2>
<p><strong>Temps pour indexer 1 hierarchie_mots (ids 1 à 1001)</strong>
<br />Documents: 1 594.000 ms
PHP Warning:  Packets out of order. Expected 2 received 1. Packet size=111 in /var/www/stprod/public_html/plugins/indexer/lib/Sphinx/SphinxQL/SphinxQL.php on line 49
<h4>Erreur à l’enregistrement des documents.</h4>

@biggrizzly
Copy link
Author

Les emails sont activés.
https://scanmy.email/results-sfaa78eb6

@biggrizzly
Copy link
Author

A propos de l'indexation : c'est sans doute trivial, mais je ne suis pas capable de déterminer l'origine de l'erreur.
Je n'ai pas accès au backoffice de Spip.
Il ne reste que l'indexation pour pouvoir commencer à valider le bon fonctionnement de SeenThis sur ce nouveau serveur.
L'erreur semble liée à l'écriture en base de données.
Quel est le sachant pouvant aider SVP ?

@biggrizzly
Copy link
Author

Je soupçonne que l'anomalie du communication pourrait être liée à MariaDB, et au bazar laissé par les différentes installations. Je n'ai pas forcément envie de tout recommencer. Mais peut-être.

@brunob
Copy link
Member

brunob commented Mar 24, 2024

Quel est le sachant pouvant aider SVP ?

Désolé, je n'ai jamais touché à la partie indexation :\

@biggrizzly
Copy link
Author

Je réinstalle depuis une machine vierge. Histoire de m'assurer que tout est bien propre.
Afin de vérifier si je bute sur le même souci avec Manticore.

@biggrizzly
Copy link
Author

Me revoilà au même point.

L'indexation des nouveaux articles : OK.
La réindexation : KO.

<h2>Analyse de Spip\Indexer\Sources\HierarchieRubriques :</h2>
<p><strong>Temps pour indexer 1 hierarchie_rubriques (ids 1 à 1001)</strong>
<br />Documents: 0.847 ms
<br />Enregistrement dans l'index: 1.271 ms
</p><p class='success'><strong>Temps pour Spip\Indexer\Sources\HierarchieRubriques :</strong><br />2.157 ms</p><hr /><h2>Analyse de Spip\Indexer\Sources\HierarchieMots :</h2>
<p><strong>Temps pour indexer 1 hierarchie_mots (ids 1 à 1001)</strong>
<br />Documents: 1 564.752 ms
PHP Warning:  Packets out of order. Expected 2 received 1. Packet size=111 in /var/www/stprod/public_html/plugins/indexer/lib/Sphinx/SphinxQL/SphinxQL.php on line 49
<h4>Erreur à l’enregistrement des documents.</h4>

Au moins suis-je assuré d'avoir un système stable et propre désormais. Je vais tâcher d'étudier plus avant tous les logs.

@biggrizzly
Copy link
Author

Padawan le stage 2 atteint il a:
manticoresoftware/manticoresearch#1034

Ajout dans searchd.conf max_packet_size = 128M et:

<h2>Analyse de Spip\Indexer\Sources\HierarchieRubriques :</h2>
<p><strong>Temps pour indexer 1 hierarchie_rubriques (ids 1 à 1001)</strong>
<br />Documents: 0.408 ms
<br />Enregistrement dans l'index: 1.419 ms
</p><p class='success'><strong>Temps pour Spip\Indexer\Sources\HierarchieRubriques :</strong><br />1.866 ms</p><hr /><h2>Analyse de Spip\Indexer\Sources\HierarchieMots :</h2>
<p><strong>Temps pour indexer 1 hierarchie_mots (ids 1 à 1001)</strong>
<br />Documents: 1 360.398 ms
<br />Enregistrement dans l'index: 871.927 ms
</p><p class='success'><strong>Temps pour Spip\Indexer\Sources\HierarchieMots :</strong><br />2 244.616 ms</p><hr /><h2>Analyse de Spip\Indexer\Sources\SpipDocuments :</h2>
<p><strong>Temps pour indexer 15 articles (ids 3 à 1003)</strong>
<br />Documents: 102.104 ms
<br />Enregistrement dans l'index: 8.367 ms
</p><p class='success'><strong>Temps pour Spip\Indexer\Sources\SpipDocuments :</strong><br />110.820 ms</p><hr /><h2>Analyse de Spip\Indexer\Sources\SpipDocuments :</h2>
<p class='success'><strong>Temps pour Spip\Indexer\Sources\SpipDocuments :</strong><br />0.282 ms</p><hr />PHP Fatal error:  Uncaught TypeError: Return value of "IndexerIndexer::execute()" must be of the type int, "null" returned. in /opt/spip-cli/vendor/symfony/console/Command/Command.php:301
Stack trace:
#0 /opt/spip-cli/vendor/symfony/console/Application.php(1040): Symfony\Component\Console\Command\Command->run()
#1 /opt/spip-cli/vendor/symfony/console/Application.php(301): Symfony\Component\Console\Application->doRunCommand()
#2 /opt/spip-cli/vendor/symfony/console/Application.php(171): Symfony\Component\Console\Application->doRun()
#3 /opt/spip-cli/bin/spip(17): Symfony\Component\Console\Application->run()
#4 {main}
  thrown in /opt/spip-cli/vendor/symfony/console/Command/Command.php on line 301

Génial.

@biggrizzly
Copy link
Author

Je n'ai pas accès à l'espace ecrire/?exec=indexer pour vérifier si c'est une incompatibilité entre spip-cli et la version active de SeenThis. Si vous avez la possibilité de tester, c'est volontiers que je lirais vos retours.

@brunob
Copy link
Member

brunob commented Apr 28, 2024

Je n'ai pas accès à l'espace ecrire/?exec=indexer pour vérifier si c'est une incompatibilité entre spip-cli et la version active de SeenThis. Si vous avez la possibilité de tester, c'est volontiers que je lirais vos retours.

Je veux bien y jeter un œil, mais je n'ai pas d'adresse publique pour accéder à la version de dev.

Sinon, tu peux te créer un compte super admin temporaire avec spip root:me.

@biggrizzly
Copy link
Author

Alors. Je me suis créé un utilisateur admin. Puis j'ai tenté de lancer l'indexation. J'ai eu une erreur 500, indiquant une mémoire insuffisante. J'ai mis à memory_limit à 1Go, et c'est allé jusqu'au bout. Mais ça s'arrête au même endroit qu'en ligne de commande. Ca n'indexe pas rien, mais presque rien.

La machine est toujours à la même adresse. seenthis2.zoo-logique.org. Je l'éteins en général en fin de journée, pour éviter que des bots y parviennent. Mais je peux la laisser allumée. Ton utilisateur est toujours présent, clef publique y compris. Le mot de passe par défaut a été modifié, cf. fichier caché. C'est vrai aussi pour les autres utilisateurs.

Les alternatives sont :

  • On parvient à faire fonctionner la réindexation, et on a un serveur tout neuf prêt à migration
  • On ne parvient pas, et on doit trouver une autre solution
    • On peut tenter une montée de version SPIP post-migration (on = b_b ;-) )
    • On peut insister pour faire fonctionner la réindexation... mais je n'ai pas de piste d'étude

Des avis, la foule ?

@biggrizzly
Copy link
Author

Quoi qu'il en soit, le serveur est à ta disposition @brunob. Il y a un snapshot. Tout est (presque) comme l'autre serveur. L'instance de référence est dans /var/www/stprod

@brunob
Copy link
Member

brunob commented May 3, 2024

Pas d'urgence @biggrizzly mais bb n'est pas dans le fichier sudoers. ^^

@biggrizzly
Copy link
Author

Oubli... Corrigé :)

@brunob
Copy link
Member

brunob commented Jun 4, 2024

Je viens de regarder pour ne pas te laisser tout seul @biggrizzly mais je n'ai pas plus de chance que toi pour une première. Je découvre https://github.com/seenthis/seenthis_sphinx/blob/971accdfb5b53f66e4a4b9ed57952690f93a74d5/indexer_sphinx.php et me demande si ce vieux truc est toujours d'actualité, si oui c'est peut-être ça qui nous manque ping @Fil ?

Edit: ha ben l'info était pourtant dans ce wiki https://github.com/seenthis/hebergement/wiki/Installation-par-compilation-de-sphinx ^^

@rastapopougros
Copy link

Ouille ça fait effectivement bien vieux code… Avec un SPIP à jour, et un plugin Indexer à jour, il serait quand même pas mal de se reposer uniquement sur les API fournies :

  1. les champs à indexer devraient se reposer sur la config du plugin Indexer (qui détecte les objets et les champs et les liaisons), et SI jamais ya des choses à compléter, il y a un pipeline pour ça qui permet d'ajouter des choses aussi bien dans les champs "fulltext" (content, title, etc), que dans le gros JSON d'attributs
  2. le lancement des indexations devraient se faire
    • soit dans les pipelines de SPIP déjà utilisés par Indexer (post_edition etc) quand c'est pour un contenu par un contenu (quand on crée ou modifie un seen) ;
    • soit si c'est en masse, avec la commande spip-cli "indexer:indexer" qui est prévue pour ça, sans rien avoir à coder en plus

@brunob
Copy link
Member

brunob commented Jun 4, 2024

Le code en question a eu le temps d'évoluer depuis qu'il est là, je ne faisais que pointer son existence, en attendant je viens de lancer le bouzin avec php cli_indexer tout et ça semble tourner. On verra dans quelques minutes si ça fait bien le job.

@biggrizzly
Copy link
Author

Merci à vous deux d'avoir regardé.
Si ça fonctionne, c'est cool. Ca pourrait vouloir dire qu'on pourrait passer direct en production ? :-)

J'ai passé les derniers WE du temps en utilisant le serveur pour tester des modifications sur le code source.
Je n'ai pas l'intention de continuer à brève échéance.

Aussi, @brunob je peux te le laisser à disposition pour que tu interviennes sur le code source à ta convenance, afin de valider la migration SPIP4, si tu as du temps pour ça, et que le serveur te permet de procéder plus facilement.

Si tu souhaites avancer, il faudra que tu me dises si je peux/dois ajouter des accès (ssh/sftp/autre ?) pour te faciliter la vie.

J'en profite pour glisser une considération qui m'importe relativement à ce changement de serveur : le vieux serveur en Debian 8 ne permet pas facilement de traiter les journaux, pour savoir ce qu'il se passe avec les bots. C'est très frustrant par rapport à mes habitudes de travail sur ELK. Il y a aussi le fait que j'aimerais tester des formules de filtrage automatique des IP, et bosser, là aussi, sur un vieux serveur, ce n'est pas idéal. Donc, vivement que nous réussission à mettre à jour SeenThis, merci d'avance pour votre implication, et tout et tout ;-)

@brunob
Copy link
Member

brunob commented Jun 4, 2024

Voilà, le temps d'un aller/retour en vélo à l'école et le script a terminé son job, avec quelques warnings en boucle sur la fin cf :

Warning: mysqli_error() expects parameter 1 to be mysqli, null given in /var/www/stprod/public_html/ecrire/req/mysql.php on line 1066
0.044 ms

	SELECT
		me.id_me,
		me.id_auteur,
		me.date,
		a.login,
		a.nom,
		GROUP_CONCAT(DISTINCT(rep.id_auteur)) AS rauteurs,
		GROUP_CONCAT(DISTINCT(ra.login)) AS rlogins,
		GROUP_CONCAT(DISTINCT(ra.nom) SEPARATOR " | ") AS rnoms,
		met.texte,
		GROUP_CONCAT(DISTINCT(rept.id_me)) AS reps,
		GROUP_CONCAT(DISTINCT(IF(rep.statut="publi",rept.texte,"")) SEPARATOR "\n\n----\n\n") AS rept,
		GROUP_CONCAT(DISTINCT(tags.tag) SEPARATOR " | ") AS tags,
		GROUP_CONCAT(DISTINCT(rtags.tag) SEPARATOR " | ") AS rtags,
		GROUP_CONCAT(DISTINCT(sh.id_auteur)) AS share,
		me.statut
	FROM
		spip_me AS me
		JOIN spip_me_texte AS met ON me.id_me = met.id_me
		JOIN spip_auteurs AS a ON me.id_auteur = a.id_auteur
		LEFT JOIN spip_me AS rep ON rep.id_parent = me.id_me
		LEFT JOIN spip_me_texte AS rept ON rept.id_me = rep.id_me
		LEFT JOIN spip_auteurs AS ra ON ra.id_auteur = rep.id_auteur
		LEFT JOIN spip_me_tags AS tags ON tags.id_me = me.id_me
		LEFT JOIN spip_me_tags AS rtags ON rtags.id_me = rep.id_me
		LEFT JOIN spip_me_share AS sh ON sh.id_me = me.id_me
	WHERE
		me.id_parent = 0
		AND (me.id_me>=1051001 AND me.id_me<1052001)
		AND (
		        1=1
			OR me.date_modif > "2014-05-15"
			OR rep.date_modif > "2014-05-15"
		)
	GROUP BY me.id_me
	
PHP Warning:  mysqli_error() expects parameter 1 to be mysqli, null given in /var/www/stprod/public_html/ecrire/req/mysql.php on line 1066

Warning: mysqli_error() expects parameter 1 to be mysqli, null given in /var/www/stprod/public_html/ecrire/req/mysql.php on line 1066

Reste à voir ce que ça indexé, et pour ça faut que je cherche comment on peut checker la chose en cli. Je vois bien ça sans savoir si c'est bon :

root@seenthis2:/etc/manticoresearch# ll /var/lib/manticore/
total 173M
drwx------ 2 manticore manticore 4,0K 2024-04-28 09:20 binlog/
-rw------- 1 manticore manticore 173M 2024-06-04 16:24 binlog.019

De ce que je vois ici les données devraient être dans /var/www/stprod/manticore/seenthis :

root@seenthis2:/etc/manticoresearch# cat conf.d-enabled/seenthis.conf 
index seenthis
{
  type = rt
  path = /var/www/stprod/manticore/seenthis

Je vais comparer avec la prod.

Trouvé dans le wiki que je cite plus haut echo "select uri from seenthis where match('sphinx');" | mysql -h127.0.0.1 -P9306 ne renvoie que 20 lignes, ça ne semble pas être un succès.

Je viens de relancer l'indexation et une fois terminée le service mariadb est Active: failed (Result: oom-kill) je pense qu'on a un problème de dépassement de ressource qui empêche l'indexation.

J'ai vidé l'index avec TRUNCATE TABLE seenthis with reconfigure; puis lancé un index des posts récents avec php cli_indexer.php et je vois qu'il n'y a rien dans l'index, donc je pense qu'en plus il manque un truc dans la conf de manticore.

@brunob
Copy link
Member

brunob commented Jun 12, 2024

Je m'y recolle, à ce jour on a bien 20 lignes dans MySQL [seenthis]> select * from seenthis;.

Je lance root@seenthis2:/var/www/stprod/public_html# php plugins/seenthis_sphinx/cli_indexer.php et vérifie de nouveau dans la base, toujours 20 lignes.

Peut-être un délai pour que l'indexation se fasse ?

@biggrizzly
Copy link
Author

Hélas, ces lignes sont à priori issues de mes propres créations de posts. Je viens de créer un nouveau post, est-ce que tu le vois dans l'index ?

@brunob
Copy link
Member

brunob commented Jun 12, 2024

Nope, toujours 20 lignes dans la table, je pense qu'il manque un truc dans la conf , mais n'ayant jamais utilisé ces outils je vais devoir me plonger plus loin dans leur doc et méthodes de debug :\

@biggrizzly
Copy link
Author

Hello,

Est-ce qu'il ne serait pas plus pratique de migrer SeenThis vers la dernière version de SPIP, puis de vérifier si l'indexation ne fonctionne pas mieux ?

@brunob
Copy link
Member

brunob commented Jun 13, 2024

Est-ce qu'il ne serait pas plus pratique de migrer SeenThis vers la dernière version de SPIP, puis de vérifier si l'indexation ne fonctionne pas mieux ?

On pourrait, mais je ne peux assurer que ça réglera le problème d'indexation avec Sphinx, comme je le disais cet outil est hors de mon scope. Si @rastapopougros qui semble le maîtriser peut y jeter un œil ça nous permettrait d'avancer.

@rastapopougros
Copy link

Dans les grandes lignes, comme je le disais, à mon avis il faut prendre le temps de ne PLUS utiliser le vieux script dédié, et d'utiliser uniquement ce que fournit le plugin SPIP de base (+ pipeline s'il faut compléter). Mais pour ça il faut s'assurer d'indexer la même chose dans les mêmes champs de Manticore (ou clés du JSON quand c'est dans le JSON). Normalement ça peut se faire sans changer de version de SPIP, car le plugin Indexer à jour fonctionne toujours en SPIP 3.2 à priori.

Pour ça il faut commencer par comprendre et lister ce que fait le vieux script, majoritairement c'est dans ce tableau : https://github.com/seenthis/seenthis_sphinx/blob/971accdfb5b53f66e4a4b9ed57952690f93a74d5/indexer_sphinx.php#L93
Et ensuite faut reproduire pile la même indexation mais uniquement de manière propre avec l'API du plugin Indexer.

Ce dernier indexe les choses :

  • suivant la config du plugin en admin, ya un panneau où on configure quels objets on veut indexer
  • pour ce qui est configuré quand un contenu est modifié et passe par le pipeline post_edition (donc SI les spip_me passe par post_edition quand on les crée ou qu'on les modifie : c'est censé les indexer)
  • en fournissant aussi une commande spip-cli, qui elle aussi reprend la config (ne se lance que sur les objets configurés) mais qui là indexe 100% des contenus configurés d'un coup
  • avec aussi un pipeline "indexer_document" qui permet de modifier/compléter les champs pour rajouter des choses que le plugin ferait pas tout seul (par exemple les clés "auteurs", "authors", etc dans le JSON "properties"

@brunob
Copy link
Member

brunob commented Jun 13, 2024

Merci pour le retour, si tu le sens de recoder ce plugin gogogo. De mon côté, je vais plutôt tenter de faire fonctionner le bouzin en l'état.

Je viens de faire un test simple, récupération d'une requête exécuté par le script d'indexation. Si je la lance manuellement en cli j'obtiens :

MySQL [seenthis]> REPLACE INTO seenthis (id,title,uri, summary, date, content,properties,signature) VALUES ('1051668', 'Tips & Tricks to Improve your #Dashboard_Design', 'https://seenthis2.zoo-logique.org/messages/1051668', '@nightingale: Tips & Tricks to Improve your #Dashboard_Design\nhttpnightingaledvscomtipstrickstoimprovedashboarddesign*\n\n❝Learn how to use data context, visual flow, color, typography, and appeal to create engaging data visualizations for business users.❞\n#Charts #dashboards #Data_Visualization #Design #Tools', '1715843257', 'Tips & Tricks to Improve your #Dashboard_Design\nhttpnightingaledvscomtipstrickstoimprovedashboarddesign*\n\n❝Learn how to use data context, visual flow, color, typography, and appeal to create engaging data visualizations for business users.❞\n#Charts #dashboards #Data_Visualization #Design #Tools\n\n----\n\n', '{\"objet\":\"me\",\"id_objet\":\"1051668\",\"date\":\"2024-05-16 09:07:37\",\"auteurs\":[10884,0],\"authors\":[\"nightingale\"],\"id_auteur\":10884,\"login\":\"nightingale\",\"share\":[10884],\"published\":1,\"tags\":[\"#charts\",\"#dashboards\",\"#dashboard_design\",\"#data_visualization\",\"#design\",\"#tools\"],\"url\":[\"https:\\/\\/nightingaledvs.com\\/tips-tricks-to-improve-dashboard-design\"]}', '');
Query OK, 1 row affected (0,002 sec)

Ce qui me fait penser que c'est bon, mais non car il y a toujours 20 items dans la "table" après ça.

En comparant avec la prod il y a cette différence :

MySQL [(none)]> show databases;
Empty set (0.00 sec)

VS en dev

MySQL [(none)]> show databases;
+-----------+
| Databases |
+-----------+
| Manticore |
+-----------+

Puis :

MySQL [seenthis]> describe seenthis;
+-----------------+-----------+
| Field           | Type      |
+-----------------+-----------+
| id              | bigint    |
| title           | field     |
| summary         | field     |
| content         | field     |
| date            | timestamp |
| date_indexation | timestamp |
| title           | string    |
| summary         | string    |
| content         | string    |
| uri             | string    |
| signature       | string    |
| properties      | json      |
+-----------------+-----------+
12 rows in set (0.00 sec)

VS en dev

MySQL [(none)]> describe seenthis;
+-----------------+-----------+--------------------------+
| Field           | Type      | Properties               |
+-----------------+-----------+--------------------------+
| id              | bigint    |                          |
| title           | string    | indexed stored attribute |
| summary         | string    | indexed stored attribute |
| content         | string    | indexed stored attribute |
| date            | timestamp |                          |
| date_indexation | timestamp |                          |
| uri             | string    |                          |
| signature       | string    |                          |
| properties      | json      |                          |
+-----------------+-----------+--------------------------+
9 rows in set (0,000 sec)

La différence de structure me questionne, ainsi que le fait qu'il n'y a pas de "base" avec sphinx alors qu'il y en a une avec Manticore.

@rastapopougros
Copy link

Alors oui avant quoi que ce soit dans SPIP, il faut impérativement que l'installation soit pile comme attendue, les bons champs, avec les bons types (et le bon nom de base utilisé dans le define dans SPIP)

@brunob
Copy link
Member

brunob commented Jun 13, 2024

@biggrizzly comment as-tu recréé la table manticore seenthis ? (à partir de quelles infos)

@brunob
Copy link
Member

brunob commented Jun 13, 2024

J'ai honte, je découvre que les select en cli sont limités à 20 lignes par défaut, MySQL [(none)]> select uri from seenthis order by id asc limit 0,10000000; renvoie bien 266 lignes, et si je lance une indexation des messages récents ça passe à 267 lignes. Je relance une indexation complète et regarde ce que ça donne.

@biggrizzly
Copy link
Author

J'ai créé le fichier de configuration dans Manticore sur le modèle du serveur actuel, en adaptant ce qui me paraissait devoir l'être, puis j'ai démarré Manticore, puis c'est tout. J'ai fait tout ça sans trop approfondir, je ne connais ni SPIP, ni Manticore/Sphinx, et je ne suis pas développeur PHP ;-)

@brunob
Copy link
Member

brunob commented Jun 13, 2024

J'ai fait tout ça sans trop approfondir, je ne connais ni SPIP, ni Manticore/Sphinx, et je ne suis pas développeur PHP ;-)

https://lesjoiesducode.fr/content/040/SoylOjH.mp4

Pas mieux pour moi, je ne connais rien à manticore/sphinx/indexer, mais je suis persévérant, je l'aurai... ^^

@brunob
Copy link
Member

brunob commented Jun 13, 2024

Je crois bien que l'indexation a collé la machine en overload, elle ne répond plus et je ne peux plus m'y connecter.

La suite au prochain épisode.

@brunob
Copy link
Member

brunob commented Jun 13, 2024

La machine répond de nouveau et.... je confirme l'indexation fonctionne bien :)

MySQL [(none)]> select uri from seenthis order by id asc limit 0,10;
+------------------------------------------------+
| uri                                            |
+------------------------------------------------+
| https://seenthis2.zoo-logique.org/messages/1   |
| https://seenthis2.zoo-logique.org/messages/2   |
| https://seenthis2.zoo-logique.org/messages/3   |
| https://seenthis2.zoo-logique.org/messages/4   |
| https://seenthis2.zoo-logique.org/messages/7   |
| https://seenthis2.zoo-logique.org/messages/10  |
| https://seenthis2.zoo-logique.org/messages/13  |
| https://seenthis2.zoo-logique.org/messages/14  |
| https://seenthis2.zoo-logique.org/messages/24  |
| https://seenthis2.zoo-logique.org/messages/152 |
+------------------------------------------------+

MySQL [(none)]> SELECT COUNT(*) FROM seenthis;
+----------+
| count(*) |
+----------+
|   552046 |
+----------+
1 row in set (0,000 sec)

Il faudra juste trouver un truc pour relancer l'indexation complète sans que ça explose et zou.

Edit : on doit être à environ la moitié des posts indexés cf

MariaDB [stprod]> SELECT COUNT(*) FROM spip_me;
+----------+
| COUNT(*) |
+----------+
|   995920 |
+----------+
1 row in set (0,000 sec)

Après vérification on a indexé jusqu'au post id 907000.

@brunob
Copy link
Member

brunob commented Jun 14, 2024

On dirait qu'on a un problème avec les posts importés depuis un flux RSS cf https://seenthis2.zoo-logique.org/people/spip => c'est normal, on n'est pas sur le même domaine ^^

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants