Forum

Reprise du message précédent

Bonjour, merci pour vos réponses. Je regarde ça dès que j'aurai la connection sur le serveur parce que mon pote s'est absenté de chez lui, et je posterai les résultats.
pour lui.

Je vote aussi pour la corruption de la base, même si je n'ai jamais vu ce message.
J'ai toujours vu recommandé la méthode d'Adrien. Il faudrait faire des essais comparatifs pour déterminer laquelle est nécessaire et suffisante.

Bonjour,

Euh !... franchement, je suis comme toi je ne sais pas !

Oui, merci le premier lien a suffit, un "rpm --rebuilddb" a marché, j'ai pu faire la mise à jour, et ça c'est bien passé, sans message d'erreur.
Le seul truc que je me reproche c'est de ne pas y avoir pensé plus tôt mince alors, je fais mon mea-culpa et je te remercie pour ta réponse.
Ensuite, avant de faire à distance, la montée de mageia 6 vers mageia 7, j'ai vu avec mon pote pour qu'il fasse les sauvegardes. Mais, comme il ne sait pas et n'a pas de disque dur externe, en accord avec lui, j'ai établi une connexion depuis mon ordi en ssh sur une konsole serveur. et je fais les sauvegardes de ces documents, images, musique, vidéos etc ... de son ordi sur un disque dur connecté à mon ordi avec un rsync. Tout cela pour dire que ça va prendre un certain temps avant que je puisse faire l'upgrade de mageia 6 vers mageia 7.
Le moment venu, j'essaierai de faire ceci:

Dès que je ferai l'upgrade je posterai pour vous tenir informé.
à tous pour votre aide précieuse.

Bonjour,

Pour une mise à jour à distance, j' activerais les nouveaux dépots et je ferais un download-all, ainsi même en cas de coupure de réseau ce qui n' est pas exclu du tout, cela ne devrait pas poser de problème d' installation des paquets puisque déjà disponibles localement.

Il doit être possible de télécharger les paquets en parallèle ( le rsync envoyant vers le pc distant, on utilise le lien montant de sa connexion, or la récupération des paquets utilise le lien descendant (un --download-all --test devrait charger les paquets sans toucher l' installation existante (à cause du paramètre test); en plus je crois qu' il est possible de les charger à un endroit particulier en attendant).

Éventuellement une clé de secours pourrait être utile si la migration s' arrête au milieu ( parce qu' un paquet en conflit, etc... )

edit: désolé, je n' avais pas lu que c' est ce qui est indiqué sur le site d' Adrien.

Édité par nic80 Le 22/08/2020 à 12h35

Oui, même pour rsync, je t'invite a utiliser une session screen. En fait, pour tout, et même pour tester !

Bonjour,

screen ne fait que détacher le process de la console/terminal lancé, non ? Dans ce cas, c' est utile si on ferme par inadvertance la session, konsole qui fait le download/rsync, etc...

