[mOved] [F] Solution de sauvegarde générique - Page 2

Ça a l'air beaucoup mieux, et l'ascii art du début aide beaucoup, j'ai enfin fait fonctionner mon premier backup

Du coup après re(re)lecture je confirme que je n'avais pas du tout compris ce qu'était la section "global" et je continue de penser que ce nom n'aide vraiment pas à saisir le concept (je suggère "storage", "repository", ou n'importe quoi qui sous-entende qu'il s'agit de configurer la façon de stocker les données des sources définies après)

Il n'y a plus que deux problèmes de mon côté : le fait de devoir ajouter | cat au bout de chaque commande pour ne pas avoir d'erreur d'encoding, et les fichiers de configuration que polyarchiv essaie de chercher dans /etc au lieu de /etc/polyarchiv par défaut. En-dehors de ça, ça a l'air tout bon

Voilà, j'ai changé en « repository ». J'ai au passage corrigé le problème du /etc, un simple oubli de ma part et uploadé une nouvelle version.

Je vais travailler sur le problème d'encodage, je ne comprends pas trop comment ça se produit.

Ensuite, je travaille sur la restauration des données, et sur un nouveau type de dépôt distant : chiffrement local individuel des fichiers via GPG, nombre d'archive conservées, etc. En contrepartie, il y aura moins de possibilités pour le transport.

Je pense pouvoir faire du git chiffré également.

