Journal Zabbix, autossh, systemd

Posté par (page perso) . Licence CC by-sa
10
9
avr.
2016

Bonjour,

Suite à ce journal : https://linuxfr.org/users/m4rotte/journaux/snmp-vs-nrpe
Je poste ici un howto pour autossh appliqué à Zabbix.
But : avoir des communications chiffrées à travers SSH pour l'agent zabbix en actif et en passif et avoir un reverse tunnel ssh vers les machines avec agent. Il y a l'ID à faire varier pour chaque machine cliente.
RQ : le chiffrement est intégré à Zabbix 3 maintenant. Donc il n'est plus trop souhaitable d'utiliser cette méthode.
RQ : j'avais essayé d'utiliser des IP locales différentes pour chaque client (ex : 127.0.1.1) mais je n'y suis pas arrivé avec ssh. Donc j'ai fait varier les ports d'écoute. Et je me suis dit que 10.000 agents possible c'était déjà bien.

    CLIUSR=sshvpnzabbix
    CLIGRP=${CLIUSR}
    SRVIP=<IP serveur zabbix>
    SRVPORT=22010
    SRVUSR=${CLIUSR}
    SRVGRP=${CLIGRP}

serveur (à faire une seule fois) :

    # coller variables
    groupadd ${SRVGRP}
    useradd --create-home --gid ${SRVGRP} ${SRVUSR} 
    passwd ${SRVUSR} 
    # entrer un mot de passe et le conserver (keepass)

