Today, Friday February 13, at 3:31 PM (PST), the UNIX time will read exactly 1234567890. So exacly what is all this excitement about UNIX being able to count to 10? Surely, the operating system that is slowly but steadily putting Microsoft out of business must be able to do that. Well, it’s actually the UNIX time stamp, and what has all of us nerds talking is really just the fact that the numbers have never lined up in sequence like this before.
So what the heck is this UNIX time anyhow? Well, simply put, it’s actually the exact number of seconds since the the Unix epoch. This was 00:00:00 UTC on January 1, 1970.
It is not a linear representation of time nor a true representation of UTC (though it is frequently mistaken for both) as the times it represents are UTC but it has no way of representing UTC leap seconds (e.g. 1998-12-31 23:59:60).
We just noticed that the time was very far off on our sparkly new VMware EXS 3.5 server. When I went to run ntpdate to bring it up to sync, I was suprised to find that it could not make a connection to the time server because outbound UDP 123 traffic was blocked by the internal firewall. Here is what I got:
# /usr/sbin/ntpdate -u time.nist.gov
9 Apr 03:47:53 ntpdate: sendto(184.108.40.206): Operation not permitted
9 Apr 03:47:54 ntpdate: sendto(220.127.116.11): Operation not permitted
9 Apr 03:47:55 ntpdate: sendto(18.104.22.168): Operation not permitted
9 Apr 03:47:56 ntpdate: sendto(22.214.171.124): Operation not permitted
9 Apr 03:47:57 ntpdate: no server suitable for synchronization found
Normally I would just add a rule to the “/etc/sysconfig/iptables” file to allow traffic out on this port, but Vmware ESX server does not use iptables… It uses its own firewall, so I had to figure out how to change it. Happily, it turns out that there is a handy “esxcfg-firewall” command built just for such things.