Problème de migration vers YNH3.0 et Debian Stretch

Support
1

Configuration de mon YunoHost

Matériel: x64 kimsufi
Accès Internet: datacenter
YunoHost version:
yunohost: 2.7.14.5
debian: stretch (après migration)

Administration via l’admin Web en générale, sauf pour problèmes (avec les certif lets encrypt précédemment).

Description de mon problème

Salut,
Je viens de tenter la mise a jour vers YNH 3.0 et Debian Stretch via la ligne de commande. Debian est bien passé sur stretch, mais la mise a jour a plantée au moment de s’occuper de ynh.
Voici le message d’erreur:

Warning: Starting the yunohost package upgrade ... The migration will end, but the actual upgrade will happen right after. After the operation is complete, you might have to re-log on the webadmin.
Error: Migration 3 migrate_to_stretch has failed with exception [Errno 2] No such file or directory: '/etc/fail2ban/filter.d/yunohost.conf', aborting

En faisant une recherche sur le forum, j’ai trouvé un message dans les feedbacks sur la beta ou la personne a eu le même soucis, a relancé la migration, et tout semblait résolu.
J’ai tenté la même chose, mais pas de chance le même message revient.

En tentant de chercher le répertoire de fail2ban, je me rends compte que /etc/fail2ban/ n’existe plus, mais que /etc/fail2ban.old/ est bien la.

Que me conseillez vous de faire? Simplement renommer le répertoire et retenter ?
Merci !

2

Tente :
cp -r /etc/fail2ban.old/ /etc/fail2ban/

Ensuite, retente la migration.

Vérifie tout de même que le paquet fail2ban existe toujours, et qu’il n’ait pas été supprimé au cours de l’une des migrations.

1 Like
3

Merci pour la réponse.

J’ai fait ça et ait relancé la migration.
Il semble que ça se soit mieux passé, mais je pense qu’il reste quelques soucis. Je me prends pleins d’erreurs en ce qui concerne la récupération des paquets.
Log complet de la migration
Un exemple d’erreur:

The following NEW packages will be installed:
  libzip4 php-apcu php-apcu-bc php-curl php-fpm php-gd php-intl php-mcrypt
  php-mysql php-zip php7.0-curl php7.0-fpm php7.0-gd php7.0-intl php7.0-mcrypt
  php7.0-mysql php7.0-zip unscd
The following packages will be upgraded:
  moulinette ssowat yunohost yunohost-admin
4 upgraded, 18 newly installed, 1 to remove and 3 not upgraded.
Need to get 11.0 MB of archives.
After this operation, 5,877 kB of additional disk space will be used.
Ign:1 http://security.debian.org stretch/updates/main amd64 php7.0-fpm amd64 7.0.30-0+deb9u1
Ign:2 http://security.debian.org stretch/updates/main amd64 php7.0-curl amd64 7.0.30-0+deb9u1
Ign:3 http://security.debian.org stretch/updates/main amd64 php7.0-gd amd64 7.0.30-0+deb9u1
Err:4 http://forge.yunohost.org/debian stretch/stable amd64 yunohost all 3.0.0.1
  Could not resolve 'forge.yunohost.org'
Err:5 http://debian.mirrors.ovh.net/debian stretch/main amd64 libzip4 amd64 1.1.2-1.1+b1
  Could not resolve 'debian.mirrors.ovh.net'
Err:6 http://debian.mirrors.ovh.net/debian stretch/main amd64 php-apcu amd64 5.1.8+4.0.11-1
  Could not resolve 'debian.mirrors.ovh.net'
Err:7 http://debian.mirrors.ovh.net/debian stretch/main amd64 php-apcu-bc amd64 1.0.3-2
  Could not resolve 'debian.mirrors.ovh.net'
Err:8 http://debian.mirrors.ovh.net/debian stretch/main amd64 php-curl all 1:7.0+49
  Could not resolve 'debian.mirrors.ovh.net'
Ign:9 http://security.debian.org stretch/updates/main amd64 php7.0-intl amd64 7.0.30-0+deb9u1
Ign:10 http://security.debian.org stretch/updates/main amd64 php7.0-mcrypt amd64 7.0.30-0+deb9u1
Ign:11 http://security.debian.org stretch/updates/main amd64 php7.0-mysql amd64 7.0.30-0+deb9u1
Ign:12 http://security.debian.org stretch/updates/main amd64 php7.0-zip amd64 7.0.30-0+deb9u1
Err:13 http://forge.yunohost.org/debian stretch/stable amd64 unscd amd64 0.53-1+yunohost

