Portál AbcLinuxu, 25. dubna 2024 08:26
/dev/eth0
ani existovat nemá, síťové rozhraní (interface) je úplně něco jiného než zařízení (device). Zkuste se podívat, jestli vám ji vypíše 'ip link show
', pak ji nakonfigurujete pomocí
ip link set eth0 up
ip addr add 1.2.3.4/28 brd + dev eth0
(ty hodnoty si samozřejmě upravte podle sebe). Do jakého konfiguračního souboru máte co napsat, aby se nastavení provedlo automaticky po startu systému, to záleží na konkrétní distribuci/instalaci.
Když se chci pobavit, pustím si v televizi (např.) Jistě, pane premiére nebo mrknu (např.) na Kompost. Od příkazů pro konfiguraci síťových rozhraní neočekávám, že mne pobaví, očekávám, že mi umožní přehledně a efektivně konfigurovat to, co konfigurovat chci. A tuto roli ip
na rozdíl od ifconfig
nebo route
plní.
Docela by me zajímalo jestli budete stejne nadšeným zastáncem nových pořadků až Linusovi rupne v bedně znova a "koncepce implementace sítí v linuxovém jádře" se změní po čtvrté.
Pokud vím, takto zásadní změna proběhla pouze jednou a "pachatelem" byl především Alexej Kuzněcov. Jestli budu novou implementaci verbálně podporovat, bude záležet na tom, zda mne přesvědčí o své výhodnosti. A v tomto případě tomu tak je.
Serie ipfwadm->ipchains->iptables je skutečně jasné připomenutí, že není radno investovat do ziskávání odbornosti v tomto směru.
I v tomto případě musím konstatovat, že jak ipchains, tak netfilter byly tak výrazným krokem vpřed, že to za trochu námahy se změnou syntaxe konfiguračního příkazu určitě stálo. Zejména v případě druhého zmíněného přechodu navíc ty (syntaktické) rozdíly nebyly tak hrozné. Navíc např. změna rozdělení paketů mezi INPUT, FORWARD a OUTPUT umožnila ve většině případů konfiguraci velmi výrazně zjednodušit.
ifconfig
už je hezkých pár let obsolete. Používejte ho, vyhovuje-li vám to, ale neučte ho, prosím, začátečníky.
ip addr add 172.16.0.1/24 dev eth0
ip addr add 172.16.1.1/24 dev eth0
ifconfig
Ten příkaz funguje jen v jakési emulaci, která je neúplná. Nemluvě o tom, že pomocí něj (a hlavně pomocí jeho kamaráda route
) spoustu věcí vůbec nelze nastavit. Je to stejné jako učit někoho s jádrem 2.4 nebo 2.6 nastavovat filtrovací pravidla pomocí ipchains
.
ifconfig
, route
, arp
apod. odpovídaly původní koncepci implementace sítí v linuxovém jádře, která se používala do řady 2.0. V řadě 2.2 (resp. 2.1) ale byla koncepce sítí zcela přepracována a neodpovídá koncepci, se kterou počítají původní příkazy.
Dobře je to vidět třeba na přiřazení více adres jednomu rozhraní. V původní koncepci se vytvořilo virtuální rozhraní, kterému jste přiřadil druhou adresu (pro každou adresu jedno). Jenže ve skutečnosti už dlouho žádné takové virtuální rozhraní neexistuje, přiřazujete všechny adresy jednomu skutečnému rozhraní a příkaz ifconfig
jeho existenci pouze předstírá na základě parametru label
. Pokud ten label neuvedete (viz příklad výše), příkaz ifconfig
další adresy vůbec neuvidí. Ta fiktivní virtuální rozhraní jsou pak nesmírně matoucí - viz např. evergreen nastavení paketového filtru "Proč mi nefunguje 'iptables ... -i eth0:0 ...
'?"
Navíc pomocí starých příkazů lze nastavit jen pár základních věcí. Neexistuje AFAIK např. možnost pomocí route
používat více směrovacích tabulek a vybírat mezi nimi pomocí pravidel (policy routing), nastavit multipath route atd.
ifconfig eth0 up
syntaxe ip bohužel nikdy nemůže dosáhnout. Takže ifconfig je pro normální lidi pohodlnější než ip, jestli funguje jako emulace, frontend, nebo cokoli, to je jedno. Jediný problém je, že by neměl zkoušet emulovat věci, které neumí, aby existovalo jasné odlišení, co s ním lze dělat.
ip link set eth0 up
' o tolik nesrozumitelnější než 'ifconfig eth0 up
'? Mně se na iproute2 líbí právě ta syntaktická konzistence, u ifconfig
se třeba vůbec nerozlišuje nastavování adres od nastavování příznaků rozhraní. Jen by mohli rozhraním přestat říkat 'dev
'...
S tou emulací to není jedno - viz můj příklad s ipchains, což je podobná situace, také emulace starší koncepce kvůli zpětné kompatibilitě. Nedávno jsem totiž někde zahlédl zmínku o tom, že se plánuje zrušení emulace ipchains. Přitom přechod od ipchains k netfilteru proběhl až o jednu stabilní řadu později než přechod k iproute2...
příkazCo to? Co ze neuvidi? Co to je za nesmysl?ifconfig
jeho existenci pouze předstírá na základě parametrulabel
. Pokud ten label neuvedete (viz příklad výše), příkazifconfig
další adresy vůbec neuvidí. Ta fiktivní virtuální rozhraní jsou pak nesmírně matoucí - viz např. evergreen nastavení paketového filtru "Proč mi nefunguje 'iptables ... -i eth0:0 ...
'?"
# ifconfig
eth0 Link encap:Ethernet HWaddr 00:04:61:68:4A:C8 inet addr:81.x.x.x Bcast:81.x.x.x Mask:255.255.255.224 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2726448 errors:0 dropped:0 overruns:0 frame:0 TX packets:3033446 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1388099644 (1323.7 Mb) TX bytes:3692917154 (3521.8 Mb) Interrupt:21 Base address:0xa000 ... eth0:13 Link encap:Ethernet HWaddr 00:04:61:68:4A:C8 inet addr:81.y.y.y Bcast:81.y.y.y Mask:255.255.255.240 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2726477 errors:0 dropped:0 overruns:0 frame:0 TX packets:3033478 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1388132862 (1323.8 Mb) TX bytes:3692943802 (3521.8 Mb) Interrupt:21 Base address:0xa000 ... eth0:18 Link encap:Ethernet HWaddr 00:04:61:68:4A:C8 inet addr:81.z.z.z Bcast:81.z.z.z Mask:255.255.255.248 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2726478 errors:0 dropped:0 overruns:0 frame:0 TX packets:3033479 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1388134092 (1323.8 Mb) TX bytes:3692943856 (3521.8 Mb) Interrupt:21 Base address:0xa000
# ip addr show
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:04:61:68:4a:c8 brd ff:ff:ff:ff:ff:ff inet 81.x.x.x/27 brd 81.x.x.x scope global eth0 ... inet 81.y.y.y/28 brd 81.y.y.y scope global secondary eth0:13 ... inet 81.z.z.z/29 brd 81.z.z.z scope global secondary eth0:18
label
, příkaz ifconfig
vám ji opravdu neukáže. Můžete si to snadno vyzkoušet na příkladu, který jsem uvedl ve svém příspěvku z 26.11.2004 22:29.
ip
, jehoz moznosti minimalne 95 procent lidi nikdy nevyuzije a pro lidi, co pet hodin denne nedatlujou do Cisco konzole, je jaksi ponekud... ehm, divny.
ip addr show
virtualni rozhrani podle vas neukazuje?! Ja teda vidim neco uplne jineho - viz vypis vyse.
ip link show
'. Také by pak mělo vlastní příznaky a parametry, takže byste mu např. mohl nastavit jinou hodnotu MTU nebo ho shodit/nahodit nezávisle na původním eth0
, mohl byste na něm provádět třeba traffic control, mohl byste ho použít jako argument podmínky -i
příkazu iptables
atd. Nic z toho ale udělat nemůžete - právě proto, že ve skutečnosti žádné takové rozhraní neexistuje.
eth0:0
neexistuje a všechny ty adresy jsou přiřazeny jednomu rozhraní eth0
. Chyba příkazu ifconfig
je (mimo jiné) v tom, že vám předstírá, že je to jinak.
ipchains
(který je mimochodem méně zastaralý než ifconfig
).
ifconfig
nepoužil už nejméně tři roky, jeho syntaxi jsem dávno zapomněl, přesto mi to nijak nebrání spravovat linuxové servery i desktopy, ani školit konfiguraci Linuxu (včetně síťových záležitostí). Takže naprostá nutnost to rozhodně není - spíš koule u nohy.
ifconfig
, snadno podlehnou dojmu, že to je jediná možnost. Proto se snažím upozorňovat, že tomu tak není.
ipchains
? Já ne.
Mimochodem, nějak se mi zdá, že v určitém okamžiku jste přestal argumentovat a od té doby jste se zmohl už jen na posměšky, které při absenci věcných argumentů působí poněkud trapně...
Správně. Navíc operuje s koncepcí, která už ve skutečnosti neexistuje. A přesně takový je vztah mezi ifconfig
/route
/arp
a příkazem ip
.
stejne tak ji nastavim ted a snad i za 5 let
Zatím ano, pokud vám nevadí, že nastavíte-li už dnes v některých distribucích dvě adresy na jedno rozhraní pomocí jejich konfiguračních nástrojů nebo konfiguračních souborů, příkaz ifconfig
vám ukáže jen jednu. A na těch pět let bych nespoléhal, ta emulace nebude fungovat věčně...
ifconfig
? V této diskusi jsem napsal spoustu důvodů a na příkladech doložil, proč je chybou stále ještě používat BSD-style příkazy. Pokud si myslíte, že něco z toho není pravda, napište mi co, ale neoperujte prosím tím, že ifconfig
musí být přeci dobrý, když ho tolik lidí používá. Takový způsob uvažování neberu. Zatím jsem tu ale bohužel jiný argument pro ifconfig
neviděl.
Mimochodem, proč byste si ty skripty nemohl přepsat? Já to u Slackware dělám skoro deset let. Na Slackware je spousta skvělých věcí, ale rc.inet1
to není ani náhodou. Vždycky jsem si myslel, že distribuce jako Slackware nebo Gentoo si člověk pořizuje, aby si s nimi mohl pohrát.
K posuzování distribuce: ano, volba adekvátních a odpovídajících nástrojů je pro mne jedním z kritérií při volbě distribuce. Například jmenovaný Slackware, který byl dlouho mou nejoblíbenější distribucí, jsem po téměř deseti letech opustil právě proto, že, s trochou nadsázky, tradici kompatibilitu s BSD klade výš než vývoj a kompatibilitu s Linuxem. Nebylo to jen proto, že nepoužívá a defaultně neinstaluje iproute2 nástroje, ale svým dílem to k mému rozhodnutí přispělo.
ifconfig
neukáže všechny adresy, byla jen ukázka, která měla demonstrovat, že ifconfig
pracuje s neexistujícími objekty, tedy jen jakási špička ledovce.
ifconfig
měl tajit, pouze že by začátečníkům neměl být předkládán jako základní (nebo dokonce jediná) možnost.
Pamatuji si to velmi dobře. Nebyl jste sepsut za udržování systému aktuálního. Byl jste pouze upozorněn, že zdaleka ne každý potřebuje každou novinku instalovat pár týdnů poté, co se objeví. Jenže ifconfig
už je obsolete odhadem šest let. Dost na to, aby se začátečníci učili tu "novější" variantu.
Dva a půl roku ho používá v init skriptech, ještě déle ho standardně instaluje.A smím vědět, jaká to je ? Protože je to nejspíš chvályhodná výjimka, co potvrzuje pravidlo. Osobně používám iproute nejmíň dva roky a vždycky mě vytočí, když někde něco potřebuju udělat a ten program tam není. A to se týkalo a týká bohužel stále většiny strojů ke kterým jsem za tu dobu sedl.
Netvrdil jsem, že by se ifconfig
měl tajit, pouze že by začátečníkům neměl být předkládán jako základní (nebo dokonce jediná) možnost.
Tvrdil jste, že by se začátečníci vůbec ifconfig neměli učit. To si koneckonců nahoře každý může přečíst.
Pamatuji si to velmi dobře. Nebyl jste sepsut za udržování systému aktuálního. Byl jste pouze upozorněn, že zdaleka ne každý potřebuje každou novinku instalovat pár týdnů poté, co se objeví.A to, že má někdo možnost nainstalovat si korektním způsobem balík pár dní po tom, co byl prohlášen za stabilní, jako někoho omezuje ? Dyť si to instalovat nemusíte, když nechcete, je to Vaše volba. Jako silně omezující je naopak to, že si nemůžu korektním způsobem nainstalovat co chci a musím kvůli tomu tahat něco odněkud z webu nebo dokonce cvs a kompilovat a udržovat to ručně.
Jenže ifconfig
už je obsolete odhadem šest let.
Jak může bejt 6 let obsolete něco, co ještě před nějakým rokem většina hlavních distribucí vůbec nepoužívala ?
Smíte, je to SuSE. V init skriptech používá příkaz ip
od verze 8.0, tedy od jara 2002. V defaultní instalaci byl už ale dříve, určitě v 7.3, starší neznám (7.3 byla má první). Ale nemyslím si, že by byla jediná. Těším se na ten poprask, až staromilci zjistí, že konfigurační soubory v /etc/sysconfig/network
se v novějších verzích nepojmenovávají podle rozhraní, ale používají persistentní jména...
Tvrdil jste, že by se začátečníci vůbec ifconfig neměli učit. To si koneckonců nahoře každý může přečíst.
Ano, že na dotaz, jak nastavit síť, nemá dostat odpověď, že pomocí ifconfig
. Na tom také trvám. Ale to neznamená, že jim ho tajím. Na školeních se také zmiňuji o tom, že se leckde mohou setkat s příkazem ifconfig
, ale že se jedná o zastaralý příkaz, a stručně jim vysvětlím, proč není vhodné ho používat. Stejně tak, jako se při výkladu paketového filtru zmiňuji ipchains
, ale budu protestovat, pokud by někdo začátečníkům doporučoval jeho používání v jádrech řady 2.4 nebo 2.6.
Jak může bejt 6 let obsolete něco, co ještě před nějakým rokem většina hlavních distribucí vůbec nepoužívala?
Tady vám poněkud nerozumíte. Jestli myslíte ip
, tak ten obsolete není. Jestli myslíte ifconfig
, tak ten se používal poměrně dlouho, dnes ho naštěstí mnohé distribuce už nepoužívají. Rozhodně bych neřekl, že ho před rokem většina distribucí ještě nepoužívala...
Pokud by ale vaše otázka zněla jak může být šest let obsolete něco, co ještě nedávno používala většina distribucí, pak by má odpověď zněla, že to je špatně položená otázka. Spíš bych se zeptal takto: jak je možné, že ještě před dvěma lety většina distribucí používala ve svých skriptech konfigurační nástroje, které jsou od roku 1998* obsolete. Na to se ovšem musíte zeptat autorů. Stejně tak, jako proč ještě koncem devadesátých let se zcela běžně v distribucích defaultně spouštěly prakticky všechny služby, které byly nainstalovány. Stejně tak, jako proč se leckde dodnes používá jako šifrovací algoritmus (single) DES, který už je pár let považován za nedostatečný. Proč některé distribuce dodnes nepřijaly PAM a přidělávají tak svým uživatelům neskutečné problémy. Proč mnoho distribucí nastavuje SUID příznak spustitelným souborům, u nichž to obvykle vůbec není nutné. Proč někteří producenti reagují na bezpečnostní chyby se značným zpožděním. A tak by se dalo pokračovat. Je to prostě otázka volby, nejdřív jejich, co a jak použijí, potom vaše, abyste si zvolil distribuci, která taková chybná designová rozhodnutí nedělá (nebo jich aspoň dělá co nejméně).
* - nechce se mi hledat přesné datum vydání jádra 2.2.0.
iproute2
...
Reaguji na celý thread pod tímto příspěvkem.
Pánové, nenechávejte se prosím unášet emocemi. Chápu Vaši spontánní reakci. Sám jsem při rozhovoru s jedním člověkem, zabývajícím se výzkumem sítí (jeho odborných znalostí si vážím) dostal na svou poznámku ve smyslu:
„Linux od verze 2.2 má nový síťový subsystém a primárním konfiguračním nástrojem je ip.“
reakci:
„Fakt? Doufám, že se to neprosadí.“
Ne vždy je první reakce, co Vás napadne, hodna písemného publikování. Obzvlášť na tomto serveru. Zkuste prosím nejprve přemýšlet, zda argumentace protistrany nedává smysl.
K tomu výběru distribuce -- příklad, kdy zahrnutí ip má vliv na volbu: Potřebuji distribuci na router, který bude dělat policy routing a používat IP tunely. Najdu kandidáta, který má (může mít) nástroje na vše potřebné a odpovím si na otázky:
PS. Též dělám linuxová školení a konfiguraci sítě předvádím s ifconfig, route, arp. Právě z důvodu kompatibility znalostí zákazníků se světem publikované dokumentace. Ale musím říci, že s ip by se vše vysvětlovalo mnohem lépe -- obzvášť ifconfig je dost nekoncepční.
Shrnutí: Je to začarovaný kruh a výroky typu „Běžte s iproute2 do ...“ nikomu nepomohou. BTW iproute2 používáte, i když nepoužíváte ip a uvedený výrok vlastně znamená „Běžte se síťovým systémem Linuxu do ...“ Nepřilévejme olej do ohně.
route
nevystačil. Ale nakonec jsem se rozhodl pro ip
i u relativně základního školení. Za prvé kvůli konzistenci, nechtěl jsem v jednom kursu něco učit a v dalším vysvětlovat, proč je to špatně. Za druhé právě proto, abych do určité míry suploval tu ne příliš rozšířenou dokumentaci.
ip
a pak teprve (a ne nezbytně) odpověď pomocí ifconfig
a spol. - ale s upozorněním, že to je zastaralý způsob s mnoha nevýhodami, který existuje pouze pro zpětnou kompatibilitu.
http://www.lartc.org/howto/
nebo http://developer.osdl.org/dev/iproute2/
Jsou to ale dokumenty spíš pro ty, kdo už o problematice něco vědí. Takže nejprve asi něco jako Linux Networking HOWTO, případně Network Administration Guide.
S tím Slackwarem se to má tak, že, jak jsem právě zjistil, verzi 10.0 jsem nainstalovanou neměl. V době, kdy vyšel, jsem totiž nutně (a celkem rychle) potřeboval pro jeden účel distribuci (nativně) s jádrem 2.6 a Slackware 10.0 tím vypadl ze hry. Potom už jsem se nedostal k tomu, abych si ho stáhl a vyzkoušel. Takže když jsem psal o Slackware, vycházel jsem z předchozí verze 9.1.
ip link show
' resp. 'ip addr show
', případně na hlášky jádra při startu.
Tiskni Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.