Borgserver sur une machine non yunohost

Matériel: Image virtualbox officielle yunohost (en attente d’avoir un raspberry pi dédié) + un 2ème Raspberry Pi non yunohost
Version de YunoHost: 3.6.5.3
J’ai accès à mon serveur : En SSH + Par la webadmin + En direct avec un clavier/écran
Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : non

Bonjour,
je suis séduit par yunohost :heart_eyes: et en attendant d’avoir ma config finale pour le faire tourner (un raspberry pi que je vais dédier à yunohost) je le teste dans une VM.

J’ai commencé à tester / mettre en place la chaine de backup de Yunohost qui sera composée comme suit:

  • la machine yunohost crée un backup sur un serveur non yunohost via l’applicaiton borg_ynh
  • le serveur non yunohost (raspberrypi.local) se charge d’uploader le backup sur mon cloud Hubic avec rclone (c’est un serveur qui est dédié à l’upload de tous mes backups sur hubic, il ne fait que ça 24/7)

J’ai pu tout configurer grâce à ces 2 fils: (edit: j’ai l’interdiction de poster des liens donc je copie le titre des sujets… :frowning_face: )

  • borgserver-sur-une-machine-qui-nest-pas-un-yunohost
  • how-to-backup-your-yunohost-server-on-another-server

mais je rencontre 2 soucis rédhibitoires: :face_with_raised_eyebrow:

  • je dois rentrer plusieurs fois le mot de passe de l’utilisateur ssh au cours du backup (pas très pratique pour automatiser )
  • le backup ne se fait pas au bon endroit

Voici comment j’ai opéré:

Dans la VM Yunohost

