-
Bonjour, c’est légal? (c’est très intéressant en tout cas)
-
-
J’ai un avis mitigé sur cet article. Le contenu est correct, aucun problème avec ça, mais ça décrit une méthode parmi tant d’autres…
Tout le monde n’est pas forcément d’accord, ce n’est pas forcément applicable à tous les projets, ça décrit plus une possibilité de workflow complet pour un projet particulier qu’une “procédure de merge request” générique comme le laisse entendre le titre.
Il manque une précision selon moi, pour dire que c’est “juste un exemple”, chaque élément décrit correspondant à une décision à prendre par les mainteneurs de chaque projet (convention de nommage des branches, langue utilisée, template de description de MR, etc.).
Cela étant dit, je suis quand même heureux de l’avoir lu, et je remercie l’auteur de partager ses connaissances/méthodes/habitudes ;)
PS: Une petite imprécision quand même,
mainn’est pas juste le nom de la branche principale sur GitHub, cette modification a aussi été appliquée sur GitLab (depuis la version 14.0), et pourrait potentiellement être appliquée un jour au niveau de git lui même (si ce n’est pas déjà fait, mais j’ai l’impression que non).-
C’est toujours mieux d’avoir un exemple pour comprendre une technique j’imagine. Mais chaque partie est indépendante et n’est pas obligatoire bien sûr, ce sont des recommandations en réalité, adaptable en fonction du sujet.
J’ai rectifié pour la partie branch
main, je te remercie :)
-
-
Déployer via github sur un FTP qui n’est pas sécurisé, quelle bonne idée ;(
-
-
C’est marrant les habitudes. J’utilise toujours
git showpour ça, et je m’aperçois aujourd’hui que ce n’est pas ce qui est proposé par la doc de Git ^^ -
-
Une astuce toujours pratique, mais attention à bien définir les objectifs ;)
Si comme supposé par l’introduction, des secrets ont été poussés dans le dépôt git, la seule bonne solution est de les renouveler.
- Quelqu’un peut avoir déjà téléchargé les commits contenant des secrets
- Sans exécuter de
git gccoté serveur, les commits seront déréférencés, mais resteront accessibles
-
Je confirme, dans le cas où cela partirait par exemple sur github, il faut tout détruite et tout refaire.
-
Très bon article, merci :) Comme tifriis, je transmettrai le lien à des novices sans hésitation.
Quelques imprécisions/raccourcis ou formulations un peu étranges par endroit, mais les concepts sont bien (et correctement) décrits et faciles à comprendre ;)
-
Pour information, le lien a changé : https://mylittleblog.fr/Bonjour_Hugo.html
C’est probablement lié au changement de moteur : https://mylittleblog.fr/AurevoirHugo.html
-
Katyucha il y a 4 ans | lien | sur : Ansible : Comment générer des labs et tester ses playbooks facilement
Le disclamer a la fin tue tout l’article et d’ailleurs, j’allais en parler : docker <> serveur linux
Pourquoi ne pas proposer un Vagrant / VirtualBox ?
-
À mi-chemin, je trouve que LXC peut aider. J’ai eut une très bonne expérience de conteneur LXC créés très rapidement grâce à btrfs dans un ramdisk : moins de 7s pour cloner, démarrer et éteindre un conteneur. Avec LXC, on a un système complet : réseau, systemd, SSH, etc. La limite est essentiellement sur le système de fichier et le kernel partagé avec l’hôte.
-
-
-
C’est pas mal, mais perso je préfère toujours travailler sur une copie plutôt que sur le disque original :)
-
De mon coté, c’est un peu plus simple, avec uniquement BorgBackup :
- Les machines qui ont suffisamment d’espace disque font un backup sur leur propre disque (accès rapide)
- Chaque machine (locale ou distante) fait un backup sur mon NAS (qui est chez moi)
- Chaque machine (locale ou distante) fait un backup sur un serveur Kimsufi (pour avoir une copie distante)
Trois machines locales (desktop, serveur LAN et NAS) et une machine distante (Kimsufi) sont sauvegardées de cette manière (système complet en excluant des répertoires trop gros dont je peux retrouver/regénérer le contenu simplement). Pour mon téléphone, les backups sont manuels via USB (script jmtps + rsync + borg), parce que 4G/Wifi/Bluetooth ne sont jamais activés. Il y a tellement peu de choses dessus que ça suffit.
Notes :
- Les deux ou trois backups de chaque machine sont indépendants : La corruption d’un repo ne touche pas les autres.
- Chaque backup se lance une heure après la fin du précédent. Le load se lisse tout seul avec le temps.
- À l’utilisation, je ne sens aucun impact, que ce soit au niveau utilisation CPU/Disque ou connexion internet (ADSL 1.3 Mbps down / 473 kbps up).
- À la fin d’un backup, les stats sont envoyées dans InfluxDB (alerting via Grafana) et par mail. Selon le statut du backup, le mail est rangé/marqué comme lu automatiquement (Success/Warning) ou laissé non lu dans la boite de réception (Erreur).
Par rapport à ce que tu as mis en place, je vois deux améliorations :
- Avoir au moins deux backups indépendants : Actuellement, tes “backups supplémentaires” (Borg du répertoire syncthing puis synchro vers Google Drive) sont chacun basés sur le précédent. Une corruption du premier se propagera donc dans les autres.
- Ajouter du monitoring pour être prévenu des anomalies (backup échoué, repo qui grossit très vite, absence de backup sur une certaine période, etc.).
-
Merci pour ton retour, je suis d’accord avec toi sur le fait que mes backups supplémentaires sont des backups de backups, donc risques de corruptions. Pour syncthing, ce n’est pas un backup, mais une synchro, ce qui n’est pas totalement pareil, le risque de corruption est quasi null.
Pour ce qui est de ta méthode, pour les serveurs oui c’est faisable, mais pour du desktop/laptop, c’est plus compliqué, comme dis, ils ne sont allumés que quand je les utilisent, et je ne veux pas que ça utilise trop de ressource (compression + chiffrement), et mes PCs ne sont pas des plus performants (par exemple un rclone mount bouffe tout mon CPU).
C’est pour cela qu’une synchronisation me semble le mieux pour le moment, ce n’est pas une sauvegarde, juste une syncrho 1:1, avec une rétention des fichiers à 2 jours en cas de suppression sur la source.Comme dis dans mon article, ma solution n’est pas un choix arrêté, mais j’ai déjà vu une faille dedans, si je perds tout chez moi, pour restaurer il faut que je télécharge toute l’archive de duplicati (pour l’instant environ 1To), alors qu’avec une solution comme restic ou borg, je pourrais monter et récupérer ce que j’ai besoin.
Pour le scheduling, je ne sais pas encore, je pense finir par partir sur ansible, qui se connectera à chaque machine pour faire les sauvegardes, ce n’est pas sont rôle normalement, mais on va dire que si, cependant, ce n’est pas encore défini.
-
[Comment removed by author]
-
De mon coté, j'utilise juste git avec :
alias homegit='git --git-dir=/home/marmotte/.home_git --work-tree=/home/marmotte'- Un fichier
~/.home_gitignorecontenant*.
Les fichiers sont directement à leur place, donc pas de problème de liens symboliques, et pas d'ajout de fichier par erreur avec le gitignore (il suffit de
homegit add -fpour ajouter un nouveau fichier). C'est simple, ça fonctionne très bien :)-
-
Effectivement, c'est le changement de git-dir qui fait toute la différence par rapport à un simple dépôt git :)
Pour le clone initial sur les autres machines, je passe par un clone bare que je reconfigure ensuite. Plus de détails sur mon blog : https://blog.garamotte.net/posts/2013/09/01/fr-version-control-user-settings.html
Et pour la completion avec bash, j'ai ça dans mon
.bashrc:_completion_loader git complete -F _git homegit
-
-
-
-
L'idée est très bonne, mais je trouve dommage de faire un backup difficile à exploiter, alors que Borg permet de faire bien mieux (de mon point de vue) :
- Bases de données : Je préfère une commande de la forme
pg_dumpall | borg create repo::archive -, ce qui permet de restaurer avec un simpleborg extract --stdout repo::archive | psql dbname - Fichiers de configuration : Pourquoi créer une archive et la sauvegarder alors que Borg est fait pour sauvegarder des fichiers ?
Je pencherais plutôt pour
borg create repo::archive *.conf. L'avantage ? Pouvoir extraire aussi simplement ces fichiers avecborg extract repo::archive filename destination, voire afficher directement le contenu avecborg extract repo::archive --stdout filename
Alors oui, ce que je propose n'est peut-être pas possible avec borgmatic (ne l'utilisant pas, je le connais mal), mais quitte à faire un script, autant en profiter pour faire un backup simple à exploiter. Pour la politique de rétention, Borg fait ça très bien tout seul avec la commande
borg prune. Pour vérifier la cohérence, c'estborg check. Et pas besoin de fichier de configuration supplémentaire ni de fichier de backup temporaire :)Le point important lorsqu'on utilise un dépôt qui contient plusieurs backups différents (ici bases de données et fichiers de configuration), c'est de bien les nommer, pour pouvoir utiliser le paramètre
--prefixdes commandesborg prune,borg list,borg check,borg delete, etc.). - Bases de données : Je préfère une commande de la forme
-
L'idée est bonne, mais plusieurs choses me dérangent dans cet article.
- Syncthing est un très bon outil, mais il n'est pas du tout adapté pour faire de la sauvegarde.
- Devoir chiffrer et déchiffrer manuellement, c'est vraiment pas pratique. Et ça nécessite d'avoir les données en double sur la machine source (données réelles, et données chiffrées).
- À moins de désactiver la synchro automatique (si c'est possible), on risque de perdre sa “sauvegarde” en la supprimant de la machine source.
- Même s'il propose du versioning, sans déduplication, ça consomme vite beaucoup de place.
- Si la nouvelle “sauvegarde” est un fichier différent, il va uploader la totalité du fichier, ou il ne télécharge que les bouts qu'il ne connait pas déjà ?
Pour de la sauvegarde, je te conseillerais plutôt de regarder du coté d'outils faits pour ça, comme Borg ;)
-
syncthing s'est bien amélioré niveau performances. - Je le trouve très adapté pour de la sauvegarde. Il faut toujours des copies de sauvegardes, pas qu'un seul exemplaire : syncthing permet de garder tout ça synchronisé. - Tu peux désactiver la suppressiond e fichiers qui auraient disparus, mais à quoi bon sauvegarder puis supprimer la sauvegarde ? - Tu as des exemples sur la place prise ? - Si tu chiffres, même avec rsync, ça sera un nouveau fichier, peu importe son nom, et le tout sera réuploadé.
Je connais borg, il ressemble beaucoup à rsync, et ce sont mes 2e choix au travers d'un tunnel SSH pour mes sauvegardes.
-
J'ai l'impression qu'on a pas la même notion de sauvegarde, ça doit influer sur la perception qu'on a de chaque outil :)
Ton article est intéressant, et Syncthing est très bien, c'est juste la notion de sauvegarde qui me gène ici :P
- Je le trouve très adapté pour de la sauvegarde. Il faut toujours des copies de sauvegardes, pas qu'un seul exemplaire : syncthing permet de garder tout ça synchronisé.
Je ne comprends pas trop ce que tu veux dire. Synchronisation et sauvegarde sont justement deux choses bien différentes pour moi.
- Tu peux désactiver la suppression de fichiers qui auraient disparus, mais à quoi bon sauvegarder puis supprimer la sauvegarde ?
Si je dois chiffrer une archive contenant la totalité de mes documents, je n'ai pas envie de conserver cette archive sur la machine source. Elle y est inutile, occupe de la place, etc.
- Tu as des exemples sur la place prise ?
Je n'ai pas fait de tests, donc je n'ai pas d'exemple, mais comme Syncthing travaille au niveau des fichiers, je suppose que conserver 3 sauvegardes de 1 GB de données occupe 3 GB, non ?
- Si tu chiffres, même avec rsync, ça sera un nouveau fichier, peu importe son nom, et le tout sera réuploadé.
Justement, je n'ai pas cité rsync mais Borg, qui peut chiffrer et dédupliquer (et ne ressemble absolument pas à rsync).
Sur une sauvegarde d'environ 500 Mo de data diverses, avec une connexion ADSL 5 Mbps/900 kbps, ça met en moyenne 3~5 secondes pour créer une nouvelle sauvegarde ne contenant aucune modification. Je n'aimerais pas avoir à uploader ces 500 Mo à chaque fois. Et je fais cette sauvegarde sur deux machines distantes différentes, ce qui serait encore plus problématique (elles sont faites séparément, pour éviter de synchroniser une corruption d'un backup :P).
-
-
En passant, BURP est pas mal aussi si tu veux économiser les ressources : https://burp.grke.org/index.html
-
De mon coté je reste sur vim (je suis perdu avec une GUI ^^), mais tous mes collègues sont passés sur VScode après un passage par ST, puis Atom.
De l'extérieur, ça donne l'impression qu'il y a un cheminement logique dans le choix des éditeurs de texte. Quel sera le remplacement de VScode ? :)
-
[Comment removed by author]
-
Si mon souvenir est bon, sous Debian et dérivées il suffit de créer un fichier /etc/vim/vimrc.local pour la config perso, ce qui évite qu'elle se fasse écrabouiller par une mise à jour.
Sur ma KDE neon (dérivée d'Ubuntu) ça ressemble à ça.
https://github.com/kikinovak/kde-neon/blob/master/config/vim/vimrc.local
-
Effectivement, comme le dit kikinovak, on peut créer un
/etc/vim/vimrc.localpour avoir une configuration spécifique globale, ou comme dit dans les commentaires de l'article, on peut aussi mettre ce qu'on veut dans le~/.vimrcpour avoir une configuration spécifique à un utilisateur. Dans tous les cas, dès qu'il est possible de ne pas toucher les fichiers gérés par les paquets, je ne les modifie pas. Ça permet d'éviter des conflits lors de mises à jour, ou simplement de regrouper ses modifications spécifiques pour les retrouver plus facilement. En cas de problème après une mise à jour, c'est plus facile de désactiver tout ce qu'on a changé d'un coup pour voir si le problème vient de nos modifications : il suffit de renommer le fichier spécifique.Pour détailler ce qui se passe : Avant Debian 9, le support de la souris n'était pas activé par défaut, donc la sélection faite à la souris était faite par l'émulateur de terminal. Maintenant, le support de la souris est activé dans vim, et donc c'est vim qui capture les événements de la souris : La sélection est maintenant faite par le
visual modede vim.La solution de désactiver le support de la souris dans vim est simple, mais pas idéale. On peut aussi sélectionner avec shift+clic, pour forcer l'émulateur de terminal à gérer la sélection, sans désactiver le support de la souris de vim. Dans ces deux cas, la sélection prendra en compte les numéros de lignes, marques de folding, etc. si c'est activé, ce qui est loin d'être idéal. Une autre solution est d'utiliser le support du clipboard de X dans vim, avec
"yune fois le texte sélectionné (envisual mode, évidemment, c'est vim qui doit gérer la sélection dans ce cas).
-
-
Est-ce bien compatible VI (et non VIM) ?
Perso, je ne comprend pas les gens qui retienne “:wq” quand on peut faire “:x” qui fait la même chose. (attention, “:w” ou ‘:q" tout seul, okay, mais les deux :s)
-
-
Hum; interessant ce point, donc, imaginions la chose suivante :
vi /var/log/syslog[2min se passe … des lignes sont rajouté dans dans le syslog] si à ce point là, je fais :x (ce qui biensur, est assez couillon, tout autant que le :wq) je n'aurais PAS les lignes rajoutées ?!
-
En relisant, je me dis que mon explication n'est peut être pas clair, du coup :) “:x” ne sauvegarde que si le fichier a été modifié dans vi.
Donc dans l'exemple : “:x” n'écrase pas le fichier, mais quitte simplement, comme “:q”. “:wq” tentera d'écrire, et demandera une confirmation, puisque le fichier a été modifié hors vi entre temps.
-
-
-
-
-
Hello,
Je partage les critiques sur Fail2ban, on en parle systématiquement pour la sécurisation d'un système mais il est assez perfectible. Il reste cependant simple d'accès et fait le job quand même, en gros je voudrais pouvoir m'en passer mais c'est ce qu'il y a encore de mieux.
La solution proposée me parait lourde à comprendre et mettre en place, ce sera source d'erreur pour une personne qui veut reprendre le sujet derrière. Je préfère utiliser un outil bien connu avec une doc abondante et des fichiers de conf bien identifiés qu'éparpiller des fichiers de conf (ou scripts) pour être plus pointu au niveau de la sécurisation. Avis perso of course.
Tcho !
-
Effectivement, je n'avais pas pensé à ajouter de précision sur la complexité de la solution. Je viens d'ajouter une note dans l'introduction de la dernière partie, pour préciser que la configuration présentée est plutôt destinée à des utilisateurs avancés.
Merci pour la remarque ;)
Après, comme chaque article de mon blog, c'est avant tout une explication de ce que je fais, en essayant d'expliquer pourquoi et comment. À chacun de prendre les informations qui l'intéressent dedans :P
-
-
Je pense surtout que la demande de base est complétement infondée (j’ai le mot idiot en tête). Après, si on te paye pour faire le taff, tant mieux pour toi Pourquoi je trouve ça infondé ? On te demande de remplacer dans une recette de cuisine, une carotte par un chou. Spoiler : t’auras pas le même gout
Typiquement, puppet va te conformer le fichier A. Quelqu’un te modifie (erreur ou intention, légtitiment ou pas) le fichier A… ll va perdre sa modification au prochain run de l’agent. Question : tu vas vraiment lancé toutes les 30 minutes les playbooks ansible sur l’ensemble de ton parc ? Perso, je l’ai jamais vu. Résultat : Fichier A sera modifié et jamais remis à son état initial.
Vala pour ma remarque ( et je redis : aucune critique sur toi, si le client paye… tant pis pour son choix, tant mieux pour ton compte bancaire)
Globalement je suis d’accord avec toi, même si c’est faisable. D’ailleurs je l’ai vu chez un client, ils faisaient du ansible en mode pull, leurs vms étaient poussées directement avec ansible d’installés, et toute les heures elles allaient chercher leurs propres configuration.
En terme de perf, ça tenait ?
Oui tant mieux sinon de quoi vivrions nous. Sinon ta remarque est pertinente mais voilà Puppet disparaît petit à petit…
Chez mon employeur actuel, on vient de faire l’inverse : Adieu Ansible et Go puppet. Pour la partie orchestration, puppet + choria fonctionne très bien
Il en fait pour tous les goûts. Bonne chance
une raison particulière à l’abandon de Ansible ?
Ça arrive dans un contexte de rachat, les différentes équipes peuvent avoir à uniformiser les outils utilisés.
Par contre, c’est pas de chance quand ça tombe sur un cas comme ça, avec deux outils dont le but est différent, et c’est celui qui n’est pas adapté au besoin qui est choisi pour rester ^^
Chez nous, Puppet et Ansible sont utilisés tous les deux, mais pour des tâches différentes : Puppet gère la conf persistante (OS, packages, etc.), tandis qu’Ansible est dédié aux tâches “oneshot” (déploiement applicatif, déclaration dans l’AD, etc.).