Posts Tagged ‘time’

Fixing the Time in an SME Server Running in VMWare Server 2

Monday, November 8th, 2010

First, a PSA: Please do a backup of all your data, if you haven’t done one in the last week!

A good daily backup over the network  saved my behind this week, after a hard drive crash on our home “server”.  My data was safe, though, I do have some rebuilding of the operating systems to do (Yes, systems, the server is a virtual machine).

I had the craziest time trying to get the time in the VM to stay in sync with the universe.   There are many posts on the web about a dozen different tricks and settings for making the time in a Linux VM work properly.  In my case, I think it turned out to be a simple problem, I didn’t have VMWare Tools automatically starting at boot time.

This page gave me the hints I needed:

The gist:
At the SME console:
/etc/rc.d/init.d/vmware-tools start
Make tools start on reboot:
# Redhat-based distros
chkconfig vmware-tools on
# SME 7
ln -s /etc/rc.d/init.d/vmware-tools /etc/rc7.d/S19vmware-tools


I had to do a song and dance to restore my DAR2 backup, but, generally I’m happy.  I still can’t access SME Server’s “/server-manager” web based GUI… that may be the next post on the PSI blog.

Background: My home server runs SME Server, formerly known as E-smith, from  I’ve been running this Linux based, server bundle for years, maybe even a decade.  However, a couple years ago, I migrated it into a virtual machine to reduce the number of computers that are running 24×7 at home.

Epilog: It might be time to do RAID at home.  Backups are good, but reconfiguration of a highly customized computer still takes a while.

Fixing the Time in Windows

Thursday, February 14th, 2008

In theory, Windows XP in a home (i.e. non-domain) setting should have no troubles keeping its time accurate. All you need to do is enable the “Internet Time” option so that it synchronizes with a network time protocol (NTP) server. It looks so easy, but it turns out that it’s really not bullet proof.

Most users should try a different NTP server first. The default server is heavily overloaded, and it’s hard to consistently get a sync. Try – that’s actually a network of machines that share the load.

But that’s not the solution in this blog post. IMHO, NTP is unusable in many small network environments because of firewalls and network address translation (NAT). Even the built-in Windows firewall can block NTP traffic which operates on UDP port 123.

Most home PCs connect to the Internet through a small, inexpensive router from the likes of D-Link, NetGear, Linksys, etc. Many of these block NTP or don’t work with it properly. This used to be a common problem with NATs. Port forwarding UDP port 123 to a computer works for some people, but that only works for one computer. And it didn’t work on the two routers I tested with today.

My solution that is generally bullet proof? Use a protocol that is TCP based. I don’t want to get too technical, suffice it to say that the chances of a TCP protocol working with all NATs is higher than that of UDP. Luckily, I found a perfectly good protocol and client (my backup plan was to write a crazy script to screenscrape a web page). It’s called DAYTIME it’s actually older and technically inferior than NTP, but what’s a second or two of accuracy if it works?

Now for a basic client, one might as well go to the source: It’s free, as functional as it needs to be, open source, and provided courtesy of a US government agency.

I setup a this as a weekly time update job on 10 small retail store POS networks through a generic maintence scripting system that is already in place: “nistime-32bit.exe Once -s5”. That’s it. It runs the time client, fixes the time, then exits. There are other options, but for this client, one time synchronizaton per week should be more than enough.

The moral of the story? UDP is over-rated in an Internet that is flooded by little home routers.