PB lors de l'installation de borg backup

[Acidope]

Bonjour,

YNH 4.3.6.2 fresh install VPS ovh
Comment régler le pb suivant aprés l’install de borg ?

sudo: /etc/sudoers.d/borg is owned by uid 997, should be 0

J’ai eu le malheur de tenter de modifier manuellement le fichier /etc/group en remplacant la ligne borg:x:997: par borg:x:0:

J’ai planté un serveur en production. Aprés reboot impossible de s’y connecter en SSH a nouveau… dans l’immédiat je cherche a restaurer avant ce soir mon backup borg sur un nouveau serveur.

J’ai bien l’impression que ma “boulette” ne soit pas réparable.

[Aleks]

@Acidope

remplacant la ligne borg:x:997: par borg:x:0:

You did what

20th century U WOT M8

• Si c’est une “fresh install”, est-ce qu’il ne suffit pas juste de réinstaller le serveur ?
• Quand tu dis “impossible de …”, il faut nous donner le détail de pourquoi c’est impossible : qu’est-ce que tu tentes de faire exactement (e.g. la commande exacte) et qu’est-ce qui se passe (e.g. le message d’erreur exact), sinon on ne peut pas magiquement deviner les choses et on ne peut donc pas t’aider
• Il faudrait regarder si OVH te propose un accès “rescue” ou quelconque console graphique accessible en web

[Acidope]

Pour répondre au sujet du mode rescue, j’y ai accés mais dans ce mode je n’ai pas accés au meme fichier. Le fichier /etc/group n’est pas le meme. je n’ai pas la ligne avec “borg”. Je ne sait pas quoi faire de plus dans ce mode. Si tu as une solution avec ce mode alors n’en lis pas plus

Pour détailler la situation :

J’ai donc deux serveur YNH, un est un VPS chez ovh (ynh 4.3.4.2) et l’autre est un RPI (ynh 4.3.6.2) a la maison.
Je sauvegarde le VPS sur le RPI. La semaine dernière j’ai ajouté un serveur proxy NPM (nginxproxymanager) car j’ajoute un deuxième serveur windows a la maison et les backup de se faisait plus malgré le fait d’avoir ouvert tout les port. J’ai compris que NPM n’autorisait pas l’ouverture du port 22.
j’ai tenté de changer le port ssh manuellement mais j’ai planté mon RPI. Ducoup je suis partis sur un fresh-install. Ce n’est que plus tard que j’ai trouvé la commande sudo yunohost settings set security.ssh.port -v <new_ssh_port_number>

En meme temps j’ai eu la bonne idée de reinstaller borgbackup sur le VPS ovh, de changer le fichier /etc/group et de planter le second serveur…

Dans l’ordre :

• je désactive le proxy et je passe le RPI en direct sur le routeur pour éviter les pb d’accés.
• je fait une fresh install du RPI mais j’ai toujours un backup sur le disque externe
• je reinstall borgbackup sur le VPS et je plante le serveur en modifiant le /etc/group
• je fait une fresh-install de YNH sur un nouveau VPS pour tenter de restaurer le backup
• j’ai toujours cette erreur de borg sudo: /etc/sudoers.d/borg is owned by uid 997, should be 0
• je chope la clé borgbackup avec sudo cat /root/.ssh/id_borg_ed25519.pub
• je transfère la clé ssh du borgbackup sur le borgserver (RPI) dans le fichier /home/userborg/.ssh/authorized_keys mais quand je tape la commande ssh -i /root/.ssh/id_borg_ed25519 userborg@serveurb.tld alors il me demande un mot de passe. ce qui veut dire que la clé n’est pas reconnu.
• la commande borg list ./ me donne une liste de fichier de sauvegarde (environ 30)

Pour l’instant j’en suis là

[Aleks]

@Acidope

Pour répondre au sujet du mode rescue, j’y ai accés mais dans ce mode je n’ai pas accés au meme fichier. Le fichier /etc/group n’est pas le meme. je n’ai pas la ligne avec “borg”. Je ne sait pas quoi faire de plus dans ce mode.

Oui, car en mode rescue, typiquement tu es dans un “autre” système, mais tu peux accéder aux fichiers de ton “vrai” système qui est monté quelque part dans le système de fichier. Tu peux potentiellement trouver où avec lsblk, ou bien avec ls / en regardant attentivement les noms des fichiers. Dans le point de montage correspondant, tu pourras trouver etc/group et l’éditer.

