Passage en "Testing" suite migration

Bonjour,

Mon serveur YunoHost

Matériel: VPS OVH
Version de YunoHost: 11.1.0.2
J’ai accès à mon serveur : En SSH
Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : non
Si oui, expliquer:

Description du problème

J’ai fait la migration d’un serveur Yunohost il y a quelques jours via la commande
yunohost tools migrations run
Tout s’est bien passé mais je me retrouve à l’issu en Testing , plus exactement YunoHost 11.1.0.2 (testing). Ce n’était pas un souhait de ma part s’agissant d’un serveur de production.

Système de base
L’architecture du serveur est kvm amd64
Le modèle/architecture du serveur est OpenStack Foundation OpenStack Nova
Le serveur utilise le noyau Linux 4.19.0-16-amd64
Le serveur utilise Debian 11.5
Le serveur utilise YunoHost 11.1.0.2 (testing)
yunohost version : 11.1.0.2 (testing)
yunohost-admin version : 11.1.0.2 (testing)
moulinette version : 11.0.9 (testing)
ssowat version : 11.0.9 (testing)

nano /etc/apt/sources.list.d/yunohost.list
deb Index of /debian/ bullseye stable

S’agit-il d’une erreur de ma part ? Comment revenir sur une version stable ?

Merci par avance,

Revenir sur une version stable n’est je pense pas possible, par contre tu peux dire à ton serveur de ne plus accepter que les mises à jour stables.

Tout est indiqué dans le diagnostique du serveur (qui a du t’envoyer des mails pour te dire que tu étais en testing, ou alors c’est la 11.1 qui apporte ça, mais vu que maintenant tu y es, tu dois l’avoir).

apt (the system’s package manager) is currently configured to install any ‘testing’ upgrade for YunoHost core.

This is probably OK if you know what you are doing, but pay attention to the release notes before installing YunoHost upgrades! If you want to disable ‘testing’ upgrades, you should remove the testing keyword from /etc/apt/sources.list.d/yunohost.list.

Voilà le message que j’ai (je suis aussi passé en testing sans trop faire attention, j’étais volontairement passé en testing pour la version 11.0 et j’avais oublié de repasser en stable)

Bonjour @Mamie

Merci de ta réponse

Je n’ai pas reçu de mail pour me dire que j’étais en testing et tous mes serveurs étaient en version stable avant l’upgrade sont désormais en testing (je viens de vérifier). Il y en a 4 ce qui me laisse perplexe sur une éventuelle erreur d’administration.

J’ai justement placé mon /etc/apt/sources.list.d/yunohost.list dans le message initial et aucune trace de “testing”
J’ai ceci : deb Index of /debian/ bullseye stable
Mon fichier yunohost.list est-il cohérent ?

ça s’est passé à 14h18 aujourd’hui

/etc/cron.hourly/yunohost-update:
Fetching available upgrades for system packages…
Updating application catalog…
The application catalog has been updated!
apps:
important_yunohost_upgrade: True
pending_migrations:
system:
0:
current_version: 11.0.11
name: yunohost-admin
new_version: 11.1.0.2
1:
current_version: 11.0.10.2
name: yunohost
new_version: 11.1.0.2
Upgrading packages…
Upgrading system packages

  • Reading package lists…
  • Building dependency tree…
  • Reading state information…
  • Calculating upgrade…
  • The following packages were automatically installed and are no longer required:
  • bind9-utils bind9utils dnsutils libicu63 libllvm7 php-gettext php7.3-apcu
  • php7.3-bcmath php7.3-bz2 php7.3-curl php7.3-gmp php7.3-igbinary
  • php7.3-imagick php7.3-imap php7.3-redis php7.3-soap php7.3-ssh2 php7.3-zip
  • postgresql-11 postgresql-client-11 python3-ply python3-publicsuffix
  • Use ‘apt autoremove’ to remove them.
  • The following packages will be upgraded:
  • yunohost yunohost-admin
  • 2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
  • Need to get 8,089 kB of archives.
  • After this operation, 234 kB of additional disk space will be used.
  • Get:1 Index of /debian/ bullseye/stable amd64 yunohost all 11.1.0.2 [1,083 kB]
  • Get:2 Index of /debian/ bullseye/stable amd64 yunohost-admin all 11.1.0.2 [7,005 kB]
  • Fetched 8,089 kB in 1s (11.7 MB/s)
  • Unpacking yunohost (11.1.0.2) over (11.0.10.2) …
  • Setting up yunohost (11.1.0.2) …
  • Regenerating configuration, this might take a while…
  • Running migration 0025_global_settings_to_configpanel…
  • Migration 0025_global_settings_to_configpanel completed
  • Configuration updated for ‘ssh’