$ ssh-keygen -t ed25519
(je n'ai pas rentré de passphrase)

sudo yunohost app install https://github.com/YunoHost-Apps/borg_ynh
Indicate the server where you want put your backups: raspberrypi.local
Indicate the ssh user to use to connect on this server: yunohost

Sur mon serveur non yunohost (raspberrypi.local), en root

sudo adduser yunohost 

Puis je me connecte en ssh à ce nouvel utilisateur:

mkdir .ssh
touch .ssh/authorized_keys
echo "command=\"borg serve --storage-quota 50G --restrict-to-repository /media/usbdisk/Yunohost\",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc AAAA[...] admin@yunohost.local" >> /home/yunohost/.ssh/authorized_keys

Comme mon serveur non yunohost est un raspberrypi, pour limiter l’usure de la SD card j’ai mis tous les logs en RAM etj’ai branché dessus un disque externe USB de 500Go pour les données volumineuses qui est monté sous /media/usbdisk au démarrage.
Je précise donc bien dans la commande borg serve le path vers ce disque.

On lance la commande de backup:

sudo yunohost backup create -n test --methods borg_app --debug

Sauf que, le backup se réalise bien MAIS pas sur le disque USB… Le répertoire /media/usbdisk/Yunohost est vide, mais si je regarde dans les logs:

    110149 DEBUG + BORG_PASSPHRASE=XXXXX
    110169 DEBUG + ssh-keygen -F raspberrypi.local
    110177 DEBUG + BORG_RSH='ssh -i /root/.ssh/id_borg_ed25519 -oStrictHostKeyChecking=yes '
    110184 DEBUG + repo=ssh://yunohost@raspberrypi.local/~/backup
    110200 DEBUG + work_dir=/home/yunohost.backup/tmp/test
    110203 DEBUG + name=test
    110205 DEBUG + size=233429032
    110207 DEBUG + description=
    110209 DEBUG + case "$1" in
    110211 DEBUG + do_backup /home/yunohost.backup/tmp/test test ssh://yunohost@raspberrypi.local/~/backup 233429032
    110219 DEBUG + export BORG_PASSPHRASE
    110221 DEBUG + export BORG_RSH
    110224 DEBUG + work_dir=/home/yunohost.backup/tmp/test
    110238 DEBUG + name=test
    110241 DEBUG + repo=ssh://yunohost@raspberrypi.local/~/backup
    110244 DEBUG + size=233429032
    110246 DEBUG + description=
    110247 DEBUG + LOGFILE=/var/log/backup_borg.log
    110251 DEBUG + ERRFILE=/var/log/backup_borg.err
    110254 DEBUG ++ date +%d_%m_%y_%H:%M
    110256 DEBUG + current_date=16_12_19_04:19
    110257 DEBUG + pushd /home/yunohost.backup/tmp/test
    110268 DEBUG /home/yunohost.backup/tmp/test /etc/yunohost/hooks.d/backup_method
    110273 DEBUG + set +e
    110276 DEBUG + borg init -e repokey ssh://yunohost@raspberrypi.local/~/backup
    yunohost@raspberrypi.local's password: 
    129188 DEBUG + echo 'Hello,
    129193 DEBUG 
    129202 DEBUG Your first backup on ssh://yunohost@raspberrypi.local/~/backup is starting.
    129204 DEBUG 
    129206 DEBUG This is an automated message from your beloved YunoHost server.'
    129208 DEBUG + /usr/bin/mail.mailutils -a 'Content-Type: text/plain; charset=UTF-8' -s '[YNH] First backup is starting' root
    129845 DEBUG + set -e
    129850 DEBUG + borg create ssh://yunohost@raspberrypi.local/~/backup::test_16_12_19_04:19 ./
    yunohost@raspberrypi.local's password: 
    360462 DEBUG + popd
    360472 DEBUG /etc/yunohost/hooks.d/backup_method
    360475 DEBUG + borg prune ssh://yunohost@raspberrypi.local/~/backup -P test --keep-hourly 2 --keep-daily=7 --keep-weekly=8 --keep-monthly=12
    yunohost@raspberrypi.local's password: 
    375499 DEBUG + exit 0
    377771 DEBUG La sauvegarde dans Borg est terminée
    377783 SUCCESS Sauvegarde terminée

Je vois repo=ssh://yunohost@raspberrypi.local/~/backup…

yunohost@raspberrypi:~ $ borg list /home/yunohost/backup
Enter passphrase for key /home/yunohost/backup: 
test_16_12_19_04:19                  Mon, 2019-12-16 04:19:42

Le backup se trouve dans le home du user yunohst, c’est à dire sur ma SD card…

Du coup j’aurais 2 questions:

  • Lorsque j’ai créé mon user sur le serveur non yunohost j’ai utilisé la commande du tutoriel en anglais adduser yunohost. Je me suis aperçu après coup que dans le tuto en français il y a une option “disabled-password”: adduser NOMDUUSER --quiet --gecos ",,," --shell /bin/bash --disabled-password
    Est ce que le problème vient de là? Je suis surpris car je pensais que la copie de clée publique servait justement à éviter d’avoir à saisir un mot de passe…
  • 2ème question, pour quelle raison me backup se fait-il à un autre endroit que celui précisé dans ma commande borg serve?

Merci à vous!

Après quelques recherches et lectures (et déductions…), il semblerait que tous mes problèmes viennent de l’échec de l’authentification par clé.

Le chemin de backup que j’indique dans la command borg serve n’est probablement pas pris en compte parce que la clé publique du serveur yunohost n’est pas reconnue.

Options associées aux clefs ssh dans authorized_keys

Forcer l’exécution d’une commande

L’option command permet quant à elle de préciser une commande à exécuter à la place de la commande fournie par la machine distante.

La commande originale fournie par le client ssh sur l’autre machine est ignorée, mais est passée à la commande forcée dans la variable d’environnement SSH_ORIGINAL_COMMAND .

Exemple:

command="/usr/local/bin/my_wrapper_script.sh user" ssh-dss AAAAC3...51R== user@example.net

Du coup puisque l’authentification par clé échoue, quand je rentre le mot de passe “à la main” pendant la procédure de backup, je dois complètement bypasser ce mécanisme et je me retrouve avec la commande par défaut de yunohost qui doit probablement sauvegarder dans home/$USER/backup.

Donc, il faut résoudre le problème de l’authentification par clé, mais là je sèche un peu… :thinking:

  • Déjà j’ai supprimer mon user “yunohost” sur le pi pour en recréer un propre avec la commande adduser $ssh_user --quiet --gecos ",,," --shell /bin/bash --disabled-password
  • Ensuite j’ai modifié mon fichier authorized_keys pour commenter la ligne borg serve pour ne mettre que la clé publique du serveur yunohost. En toute logique, le serveur doit pouvoir s’authentifier sans demander de mot de passe et va créer un backup dans le chemin par défaut.
sh-ed25519 AAAAC[...] admin@yunohost.local
#commande originale 
#command=\"borg serve --storage-quota 50G --restrict-to-repository /media/usbdisk/Yunohost/backup\",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc ssh-ed25519 AAAAC[...]  admin@yunohost.local

Je teste:

admin@yunohost:~$ ssh yunohost@raspberrypi.local
Linux raspberrypi 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019 armv7l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
yunohost@raspberrypi:~ $ 

:white_check_mark: Pas de demande de mot de passe et je suis bien logué.
Je relance la comman de de backup sudo yunohost backup create -n test --methods borg_app --debug et tous mes espoirs se fracassent sur un :

131207 DEBUG + borg init -e repokey ssh://yunohost@raspberrypi.local/~/backup
yunohost@raspberrypi.local's password: 

:sob:

Donc pour résumer, si je me connecte à mon pi à la main ça passe, mais quand c’est yunohost ça coince…
Je sèche, je suis preneur de toute idée…
Merci à vous

--------- EDIT ---------
Voivi les logs de sshd sur mon PI pour une connexion réussie “à la main”:
(ma machine yunohost est 192.168.0.21)

Dec 18 00:20:14 raspberrypi sshd[23094]: Accepted publickey for yunohost from 192.168.0.21 port 34724 ssh2: ED25519 SHA256:+WCfOpvCkna6/sooS9JPuLf9q6bAySxCdSYKkMhJsm0
Dec 18 00:20:14 raspberrypi sshd[23094]: pam_unix(sshd:session): session opened for user yunohost by (uid=0)
Dec 18 00:20:14 raspberrypi systemd-logind[317]: New session c11 of user yunohost.
Dec 18 00:20:14 raspberrypi systemd: pam_unix(systemd-user:session): session opened for user yunohost by (uid=0)
Dec 18 00:20:15 raspberrypi sshd[23094]: lastlog_openseek: Couldn't stat /var/log/lastlog: No such file or directory
Dec 18 00:20:15 raspberrypi sshd[23094]: lastlog_openseek: Couldn't stat /var/log/lastlog: No such file or directory
Dec 18 00:20:18 raspberrypi sshd[23110]: Received disconnect from 192.168.0.21 port 34724:11: disconnected by user
Dec 18 00:20:18 raspberrypi sshd[23110]: Disconnected from 192.168.0.21 port 34724
Dec 18 00:20:18 raspberrypi sshd[23094]: pam_unix(sshd:session): session closed for user yunohost
Dec 18 00:20:19 raspberrypi systemd-logind[317]: Removed session c11.
Dec 18 00:20:19 raspberrypi systemd: pam_unix(systemd-user:session): session closed for user yunohost

Malheureusement je ne vois pas de nouveau log lorsque le script de yunohost me demande le mot de passe? Peut être pas le bon niveau de logs? Bref, pas d’info de ce côté là…

J’ai peut être une piste finalement…

J’ai suspecté un problème de borg et j’ai du coup essayé d’initialiser à la main des repo borg. Et là j’ai tilté que je mettais sudo devant ma commande: sudo borg init [...]
Du coup j’ai tenté un sudo ssh yunohost@raspberrypi.local et effectivement il me demande bien un mot de passe!

J’ai donc regénéré une clé pour l’utilisateur root que j’ai collé dans mon pi… et là je peux faire “à la main” du sudo borg init [...]!

Sauf que… ça ne marche toujours pas pour la commande de backup de yunohost.
Du coup je suis perplexe car la commande est: sudo yunohost backup create -n test --methods borg_app --debug.
Il y a bien sudo devant!

Est ce que le loup pourrait provenir de là?

Le moins que l’on puisse dire c’est que mon sujet n’enflamme pas les foules :sweat_smile:

N’ayant trouvé aucune info supplémentaire sur la toile, j’ai changé mon fusil d’épaule et j’ai été voir dansle code. J’aurais dû le faire plus tôt, j’ai trouvé tout de suite…
Dans /etc/yunohost/hooks.d/backup_method/05-borg_app:

if ssh-keygen -F "raspberrypi.local" >/dev/null ; then
    BORG_RSH="ssh -i /root/.ssh/id_borg_ed25519 -oStrictHostKeyChecking=yes "
else
    BORG_RSH="ssh -i /root/.ssh/id_borg_ed25519 -oStrictHostKeyChecking=no "
fi
repo=ssh://yunohost@raspberrypi.local/~/backup   #$4

En fait après installation de borg_ynh, le système à déjà sa propre paire de clés disponible dans /root/.ssh/id_borg_ed25519.pub, c’est donc celle ci qu’il faut copier sur le serveur de backup!!

Et là, oh joie, la backup se fait correctement sans avoir de demande de mot de passe! :tada:

J’attends encore avant de sortir l’émoticone :champagne: , j’ai encore un problème de path pour la destination du backup.
Le backup se fait dans le $HOME de mon user si je copie id_borg_ed25519.pub dans authorized_keys, mais ça ne marche plus si je la place à la fin de command=\"borg serve --storage-quota 50G --restrict-to-repository /media/usbdisk/Yunohost\",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc. Dans ce cas là, l’authentification echoue de nouveau et j’ai une demande de mot de passe.

Je pourrais ruser en modifiant le path du backup dans le script borg_ynh, mais ça serait un patch vraiment crado.
Ou sinon monter le home de mon user directement sur le disque USB, çà pourrait être une solution temporaire en attendant de trouver la vraie raison.

En tout cas, j’ai quand même un embryon de solution pour un backup chiffré automatique de mon instance yunohost sur mon cloud hubic! :partying_face:

Bonjour et bienvenue dans la communauté des “Yunohosters” :wink:
J’avoue humblement que ton cas d’usage est bien au dessus de mes moyens et connaissances !
Es-tu sûr que ton problème n’est pas lié à l’usage d’une machine virtuelle pour Yunohost ?
Je ne me serais pas lancé dans de telles opérations de config sans être sur mon matériel cible, mais bon tu as l’air d’en connaître un rayon.
En espérant que tu parviennes à tes fins !

Merci @Limezy :slight_smile:

En ce qui concerne le problème d’authentification, ce n’est pas lié à la VM mais à mon raspberrypi. Je ne m’explique pas pourquoi, j’ai cherché un peu partout mais l’usage des “restricted ssh commands” ne fonctionne pas chez moi même avec les exemples les plus simples du monde trouvés sur le web.
Du coup je zappe cette partie, vu que l’on parle de 2 machines stockées chez moi avec pour seul et unique utilisateur moi même… D’un point de vue sécurité sur un vrai serveur dans la vraie vie je dis pas, mais là ça me ramène un lot d’ennuis inutiles pour mon utilisation.

Et je n’ai pas pu résoudre mon problème de path non plus, là faute à yunohost qui veut à tout prix que le backup se fasse dans ~/backup. J’ai essayé de ruser en modifiant le path à la main dans le script de backup, en mettant un lien symbolique vers mon disque USB, en utilisant la commande mount --bind, rien à faire le script de backup plante avec une jolie backtrace:

47820 ERROR Échec de l’exécution du script : /etc/yunohost/hooks.d/backup_method/05-borg_app
Traceback (most recent call last):
  File "/usr/lib/moulinette/yunohost/hook.py", line 283, in hook_callback
    no_trace=no_trace, raise_on_error=True)[1]
  File "/usr/lib/moulinette/yunohost/hook.py", line 397, in hook_exec
    raise YunohostError('hook_exec_failed', path=path)
