eth0 link-ok check script

Linux-kezdő

Ki hogyan készítene ellenőrző scriptet arra, hogy vajon kihúzták-e az adott eth0 kártyából a kábelt?

pici én konkrétan úgy, hogy folyamatosan futtatnám az

if mii-tool eth0 | grep -q "no link"; then echo uristenkihuztak-datumbele-egy-filebe; else echo noproblem; fi

-t.

mert az adott routerban pl.: vlan lenne beállítva, hogy ne lehessen sniffelni a másik forgalmát u.a. alhálózatról, vagy kalóz dhcp-t futtatni, viszont egy switchbe átdugva két kábelt meg nem ér semmit a vlan, ezért lenne jó csekkolnom, hogy vajon átrakják-e a kábeleket egy másik switchbe, ami a routerba van dugva, pl.: az eredeti portba, ahol volt a saját gépem.

ciklusba rakva nem jó, mert tudtommal a pl.: sleep-ben 1 mp-nél kevesebbet nem lehet megadni, és lehet, hogy gyorskezű az illető :D

csak elmélkedem

  • 904 megtekintés

( mn3monic v | 2010. 01. 10., v – 14:43 )

Meg lehet adni sleep-nek kisebbet mint 1 sec, de szerintem is ifplugd.

( gbor | 2010. 01. 10., v – 17:50 )

szerintem sokkal nagyobb élvezete van pl.: ennek: 


#!/bin/bash

clear

while true; do
	if ! mii-tool eth0 | grep -q "link ok"
		then 
			PANIK_KEZDO_IDO=$(date "+%F %H:%M %Ss")
				while ! mii-tool eth0 | grep -q "link ok"; do
					sleep 1
				done
			PANIK_VEGE_IDO=$(date "+%F %H:%M %Ss")
			echo "no link from: "$PANIK_KEZDO_IDO" to: "$PANIK_VEGE_IDO"!"
	fi
	sleep 1
done

és most jöhetnek a programozók leszólni a béna kód miatt :D:D

--
irj egy e-mailt, ha itt barmi hibat talalsz. ^ ^

( godot v | 2010. 01. 10., v – 18:53 )

Szerintem a logot figyeld, a kernel logolja az ilyen eseményeket.

Jan 10 18:50:56 abc kernel: [29441.245209] e1000e: eth0 NIC Link is Down
Jan 10 18:51:04 abc kernel: [29449.877733] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX

Nálam általában azért, mert minden gépen van log figyelő alkalmazás (ami a menedzsment alkalmazás része ) és egyszerűbb +1 eseményre figyelést beállítani mint erre külön scriptet faragni.
Általában is azt szoktam javasolni, hogy mindent a logba kell beküldeni, még a custom scriptek eredményeit is mert a log később visszakereshető + letöbbször remote logszerverre továbbítva van stb....

Ja és ebben az esetben meg főként azért, mert nem kell folyamatosan egy végtelen ciklust futtatni sleep-el, hanem a kernel neked azonnal jelez, mindek szenvedni ha megcsinálják helyetted. Másrészt az mii-tool megbízhatatlan, bizonyos driverekkel nem jó státuszt jelez, ha már script inkább ethtool.

Mindket meglatast tamogatom.

A logfigyelesnek sok elonye van a tipikus busy loop megoldasokkal szemben, tobbek kozt:
- rogton jon a jelzes az esemenyrol, nem x varakozas utan
- nem lehetseges, hogy egy tul rovid ideig tarto (oda-vissza) valtozasrol elmarad a jelzes
- altalaban kevesebb eroforrassal beeri

Itt a debian-administration.org-on valaha osszeirtam egy pelda konfigot logfigyelesre inotify-jal, de nyilvan lehet talalni millio mas megoldast is ra.

Es az mii-tool-lal is pont nemreg szivtam, hogy egyaltalan nem ismeri a gigabites interface-eket, szoval +1 for ethtool.

szerk.: Az mondjuk okozhat gondot, hogy a dmesgbe kerulo logok szovege driverenkent valtozik, vagy akar egy extra gagyi driver lehet, hogy nem is logolja az L2 statusz valtozasat.

Lehet olyan log figyelő alkalmazás is ami periodikusan fut, de ez korántsem biztos.

Pl itt a syslog-ng+megfelelő filter+program destination tökéletes lehet.
A filterben meghatározott logsorra a program destination azonnal reagál.

http://www.balabit.hu/dl/html/syslog-ng-v3.0-guide-admin-en.html/ch08s0…

A program destination pedig lehet bármi, egy nagios plugin, mail küldés snmp trap stb.

Különben a topic eredeti kérdésfelvetése ha jól értem nem is akart mást csak rögzíteni az eseményt, ehhez nem kell semmit tenni benne van a logban.