Ben la migration c’est pas au point les ptis gars :p

Support
1

My YunoHost server

Hardware: Olimex lime 2 with vpn
YunoHost version: 3.8.6 a 4.0
I have access to my server : tout
Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : no

La migration devrait d’abord contrôler la présence du mot de passe root ou même obliger à le réentrer car en cas de perte de problème…

Ma migration qui n’est pas sur une installation super particulière, a raté au niveau de l’upgrade des package. Donc relativement tôt dans le processus.
J’ai du coup engagé l’upgrade apt manuellement. Je n’ai bizarrement pas eu de soucis du coup, sauf à la toute fin avec sysfs.

Toutes les connexions ont été rompues évidemment. Sauf le ssh. Mais comme je n’ai pas continué directement, j’ai perdu la connexion. Fatalement du au changement des fichier de config openssh le root n’est plus accepté donc il a fallu que j aille sur l appareil lui même pour réautoriser l accès root en ssh. Plusieurs connexion vpn les mêmes se sont superposées aussi ce qui veut dire qu’un arrêt total du vpn durant une migration serait une bonne idée car sinon perte de connectivité par un trop plein de route les mêmes ( sauf en ce qui concerne l’interface)…

Heureusement que j’ai eu la présence d’esprit d’à jaque fois faire un .back pour chaque fichier de configuration que apt voulait changer. Il faudrait inclure d’office une fonctionnalité comme celle là dans un script de migration. Ne pas compter seulement sur le fait que l’utilisateur ait fait un backup. Un backup peut être partiel, incomplet pour x dizaines de raisons, etc.

Selon moi le script de migration devrait être en plusieurs partie et devrait pouvoir être relancé par étape.

ici le log de d’échec de départ.
https://paste.yunohost.org/raw/buhewizana

ici le dernier problème apt

After this operation, 0 B of additional disk space will be used.
Setting up sysfsutils (2.1.0+repack-5) ...
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
Job for sysfsutils.service failed because the control process exited with error code.
See "systemctl status sysfsutils.service" and "journalctl -xe" for details.
invoke-rc.d: initscript sysfsutils, action "restart" failed.
● sysfsutils.service - LSB: Set sysfs variables from /etc/sysfs.conf
   Loaded: loaded (/etc/init.d/sysfsutils; generated)
   Active: failed (Result: exit-code) since Sat 2020-08-01 15:35:24 UTC; 164ms ago
     Docs: man:systemd-sysv-generator(8)
  Process: 7972 ExecStart=/etc/init.d/sysfsutils start (code=exited, status=1/FAILURE)

Aug 01 15:35:23 dev.consulting.net systemd[1]: Starting LSB: Set sysfs variables from /etc/sysfs.conf...
Aug 01 15:35:24 dev.consulting.net sysfsutils[7972]: Setting sysfs variables.../etc/init.d/sysfsutils: 50: echo: echo: I/O error
Aug 01 15:35:24 dev.consulting.net systemd[1]: sysfsutils.service: Control process exited, code=exited, status=1/FAILURE
Aug 01 15:35:24 dev.consulting.net systemd[1]: sysfsutils.service: Failed with result 'exit-code'.
Aug 01 15:35:24 dev.consulting.net systemd[1]: Failed to start LSB: Set sysfs variables from /etc/sysfs.conf.
dpkg: error processing package sysfsutils (--configure):
 installed sysfsutils package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 sysfsutils
E: Sub-process /usr/bin/dpkg returned an error code (1)

Sachant que le fichier de config est

    #
    # /etc/sysfs.conf - Configuration file for setting sysfs attributes.
    #
    # The sysfs mount directory is automatically prepended to the attribute paths.
    #
    # Syntax:
    # attribute = value
    # mode attribute = 0600 # (any valid argument for chmod)
    # owner attribute = root:wheel # (any valid argument for chown)
    #
    # Examples:
    #
    # Always use the powersave CPU frequency governor
    # devices/system/cpu/cpu0/cpufreq/scaling_governor = powersave
    # 
    # Use userspace CPU frequency governor and set initial speed
    # devices/system/cpu/cpu0/cpufreq/scaling_governor = userspace
    # devices/system/cpu/cpu0/cpufreq/scaling_setspeed = 600000 
    #
    # Set permissions of suspend control file 
    # mode power/state = 0660
    # owner power/state = root:power
      
    block/mmcblk0/queue/scheduler = noop
    #block/sda/queue/scheduler = cfq

