network hiányában a bootfolyamat megáll ntpd-nél

Debian GNU/Linux

A fenti problémára kéne egy megoldás egy vegyes használatú (van net, nincs net) rendszer esetében. Előre is köszönöm a tippeket.

  • 1306 megtekintés

( igiboy | 2010. 02. 09., k – 13:38 )

Biztos nem megy tovább percek mulva sem? Bootolás közben hol akad el? Esetleg nem DHCP címkérést akar, csak egy kicsit magas a timeout?

( Tyra3l | 2010. 02. 09., k – 13:39 )

ntpd inditasat atrakni network inditas utanra, vagy ilyesmi?

Tyrael

( zitev v | 2010. 02. 09., k – 13:51 )

pár infó: fix ip-kiosztás van, a gép nem minden esetben kerül hálózatra, tehát valahogy az ntp szerver timeoutját kéne kisebbre venni, de eddig nem találtam erre megoldást.
tehát magyarán minden jó, kivéve amikor a gép nem kerül hálózatra és úgy akarják használni. viszont az ntp-t nem dobnám ki emiatt..

Elvileg 5000ms a timeout. /etc/inid.d/ntpd, vagy épp ami neve a scriptnek, ott paraméterezheted is. Esetleg ntpd frissítése, mert ha "ntpd timeout"-ra keresel akkor láthatod hogy nem csak neked van/volt ilyen problémád. Végső esetben a scriptbe belehekkelni valamit hogy csak akkor ntpd-zzen ha van hálózat.

úgy tudom, hogy az ntp az adott hardveróra ingadozásaiból átlagolva korrigálja azt az időszerverhez viszonyítva. így lehetőleg nem lőném le, ha nincs háló akkor sem.
az ntp.conf-ban nincs ilyen opció, a /etc/init.d/ntp -ben sincs, szóval még keresem az okát. biztos hogy más is szív vele, de a megoldást így konkrétan leírva még nem találtam meg, ezért kérdezem itt.

man ntpdate 

-t timeout
             Specify the maximum time waiting for a server response as the
             value timeout, in seconds and fraction.  The value is rounded to
             a multiple of 0.2 seconds.  The default is 1 second, a value
             suitable for polling across a LAN.

man ntpd 


the Configuration File

Ordinarily, ntpd reads the ntp.conf configuration file at startup...
....
Usually, the configuration file is installed in the /etc directory....

Az ntp valóban a harverórához szinkronizál - csak éppen nem egy mezei cmos vekkerről beszélünk, hanem monjuk atomóráról. Ilyen meg nincs minden gépre akasztva, tehát ahhoz, hogy szinkronizálni tudjon hozzá a masina, hálózat is kell. (NTP = Network Time Protocl) Ha viszont nincs hálózat, akkor az ntp semmit nem ér. Szóval ha háló nélkül bootol a gép, akkor teljesen fölösleges elindítani az ntp-t.

Ha frissítés után is fennmarad a probléma, és timeout van boot-kor, akkor kb 5 másodperc újra belerakni azt a bizonyos & jelet.

Tisztább megoldás, mint pl. az , amit valaki más javasolt - belehekkelni a scriptbe, hogy lekezelje a hálózat hiányát.

Egyébként tapasztalatom szerint init scripteket frissítések nagyon ritkán módosítanak csak.

Alapvetésként tartom magam ahhoz, hogy initscriptet, pláne ha nem én követtem el, nem matatok.

Már az is jobb, ha kiveszi a megfelelő runlevelből, és rc.local-ból indítja egy szép egészséges if pingik a timeserver, then start ntpd. Bár ennek meg van egy olyan mellékhatása, hogy nagyobbacska időeltérés esetén ha visszarángatja a valós időbe a gépet, azt néhány cucc nehezen viseli el... (valamelyik imap/pop3 szerver dőlt ilyesmitől a kardjába...).

Az rc-scripteket lehetőleg nem matatja az ember, lehet paraméterezni, lehet tologatni, hogy mi előtt/után induljon, vannak futási szintek, amiket pont arra találtak ki, hogy különböző beállításokkal lehessen indulni. Defaultnak belökni a wan-interfész nélkülit, egyel fölé meg a wan interfész felhúzását, meg utána a kapcsolódó szolgáltatások indítását végző scripteket is linkelni, aztán kész.
Az, hogy a wan interfész adott runlevelen feljöjjön/ne jöjjön, azt meg pre-up -ban szépen egy who -r vagy runlevel kimenetének a megvizsgálásával lehet megoldani szerintem... (Ha a pre-up sikertelen, az interfészt nem húzza fel)

De nem is kell plusz futási szint akár: wan interfész nem auto, post-up -ba egy "/etc/init.d/ntpd start", aztán amikor kézzel elindítja az interfészt (és az feljön), akkor indul az ntpd. (Leállítás értelemszerűen).

"Alapvetésként tartom magam ahhoz, hogy initscriptet, pláne ha nem én követtem el, nem matatok"

Nincs azzal gond, ha normálisan dokumentálva van a változtatás.

"nagyobbacska időeltérés esetén ha visszarángatja a valós időbe"
ntpd (az ntpdate-el ellentétben) kis lépésekben módosít, pont az ilyesmi elkerülésére

Egyébként meg a post-up megoldás amit írsz eddig a legjobb.

Valaki az ntpdate-et emlegette, arról jutott eszembe az idő rángatása és annak következményei.
A post-up az picit Linux-specifikus, ha jól rémlik, a futási szintek lettek anno erre kitalálva Eredetileg a 2 az a "multiuser, hálózat nélkül" vala, de majd Zahy kijavít, ha nem :-))

Ha csak az ntpd a gondod, akkor az interfaces-ben a wan-láb post-up a te barátod. Ha más is, akkor lehet gányolni, de a szép megoldás az szerintem, hogy 2. futási szinten nem indítod el azokat a kacatokat, amik wan-kapcslatta vágynak, csak a 3-on, ahol a wan interfész is felhúzásra kerül.

( muszi v | 2010. 02. 09., k – 16:10 )

Ezt ugy szoktam megoldani, hogy az 

/etc/rc?.d

mintajara van egy 

/etc/rc-wan.d

, abba teszem azokat az inditoszkripteket, amiknek szukseguk van a netre (nalam ez az 

ntpdate

, 

ntp

es az 

openvpn

). A WAN interfeszt egy kulon inditoszkript huzza fel a hatterben (a 

networking

utan indul), az 

/etc/rc-wan.d

-ban levo szkripteket pedig az ifup inditja, miutan sikerult kapcsolodni (

up

parameter az 

/etc/network/interfaces

-ben). Igy a helyi szolgaltatasok el tudnak indulni (pl. dhcpd, dnsmasq), nem kell megvarni a WAN interfeszt.

mert sokkal jobbnak tartom a beállítási módszerét (nem csak bizonyos időnként szinkronizál, hanem folyamatosan korrigál, hálózat hiányában is). a felhasználási köre szvsz nem feladatfüggő, de ez spec egy olyan gépen lesz, aminél nagyban számít a belső óra pontossága.