Distribution EOLE

Pour participer à l’identification des changements potentiels, quelques pistes :

informations sur les paquets¶

Sur les deux versions 2.10 et 2.11, récupérer les paquets installés et les versions

dpkg-query -W

Filtrer avec les fichiers de configuration qu’on écrase (ne couvre pas tous les programmes pour lesquels on créé des fichiers de configuration.

dpkg -S $(xmllint --xpath '//file/@name' /usr/share/eole/creole/dicos/*.xml 2>/dev/null | sed -e 's/ name="\(.*\)"/\1/')

Un problème dans pyeole.common.get_current_column : fcntl.ioctl(sys.stdout.fileno(), termios.TIOCGWINSZ, u'1234') provoque une erreur SystemError: buffer overflow.

Ce code est utilisé par les commandes Maj-Auto, instance,…

Le fait que sys.stdout soit du type io.StringIO et ne possède pas de méthode fileno pourrait expliquer le plantage de fcntl.ioctl. Toutefois, en 2.9, le même problème se pose mais n’empêche pas le code de bien récupérer la largeur de colonne du terminal.

for pv in 3.9 3.10 3.11 3.12 3.13 3.14
do
  uv python install $pv
  uv init $pv
  sed 
done

python3 -c "import fcntl, termios, struct, sys;data = fcntl.ioctl(sys.stdout.fileno(), termios.TIOCGWINSZ, u'1234');print(struct.unpack('hh', data)[1])" 

root@eolebase:~# cd 3.9/
root@eolebase:~/3.9# uv run main.py
Using CPython 3.9.25
Creating virtual environment at: .venv
Hello from 3-9!
148
root@eolebase:~/3.9# cd ../3.10/
root@eolebase:~/3.10# uv run main.py
Using CPython 3.10.20
Creating virtual environment at: .venv
Hello from 3-10!
148
root@eolebase:~/3.10# cd ../3.11/
root@eolebase:~/3.11# uv run main.py
Using CPython 3.11.15
Creating virtual environment at: .venv
Hello from 3-11!
148
root@eolebase:~/3.11# cd ../3.12/
root@eolebase:~/3.12# uv run main.py
Using CPython 3.12.13
Creating virtual environment at: .venv
Hello from 3-12!
148
root@eolebase:~/3.12# cd ../3.13/
root@eolebase:~/3.13# uv run main.py
Using CPython 3.13.12
Creating virtual environment at: .venv
Hello from 3-13!
148
root@eolebase:~/3.13# cd ../3.14/
root@eolebase:~/3.14# uv run main.py
Using CPython 3.14.3
Creating virtual environment at: .venv
Hello from 3-14!
Traceback (most recent call last):
  File "/root/3.14/main.py", line 9, in <module>
    main()
    ~~~~^^
  File "/root/3.14/main.py", line 4, in main
    data = fcntl.ioctl(sys.stdout.fileno(), termios.TIOCGWINSZ, u'1234')
SystemError: buffer overflow

On peut contourner le problème en surchargeant la fonction get_current_column pour qu’elle renvoie un entier arbitraire.

On doit pouvoir utiliser les fonctions du module termios directement :

width = termios.tcgetwinsize(sys.stdout)[1]

La fonction accepte le type io.StringIO. Il n’est donc pas nécessaire d’obtenir le file descriptor correspondant.

Journal d’instance :

chsh: Warning: /usr/bin/manage-eole is an invalid shell

Ajouter /usr/bin/manage-eole au fichier /etc/shells suffit à supprimer l’avertissement.
Ce fichier n’est pas apporté par un paquet.

Pas d’autres erreurs à l’instance.

La commande diagnose rapporte seulement le problème de mise à jour (clés des dépôts introuvables).

sysctl --all --deprecated > all
sysctl --all > almost_all

diff all almost_all 
52c52
< fs.dentry-state = 58115       43495   45      0       6256    0
---
> fs.dentry-state = 58114       43494   45      0       6256    0
64,65c64,65
< fs.inode-nr = 61100   5053
< fs.inode-state = 61100        5053    0       0       0       0       0
---
> fs.inode-nr = 61099   5053
> fs.inode-state = 61099        5053    0       0       0       0       0
165c165
< kernel.ns_last_pid = 23922
---
> kernel.ns_last_pid = 23932
203c203
< kernel.random.uuid = 28afd580-e685-4944-b817-0e9fd39d77c9
---
> kernel.random.uuid = fcbaa845-6379-4d58-a0b2-6b5a9d4c9758
478d477
< net.ipv4.neigh.default.base_reachable_time = 30
492d490
< net.ipv4.neigh.default.retrans_time = 100
499d496
< net.ipv4.neigh.enp4s0.base_reachable_time = 30
509d505
< net.ipv4.neigh.enp4s0.retrans_time = 100
516d511
< net.ipv4.neigh.lo.base_reachable_time = 30
526d520
< net.ipv4.neigh.lo.retrans_time = 100
933d926
< net.ipv6.neigh.default.base_reachable_time = 30
947d939
< net.ipv6.neigh.default.retrans_time = 1000
954d945
< net.ipv6.neigh.enp4s0.base_reachable_time = 30
964d954
< net.ipv6.neigh.enp4s0.retrans_time = 1000
971d960
< net.ipv6.neigh.lo.base_reachable_time = 30
981d969
< net.ipv6.neigh.lo.retrans_time = 1000

Toutes les variables *_time ont un pendant en millisecondes qui est valable.

Mise à jour en erreur :

Paramétrage de openssh-server (1:10.2p1-2ubuntu3) ...
Could not execute systemctl:  at /usr/bin/deb-systemd-invoke line 148.
dpkg: erreur de traitement du paquet openssh-server (--configure) :
 old openssh-server package postinst maintainer script subprocess failed with exit status 1

L’erreur provient donc de l’exécution de cette ligne dans /usr/bin/deb-systemd-invoke

system('systemctl', --quiet', @instance_args, $action, @start_units) == 0 or die("Could not execute systemctl: $!");

Le service ne peut pas être démarré parce qu’il a des dépendances non satisfaites.
Le service est dorénavant activé via un socket. Le socket ne peut pas démarré parce que le port est utilisé par le service lui-même.

Ce problème n’est pas reproduit en toutes circonstances…

Paramétrage de python3-pyeole (2.11.0-2~dev+2~g14de729) ...
/usr/lib/python3/dist-packages/pyeole/bareos.py:376: SyntaxWarning: 'return' in a 'finally' block
  return mount_bareos_support(retry=attempt-1, chown=chown)

=> #37522

Le nouveau pager par défaut des commandes apt n’est pas configuré (compatible ?) pour la coloration.

Pour le désactiver (en attendant de voir comment ça se configure) :

Binary::apt::Pager "false";

Dans l’environnement de test automatisé, l’instance du module Eolebase échoue avec un problème d’allocation mémoire. Pour l’instant, ce problème n’a pas été reproduit dans les tests manuels.
Quand on observe la mémoire utilisée par salt, notamment lors de l’enregistrement des modules qui correspond à un pic, on constate que la procédure est très gourmande en ressources.

On peut tester si donner davantage de mémoire au module pallie le problème (à voir si l’augmentation nécessaire est raisonnable). Sinon, il faut voir si les ressources de salt peuvent être limitées (via systemd à défaut ?).