Curiously, since I already run ntpd on my main computer
("server" serving DHCP and NFS to my LTS machine,
and that "server" accomodates time according to 3 internet ntp-computers),
the "ntpdate" solution works well, but the seemingly simpler
"rdate" approach would probably require installing many more files
on my LTSP machine.
With "ntpd" already running on my server, here are the changes I made to
my LTSP machine.
I added
/opt/ltsp/i386/usr/sbin/ntpdate
/opt/ltsp/i386/lib/libreadline.so.4 #a link
/opt/ltsp/i386/lib/libreadline.so.4.2
And I added the following line to /opt/ltsp/i386/etc/rc.webcam,
/usr/sbin/ntpdate `grep server /etc/hosts |sed 's/ .*//'`
On my LTS machine, this just runs
ntpdate 192.168.1.1
Because a basic LTS keeps no "localtime" ("zoneinfo" like "US/Eastern"),
the above will probably set your time to Greenwich Mean Time (UTC).
Because basic LTSP cannot access DNS to get IP addresses,
we must set any IP addresses directly, including "server"
[curiously, ntpdate seems to ignore /etc/hosts, going directly to DNS
servers].
I just tried ntpdate with several internet time servers,
without adding more files accomodating DNS for LTSP
and without using ntpd on my "server".
I tried using the following actual IP addresses
in the second line below,
ntpdate chrivh40.cch.com ntp-0.cso.uiuc.edu ntp-1.mcs.anl.gov
ntpdate 198.147.37.140 130.126.24.53 216.204.156.2 140.221.9.20
This works!
One small glitch would be that IP addresses aren't as stable as
domainnames, so rather than using the suggested 3 domainnames,
you might use 5 IP addresses.
You can find ntp domainames (and so too their IP addresses) for over 100
ntp servers worldwide at
http://www.eecis.udel.edu/~mills/ntp/clock2a.html
I am satisfied with the ntpdate approach since I only want my LTS
machine with a time similar to its server.
Unfortunately, ntpdate probably doesn't satisfy a requirement
of "minimal" change to the main computer,
since it requires that computer run "ntpd",
but it does satisfy "minimal" if you're willing to enter several
IP addresses from ntp servers listed at
http://www.eecis.udel.edu/~mills/ntp/clock2a.html
I thank John Karns for his extensive comments
and Jason Straw for pushing the ntp approach.
By the way:
What's up with his Yorktown High School?
They had IBM speak there about mainframe Linux in 1999,
before IBM started marketing mainframe Linux,
Vinton Cerf was going to talk there last Friday,
and they have a room full of LTSP machines.
Is this high school a harbinger for the most viable computing solutions?
On Fri, Feb 07, 2003 at 09:17:29PM -0500, John Karns wrote:
> On Fri, 7 Feb 2003, Jameson C. Burt said:
>
> > Here are some approaches to change date that I minimally tried,
> > including approaches that would require excessive changes
> > and the not-satisfying approach I took.
> >
> > 1. rdate.
> > I copied the "rdate" binary somewhere in /opt/ltsp/i386 to test it.
> > I tried
> > rdate server
> > rdate time.nist.gov
> > rdate 192.43.244.18 #IP address of time.nist.gov
> > These "rdate" executions responded,
> > rdate: Name or service not known
>
> It should be rdate <yourLTServer>. I think that's what you're meaning by
> the 1st entry above. If you want to access the Internet time servers such
> as time.nist.gov, then you would not use rdate, but rather "ntpdate -u
> time.nist.gov".
>
>
> > From my main computer's Debian Linux /etc/inetd.conf,
> > I see that the "time" used by "rdate" is a service built-into the
> > "inetd" daemon.
> > But LTSP runs no "inetd" daemon, so this daemon would have to be added.
>
> LTSP would not be running the daemon, but rather Debian. I don't see that
> the client would need to run a daemon for this.
>
>
> > Then I would need to add the inetd.conf file,
> > and standard security might add hosts.allow, hosts.deny, ...
>
> Correct, except that the /etc/inetd.conf should already exist, and it
> should be a matter of simply uncommenting / enabling the time service,
> something like:
>
> time stream tcp nowait root internal
> time dgram udp wait root internal
>
> Since I have yet to set up a Debian installation, I don't know whether
> they are using inetd or xinetd (RH uses the latter). Sorry, I'm not
> familiar with xinetd, so I can't give any advise with that.
>
>
> > Evidently, if I installed the local_apps LTSP package,
> > then the current /etc/rc.local would start the following two needed
> > daemons,
> > portmap
> > xinetd
>
> You shouldn't need to add the local_apps pkg for that reason. You can
> just edit xinetd yourself to respond to the time service call. portmap
> should already be set up (on the server), as it is a core part of LTSP.
> You don't need it to run on the client to run rdate.
>
>
> > I may have missed some needed software to carry out this "rdate"
> > approach.
>
> I believe that you would need to have local_apps for the capability of
> running rdate (or any other date / time setting utility) on the client.
>
> This is the approach I would take = i.e., run a script to call rdate to
> set the time on the client. Then if your Debian server is Internet
> connected, use ntpdate to set the servers time. That shouldn't be
> necessary to do more than about once a week for the average installation
> where to-the-second time is not mandatory on the server.
>
>
> > So, this "rdate" approach to setting date requires adding more
> > software than is reasonable.
>
> I would say that it's the nature if te beast.
>
>
> > Only the hardheaded would continue on this route.
>
> > 2. ntpd or ntpdate.
> > These both require installing the library
> > libreadline
> > For LTSP, I feel the ntp is excessive.
>
> I would agree, insofar as ntpd at least. OTOH, ntpdate I would not
> consider to be excessive, given that the server has Internet access.
>
>
> > It requires internet networking (though most people have this in some
> > form), not just networking to the main computer (server).
> > Alternatively, I could run ntpd on the server,
> > but I seek a minimalist approach (which I seek to avoid future
> > installation extras at other locations or with other LTSP machines).
> >
> > However, I am fond of ntp for disk/interneted computers,
> > first deciding in 1995 that such a thing had to exist,
> > so I searched a likely place, the Naval Observatory,
> > which fulfills all "time" dreams.
> >
> > 3. A date remnant from the main computer (server).
> > I searched for any date left by the main computer
> > when the LTSP boots,
> > but I found no such date.
> > I could have the main computer (server) "touch" a file in
> > /opt/ltsp/i386
> > then pick up its date for the LTSP machine.
> > But this involves further configuring the main computer (server),
> > which violates any minimalist approach.
> > I am willing to violate a minimalist approach
> > if the LTSP incorporates them,
> > but I don't want to create and maintain my own scheme.
>
> I would consider that approach to be a last resort.
>
>
> > I did make the following change, which is un-satisfying.
> > It somewhat solves the date problem until Congress mandates its
> > next time-change, which it does twice a year,
> > or until the battery runs down (which may LTSP machines had happen long
> > ago).
> > LTSP does not natively include any local-time or timezone information.
> > I changed my LTSP machine's hardware date as follows
> > a. date 2003.02.06-23:02:30 #nonstandard "date" binary in LTSP
> > This changes the Linux OS current date.
> > b. hwclock --systohc
> > This uses the above set Linux OS date to change the hardware date.
> > I first copied this "hwclock" binary from my main computer
> > to somewhere in /opt/ltsp/i386 so I could execute it.
>
> Part b. you will need in any case (if you want to adjust the hardware
> clock - this you would do via a script which would take care of the whole
> process), as both rdate and ntpdate set the Linux system clock, not the
> hardware clock, AFAIK. It would not be strictly necessary if you're going
> to make the call to rdate on every login of the terminal(s), though.
>
>
> > I still welcome a better approach, an approach that doesn't require
> > excessive changes on the main computer (server) and the LTSP machine,
> > or an approach condoned by the main LTSP writers.
>
> I'd say that you're basicly on the right track, and that you just need to
> tend to a few more details.
--
Jameson C. Burt, NJ9L Fairfax, Virginia, USA
[EMAIL PROTECTED] http://www.coost.com
(202) 690-0380 (work)
msg11860/pgp00000.pgp
Description: PGP signature
