Oui car la conf ssh_config fait référence à la conf client (et sshd la conf serveur), donc relative à ce qu’il se passe si tu essayes de te connecter à un serveur depuis cette machine. Ca n’a effectivement probablement pas de sens apriori d’y trouver les memes noms d’options que dans la conf serveur
/
Hello,
It seems to me that archivists do not really appreciate the changes concerning the compression of archive
Bonjour,
Il me semble qu’archiviste n’apprécie pas trop les changements concernant la compression des archives :
Build list of files to backup
Password has been changed.
md5sum: na: Aucun fichier ou dossier de ce type
Compress backups
Backup YunoHost core and apps
Make a temporary backup for agendav_backup
usage: yunohost {backup} …
[-h] [–output-as {json,plain,none}] [–debug] [–quiet]
[–timeout ==SUPPRESS==] [-v]
yunohost: error: unrecognized arguments: --no-compress
/
I tried to remove the --no-compress command from the archivist.sh file, but it’s not that easy …
J’ai essayé de supprimer la commande --no-compress du fichier archiviste.sh, mais ce n’est pas aussi simple …
J’ai exactement le même soucis !
Indeed…
Work in progress here Allow to choose the compression algorithm by maniackcrudelis · Pull Request #12 · mcrudelis/archivist · GitHub
Fixed by this PR Fix YunoHost 4.1 by maniackcrudelis · Pull Request #29 · YunoHost-Apps/archivist_ynh · GitHub
You can also choose not to compress your backups or with which algorithm you want to do it.
Merci !
FR
Par contre j’obtiens ce message d’erreur lorsque je veux me rendre sur le config-panel :
Erreur lors de l'analyse de l'argument de mot de passe 'YNH_CONFIG_MAIN_ENCRYPTION_ENCRYPTION_PWD' : l'argument de mot de passe ne peut pas avoir de valeur par défaut pour des raisons de sécurité
Je précise que je n’utilise pas le chiffrement pour les sauvegardes.
ENG
On the other hand I get this error message when I want to go to the config-panel :
Erreur lors de l'analyse de l'argument de mot de passe 'YNH_CONFIG_MAIN_ENCRYPTION_ENCRYPTION_PWD' : l'argument de mot de passe ne peut pas avoir de valeur par défaut pour des raisons de sécurité
I specify that I do not use encryption for backups.
logs : hastebin
Seen that too, reported here Broken config-panel · Issue #1709 · YunoHost/issues · GitHub with 2 PR ongoing to fix it.
By the way, glad to know some users are actually using those features. I ended up thinking no one would ever use it…
Also, since it doesn’t work, I haven’t tested the new options in the config-panel.
It’s working better now !
Thanks !
Hello,
While working on Borg to understand how it works, I’m trying to improve my backup system.
I’ve attached a NAS to my main yunohost server and run a script that contain the following, 2 hours after archivist.sh (I added a line in /etc/cron.d/archivist) :
rsync -avzh -e ssh user@serverB.fr:/home/yunohost.app/archivist/backup/ “/mnt/NAS/backup/srvB”
rsync -avh /home/yunohost.app/archivist/backup/ “/mnt/NAS/backup/SrvA”
The first line retrieves the archival backup from a remote server and copies it to my NAS and the second line takes the local backup and copies it to my NAS.
Is there a more elegant way to do it ?
Another question, in archivist log I can see :
Erreur : Script de sauvegarde ‘conf_ssh’ inconnu
Erreur : Script de sauvegarde ‘conf_ssowat’ inconnu
Erreur : Script de sauvegarde ‘conf_ynh_firewall’ inconnu
Erreur : Script de sauvegarde ‘conf_xmpp’ inconnu
Erreur : Script de sauvegarde ‘conf_nginx’ inconnu
Erreur : Script de sauvegarde ‘conf_cron’ inconnu
Erreur : Script de sauvegarde ‘conf_ynh_currenthost’ inconnu
Is this a problem?
Probably again a modification of the backup command… Again…
Could you please open an issue about that, so I can have a look to it when I have some time…
Not sure to get the idea of your rsync commands, if you need to send your backup to multiple places, archivist can do it, you just have to add multiple recipients.
Yes sure, I’ll do that.
You are right, I can use seeders to send the backup to my NAS via my local Yunohost server. I was trying to make something complex that can be simple… as usual…
I have the same messages since the last yunohost update (4.2)
I add an issue : Issues · YunoHost-Apps/archivist_ynh · GitHub
Hello,
I’m using the sender “local” to copy archivist backup to a local path.
And I have the following error
Build the list of files for the recipient local example
Copy backups files in /mnt/NASbck/backup/srv/.
building file list … done
rsync: chown “/mnt/NASbck/backup/srv/.” failed: Operation not permitted (1)
rsync: delete_file: unlink(enc_backup_list) failed: Permission denied (13)
rsync: delete_file: unlink(backup_list) failed: Permission denied (13)
rsync: delete_file: unlink(.encfs6.xml.encrypted.cpt) failed: Permission denied (13)
rsync: delete_file: unlink(.encfs6.xml) failed: Permission denied (13)
.d…t.og… ./
rsync: chown “/mnt/NASbck/backup/srv/ynh_backup” failed: Operation not permitted (1)
It’s working manually if I don’t use sudo.
To which user should I give permission to the destination folder ?
Maybe I should just remove sudo from “local.sender.sh” …
The cron task use root.
I don’t remember why I did put a sudo in the first place…
/
I think I’ve found the reason why Archivist’s rsync doesn’t work as expected in my case. And, as I understand it, this can happen with any application that has interaction with files.
On my yunohost server, I have mapped a network share to NFS.
By default, on a file server with an NFS service, there is a rootsquash
security option which makes root on a client system have the same privileges as the nobody
user.
So, using sudo
gives low-level access to the NFS share.
There is a No-Root-squash
option that exists in the NFS share configuration on the server side, but on my old NETGEAR Duo NAS, I don’t have access to this option …
I have configured the NFS rights on my NAS differently (I checked: guest has full access).
Now the archivist sender “rsync via ssh” from my remote Yunohost server to the local server works fine.
But the “local” archivist sender, on my local server, still gives me errors on the chown, mkdir and mkstemp commands that Rsync is trying to run.
rsync: chown "/mnt/NASbck/backup/srva/." failed: Operation not permitted (1)
rsync: recv_generator: mkdir "/mnt/NASbck/backup/srva/ynh_backup" failed: Permission denied (13)
rsync: mkstemp "/mnt/NASbck/backup/srva/ynh_backup/.agendav_backup.tar.gz.ZRJzQ1" failed: Permission denied (13)
I tried removing sudo
before the rsync
command in the local sender, but the result is the same.
Is there a solution?
Maybe I should go through a CIFS share …
/
Je pense avoir trouvé la raison pour laquelle rsync d’Archiviste ne fonctionne pas comme prévu dans mon cas. Et, si j’ai bien compris, cela peut arriver avec n’importe quelle application qui a une interaction avec des fichiers.
Sur mon serveur yunohost, j’ai mappé un partage réseau avec NFS.
Par défaut, sur un serveur de fichiers avec un service NFS, il y a une option de sécurité rootsquash
qui fait que root sur un système client a les mêmes privilèges que l’utilisateur nobody
.
Donc, l’utilisation de sudo
donne un accès avec peu de droits sur le partage NFS.
Il y a bien une option No-Root-squash
qui existe dans la configuration du partage NFS, côté serveur, mais sur mon vieux NAS NETGEAR Duo, je n’ai pas accès à cette option …
J’ai configuré différemment les droits NFS sur mon NAS (j’ai coché : invité a un accès complet).
Maintenant, le sender d’archiviste “rsync via ssh” de mon serveur Yunohost distant vers le serveur local fonctionne bien.
Mais le sender d’archiviste “local”, sur mon serveur local, me donne encore des erreurs sur les commandes chown, mkdir et mkstemp que Rsync cherche à lancer.
rsync: chown "/mnt/NASbck/backup/srva/." failed: Operation not permitted (1)
rsync: recv_generator: mkdir "/mnt/NASbck/backup/srva/ynh_backup" failed: Permission denied (13)
rsync: mkstemp "/mnt/NASbck/backup/srva/ynh_backup/.agendav_backup.tar.gz.ZRJzQ1" failed: Permission denied (13)
J’ai essayé en retirant sudo
devant la commande rsync
dans le sender local, mais le résultat est le même.
Est-ce qu’il existe une solution ?
Il vaut peut-être mieux que je passe par un partage CIFS …
Ça marche mieux avec un partage CIFS
Je n’ai plus de message d’erreur !
/
It works better with a CIFS share
I don’t get any more error messages!
No more error message after the udpate.
Thanks !
Sorry for the necropost. I plan to use Borg Backup once I have completed several other steps in my YNH deployment project, but until that is installed I intend to use
rsync
for several backups, including one right at the very start of my project, when the only thing that I will have accomplished by then is burning the YunoHost v4.1.7.2 iso image onto the µSD-card, even before the initial booting of YunoHost, before I have even run
yunohost tools postinstall
on it. I want to take several backups even before the stage that I’ll be able to install apps such as Archivist. Can someone please advise me on using rsync
manually from the terminal, without any scripts involved, just plain CLI instructions? I assume that I would need to ssh into the YunoHost machine (I’m running YNH on a Raspberry Pi 4) from my laptop (which is running
Ubuntu), and execute the commands from there, right? I’m not yet confident with
rsync
, but I am sure it is possible to do this from the terminal, without having to install anything else. Is that right?
Oupss, I just figured out, that this is an old post …
Sorry
Hello @frittro,
if you want to use rsync manually, you’ll a lot of example on some webpages. Search with DuckDuckGo or Qwant for “rsync ssh”, and you’ll find pages like these : https://linuxize.com/post/how-to-transfer-files-with-rsync-over-ssh/
https://linuxize.com/post/how-to-transfer-files-with-rsync-over-ssh/https://linuxize.com/post/how-to-transfer-files-with-rsync-over-ssh/
Good luck,
Cyril