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 clientconfiguration 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 startautossh :
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}.servicesupprimer 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 Sébastien Maccagnoni (site web personnel) . É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 :)
[^] # Re: comple[t/xe]
Posté par Parleur . Évalué à 1.
Ce n'est pas inintéressant pour les possesseurs de Debian stable, par exemple, qui sont toujours en version 2.
[^] # Re: comple[t/xe]
Posté par Sébastien Maccagnoni (site web personnel) . Évalué à 3.
https://www.zabbix.com/documentation/3.0/manual/installation/install_from_packages#debianubuntu
http://repo.zabbix.com/zabbix/3.0/debian/
# Merci
Posté par Christophe B. (site web personnel) . Évalué à 5.
En plus j'aime bien comment tu gères systemd
finalement c'est pas si compliqué
Encore merci
[^] # Re: Merci
Posté par Kaane . É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
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 mh-cbon . É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 ghusson (site web personnel) . Évalué à 1. Dernière modification le 10 avril 2016 à 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 Kaane . Évalué à 3.
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 ghusson (site web personnel) . É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 Kaane . É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 barmic . Évalué à 3.
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 :
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 Kaane . Évalué à 4.
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 barmic . Évalué à 3.
Ok
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 Hobgoblins Master (Mastodon) . Évalué à 3. Dernière modification le 11 avril 2016 à 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.confIl 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é)[^] # Re: Merci
Posté par ghusson (site web personnel) . É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 ghusson (site web personnel) . É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 Moonz . Évalué à 3.
C’est ce que fait
After=[^] # Re: Merci
Posté par mh-cbon . Évalué à -8.
attention ! trop de suspicion et tu en deviens suspicieux ;)
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…
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 ghusson (site web personnel) . É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 Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
[^] # Re: Merci
Posté par Christophe B. (site web personnel) . Évalué à 1. Dernière modification le 11 avril 2016 à 10:00.
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 ghusson (site web personnel) . É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 Anonyme . É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.
[^] # Re: Directive EnvironmentFile pour l’unité systemd
Posté par ghusson (site web personnel) . Évalué à 1.
A moins que je n'ai pas compris ton idée, pour moi ce n'est pas nécessaire.
Il y a 1 seul autossh par OS client.
Après pour l'environment file, pourquoi pas. Normalement la bonne pratique serait un fichier /etc/default/autossh_zabbix par exemple. Mais pour ce cas j'ai voulu quelque chose de simple et d'autoporteur. A améliorer avant déploiement massif.
Pour le %i j'ai rencontré ça avec getty. Tiens je vais faire un journal :-) J'ai un peu galérer pour la sonsole sur port série ;p
[^] # Re: Directive EnvironmentFile pour l’unité systemd
Posté par ghusson (site web personnel) . Évalué à 1.
"J'ai un peu galérer pour la sonsole sur port série ;p"
=> "J'ai un peu ramé pour la console sur port série ;p"
il se fait tard…
[^] # Re: Directive EnvironmentFile pour l’unité systemd
Posté par Anonyme . Évalué à 1.
Je crois que LinuxFR m’a mâché un peu de texte :(
Je voulais donc écrite
sshtunel@<instance>.serviceoù<instance>correspondra à tonEnvironmentFile.[^] # Re: Directive EnvironmentFile pour l’unité systemd
Posté par ghusson (site web personnel) . Évalué à 1.
Oui mais c'est pas grave, j'avais compris quand même.
Voir exemple de barmic plus loin.
# HEREDOC et variables
Posté par Tonton Benoit . Évalué à 4.
Quel avantage à utiliser
seddans ce cas plutôt que juste virer les guillemets du 'EOF' ?[^] # Re: HEREDOC et variables
Posté par ghusson (site web personnel) . É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 Tonton Benoit . Évalué à 3.
Je parle de de placer les variables directement dans le heredoc, comme ça :
[^] # Re: HEREDOC et variables
Posté par ghusson (site web personnel) . É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 mh-cbon . É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 barmic . É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 :
Il est clair et tu évite d'avoir une dizaine de
sedcompliqué à relire et à mettre à jour.À minima quitte à utiliser bash, tu peux faire :
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 ghusson (site web personnel) . É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 barmic . Évalué à 3. Dernière modification le 11 avril 2016 à 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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.