Je n'ai pas encore essayé la nouvelle version, mais pour l'erreur que j'obtiens quand je ne redirige pas stdout je pense que c'est un cas assez classique. Ma locale est en ISO-8859-1 (je n'ai rien changé), donc sys.stdout.encoding aussi. Quand tu fais un print() Python déclenche une conversion implicite UTF-8 => ISO-8859-1 vu que tu as l'air d'utiliser de l'unicode en interne, sauf que certaines de tes chaines contiennent des caractères qui n'existent que dans le jeu unicode. J'imagine qu'il s'agit des caractères que tu utilises pour avoir une sortie colorée, vu que c'est le seul comportement qui a l'air de changer quand on redirige stdout (cf. termcolor.py ligne 117).

Comme tu vérifies que sys.stdout possède bien une propriété encoding, tu peux en profiter pour faire la conversion explicitement et ajouter le paramètre "ignore" au lieu de laisser print() le faire (et lancer une exception quand ça ne passe pas)

Ah ok, je pensais que tu étais totalement UTF-8. Je comprends mieux l'erreur, et j'ai au final supprimé tout caractère qui ne tient pas en latin1.
En plus, le comportement est subtilement différent en python2 et python3

Si jamais tu as les sources, peux-tu lancer « python tests/test_encoding.py ; python3 tests/test_encoding.py; python tests/test_encoding.py | cat ; python3 tests/test_encoding.py | cat » ?

Merci bien !

Un locale non-UTF-8??? En 2016???

./34 ; je n'ai plus les sources mais j'essaierai à l'occasion
./35 : he oui, j'ai pris ça sans modification et je n'ai quand même pas d'UTF-8

C'est étrange, quand je fais un vagrant ssh, mes LC_ALL et LC_LTYPE sont hérités de mon shell d'origine (comme toujours avec ssh, à ma connaissance) et du coup j'ai bien tout en fr_FR.UTF-8.

Pour le coup je fais un SSH depuis Windows donc je ne sais pas trop de quoi il hérite, mais ça explique probablement pourquoi il se retrouve en ISO-8859-1. Je regarderai s'il y a moyen de définir explicitement le jeu de caractères.

au moins, ça m'a permis de corriger le problème. Tout ça parce que j'avais oublié que ‘ et ’ n'étaient pas dans ISO-8859-1… ^^

je suis en train de créer un Vagrant pour tester tous les types, je sens que je vais avoir des surprises
Au passage, git est franchement pénible à avoir un fichier de conf global qui se change en modifiant la variable $HOME :/

./34 : voilà le résultat des tests :vagrant@limestone:~/PolyArchiv$ python tests/test_encoding.py *** python2 *** LC_ALL=, LC_CTYPE= sys.stdout.encoding=ISO-8859-1, sys.stdout.isatty()=True accents:▒▒ vagrant@limestone:~/PolyArchiv$ python3 tests/test_encoding.py *** python3 *** LC_ALL=, LC_CTYPE= sys.stdout.encoding=ISO-8859-1, sys.stdout.isatty()=True accents:▒▒ vagrant@limestone:~/PolyArchiv$ python tests/test_encoding.py | cat *** python2 *** LC_ALL=, LC_CTYPE= sys.stdout.encoding=None, sys.stdout.isatty()=False accents:éè vagrant@limestone:~/PolyArchiv$ python3 tests/test_encoding.py | cat *** python3 *** LC_ALL=, LC_CTYPE= sys.stdout.encoding=ISO-8859-1, sys.stdout.isatty()=False accents:▒▒Seul le 3ième est lisible. Les deux premiers s'affichent en rouge, les deux derniers en blanc (je ne sasi pas si ça correspond à un test échoué ou non).

Sinon je viens de refaire l'essai, avec une Ubuntu Xenial toute neuve sur laquelle la seule commande que j'ai effectué est "apt-get install ansible" (j'ai du mal à croire que ça soit le responsable), voilà ce que j'ai quand je me SSH depuis Windows :$ uname CYGWIN_NT-6.1 $ locale LANG=fr_FR.UTF-8 LC_CTYPE="fr_FR.UTF-8" LC_NUMERIC="fr_FR.UTF-8" LC_TIME="fr_FR.UTF-8" LC_COLLATE="fr_FR.UTF-8" LC_MONETARY="fr_FR.UTF-8" LC_MESSAGES="fr_FR.UTF-8" LC_ALL= $ vagrant ssh limestone Welcome to Ubuntu 16.04 LTS (GNU/Linux 4.4.0-21-generic x86_64) * Documentation: https://help.ubuntu.com/ ---------------------------------------------------------------- Ubuntu 16.04 LTS built 2016-04-26 ---------------------------------------------------------------- Last login: Sun May 15 07:35:37 2016 from 10.0.2.2 vagrant@limestone:~$ locale LANG=en_US LANGUAGE=en_US: LC_CTYPE="en_US" LC_NUMERIC="en_US" LC_TIME="en_US" LC_COLLATE="en_US" LC_MONETARY="en_US" LC_MESSAGES="en_US" LC_PAPER="en_US" LC_NAME="en_US" LC_ADDRESS="en_US" LC_TELEPHONE="en_US" LC_MEASUREMENT="en_US" LC_IDENTIFICATION="en_US" LC_ALL= vagrant@limestone:~$ python Python 2.7.11+ (default, Apr 17 2016, 14:00:29) [GCC 5.3.1 20160413] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.stdout.encoding 'ISO-8859-1'Vous voyez une raison pour laquelle je me retrouve en ISO-8859-1 par défaut ?

Pour le rouge ou blanc, c'est simplement qu'il détecte le pipe et ne met pas de couleur dans ce cas (histoire de ne pas se traîner de codes couleurs).
À part ça, ton terminal est en UTF-8, mais LC_CTYPE n'est pas défini et il doit alors prendre par défaut du ISO-8859-1 comme encodage de stdout.
Avec Python 2 et un pipe, l'encodage de stdout n'est pas défini, du coup je prends de l'UTF-8 par défaut et ça fonctionne. Malheureusement, c'est plus du hasard qu'autre chose

En mettant LC_TYPE=fr_FR.UTF-8, tu ne devrais plus avoir de problème.

Moui, enfin reste qu'il n'est pas défini par défaut, du coup je vois pas bien pourquoi je devrais le définir manuellement :/ (surtout que ça n'a pas l'air de poser de problème à d'autres softs que Python, pour le moment)

Zeph (./42) :
(surtout que ça n'a pas l'air de poser de problème à d'autres softs que Python, pour le moment)

Je ne vois que deux possibilités :
* ils n'utilisent que des caractères ASCII (je suis parti sur cette solution, du coup)
* ils font de toute façon de l'UTF-8

Bon, je progresse petit à petit, notamment avec une VM (Vagrant) pour pouvoir tester l'ensemble des types sources et de dépôts distants. C'est d'ailleurs un peu pénible de devoir installer un Gitlab automatiquement uniquement pour pouvoir pusher dedans.

On peut d'ailleurs utiliser Gitlab (clone de Github) es dépôt distant avec une création automatique de projets pour sauvegarder dedans ^^ Ça permet d'avoir un versionning automatique avec une IHM pour afficher les fichiers

Je commence à travailler pour faire un backend de stockage FTP/WebDAV/SSH/fichier permettant de :
* lister les fichiers (nécessaire pour supprimer de vieilles archives, cf. le commentaire de RHJPP)
* créer automatiquement les dossiers intermédiaires nécessaires

Est-ce qu'il y a moyen d'utiliser polyarchiv sans installation ? Je voudrais simplement checkout dans /var/opt/polyarchiv et exécuter à partir de là, pour avoir une désinstallation qui consiste uniquement à supprimer le dossier.

J'ai essayé de récupérer le projet et d'appeler directement ./polyarchiv/cli.py mais :

- Aucun fichier n'a les droits en exécution par défaut, il faut donc les chmod +x
- Aucun fichier n'a de shebang, du coup c'est un shell qui est utilisé par défaut (et bien sûr ça ne va pas très loin)
- Exécuter directement "cli.py" semble n'avoir aucun effet (retourne 0 sans rien afficher, que ce soit sans argument ou avec -h)

Il y a un moyen de faire comme ça ?

Il y a un run.py qui a l'air de faire ce que tu veux ?

$ git clone https://github.com/d9pouces/Polyarchiv
Cloning into 'Polyarchiv'...
remote: Counting objects: 795, done.
remote: Compressing objects: 100% (176/176), done.
remote: Total 795 (delta 63), reused 0 (delta 0), pack-reused 619
Receiving objects: 100% (795/795), 769.52 KiB | 793.00 KiB/s, done.
Resolving deltas: 100% (495/495), done.
Checking connectivity... done.
$ python Polyarchiv/run.py -h
usage: run.py [-h] [-v] [-f] [-n] [-D] [--show-commands] [--confirm-commands]
              [--only-locals ONLY_LOCALS [ONLY_LOCALS ...]]
              [--only-remotes ONLY_REMOTES [ONLY_REMOTES ...]]
              [--config CONFIG]
              command

backup data from multiple sources

positional arguments:
  command               backup|restore|config|plugins

optional arguments:
  -h, --help            show this help message and exit
  -v, --verbose         print more messages
  -f, --force           force backup if not out-of-date
  -n, --nrpe            Nagios-compatible output
  -D, --dry             dry mode: do not execute commands
  --show-commands       display all bash executed commands
  --confirm-commands    ask the user to confirm each command
  --only-locals ONLY_LOCALS [ONLY_LOCALS ...]
                        limit to these local tags
  --only-remotes ONLY_REMOTES [ONLY_REMOTES ...]
                        limit to these remote tags
  --config CONFIG, -C CONFIG
                        config dir

nitro > sauf que l'installation enregistre les différents types disponibles : ainsi n'importe qui peut écrire d'autres types de dépôts et les enregistrer en plus sans avoir à toucher mon code.

J'ai quand même corrigé le truc : j'ai décrit tous les types disponibles dans un fichier 'engines.ini', qui est utilisé par setup.py pour enregistrer à l'installation, et par run.py pour les détecter si on le lance sans installation. Au passage, pkg_resources est maintenant facultatif

./46 : heu c'est curieux, je suis à peu près sûr que c'est celui que j'ai essayé de faire tourner en premier, mais peut-être que non. Je retente dès que j'ai le temps

Zeph > j'avais déjà un peu amélioré la situation

(oui, je prends soin de mes potentiels futurs utilisateurs !)

Bon je ne sais pas ce que j'avais fichu la dernière fois mais effectivement "run.py" fonctionne très bien. J'ai vu qu'entre temps tu l'avais passé en 755 donc c'est utilisable tout frais sorti de GitHub

Je vais commencer à remplacer mes scripts custom par des configurations PolyArchiv, pour l'instant j'ai l'impression que tout y est

[edit] Bon j'y suis pas encore

J'ai créé un unique fichier local en suivant ce que m'indique polyarchiv plugins -v :

available local repository engines:
  * engine=files

Il ressemble à ça :[repository] engine=files frequency=daily local_path=/etc/polyarchiv/local [sql] engine=mysql host=localhost port=3306 database=blabla user=blabla password=blabla destination_path=./fr_mirari_www.sqlMais quand j'essaie de le valider avec polyarchiv config -v j'ai l'erreur :
In file '/etc/polyarchiv/httpd_site__fr_mirari_www.local', section 'repository': invalid engine 'files'Sinon je crois que je suis toujours aussi perdu avec les concepts de "local repository" et "remote repository". Je m'attendrais à configurer d'un côté les sources à sauvegarder, de l'autre l'emplacement où les stocker, du coup je n'ai toujours pas vraiment compris pourquoi les deux types de fichiers (.local et .remote) doivent tous les deux spécifier une section repository avec un engine (qui n'est pas le même dans les deux cas d'ailleurs).

J'ai supposé que celui de mon fichier local pouvait être "files" pour collecter temporairement les fichiers quelque part, puis que celui du fichier remote pouvait être "tar" pour conserver des archives compressées, mais du coup le "repository" du fichier local me semble être une étape intermédiaire qui ne me sert à rien. Je l'aurais bien supprimée, mais il faut obligatoirement avoir une section repository dans les deux fichiers

(en fait Flan va lancer un support payant, c'est pour ça que c'est pas clair )

1) en effet, il y avait un bug qui était transparent chez moi
J'utilise simultanément deux moyens pour déclarer les types de base :
a) un fichier .ini qui fait partie des sources et qui est lu quand il est disponible (mais d'une part ça ne fonctionne plus après installation, et d'autre part ça ne permet pas d'utiliser des types tierce-partie)
b) une fonction fournie par les setuptools qui permet d'enregistrer des objets à l'installation (un peu comme une base de registre), afin d'utiliser des types tierce-partie, mais qui requiert une installation.

Le premier moyen avait un bug, mais c'était compensé de façon transparente par l'option b). C'est bien pour tous ces petits soucis que je bosse sur le script vagrant ^^

2) sauf qu'elle ne sert pas à rien : j'ai distingué une étape « collecte locale » puis « envoi » afin de pouvoir faire plusieurs types de collecte locale à l'avenir (fichiers plats ou git local pour l'instant). Je ne vois pas trop comment je pourrais faire pour m'en passer réellement (ou alors par défaut ça serait un dossier temporaire qui est effacé après). Au passage, la collecte locale pourrait très bien être dans un dossier SSH/FTP/NFS, ce qui rend les dépôts distants caducs ^^

