SUSE server alatt van olyan lehetőség, hogy ha az egyik network interface lemegy down-ba, akkor ennek hatására egy script-et lefuttasson automatikusan?
Kizárólag, a fizikai állapot esetén. Tehát az nem érdekel, hogy IP szinten elérhető e valami, csak ha a kábel kihúzás, vagy másik oldali sw hiba esetén, mikor a port lemegy down-ba.
Oize, tenyleg csak a tisztanlatas vegett: az ifup.d/ifdown.d nem csak akkor fut le, amikor az ember az erintett parancsokat kiadja? Link down eseteben sztem ezek a parancsok es scriptek nem futnak le.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
Anno, diplomamunkaként írtam egy kiegészítést iptables-hez, ami figyelte az adott interfész állapotát...
Ez alapján tudott a rendszer szabályokat alkalmazni...
Nem tudom, jó-e neked...
Köszi mindenképp megnézem.
Igazából az érdekelt, hogy a rendszer generál e valamilyen eseményt ezen változás kapcsán, amire lehet felfűzni egy saját kis scriptet, vagy nekem kell figyelni pl a /sys/class/net/ethx/carrier állapotát.
Igen, de minden szabványos mód ennek konfigurációjára az ifup ifdown parancs. Ha hálózati menedzsert futtatsz akkor ő ezt fogja meghívni unplug eseményre
Én nem mondtam network-managert, bár amit akar az igen csak erre hajaz (a network-manager alapesetben nem egy őrült ötlet ott ahol ilyet akar valaki) neki elég egy dhcpcd vagy egy netplug
Az nem hálózati esemény a gépen belül, hülyeség rászervezni bármilyen operációs rendszer folyamatot. Ha a hoston van notification (azaz valaminek az állapota változik) akkor történik ilyen. Ha te hálózat monitorozást szeretnél az egy másik kérdés. Vannak rá programok pl. nagios. (amik tudnak notification, és cselekvést is tudnak tenni). ie: a "nem látszik, felrobban a switch" azért egy komplex probléma (meddig nem látszik, időszakos e, stb)
Ez egy ideiglenes megoldás lenne.
Az a lényeg, ha ennek a gépnek az egyik interface-e pl eth0 down-ba kerül, akkor tegye a másik pl eth1-et is abba, hogy az erre jövő forgalmat az erre küldő eszköz egy másik irányba terelje.
Tehát ha kihúzom a kábelt eth0-ból akkor eth1 mennyen down-ba. Ha lekapcsolom a switch tápját akkor eth1 menjen down-ba. Ha bedugom a kábelt vagy adok tápot a switch-nek, akkor eth1 legyen ismét vagy legyen up.
Primitív hülyeség, de én ezt szeretném egy teszt miatt.
Értem, hogy tesztelsz, de elmondhatnád, konkrétan mi a terved :D
Lehet sokkal jobb megoldások is vannak...
Polling: pazarlás
Event driving: nehézkes...
Viszont lehet lenne jobb megoldás is.
Amit én látok, hogy ha nem cross-link az eth1-ed a másik oldallal (azaz simán csak egy másik switch-be nyomtad), akkor a külvilág nem fogja érzékelni, hogy az eth1-edet lenyomtad...
Teszt célból be lett illesztve egy gép active/slave interface-es gép forgalmába, mert switch anomáliák vannak. De ha ez az interface leesés előjön, akkor ezt közölni kell ugyebár a másik oldalon lévő géppel, hogy tereljen, ha eddig erre ment minden.
Tükrözni akarom az egyik ethernet port állapotát a másikra. A gépben 3 ethernet port van így nem tűnik el örökre :)
nem inkább a hálókártyának kellene pl. callback event-et generálnia ha a driver úgy érzékeli megszakadt a link? ez a mp-kénti polling-ozás a lehető legpazarlóbb megoldás, amit csak el lehet képzelni. Ha az interface ugrál le-fel 1 mp alatti időközönként, azt nem fogja érzékelni.
Hozzászólások
http://stackoverflow.com/questions/2261759/get-notified-about-network-i…
Igazából akkor jobb, ha írok rá egy saját figyelő script-et, és abból valósítom meg.
Hülyeség, ott a ifup.d meg az ifdown.d (gondolom szépen megy suse alatt is)
Ez akkor is áll, ha kihúzom a kábelt, vagy a switch portja lehal, vagy az egész sw felrobban és leszakad?
--
Most akkor mit is szeretnél?
Hálózati esemény lehet:
- interface fel/le állapot,
- hálózat fel/le állapot.
1. if-up.d/if-down.d
2. script (ping, fping, oping)
Debian Linux rulez... :D
Kizárólag, a fizikai állapot esetén. Tehát az nem érdekel, hogy IP szinten elérhető e valami, csak ha a kábel kihúzás, vagy másik oldali sw hiba esetén, mikor a port lemegy down-ba.
Erről szól a dolog. if-up.d if-down.d
1. Fizikai állapot változás if-up.d/if-down.d...
2. Másik oldali sw hiba???? sw=software vagy sw=switch ???
Ha jól értem, akkor csak az 1. pont kell neked... A 2. valami képzavar...
--
Debian Linux rulez... :D
Oize, tenyleg csak a tisztanlatas vegett: az ifup.d/ifdown.d nem csak akkor fut le, amikor az ember az erintett parancsokat kiadja? Link down eseteben sztem ezek a parancsok es scriptek nem futnak le.
--
szerintem is ez a helyzet, ezért kérdeztem rá.
Teszteltem és nem futtatja le csak belső események ifup/ifdown használata esetén.
Anno, diplomamunkaként írtam egy kiegészítést iptables-hez, ami figyelte az adott interfész állapotát...
Ez alapján tudott a rendszer szabályokat alkalmazni...
Nem tudom, jó-e neked...
http://glsys.eu/iface
--
Debian Linux rulez... :D
Köszi mindenképp megnézem.
Igazából az érdekelt, hogy a rendszer generál e valamilyen eseményt ezen változás kapcsán, amire lehet felfűzni egy saját kis scriptet, vagy nekem kell figyelni pl a /sys/class/net/ethx/carrier állapotát.
Igen, de minden szabványos mód ennek konfigurációjára az ifup ifdown parancs. Ha hálózati menedzsert futtatsz akkor ő ezt fogja meghívni unplug eseményre
De itt meg mindig nem ez a feladat, szerveren a NetworkManager meg meg csak emlitesre sem kerul. De az otlet alapvetoen nem volt rossz.
--
Én nem mondtam network-managert, bár amit akar az igen csak erre hajaz (a network-manager alapesetben nem egy őrült ötlet ott ahol ilyet akar valaki) neki elég egy dhcpcd vagy egy netplug
Az nem hálózati esemény a gépen belül, hülyeség rászervezni bármilyen operációs rendszer folyamatot. Ha a hoston van notification (azaz valaminek az állapota változik) akkor történik ilyen. Ha te hálózat monitorozást szeretnél az egy másik kérdés. Vannak rá programok pl. nagios. (amik tudnak notification, és cselekvést is tudnak tenni). ie: a "nem látszik, felrobban a switch" azért egy komplex probléma (meddig nem látszik, időszakos e, stb)
Ez egy ideiglenes megoldás lenne.
Az a lényeg, ha ennek a gépnek az egyik interface-e pl eth0 down-ba kerül, akkor tegye a másik pl eth1-et is abba, hogy az erre jövő forgalmat az erre küldő eszköz egy másik irányba terelje.
Tehát ha kihúzom a kábelt eth0-ból akkor eth1 mennyen down-ba. Ha lekapcsolom a switch tápját akkor eth1 menjen down-ba. Ha bedugom a kábelt vagy adok tápot a switch-nek, akkor eth1 legyen ismét vagy legyen up.
Primitív hülyeség, de én ezt szeretném egy teszt miatt.
Bonding ? Ott lehet definiálni, h load balancing-ot szeretnél vagy failover-t a másik csatolóra.
anti-szabályt szeretne, nem failovert. ha elmegy az egyik interfész, menjen a másik is vele együtt.
Ahh. Nem olvastam végig... :(
Értem, hogy tesztelsz, de elmondhatnád, konkrétan mi a terved :D
Lehet sokkal jobb megoldások is vannak...
Polling: pazarlás
Event driving: nehézkes...
Viszont lehet lenne jobb megoldás is.
Amit én látok, hogy ha nem cross-link az eth1-ed a másik oldallal (azaz simán csak egy másik switch-be nyomtad), akkor a külvilág nem fogja érzékelni, hogy az eth1-edet lenyomtad...
Szóval mit szeretnél?
--
Debian Linux rulez... :D
Teszt célból be lett illesztve egy gép active/slave interface-es gép forgalmába, mert switch anomáliák vannak. De ha ez az interface leesés előjön, akkor ezt közölni kell ugyebár a másik oldalon lévő géppel, hogy tereljen, ha eddig erre ment minden.
Tükrözni akarom az egyik ethernet port állapotát a másikra. A gépben 3 ethernet port van így nem tűnik el örökre :)
Az, amivel a problémádat korrektül lehetne megoldani, azt úgy hívják, hogy dinamikus routing.
Pl. http://www.quagga.net/docs.php
Ezt sikerült összevadászni. Netlink nem 10 perces olvasmány :-)
A recv() addig vár, amíg a kernel nem üzen.
Futtattam a laptopomon: kihúztam a kábelt, majd visszadugtam. Összesen ez a két üzenet jött:
Kiírás helyett system(), és még az is lehet hogy jó lesz neked :-)
ifplugd ?
http://0pointer.de/lennart/projects/ifplugd/
Másodpercenként kérdezi le az interface állapotát.
nem inkább a hálókártyának kellene pl. callback event-et generálnia ha a driver úgy érzékeli megszakadt a link? ez a mp-kénti polling-ozás a lehető legpazarlóbb megoldás, amit csak el lehet képzelni. Ha az interface ugrál le-fel 1 mp alatti időközönként, azt nem fogja érzékelni.