De plus, yunohost ne semble pas s’être mis a jour comme il faut:

yunohost --version
yunohost:
  repo: now
  version: 2.7.14.5
yunohost-admin:
  repo: now
  version: 2.7.14
moulinette:
  repo: now
  version: 2.7.14
ssowat:
  repo: now
  version: 2.7.14

Quelques idées ?
Est-ce que cela peut venir du fait que mon serveur est un Kimsufi?

4

Est-ce que tu peux vérifier que dnsmasq tourne bien avec systemctl status dnsmasq ? Si il ne tourne pas, tente un systemctl restart dnsmasq puis refait un status (avec la commande d’avant)

5

C’était bien le probleme, merci ! J’étais en train de tester un ping qui me marchait pas avec un ndd mais fonctionnait avec une ip.

Est-il safe de retenter la migration ou faut-il faire une manip spécifique ?
Merci !

6

Maintenant tu peux relancer la migration je pense :wink:

7

Mince, je me prends un

Warning: No migrations to run

Mais yunohost est toujours en en 2.7.14 via yunohost --version

8

Arf bon … On peut lui dire de revenir en arrière je pense, avec genre yunohost tools migrations migrate -t 2

9

Juste pour ne pas faire de bêtises… J’ai souvenir d’avoir eu 3 opérations migrations en tout (la troisième étant celle vers ynh 3.0).
Est-ce que je devrais faire yunohost tools migrations migrate -t 3 dans ce cas?

Edit: l’admin fonctionne encore, je vois dans les migrations précédentes:

3. migrate to stretch
2. migrate to tsig sha256
1. change cert group to sslcert
10

Je ne sais plus exactement, mais il me semble qu’il faut lui dire de revenir à l’état “après la deuxieme migration” (d’où le -t 2) pour pouvoir relancer la troisieme … mais je me trompe peut-être (normalement ça ne casse rien d’essayer)

11

OK, cette fois ci j’ai ce message d’erreur:

yunohost tools migrations migrate -t 2 --accept-disclaimer
Warning: Running migration 3 migrate_to_stretch...
Error: Migration 3 migrate_to_stretch has failed with exception The stretch migration cannot be reverted., aborting
12

Zblerf, et si tu rajoutes --skip ?

13

Ça me donne Warning: Skipping migration 3 migrate_to_stretch...

14

Oké, donc là tu devrais pouvoir relancer :wink:

15

Ah, malheureusement je prends toujours:

root@$$$$$$:~# yunohost tools migrations migrate --accept-disclaimer
Warning: No migrations to run
16

Bon on va la faire autrement …

Edite le fichier /etc/yunohost/migrations_state.json avec la commande nano /etc/yunohost/migrations_state.json

Dedans, remplate le chiffre après last_run_migration ... number : par 2, et le truc après name par migrate_to_tsig_sha256

Ensuite retente la migration :s

Edit: dans nano tu peux quitter+enregistrer avec Ctrl+X, Y (pour Yes) puis entrée pour confirmer le fichier à écrire

1 Like
17

Ça avance :grinning: !

Log de la migration
J’ai des erreurs fail2ban qui se sont glissées ça et là, et le service semble down pour le moment.
Exemple d’erreur dans le log qui me font me poser des questions:

dpkg: dependency problems prevent configuration of yunohost:
 yunohost depends on fail2ban; however:
  Package fail2ban is not configured yet.

YNH est bien updaté en 3.0 par contre, le portail semble fonctionner et l’admin aussi. La seule app qui semble down est Roundcude, qui me lance un Connection to storage server failed

Je tente de débugger fail2ban:
Pour systemctl status fail2ban.service

● fail2ban.service - Fail2Ban Service
   Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Mon 2018-08-13 10:57:17 CEST; 30s ago
     Docs: man:fail2ban(1)
  Process: 23331 ExecStart=/usr/bin/fail2ban-client -x start (code=exited, status=255)