Bonsoir,

J’ai observé le même problème aujourd’hui aussi sur mon VPS @xfauXtvFNs.
J’étais d’ailleurs dans l’impossibilité de me reconnecter en SSH, seulement en webadmin.

J’ai fait depuis l’interface OVH, un retour arrière en restaurant ma sauvegarde quotidienne (03/11 à 23h02), ouf je n’avais pas bossé sur mon serveur aujourd’hui.

A cet instant, mon serveur est en version 11.0.10.2 (stable) et il me propose de nouveau la 11.1.0.2 avec ce message en en-tête

A major YunoHost upgrade is available. It is heavily recommended to carefully read the release note(s) on the forum before upgrading : Browse the release notes on the forum

Je n’ai pas activé un souhait de recevoir une version testing ! Du coup, je ne refait pas la mise à jour :wink:

Petite mise à jour, j’ai reçu ce mail via mon serveur (service apticron report) du 04/11 à 23h35

apticron has detected that some packages need upgrading on “myserver”
The following packages are currently pending an upgrade:

  • yunohost 11.1.0.2
  • yunohost-admin 11.1.0.2

Package Details:

  • apt-listchanges: Reading changelogs…
  • apt-listchanges: Changelogs

Changes for yunohost

  • yunohost (11.1.0.2) testing; urgency=low
  • globalsettings: make sure to run migration 25 prior to the regenconf (f3750598)
  • domaininfo: Some apps don’t have path (#1521)
  • Add sponsors to the README (#1522)
  • postfix: fix relay conf not triggered because new setting system now returns ‘1’ and not ‘True’ (cd43c8bd)
  • postfix: fix permission issue preventing to properly create sasl_passwd.db (5394790f)
  • [i18n] Translations updated for French

Thanks to all contributors <3 ! (Félix Piédallu, Florian Masy, ppr, Tagada) – Alexandre Aubin alex.aubin@mailoo.org Fri, 04 Nov 2022 13:13:40 +0100

La même chose m’est arrivée tout à l’heure avec mon Pi. Y a-t-il un moyen de retourner vers stable ?

1 Like

attendez, je viens de signaler le probléme aux core dev

3 Likes

Merci @yalh76

Donc a priori juste un petit problème lors de la sortie de la version 11.1.0.2 qui était une testing mais qui est passé dans la branche stable. :confused:

Pour le moment sans autre consigne, n’essayer pas de revenir en arrière. Au pire du pire, lorsque une nouvelle release de la branche 11.1 sortira en stable, vos yunohost l’installeront et vous retournerez en stable.

En fait vous n’etes pas passé en testing, c’est une version testing qui a été délivrée par erreur sur la branche stable…

9 Likes

Merci @yalh76 , même “problème” ici, je pensais simplement que la testing avait été (volontairement) poussée en stable.

1 Like

lol nope ^^ une erreur…
On essaye de pas forcer à passer sur des versions en testing ^^

1 Like

Ok, merci @yalh76 en revanche du coup la connexion par SSH reste impossible, une piste pour résoudre ce problème ?

en ssh tu te connectes en tant que quel utilisateur ? root ou un autre utilisateur ?

en tant qu’admin.

Potentiellement tu peux tenter de redémarrer le service slapd depuis la webadmin pour voir si ça résouds le soucis ?

(Déso pour le passage innopiné en testing @_@)

au sein de ta connexion ssh en tant qu’admin, tu essayes pas de passer en root en même temps ?

je demande parce que sur plusieurs serveurs passés en 11.1.0.2, la connexion SSH fonctionne

Merci yalh76 des précisions. Chez moi le ssh fonctionne.

Merci beaucoup @yalh76
Je comprends que la prochaine version stable va venir remplacer cette testing pour un retour à la normale.

Bonjour,
@Aleks et @yalh76 comme dis plus haut j’ai fait un retour arrière et j’attend une autre mise à jour avant de retenter celle-ci.
En SSH, je rencontrais l’erreur Permission denied (publickey)

@yalh76 non uniquement une connexion en tant qu’admin, j’avais désactivé l’authentification par mot de passe et la connexion par root en ssh. Sauf si pendant la migration tout à bougé. Le port modifié était bien repris par contre.

1 Like

Ok, je me suis inquiété aussi, j’ai du être une potentielle victime… J’aurais du bien lire avant de faire l’upgrade…
Sinon autre effet de cette mise à jour inopinée, le problème des mails ! Du coup un user qui est aussi dans le groupe admins (le premier user) avait plusieurs alias dont admin, root, postmaster, webmaster, abuse, contact, etc…

Certains ont sauté et j’ai eu ce type de messages: concernant les backups de borg

This is the mail system at host domaine.tld.

I’m sorry to have to inform you that your message could not
be delivered to one or more recipients. It’s attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

               The mail system

admin@domaine.tld (expanded from root@domaine.tld): user unknown

Reporting-MTA: dns; domaine.tld
X-Postfix-Queue-ID: B02DB2884C7
X-Postfix-Sender: rfc822; root@domaine.tld
Arrival-Date: Sat, 5 Nov 2022 04:21:34 +0100 (CET)

Final-Recipient: rfc822; admin@domaine.tld
Original-Recipient: rfc822;root@domaine.tld
Action: failed
Status: 5.1.1
Diagnostic-Code: x-unix; user unknown

ForwardedMessage.eml
Sujet :
[borg] Backup succeed from domaine.tld onto ssh://borgrod@rodinux.fr:6060/~/backup
De :
root root@domaine.tld
Date :
05/11/2022 04:21
Pour :
root@domaine.tld

et celui-ci, je ne sais plus trop pourquoi ??

This is the mail system at host domain.tld.

I’m sorry to have to inform you that your message could not
be delivered to one or more recipients. It’s attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

               The mail system

admin@domain.tld (expanded from ): user unknown

Reporting-MTA: dns; domain.tld
X-Postfix-Queue-ID: 093722884D7
X-Postfix-Sender: rfc822; admin@domain.tld
Arrival-Date: Sat, 5 Nov 2022 09:32:29 +0100 (CET)

Final-Recipient: rfc822; admin@domain.tld
Original-Recipient: rfc822;root@domain.tld
Action: failed
Status: 5.1.1
Diagnostic-Code: x-unix; user unknown

ForwardedMessage.eml
Sujet :
*** SECURITY information for domain.tld ***
De :
admin@domain.tld
Date :
05/11/2022 09:32
Pour :
root@domain.tld

domain.tld : Nov 5 08:32:29 : admin : a password is required ; TTY=pts/1 ; PWD=/root ; USER=root ; COMMAND=/bin/bash

Pour l’instant j’ai tenter de remettre les alias pour mon user principal, ceci dit ces messages sont arrivés dans la boîte mail de cet user… Et bizarrement les messages de Borg sont bien arrivés aussi après les backups (mais c’était avant cette mise à jour)…

Bref, c’est embêtant… qu’est-ce qu’il faut faire ?