EDIT:
visiblement noop n’a plus l’air d’être accepté comme scheduler I/O mais je n’ai trouvé aucune référence concernant ce changement et il semble que ce soit même cantonné à debian puisque ubuntu reprend encore les référence noop (noop qui n’est pas équivalent à none pour info comme signaler ici

Je l’ai temporairement remplacé par none mais si quelqu’un sait par quoi remplacé noop dans le cadre d’une carte SD pour améliorer la longévité de cette carte SD ce serait sympa?

EDIT2:
Dans la seconde partie de la migration
Ca serait bien que ne fut-ce que sur l’interface web, on est une partie réservée aux fichiers de référence qui étaient censés être modifiés et qui ne l’ont donc pas été.

The configuration file '/etc/nslcd.conf' has been manually modified and will not be updated
Configuration updated for 'yunohost'
The configuration file '/etc/resolv.dnsmasq.conf' has been manually modified and will not be updated
The configuration file '/etc/fail2ban/jail.conf' has been manually modified and will not be updated
The configuration file '/etc/fail2ban/jail.d/yunohost-jails.conf' has been manually modified and will not be updated
Configuration updated for 'dovecot'
Configuration updated for 'nsswitch'
The configuration file '/etc/ldap/schema/mailserver.schema' has been manually modified and will not be updated
The configuration file '/etc/ldap/schema/sudo.schema' has been manually modified and will not be updated
The configuration file '/etc/ssh/sshd_config' has been manually modified and will not be updated
Could not run script: /usr/share/yunohost/hooks/conf_regen/43-dnsmasq

Dans ce cas-ci il y a quand même une certaine quantité de fichiers liés à la sécurité, et parce qu’ils ont été modifiés manuellement, je ne peux donc pas savoir ce que yunohost avait prévu comme template de ces fichiers. Or si j’avais directement accès à cette information dans ma partie admin, je pourrais comparer et les modifier à dessin ou en tout cas évaluer la nécessité de les faire évoluer ou non.

Visiblement il y a aussi un problème au niveau de la migration de la db postgres (dont je n’ai pas encore les connaissance de savoir où elle se trouve dans la hiérarchie de l’infra yunohost et donc son utilité).

Migration 0016_php70_to_php73_pools completed
Running migration 0017_postgresql_9p6_to_11...
grep: write error: Broken pipe
grep: write error: Broken pipe
Cluster is not running.
Error: could not stop server, aborting
Migration 0017_postgresql_9p6_to_11 did not complete, aborting. Error: Command 'pg_dropcluster --stop 11 main' returned non-zero exit status 1

ici pour ce qui est du log qui n’apporte que peu de réponse

Est-ce dû au fait que j’aie dû faire un apt dist-upgrade manuellement et qu’il a donc upgrade la db via apt et casser tout le processus, sans plus d’informations je ne saurais dire.

pas encore de solution pour la migration de psotgres, c’est la seule qui est en mode pending apparemment.

    root@dev:/usr/lib/moulinette/yunohost/data_migrations# yunohost tools migrations migrate 
    Info: Running migration 0017_postgresql_9p6_to_11...
    grep: write error: Broken pipe
    grep: write error: Broken pipe
    Cluster is not running.
    Error: could not stop server, aborting
    Error: Migration 0017_postgresql_9p6_to_11 did not complete, aborting. Error: Command 'pg_dropcluster --stop 11 main' returned non-zero exit status 1
    Info: The operation 'Run migrations' could not be completed. Please share the full log of this operation using the command 'yunohost log display 20200802-011903-tools_migrations_migrate_forward --share' to get help

Je mettrai à jour ce thread au fur et à mesure du debug

2

Le mot de passe root est synchronisé avec celui d’admin depuis plusieurs versions maintenant (donc sauf si tu as toi-même rechangé le mot de passe root derrière, il n’est pas censé y’avoir de soucis de ce côté…). (Enfin en écrivant ces lignes je réalise que ptete si tu as restauré ton système ptete il a pas repropagé le truc sur le mot de passe root ~.~)

De ce que je peux voir dans le log que tu partages plus loin, c’était un soucis “temporaire” (?) de téléchargement de fichier, donc pas sur que ce soit le fait d’avoir relancé manuellement qui ai changé un truc. Relancer la migration normalement aurait pu marcher …

Pas compris pourquoi “évidemment”, c’est pas spécialement attendu que les connexions soient rompues pendant l’upgrade … (enfin le mot “connexion” est un peu flou là)

Pas compris pourquoi la conf ssh a été changé non plus

Il n’y a pas besoin de faire un backup des fichiers de conf puisque la commande apt dans la migration précise de ne pas changer les fichiers de conf (c.f. l’option --force-confold) mais forcément si tu lances à la main tu met généralement pas toute la panoplie d’option qui va bien et il te pose des questions tu garder l’ancien fichier de conf ou mettre le nouveau … M’enfin dans tout les cas après coup tu peux remettre le système d’équerre avec yunohost tools regen-conf …

Oui c’est déjà le cas, dans le sens où la migration peut très bien être relancé si elle a échoué (et c’est même conseillé par la doc) et il ne refera pas ce qui a déjà été fait.

Et pour ce qui est de sysfsutils et noop ça a l’air d’être des trucs pas dans le setup standard donc je sais pas trop quoi te dire là dessus

1 Like
3

:roll_eyes:

Oui, tu peux aller dans la partie diagnostic et tu verras que yunohost te propose des commandes à coup de yunohost tools regen-conf --dry-run --with-diff pour voir le diff …

4

J’avais dû le changer car dès la première install qui s’est faite via le script d’installation de l’association neutrinet, le mot de passe root n’avait pas été la calque de celui d’admins justement à mon grand étonnement ce qui m’avait provoqué une grande phase de stress à ce moment-là. Donc je ne sais pas ce qu’il y a de différent mais je sais que la fusion des mots de passe n’est pas effective partout.

5

dans le cas du vpn? vu qu’il y a un restart de ce service justement…

6

parce que lors de l’apt dist-upgrade fatalement il m’a demandé de savoir si j’installais ou pas le fichier du maintainer, ce à quoi j’ai dit oui (pour la 10 de fois que le process m’a posé la question pour les différents fichiers, j’ai analysé à chaque fois la question au cas par cas). Et j’ai dit oui car pour avoir déjà eu des soucis par le passé avec debian ou ubuntu ou fedora sur les fichiers de config ssh je préfère repartir du template du maintainer. Chose qui m’évite quand même parfois des soucis, style le souci que je viens d’avoir avec le scheduler I/O.
Après je reprends les options de l’ancien fichier de config et je vois si elles sont toujours d’actualité.

7

Alors je regarderai plus en détail cette commande après sachant que je ne sais pas ce qui a été changé dans l’install de neutrinet de base par rapport à yunohost de base et mes changements que ceux-là je connais qui se trouvaient dans fail2ban exclusivement.

8

je vois aussi avec étonnement qu’il y a toujours le bug ssh alors qu’il parait que ce bug est résolu d’après des les maintainer
et ça c’est quand même dommage

Aug  1 16:58:55 dev sshd[5580]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=109.x.x.x  user=admin
Aug  1 16:58:56 dev sshd[5580]: Accepted password for admin from 109.x.x.x port 34100 ssh2
Aug  1 16:58:56 dev sshd[5580]: pam_unix(sshd:session): session opened for user admin by (uid=0)
Aug  1 16:58:56 dev systemd-logind[822]: New session 5 of user admin.
Aug  1 16:58:57 dev systemd: pam_unix(systemd-user:session): session opened for user admin by (uid=0)

et donc ceci est post-migration

9

Pas compris de quel bug tu parles ni de quels mainteneur tu parles …

10

@Aleks
J’ai déjà parlé à plusieurs reprises sur ce même forum du bug que je viens de remettre en lumière avec mon copy paste. c’est l’authentification failure qui ne devrait pas se produire puisque la session est accepté. Les maintainers dont je parle sont bien entendus ceux de debian-ssh mailing list. Plusieurs tickets avaient été ouvert au fil des années si tu fais une recherche google dessus tu retomberas dessus facilement.

Et comme je l’exprimais dans ce thread par exemple, c’est quelque chose de récurrent et fort problématique puisque ça a une capacité de nuisance couplée avec fail2ban très importante.

11

par contre si tu pouvais me dire en deux mots à quoi sert la db postgres qui est installée, si elle est essentielle aux systmes ou bien si c’est par rapport à certaines des applis qui sont installées sur mon système, ça me serait bien utile que je commence à visualiser comment je peux essayer de la sauver et de la réparer

12

Mouaip … j’ai pas moulte creusé mais de ce que j’en comprends ça a l’air vraiment lié au client ssh que tu utilises … en tout cas j’ai pas vu des masses de personnes rapporter ce même genre de problème …

13

C’est pas rapport aux applis installées sur ton système … pas spécialement de moyen simple de savoir lequelles sauf à regarder les dépendances de tous les paquets en -ynh-deps installé et/ou en regardant les scripts d’install des apps installées …

Mais de manière générale y’a plusieurs petits soucis rapportés par les gens à propos de cette migration de postgresql bien que je pige pas trop pourquoi car c’est la même procédure que pour 9.4->9.6 lors de la migration jessie->stretch et ça avait plutôt bien marché … :[

14

okey donc pour l’intégrité du système ça ça va ça ne rentre pas en jeu c’est vraiment par rapport aux différentes apps, donc ça je peux prendre un peu plus de temps pour investiguer du coup.

ce n’est que sur windows pour te rassurer déjà et ça concerne TOUS les clients sous windows. Que ce soit le client ssh made in microsoft, putty, termius, terminus et je ne sais encore lesquels.
Tu peux voir qu’en effet il n’y a pas tellement de gens qui le rapportent mais à travers le monde il y en a quand même, signe qu’il y a donc un souci. Et si tu as le temps de regarder proprement le ticket fait en 2017 je pense à ce propos, c’est un problème entre pam et le daemon sshd. Alors certes c’est peut-être une mauvaise implémentation du protocole sous windows mais windows représente encore plus de 80% de part de marché à ma connaissance donc… Et malheureusement je pense que ce bug n’est plus présent que sur le 32bits de arm debian et pas x86-64 du coup il y a encore moins de gens concernés puisque mes serveurs debian x86-64 eux n’ont de ce que j’ai vu pas ce problème.
Donc si jamais tu as le temps de faire un ticket (ce que je ferai aussi) ou de poser la question sur la mailing list ce serait cool.

15

pour ce qui est des apps, à priori celles qui sont concernées par le problèmes postgres sont lutim, lstu, lufi et jupyterlab

16

@Alekstu as quelques références de personnes qui ont rencontré les soucis avec postgres par rapport à la migration ?
Que je cherche pas des heures pour identifier les éventuels problèmes?

PArce que si je vois bien il y a la version 11 et 9.6 et tous les deux sont active et y en a aucun en failed donc je comprends pas bien où s’est passé le problème de migration du coup si les deux fonctionnent…

17

Vraissemblablement pour postgres, le problème c’est que votre script ne prend pas en compte si l’ancien cluster est down. Il suffisait donc de le relancer.

Ceci dit il y a toujours les deux grep error au début de votre script qui viennent donc d’un de vos import dans votre script python je sais pas lequel mais ça serait bien d’y regarder de plus prêt. Et il faut donc rajouter un if à votre script python dans le cas où le cluster 9.6 ici, est down pour d’abord le relancer.

18

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.