Discussion :

[Lekno]

Bonjour à tous, je travail sur une petite app me permettant d'administrer via ssh une ferme de serveur sous ubuntu,
Je souhaite pouvoir automatiser mes commandes sur tout mes serveurs et pour que cela soit plus "facile" à traiter, je voudrai faire passer la sortie des commandes dans un format plus facilement manipulable (json ou xml)

Pour illustrer cela j'utilise très régulièrement la commande "lsof -i -N -P" qui me retourne toutes les connections actives :

Auriez-vous une idée de comment passer d'un "output" classique bash vers un format un peut plus manipulable ? (json, xml ou autres....)

Une autre solution serai de rendre accessible toutes ces informations via une api dédié afin d'éviter tout la surcouche de commande via ssh puis de le traiter manuellement avec des script, si vous avez quelques idées la dessus ...

merci

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
COMMAND   PID      USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
sshd     1306      root    3u  IPv4  54161      0t0  TCP *:22 (LISTEN)
sshd     1306      root    4u  IPv6  54163      0t0  TCP *:22 (LISTEN)
apache2  1431      root    4u  IPv6  18365      0t0  TCP *:80 (LISTEN)
apache2  1435  www-data    4u  IPv6  18365      0t0  TCP *:80 (LISTEN)
apache2  1436  www-data    4u  IPv6  18365      0t0  TCP *:80 (LISTEN)
apache2  1437  www-data    4u  IPv6  18365      0t0  TCP *:80 (LISTEN)
apache2  1438  www-data    4u  IPv6  18365      0t0  TCP *:80 (LISTEN)
apache2  1439  www-data    4u  IPv6  18365      0t0  TCP *:80 (LISTEN)
dhclient 5994      root    6u  IPv4  59801      0t0  UDP *:68
sshd     6681      root    3u  IPv4  65725      0t0  TCP LABOVM.mtromain.local:22->10.0.0.99:38223 (ESTABLISHED)
sshd     6683      root    3u  IPv4  65732      0t0  TCP LABOVM.mtromain.local:22->10.0.0.99:38224 (ESTABLISHED)
sshd     6742  userlabo    3u  IPv4  65725      0t0  TCP LABOVM.mtromain.local:22->10.0.0.99:38223 (ESTABLISHED)
sshd     6742  userlabo    9u  IPv6  65818      0t0  TCP localhost:6010 (LISTEN)
sshd     6742  userlabo   10u  IPv4  65819      0t0  TCP localhost:6010 (LISTEN)
sshd     6750  userlabo    3u  IPv4  65732      0t0  TCP LABOVM.mtromain.local:22->10.0.0.99:38224 (ESTABLISHED)
sshd     6993   root       3u  IPv4  66306      0t0  TCP LABOVM.mtromain.local:22->10.0.0.99:38319 (ESTABLISHED)
sshd     7024  userlabo    3u  IPv4  66306      0t0  TCP LABOVM.mtromain.local:22->10.0.0.99:38319 (ESTABLISHED)

[becket]

Quelque chose comme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
lsof -i -N -P | awk ' $2 ~ /[0-9]/  { print "<process>\n\t<name>"$1"</name>\n\t<pid>"$2"</pid>\n</process>" } '

[Lekno]

super, c'est exactement ce que je cherchais, peux tu m'indiquer comment appel on cela ? Ca me fait penser un peut à du xml mais ca ne correspond pas tout à fait
Je vais utiliser ton exemple pour le compléter suivant mon besoin, top

[becket]

Awk est simplement un langage de scripts qui permet de traiter ligne par ligne des documents textes.
L'exemple est fictif mais il est facile de comprendre le mécanisme pour l'adapter.

[N_BaH]

Bonjour,

reformater un tableau simple et sans ambiguïté vers une format plus complexe et pénible à parser tel que json ou xml...

[Lekno]

Bonjour,
reformater un tableau simple et sans ambiguïté vers une format plus complexe et pénible à parser tel que json ou xml...

xml et json plus complexe et pénible à parser que un tableau ? O0

[becket]

Bonjour,

reformater un tableau simple et sans ambiguïté vers une format plus complexe et pénible à parser tel que json ou xml...

En quoi cette réponse fait avancer cette question ?

Non Le monde ne tourne pas exclusivement autour du shell script ! Il y a énormément de situations au un format différent json/xml ... autre sera plus intéressant qu'un "simple" fichier texte.


Cette sempiternelle bigoterie est particulièrement exaspérante

[N_BaH]

vous rigolez ?

entre ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mon beau tableau roi des tableaux...

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<racine><premièreLigne><premierMot>mon</premierMot></deuxièmeMot>beau</deuxièmeMot>...<niÈmeMot>...</niÈmeMot></premièreLigne></racine><

lequel vous semble le plus simple à parser ?



vous voulez pas utiliser un SGBD complet pour trois lignes de données ?

[Lekno]

Tout dépend de l'utilisation que vous en faite, dire que un tableau est plus simple que utiliser un formatage de données c'est mettre la charrue avant les boeufs ... c'est comme choisir une solution sans connaître la problématique

Dans mon cas l'utilisation de tableau rendrai mon code imbuvable puisque je dois pouvoir réutiliser dans d'autres langage le output de mes commandes bash.

