TWiki VM has wrong date
One new problem: date in my TWiki VM is wrong (Jan 30th with real date Feb 19th), and doing
hwclock --hctosys
doesn't fix this (copies the CMOS hardware clock time to system time)... Very odd, don't have time to debug, but interested if anyone else has seen this.
This VMware KB entry may help where it discusses slow clock.
I think part of the problem is suspending the VM for many days, but surely
hwclock
should resync to real time... One way to fix this might be to install VMware Tools (maybe too heavy) or just enable time synchronisation in Debian, which I think can sync off VMware provided time service in the host PC.
Not really a TWiki issue at all, but important to the increasingly popular
TWikiVMDebianStable (400+ downloads in a few days from one mirror...)
--
RichardDonkin - 19 Feb 2006
Discussion
Good point, Richard. I think the easiest way to solve this in most cases (where ntp network connectivity is allowed through the firewall) is to make sure the timezone configuration in the VM is correct and do a default install of
ntpdate
. (This won't do much good for the suspend issue though, that's a bugger).
Well, do the following:
- Run
tzconfig
(as root). If the default US/Eastern time zone is not correct, simply follow the instructions given and choose the nearest location.
- Install
ntpdate
by simply issuing the command: apt-get install ntpdate
.
That's it - the system clock is now (hopefully! :-)) synchronized with the public ntp servers from
http://www.ntp.org/ (you can test current time by simply running
date
). And further, everytime the machine is rebooted,
ntpdate
is now automatically run as part of the boot procedure.
If you're behind a firewall, typically there are ntp servers available at the internal network that can be used - your network admin will be able to point you to these. To update the installation with these local ntp servers, edit the file
/etc/default/ntpdate
.
This should be OK for most installations, simply synchronizing time at boot - but if you prefer to be 100% in sync at all times, you can consider installing a ntp daemon, e.g.
ntp-simple
. - This is left as an exercise :-).
(As pointed out in the KB, there might be issues with ntp - and under all circumstances it shouldn't be run simultaneously with VMware Tools).
--
SteffenPoulsen - 19 Feb 2006
Steffen - thanks, that fixed it. I'll probably put it in the
.profile
for root since the VM is normally suspended.
--
RichardDonkin - 20 Feb 2006
Steffen and Richard, just to make this clear: my clock in the VM lost about 7 minutes in 15 "real" minutes, so I had to adjust the kernel command in the GRUB loader according to the KB article and had to add
clock=pit nosmp noapic nolapic
. Now everything is working as expected. Could this possibly be added to the next release?
--
RalfLimmer - 21 Feb 2006
Thanks you for trying this out, Ralf - sounds like it's a real problem in some installations. I'll add both your kernel parameters and the
ntpdate
functionality to the next version.
--
SteffenPoulsen - 21 Feb 2006
For laptops where the VM is kept asleep a lot of the time, it would be great to trap the 'wake up' event somehow (no idea how to do this as probably even Linux doesn't notice this). Failing that, we could optionally resync the time every 5 minutes or so (though this may not be a good idea in a large deployment depending on the NTP infrastructure).
Generally, we may just have to suggest to people to run an
ssh twiki-vm ntpdate
from the host PC after resuming the VM.
--
RichardDonkin - 22 Feb 2006
Steffen, thanks for incorporating my parameters into the next version!
Richard, I don't think that the suggestion to enter commands via
ssh
after wakeup is a good idea, because we should keep it as simple as possible for the Windows users - this is the idea of the VM after all. If we want to attract typical Windows users for TWiki, then we shoudn't assume unix knowledge.
In my opinion, the time synchronisation after a wakeup is a job of the VM player, not of the guest operating system. If I understand the VMWare docs correctly, then this is only possible with something called "VMWare Tools" - but I couldn't find them for the VM player and they seem to be available only for the commercial variants...
I think we have only two possibilities here:
- use a
cron
-job to synchronize the time every 5 or 10 minutes
- suggest that the VM should be restarted after a wakeup
Number (1) has the problem, that the time in the VM is still wrong right after a wakeup - if you would like to create a short entry or modify an existing page and the
cron
-job hasn't completed yet, then you still have the wrong time! I'm using this approach right now and it works (5 minute interval), but I think that for most users this will be confusing. This leaves us with suggestion (2)...
--
RalfLimmer - 22 Feb 2006
I think VMware tools is available for Player, since it's basically VMware workstation - however, you would need to install X (X Windows) on the TWiki VM, since the tools are graphical. This is based on last time I installed VMware, a few years ago, but is unlikely to have changed.
Restarting the VM after a wakeup rather removes the point of suspending it in the first place, so I think the best option is a periodic cron job, or using VMware tools if you have enough memory for X. Using X would also let you use graphical tools to administer Linux, which might be a good idea anyway for Windows users - I think
SvenDowideit is going to release a VM with X installed, by the way, see
TWikiVMDebianStable.
--
RichardDonkin - 23 Feb 2006
I have the same symptoms like
RalfLimmer for my system - it is losing time at a significant rate. This is critical because I want to use Kerberos for authentication, where a time skew must never exceed five minutes.
Many thanks for pointing to the
VMware KB article - I had tried to connect to other ntp servers, to set up an own ntp daemon, all without improvement.
One notice about VMware tools: To install VMware tools, or to be precise to
configure them on Debian, VMware needs the kernel includes in /usr/src/linux/ - otherwise they can't be activated.
--
HaraldJoerg - 23 Feb 2006
The solution with X Windows and the VMWare Tools sounds like the most elegant one. Do you know whether we are allowed to "ship" the VMWare Tools together with the VM? I'm envisioning a five-step-installation on Windows:
- Download VM Player
- Download VM image
- Fire up VM Player with image
- Fire up browser and do a
configure
- Start working with TWiki!
I think this would be a great way to enable the usage of TWiki for the zillions of Windows users out there...
--
RalfLimmer - 23 Feb 2006
It seems that
VMware actively encourages inclusion of VMware Tools in VMs being built for VMware Player (see the 6th bullet in list at end), so I would go ahead and include them in a future X-based image.
Note that
SvenDowideit may be doing an Ubuntu-based VM that would include X, and that there are some Ubuntu and Kubuntu images, as well as Damn Small Linux VMs, which might be a good starting point. All these variants are Debian-based, which I think is a good option for ease of software installation and updates.
The five-step installation is very much doable today even without VMware tools - in reality there are a couple of security steps, at least one of which is mandatory (see
TWikiVMDebianStable's
How to get started section for details).
--
RichardDonkin - 25 Feb 2006
nonono
I'm a debian person - I have however stopped working on it, as I am having ISP problems, and thus can't upload 300Meg
Instead, I'm working on the
TWikiOnDebian Debian package - hope to have it, and maybe a plugins pack done this week.
--
SvenDowideit - 26 Feb 2006
But Ubuntu is Debian
Or at least based on it, as is Damn Small Linux.
--
RichardDonkin - 26 Feb 2006
Applying kernel changes from KB article
The Twiki-vm is set up to use grub, the config file referenced in the KB article above is at the following location in this distro:
/boot/grub/menu.lst
.. edit it with something like Pico, and append the appropriate switches from the article. (for example, see above comment by
RalfLimmer on the subject)
--
DavidWall - 13 Mar 2006
It has been 24 hours since appending
clock=pit nosmp noapic nolapic
to the command line on the kernel; previously the wiki would be 5-6 hours behind by now. Currently it is still accurate, I find these changes definately work as intended.
--
DavidWall - 14 Mar 2006
TWikiVMDebianStable release 4.0.4 includes VMware Tools, which should address this issue by doing NTP time synchronisation. You would need to configure a suitable NTP time server.
--
RichardDonkin - 09 Jul 2006