Ahavi je paráda, konečně konkurence winbindu, a statickému mapování IP adres.
Až na jednu drobnost - s tou pseudodoménou ".local" nefunguje například mountování samba disků. Čili, je to pr mě momentálně nepoužitelné :(
jsem stále odkázaný na winbind.
Detaily a prosba o zodpovězení mého dotazu zde:
http://serverfault.com/questions/356378/configure-avahi-nss-mdns-not-to-use-local-suffix-with-hostnames-because-of-issue
NetworkManager(i) velmi radi mazu resolv.conf a vytvaraju vlasny... Takze az take jednoduche to nie je.
Mna to tak stavlo, ze som si opatchoval mdns nss kniznicu (ku kazdemu dotazu bez domeny ".local" tam proste ".local" prida a az tak hlada)
OMG, NetworkManager sice maže resolv.conf, ale přepisuje ho hodnotami ze své konfigurace – takže si ty domény k prohledávání naklikáš v něm (nebo upravíš soubory v /etc/NetworkManager/…).
NetworkManager má nastavení, kde se to nejspíš dá přidat (ale to jsem nezkoušel). Nebo můžete nainstalovat resolvconf, NetworkManager potom používá jej, a do /etc/resolvconf/resolv.conf.d/base přidat „search local“.
Urcite lze ridit NetworkManager pridanim skriptu do /etc/NetworkManager/dispatcher.d. Skript dostane dva argumenty - interface a co se s nim deje (up, down).
Ja napriklad prepisuji nameserver na 127.0.0.1, aby se pouzival lokalni unbound.
V unboundu lze pak taky pridat statickou zonu "local" (viz local-zone v https://unbound.net/documentation/unbound.conf.html)
To nefunguje! libnss mdns knizica ignoruje "search local" v /etc/resolv.conf
Vid http://0pointer.de/lennart/projects/nss-mdns/
Ano, obsah resolv.conf se přepisuje.
Říká se to hned v hlavičce:
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
Dál tam mám jen:
nameserver 192.168.1.1
A toť vše.
Do elaborování s /etc/resolvconf/resolv.conf.d/... se pouštět nebudu. Stejně to nefunguje. Viz příspěvky níže. Bohužel.
Bohužel, musím potvrdit, že tohle NEfunguje.
Přidání "search local" do resolf.conf nepomohlo.
Více například zde:
http://serverfault.com/questions/356351/adding-search-to-resolv-conf-prevents-fqdn-searches
Shrnutí:
Zeroconf != DNS
P.S.
Bohužel, jak mě Avahi nadchlo, tak mě i zklamalo. Musím nadále zůstat u Winbindu :(
Smutné je, že jediný systém který si dynamicky a decentralizovaně poradí s hostnames na lokální síti je jednak od Microsoftu, a jednak je deprecated.
Hmm, na serverech jsem měl tendenci se téhle vymoženosti zbavovat. Po odinstalaci avahi pak bylo tuším nutné se zbavit mdns* věcí v nsswitch.conf jinak byly problémy s resolvováním.
Nějak tomu zatím nemohu přijít na chuť (zdá se mi, že to příliš fušuje do oblastí DNS a trochu i DHCP) - pravda taje avahi jsem ještě moc neodkrýval. Spíše preferuji síťovému zařízení (které se hodlá v síti občas vyskytovat) přidělit dle MAC konkrétní IP a také mu dát konkrétní jméno v DNS. Ovšem pro případná spojení AD-HOC to smysl asi má. Také CUPS tuším tvrdí, že avahi je bezva.
Kde se berou jména síťových zařízení? To podle toho jaké jméno tvrdí zařízení (dle hostname), že má? A jak se vyrovná tento systém s duplicitními jmény?
Potiz je, ze kdyz na dnesnim distru odinstalujete Avahi, tak vam na disku zbyde asi tak jadro a tri utilitky, ktere na Avahi jeste nezavisi.
U Debian squeeze vypadá, že takový problém se závislostmi není.
Naprostá většina těch závislostí na avahi-daemon je jenom „Recommends“, opravdové závislosti jsou jenom na libavahi, a to jenom u CUPS, GNOME a SANE, ani jedno na serveru asi instalovat nebudete.
CUPS, GNOME (a i SANE) na server, který například slouží (nejen) pro grafický terminálový přístup je naopak hodně vhodný... Nicméně avahi-daemon asi přítomen být opravdu nemusí.
avahi a network manager - prvni veci co sly pryc po instalaci :D
avahi a network manager - prvni veci co sly pryc po instalaci
Tak jsem si říkal - dlouho jsem žádný článek od příšerného autora jménem Štrauch nečetl, tak uvidíme, zda se za tu dlouhou dobu něco změnilo - zda je schopen vyjadřovat se na vyšší úrovni než cikán z třetí třídy pomocné školy, zda je schopen psát nějakou pořádnou recenzi a ne jen "teď jsem potřeboval nějakou utilitu, tak jsem stáhl, použil a rovnou napsal článek", tedy něco, co by se hodilo na blog než kamkoliv jinam.
No, dočetl jsem k první větě druhého odstavce a je mi celkem jasné, že se nezměnilo vůbec nic. Redakci nedošlo, že by autor měl umět aspoň trochu česky, autorovi nedošlo, že jazyk je jeho pracovním nástrojem a měl by ho ovládat a ani nechápou, že zajímavý článek se prostě dělá jinak. Jediný pokrok registruji v tom, že p. Štrauch zaregistroval existenci jiných distribucí než té, kterou právě používá.
Ale naprosto mi uniká koncepce Rootu, protože mít na jednom server články z úplně opačných konců kvality, to smysl nedává. A rozdíl mezi články p. Štraucha a např. p. Tišnovského je tak markantní, že v matematice bych ho označil skoro za nekonečno.
Vidíte, našel jste u Adama Štraucha pokrok. Možná potřebujete ještě nějaký čas a naleznete další pokrok.
Za sebe říkám, že si rád na Root přečtu něco dalšího o avahi a nebude mi vadit, když to bude od Adama. Avahi je věc, která se nám nějak v Linuxu uhnízdila a já zatím vidím v ní spíše různá negativa - pravda je však taková, že zatím vlastně moc o ní nevím...
Mně teda avahi šetří spoustu času a starostí. Servery se při testování na lokální síti najdou samy podle jména. Desktopy mají jména, což se hodí při kopírování souborů. U tiskárny nezadávám IP adresu, počítače ji najdou samy.
A když je nejhůř, tak aspoň přes avahi-browse vypíšu, co na té síti je.
Běžte dělat do restaurace číšníka až host řekne, že polévka je přesolená, můžete mu říct "uvař lepší". Aneb nemusím být pekařem, abych poznal připálenou housku.
Jiste. Ale ten host napriklad asi nebude tomu cisnikovi rikat, ze cisnikuje jako cikan ze treti tridy pomocne skoly.
Autore. Link local adresy a bezestavova konfigurace existuji i na ipv4. Nemohu uverit tomu ze nekdo kdo pise takovy clanek to nevi. Jiz za mych pubertalnich let znamenalo ze jakmile se objevily na stanicich adresy 169.* tak chcipl dhcp server.
Blahe pameti cosi takoveho fungovalo uz na Windows 95 OSR2 (buzzword APIP) a mozna na to jeste nebyly RFC.
Zacal bych tady http://www.ietf.org/rfc/rfc3927.txt
To ze na to nebylo RFC neznamena, ze to nebylo castecne v OS aplikovano davno predtim. Jak jsem jiz psal - APIP. A microsoft ten na naka RFC z vysoka kasle.
Staci trochu cist...mozna na to jeste nebyly rfc,APIP,Windows 95 OSR2. Clovece nectete to jako smsku od pritelkyne:)
Akorát nefungují moc dobře :). Třeba mizí při úspěšném kontaktu s DHCP serverem, nebo se objevují se zpožděním a ne hned při zapnutí interface. Je to takový chudý bratránek IPv6LL.
Po kontaktu s DHCP serverem mizi by design, protoze ten je vetsinou preferovan. Neobjevuji se ihned protoze musi nejdrive vyprset pokusy o kontakt dhcp serveru.
„Po kontaktu s DHCP serverem mizi by design“
Captain Obvious?
Možná to přecijen nebylo z mého předchozího příspěvku zřejmé,
ale ten příspěvek byl právě kritikou špatného designu.
„protoze ten je vetsinou preferovan.“
Kdo že je preferován?
„Neobjevuji se ihned protoze musi nejdrive vyprset pokusy o kontakt dhcp
serveru.“
Zajímavá teorie. Škoda že je dávno vyvrácená.
mi na siti ma UDP dokaze u routeru a switche rozblikat kontrolky do nepricetnosti, kdyz hleda system se kterym muze komunikovat. Po vypnuti Win7 se najednou komunikace utisi. Moc se mi nelibi, ze po startu pocitace se system snazi vsemozne komunikovat s cimkoliv po siti. Radeji mam konfiguraci a komunikaci pod dozorem. Vsechny podobne hracky muzou byt i v nepovolanych rukou nebezpecne.
Ahoj Adame,
teorie je krásná věc, ale realita je v případě IPv6LL následující:
* aplikace, například SSH, se pokouší resolvovat jméno *.local pomocí NSS
* libnss-mdns zavolá avahi démona
* avahi démon resolvuje správně jméno na adresu a identifikátor rozhraní
* na cestě od avahi démona přes libnss-mdns přes NSS, tedy glibc, doputuje
do aplikace, ale zřejmě už bez identifikátoru rozhraní
* aplikace se připojuje na IPv6LL adresu bez identifikátoru rozhraní
* připojení selže (Invalid argument)
Pokud někdo víte, kde a jak toto opravit, tak uvítám každou pomoc!
pravdepodobne tam mate bridge, opravite to tim ze nebudete pouzivate linkove adresy ale neco v rozsahu fd::/8, a az nekdy ziskate verejny prefix::/64 tak zjistite ze avahi je na ipv6 neopuzitelny, jelikos napraska i neautonomni adresy ( je mu jedno jestli na sebe uzivatele "vidi" nebo ne, hlavne, ze neco vyprodukuje )
Avahi získá informace, pokud druhá strana dostane jeho multicast. V tom případě by ale měly pakety na ten počítač dojít i unicastem, jinak máte něco na síti špatně nastavené.
Musím se rázně ohradit k jistému tvrzení z článku, konrtétně k této větě:
"Můžeme o Avahi prohlásit, že váš počítač ani síť nezatěžuje žádným způsobem, kterým byste to mohli reálně poznat. Z tohoto pohledu není důvod ho ani dávat pryč."
Na kolejní síti Větrník - Praha (více než 100 připojených strojů) způsobuje Avahi-daemon neúměrně velký RX provoz v řádu 200 KB/s = 703MB/hod. A to i v době, kdy se síť vůbec nepoužívá (síťové aplikace povypínané, žádná přimapovaná síťová jednotka, ... ). Nevím, zda se jedná o bug, nebo o vlastnost řešení, ale takováto režije je naprosto neúnosná. Po odinstalování zmíněné služby příval příchozích paketů ustal, takže v Debian based distru doporučuji následující kouzelnou formulku:
sudo apt-get remove avahi-daemon
(Xubuntu 11.10 64bit)