vous voulez pas utiliser un SGBD complet pour trois lignes de données ?

Vous pouvez aussi arrêter les sarcasmes c'est pas super utile dans une discussion

C'est assez comique de voir l'inutilité de votre intervention avec au dessus de votre pseudo "Modérateur", ca donne une super image bravo
becket c'est donné la peine de me répondre de façon constructive, vous vous contentez de balancer des morceaux de vérité sans démontrer quoi que ce soit, donnez vous la peine d'illustrer votre propos avec un exemple concret en rapport avec ma question. Si il est concluant je vous remercierai de m'avoir indiqué une autre solution moins lourde que celle que j'avais en tête en attendant mieux vaut vous abstenir si c'est simplement pour balancer ca.
Amicalement

[N_BaH]

et d'autres langages (probablement plus puissant que bash (ce n'est pas difficile)) ne peuvent pas traiter des données dans un tableau simple ?

plutôt que de transformer les données avec awk, traite les données directement avec awk !

quand tu seras modérateur, tu pourras caresser les intervenants dans le sens du poil jusqu'à te renier si tu veux.

[Flodelarab]

Bonjour

La meilleure réponse est évidemment la première réponse de becket. J'ai répondu pareil en mon for intérieur.
Mais je soutiens N_BaH quand il dit que la question n'est pas bonne.

J'ai l'impression d'assister à une discussion écologiste entre les partisans de légumes tels quels, et ceux qui veulent des légumes sous emballages. Ces derniers prétendent que c'est plus propre, et les premiers indiquent que cela ne sert à rien de mettre un plastique (->pétrole) superfétatoire. Mon cœur penche pour les légumes tels quels.

L'information, toute l'information, rien que l'information. Le balisage xml ou les séparateurs multiples du format JSON (accolades ouvrantes, fermantes, crochets ouvrants, fermants, les deux points, la virgule) sont compliqués. Pour rien. l'information brute est déjà donnée par la commande lsof elle-même. La seule justification d'un tel reformatage serait une exigence client. Sinon c'est une perte de temps. Pour aucun gain de productivité.

Bon. Je vais me mettre sous cellophane pour me protéger de la vague de critique.

[CosmoKnacki]

On ne peut pas mettre JSON et XML dans le même sac en papier ou en plastique d'amidon (attention, le panier d'osier fait son retour en force). Enfonçons les portes grandes ouvertes de l'AMAP:

• Le JSON est un format léger qui sert exclusivement à la transmission de données. Chaque langage a sa petite fonction ou au pire sa bibliothèque pour l'importer facilement dans une structure de données qui lui est propre. Et ça ne sert qu'à ça.¹
  (Au passage on peut aussi se demander si le CSV n'est pas un meilleur candidat dans le cas présent car encore plus léger que l'original et tout aussi répandu que le format JSON.)
• Par contre le XML, s'il est plus lourd, ouvre plus de perspectives. Ce n'est pas juste un format de données, c'est surtout l'accès à XSD pour valider, XSLT pour transformer, XPath pour trouver, XQuery pour interroger... Ce qu'on peut faire de la même manière dans pratiquement tous les langages et avec de nombreux outils.

On peut raisonnablement se demander l'intérêt de convertir ce tableau au format JSON (CSV même combat) si ce n'est pour éviter trois lignes de code, et tout ça pour aboutir à une structure de données imposée qui ne colle pas forcément à ce qu'on veut en faire et chiante comme la mort à interroger (à grand renfort de boucles). Mais bon parfois on a pas le choix, genre le logiciel qui ne sait importer que ça.

Avec le XML on n'est plus dans la simple transmission de données. On se place d'emblée dans la perspective de l'exploitation des données. De fait, la lourdeur du parsing (que le développeur n'a pas à supporter) devient secondaire.


_{1. Il existe bien l'outil jq pour traiter directement du JSON, ainsi que le langage de requête JSONiq, mais il est très peu diffusé.}

[Lekno]

Je prend note de vos remarques

[chrtophe]

Les formats json et XML sont des formats structurés mais restant lisibles par l'humain (bien que n'étant pas le but premier). Les sorties des commandes systèmes ne sont pas faites pour être retraités bien que tu puisses les envoyer à d'autres commandes via des pipes par exemples.

L’intérêt de "transformer" tes sorties brutes en XML ou autres, c'est de les exploiter avec des outils attendant du XML justement. Je suppose que c'est ce que tu cherches à faire, que l'outil soit de toi ou un produit existant.

Regardes ceci :
https://antoine-solnichkin.developpe...ec-prometheus/
Tu verras qu'il y a des briques te permettant de te faciliter la tâche.

Il existe aussi des produits tout fait répondant à ton besoin.
on
Edit : En gros c'est à toi de récupérer la sortie des commandes et de la mettre au bon format.
Pour le XML, tu peux regarder du coté de XMLStartlet qui va te permettre de manipuler un fichier XML depuis la ligne de commande (non exhaustif, d'autres utilitaires doivent exister), car les commandes de type awk etc tu auras vite fait d'avoir un XML invalide.

[disedorgue]

Il y a une option spéciale de lsof pour une sortie dans un format facilement traitable par un programme externe sans ambiguïté sur les champs:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

man -P'less "+/^OUTPUT FOR OTHER PROGRAMS"' lsof