You just have to install mailutils
2 Likes
sudo apt-get install ccrypt mailutils
then
sudo yunohost app install https://github.com/YunoHost-Apps/fallback_ynh/ --verbose
and both installation completed. Thanks a lot @Maniack_Crudelis!
1 Like
Salut,
J’ai pas encore testé mais je trouve que c’est une super app ! Ça peut vraiment sécuriser l’auto-hébergement à la maison, alors que pour l’instant, si mon serveur tombe alors que je suis en vacances, c’est compliqué…
J’ai quelques questions sur le futur de cette app :
- Est-ce que l’utilisation de borg est prévue ? Ça permettrait de limiter encore la taille des backups et les débits entre les 2 serveurs
- On pourrait automatiser la relève : si le serveur principal ne répond pas pendant 12h par exemple, on lance le fallback. Et avec un vpn, on n’a pas de dns à changer. Est-ce que ça vous semble faisable ?
- encore plus dans le futur : pour le serveur secondaire, ça serait cool d’avoir une app yunohost (ou un autre moyen) permettant de l’installer simplement sur une instance yunohost qui est utilisée (non dédiée uniquement au fallback), peut-être via une VM ou docker. Ça rendrait vraiment simple l’échange de backup/fallback entre 2 utilisateurs de yunohost.
Merci en tout cas, et je vais essayer de la tester bientôt.
Non, car je n’utilise pas borg. Toutefois, son usage n’est pas exclus. Il serait probablement plus intéressant de se pencher sur la question avec l’app Archivist, car elle permet facilement l’inclusion d’autre méthode d’export des backups. Et le mécanisme est approximativement le même.
Il serait dés lors plus simple de l’implémenter sur cette app par la suite.
Ça implique un VPS ou un moyen de changer l’ip automatiquement. Mais c’est faisable.
Il serait possible de détecter la disponibilité du serveur depuis le fallback.
Je te propose d’ouvrir une issue sur le dépôt de l’app pour garder ça de côté.
C’est plus compliqué, sauf à utiliser un conteneur lxc. Mais la redirection de port dans un conteneur lxc n’est pas trivial. Et héberger un fallback sur un serveur déjà utilisé posera des problèmes sur la disponibilité des ports.
Par contre pour l’échange de backup, il y a les apps Archivist et ssh_chroot_dir qui permettent cet usage. Un post du forum présente cet usage: [Archivist] Backup your server with rsync.
Ok, j’ai créé des issues sur les app respectives.
Merci pour Archivist et ssh_chroot_dir, je ne les avais pas vu, elles sont bien pratiques !
Bonjour,
désolé pour le déterrage de topic mais je n’ai rien trouvé de plus récent sur le forum.
Une chose me turlupine sur le principe du serveur de secours… c’est comment le serveur principal communique avec le serveur de secours…
Pour faire le test, j’ai installé l’application sur le serveur principal et crée un ynh de secours avec installation de l’appli en mode fallback server sur une virtualbox… donc sur le même réseau (je suis en auto hébergement)…maintenant, comment le serveur principal fait le lien avec le serveur secondaire?
merci de vos lumières
Bon,
en fait chui vraiment une buse…
le lien se fait dans la configuration du main server dans la partie “domain ou ip address”…
Par contre pour vérifier que cela fonctionne, je ne trouve pas la commande CLI pour lancer une sauvegarde en manuel dans /opt/yunohost/fallback/
Merci de votre aide
Salut,
Alors j’essaye de mettre en place fallback_server, mais sans succes pour l’instant 
Pour une raison inconnue, je ne reçois pas de mail avec ma clé public lors de l’installation. Par contre, je la copie-colle sur le serveur 2. Mais il m’indique toujours un problème pour se connecter (mail reçu tous les matins…) :
Raspbian GNU/Linux 9
Permission denied, please try again.
Permission denied, please try again.
Permission denied (publickey,password).
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(235) [sender=3.1.2]
Sinon j’essaye directement avec la commande suivante :
sudo -u root /opt/yunohost/fallback/send_process/./send_backup.sh
Et là, il me demande le mot de passe pour fallback@mondomainedebackup.fr, mais il n’y en a pas je crois.
Quelqu’un à une idée ?
1 Like
Bonjour,
j’ai encore une incompréhension dans l’installation… pour la partie fallback server cette fois -ci…
c’est à propos de la clé publique… à priori, elle est de la forme:
ssh-rsa AAAA.......== root@NDD.TLD
doit on intégrer le tout ou bien seulement la partie
AAAA.....==
ou bien
AAAA....== root@NDD.TLD
Merci de votre aide
Hi guys, sorry that I’m not so available lately.
@fidoboulettes, to run a backup manually, run /opt/yunohost/fallback/send_process/send_backup.sh as root.
And for your second question, put your entire key.
@ludovic That’s strange indeed that you didn’t receive the email.
As the log is not explicit, try to add -v to the ssh options at the beginning of the script send_backup.sh. Or try to have a look to the ssh log on the fallback server. It could happen that the server refuse the key.
Thanks for your answer !
You migth have answer my issue because I was not coping the root@NDD.TLD for my key…
I will try again, looking for the log you mentionned and adding the -v option.
Unfortunately, it will have to wait a couple a days before I try.
Cheers, et encore merci 
Hello Maniak,
merci de tes précisions…
bon, j’ai un problème…
Donc déja, pour faire le test, j’ai le serveur de secours sur une VM où il n’y a que fallback d’installé.
Lors de l’installation du “Main server”, je configure l’adresse du fallback server en IP (et non en nom de domaine)…
Le backup à l’air de bien se passer (une seule appli pour tester)
voici ce que je j’obtiens:
/opt/yunohost/fallback/send_process/send_ backup.sh
Make a temporary backup for system_fallback_bck
This backup is different than the previous one
Make a real backup for system_fallback_bck
Now creating a backup archive from the files collected…
Backup created
name: system_fallback_bck
results:
apps:
system:
conf_cron: Success
conf_ldap: Success
conf_nginx: Success
conf_ssowat: Success
conf_xmpp: Success
conf_ynh_certs: Success
conf_ynh_currenthost: Success
conf_ynh_mysql: Success
data_mail: Success
size: 18203644Encryption of system_fallback_bck
Make a temporary backup for ttrss_fallback_bck
This backup is different than the previous one
Make a real backup for ttrss_fallback_bck
Collecting files to be backuped for ttrss…
[+++++…] > Loading installation settings…
[#####++…] > Backing up the main app directory…
[#######+++…] > Backing up nginx web server configuration…
[##########++…] > Backing up php-fpm configuration…
[############+++…] > Backing up the MySQL database…
[###############++…] > Backing up systemd configuration…
Now creating a backup archive from the files collected…
Backup created
name: ttrss_fallback_bck
results:
apps:
ttrss: Success
system:
size: 24044581
Encryption of ttrss_fallback_bck
Encryption of config.conf
Encryption of app_list
Send the archives on the server 192.168.1.10
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:kNrEbAGJCJ7miZoLnTD1PecTxYq+q4+uHCnX+/I8+hM.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending RSA key in /root/.ssh/known_hosts:4
remove with:
ssh-keygen -f “/root/.ssh/known_hosts” -R 192.168.1.10
ECDSA host key for 192.168.1.10 has changed and you have requested strict checking.
Host key verification failed.
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(235) [sender=3.1.2]
Je suis allé commenter la ligne correspondante dans /root/.ssh/known_hosts à tout hasard pour voir si ça me recreait une nouvelle entrée mais rien… je ne comprends pas bien d’où vient le problème.
That’s a common issue with ssh, either you use the command ssh-keygen -f “/root/.ssh/known_hosts” -R 192.168.1.10 as explain in the message, or you remove the line 4 of the same file.
You may have to do it many times to clean it all.
It works 
Thanks Maniack for your work
reste plus qu’à tester en grandeur nature
hi 
thx for your work !
i have some issue too with the email not sent before the ask for the ssh key during the master deploy, i didn’t give any key and continue the install,
i recieved the mail after the install with the key in the installation confirmation mail : 
🆈🅽🅷:cloud:: fallback has just been installed!
here is the cli output :
https://krashboyz.org/zerobin/?1f307bb43fb76514#8Lv9SVNx6PyAl/IfcChTBCmKeSwFQYueckjQVDJZbss=
do you want i create an issue in the github ?
EDIT : i am the bug : the asked key is ONLY for the fallback server (the failover one, the slave) not the main one (master)
Hi isAAAc
Not sure I get your problem.
Could you explain more precisely what the issue and what did you expect.
1 Like
step 1 start install on MASTER ynh server
step 2 the fallback install ask me a key, i check my mails nothing, nor a fallback new user on the system
so i don’t enter any key and continue the install
step 3 install end and i have a final mail of confirmation of the install in my mailbox, and this mail give me the asked key during the install in step 2
i expected to have the key BEFORE the step 2, without any key given before the step 2, i don’t see how i can specify it in step 2 … (do you understand ?)
now how can/should i fix this on my MASTER system ?
i’m lost in this installation process
i 'll try the install on the slave/failover server right now
thx for your help
EDIT : i’m stupid, and need to read better, the output was clear … [fallback server seulement] for the asked key, not for the main server …
ok i think everything is ok ,
my apologies
perhaps the install process could be improved if the request for the “[fallback server only]” are not requested during the “main server” install,
and same in the other side, “[main server only]” not requested during the “fallback server” install, depends of the first choice at the beginning of the process :
Choose which kind of installation you want. [main server | fallback server] (default: main server)
so no confusion
i was confused with this (yes … my eyes are old 
, i need to accept that … 
)
I would love to do that, but we currently have no way to have an interactive manifest that would ask questions depending of what you’ve answered before.
So, unfortunately, I can’t split the questions to have only those that are relevant for each type of installation.
for tracking : the migration is related here on github : https://github.com/YunoHost-Apps/fallback_ynh/issues/17