YunohostError: Échec de l’exécution du script : /etc/yunohost/hooks.d/backup_method/05-borg_app

:confused:

Bon là par contre c’est plus ennuyeux, parce que je ne peux pas backuper tout mon yunohost sur une carte SD de 8Go…
Je pense que je vais devoir éditer mon fstab pour directement monder mon /dev/sde sur /home pour mettre physiquement mon home sur le DD externe.
Sinon il reste la solution donnée dans le 1er tuto que j’avais donné en lien, à savoir tout refaire “à la main” sans utiliser l’appli borg officielle, mais là on perd vraiment l’intérêt du truc…

Ceci dit, notez que ce dernier problème ne concerne que mon setup car j’utilise à raspberry avec le système sur une carte SD. Si j’installais le système sur un disque dur externe ou sur un PC classique je n’aurai absolument pas ce cas de figure!

Bonjour,
Perso, ce n’est pas que le sujet ne m’intéresse pas, loin de là, mais il est un peu (beaucoup) en dehors de mon champ de compétences :sweat_smile:
Sur mon Pi3 j’ai tout installé sur le disque sata externe vu que mes cartes SD ont une durée de vie très limitée avec moi :slight_smile:
Concernant la place sur la carte SD, je pourrai suggérer de déplacer ensuite la sauvegarde vers un autre répertoire, sur le disque externe. Par contre cela ne résoud pas le souci “d’usure” de la carte.
Il semblerait d’après le fichier backup.py que le chemin de sauvegarde y soit inscrit “en dur” :