client (à faire sur chaque client :

    groupadd ${CLIGRP}
    useradd --create-home --gid ${CLIGRP} ${CLIUSR}
    su - ${CLIUSR}
    # recoller les variables
    ssh-keygen -t rsa -b 4096 -f ${SRVIP}_id_rsa_4096 # ne pas donner de mot de passe
    chmod 400 ${SRVIP}_id_rsa_4096*
    ssh-copy-id -p ${SRVPORT} -i ./${SRVIP}_id_rsa_4096.pub ${SRVUSR}@${SRVIP}
    ssh -p ${SRVPORT} -i ./${SRVIP}_id_rsa_4096 ${SRVUSR}@${SRVIP}
    # verifier dans .ssh/authorized_keys si tout est OK
    exit # deco ssh du serveur
    exit # retour a root en local sur le client

configuration distribuée :

    NODEID=3
    service zabbix-server stop
    service apache2 stop
    sed -i "s/.*NodeID=.*/NodeID=${NODEID}/g" /etc/zabbix/zabbix_server.conf
    zabbix_server -n ${NODEID} -c /etc/zabbix/zabbix_server.conf
    service apache2 start
    #MASTER : admin -> DM
    #selectioner "node" dans la dropbox en haut à droite
    #vérifier paramètres neud local
    #créer un noeud
    service zabbix-server start

autossh :

    apt-get install autossh

    ASSHHOST=<IP serveur zabbix>
    ASSHKPATH=/home/sshvpnzabbix/${ASSHHOST}_id_rsa_4096
    TUNNELID=3
    ASSHPORT=22010
    ASSHLUSER=sshvpnzabbix
    ASSHDUSER=sshvpnzabbix
    # tunnel local(listen)->distant
    ASSHLDIP=127.0.0.1
    ASSHLLPORT=$((30000+${TUNNELID}))
    ASSHLDPORT=10051
    # tunnel distant(listen)->local
    ASSHRDIP=127.0.0.1
    ASSHRLPORT=$((30000+${TUNNELID}))
    ASSHRDPORT=10051
    # tunnel SSH distant(listen)->local
    ASSHRDIPSSH=127.0.0.1
    ASSHRLPORTSSH=$((40000+${TUNNELID}))
    ASSHRDPORTSSH=22000

    cat << 'EOF' > /etc/systemd/system/sshtunel_${ASSHHOST}_${TUNNELID}.service
    [Unit]
    Description=Keeps a tunnel to '__ASSHHOST__' open, tunnel ID : '__TUNNELID__'
    After=network.target

    [Service]
    User=__ASSHLUSER__
    # -p [PORT]
    # -l [user]
    # -M 0 --> no monitoring
    # -N Just open the connection and do nothing (not interactive)
    # LOCALPORT:IP_ON_EXAMPLE_COM:PORT_ON_EXAMPLE_COM
    Environment="AUTOSSH_GATETIME=0" "AUTOSSH_PORT=0"
    ExecStart=/usr/bin/autossh -M 0 -N -q -o "ServerAliveInterval 60" -o "ServerAliveCountMax 3" -p __ASSHPORT__ -L     __ASSHLLPORT__:__ASSHLDIP__:__ASSHLDPORT__ -R __ASSHRLPORT__:__ASSHRDIP__:__ASSHRDPORT__ -R __ASSHRLPORTSSH__:__ASSHRDIPSSH__:__ASSHRDPORTSSH__ -i __ASSHKPATH__ __ASSHDUSER__@__ASSHHOST__

    [Install]
    WantedBy=multi-user.target

    EOF

    chmod 644 /etc/systemd/system/sshtunel_${ASSHHOST}_${TUNNELID}.service
    sed -i "s|__ASSHHOST__|${ASSHHOST}|g" /etc/systemd/system/sshtunel_${ASSHHOST}_${TUNNELID}.service
    sed -i "s|__ASSHKPATH__|${ASSHKPATH}|g" /etc/systemd/system/sshtunel_${ASSHHOST}_${TUNNELID}.service
    sed -i "s|__TUNNELID__|${TUNNELID}|g" /etc/systemd/system/sshtunel_${ASSHHOST}_${TUNNELID}.service
    sed -i "s|__ASSHPORT__|${ASSHPORT}|g" /etc/systemd/system/sshtunel_${ASSHHOST}_${TUNNELID}.service
    sed -i "s|__ASSHLUSER__|${ASSHLUSER}|g" /etc/systemd/system/sshtunel_${ASSHHOST}_${TUNNELID}.service
    sed -i "s|__ASSHDUSER__|${ASSHDUSER}|g" /etc/systemd/system/sshtunel_${ASSHHOST}_${TUNNELID}.service
    sed -i "s|__ASSHLDIP__|${ASSHLDIP}|g" /etc/systemd/system/sshtunel_${ASSHHOST}_${TUNNELID}.service
    sed -i "s|__ASSHLLPORT__|${ASSHLLPORT}|g" /etc/systemd/system/sshtunel_${ASSHHOST}_${TUNNELID}.service
    sed -i "s|__ASSHLDPORT__|${ASSHLDPORT}|g" /etc/systemd/system/sshtunel_${ASSHHOST}_${TUNNELID}.service
    sed -i "s|__ASSHRDIP__|${ASSHRDIP}|g" /etc/systemd/system/sshtunel_${ASSHHOST}_${TUNNELID}.service
    sed -i "s|__ASSHRLPORT__|${ASSHRLPORT}|g" /etc/systemd/system/sshtunel_${ASSHHOST}_${TUNNELID}.service
    sed -i "s|__ASSHRDPORT__|${ASSHRDPORT}|g" /etc/systemd/system/sshtunel_${ASSHHOST}_${TUNNELID}.service
    sed -i "s|__ASSHRDIPSSH__|${ASSHRDIPSSH}|g" /etc/systemd/system/sshtunel_${ASSHHOST}_${TUNNELID}.service
    sed -i "s|__ASSHRLPORTSSH__|${ASSHRLPORTSSH}|g" /etc/systemd/system/sshtunel_${ASSHHOST}_${TUNNELID}.service
    sed -i "s|__ASSHRDPORTSSH__|${ASSHRDPORTSSH}|g" /etc/systemd/system/sshtunel_${ASSHHOST}_${TUNNELID}.service

    chmod 644 /etc/systemd/system/sshtunel_${ASSHHOST}_${TUNNELID}.service
    systemctl --system daemon-reload
    systemctl start sshtunel_${ASSHHOST}_${TUNNELID}.service
    systemctl enable sshtunel_${ASSHHOST}_${TUNNELID}.service

supprimer le service

    systemctl stop sshtunel_${ASSHHOST}_${TUNNELID}.service
    systemctl disable sshtunel_${ASSHHOST}_${TUNNELID}.service
    rm /etc/systemd/system/sshtunel_${ASSHHOST}_${TUNNELID}.service
  • # comple[t/xe]

    Posté par (page perso) . Évalué à 0.

    J'avais fait plus simple (probablement un peu plus à la rache), mais vu que Zabbix 3 est sorti y'en a plus besoin, jvais pas me faire ch… à donner des détails alors :)

    https://www.domotego.com/ | https://www.maccagnoni.eu/ | https://www.smm-informatique.fr/

  • # Merci

    Posté par . Évalué à 5.

    En plus j'aime bien comment tu gères systemd
    finalement c'est pas si compliqué

    Encore merci

    • [^] # Re: Merci

      Posté par . Évalué à 3.

      D'avance toutes mes excuses, car je n'arrive pas à formuler ma question d'une façon qui ne sonne pas comme un troll - surtout vis à vis de mon passif concernant systemd.

      Ma question est la suivante : quand tu dis

      En plus j'aime bien comment tu gères systemd

      Es-tu sérieux ou sarcastique ?

      Pour moi le type d'automatisation mis en place par ghusson pour la mise en place des différents services et clients est le pire des cauchemars, que ce soit en terme de suivi, de maintenance, de reprise (le mec qui ne sait pas comment on a procédé il va un peu se gratter la tête pour comprendre) etc.

      Suis-je le seul dans ce cas ?

      • [^] # Re: Merci

        Posté par . Évalué à -7.

        c'est quoi exactement le problème ? Pour du bash c'est plutôt malin d'utiliser le manager de service ainsi. Et même pour du non-bash en fait.

        Enfin, au cas où, il n'y a bien qu'un seul service, et une pluie de copier coller, ça c'est vrai que c'est moche.

        Je proposerais bien une petite alternative, mais faudra utiliser un autre langage pour le moteur de template. On peut par contre garder bash pour déclarer les variables et appeler l'outil.

        • [^] # Re: Merci

          Posté par (page perso) . Évalué à 1. Dernière modification le 10/04/16 à 22:16.

          Personnellement je considère autossh comme le démon. Le bash autour n'est la que pour gérer le lancement du démon et les variables. Et systemd gère le service.
          Après pour le déploiement, la configuration, ce serait en effet plus judicieux d'utiliser un système comme Ansible par exemple. Mais ça ne change pas la base de la solution :-)

        • [^] # Re: Merci

          Posté par . Évalué à 3.

          c'est quoi exactement le problème ?

          Le problème c'est que si tu as 100 agents à collecter (et ça va vite de monter à 100 agents et plus) tu te retrouves avec 100 services
          - Que tu dois maintenir/mettre à jour
          - Que tu dois éventuellement monitorer à leur tour
          - Que tu dois documenter
          - Qui ne sont pas vraiment liés à Zabbix (ce sont des tunnels), mais qui ont un impact sur la production si ils tombent.
          etc.

          De plus je me met dans la peau de l'admin system qui reprend le truc (l'ancien admin est en fuite pour cause de compte en banque dans les iles sud américaines - et n'est absolument pas joignable ) , il va dans la config du service (donc plus Zabbix puisque SSH est intégré maintenant, mais un autre) et là il voit que les sondes sont accédées par 127.0.0.1:30000, 127.0.0.1:30002 … 127.0.0.1:30100. Il est content.

          Il va alors chercher le truc qui ouvre le tunnel, et joie, santé, bonheur il tombe sur plus de 100 fichiers de services dans lib/systemd et etc/systemd (ben oui, il y a pas que Zabbix dans la vie). Si l'admin précédent a été très propre il va s'en sortir - par contre si il a été un peu brouillon ou un peu trop prudent on va avoir du NEW-ssh-tunel-XXXX-YYYY-test-DONT_ENABLE.service par paquets. Et vas-y de tester lesquels sont activés et lesquels sont éteints. Eventuellement il sera bon pour faire un tour sur le routeur/collecteur pour voir si il s'agit du lien OOB ou du monitoring spécifique d'un port pour un client.

          Personnellement c'est typiquement un des cas ou j'envoie balader systemd (traduction je lui demande de lancer un wrapper et de ne surtout pas s'en occuper) et ou je passe des variables d'environnement (ou des fichiers de conf - ca marche aussi) dynamiquement à mon wrapper qui fait du coup office de pseudo gestionnaire de service.

          Je centralise toute ma conf en un point, mon wrapper lance les tunnels, fait les test et finalement lance le collecteur.

          Mais maintenant je me dis que je suis peut-être un dino, et que bien entendu tout admin de moins de 35 ans se ruera sur /etc/systemd et comprendra la conf en deux minutes.

          • [^] # Re: Merci

            Posté par (page perso) . Évalué à 2.

            Je comprends tout à fait ton point de vue. Et je n'ai pas finalisé le tout. Saches que :
            1) c'est un hack pour chiffrer le protocole de zabbix, bien que la gateway de reverse SSH soit intéressante fonctionnellement
            2) les services tournent sur les OS clients (donc 1 seul service par OS, pas 100 sur un)
            3) pour faire propre, il faudrait soit un système de déploiement automatique type Ansible, soit faire un paquet, soit packager un minimum et en effet sortir la conf
            4) il doit y avoir une corrélation entre l'ID zabbix, l'ID du tunnel et donc les ports
            Bref, c'est loin d'être fini pour une mise en production massive et parfait. Mais en attendant ça fait bien le job.
            Après en documentant, ce système reste simple et efficace donc pas cher à mettre en œuvre, si il y a peu de noeuds distants. Tu connais la loi des 80/20 ? Il faut rester rentable. Et je pense qu'avec un petit coup d'Ansible ça va le faire :-)

            Après sur la question de la doc, c'est toujours pareil, l'admin qui ne documente pas suffisamment afin qu'il (ou la société qui l'emploie) puisse être tranquille si du jour au lendemain il n'est plus dans la boite (vacances, maladies, quoi que ce soit), est un mauvais admin. Ou alors il n'a pas su convaincre sa hiérarchie de l'intérêt de documenter.

            Au sujet de ta notion de wrapper, pourquoi pas. Mais il est lancé par quoi ? rc.local ? Je ne suis pas d'accord. Systemd a été choisi par Debian. Il a son rôle. Il faut l'utiliser (lancer, maintenir, renvoyer l'état, gérer les services/démons). Ok, il faut faire l'effort de lire la doc. Mais tu utilises toujours ifconfig ou tu es passé à ip link/addr/route ? :-)

            • [^] # Re: Merci

              Posté par . Évalué à 1.

              Alors on commence par la fin :
              J'utilise toujours ifconfig. Sur mes vms j'ai des cartes réseaux qui sont rajoutés dynamiquement, des VPN et des émulateurs ports com qui viennent se mettre par dessus en fonction des besoins et malgré plusieurs tentatives je ne vois pas comment gérer ce genres de choses avec ifup, ip et consors. Surtout que je n'ai pas forcément besoin de TCP/IP sur ces cartes, et que je ne veux pas surtout pas de link-local/mDNS.

              Donc sur mes cartes dynamiques, c'est des sets de règles udev et des scripts à base d'ifconfig qui se lancent.

              Par contre route, clairement je l'utilise quand j'ai besoin. ifconcig ne pas faire grand chose niveau route.

              En ce qui concerne le lancement du wrapper, il est lancé par systemd dans le mode le plus bête possible (pas de surveillance, pas de restart, forcé dans un slice dégénéré avec des droits sur la majorité des cgroups etc.) Le fait que systemd ait été choisit par Debian m'impacte peu. Je vais utiliser les outils Debian dans la mesure du possible, mais très vite je diverge de ce qui est fourni. Pour Apache, Nginx, Postgres/PostGIS, postfix, Nagios/Zabbix, Java/Tomcat etc. J'utilise mes propres packages avec mes propres scripts d'init. Dans la majorité des cas les choix fait par Debian ne sont pas les choix optimaux pour ma production. Pour moi Debian est une base (et un très bonne base, j'aime vraiment beaucoup cette distribution) mais je n'ai aucune hésitation à m'écarter de cette base si ça m'apporte quelque chose.

              En ce qui concerne systemd strictement, la réponse courte est que systemd a trop de lacunes par rapport aux systèmes d'init historiques pour me permettre de faire tout ce dont j'ai besoin. J'ai besoin de services dynamiques, j'ai besoin de pouvoir forcer certains démarrages en mode séquentiel sans pour autant qu'il y ait dépendance (i.e le service b doit se lancer après le service a et ce même si le service a échoue à se lancer - ce genre de condition sont très courantes quand on fait du fencing notamment) et par dessus tout j'ai besoin que des utilisateurs des machines distantes et des services puissent relancer d'autres services sans nécessairement avoir les droits root (et également sans avoir à créer des slices dégénérés tous les quatre matin)

              Pour finir avec ton tutorial, je l'ai lu comme un exemple simple à compléter (que ce soit avec de l'ansible, du saltstack ou des recette cook) et j'ai bien conscience que la pédagogie va parfois à l'encontre de la propreté/qualité. La méthode qui consiste à donner un exemple qui fonctionne et que tout le monde comprend - avant d'expliquer pourquoi il ne faut jamais faire comme ça - est tout à fait valable.

              C'est juste la réaction de Christophe B. avec notamment son "En plus j'aime bien comment tu gères systemd / finalement c'est pas si compliqué" qui m'a fait froid dans le dos.

              • [^] # Re: Merci

                Posté par . Évalué à 3.

                C'est juste la réaction de Christophe B. avec notamment son "En plus j'aime bien comment tu gères systemd / finalement c'est pas si compliqué" qui m'a fait froid dans le dos.

                Je pense qu'il parlait du fait de pouvoir facilement se créer un service.
                Je ne crois pas (mais je peux me planter) qu'il soit sysadmin.

                Tu prends la mouche un peu facilement :)

                Je ne rentrerais pas dans ton troll, mais :

                on fait du fencing

                C'est quoi ?

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: Merci

                  Posté par . Évalué à 4.

                  C'est quoi ?

                  Page Wikipedia

                  Grosso-modo quand tu essayes de faire de la haute disponibilité, de la continuité de service etc. tu te retrouves à devoir gérer des systèmes qui dysfonctionnent mais qui ne s'en rendent pas forcément compte. Il te faut donc des mécanismes qui permettent à un arbitre de prendre des décisions, typiquement tuer ou isoler une instance et un promouvoir une autre comme chef de file. Dans ce genre de cas il faut faire très attention à ce que l'instance dont tu cherches à te débarrasser ne puisse plus agir sur les ressources à présent gérées par l'instance que tu cherches à promouvoir.

                  D’où le terme de fencing - mise en enclos.

                  • [^] # Re: Merci

                    Posté par . Évalué à 3.

                    Ok

                    D’où le terme de fencing - mise en enclos.

                    Mon dictionnaire me dis « escrime ».

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Merci

                Posté par (page perso) . Évalué à 3. Dernière modification le 11/04/16 à 12:05.

                ip n’a rien à voir avec Debian (et ifupdown), il s’agit juste des outils CLI officiels de gestion du réseau depuis la version 2.2 du noyau (utilisant l’interface netlink au lieu de vieux ioctl).

                Qu’entends-tu par link-local ? les adresses V6 ll créées automatiquement par le noyau ?
                /etc/sysctl.d/99-ipv6.conf

                net.ipv6.conf.all.disable_ipv6=1
                net.ipv6.conf.lo.disable_ipv6=0
                

                Il vaut mieux garder IPv6 actif sur lo, certains services (exim) supportent mal de ne pas pouvoir écouter su ::1.

                Pour mDNS, il suffit de ne pas installer avahi et libnss-mdns… Quitte à les blacklister pour qu’il ne descende pas avec des recommand ou suggest :
                /etc/apt/preferences.d/avahi (pas testé)

                Package: avahi*
                Pin: origin ""
                Pin-Priority: -1
                
                Package: libnss-mdns
                Pin: origin ""
                Pin-Priority: -1
                
                • [^] # Re: Merci

                  Posté par (page perso) . Évalué à 0.

                  Bon, là on diverge… (oui j'ai entendu "verge dans le fond de la salle ? - CQP)
                  Déjà qu'on évite le troll sur systemd, on va pas se lancer dans IPv6 si ? En tout cas pour ma part, je passe ;-p

              • [^] # Re: Merci

                Posté par (page perso) . Évalué à 1.

                Ok, je vois un peu mieux ta façon de voir les choses. Comme je dis toujours avant de juger il faut connaître et quand on connaît on a plus envie de juger :-) Du coup je serai curieux d'en savoir un peu plus sur ta façon de faire et ce qui t'as conduit à implémenter toi même du fencing etc. N'hésite pas à m'appeler si tu veux discuter. Tu pourras trouver mes coordonnées par diverses moyens ;-)

              • [^] # Re: Merci

                Posté par . Évalué à 3.

                le service b doit se lancer après le service a et ce même si le service a échoue à se lancer

                C’est ce que fait After=

          • [^] # Re: Merci

            Posté par . Évalué à -8.

            l'ancien admin est en fuite pour cause de compte en banque dans les iles sud américaines - et n'est absolument pas joignable

            attention ! trop de suspicion et tu en deviens suspicieux ;)

            à mon wrapper qui fait du coup office de pseudo gestionnaire de service.

            Donc tu refais un système de gestion de service par dessus le système natif ? Oui, ça se vaut si ton code existe déjà, est éprouvé, et prêt à faire ce job. Si tu dois partir sur un nouveau module c'est déjà une autre histoire.

            Et puis quand à parler de clarté en programmation, des fois t'as envie de pleurer. Moi j'étais bien étonné l'autre jour cf.

            Alors est ce que ton code est vraiment limpide et bugfree pour laisser un autre le reprendre ? Je ne sais pas…

            Mais maintenant je me dis que je suis peut-être un dino, et que bien entendu tout admin de moins de 35 ans se ruera sur /etc/systemd et comprendra la conf en deux minutes.

            arrêtons la suspicion ; ) osef, chacun voit midi à sa porte en fonction de son contexte. De temps en temps une solution commune émerge, sinon on la fait passer par la force. Ça ce trouve elle est très bien ta solution, ça se trouve tu te ***** la nouille devant… M'enfin, si on part sur l'idée d'utiliser bash, c'est surement possible de faire un gestionnaire de service, par contre, je doute sur tout le reste (mais bon je ne suis pas très barbu).

      • [^] # Re: Merci

        Posté par (page perso) . Évalué à 2.

        Qu'est ce que tu reproches au fait que j'utilise systemd pour gérer un service ? Moi ça me paraît naturel.
        En relisant, j'ai laissé traîner des droits abusifs pour le fichier, qui devraient être en 644 au lieu de 755 (si un gentil modérateur passe par la…). Après, je ne sais pas si je fais tout bien avec systemd (wantedby) mais le fait est que ça fonctionne.

      • [^] # Re: Merci

        Posté par . Évalué à 1. Dernière modification le 11/04/16 à 10:00.

        Es-tu sérieux ou sarcastique ?

        Sérieux, voici enfin un exemple simple de service sous systemd (complet en plus)
        en fait c'est un bête fichier texte quelque part avec une syntaxe particulière
        pas de quoi casser 3 pattes à un canard

        J'ai économisé 3h de lecture ;-)

        Surtout que sur mes machines en prod le reboot c'est 1 fois tout les 3 ans :)

        Je trouve que notre ami a bien tout décrit, y compris la génération de clé sans passphrase
        bref c'est simple efficace et concis

        Pour l'histoire des ports / serveurs, je suis arrivé à la même conclusion
        Même si je sais qu'il est tout a fait possible de gérer via des décalage de ports locaux style 127.0.C.S (c=client s=serveur chez le client) impossible avec autossh.

    • [^] # Re: Merci

      Posté par (page perso) . Évalué à 2.

      C'est pas compliqué quand on lit la doc de systemd (j'ai pris 3h pour ça en passant, c'était l'occasion de m'y mettre :-).

  • # Directive EnvironmentFile pour l’unité systemd

    Posté par (page perso) . Évalué à 1.

    Yo

    Ne serait-il pas plus approprié d’utiliser la combinaison instance + EnvironmentFile pour tes services ?

    [Service]
    EnvironmentFile=/etc/sshtunel/%i

    man systemd.unit pour "%i" et les instances et man systemd.service pour EnvironmentFile.

    Et l’unité se nommerait sshtunel@.service et activerais les instances en fonction des fichiers de conf créés.

    Love – bépo

  • # HEREDOC et variables

    Posté par . Évalué à 4.

    Quel avantage à utiliser sed dans ce cas plutôt que juste virer les guillemets du 'EOF' ?

    • [^] # Re: HEREDOC et variables

      Posté par (page perso) . Évalué à 1.

      Je ne comprends pas bien le sens de ta question.
      J'utilise cette méthodo : variables, template, sed parce que pour le moment je ne me suis pas mis à des moteurs de templating ou d'industrialisation de déploiement / gestion de conf. Donc pour moi c'est le bon moyen de séparer les choses en attendant mieux (Ansible / Salt). Avec cette méthode (cat/sed) je ne suis pas embêté avec les problèmes de caractères d'escaping dans les variables bash.

      • [^] # Re: HEREDOC et variables

        Posté par . Évalué à 3.

        Je parle de de placer les variables directement dans le heredoc, comme ça :

        TOTO=kevin
        cat - << EOF
        > '$TOTO'
        > EOF
        'kevin'
        • [^] # Re: HEREDOC et variables

          Posté par (page perso) . Évalué à 2.

          A cause de problèmes de caractères d'escapes et autres. Ça m'est arrivé par le passé, j'ai donc trouvé une méthode fiable, systématique et qui sépare bien les choses avant de faire un pas vers l'automatisation. Exemple, si dans ton texte à remplacer tu as "VAR" ou $VAR, ça peut poser problème. On peut faire autrement, mais cette solution m'a paru saine.

          • [^] # Re: HEREDOC et variables

            Posté par . Évalué à -9.

            les copié-collé c'est comme l'abus d'alcool, c'est une nuisance pour une bonne intelligibilité.

          • [^] # Re: HEREDOC et variables

            Posté par . Évalué à 3.

            Je ne vois pas bien le problème dont tu parle, mais à minima tu peux te simplifier la vie en construisant la commande dans ton script (1 ligne si tu t'embête pas avec les longueurs de ligne, 3 ou 4 sinon) et construire ton document ainsi :

            cat << 'EOF' > /etc/systemd/system/sshtunel_${ASSHHOST}_${TUNNELID}.service
            [Unit]
            Description=Keeps a tunnel to '${ASSHHOST}' open, tunnel ID : '${TUNNELID}'
            After=network.target
            
            [Service]
            User=${ASSHLUSER}
            # -p [PORT]
            # -l [user]
            # -M 0 --> no monitoring
            # -N Just open the connection and do nothing (not interactive)
            # LOCALPORT:IP_ON_EXAMPLE_COM:PORT_ON_EXAMPLE_COM
            Environment="AUTOSSH_GATETIME=0" "AUTOSSH_PORT=0"
            ExecStart=${ssh_cmd_format}
            
            [Install]
            WantedBy=multi-user.target
            
            EOF

            Il est clair et tu évite d'avoir une dizaine de sed compliqué à relire et à mettre à jour.

            À minima quitte à utiliser bash, tu peux faire :

            service_file="/etc/systemd/system/sshtunel_${ASSHHOST}_${TUNNELID}.service"
            declare -A unit_vars
            unit_vars[__ASSHHOST__]="<IP serveur zabbix>"
            # comme tes variables ne servent qu'au remplacement tu peu directement les stocker dans le dictionnaire
            
            for var in "${!unit_vars[@]}" ; do
                sed -i "s|${var}|${unit_vars[$var]}|g" "${service_file}"
            done

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: HEREDOC et variables

              Posté par (page perso) . Évalué à 1.

              Oui ce sont des bonnes idées en effet. J'y regarderai de plus près le jour au j'aurai à mettre ça au propre pour beaucoup de serveurs. Mais je reste convaincu qu'utiliser un Ansible et faire un service systemd très bête sera aussi bien. Parce que avec ta méthode, bien que j'externalise 2 paramètres essentiels, je garde une "intelligence" interne pour déterminer les ports du tunnel. Alors que ces paramètres je pourrai les externaliser en gérant avec Ansible, et mettre l'intelligence à un plus haut niveau. Le tout en ayant une approche plus produit (conf agent + conf tunnel systématisés).

              • [^] # Re: HEREDOC et variables

                Posté par . Évalué à 3. Dernière modification le 11/04/16 à 14:57.

                Ah mais ce que je propose ne fait rien de plus rien de moins que ce que tu as déjà, c'est juste des façons plus agréables de maintenir du shell.

                Oui si tu veux faire de l'ansible, c'est toujours mieux.

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.