J'utilisais pelican également et j'ai migré sur sphinx (à jour, plus de thèmes), tu peux voir le site ici (construction et déploiement sont automatisés).
Une autre possibilité est de rester sur du reST (que j'apprécie également pour son "formalisme"), puis de le convertir vers le format de son choix avec pandoc. Ainsi, si tu veux un jour migrer de générateur, que celui ci n'accepte que du markdown/asciidoc ou autre, tu pourras facilement ajouter la conversion (à la volée) dans un script. Grâce à cela, ce que tu feras sera "future-proof", et ça… j'aime bien :).
En lisant un peu leur doc, j'ai l'impression que c'est un retour au PHP, avec JSX/TS à la place (et la possibilité de laisser facilement des petits bouts en JS si besoin pour des parties interactives).
Est-ce le cas, ou bien ai-je loupé un nouveau concept révolutionnaire? Si des devs web passent par là, je suis curieux d'avoir leur avis.
Merci de prendre le temps d'expliquer un peu la vision de l'outil. C'est bien que ce soit une démarche de faire découvrir l'outil plutôt qu'un "simple" clicodrome.
Dans mon expérience personnelle, qui n'est pas représentative de la réalité, 100% des utilisateurs de docker desktop n'avait jamais eu l'idée de lire docker run, se privant de découvrir les possibilités de l'outil. Sans une GUI, cela serait-il différent? Pas sûr, et je reconnais que c'est un coupable facile pour moi.
Pour l'avoir déjà utilisé, l'interface de Docker Desktop est plutôt bien faite, et comme tu le soulignes, il y a plusieurs fonctionnalités fort pratique.
Je ne pense pas qu'il soit nécessaire que chacun connaisse parfaitement la cli de docker. Seulement, ton exemple sur Git est juste. Oui, avoir une GUI permet à des profanes de s'en servir. Mais d'un autre côté, ça empêche aussi les gens d'en découvrir plus sur l'outil. C'est un débat qui restera ad vitam dans l'informatique je pense. Avec docker-desktop, le message transmis est "Un conteneur, c'est comme une machine virtuelle, mais avec une baleine". C'est dommage, car ce n'était pas la philosophie première.
Après, pour le choix d'avoir des VM par défaut, je comprends la motivation. Ce n'est pas mon besoin personnel, mais oui, c'est sans doute plus juste pour la majorité des utilisateurs. Il n'empêche que j'y vois toujours un certain retour en arrière, même si avec les Dockerfile, c'est toujours moins pire qu'avant.
À mes yeux, l'outil perd vraiment tout intérêt à forcer l'utilisation d'une VM.
Autant sous windows c'était obligatoire pour de vraies raisons, autant sous Linux, c'est dommage de ne pas avoir le choix. M'enfin, à partir du moment où une GUI est nécessaire pour lancer un conteneur, VM ou pas, l'utilisateur concerné ne doit pas y voir grand chose.
Pour la faire courte, on achète un bouquin sur le store de son choix, on l'ouvre avec Adobe Digital Editions (qu'on peut faire tourner dans wine), cela débloque le livre (et le lie à ce compte Adobe), et Calibre avec DeDRM fait le reste. De là, vous possédez un ebook sans DRM. Personnellement, j'éprouve une certaine satisfaction à utiliser un lecteur permettant aux DRM d'exister afin de supprimer ceux-ci. Bien, ou pas bien, je laisse à chacun le soin de juger.
Passé ce point, cela permet d'être libre des contraintes des formats de fichier (calibre convertit tout et n'importe quoi), et également des stores de chaque fabricant. Ainsi, tant que l'upload en USB est possible, aucun besoin d'un quelconque compte.
Fort de cette liberté, j'apprécie le Kindle d'Amazon. Prix raisonnable, bien fini. En bonus, si tu n'as jamais activé le wifi dessus, tu n'auras jamais de pubs affichées.
Tes craintes sur le wifi et l'autonomie sont peu importantes, car au final, une fois désactivé, ma liseuse tient aussi le mois sans problème.
Quant au rétro-éclairage, je ne pourrais plus m'en passer. C'est d'ailleurs la raison pour laquelle j'ai changé d'un Kindle "ancien" vers un modèle récent, qui en dispose. Si tu lis uniquement dans ton lit, seul, avec une bonne lumière, alors pourquoi pas faire sans. Mais partout ailleurs (transports, chez des amis ou… dans une tente), ou quand ta femme veut dormir (dans le noir de préférence), tu seras ravi d'avoir un écran correctement éclairé sans besoin d'une lumière externe. Il faut aussi garder à l'idée que le rétroéclairage d'un modèle comme un Kindle n'a rien à voir avec le rétroéclairage d'une tablette Android, c'est infiniment moins gourmand.
J'apprécie aussi le tactile, en tout cas on y prend vite goût. J'aime la possibilité de pouvoir lire sous une couverture et changer les pages avec mon nez (rigolez pas, je le fais). Je n'ai jamais eu une liseuse avec des boutons ergonomiques (mais ça existe ptet), donc je laisse le bénéfice du doute.
Je n'ai jamais essayé les Kobo, mais d'après ce que j'ai entendu, je dirais que c'est kif-kif. Si tu trouves qu'Amazon c'est le mal absolu, ta conscience s'en portera mieux.
je t'avoue que je n'avais pas pensé à vérifier ces points là. Personnellement, j'utilise vim et mosh/tmux, donc Visual code (ou codium) n'est pas trop mon environnement.
C'est juste qu'ayant "trouvé" ce mode de fonctionnement, je me suis dit que ça pourrait intéresser certains devs/IT pour lesquels leurs collègues remontent des soucis avec x2go (ou VNC, ou RDP, ou autre protocole graphique à distance).
Imagine que ta machine perso est un vieux portable d'il y a 5 ans. Et que ta machine au boulot est un serveur avec 32 coeurs et 128go de ram. Non, tu ne veux pas utiliser ta machine perso pour indexer/construire ou faire quoique ce soit sur ton code (en dehors d'avoir une IHM pour l'éditer).
De deux, imagine que tu as un dépôt git assez gros, avec plusieurs dizaine de milliers de fichiers indexés. Bon courage pour bosser avec ça au dessus de sshfs. Je te dis ça, car c'est notamment ce que j'ai essayé avant de trouver ce mode "remote" de vscode. Et c'était la cata (pourtant, j'ai la fibre, et autre chose qu'un vieux portable à la maison).
Il y a donc un vrai intérêt à pouvoir bosser en distant "nativement" plutôt que monter un répertoire.
En revanche, il y a des gens qui n'utilisent pas forcément un éditeur léger et/ou en terminal. Pour ma part, je ne fais que du vim/mosh/tmux, mais certains collègues utilisent uniquement vscode.
Pour ma part, j'ai essayé Slackware, après avoir été un peu déçu de ce que j'avais appris avec Linux From Scratch (qui reste une grosse liste de commandes à taper à mes yeux, sans vraiment plus).
Sous Slackware, du fait que tout le système d'init et de gestion de services est écrit en script shell, il est facile de comprendre comment une machine démarre, comment les services sont lancés, et pourquoi. Ça m'a vraiment permis de comprendre cette partie là de mon système.
Je recommande à ceux intéressés d'en apprendre plus de se pencher sur Slackware, de l'installer, et de jouer un peu avec tout ce qu'on peut trouver dans /etc.
Après avoir passé un peu de temps sur ces questions, j'en étais arrivé à une solution basée sur rsync et cron.
Après avoir perdu du temps autour de plusieurs projets, je suis tombé sur rsbackup.
Un projet à jour, développé, simple, bien foutu, et dispo de base sur ta debian. Il y a aussi directement les .deb sur le site si tu veux la dernière version (possibilité de backup horaire).
Ça peut faire une sauvegarde à l'endroit que tu veux, en incrémental (avec des hard links) basé sur rsync. Évidemment, ça gère aussi une rotation des sauvegardes, et tout ce qu'on peut attendre. En bonus, tu peux avoir un rapport html.
Un fichier de config définit le tout, de façon assez lisible je trouve.
Bref, essayé et adopté :) Au boulot, j'ai une sauvegarde horaire de mon système, avec un mois d'historique. De quoi flinguer mon disque en toute quiétude.
Ce que tu demandes n'est pas lié à la surcharge d'opérateur.
Le standard précise que tous les effets de bord d'un statement doivent être terminés au point de séquence (ici, le ;). Mais sans préciser l'ordre d'évaluation. Notamment, = n'est pas un point de séquence.
La ligne
m[1] = m.size();
Peut donc soit d'abord évaluer m[1], soit m.size(), avant d'effectuer l'affectation.
Après plusieurs recherches, j'ai finalement opté pour l'approche distroless, développée chez Google.
L'idée est de faire un dockerfile multi stage, pour ne garder que le serveur ssh et ses dépendances.
De cette façon, le conteneur final ne possède ni shell, ni binaire superflu. La surface d'attaque est donc très réduite, voire nulle. À mes yeux, ce modèle est plus viable que simplement réduire la taille de sa distribution.
Plus exactement, ma machine du boulot essaye (constamment, 1 fois/30sec) d'ouvrir un tunnel vers une ip que je contrôle.
Lorsque je veux y accéder, j'ouvre le serveur sur ma machine perso, le tunnel est alors créé. Je ne laisse pas ma machine perso allumée constamment, et encore moins le serveur ouvert.
Je peux alors me connecter à la machine du boulot.
Je ne cherche pas spécialement à me cacher (sinon écrire un article en mon nom sur linuxfr serait quelque peu stupide), mais si un jour on vient me voir, j'aurais de quoi échanger techniquement.
Je n'ai pas d'accès SSH ni de VPN au boulot. N'étant pas IT, c'est difficile pour moi de pousser une telle décision.
Mon but, c'est juste de pouvoir lancer une commande que j'aurais oublié facilement depuis la maison, et avoir le résultat le lendemain.
Le problème, c'est la machine personnelle. Elle ne correspond pas à la politique IT de ta boîte, et ça peut faire criser certains d'ouvrir une connexion à l'intérieur du réseau "sécurisé" de ta boîte depuis ta machine. Si un jour j'ai un souci (ça demanderait du deep packet inspection au minimum), je pourrais clairement défendre ma solution. Et puis au fond, c'était juste fun comme idée ;)
Le protocole n'est pas ssh + ftp. C'est ftp, redirigé à travers une connexion ssh. Derrière, ton serveur à la maison transfère en clair avec le FTP final. Mais tu peux avoir un peu plus de confiance en ton FAI que dans le wifi du café du coin.
Ce que tu dis le fait ne pas laisser de traces est pertinent aussi. Un tunnel SSH est très couramment utilisé pour laisser une backdoor sur une machine sur laquelle un attaquant s'est introduit.
À ma connaissance, stunnel ne fait qu'ajouter une couche SSL à une connexion existante (pour un client, ou un serveur), et rien d'autre.
Typiquement, tu as un serveur qui ne parle que http. Tu peux utiliser stunnel pour avoir SSL "gratuitement" par dessus.
Pour vulgariser:
cat mon_fichier | stunnel | OVER_INTERNET | stunnel | cat, donne mon fichier, mais transmis de façon chiffré.
Un tunnel SSH permet davantage. Il offre bien sûr le chiffrement de la connexion, mais de plus, il offre un tunnel qu'on peut établir dans les deux sens, ainsi que la notion de port forwarding (rediriger un port distant sur un autre local et inversement).
Du coup, je dirai plutôt que stunnel est fait pour "décharger" le calcul de SSL sur un point d'entrée donné, et avoir un serveur qui parle en "clair" derrière. En tout cas, je l'avais connu dans ce contexte (car c'est souvent compliqué et error-prone de gérer SSL dans ton appli).
En réalité, lorsque j'ai entendu parler de Alpine Linux (pour Docker) cette année, j'ai aussi vu un certain mouvement de devs qui la quittent afin de revenir vers des distributions plus "mainstream", notamment depuis l'arrivée des images réduits ubuntu et debian.
J'imagine que tu faisais référence à Debian-slim en parlant de Debian-stretch, que j'ai en effet mis en place à la place de buster (buster -> buster-slim). Merci!
Quant à Alpine, malgré tout le hype autour de cette distribution dans le monde docker, je reste assez sceptique du résultat, notamment d'un point de vue sécurité. Je préfère encore une distribution fiable, basée sur des composants éprouvés, plutôt qu'une surcouche à busybox.
# Sphinx
Posté par Pierrick Bouvier . En réponse au journal Static Site Generator. Évalué à 8.
J'utilisais pelican également et j'ai migré sur sphinx (à jour, plus de thèmes), tu peux voir le site ici (construction et déploiement sont automatisés).
Une autre possibilité est de rester sur du reST (que j'apprécie également pour son "formalisme"), puis de le convertir vers le format de son choix avec pandoc. Ainsi, si tu veux un jour migrer de générateur, que celui ci n'accepte que du markdown/asciidoc ou autre, tu pourras facilement ajouter la conversion (à la volée) dans un script. Grâce à cela, ce que tu feras sera "future-proof", et ça… j'aime bien :).
# Le nouveau php?
Posté par Pierrick Bouvier . En réponse au lien Fresh is a new full stack web framework for Deno. Évalué à 2. Dernière modification le 28 juin 2022 à 18:18.
En lisant un peu leur doc, j'ai l'impression que c'est un retour au PHP, avec JSX/TS à la place (et la possibilité de laisser facilement des petits bouts en JS si besoin pour des parties interactives).
Est-ce le cas, ou bien ai-je loupé un nouveau concept révolutionnaire? Si des devs web passent par là, je suis curieux d'avoir leur avis.
[^] # Re: Modèle de conteneurisation
Posté par Pierrick Bouvier . En réponse au journal Docker Desktop 4 Linux et rootless containers. Évalué à 5.
Merci de prendre le temps d'expliquer un peu la vision de l'outil. C'est bien que ce soit une démarche de faire découvrir l'outil plutôt qu'un "simple" clicodrome.
Dans mon expérience personnelle, qui n'est pas représentative de la réalité, 100% des utilisateurs de docker desktop n'avait jamais eu l'idée de lire docker run, se privant de découvrir les possibilités de l'outil. Sans une GUI, cela serait-il différent? Pas sûr, et je reconnais que c'est un coupable facile pour moi.
[^] # Re: Modèle de conteneurisation
Posté par Pierrick Bouvier . En réponse au journal Docker Desktop 4 Linux et rootless containers. Évalué à 4.
Allez, j'avoue, j'ai un peu trollé :)
Pour l'avoir déjà utilisé, l'interface de Docker Desktop est plutôt bien faite, et comme tu le soulignes, il y a plusieurs fonctionnalités fort pratique.
Je ne pense pas qu'il soit nécessaire que chacun connaisse parfaitement la cli de docker. Seulement, ton exemple sur Git est juste. Oui, avoir une GUI permet à des profanes de s'en servir. Mais d'un autre côté, ça empêche aussi les gens d'en découvrir plus sur l'outil. C'est un débat qui restera ad vitam dans l'informatique je pense. Avec docker-desktop, le message transmis est "Un conteneur, c'est comme une machine virtuelle, mais avec une baleine". C'est dommage, car ce n'était pas la philosophie première.
Après, pour le choix d'avoir des VM par défaut, je comprends la motivation. Ce n'est pas mon besoin personnel, mais oui, c'est sans doute plus juste pour la majorité des utilisateurs. Il n'empêche que j'y vois toujours un certain retour en arrière, même si avec les Dockerfile, c'est toujours moins pire qu'avant.
# Modèle de conteneurisation
Posté par Pierrick Bouvier . En réponse au journal Docker Desktop 4 Linux et rootless containers. Évalué à 4.
À mes yeux, l'outil perd vraiment tout intérêt à forcer l'utilisation d'une VM.
Autant sous windows c'était obligatoire pour de vraies raisons, autant sous Linux, c'est dommage de ne pas avoir le choix. M'enfin, à partir du moment où une GUI est nécessaire pour lancer un conteneur, VM ou pas, l'utilisateur concerné ne doit pas y voir grand chose.
# Excellent chaîne
Posté par Pierrick Bouvier . En réponse au lien [Youtube] Deus Ex Silicium : Sources Radioactives et Détecteur Electronique. Évalué à 1.
À titre plus général, cette chaîne est vraiment d'excellente qualité.
Ça fait quelque mois que je la suis, et si le sujet vous intéresse, le contenu est vraiment à la hauteur.
# Peu importe la liseuse, tant qu'on a l'ebook
Posté par Pierrick Bouvier . En réponse au journal Liseuse, recherche conseils et retours d'expérience. Évalué à 4. Dernière modification le 01 mars 2021 à 04:06.
À titre personnel, je partage le constat de certains sur les DRM et l'approche préhistorique du monde du livre pour protéger son contenu.
Heureusement, certains sont concernés, et voici un plugin pour Calibre qui permet de s'en débarrasser: https://github.com/apprenticeharper/DeDRM_tools
Pour la faire courte, on achète un bouquin sur le store de son choix, on l'ouvre avec Adobe Digital Editions (qu'on peut faire tourner dans wine), cela débloque le livre (et le lie à ce compte Adobe), et Calibre avec DeDRM fait le reste. De là, vous possédez un ebook sans DRM. Personnellement, j'éprouve une certaine satisfaction à utiliser un lecteur permettant aux DRM d'exister afin de supprimer ceux-ci. Bien, ou pas bien, je laisse à chacun le soin de juger.
Passé ce point, cela permet d'être libre des contraintes des formats de fichier (calibre convertit tout et n'importe quoi), et également des stores de chaque fabricant. Ainsi, tant que l'upload en USB est possible, aucun besoin d'un quelconque compte.
Fort de cette liberté, j'apprécie le Kindle d'Amazon. Prix raisonnable, bien fini. En bonus, si tu n'as jamais activé le wifi dessus, tu n'auras jamais de pubs affichées.
Tes craintes sur le wifi et l'autonomie sont peu importantes, car au final, une fois désactivé, ma liseuse tient aussi le mois sans problème.
Quant au rétro-éclairage, je ne pourrais plus m'en passer. C'est d'ailleurs la raison pour laquelle j'ai changé d'un Kindle "ancien" vers un modèle récent, qui en dispose. Si tu lis uniquement dans ton lit, seul, avec une bonne lumière, alors pourquoi pas faire sans. Mais partout ailleurs (transports, chez des amis ou… dans une tente), ou quand ta femme veut dormir (dans le noir de préférence), tu seras ravi d'avoir un écran correctement éclairé sans besoin d'une lumière externe. Il faut aussi garder à l'idée que le rétroéclairage d'un modèle comme un Kindle n'a rien à voir avec le rétroéclairage d'une tablette Android, c'est infiniment moins gourmand.
J'apprécie aussi le tactile, en tout cas on y prend vite goût. J'aime la possibilité de pouvoir lire sous une couverture et changer les pages avec mon nez (rigolez pas, je le fais). Je n'ai jamais eu une liseuse avec des boutons ergonomiques (mais ça existe ptet), donc je laisse le bénéfice du doute.
Je n'ai jamais essayé les Kobo, mais d'après ce que j'ai entendu, je dirais que c'est kif-kif. Si tu trouves qu'Amazon c'est le mal absolu, ta conscience s'en portera mieux.
# Excellent pour des schémas
Posté par Pierrick Bouvier . En réponse au lien Excalidraw: dessiner c'est xkcd. Évalué à 1.
Vraiment un outil très ergonomique pour faire des schémas jolis rapidement.
En plus, c'est libre, et respectueux de votre vie privée. What else?
[^] # Re: Avec n'importe quel IDE / éditeur et sshfs
Posté par Pierrick Bouvier . En réponse au lien Travail à distance avec Visual Studio Code (quand x2go "c'est trop lent"). Évalué à 1.
Merci pour ces infos!
je t'avoue que je n'avais pas pensé à vérifier ces points là. Personnellement, j'utilise vim et mosh/tmux, donc Visual code (ou codium) n'est pas trop mon environnement.
C'est juste qu'ayant "trouvé" ce mode de fonctionnement, je me suis dit que ça pourrait intéresser certains devs/IT pour lesquels leurs collègues remontent des soucis avec x2go (ou VNC, ou RDP, ou autre protocole graphique à distance).
[^] # Re: l'intérêt?
Posté par Pierrick Bouvier . En réponse au lien Travail à distance avec Visual Studio Code (quand x2go "c'est trop lent"). Évalué à 2.
Oui et non.
Imagine que ta machine perso est un vieux portable d'il y a 5 ans. Et que ta machine au boulot est un serveur avec 32 coeurs et 128go de ram. Non, tu ne veux pas utiliser ta machine perso pour indexer/construire ou faire quoique ce soit sur ton code (en dehors d'avoir une IHM pour l'éditer).
De deux, imagine que tu as un dépôt git assez gros, avec plusieurs dizaine de milliers de fichiers indexés. Bon courage pour bosser avec ça au dessus de sshfs. Je te dis ça, car c'est notamment ce que j'ai essayé avant de trouver ce mode "remote" de vscode. Et c'était la cata (pourtant, j'ai la fibre, et autre chose qu'un vieux portable à la maison).
Il y a donc un vrai intérêt à pouvoir bosser en distant "nativement" plutôt que monter un répertoire.
[^] # Re: x2go trop lent
Posté par Pierrick Bouvier . En réponse au lien Travail à distance avec Visual Studio Code (quand x2go "c'est trop lent"). Évalué à 1. Dernière modification le 07 octobre 2020 à 09:53.
Je suis tout à fait d'accord avec toi.
En revanche, il y a des gens qui n'utilisent pas forcément un éditeur léger et/ou en terminal. Pour ma part, je ne fais que du vim/mosh/tmux, mais certains collègues utilisent uniquement vscode.
[^] # Re: Une vraie alternative à LFS
Posté par Pierrick Bouvier . En réponse au journal Pourquoi j'ai installé Slackware ou la découverte du livre Débuter avec Linux. Évalué à 6.
Je suis d'accord pour LFS. C'est juste que le chemin ne m'a pas autant appris que ce que j'espérais.
Au final, LFS, ça apprend surtout à faire:
wget && tar && ./configure && make && make install
Mais peu de choses sur le coeur du système. Moins ce que je pensais en tout cas. Sur ça, Slackware m'a beaucoup aidé.
# Une vraie alternative à LFS
Posté par Pierrick Bouvier . En réponse au journal Pourquoi j'ai installé Slackware ou la découverte du livre Débuter avec Linux. Évalué à 7. Dernière modification le 22 juillet 2020 à 07:47.
Pour ma part, j'ai essayé Slackware, après avoir été un peu déçu de ce que j'avais appris avec Linux From Scratch (qui reste une grosse liste de commandes à taper à mes yeux, sans vraiment plus).
Sous Slackware, du fait que tout le système d'init et de gestion de services est écrit en script shell, il est facile de comprendre comment une machine démarre, comment les services sont lancés, et pourquoi. Ça m'a vraiment permis de comprendre cette partie là de mon système.
Je recommande à ceux intéressés d'en apprendre plus de se pencher sur Slackware, de l'installer, et de jouer un peu avec tout ce qu'on peut trouver dans /etc.
# Sony's style
Posté par Pierrick Bouvier . En réponse au lien int random() { return 4; /* Good enough. */ }. Évalué à 1.
https://www.youtube.com/watch?v=LP1t_pzxKyE
[^] # Re: Rsbackup
Posté par Pierrick Bouvier . En réponse au journal Sauvegarde pour ordinateur personnel légèrement avancé. Évalué à 2. Dernière modification le 09 avril 2020 à 13:26.
Borg ça a l'air canon. Merci de la découverte!
# Rsbackup
Posté par Pierrick Bouvier . En réponse au journal Sauvegarde pour ordinateur personnel légèrement avancé. Évalué à 5. Dernière modification le 08 avril 2020 à 19:54.
Après avoir passé un peu de temps sur ces questions, j'en étais arrivé à une solution basée sur rsync et cron.
Après avoir perdu du temps autour de plusieurs projets, je suis tombé sur rsbackup.
Un projet à jour, développé, simple, bien foutu, et dispo de base sur ta debian. Il y a aussi directement les .deb sur le site si tu veux la dernière version (possibilité de backup horaire).
Ça peut faire une sauvegarde à l'endroit que tu veux, en incrémental (avec des hard links) basé sur rsync. Évidemment, ça gère aussi une rotation des sauvegardes, et tout ce qu'on peut attendre. En bonus, tu peux avoir un rapport html.
Un fichier de config définit le tout, de façon assez lisible je trouve.
Bref, essayé et adopté :) Au boulot, j'ai une sauvegarde horaire de mon système, avec un mois d'historique. De quoi flinguer mon disque en toute quiétude.
[^] # Re: bonne perf !
Posté par Pierrick Bouvier . En réponse au lien Les serveurs ARM ont maintenant un vrai représentant. Évalué à 1. Dernière modification le 10 mars 2020 à 16:43.
L'article dans le lien réalise aussi un bench, de façon bien plus complète!
# Sequence point
Posté par Pierrick Bouvier . En réponse au journal C++, surcharge d'opérateur, ordre d'évaluation. Évalué à 4. Dernière modification le 21 février 2020 à 15:05.
Ce que tu demandes n'est pas lié à la surcharge d'opérateur.
Le standard précise que tous les effets de bord d'un statement doivent être terminés au point de séquence (ici, le ;). Mais sans préciser l'ordre d'évaluation. Notamment, = n'est pas un point de séquence.
La ligne
m[1] = m.size();
Peut donc soit d'abord évaluer m[1], soit m.size(), avant d'effectuer l'affectation.
Un exemple classique est i = i++;
https://en.wikipedia.org/wiki/Sequence_point
[^] # Re: diminuer la surface d'attaque
Posté par Pierrick Bouvier . En réponse au journal Tunneling SSH conteneurisé. Évalué à 1.
Après plusieurs recherches, j'ai finalement opté pour l'approche distroless, développée chez Google.
L'idée est de faire un dockerfile multi stage, pour ne garder que le serveur ssh et ses dépendances.
De cette façon, le conteneur final ne possède ni shell, ni binaire superflu. La surface d'attaque est donc très réduite, voire nulle. À mes yeux, ce modèle est plus viable que simplement réduire la taille de sa distribution.
https://github.com/GoogleContainerTools/distroless
Une vidéo présentant l'idée: https://www.youtube.com/watch?v=lviLZFciDv4
Et le résulat:
https://github.com/second-reality/reverse-tunnel/commit/3680dc34d69727bad88b3be154a9b3d7862ee8c6
[^] # Re: Ais je compris ?
Posté par Pierrick Bouvier . En réponse au journal Tunneling SSH conteneurisé. Évalué à 1.
Plus exactement, ma machine du boulot essaye (constamment, 1 fois/30sec) d'ouvrir un tunnel vers une ip que je contrôle.
Lorsque je veux y accéder, j'ouvre le serveur sur ma machine perso, le tunnel est alors créé. Je ne laisse pas ma machine perso allumée constamment, et encore moins le serveur ouvert.
Je peux alors me connecter à la machine du boulot.
Je ne cherche pas spécialement à me cacher (sinon écrire un article en mon nom sur linuxfr serait quelque peu stupide), mais si un jour on vient me voir, j'aurais de quoi échanger techniquement.
[^] # Re: Ais je compris ?
Posté par Pierrick Bouvier . En réponse au journal Tunneling SSH conteneurisé. Évalué à 0. Dernière modification le 08 janvier 2020 à 14:54.
Je n'ai pas d'accès SSH ni de VPN au boulot. N'étant pas IT, c'est difficile pour moi de pousser une telle décision.
Mon but, c'est juste de pouvoir lancer une commande que j'aurais oublié facilement depuis la maison, et avoir le résultat le lendemain.
Le problème, c'est la machine personnelle. Elle ne correspond pas à la politique IT de ta boîte, et ça peut faire criser certains d'ouvrir une connexion à l'intérieur du réseau "sécurisé" de ta boîte depuis ta machine. Si un jour j'ai un souci (ça demanderait du deep packet inspection au minimum), je pourrais clairement défendre ma solution. Et puis au fond, c'était juste fun comme idée ;)
Le protocole n'est pas ssh + ftp. C'est ftp, redirigé à travers une connexion ssh. Derrière, ton serveur à la maison transfère en clair avec le FTP final. Mais tu peux avoir un peu plus de confiance en ton FAI que dans le wifi du café du coin.
Ce que tu dis le fait ne pas laisser de traces est pertinent aussi. Un tunnel SSH est très couramment utilisé pour laisser une backdoor sur une machine sur laquelle un attaquant s'est introduit.
[^] # Re: Stunnel dynamique
Posté par Pierrick Bouvier . En réponse au journal Tunneling SSH conteneurisé. Évalué à 2.
À ma connaissance, stunnel ne fait qu'ajouter une couche SSL à une connexion existante (pour un client, ou un serveur), et rien d'autre.
Typiquement, tu as un serveur qui ne parle que http. Tu peux utiliser stunnel pour avoir SSL "gratuitement" par dessus.
Pour vulgariser:
cat mon_fichier | stunnel | OVER_INTERNET | stunnel | cat, donne mon fichier, mais transmis de façon chiffré.
Un tunnel SSH permet davantage. Il offre bien sûr le chiffrement de la connexion, mais de plus, il offre un tunnel qu'on peut établir dans les deux sens, ainsi que la notion de port forwarding (rediriger un port distant sur un autre local et inversement).
Du coup, je dirai plutôt que stunnel est fait pour "décharger" le calcul de SSL sur un point d'entrée donné, et avoir un serveur qui parle en "clair" derrière. En tout cas, je l'avais connu dans ce contexte (car c'est souvent compliqué et error-prone de gérer SSL dans ton appli).
[^] # Re: diminuer la surface d'attaque
Posté par Pierrick Bouvier . En réponse au journal Tunneling SSH conteneurisé. Évalué à 2.
Mon commentaire était en effet un peu gratuit.
En réalité, lorsque j'ai entendu parler de Alpine Linux (pour Docker) cette année, j'ai aussi vu un certain mouvement de devs qui la quittent afin de revenir vers des distributions plus "mainstream", notamment depuis l'arrivée des images réduits ubuntu et debian.
Dans les problèmes reportés:
- soucis liés à la sécurité: https://www.alpinelinux.org/posts/Docker-image-vulnerability-CVE-2019-5021.html
- problème de performance: https://superuser.com/questions/1219609/why-is-the-alpine-docker-image-over-50-slower-than-the-ubuntu-image
- problème dès qu'on a besoin d'un paquet non disponible sous Alpine (et il y en a bien peu que sous debian)
Bien sûr, ces liens sont vieux, et peut-être le projet est-il plus mature. Bien sûr, on peut trouver le même genre d'articles sur Debian.
Mais clairement, adopter Alpine pour le simple besoin d'une plus petit image, en dépit du reste, me convainc assez peu.
Je ne visais pas Busybox, mais plutôt, un "bricolage" autour de Busybox.
[^] # Re: diminuer la surface d'attaque
Posté par Pierrick Bouvier . En réponse au journal Tunneling SSH conteneurisé. Évalué à 1.
J'imagine que tu faisais référence à Debian-slim en parlant de Debian-stretch, que j'ai en effet mis en place à la place de buster (buster -> buster-slim). Merci!
Quant à Alpine, malgré tout le hype autour de cette distribution dans le monde docker, je reste assez sceptique du résultat, notamment d'un point de vue sécurité. Je préfère encore une distribution fiable, basée sur des composants éprouvés, plutôt qu'une surcouche à busybox.
[^] # Re: On est en 2020
Posté par Pierrick Bouvier . En réponse au journal Tunneling SSH conteneurisé. Évalué à 2.
Je suis en accord avec toi, j'ai simplement pris ftp comme exemple d'un protocole "classique" non sécurisé.