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

Bien sûr :

root@$$$$$$:~# systemctl restart fail2ban
root@$$$$$$:~# systemctl status fail2ban | cat
● fail2ban.service - Fail2Ban Service
   Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2018-08-13 14:54:15 CEST; 2s ago
     Docs: man:fail2ban(1)
  Process: 5398 ExecStop=/usr/bin/fail2ban-client stop (code=exited, status=0/SUCCESS)
  Process: 5432 ExecStart=/usr/bin/fail2ban-client -x start (code=exited, status=0/SUCCESS)
 Main PID: 5436 (fail2ban-server)
   CGroup: /system.slice/fail2ban.service
           └─5436 /usr/bin/python3 /usr/bin/fail2ban-server -s /var/run/fail2ban/fail2ban.sock -p /var/run/fail2ban/fail2ban.pid -x -b

Aug 13 14:54:12 $$$$$$.$$$$$$.eu systemd[1]: Starting Fail2Ban Service...
Aug 13 14:54:13 $$$$$$.$$$$$$.eu fail2ban-client[5432]: 2018-08-13 14:54:13,725 fail2ban.server         [5434]: INFO    Starting Fail2ban v0.9.6
Aug 13 14:54:13 $$$$$$.$$$$$$.eu fail2ban-client[5432]: 2018-08-13 14:54:13,725 fail2ban.server         [5434]: INFO    Starting in daemon mode
Aug 13 14:54:15 $$$$$$.$$$$$$.eu systemd[1]: Started Fail2Ban Service.

Si ça peut aider, voici le résultat d’un apt-get upgrade simulé :

root@$$$$$$:~# apt-get upgrade -s
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
  libmilter1.0.1 libmysqlclient18 libopendkim9 php5-curl php5-fpm php5-ldap php5-mysql rmilter
Use 'apt autoremove' to remove them.
The following packages have been kept back:
  gnupg python-gnupg
The following packages will be upgraded:
  metronome
1 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
3 not fully installed or removed.
Inst metronome [3.9.10+yunohost-1] (3.9.20+yunohost-1 YunoHost for Stretch:9.0/stable [amd64])
Conf metronome (3.9.20+yunohost-1 YunoHost for Stretch:9.0/stable [amd64])
Conf fail2ban (0.9.6-2 Debian:9.5/stable [all])
Conf yunohost (3.0.0.1 YunoHost for Stretch:9.0/stable [all])
Conf yunohost-admin (3.0.0 YunoHost for Stretch:9.0/stable [all])

Tu peux tenter un apt install -f ?

Bien sûr !
Voila le résultat
Je note le soucis avec fail2ban, et pour la suite que la conf nginx de yunohost_admin.conf ainsi que de mon domaine principale n’ont pas été mis a jour.

J’ai de nouveau accès a l’admin, ainsi qu’au webmail.
Voici l’état des services:

"services": {
    "glances": "running (enabled)",
    "nslcd": "running (enabled)",
    "metronome": "running (enabled)",
    "postfix": "exited (enabled)",
    "rspamd": "running (enabled)",
    "transmission-daemon": "running (enabled)",
    "yunohost-firewall": "exited (enabled)",
    "nginx": "running (enabled)",
    "php7.0-fpm": "running (enabled)",
    "dnsmasq": "running (enabled)",
    "fail2ban": "running (enabled)",
    "yunohost-api": "running (enabled)",
    "mysql": "running (enabled)",
    "avahi-daemon": "running (enabled)",
    "dovecot": "running (enabled)",
    "redis-server": "running (enabled)",
    "slapd": "running (enabled)",
    "ssh": "running (enabled)"
},

Postfix et yunohost-firewall sont toujours en exited, mais je ne sais pas si c’est un soucis ou pas.

Y a-t-il d’autres actions que je puisse prendre pour m’assurer que la migration est complète ?
Merci !

Nope, ce n’est pas un probleme, c’est la situation normale :+1:. Ils tournent quand même :+1:

Un yunohost --version et lsb_release -a devrait montrer que tu es sous Yunohost 3.x et Debian 9.

J’aime beaucoup cette discussion.

@m_t prend le temps d’expliquer la situation, et @frju365 et @Aleks prennent du coup, le temps de trouver des réponses.

Ce n’est pas un sujet qui me concerne, mais j’ai quand même eu plaisir à le lire.

2 Likes

Les deux commandes me donnent les bons résultats !

root@$$$$$$:~# yunohost --version
yunohost:
  repo: stable
  version: 3.0.0.1
yunohost-admin:
  repo: stable
  version: 3.0.0
moulinette:
  repo: stable
  version: 3.0.0
ssowat:
  repo: stable
  version: 3.0.0
root@$$$$$$:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 9.5 (stretch)
Release:        8
Codename:       stretch

Avant de conclure, en faisant un diagnostic détaillé j’ai la liste des configs mises a jour a la main. Est-ce que vous pensez que le fait que /etc/nslcd.conf et /etc/resolv.dnsmasq.conf soit un probleme ?

Merci !

Hmmmm à voir, ça dépends un peu des différences exactes. Tu peux inspecter ça avec yunohost service regen-conf --dry-run -d (pour montrer les différences)

1 Like

OK, de ce que je pige de la sortie de cette commande, c’est que les confs nginx modifiées le sont pour tout ce qui est ssl (probablement un reste de mes modifs specifique a Let’s Encrypt, datant d’avant le support par YNH), y compris pour la conf de yunohost_admin.

Idem pour nslcd:

nslcd:
  applied:
  pending:
    /etc/nslcd.conf:
      diff: @@ -23,4 +23,3 @@

 # The minimum numeric user id to lookup.
 nss_min_uid 1000
-tls_cacertfile /etc/ssl/certs/ca-certificates.crt
      status: modified

Et pour Dnsmasq, il s’agit de liste d’IP:

dnsmasq:
  applied:
    /etc/resolv.dnsmasq.conf:
      diff: @@ -1,13 +1,13 @@
+nameserver 89.234.141.66
+nameserver 84.200.69.80
+nameserver 89.234.186.18
+nameserver 89.233.43.71
+nameserver 80.67.188.188
+nameserver 84.200.70.40
+nameserver 213.73.91.35
+nameserver 85.214.20.141
+nameserver 141.255.128.101
+nameserver 91.239.100.100
 nameserver 141.255.128.100
-nameserver 80.67.188.188
-nameserver 84.200.69.80
-nameserver 84.200.70.40
 nameserver 80.67.169.40
-nameserver 141.255.128.101
-nameserver 213.73.91.35
-nameserver 91.239.100.100
-nameserver 85.214.20.141
-nameserver 89.233.43.71
 nameserver 80.67.169.12
-nameserver 89.234.186.18
-nameserver 89.234.141.66
      status: updated

Tout me semble correct donc!

1 Like

Ouaip ça a l’air bon ! (Pour dnsmasq, au final il regenere a chaque fois une liste de DNS différent, c’est “attendu” meme si en fait c’est pas optimal - on taffe dessus)

Génial !

Alors, pour résumer, on a fait :

  • Copier la config fail2ban qui avait disparue via cp -r /etc/fail2ban.old/ /etc/fail2ban/
  • Relancer la migration
  • Relancer dnsmasq qui était dans les choux via systemctl restart dnsmasq
  • Modifier l’historique des migrations a la main dans /etc/yunohost/migrations_state.json
  • Relancer la migration
  • Régénérer la config de fail2ban via yunohost service regen-conf fail2ban --force
  • Régénérer la config de Yunohost (je ne sais pas si ça a été utile au final) via yunohost service regen-conf yunohost --force
  • Finir d’installer les updates via apt install -f
  • Et voila !

Après ça, tout semble fonctionner !

Merci beaucoup a tous pour votre aide.

3 Likes