Vetsina v clanku uvadenych prikladu me pripada dost nerozumna a nasazovani upstartu kvuli nim mi prijde jako reseni nasledku misto priciny. Napr. proc bych mel startovat sitove sluzby az pote, co dostanu od DHCP adresu? Sitova sluzba by se mela vyporadat s objevovanim novych interfacu a zmenami adres, tudiz by melo byt korektni ji startovat klidne pred DHCPckem. Podobne hudebni demon by mel pocitat s objevovanim novych interfacu.
Nevim, jak presne je upstart resen. Vetsina podobnych systemu zalozenych na pouziti callbacku psanych v shellovych skriptech jsou desne nachylna na race conditions - maloktery administrator ty skripty napise tak, aby byly race condition free. Asi by to chtelo uplne nova synchronizacni primitiva do shellovych skriptu a bezpecne implicitni chovani.
"Sitova sluzba by se mela vyporadat s objevovanim novych interfacu a zmenami adres..."
No, co jsem zjistil, tak tusim bind nebo NTP se nahodi na dalsich adresach, ktere zjisti, ale problem muze byt treba v pripade, ze chci danou sluzbu nahazovat pouze na urcitem IPcku, takze kdyz se budu odkazovat na takove IPcko v konfiguraku, ale iface jeste nebude nahozeny, tak mi muze sluzba chcipnout z duvodu, ze se nebuze nabindovat na zadanou IP adresu. A nemyslim si, ze by bylo dobry, aby ta sluzba jen tak nabehla a pak nic nedelala. Takze u nekterych sluzeb je nutne, aby cekaly na jine sluzby.
Jasne, takove problemy jsou, ale jejich 'reseni' pomoci upstart je spis jen zazene do temnejsich koutu. Co kdyz takova sluzba bude nastavena, aby poslouchala na dvou ruznych IP adresach, pustis ji az po nakonfigurovani techto adres, ale pak shodis a nahodis jeden z tech interfacu. Ma byt treba takovou sluzbu pak restartovat (coz by zbytecne rozbilo komunikaci na druhem interface)? Nebo je spravne, aby se sluzba s tim vyporadala sama?
problem je s tim, ze pokud nechci aplikaci na adrese 0.0.0.0/0 tak je vetsinou dost zkostnatela na to, aby se vyporadala s nepritomnosti potrebne adresy. proste nebindne, tak chcipne.
Tak zrovna bind se takto nechova. Sice se u IPv6 binduje na ::/0, ale pro IPv4 se binduje na jednotliva rozhrani. Nakonec jsem musel na pppd navesit posilani SIGHUP.
Dalsim rostakem je racoon, ktery se zasadne binduje na IP adresy a jeste se tim chlubi.
"Tak zrovna bind se takto nechova. ... ale pro IPv4 se binduje na jednotliva rozhrani."
To je pravda, ale mam dojem, ze kdyz jsem nahodil alias s novym IPckem, tak se hned bind nahodil i na tohle novy IPcko, za coz ho chvalim, protoze tak by se mel spravnej server chovat. Ale nejsem si ted jistej, jestli to byl bind nebo ntpd, ale jeden z tech dvou me urcite takhle mile prekvapil.
Co je mi platna IP adresa, kdyz mi za behu vznikaji a zanikaji rozhrani :)
Ostatne chtelo by to vice odvahy. Linux standardne prijima pakety pro mistni IP adresy at prijdou kterymkoliv rozhranim. Pri dynamickem routovani se skutecna verejna adresa vetsinou strka na dummy rozhrani, aby prezila vsechno. Paket pro host scope adresu se take dorucuje pres loopback. Smerovaci tabulky se take nezajimaji kudy paket prisel a jakou ma zdrojovou adresu.
Je na case zrusit koncept pridelovani global/site scope adres rozhranim. Takova adresa je adresa stroje a tecka. Ovsem uplne prvni a ne zrovna snadny ukol bude vyhodit ifconfig z Debianu :)
