Anti-admins
Aug. 17th, 2004 11:45 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
jennyaxeSo, I'm still working with the web statistics thingy for all our domain customers. Currently I'm trying to hold a number of somewhat complex data structures in my mind, because it's easier to make the damn code if I can remember what I planned to do at least long enough to document it.
Before my vacation, there was a problem with logs for the customers on one of our NT servers. It turned out that the damn thing had been upgraded and the NTadmins (say that one out loud, if you don't understand the subject of this post) had forgotten to enable ftp login for the log transfer box. I handed the problem over to the PFY, who got the NTadmin to fix the login.
Still, customers were complaining that they didn't get their logs and stats. PFY checks, and finds that the logs he's getting aren't of the right format. He talks to the NTadmin, who has to call Microsoft to get help on how to change the format. Since the logs are being parsed by a horrible perl script, they're pretty much useless unless they're in the format the script expects.
Sometime during the last week, NTadmin reports that the problem has been fixed.
Today PFY comes to me and asks me to help him check what's going wrong, as he'd just done a double-check to verify that it worked - and found that it didn't.
It turned out that while the logs were still in IIS format, the format has changed between IIS 5.0 and 6.0. Logs from both versions claim to be "Version 1.0". But the fields come in a different order, so the horrible perl script croaks. And since my predecessor made sure that no error messages are ever seen by a person, noone noticed until PFY checked.
We took this up with the NTadmin. His reply: "Well, it's the same format, you'll just have to deal with the order being different cause it can't be helped".
Lucky for him that I've still got some vacation good humor left over. I am reaching for the painkillers, not the axe... for the moment, at least.
Before my vacation, there was a problem with logs for the customers on one of our NT servers. It turned out that the damn thing had been upgraded and the NTadmins (say that one out loud, if you don't understand the subject of this post) had forgotten to enable ftp login for the log transfer box. I handed the problem over to the PFY, who got the NTadmin to fix the login.
Still, customers were complaining that they didn't get their logs and stats. PFY checks, and finds that the logs he's getting aren't of the right format. He talks to the NTadmin, who has to call Microsoft to get help on how to change the format. Since the logs are being parsed by a horrible perl script, they're pretty much useless unless they're in the format the script expects.
Sometime during the last week, NTadmin reports that the problem has been fixed.
Today PFY comes to me and asks me to help him check what's going wrong, as he'd just done a double-check to verify that it worked - and found that it didn't.
It turned out that while the logs were still in IIS format, the format has changed between IIS 5.0 and 6.0. Logs from both versions claim to be "Version 1.0". But the fields come in a different order, so the horrible perl script croaks. And since my predecessor made sure that no error messages are ever seen by a person, noone noticed until PFY checked.
We took this up with the NTadmin. His reply: "Well, it's the same format, you'll just have to deal with the order being different cause it can't be helped".
Lucky for him that I've still got some vacation good humor left over. I am reaching for the painkillers, not the axe... for the moment, at least.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2004-08-17 03:38 am (UTC)"It's the same format but it's different"
no subject
Date: 2004-08-17 11:40 pm (UTC)If he does, he doesn't care about it. I mean, it's just us condescending Unix computer users who'd think that, and we don't really count.
Anyhow, I'm now making the script function regardless of what order the fields come in. Hashes are amazingly handy at times.