Pour surveiller l'état de machines, et de service, ping ne suffit pas.
D'abord, il retourne toujours NOERR, et en plus j'ai souvent vu des machines
plantées avec la pile TCP/IP vivante.
Une meilleure solution ne serait-elle pas l'usage de nc(1) ?
Du genre :
| $ nc -n -z 192.168.100.1 25 || logger -si -p kernel.err \
| "Et m***e, le SMTP est encore tombe !"
Oui, je loggue kernel.*, c'est pas bô, mais ça fait hurler la console (et
est reporté par periodic/security/whatever )
On voit bien en mode verbose ce que donne l'option -z :
| $ nc -vv -n -z 192.168.100.1 25 && echo "OK"
| (UNKNOWN) [192.168.100.1] 25 (?) open
| sent 0, rcvd 0
| OK
Parce qu'un passage de la doc m'ennuie :
> The nc utility exits after both input streams (it's stdin and the remote
> socket) have been closed. It doesn't do this very well, and relies
> rather heavily on the network layers at both ends for this.
J'ai pas envie de laisser ma crontab créer des tas de sockets zombies...
Merci,
XAv
--
Xav
NetBSD, parce que je le vaux bien
http://www.tibet.fr/
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Julien Salgado
Xavier HUMBERT a écrit :
Bonjour,
Bonjour,
Pour surveiller l'état de machines, et de service, ping ne suffit pas. D'abord, il retourne toujours NOERR, et en plus j'ai souvent vu des machines plantées avec la pile TCP/IP vivante.
Une meilleure solution ne serait-elle pas l'usage de nc(1) ? [...snip...]
Pour faire de la supervision, on peut aussi utiliser des outils faits pour par exemple nagios : http://www.nagios.org/ Ça évite d'avoir à réinventer la roue.
On touche un peu au sujet du groupe fr.comp.reseaux.supervision, tu peux avoir un peu plus de réponses là-bas.
-- Julien
Xavier HUMBERT a écrit :
Bonjour,
Bonjour,
Pour surveiller l'état de machines, et de service, ping ne suffit pas.
D'abord, il retourne toujours NOERR, et en plus j'ai souvent vu des machines
plantées avec la pile TCP/IP vivante.
Une meilleure solution ne serait-elle pas l'usage de nc(1) ?
[...snip...]
Pour faire de la supervision, on peut aussi utiliser des outils faits pour
par exemple nagios :
http://www.nagios.org/
Ça évite d'avoir à réinventer la roue.
On touche un peu au sujet du groupe fr.comp.reseaux.supervision, tu peux
avoir un peu plus de réponses là-bas.
Pour surveiller l'état de machines, et de service, ping ne suffit pas. D'abord, il retourne toujours NOERR, et en plus j'ai souvent vu des machines plantées avec la pile TCP/IP vivante.
Une meilleure solution ne serait-elle pas l'usage de nc(1) ? [...snip...]
Pour faire de la supervision, on peut aussi utiliser des outils faits pour par exemple nagios : http://www.nagios.org/ Ça évite d'avoir à réinventer la roue.
On touche un peu au sujet du groupe fr.comp.reseaux.supervision, tu peux avoir un peu plus de réponses là-bas.
-- Julien
Medhi BENKIR
Xavier HUMBERT wrote:
Bonjour,
Pour surveiller l'état de machines, et de service, ping ne suffit pas. D'abord, il retourne toujours NOERR, et en plus j'ai souvent vu des machines plantées avec la pile TCP/IP vivante.
Une meilleure solution ne serait-elle pas l'usage de nc(1) ?
Nessus, par ailleurs fort utile en environnement multi-administrateurs, est livré en standard avec tout un tas de scripts capables de tester efficacement les services courants Unix.
Au besoin, Nessus est livré en standard avec un interprète nasl2 en ligne de commande. Au besoin, nasl2 est un langage un peu étrange, mais avec lequel il est aisé d'écrire des scénarios de test de protocoles.
Xavier HUMBERT wrote:
Bonjour,
Pour surveiller l'état de machines, et de service, ping ne suffit pas.
D'abord, il retourne toujours NOERR, et en plus j'ai souvent vu des machines
plantées avec la pile TCP/IP vivante.
Une meilleure solution ne serait-elle pas l'usage de nc(1) ?
Nessus, par ailleurs fort utile en environnement multi-administrateurs,
est livré en standard avec tout un tas de scripts capables de tester
efficacement les services courants Unix.
Au besoin, Nessus est livré en standard avec un interprète nasl2 en
ligne de commande. Au besoin, nasl2 est un langage un peu étrange, mais
avec lequel il est aisé d'écrire des scénarios de test de protocoles.
Pour surveiller l'état de machines, et de service, ping ne suffit pas. D'abord, il retourne toujours NOERR, et en plus j'ai souvent vu des machines plantées avec la pile TCP/IP vivante.
Une meilleure solution ne serait-elle pas l'usage de nc(1) ?
Nessus, par ailleurs fort utile en environnement multi-administrateurs, est livré en standard avec tout un tas de scripts capables de tester efficacement les services courants Unix.
Au besoin, Nessus est livré en standard avec un interprète nasl2 en ligne de commande. Au besoin, nasl2 est un langage un peu étrange, mais avec lequel il est aisé d'écrire des scénarios de test de protocoles.
mna
Bonjour,
salut,
Pour surveiller l'état de machines, et de service, ping ne suffit pas. D'abord, il retourne toujours NOERR, et en plus j'ai souvent vu des machines plantées avec la pile TCP/IP vivante.
je suis assez d'accord avec ces propos. Pour ma part j'utilise nagios qui sait surveiller tout ça impeccablement.
si l'ensemble nagios est trop lourd pour toi, je pense que tu peux ré-utiliser uniquement les pluggins nagios qui permettent de jouer des tests de services smtp, pop, ntp, .... mysql, oracle, ...
tous ces pluggins sont des scripts shell, perl ou parfois des executable ELF. Ils sont dispo en solo http://www.nagios.org/download/
si tu leur passes les bons arguments tu pourras logger les différentes sorties comme tu le proposes..
bonne continuation. mna.
Bonjour,
salut,
Pour surveiller l'état de machines, et de service, ping ne suffit pas.
D'abord, il retourne toujours NOERR, et en plus j'ai souvent vu des machines
plantées avec la pile TCP/IP vivante.
je suis assez d'accord avec ces propos. Pour ma part j'utilise nagios
qui sait surveiller tout ça impeccablement.
si l'ensemble nagios est trop lourd pour toi, je pense que tu peux
ré-utiliser uniquement les pluggins nagios qui permettent de jouer
des tests de services smtp, pop, ntp, .... mysql, oracle, ...
tous ces pluggins sont des scripts shell, perl ou parfois
des executable ELF. Ils sont dispo en solo
http://www.nagios.org/download/
si tu leur passes les bons arguments tu pourras logger les différentes
sorties comme tu le proposes..
Pour surveiller l'état de machines, et de service, ping ne suffit pas. D'abord, il retourne toujours NOERR, et en plus j'ai souvent vu des machines plantées avec la pile TCP/IP vivante.
je suis assez d'accord avec ces propos. Pour ma part j'utilise nagios qui sait surveiller tout ça impeccablement.
si l'ensemble nagios est trop lourd pour toi, je pense que tu peux ré-utiliser uniquement les pluggins nagios qui permettent de jouer des tests de services smtp, pop, ntp, .... mysql, oracle, ...
tous ces pluggins sont des scripts shell, perl ou parfois des executable ELF. Ils sont dispo en solo http://www.nagios.org/download/
si tu leur passes les bons arguments tu pourras logger les différentes sorties comme tu le proposes..
bonne continuation. mna.
Arnaud Launay
Le Fri, 01 Oct 2004 18:11:25 +0200, Medhi BENKIR écrivit:
Au besoin, Nessus est livré en standard avec un interprète nasl2 en ligne de commande. Au besoin, nasl2 est un langage un peu étrange, mais avec lequel il est aisé d'écrire des scénarios de test de protocoles.
Connaissant bien les créateurs de Nessus et de nasl/nasl2, ça n'a rien de bien étonnant :_)
Le Fri, 01 Oct 2004 18:11:25 +0200, Medhi BENKIR écrivit:
Au besoin, Nessus est livré en standard avec un interprète nasl2 en
ligne de commande. Au besoin, nasl2 est un langage un peu étrange, mais
avec lequel il est aisé d'écrire des scénarios de test de protocoles.
Connaissant bien les créateurs de Nessus et de nasl/nasl2, ça n'a
rien de bien étonnant :_)
Le Fri, 01 Oct 2004 18:11:25 +0200, Medhi BENKIR écrivit:
Au besoin, Nessus est livré en standard avec un interprète nasl2 en ligne de commande. Au besoin, nasl2 est un langage un peu étrange, mais avec lequel il est aisé d'écrire des scénarios de test de protocoles.
Connaissant bien les créateurs de Nessus et de nasl/nasl2, ça n'a rien de bien étonnant :_)
