Do I possibly have bad install media?


I have installed a clean install of UCS4.1 twice tonight, and each time it has had some showstopping error. The first time it was erroneous packages and the second time it was internal server error on the console.

Should I download again? I have used this image for several installs. This is on a different hyper-v server, but I have ONLY installed it on hyper-v server… so I can’t imagine that being it. And I checked the checksum with the website.

I must be the most unlucky guy in the world. After the AD Takeover finally went through, the last 2 days I have been dealing with machine trusts getting lost, and I find that kerberos is expiring all the tickets. I have given up on this take over… 40 angry users using cached credentials and having to put their name in twice is enough. So I am building a new domain to manually move to, cutting my losses since the old 2003 domain was configured by someone who probably learned on this network before I took it over. I need a beer.



well, if the checksum of your local image matches the one published on the web site then I strongly doubt downloading it again will change anything.

If you want to get to the bottom of the reason why the web console server isn’t working you should check the log files. The one for the console web server itself is “/var/log/univention/management-console-web-server.log”, and Apache’s log file “/var/log/apache2/error.log” might be of interest, too.

Kind regards,


I figured that out later last night after a third install. The time was an hour behind even though the timezone was right.

Service NTP stop, ntpdate, service NTP start and I had the right time.

I tailed those logs and it was failing to load the SSL cert, which made little sense that it could be a bad cert created twice in a row. So I checked the time and saw it was behind. My assumption is that the cert was not valid because my browser was trying to load it from 1 hour in the future (cert time wasn’t valid yet?) and if I waited an hour it would become valid.

I am not sure if that was the real issue, but syncing the time certainly did resolve it.



Glad you were able to figure it out! Yeah, having the clock set wrong can really ruin your day :slight_smile: Several security-critical services require the time to be correct, including certificates (if the client thinks they’re not valid yet then you’re screwed as you’ve seen) and Kerberos (if the time between the three involved machines client, authentication server and key distribution center doesn’t match within more or less strict parameters then the whole process simply fails).

For the record: the NTP daemon only does minor adjustments to the clock; huge differences are distributed over a lot of changes, and those take quite a while to be implemented. Meaning that if you have a big discrepancy like more than 15 minutes or so you should stop the NTP daemon and use ntpdate once. ntpdate sets the clock right now to the time retrieved from the NTP server. Afterwards you can start the NTP daemon again. Or in short: use ntpdate for setting the clock right now, use the NTP daemon for keeping it in sync.

Kind regards,