Logo journal du hacker middle
  1. 1

    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, main n’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).

    1. 1

      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 :)

    1. 2

      Déployer via github sur un FTP qui n’est pas sécurisé, quelle bonne idée ;(

      1. 1

        À priori, c’est sa seule méthode de déploiement possible, donc via GitHub ou à la main, autant que ce soit automatisé :)

        Mais je suis d’accord avec toi sur l’utilisation du FTP en 2022, c’est dommage ^^

      1. 2

        C’est marrant les habitudes. J’utilise toujours git show pour ça, et je m’aperçois aujourd’hui que ce n’est pas ce qui est proposé par la doc de Git ^^

        1. 1

          +1 git show ici aussi

          1. 1

            Je ne connaissais pas git show et effectivement le retour est le même entre les 2 commandes. Merci bien ;-)

          1. 2

            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 gc coté serveur, les commits seront déréférencés, mais resteront accessibles
            1. 1

              Je confirme, dans le cas où cela partirait par exemple sur github, il faut tout détruite et tout refaire.

            1. 1

              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 ;)

              1. 1

                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

                1. 3

                  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 ?

                  1. 3

                    À 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.

                    1. 2

                      Et pour ce genre d’utilisation, avec LXC ou systemd-nspawn (que je préfère, je le trouve bien plus simple à mettre en place), il y a la notion de conteneurs éphémères :)

                  1. 1

                    C’est pas mal, mais perso je préfère toujours travailler sur une copie plutôt que sur le disque original :)

                    1. 1

                      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.).
                      1. 2

                        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.

                      1. [Comment removed by author]

                        1. 3

                          De mon coté, j'utilise juste git avec :

                          • alias homegit='git --git-dir=/home/marmotte/.home_git --work-tree=/home/marmotte'
                          • Un fichier ~/.home_gitignore contenant *.

                          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 -f pour ajouter un nouveau fichier). C'est simple, ça fonctionne très bien :)

                          1. [Comment removed by author]

                            1. 3

                              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
                              
                          2. 1

                            Same problem here, un truc qui m'emmerde bien ça.

                            Tcho !

                          1. 4

                            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 simple borg 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 avec borg extract repo::archive filename destination, voire afficher directement le contenu avec borg 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'est borg 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 --prefix des commandes borg prune, borg list, borg check, borg delete, etc.).

                            1. 1

                              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 ;)

                              1. 1

                                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.

                                1. 1

                                  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).

                                2. 1

                                  En passant, BURP est pas mal aussi si tu veux économiser les ressources : https://burp.grke.org/index.html

                                1. 2

                                  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 ? :)

                                  1. 1

                                    Comme dit dans les commentaires, il vaut mieux modifier son propre vimrc plutôt que le fichier defaults.vim qui sera écrasé à la prochaine mise à jour.

                                    Les manpages disent ça à propos de mouse :

                                    The mouse can be enabled for different modes:
                                            n   Normal mode
                                            v   Visual mode
                                            i   Insert mode
                                            c   Command-line mode
                                            h   all previous modes when editing a help file
                                            a   all previous modes
                                            r   for |hit-enter| and |more-prompt| prompt
                                        Normally you would enable the mouse in all four modes with:
                                            :set mouse=a
                                        When the mouse is not enabled, the GUI will still use the mouse for
                                        modeless selection.  This doesn't move the text cursor.
                                    
                                        See |mouse-using|.  Also see |'clipboard'|.
                                    
                                        Note: When enabling the mouse in a terminal, copy/paste will use the
                                        "* register if there is access to an X-server.  The xterm handling of
                                        the mouse buttons can still be used by keeping the shift key pressed.
                                        Also see the 'clipboard' option.
                                    

                                    L'idée de ce contournement apparemment, c'est donc de désactiver le support souris sauf pour les prompt. Du coup le copier/coller (par exemple en mode insertion) fonctionne à travers le « relais » de l'émulateur de terminal. Mais ça ne nous aide pas à comprendre pourquoi depuis Debian 9 ça ne fonctionne plus. D'après ce que je comprends, vim ne peut plus accéder au clipboard Xorg ?

                                    Les manpages font référence à Xorg, peut-on espérer un jour des adaptations pour copier-coller avec Wayland en ayant le mode souris activé ?

                                    1. 2

                                      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

                                      1. 1

                                        Effectivement, comme le dit kikinovak, on peut créer un /etc/vim/vimrc.local pour 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 ~/.vimrc pour 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 mode de 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 "y une fois le texte sélectionné (en visual mode, évidemment, c'est vim qui doit gérer la sélection dans ce cas).

                                      1. 1

                                        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)

                                        1. 1

                                          Il y a une très légère différence entre les deux : “:wq” sauvegarde, puis quitte. “:x” sauvegarde si le fichier a été modifié, puis quitte.

                                          Dans le cas où le fichier a été modifié par une autre application entre temps, le résultat final sera différent ;)

                                          1. 1

                                            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 ?!

                                            1. 3

                                              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.

                                              1. 1

                                                Je comprend, par contre ca me conforte dans l'idée que :x est plus intéréssant dans beaucoup de cas de figure. L'edition simple d'une part, et de l'autre, on evite la demande de confirmation. Merci pour les explications en tout cas :)

                                        1. 3

                                          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 !

                                          1. 1

                                            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

                                            1. 1

                                              Ton article est excellent, ma remarque était d'ordre générale, je connais malheureusement trop de monde qui font un copier-coller sans rien comprendre à ce qu'ils font, ce que ça fait et comment ça fonctionne.

                                              Tcho !