1) OK, je mets à jour et je retente [edit] Tu es sûr d'avoir corrigé ? J'ai toujours le même message d'erreur
2) Je me doute qu'elle ne sert pas à rien, ce que je voulais dire c'est que j'ai du mal à comprendre le fonctionnement de cette partie (et peut-être que je ne suis pas le seul ?)

Bon, en vrai j'ai peut-être à peu près compris ce que ça fait, mais j'ai du mal avec le découpage et le choix des termes ce qui rend à mon sens la fonctionnalité difficile à comprendre. En gros j'ai l'impression qu'on a deux notions présentées comme indépendantes dans PolyArchiv : la collecte intermédiaire (le "engine" de "local repository") et la destination de sauvegarde (le "engine" de "remote repository"). Ce que je trouve curieux c'est qu'en vrai ces deux notions ne sont pas si indépendantes que ça, et du coup la frontière entre les deux n'est pas claire. Par exemple :

• J'imagine que le local repository "git" n'est compatible qu'avec le remote repository "git", du coup c'est une invitation à faire une configuration invalide si j'en combine un des deux avec un autre engine.
• Si je veux créer un fichier tar et l'envoyer via rsync, comme ces deux moteurs sont tous les deux des remote repositories c'est impossible ?
• D'ailleurs, avoir "tar" comme type de remote repository est curieux, c'est peut-être même celui-ci qui m'a fait réaliser qu'un remote repository n'était pas du tout ce que j'imaginais d'après le nom.
• Si je ne veux faire qu'une sauvegarde locale je vais être quand même obligé de déclarer un remote repository, ce qui ne parait pas vraiment intuitif.

