[BACK]Return to loncapatimesync.html CVS log [TXT] [DIR] Up to [LON-CAPA] / doc / build

Diff for /doc/build/Attic/loncapatimesync.html between versions 1.1 and 1.2

version 1.1, 2001/02/07 13:10:16 version 1.2, 2001/09/07 14:54:47
Line 24  the time of the server be kept accuratel Line 24  the time of the server be kept accuratel
 <P>  <P>
 Accuracy involves   Accuracy involves 
 </P>  </P>
 </BODY>  <pre>
 </HTML>  I will explain the components of ntp and how they
   interrelate on a LON-CAPA system
   
   There are three relevant components here:
   1. a correct /etc/ntp/step-tickers,
   2. a correct /etc/ntp.conf
   3. enabling xntpd for boot up
   
   Without /etc/ntp.conf, /etc/rc.d/init.d/xntpd won't do anything.
   With /etc/ntp.conf but without /etc/ntp/step-tickers, Gerd is correct
   when he says:
   
   > What I do know is that if the clock in the CMOS is off by too much,the normal
   > ntp will not work. Instead, the clock has to be forced to synch initially,and
   > from then on can be automatically adjusted.
   
   The unix commands for Gerd's manual approach are:
   /etc/rc.d/init.d/xntpd stop
   /usr/sbin/ntpdate ntp.msu.edu (or whatever your ntp server is)
   /etc/rc.d/init.d/xntpd start
   
   To force xntpd to avoid the offset problem, defining
   /etc/ntp/step-tickers does the trick.
   
   With /etc/ntp.conf and /etc/ntp/step-tickers, xntp still may not
   work (depending on whether the last instruction was followed
   for the LON-CAPA installation, see
   http://install.lon-capa.org/docs/3.1/instructions_with_cd.html)
   
   Making sure xntp starts up upon boot time should simply
   be a matter of:
   
   /sbin/chkconfig xntpd on
   
   Finally, the correct settings for /etc/ntp.conf
   and /etc/ntp/step-tickers are:
   
   1 line with the ip address of your ntp server
   
   For instance:
   
   echo "whistler.sfu.ca" > /etc/ntp/step-tickers
   echo "whistler.sfu.ca" > /etc/ntp.conf
   
   Everyone is currently setting these and other LON-CAPA conf
   files manually after cvs upgrades, because
   there were several parties who were
   
   * doing different things
   * in different ways
   * for different reasons
   * for different institutions
   * for their machine-specific configurations
   
   I was not able to make everyone happy with
   "make configinstall".  For the future, we (Guy and I) do think
   we've come up with a new way to do everything
   for everyone for updating configuration files
   as the CVS source repository changes.
   
   -Scott
   </pre>
   </body>
   </html>
Removed from v.1.1  
changed lines
  Added in v.1.2

FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>