Aug 13 10:57:16 $$$$$$.$$$$$$.eu systemd[1]: fail2ban.service: Unit entered failed state.
Aug 13 10:57:16 $$$$$$.$$$$$$.eu systemd[1]: fail2ban.service: Failed with result 'exit-code'.
Aug 13 10:57:17 $$$$$$.$$$$$$.eu systemd[1]: fail2ban.service: Service hold-off time over, scheduling restart.
Aug 13 10:57:17 $$$$$$.$$$$$$.eu systemd[1]: Stopped Fail2Ban Service.
Aug 13 10:57:17 $$$$$$.$$$$$$.eu systemd[1]: fail2ban.service: Start request repeated too quickly.
Aug 13 10:57:17 $$$$$$.$$$$$$.eu systemd[1]: Failed to start Fail2Ban Service.
Aug 13 10:57:17 $$$$$$.$$$$$$.eu systemd[1]: fail2ban.service: Unit entered failed state.
Aug 13 10:57:17 $$$$$$.$$$$$$.eu systemd[1]: fail2ban.service: Failed with result 'exit-code'.

Merci beaucoup pour l’aide, je sens qu’on approche :smile:

Petit Edit:
J’ai fait un yunohost service regen-conf fail2ban --force qui semble avoir résolu le soucis pour fail2ban:

active: active
active_at:
  human: 2018-08-13 11:07:39
  timestamp: 1534151259038650
description: protects against bruteforce and other kind of attacks from the Internet
loaded: enabled
service_file_path: /lib/systemd/system/fail2ban.service
status: running

En revanche, l’admin semble ne pas se charger correctement (Loading et petit pacman qui reste sur place).
En regardant ce qu’il se passe, le call /yunohost/api/users?locale=en me retourne une 500 Unable to reach LDAP server

18

est-ce que le service slapd est lancé ?
service slapd status et tente un start s’il n’est pas lancé.

19

Yep, il a l’air de tourner:

● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)
   Loaded: loaded (/etc/init.d/slapd; generated; vendor preset: enabled)
   Active: active (running) since Sun 2018-08-12 16:12:08 CEST; 19h ago
     Docs: man:systemd-sysv-generator(8)
   CGroup: /system.slice/slapd.service
           └─31562 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u openldap -F /etc/ldap/slapd.d

Aug 13 10:47:30 $$$$$$.$$$$$$.eu slapd[31562]: <= mdb_equality_candidates: (memberUid) not indexed
Aug 13 10:47:44 $$$$$$.$$$$$$.eu slapd[31562]: <= mdb_equality_candidates: (uidNumber) not indexed
Aug 13 10:47:44 $$$$$$.$$$$$$.eu slapd[31562]: slap_global_control: unrecognized control: 1.3.6.1.4.1.4203.666.5.16
Aug 13 10:47:44 $$$$$$.$$$$$$.eu slapd[31562]: <= mdb_equality_candidates: (gidNumber) not indexed
Aug 13 11:07:34 $$$$$$.$$$$$$.eu slapd[31562]: <= mdb_equality_candidates: (cn) not indexed
Aug 13 11:07:35 $$$$$$.$$$$$$.eu slapd[31562]: <= mdb_equality_candidates: (sudoUser) not indexed
Aug 13 11:07:35 $$$$$$.$$$$$$.eu slapd[31562]: <= mdb_equality_candidates: (sudoUser) not indexed
Aug 13 11:07:35 $$$$$$.$$$$$$.eu slapd[31562]: <= mdb_equality_candidates: (sudoUser) not indexed
Aug 13 11:07:35 $$$$$$.$$$$$$.eu slapd[31562]: <= mdb_equality_candidates: (sudoUser) not indexed
Aug 13 11:07:35 $$$$$$.$$$$$$.eu slapd[31562]: <= mdb_substring_candidates: (sudoUser) not indexed

Le seul service qui semble différent des autres est Yunohost firewall, il est en status exited:

yunohost-firewall:
  active: active
  active_at:
    human: 2018-08-13 11:20:15
    timestamp: 1534152015025785
  description: manages open and close connexion ports to services
  loaded: enabled
  service_file_path: /lib/systemd/system/yunohost-firewall.service
  status: exited

Edit:

Comme les erreurs de conf lors de la migration concernaient yunohost et yunohost admin, j’ai tenté ceci:

root@$$$$$$:/etc/yunohost#  yunohost service regen-conf yunohost --force
root@$$$$$$:/etc/yunohost#  yunohost service regen-conf yunohost-admin --force
Error: Unable to regenerate the configuration for service(s):

Le premier semble être passé mais pas le deuxième.

20

Hmmm tu saurais faire un systemctl restart fail2ban puis un systemctl status fail2ban | cat pour vérifier quelles sont les erreurs si il y en a toujours ?