[Acidope]

J’ai vu la doc d’ovh a ce sujet mais je n’ai pas trouvé mon ancien disque

/home/debian $ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            3.8G     0  3.8G   0% /dev
tmpfs           779M   25M  754M   4% /run
/dev/sda1       2.4G  1.6G  626M  73% /
tmpfs           3.9G     0  3.9G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup

$ lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0  2.5G  0 disk 
`-sda1   8:1    0  2.5G  0 part /
sdb      8:16   0  160G  0 disk 
`-sdb1   8:17   0  160G  0 part

j’ai loupé qqchose?

[Aleks]

J’imagine qu’il s’agit de /dev/sdb1 qui n’est en fait pas monté … il faut le monter manuellement, par exemple mkdir /mnt/mysystem puis mount /dev/sdb1 /mnt/mysystem

Ensuite, nano /mny/mysystem/etc/group pour éditer le fichier

[Acidope]

c’était bien /dev/sdb1 qui n’était pas monté. Merci

Aprés modif, toujours pas d’accés SSH.

je vais retourner en mode rescue pour voir si la modif a bien été sauvegardé.

[Acidope]

ok. j’ai vérifié et remplacer le groupe de borg. La modif a été enregistré.
j’ai remplacé borg:x:0: par borg:x:997:

j’ai redémarré le serveur en mode normal.

ssh en root et en admin ne donne pas d’accés

Un ping du serveur donne :
8 packets transmitted, 0 packets received, 100.0% packet loss
Un ping de l’ip donne la meme erreur.

NSlookup me stipule bien que le nom de domaine pointe bien sur la bonne ip.

Vers ou puis-je me diriger?

[Aleks]

@Acidope

ssh en root et en admin ne donne pas d’accés

Il faut donner LE VRAI MESSAGE D’ERREUR EXACT ET COMPLET, je répète, LE VRAI MESSAGE. On ne PEUT PAS deviner magiquement ce qui ne marche pas si vous ne donnez pas les détails PRÉCIS

@Aleks

Quand tu dis “impossible de …”, il faut nous donner le détail de pourquoi c’est impossible : qu’est-ce que tu tentes de faire exactement (e.g. la commande exacte) et qu’est-ce qui se passe (e.g. le message d’erreur exact), sinon on ne peut pas magiquement deviner les choses et on ne peut donc pas t’aider

[Acidope]

pardon. le voici :
ssh: connect to host mydomain.tld port 22: Operation timed out

[Aleks]

Zblerg beh du coup ça semble dire que ton serveur ne démarre toujours pas correctement, et en particulier que le réseau ne se monte pas … Mais difficile d’en savoir plus comme ça … Si OVH te fourni une console web, ce serait pratique pour observer le démarrage de la machine et voir ce qui se passe …

Sinon, une alternative technique est de retourner sur le mode rescue et de regarder le log du démarrage dedans, avec un truc genre tail -n 300 /<point de montage du rescue>/var/log/dmesg (ou alors peut-être syslog ou un kern.log, l’un des trois)

[Acidope]

ok je vais checker ca dessuite merci

[Acidope]

j’ai chopé syslog et kern.log

Dans syslog j’ai remarqué la ligne suivante :
error resolving pool 2.debian.pool.ntp.org: Temporary failure in name resolution (-3)

les fichiers sont assez long. je fait un wetransfert.

log.zip

[Acidope]

aprés j’ai un accés KVM, je vais tenter un reboot en mode normal

[Aleks]

Oui, c’est un symptome mais ce n’est pas la cause

On voit aussi:

Feb 13 17:47:52 sabeogroup ifup[399]: ifup: /etc/network/interfaces:1: misplaced option
Feb 13 17:47:52 sabeogroup ifup[399]: ifup: couldn't read interfaces file "/etc/network/interfaces"

qui semble pointer vers un problème dans le fichier /etc/network/interfaces ligne 1 …

[Acidope]

@Aleks

Feb 13 17:47:52 sabeogroup ifup[399]: ifup: /etc/network/interfaces:1: misplaced option

Bwaaah trop fort c’était ca Ca déchire mec. la soirée était vraiment mal partie.

la première ligne avait une lettre avant le #.
Va savoir pourquoi. Je n’ai pas ouvert ce fichier depuis au moins 6 mois et la machine a redémarré qqfois entre temps.

Cela resteras dans les mystère non résolus je crois…

[Aleks]

The X-Files Theme

[Acidope]

mdr