BACKUP_PATH = ‘/home/yunohost.backup’

ARCHIVES_PATH = ‘%s/archives’ % BACKUP_PATH

(tout ça si c’est bien ce fichier qui gère la sauvegarde voulue ici)

De là, soit modifier ce fichier chez soi, mais il sera certainement remplacé à chaque mise à jour de yunohost et le souci reviendra, ou via une manipulation linux (dont je n’ai aucune idée, mais ça pourrait être le déplacement de /home sur une autre partition??) rediriger les enregistrements ailleurs que sur la carte SD. Là, je ne sais pas trop pourquoi un lien symbolique ne marche pas :thinking:
Un truc avec /etc/fstab, genre ajouter à la fin :
/dev/sdX /home/backup ext4 user,auto 0 0
où /dev/sdX correspond à une clé usb/disque externe, /home/backup le répertoire normal des backups, etc.
Attention! C’est un vague souvenir d’un truc pour monter un répertoire réseau comme s’il était local, il faudrait vous renseigner plus avant de copier-coller cette ligne dans votre fichier /etc/fstab

[edit] : l’idée dans fstab est de changer le point de montage du disque externe sur le répertoire , normalement ce qu’on enregistrera dans ce répertoire sera en fait sauvé sur le disque externe (ne m’en voulez pas si je raconte des bêtises :wink:
Un lien symbolique normalement ferait un peu pareil :
ln –s /montage/durépertoire/backup/externe /home/yunohostbackup
a priori il faudrait que /home/yunohostbackup n’existe pas à ce moment, la commande ls le créant alors.
https://doc.ubuntu-fr.org/lien_physique_et_symbolique

Bonne chance o/

Merci pour ta réponse, mais attention!
Le fichier backup.py concerne les sauvegardes par défaut effectuées sur la machine yunohost elle même.
Dans le cas de ce topic je parle d’une sauvegarde distante sur une autre machine, et ce backup est géré par l’application borg et non plus par le script backup.py :wink:

Je n’ai pas eu le temps de faire les modifs aujourd’hui, mais la dernière section de ta réponse correspond effectivement à ce que je vais faire sur mon raspberrypi distant: monter le $home qui va bien sur le disque externe du raspberry.

Quand j’aurais finalisé la procédure de A à Z je ferai un récap sur ce topic pour le clore.

Bon et bien je me suis arraché les cheveux pour pas grand chose… :relieved:
J’ai reçu mon raspberrypi et j’ai donc remisé la VM au placard.

Je refais toute la séquence d’installation, et j’en profte pour monter /home/yunohost sur un disque externe sur mon serveur de sauvegarde. Et là je me reprends la backtrace! Alors que ça marchait avec la VM! :face_with_symbols_over_mouth:

Après avoir pesté pendant 5min, je m’apperçois que les autorisations/propriétaires du dossier backup ne sont pas super propres. Je remets tout d’équerre avec chmod et chown et ça remarche, ouf! :sweat:

Du coup j’enlève le montage de la partition /home/yunohost sur le disque externe pour retester avec un simple lien symbolique - en faisant gaffe aux permissions/propriétaires cette fois - et c’est bon! :tada:

Voilà, heureux je suis! :sunglasses: Je peux donc sauvegarder toute mon installation yunohost sur mon serveur de sauvegarde à l’emplacement choisi, et balancer tout ça sur mon cloud hubic dans la foulée!

Pour clore le topic j’essaierai de faire une récap claire dans un seul post, ça sera plus lisible que de relire tout le fil…

How to mis à jour:

1 Like

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.