>> >>> Tech showed up today to fix the clock on the XP (SP1) boxes.
>> Why on God's green earth are you still running SP1? Do you realize how
>> many security hotfixes you don't have installed on those boxes?
> We don't have admin rights so we can't do updates. I did ask the tech
> why we aren't on SP2 and he replied "SP2 causes problems". I then
> told him it has been a while since SP2 has been out, no? He said
> "yeah" and left it at that. My guess is "big brother" ordered no
> machines to be upgraded to SP2 unless absolutely necessary.
> At the end of next week I'll ask people in the main office (I am off
> site) if any machines are on DST. Hopefully they will come up with a
> plan that doesn't include "just wait until 02:00 on the first Sunday > in April" :0)
Your tech just doesn't want to be bothered, that's all.
And there's a way around the adm> >> Our Debian boxes worked just fine, but we had to patch a couple of
> older RH7.3 boxes.
> Here's the way it went for me:
> ** Suse 10: nothing required, it shipped out of the box with the > changes.
> ** Red Hat Enterprise Linux 3: only needed to update the appropriate > RPM package.
> ** Red Hat 8 and 9: too old to have updated packages, end-of-life
> products, and therefore had to download the tzdata tarballs and
> compile from source. Only took a few minutes for each server.
> ** Windows XP - there were some client machines that didn't update
> properly for whatever reason (all SP2, btw). Ours at home ... all
> three of them ... did.
> ** Windows 2000 - have to manually update DST data, but it's not > difficult to do.
>> Same for me. Sounds like his host info changed and the server doesn't
>> recognize it. Time to hose the entry for his login in
>> /etc/sshd/known.hosts
> That's it. Although PuTTY is a Windows client, so the file is
> somewhere else. I forgot about known_hosts :)
No -- I meant on the server side. If you clear your machines entry on the server it'll then re-set the key.