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. ---------------------------------------------------------------- John Karns [EMAIL PROTECTED] ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _____________________________________________________________________ Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: https://lists.sourceforge.net/lists/listinfo/ltsp-discuss For additional LTSP help, try #ltsp channel on irc.freenode.net