Mais cela ne protège pas contre, une rupture complète du réseau ( parce que le paquet x n' a pas toute ces dépendances installées).

Tiens une autre chose à laquelle je viens de penser... Passer en mode console ( init 3) avant de lancer la mise à jour ( cela évite le plantage de l' environnement graphique et/ou un message d' erreur indiquant qui indique qu' il faut taper la commande loginctl unlock-session c2 ( ou quelque chose du même genre))

Édité par nic80 Le 22/08/2020 à 14h41

Je pourrais tester demain, mais je crois qu'on peut fermer Konsole et l'activité derrière screen ne sera pas fermée.
En tout cas, derrière ssh, si la connexion se rompt, on se fait déconnecter ssh, mais le logiciel lancé dans screen ne se fait pas KILL.
Elle "protège" d'une coupure de réseau dans le sens où, lorsqu'il y a une coupure de réseau, le logiciel dit qu'il n'a pas pu finir de télécharger/installer, alors que sans, lorsque ssh se ferme, l'installation est coupée en plein paquet, en plein milieu d'une installation, comme un kill -9.

Bonjour les gars et merci pour toutes ces infos. Excusez-moi mais j'avoue que je patauge un peu dans vos explications, donc déjà je vais essayer de vous expliquer quelle est la configuration actuelle le plus clairement possible:
Depuis mon PC (donc client) j'ai ouvert une konsole dans laquelle j'ai tapé:
su suivi de mon mot de passe root.
Puis ssh root@adresse-du-pc-de-mon-pote (donc adresse du serveur)
De là j'ai tapé:
rsync -azz --progress --exclude=.* /home/user-de-mon-pote/ mon-user@mon-ip-v4:/adresse-du-disque-dur-sur-lequel-je-sauvegarde-les-docs-de-mon-pote/
De plus actuellement, c'est à dire en même temps que rsync s'exécute, je suis connecté sur l'écran de mon pote c'est à dire en VNC.
Voilà, j'espère que c'est assez clair. Donc pour l'instant avec l'option --progress je sais où j'en suis.

Quand tu parles de session screen tu veux dire une connexion VNC ? si oui c'est ce que j'ai fait.


Qu'entends-tu par nouveaux dépôts ? que dois-je faire sur le pc distant pour activer ces nouveaus dépôts ?
Ensuite je suppose que le download-all (toujours sur pc distant) copierai tous les paquetages de la version 7 quelque part sur le disque ?


Euh là !!!!!!!! perso je préfèrerais ne pas tout mélanger parce qu'une fois que la sauvegarde des documents sera faite, je serai tranquille même s'il y a un pet sur le serveur, tandis que là j'ai l'impression qu'on mélange tout, sauvegarde et updrade, bon tu as certainement raison mais je ne me sens pas de faire tout d'un coup ... j'ai la trouille hein ?!!!

pour toute vos explications, je continue la sauvegarde et je vous tiens au courant.

Euh .... j'ai oublié de vous dire, si vous voulez que je fasse des tests qui pourraient être utiles pour la communauté, il n'y a pas de problème, je le ferai, mais dans ce cas je vous demande de bien vouloir me détailler avec précision les différentes étapes parce que je ne veux pas que mon pote en subisse les dommages. Sinon pas de problème je fais tous les tests susceptibles de faire avancer le schmilblick de la communauté mageia.

Bonjour,



Non en fait screen est un programme qui quand tu le lances ( de la manière "screen le_programme_que_je_veux"), crée une "session" différente que celle où l' on a tapé la commande screen.

Par exemple, je lance une session ssh sur un pc distant et depuis cette session je lance la commande "rsync quelques_paramètres" qui devient processus enfant. Si par hasard, la connexion ssh est interrompue, le processus rsync sera arrêté ( en principe l' arrêt du processus parent tue les processus enfants). En revanche, si la commande screen est utilisée, même si la connexion ssh est interrompue, rsync continuera à fonctionner ( processus indépendant de ssh) et l' on peut retrouver le processus en cours en se rattachant de nouveau à la session screen En tous cas, c' est comme ça que le comprends.

Concernant les dépots, si on fait une mise à jour de la version 6 à la version 7 comme indiquée dans sur le site, il faut enlever les dépots Mageia 6 pour rajouter les dépots de Mageia 7 à la place ( urpmi.removemedia -a; urpmi.addmedia --distrib --mirrorlist http://mirrors.mageia.org/api/mageia.7.x86_64.list ). tiens d' ailleurs, je ne vois pas comment on réactive les dépots nonfree et/ou tainted le cas échéant dans la procédure...

Je ne pense pas que le download-all va télécharger tous les paquets , juste ceux nécessaire à la mise à jour avant de mettre à jour quoique que ce soit. Sans chemin spécifique cela sera chargé dans le répertoire par défaut d' urpmi ( attention à l' espace disque disponible sur la partition / ).

Édité par nic80 Le 22/08/2020 à 16h04

Non, screen et vnc sont deux choses différentes.

Vois-tu les consoles différentes avec [ctrl]+[alt]+[F2] par exemple ? Tu peux aller sur F4, et avoir un autre contenu.
Je dirai que screen c'est la même chose, mais purement logiciel.
A la différence de nic80 qui fait screen commande (ce que je trouve galère à récupérer) par son identifiant numérique, je fais
screen -RDU NOM_DE_MA_SESSION
et je me retrouve dans un "nouveau" terminal vierge. Je peux y faire toutes mes commandes désirées, et quand ne souhaite "quitter" pour reprendre plus tard le logiciel en cours d'exécution, je fais la combinaison de touche ctrl-A puis D.

Tu peux expérimenter !



Voilà, notre fenetre konsole est fermée, avec un fichier texte en cours d'édition et non sauvegardée.
Si les processus ont été tué, alors nous n'aurons aucune trace du texte. On regarde où s'en est :

Whaouh !!!! bon, excusez-moi, je suis un vieux monsieur qui a les neurones un peu en vrac !!! alors vu que ma session avec le serveur est tombée, je vais devoir me reconnecter pour relancer rsync, alors je récapépète pour voir si j'ai tout bien compris, mais uniquement pour la sauvegarde des documents du copain sur un disque dur connecté à mon ordi:
Si je prends la solution de nic80:

c'est ce qui vient de se produire donc dès que j'ai accès au serveur je pense faire ceci depuis mon ordi en konsole root:
ssh root@ip-du-serveur
maintenant que je suis sur le serveur, au lieu de faire:
rsync -azz --progress --exclude=.* /home/user-de-mon-pote/ mon-user@mon-ip-v4:/adresse-du-disque-dur-sur-lequel-je-sauvegarde-les-docs-de-mon-pote/

je fais:
screen rsync -azz --progress --exclude=.* /home/user-de-mon-pote/ mon-user@mon-ip-v4:/adresse-du-disque-dur-sur-lequel-je-sauvegarde-les-docs-de-mon-pote/
Ai-je bien compris nic80 ?

Si je prends la solution de jybz:
depuis mon ordi en konsole root:
ssh root@ip-du-serveur
maintenant que je suis sur le serveur, je fais
screen -RDU NOM_DE_MA_SESSION
Ai-je bien compris Jybz ? si oui, juste un petit détail, heu ... sais plus où je trouve NOM_DE_MA_SESSION !!!!!!!!

Bonjour,

Je pense que le NOM_DE_MA_SESSION est arbitraire ( je pense que c' est pour retrouver plus rapidement la session, mais je ne connais pas screen pour savoir si c' est le cas).

Pour savoir les screen lancés, la commande screen -list permet de lister celles déjà existantes.

En fait "screen -RDU n_importe_quoi" ouvre une session screen ( qui s' appellera n_importe_quoi) dans laquelle il faut taper la commande rsync. Pour la retrouver, l faut faire "screen -RDU n_importe_quoi"

En tous cas, c' est ce que j' ai compris des quelques expérimentions faites en local.

Édité par nic80 Le 22/08/2020 à 17h50

Ah Ok merci nic80 pour ton explication, donc je peux faire par exemple: screen sauvegarde-de-mon-pote là j'ai une konsole dans laquelle je tape rsync etc ... et s'il y a rupture de connexion je peux retrouver en tapant screen -RDU sauvegarde-de-mon-pote.
Bon, j'attends de pouvoir me reconnecter sur le serveur pour faire ces manips, je posterai après.

Édité par zatox Le 22/08/2020 à 17h59

Oui c'est bien ça nic80, le nom est arbitraire et tu as bien compris l'utilisation.
Il y a d'autre options possibles que RDU, certaines exclusivement pous ouvrir une nouvelle session, d'autre uniquement pour récupérer, je recommande -RDU car c'est aussi bien pour ouvrir (si inexistant) que récupérer (si existant).
J'utilise aussi -list pour surveiller l'état. À savoir, j'utilise quotidiennement 4 screen différents sur un serveur.

Choses qui ne me plaisent pas :
Pourquoi le root ?
Autant du coté client que serveur, c'est mal ! Je te tape sur les doigts !