Quelques suggestions en vrac qui rendraient à mon avis le soft et la documentation plus faciles à comprendre, à toi de voir si certaines te semblent sensées :

• Changer au moins l'un des deux noms, par exemple utiliser "backup format" au lieu de "local repository" et conserver "remote repository" pour l'autre (voire le renommer juste en "repository", pusiqu'il n'est pas forcément remote)
• Modifier "tar" pour qu'il s'agisse d'un backup format au lieu d'un repository : même si c'est inefficace je pourrais vouloir créer des archives tar et les commiter dans un repository git, il n'y a pas de raison à ce que ça ne soit techniquement pas faisable
• Supprimer "git" des backup formats, ne laisser que "git" dans les remote repositories et le laisser s'occuper à la fois du commit et du push (de cette façon je pourrais archiver tout ce que je veux dans git, très probablement je choisirai d'y mettre mes fichiers tels quels avec le backup format "files")
• Rendre la déclaration d'un ou plusieurs remote repository(ies) optionnelle (une fois les deux notions clairement séparées il n'y a pas de raison que je sois obligé d'envoyer mes backups quelque part)

Bon, j'ai encore beaucoup de progrès à faire pour la doc (même si je n'avais pas prévu d'avoir un utilisateur si tôt )

• J'imagine que le local repository "git" n'est compatible qu'avec le remote repository "git", du coup c'est une invitation à faire une configuration invalide si j'en combine un des deux avec un autre engine.
  Oui, je suis d'accord avec toi, mais je ne vois pas trop comment faire autrement (cf. plus bas)
  
