Monthly Archives: March 2014

Sysprep still needed but not because of duplicate SID

Leave a reply

I was told a long time ago that you needed to run sysprep because of issues with joining two machines to the domain with the same machine Security Identifier (SID). While researching what you need to do with cloned AMI images on EC2 I found this.

https://blogs.technet.com/b/markrussinovich/archive/2009/11/03/3291024.aspx

I can attest to wsus getting messed up if you don’t run sysprep, but interesting to find out that duplicate SIDs is not an issue.

Oops Java thinks the clock is an hour out.

1 Reply

I have been experimenting with home automation and have been testing out openHAB. I wanted to have a set of lights turn on at sunset and turn off early in the morning. One of the issues I found was with the time in openHAB being an hour out. After some head scratching and research everything looked normal.

$ date
Sun Mar 16 00:37:35 EDT 2014

Looks good the time is correct, the timezone is correct.

$ date --utc
Sun Mar 16 04:40:11 UTC 2014

Looks good as well.

$ md5sum /etc/localtime 
e4ca381035a34b7a852184cc0dd89baa  /etc/localtime

$ md5sum /usr/share/zoneinfo/America/New_York
e4ca381035a34b7a852184cc0dd89baa  /usr/share/zoneinfo/America/New_York

The timezone is set correctly to New_York.

I am using openjdk 1.7 so I need to install the dev tools,

$ sudo yum install java-1.7.0-openjdk-devel

then run a little sample code,

more DateDemo.java 
import java.util.Date;
import java.util.*;

public class DateDemo {
   public static void main(String args[]) {
       // Instantiate a Date object
       Date date = new Date();

       // display time and date using toString()
       System.out.println(date.toString());

       System.out.println(new Date());
       System.out.println(TimeZone.getDefault());
   }
}

$ javac DateDemo.java

$ java DateDemo
Sat Mar 15 23:45:40 GMT-05:00 2014
Sat Mar 15 23:45:40 GMT-05:00 2014
sun.util.calendar.ZoneInfo[id="GMT-05:00",offset=-18000000,dstSavings=0,useDaylight=false,transitions=0,lastRule=null]

Ok thats interesting, the time is an hour out from the system clock, and when I ran it on another centos 6 box I got,

$ java DateDemo
Sun Mar 16 00:47:46 EDT 2014
Sun Mar 16 00:47:47 EDT 2014
sun.util.calendar.ZoneInfo[id="America/New_York",offset=-18000000,dstSavings=3600000,useDaylight=true,transitions=235,lastRule=java.util.SimpleTimeZone[id=America/New_York,offset=-18000000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]]

Both hosts were set to the same New York time zone, and the md5 on /etc/localtime matched, so both appeared to be configured the same way.

A little more digging on how java gets it timezone and i found,

https://bugzilla.redhat.com/show_bug.cgi?id=489586

Turns out Java looks at /etc/sysconfig/clock.

The working host had,

$ more /etc/sysconfig/clock 
ZONE="America/New_York"

and the other one with the issue had

$ more /etc/sysconfig/clock
# The time zone of the system is defined by the contents of /etc/localtime.
# This file is only for evaluation by system-config-date, do not rely on its
# contents elsewhere.
ZONE="America/New York"

Well look at that, one has New York and the other has New_York.

After adding the _ to New_York Java now reports the correct time on both hosts, and my issue with openHAB is fixed.