JulienG a écrit 71 commentaires

  • [^] # Re: Pas "moins permissive"

    Posté par  . En réponse au journal Activer Elasticsearch pour son instance Mastodon. Évalué à 1. Dernière modification le 29 août 2023 à 19:30.

    Sur Opensearch mea culpa, en effet ma phrase est mal formulée. Tu as raison sue le fond, Opensearch est libre et Elasticsearch non.

    Non je n'ai pas testé une alternative - voir l'échange Mastodon que je cite en intro, qui indique des instances qui utilisent Opensearch.

    Pour l'usage au sein de Mastodon, voici un commit de la documentation du projet :
    https://github.com/mastodon/documentation/commit/18defebf2f5eba82c403a6ef8be4ae336d6611f4

    Elasticsearch est cité à plusieurs reprises. En partie parce que c'est une bibliothèque de l'éditeur qui est utilisée en interne, cf. :
    https://oisaur.com/@renchap/110961332489669407

    Pour le fond, je te laisse contacter l'auteur pour avoir plus de détails, je n'en sais pas plus…

  • [^] # Re: Oups

    Posté par  . En réponse au message Signature S3 et comportement du navigateur Web . Évalué à 1.

    J'aime tellement cet article de Wikipedia… ! Merci.

  • [^] # Re: Oups

    Posté par  . En réponse au message Signature S3 et comportement du navigateur Web . Évalué à 2.

    Bon… il faut croire que mettre à plat mes idées dans un post de forum aide (beaucoup)… Finalement j'ai abandonné l'idée d'envoyer Date via une requête gérée par fetch. Et comme je suis dans une WebExtension, je peux aller modifier les entêtes juste avant l'envoi réel :

    function ajouter_entete_date(details) {
      console.log("ajouter_entete_date", details);
      const headers = details.requestHeaders;
      headers.push({ name: "Date", value: date });
      return { requestHeaders: headers };
    }
    browser.webRequest.onBeforeSendHeaders.addListener(
      ajouter_entete_date,
      { urls: ["<all_urls>"] },
      ["blocking", "requestHeaders"]
    );

    Et là plus de problème !

    Je vais voir pour avoir un entête bidon avec un jeton de type X-Date-{jeton} qui sera écouté. Si cet entête est trouvé, il est transformé en entête classique Date. Le jeton ne sera connu que de l'extension elle-même, et aléatoire.

    PS : jugez-moi.

  • # Oups

    Posté par  . En réponse au message Signature S3 et comportement du navigateur Web . Évalué à 3.

    Je m'auto-réponds sur la partie entête "Date" : on ne peut pas l'envoyer.

    Mais du reste, ça ne devrait pas poser problème si on en croit la doc AWS :

    Some HTTP client libraries do not expose the ability to set the Date header for a request. If you have trouble including the value of the 'Date' header in the canonicalized headers, you can set the timestamp for the request by using an 'x-amz-date' header instead. The value of the x-amz-date header must be in one of the RFC 2616 formats (http://www.ietf.org/rfc/rfc2616.txt). When an x-amz-date header is present in a request, the system will ignore any Date header when computing the request signature. Therefore, if you include the x-amz-date header, use the empty string for the Date when constructing the StringToSign.

    Là je sèche vraiment…

  • [^] # Re: Instance n'est pas relais

    Posté par  . En réponse au journal Héberger son instance Mastodon (seulement en profil individuel ?). Évalué à 2.

    En effet, après approfondissement, erreur de ma part :
    https://github.com/mastodon/mastodon/discussions/17187#discussioncomment-1868314

  • # J'ai même pas mis le lien vers ma propre instance...

    Posté par  . En réponse au journal Héberger son instance Mastodon (seulement en profil individuel ?). Évalué à 5.

    Pour me suivre : https://mastodon.nothus.fr.

  • [^] # Re: memforget et fuite mémoire

    Posté par  . En réponse au journal cTypes + Rust = approfondir une relation d'amour et d'eau (fraîche) . Évalué à 2.

    Merci de ton retour et de tes alertes !

    Sur la partie __del__, j'ai bien conscience qu'il existe des cas limites. Comme tu le soulignes, rien n'empêche d'exploiter par le développeur en appelant malib.liberer_valeurretour( obj_ptr ) "au bon moment" (celui qui serait attendu).

    Sur le deuxième point c'est effectivement un corollaire à ton commentaire initial : ne connaissant pas tous les pointeurs vers un objet en mémoire, on ne connaît pas l'usage de tous ces pointeurs potentiels.
    Par contre je m'interroge sur le caractère automatique de la désallocation de la stratégie d'emprunt et de suppression de Rust. Peut-être auras-tu une réponse ?

    Premier cas :

    struct MonObjet {
      champ: UnAutreObjet // possession "stricte"
    }

    … c'est le cas de mon exemple. La mémoire est libéré par Rust, car il a la possession. Si un pointeur existe vers cette valeur en mémoire, c'est embêtant mais pas pour l'objet source : pour celui-ci, pas de problème.

    Si par contre j'avais eu un partage mutable ou non :

    struct MonObjet {
        champ: &UnAutreObjet // multiples emprunts non-mutables possibles 
    }
    struct MonObjet {
        champ: &mut UnAutreObjet // un seul emprunt mutables possible 
    }

    … Rust n'aurait pas libéré la mémoire, car il n'a pas de possession mais d'emprunt. La désallocation dans de tel cas, invaliderait gravement le fonctionnement des durées de vie.

    Ça marche parce que tu copies les valeurs du tableau rust dans un tableau python.

    Dans l'exemple, ma compréhension du phénomène est la suivante : le passage dans liberer_valeurretour supprime le tableau car j'ai déclaré côté Rust, la pleine possession de celui-ci.

    "la gérer correctement dans une couche glue entre deux langages qui n'ont pas les mêmes logiques de gestion mémoire n'est pas une mince affaire."

    Ce journal à au moins cet avantage de (bien) mettre en lumière qu'on peut se prendre facilement les pieds dans le tapis, oui. Mais sinon on ne progresse pas :)

    PS : hâte de lire ça si tu fais un journal sur le sujet.

  • [^] # Re: memforget et fuite mémoire

    Posté par  . En réponse au journal cTypes + Rust = approfondir une relation d'amour et d'eau (fraîche) . Évalué à 2.

    @Maga : voici une proposition de complément de l'article. Si tu l'as l'occasion / la possibilité d'y jeter un coup d’œil… (peur d'une coquille supplémentaire)


    Mea maxima culpa

    Errare humanum est, perseverare diabolicum : j'ai fait une erreur. Pris dans mon élan je n'ai pas évoqué la question de la libération de la mémoire. En réalité, j'avais tort sur ma vision de la gestion de la mémoire par cTypes.

    Mon idée était la suivante : cTypes n'évoque à aucun moment la question de la libération de la mémoire. J'ai supposé que c'est la stratégie de gestion de la mémoire de Python qui s'applique, et donc qu'il était en capacité de prendre en charge pour nous.

    Las, le commentaire de GaMa, tape juste : quoiqu'il arrive ça pêche sur l'usage, car un pointeur renvoie vers une zone qui peut avoir elle-même d'autres pointeurs (voir ici et ). Il faut gérer côté Python cet aspect, en demandant côté Rust dans notre cas, la libération de la mémoire. Et il ne peut pas connaître du reste, toutes les tailles à désallouer (typiquement le tableau mais pour d'autres éléments, il connaît la taille).

    Dans notre bibliothèque Rust, rajoutons donc le nécessaire :

    #[no_mangle]
    pub unsafe extern "C" fn liberer_valeurretour( ptr: *mut ValeurRetour ) {
        drop(Box::from_raw(ptr));
    } 

    Côté Python, c'est plus compliqué. On doit gérer désormais la durée de vie de la mémoire derrière le pointeur, mais l'appeler au bon moment pour ne pas désallouer côté Rust et utiliser côté Python.

    Pour cela, le mieux que j'ai trouvé est d'avoir un objet intermédiaire dont on aura le signal de destruction. ("__del__"). C'est lui qui permettra de faire appel à la désallocation :

    print( "--- partie 3.2 - création d'un objet de retour de taille indéterminée à l'appel" ) 
    
    class ValeurRetour(Structure): # on n'utilise pas directement 
      _fields_ = [ 
        ( "a", c_int ),
        ( "contenu", POINTER(c_int) )
      ] 
    
    malib.test_array_retour_complexe.restype = POINTER( ValeurRetour )
    malib.liberer_valeurretour.argtypes = [POINTER( ValeurRetour ),] # on généralise à toutes les valeurs retours 
    
    class EnveloppeValeurRetourLibDistante():
    
      def __init__( self ): 
        self.obj_ptr = malib.test_array_retour_complexe( 
          len(tableau) 
        ) 
        self.a = self.obj_ptr.contents.a 
        c = self.obj_ptr.contents.contenu 
        self.contenu = [ c[i] for i in range(0,self.a) ]
    
      def __del__(self): 
        # l'objet d'enveloppe de l'objet pointeur Python va être supprimé :
        # il déclenche donc la libération de la mémoire allouée par Rust 
        malib.liberer_valeurretour( self.obj_ptr )
    
    obj_enveloppe = EnveloppeValeurRetourLibDistante()
    
    print( "[PYTHON] ===>", obj_enveloppe.a, obj_enveloppe.contenu)

    Si la comparaison d'attributs vous est importante, gardez à l'esprit que cTypes créée un nouvel objet interne à chaque appel à l'objet pointé, comme l'illustre l'exemple de la documentation :

    from ctypes import *
    i = c_int(42)
    pi = pointer(i)  
    pi.contents is pi.contents # vaut False 

    Cependant si vous vous ne souciez pas de ce point, pensez au décorateur "property" pour envelopper plus aisément l'appel à l'objet lié par le pointeur, dans l'objet d'enveloppe :

    class EnveloppeValeurRetourLibDistante():
      # (...)
      @property
      def a(self):
        return self.obj_ptr.contents.a 
    
      @property
      def contenu(self):
        return self.obj_ptr.contents.contenu

    Enfin vous pouvez retrouver très facilement le jeu de poupées imbriquées qui sert à la mécanique interne ("tout est objet en Python") :

      def __init__( self ): 
        self.obj_ptr = malib.test_array_retour_complexe( 
          len(tableau) 
        ) 
        print( self.obj_ptr )
        print( self.obj_ptr.contents )
        print( self.obj_ptr.contents.contenu.contents )

    Au premier niveau, on retrouve bien un objet "pointeur" à la sauce Python :

    <__main__.LP_ValeurRetour object at 0x7fdd12f7f940>

    Qui permet d'accéder via ".contents" à l'objet "reconstitué" via la classe du même nom,

    <__main__.ValeurRetour object at 0x7fdd12f7c6c0>

    Qui permet lui-même d'accéder à mon tableau au travers d'un autre pointeur :

    <__main__.LP_c_int object at 0x7fdd12f7c3c0>

    Qui, devinez quoi ?, me permet d'accéder à ma valeur (la première case qui est à 42, puis de pouvoir d'itérer sur le tableau en mémoire).

  • # Edition de l'article ?

    Posté par  . En réponse au journal cTypes + Rust = approfondir une relation d'amour et d'eau (fraîche) . Évalué à 1.

    Si un administrateur ou un habitué du site connaît le meilleur moyen pour demander l'édition de ce journal (à qui je l'envoi… ? comment ?) car je sèche un peu sur l'aide du site…

  • [^] # Re: memforget et fuite mémoire

    Posté par  . En réponse au journal cTypes + Rust = approfondir une relation d'amour et d'eau (fraîche) . Évalué à 3. Dernière modification le 07 novembre 2022 à 19:53.

    Mea maxima culpa.

    https://doc.sagemath.org/html/en/thematic_tutorials/numerical_sage/ctypes_examples.html

    La doc est pas claire justement, car elle indique que le pointeur donné est transformé en une référence interne, elle-même utilisée ailleurs si nécessaire. En reprenant la stratégie globale d'allocation des variables Python, ça ne m'a pas choqué. Compte tenu que tu déclares le type, j'ai bêtement pensé qu'il connaissait donc sa taille calculable et par conséquent, faisait le nécessaire.

    C'est moche. Je regarde pour la fuite mémoire et j'écris cette semaine une édition de cet article.

    Merci !

    Edit : Wrapper "__del__" pour appel à Box comme tu m'indiques.

  • [^] # Re: memforget et fuite mémoire

    Posté par  . En réponse au journal cTypes + Rust = approfondir une relation d'amour et d'eau (fraîche) . Évalué à 3.

    Si j'en crois la doc, Python récupère le pointeur et créé via cTypes, tout le nécessaire pour gérer son cycle de vie. Donc non, il n'y a pas de risque.

    En somme je garde la mémoire allouée pour qu'elle passe sous la supervision Python via un pointeur, sous la forme d'une objet référençable interne : l'objet cible (ou la référence elle-même) qui l'utilisera formera sa première référence incrémentée.

    Si l'objet cible n'est plus utilisé, il sera supprimé par le GC qui décrémentera le compteur interne de l'objet référençable, qui tombera à 0 et sera donc lui aussi supprimé.

    • Rust -> emprunt et temps de vie statique
    • Python -> compteur de références

    De ce que j'en ai compris - à confirmer par un connaisseur -, c'est le principe de Numpy.

  • [^] # Re: Merci

    Posté par  . En réponse au journal cTypes + Rust = approfondir une relation d'amour et d'eau (fraîche) . Évalué à 3. Dernière modification le 06 novembre 2022 à 19:17.

    C'est plus reposant pour l'esprit, et ça permet de plus ce concentrer sur les problématique à résoudre, et moins sur la technique pour les résoudre.

    Je suis entièrement d'accord avec toi. Rust a vraiment des qualités intrinsèques tant la définition du langage comme grammaire que du fonctionnement de son compilateur (et ses outils associés), que c'est un plaisir. Avec la garantie de la mémoire comme une sublime cerise. Il nous oblige à faire correctement.

    Bien sûr j'ai rajouté un peu d'humour sur la différence entre interprété et compilé. Du reste j'ai plaisir à Python pour la beauté de résoudre certains aspects métier, en faisant une (forte) abstraction du sous-jacent technique.

    Pour les projets perso, je ne me vois pas commencer un projet ou un développement un peu conséquent, si d'abord passer par la case "script pythonique" pour tenter d'abord de bien saisir ce que j'ai à faire et les ramifications. Après le passage à Rust est juste l'outil le plus correct pour tout mettre en œuvre ou simplement "accélérer" un traitement comme ce week-end.

    Au passage, merci pour ton commentaire sur l'intérêt de l'article.

  • [^] # Re: MicroVM ?

    Posté par  . En réponse au journal # Du serverless au FaaS - et du Golang -, c'est l'été . Évalué à 1.

    "à quelques ajustements près". Horreur.

  • [^] # Re: Ne pas craindre la Faucheuse

    Posté par  . En réponse au journal # Du serverless au FaaS - et du Golang -, c'est l'été . Évalué à 1.

    Rust te propose des aides, mais il ne te garantie absolument pas que ton code gère bien la mémoire :-)

    J'entends bien ! :) Cependant comme l'indique barmic :

    La gestion de l'ownership réduit pas mal le risque, mais tu as toujours la possibilité d'écrire des algos monstrueux d'un point de vue mémoire.

    Si mon algo est foireux, mon code est de toute façon foireux. Je distingue bien les deux : la mise en œuvre (Rust y apporte des garanties sur la propriété et donc indirectement sur la gestion de la mémoire, le partage et la [dés]allocation) et la définition de la résolution (où aucun langage ne t'apporte une garantie, parce que par nature, ça relève du travail - pour l'instant - humain).

  • [^] # Re: Ne pas craindre la Faucheuse

    Posté par  . En réponse au journal # Du serverless au FaaS - et du Golang -, c'est l'été . Évalué à 1. Dernière modification le 10 septembre 2022 à 09:46.

    Sur cette partie oui, mais le début de l'intervention est dans la même veine : "c'était nouveau", "pour pas avoir de débat des dév sur le choix du langage", etc. Dans son conclusion il le rappelle : c'était Go parce que système et "efficace" (efficient) du point de vue du projet (temps de compilation, organisation, etc.). Et qu'à la base, c'était parti d'un hack total.

    Du reste au-delà du choix de Go par Docker, il y a sa critique pas très subtile des choix du langage, qui me semblent justifiée.

  • [^] # Re: MicroVM ?

    Posté par  . En réponse au journal # Du serverless au FaaS - et du Golang -, c'est l'été . Évalué à 1.

    Je ne connaissais pas Firecracker, et l'approche semble très intéressante. Par contre ça limite un environnement Linux (ce qui n'est pas pour me déplaire….).

    L'avantage que j'y vois, ce sont les cas un peu limite des conteneurs ou si la volonté d'isolation avec l'hôte est prioritaire. Par contre ça impose plus de travail amont vis-à-vis d'un conteneur sur la question des images (image d'environnement vs image kernel). Sur ce point, la prédominance et la facilité de Docker ou Podman, me semblent dominer.

    Quant au démarrage, je pense que c'est un débat d'implémentation. Je ne doute pas que Firecracker ou Qemu soit aussi rapide que Docker, peut-être davantage à la marge des conteneurs (c'est un sentiment, j'ai pas de preuves particulières pour étayer). Docker (ou Podman) peut être très rapide si on passe directement via sa socket et sans demander une conf complexe (ce qui est mon cas).

    Là j'ai fait un choix qui est un compromis sur l'implémentation, en passant par une invocation de commande, qui est le pire scénario en lancement individuel ("fonction"), mais très raisonnable pour la partie "service". Par contre je suis plus robuste sur un portage vers d'autres OS - à quelques ajustements prêts.

    Autres éléments à prendre en compte : l'API de Firecracker est certes fournie, mais elle correspond à la partie infrastructure / montage de la VM. Ce que je propose là, c'est cette abstraction justement, au profit d'une API qui se concentre sur "ajouter une route qui conduit vers un truc qui porte ma fonction" (avec des délais, une authentification, etc.).
    L'API de Firecracker ne gère donc aucun espace de nom pour organiser les microVM et faire la liaison entre une requête entrante / une microVM. Idem pour Qemu avec une socket activation.

    Firecracker n'est pas Amazon Lambda, mais seulement un bout de celui-ci. C'est un sous-ensemble parfaitement justifié pour les problématiques d'isolation, mais dans le cas que je présente (réseau privé et/ou de développement), rajoute un élément extérieur à mon binaire solitaire (qui plus est en Go, et la comm' Rust/Go…), sans révolutionner la nature de la problématique métier que je présente.

  • [^] # Re: Ne pas craindre la Faucheuse

    Posté par  . En réponse au journal # Du serverless au FaaS - et du Golang -, c'est l'été . Évalué à 1.

    Ne pas s'intéresser à la question et se la prendre quand on découvre que ça fait des semaines, mois, années qu'on applique aucune règle posera toujours problème.
    rust te contrains à entrer dans des cas qu'il sait gérer (mais il y a des patterns qu'il ne sait pas gérer) dès le départ.

    Perso c'est ce que j'apprécie dans Rust : je sais que je suis une quiche pour gérer la mémoire finement (manque de temps, de compétences), et il me garantie que les patterns qu'il contraint, forment la meilleure option qui m'est offerte face à l'étendu de mon ignorance. J'ai à la fois une garantie que ça fonctionne sans problème, que mon code est "juste" et avec plutôt les bonnes pratiques sur ces questions (parce que j'ai confiance dans la qualité de la communauté des développeurs derrière). Royal !

    J'en profite pour mettre le lien vers la vidéo évoqué dans l'article qui hélas n'est pas passée dans le contenu de l'article : "Pourquoi Maurice ne doit surtout pas coder en GO", de Jean-Laurent de Morlhon (directement sur l'extrait sur le "pourquoi" réel de Go pour Docker).

  • [^] # Re: Go remplace Java

    Posté par  . En réponse au journal # Du serverless au FaaS - et du Golang -, c'est l'été . Évalué à 3.

    Tes arguments sont justes et je suis d'accord avec toi, j'ai l'impression qu'une partie des applications bascules de Java à Go. Surtout sur la portabilité de plus en plus simple et naturelle entre plateformes à l'ère des conteneurs, ça marginalise à mon sens la JVM.

    Par contre est-ce qu'il y a suffisamment de bibliothèques disponibles pour lui faire une vraie "ombre" ? (vraie question)

  • # Post-scriptum

    Posté par  . En réponse au journal # Du serverless au FaaS - et du Golang -, c'est l'été . Évalué à 1.

    Il reste probablement plein de coquilles malgré la relecture… Par avance, veuillez m'en excuser !

  • [^] # Re: il faudrait le réécrire <s>en Rust</s> !

    Posté par  . En réponse au journal Test de vie et Ansible : un exemple de réalisation pour mieux comprendre l'outil . Évalué à 4.

    Et après tu utilises hiera ou tout autre node classifier pour gérer les différences entre les groupes de machines ou des exceptions.

    J'avoue ne pas comprendre : tu peux avoir des inventaires automatiques ou des inventaires statiques ; avec des notions de groupes hiérarchisés entre eux (idem pour la gestion des varibles). Tu peux avoir cette faculté directement au sein d'Ansible. Je ne dis pas que c'est mieux qu'un autre applicatif de la même famille, mais en soi je retrouve ce potentiel dans Ansible, sans l'ombre d'un problème.

    Ansible c'est juste bien pour remplacer des scripts bash de déploiement par dessus des trucs pas forcément bien gérés/administrés (…)

    Si tu navigues sur Ansible-Galaxy, tu trouveras du sale. Comme tous les produits applicatifs de la planète, qui ont l'équivalent d'une place de marché aux modules.

    A titre perso, je suis plutôt content que l'outil soit permissif sur les machines à qui il s'adresse. De plus ramener Ansible à un script Bash, comme cela a été dit dans les autres commentaires, c'est oublier la notion de description d'un état désiré lors de l'appel à un module - le fonctionnement normal - plutôt qu'un script impératif avec beaucoup d'embranchements.

    Derrière le code exécuté peut être le même (au sens où l'action réalisée serait la même), mais l'orchestration, la maintenance et les déploiements sont radicalement différent. Ce sujet est en préambule de la doc officielle de l'outil.

    Cela permet une généralisation très forte, en segmentant le module comme une opération ou un ensemble limité d'opérations dans un but déterminé. Les rôles permettent encore de produire des ensembles qui seront contextualisés par les playbooks. Ce but peut être technique ou davantage "métier".

    (…) et ça plait beaucoup aux sysadmins du dimanche parce qu'ils peuvent continuer à faire de la merde comme avant, sauf que c'est en YAML donc ils peuvent dire qu'ils sont Devops et prétendre à un salaire plus élevé parce que les RH adorent ce mot.

    Jugement de valeur non ? Les salariés de chez RedHat, c'est tous des sysadmins du dimanche ?

  • [^] # Re: il faudrait le réécrire <s>en Rust</s> !

    Posté par  . En réponse au journal Test de vie et Ansible : un exemple de réalisation pour mieux comprendre l'outil . Évalué à 5.

    Tu décris des états, tu ne les codes pas (enfin, tu codes si tu écris toi-même les modules sous-jacent.)

    Je suis bien d'accord sur la notion d'état désiré. Pour la partie "pas coder dans le playbook", ce n'est hélas pas rare de le voir via les deux modules de l'enfer : "Shell" / "Win_Shell". Combien le font, par méconnaissance (ou flemme) ? On se retrouve avec des déploiements in-maintenables et pas d'idempotence…

    Probablement qu'une partie du problème vient de là, dans la culture et l'image que renvoient Ansible.

  • [^] # Re: il faudrait le réécrire <s>en Rust</s> !

    Posté par  . En réponse au journal Test de vie et Ansible : un exemple de réalisation pour mieux comprendre l'outil . Évalué à 4.

    C'est un mauvais langage de script parce que c'est justement pas censé être un langage de script.

    Ça ce discute. À partir du moment où cela gère des instructions, des variables, des conditions, des entrées et des sortie, je ne vois pas ce qui le différencie d'un langage de programmation.

    En soi Ansible ne gère rien, sinon du déclaratif : on lui donne une liste d'états désirés, et ce sont les modules (Python, PS1, ou autres) qui font le taff. La machine distante (qui peut être localhost à l'occasion), renvoie des états post-opération, et Ansible va donc superviser la suite en fonction de ce retour.

    Ansible n'a même pas connaissance des valeurs réelles sur les machines, vu qu'il envoie une charge utile à la machine distante et qu'il n'intervient donc pas durant cette phase (à de rares exceptions près, mais subsidiaires).

    Bash peut faire le même travail effectivement : tu gères tes accès à la machine distante, les commandes à envoyer, etc. Mais un dry run ou des opérations un peu complexes (au sens "métier" j'entends), dans une phase d'industrialisation du SI, c'est inimaginable avec Bash. Non que ça soit impossible - par Bash ou par le langage x -, mais parce que c'est juste imbitique par conception, car pas la finalité première.

  • [^] # Re: il faudrait le réécrire <s>en Rust</s> !

    Posté par  . En réponse au journal Test de vie et Ansible : un exemple de réalisation pour mieux comprendre l'outil . Évalué à 1. Dernière modification le 24 mars 2022 à 23:22.

    C'est rarement un choix fait par les devs :-)

    Ne me jetez pas la pierre, faut bien que je justifie mon salaire… ;)

  • [^] # Re: il faudrait le réécrire <s>en Rust</s> !

    Posté par  . En réponse au journal Test de vie et Ansible : un exemple de réalisation pour mieux comprendre l'outil . Évalué à 5.

    Parfois on a du texte sans guillemet, et parfois il faut mettre des guillemets alors que ça ne sera pas du texte (!).

    Ce n'est pas "la faute" à Ansible, mais au respect de la grammaire YAML. Déconcertant certes. Mais pas illogique.

    L'autre aspect vraiment regrettable est qu'Ansible n'est pas du tout pensé pour être API-isable, avec simplement un ansible-runner qui fait semblant de l'être.

    Tout à fait d'accord. Mais parce que le principe est d'avoir soit l'accès en une "ligne de commande" (enfin un panel restreint), soit via un outil graphique type AWX/Tower.

    Après on peut automatiser Ansible en faisant un playbook Ansib-… heu… attendez…

  • [^] # Re: il faudrait le réécrire <s>en Rust</s> !

    Posté par  . En réponse au journal Test de vie et Ansible : un exemple de réalisation pour mieux comprendre l'outil . Évalué à 4.

    En soi n'importe quel ordinateur est vecteur d'attaque : un serveur AWX/Tower ou un poste d'administrateur.

    Si on centralise sur l'un ou l'autre, tout l'accès au SI avec des privilèges élevés, le résultat sera le même : pas bon.

    Au-delà de l'usage d'AWX, le principe d'avoir un serveur dédié est de ne pas avoir l'effet oups lors que l'administrateur part en vacances, que son poste crame pour x raison(s). Un serveur peut avoir aussi ses difficultés, mais si on respectueux de ne pas lui faire porter la terre entière, et qu'on a des serveurs physiques ou VM dédiés par usage, voire des pools, ça limite la casse.

    Maintenant sur le fond : un poste d'admin ou d'AWX, ça se surveille. Si la sécurité est vraiment importante, ce n'est certainement pas en direct qu'on fait pointer le poste de commandement de déploiement vers l'infra : on passe par un bastion (pour Linux hein, pour Windows… non mais faut juste retirer Windows). Là c'est ce qui est autorisé qui passe, même en commandes envoyées. Pas parfait, mais mieux que rien.