• Si je veux créer un fichier tar et l'envoyer via rsync, comme ces deux moteurs sont tous les deux des remote repositories c'est impossible ?
  « engine=tar: Collect all files of your local repository into a .tar archive (.tar.gz, .tar.bz2 or .tar.xz) and copy it to a remote server with 'cURL'. If the remote URL begins by 'http://file://', then the 'cp' command is used instead. »
  bon, ok, le nom est vraiment mal choisi send_archive ? tar_and_curl ? remote_archive ?
  
• D'ailleurs, avoir "tar" comme type de remote repository est curieux, c'est peut-être même celui-ci qui m'a fait réaliser qu'un remote repository n'était pas du tout ce que j'imaginais d'après le nom.
  cf. ci-dessus
  
• Si je ne veux faire qu'une sauvegarde locale je vais être quand même obligé de déclarer un remote repository, ce qui ne parait pas vraiment intuitif.
  Ça tombe bien, tu n'est pas obligé de déclarer le moindre remote repo ^^ Faudrait que je le marque en toute lettre.
  
• Supprimer "git" des backup formats, ne laisser que "git" dans les remote repositories et le laisser s'occuper à la fois du commit et du push (de cette façon je pourrais archiver tout ce que je veux dans git, très probablement je choisirai d'y mettre mes fichiers tels quels avec le backup format "files")
  Mais ça modifierait le dépôt local. Que se passerait-il si j'avais deux remote de type git ?
  Ou alors, ça obligerait à avoir plusieurs copies des fichiers à sauvegarder, et pour le coup ça me semble handicapant :/

flanker (./54) :

Si je veux créer un fichier tar et l'envoyer via rsync
[...] c'est impossible ?

[...] and copy it to a remote server with 'cURL'.

Forcément si tu ne lis pas mes requêtes aussi

J'avais bien vu qu'on pouvait envoyer via cURL, mais tu ne vas pas pouvoir t'amuser à supporter la combinatoire de tous les protocoles d'envoi dans tous les formats de backup, c'est exactement pour ça que je trouvais plus simple de rendre indépendantes ces deux notions (déjà parler de curl dans un engine "tar", ça me trouble, tout comme mélanger les notions de format de compression et de protocole d'envoi ^^)

En l'occurrence si je crée un .tar non compressé, j'ai peut-être vraiment envie d'utiliser rsync et non pas curl, parce que je n'ai pas envie d'envoyer la totalité du fichier à chaque backup.

flanker (./54) :
Mais ça modifierait le dépôt local. Que se passerait-il si j'avais deux remote de type git ?Ou alors, ça obligerait à avoir plusieurs copies des fichiers à sauvegarder, et pour le coup ça me semble handicapant :/

