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
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.
Then I would need to add the inetd.conf file,
and standard security might add hosts.allow, hosts.deny, ...
Evidently, if I installed the local_apps LTSP package,
then the current /etc/rc.local would start the following two needed daemons,
portmap
xinetd
I may have missed some needed software to carry out this "rdate"
approach.
So, this "rdate" approach to setting date requires adding more software than
is reasonable.
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.
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 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.
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.
On Thu, Feb 06, 2003 at 07:28:58PM -0500, Jason Straw wrote:
> I would actually suggest running ntpd on it, yes, it seems excessive for
> an ltsp client (but remember how much is actually running on a client)
> And it does a much better job at getting the time set correctly. Not to
> mention that rdate doesn't know if the time it is getting from the
> server is accurate, ntp is accurate usually to .001s. Finally, the big
> difference is that ntp when setup correctly, will check against many
> servers, whereas rdate can only do one
>
> there are devices that require that kind of accuracy, although LTS isn't
> one of them.
>
> Also, tomorrow night (Friday 7 February 2003 at 7pm at Yorktown High
> School in Arlington, there is a LUG that is meeting, they have a running
> LTS Lab and a bunch of guys that could answer your questions in person.
>
>
> On Thu, 2003-02-06 at 11:17, Jameson C. Burt wrote:
> > I use the LTSP webcam package, ltspwebcam,
> > which displays a picture having a machine date, because of a setting in
> > /opt/ltsp/i386/usr/local/share/camserv.cfg
> > This displayed date can be useful since webcams apparently
> > retain a few images sometimes hours old.
> > SO, WHAT APPROACH WOULD YOU TAKE TO SETTING DATE?
> >
> > Here are some approaches I consider.
> > 1. rdate
> > I lean towards this approach, which would run on bootup of the LTS,
> > rdate my-main-computer
> > Presuming I use this approach, would I then best add
> > /opt/ltsp/i386/sbin/rdate #a 5 kilobyte file
> > and append to
> > /opt/ltsp/i386/etc/rc.local
> > the line
> > /sbin/rdate my-main-computer
> >
> > 2. ntp (Network Time Server); in particular, ntpdate.
> > I decided not to use this since, for a LTS,
> > it's excessive in software installation,
> > and either external networking must be up, or my main computer must
> > run an ntpd daemon.
> >
> > 3. ??? What haven't I thought of?
> >
> > 4. This is a crazy idea that merely makes things more complex.
> >
> >
> > The Jammin 125 I got 4 weeks ago has a date differing by two hours
> > (I'm EST, and it must be MST).
> > I could probably add
> > /opt/ltsp/i386/sbin/hwclock
> > then permanently change my LTS hardware clock.
> > But this approach isn't as robust as an approach like "rdate",
> > which (hopefully) properly changes date even when the LTS clock
> > runs low, and once setup,
> > this approach needn't be applied by hand to each LTS.
> >
> >
> > I welcome any suggestions.
--
Jameson C. Burt, NJ9L Fairfax, Virginia, USA
[EMAIL PROTECTED] http://www.coost.com
(202) 690-0380 (work)
msg11815/pgp00000.pgp
Description: PGP signature