Je ne vois pas trop le problème ? Tu traites tous tes local repositories (ou tes "backup formats", ou bien encore tes "sources", finalement c'est ce qui me parait le plus clair), et tu obtiens ainsi plein de fichiers (parfois des fichiers bruts, parfois des archives tar, ça dépend du format choisi). Une fois tout ça traité, le remote repository "git" s'occupe de faire un unique commit et de pusher

Il est tout à fait possible de faire un type de dépôt local « archive tar » (toutes les primitives requises sont disponibles pour le faire), puis d'utiliser un dépôt distant type « rsync ». C'est simplement que je n'y ai pas pensé Mais c'est sûr qu'il resterait incompatible avec le git distant…

C'est sûrement lié à ma méconnaissance de git, mais je ne comprends toujours pas ce que tu veux dire. Tous les fichiers obtenus doivent bien être au même endroit local pour commiter en local, avant de pusher, non ?

Bon, pour le Vagrant qui teste tout, va falloir demander à Apple de se dépêcher de sortir ses nouveaux MacBook Pro
Il faut au moins 1,5Go de RAM dans la VM (entre autres à cause de gitlab + mysql + ldap + postgresql), et du coup le reste rame beaucoup trop avec les autres applis pour que ça soit vivable :/

flanker (./56) :
C'est sûrement lié à ma méconnaissance de git, mais je ne comprends toujours pas ce que tu veux dire. Tous les fichiers obtenus doivent bien être au même endroit local pour commiter en local, avant de pusher, non ?

Heu non pas forcément, mais je ne pense pas que ça aide ici. En tout cas c'est pas à ce type de solution que je pensais, donc c'est moi qui n'ai pas du comprendre la restriction ? Enfin à la limite peu importe, Git n'est qu'une instance parmi d'autres, à mon avis si les concepts sont bien séparés alors Git n'a aucune raison de ne pas y rentrer aussi bien que les autres. Ce que je proposais en ./53 ne fonctionnerait pas, pour séparer format et transport ?

J'ai l'impression qu'on ne se comprend pas

Ton dépôt local te permet de créer plusieurs fichiers, par exemple /var/backups/local1/fichier1, /var/backups/local1/fichier2, /var/backups/local1/fichier3 (ça peut être des fichiers ou des archives).
Je pense que jusqu'à là, on est d'accord.

Si c'est un dépôt de type files (l'actuel), ces fichiers seront ceux d'origine.
Si c'est un dépôt de type tar.gz (qui n'existe pas encore), on aura un seul fichier /var/backups/monarchive.tar.gz (avec un petit dossier caché à côté pour conserver l'état du dépôt).

Si je veux les envoyer via rsync, c'est assez facile : il suffit de faire dans le remote :
rsync /var/backups/local1 ssh://server:destination
Si je veux faire une archive et l'envoyer, c'est aussi facile dans le remote :
tar -Czf /tmp/archive.tar.gz /var/backups/local1 && curl -T /tmp/archive.tar.gz ftp://server:destination
Par contre, si je veux faire un git, je dois faire :

git init /var/backups/local1
git add .
git commit -am 'message'
git push http://server/destination.git

Malheureusement, ça modifie /var/backups/local1 et ça me chagrine quand même pas mal

flanker (./59) :
J'ai l'impression qu'on ne se comprend pas

Alors ça oui, je te confirme, c'est même ce que j'essaie d'expliquer depuis plusieurs posts

flanker (./59) :
Si c'est un dépôt de type tar.gz (qui n'existe pas encore), on aura un seul fichier /var/backups/monarchive.tar.gz (avec un petit dossier caché à côté pour conserver l'état du dépôt).

Arg, "tar" aussi ça va devenir à la fois un type de local repo et de remote repo ? Je pense vraiment que ça aurait du être un local repo et rien d'autre, si tu comptes laisser les deux alors vraiment je ne comprends pas la logique derrière le découpage

flanker (./59) :
Malheureusement, ça modifie /var/backups/local1 et ça me chagrine quand même pas mal

Mais pourquoi tu veux que ça modifie ton dossier ? Garde les metadonnées Git ailleurs, par exemple avec core.worktree, c'est pourtant pas les options qui manquent ?

Mais bon, pour insister encore une fois, tout ça me semble moins gênant que la différence qui me parait de plus en plus floue entre les deux types de repos