Since I've been forced to use my XP laptop more recently, I decided to re-install VersionTracker to keep me notified of any important updates. As I have come to expect, this failed. Even better, it failed in a fairly similar way to the iTunes problems I was having in my last post. An error message of "The system cannot open the device or file specified" and an Event Log ID of 10005.
What on earth is going on here? Deciding to now do a more general search on this issue, I fairly quickly came across the following Microsoft Knowledge Base article titled, 'You receive a "cannot open the device or file specified" error message when you try to install a Windows Installer package.'
Ay, caramba! I would have thought a better fix would have been to correct the fairly fundamental flaw in Windows Installer than to try and bugger around with removing encryption from various directories. After all, a good standard install of XP should have all home directories encrypted for each user to prevent access from other users and people with physical access to your computer (especially if you've got a laptop like I have.)
But seeing how this seems to be disrupting more and more installs lately, I decided to make my TEMP and TMP directories unencrypted with the assumption that important data shouldn't be living in there anyway, and the directories should be regularly cleaned up to not leave data lying around there for long.
But as the KB article also suggests, it appears that a lot of the time that the directory you are running the installer from has to be unencrypted as well. *sigh* There goes installing from my desktop from now on. I have to download to my temporary (unencrypted) directory and then install from there. Oh, to have the cute little "Downloads" folder pop-up that gives quick, one-click access to recent downloads that was in the recent OS X "Leopard" release on XP...
This worked for VersionTracker. I then decided to try and do a bit of other upgrading to see if I could stumble across any other issues. I did. There was an update available for Adobe Reader and lo and behold, it downloaded and failed to update correctly. Digging behind the scenes (now I knew what to look for), I found that it was downloading to
C:\Documents and Settings\lee\Local Settings\Application Data\Adobe\Updater5\Install
*sigh* again. This directory is obviously encrypted (as is every directory under my home by default) as well. Luckily I noticed that the Adobe updater has an option to configure where it downloads its updates to, so I pointed that out to a suitable unencrypted directory and now it works as well.
But it's inevitable that I am going to keep having issues with Windows Installer files until they fix this brain damaged flaw. Each and every application that decides it wants to use it's own directory for automatic updates will trigger off this problem that I will need to go in and fix by hand. I guess I should be grateful that at least I know how to recognise the problem now and how to quickly fix it. Hopefully this post might help someone else as well.
I hate Windows. I hate stupid, lazy programmers even more.
I do like gardens however.
Thursday, 6 December 2007
Tuesday, 4 December 2007
iTunes 7.5 on XP upgrade issues
Never one to make life simple for myself, I decided to do a bit of upgrading on my laptop today.
The Apple Software Update service had helpfully informed me that the latest iTunes + Quicktime updates (7.5.0.20 and 7.3.0.70 respectively) were available to download, so I decided to do the download through this tool instead of just using it as a notification service and doing a full, manual download by hand like I normally do. I'm pretty sure the MSI packages that are downloaded through this tool are pretty much full installs, so it's not really saving any bandwidth to do it this way (which is a shame - it would be worth doing if they were actually patches/deltas).
Of course the update failed. No useful message as to why of course. Just an extremely unhelpful pop-up saying "The system cannot open the device or file specified," and an equally unhelpful Application Event Log message (Event ID of 1013 and that's about it.) It appeared as if the failure was happening during "Starting Apple Mobile Device Support installation..."
Apple Software Update suggested I should try and install the MSI by hand, so that is what I then dutifully tried to do. I tried the iTunes MSI file and this failed as well, with no further useful information. Trying the AppleMobileDeviceSupport MSI file failed with the same error message, but with an error code as well (2755). The Application Event Log entry was more verbose, but equally as unhelpful except for a new Event ID of 10005. Seriously, would it kill programmers to actually log why they're putting an entry into the Event Log in the first place (and not just the what)?!
A quick Google on the various error messages and Event IDs didn't really turn up anything useful at all, except for vague suggestions of cleaning up the MSI Installer database through use of the "Windows Installer CleanUp Utility" and deleting the entry for the application that wasn't installing properly. This seemed worth a try if the application in question doesn't require too much custom configuration (which applied in my case as I just needed to adjust the install path like I do for all my installs anyway.)
So the next issue I ran into is that this tool needs Windows Script Host enabled to use it. Somewhere along the way, I've disabled that completely on my laptop due to the inherent security weaknesses it introduces and the fact that nothing I use needs it. Until now of course. So I temporarily re-enabled it, which basically just means setting the following registry key back to "1":
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows Script Host\Settings\Enabled
I removed the entries for both iTunes and Apple Mobile Device Support, and attempted to the re-do the Apple Mobile Device Support install again via the MSI. Same problem. Same problem with iTunes.
I then decided to delete iTunes completely and try a fresh install, except when I went to Add/Remove programs, it wasn't there... which on reflection is probably obvious as the Windows Installer Cleanup Utility most likely removes the entry that is used by Add/Remove Programs to track what software is installed. Mental note for the future.
At this stage, I began to suspect that my installation of Quicktime Alternative might have something to do with things, although I was under the impression that an upgrade of Quicktime should pretty much install straight over the top without too much hassle and I'd only be left with the hassle of disabling Quicktime and getting Quicktime Alternative to work again. I had installed Quicktime Alternative so that MPEG Streamclip would work properly on my laptop when I forced to use it instead of one of my Macs.
So the next step was to uninstall Quicktime Alternative to see if this made a difference. After the reboot (grr...) that this required, I then retried the iTunes MSI install and this failed as before. I now tried the Quicktime only MSI install and this failed in the same way as the Apple Mobile Device Support install (error code 2755 and Event ID 10005.) Which I thought was interesting, as my guess was that they were both looking for some file and/or service that wasn't present or running. Why couldn't the programmer just log that?! Without that info, I was either forced to spend even more frustrating time trying to debug/deduce what was missing through process tracing tools, or just use the de-facto, brute force fix on almost all things Windows related - do a complete reinstall.
This meant going back to the full setup files for iTunes + Quicktime instead of just the updated MSI files. I tried an old Quicktime full install that I had (7.2.0.240) and it worked! I then tried the newer MSI file... and it failed. Wow. By this stage though, the call of the garden was strong, and I decided to admit defeat and download the full installs of both iTunes + Quicktime and reinstall by hand. Bugger using the updates; I'll just have to stomach paying for the redundant downloads.
Which of course worked. Sigh. If there's one thing that I hate worse than the atrocious logging used by the vast majority of lazy programmers that makes life far more difficult for system administrators and support personnel that it should be, it's brain-dead, poorly tested upgrades to software that almost seem to rely upon the trained response in Windows users to just reinstall everything from scratch whenever something goes wrong.
Deep breath. I disabled WSH again, and then started to muse over how well my iPod Nano would stand up to direct sunlight and the occasional bit of dirt thrown at it...
The Apple Software Update service had helpfully informed me that the latest iTunes + Quicktime updates (7.5.0.20 and 7.3.0.70 respectively) were available to download, so I decided to do the download through this tool instead of just using it as a notification service and doing a full, manual download by hand like I normally do. I'm pretty sure the MSI packages that are downloaded through this tool are pretty much full installs, so it's not really saving any bandwidth to do it this way (which is a shame - it would be worth doing if they were actually patches/deltas).
Of course the update failed. No useful message as to why of course. Just an extremely unhelpful pop-up saying "The system cannot open the device or file specified," and an equally unhelpful Application Event Log message (Event ID of 1013 and that's about it.) It appeared as if the failure was happening during "Starting Apple Mobile Device Support installation..."
Apple Software Update suggested I should try and install the MSI by hand, so that is what I then dutifully tried to do. I tried the iTunes MSI file and this failed as well, with no further useful information. Trying the AppleMobileDeviceSupport MSI file failed with the same error message, but with an error code as well (2755). The Application Event Log entry was more verbose, but equally as unhelpful except for a new Event ID of 10005. Seriously, would it kill programmers to actually log why they're putting an entry into the Event Log in the first place (and not just the what)?!
A quick Google on the various error messages and Event IDs didn't really turn up anything useful at all, except for vague suggestions of cleaning up the MSI Installer database through use of the "Windows Installer CleanUp Utility" and deleting the entry for the application that wasn't installing properly. This seemed worth a try if the application in question doesn't require too much custom configuration (which applied in my case as I just needed to adjust the install path like I do for all my installs anyway.)
So the next issue I ran into is that this tool needs Windows Script Host enabled to use it. Somewhere along the way, I've disabled that completely on my laptop due to the inherent security weaknesses it introduces and the fact that nothing I use needs it. Until now of course. So I temporarily re-enabled it, which basically just means setting the following registry key back to "1":
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows Script Host\Settings\Enabled
I removed the entries for both iTunes and Apple Mobile Device Support, and attempted to the re-do the Apple Mobile Device Support install again via the MSI. Same problem. Same problem with iTunes.
I then decided to delete iTunes completely and try a fresh install, except when I went to Add/Remove programs, it wasn't there... which on reflection is probably obvious as the Windows Installer Cleanup Utility most likely removes the entry that is used by Add/Remove Programs to track what software is installed. Mental note for the future.
At this stage, I began to suspect that my installation of Quicktime Alternative might have something to do with things, although I was under the impression that an upgrade of Quicktime should pretty much install straight over the top without too much hassle and I'd only be left with the hassle of disabling Quicktime and getting Quicktime Alternative to work again. I had installed Quicktime Alternative so that MPEG Streamclip would work properly on my laptop when I forced to use it instead of one of my Macs.
So the next step was to uninstall Quicktime Alternative to see if this made a difference. After the reboot (grr...) that this required, I then retried the iTunes MSI install and this failed as before. I now tried the Quicktime only MSI install and this failed in the same way as the Apple Mobile Device Support install (error code 2755 and Event ID 10005.) Which I thought was interesting, as my guess was that they were both looking for some file and/or service that wasn't present or running. Why couldn't the programmer just log that?! Without that info, I was either forced to spend even more frustrating time trying to debug/deduce what was missing through process tracing tools, or just use the de-facto, brute force fix on almost all things Windows related - do a complete reinstall.
This meant going back to the full setup files for iTunes + Quicktime instead of just the updated MSI files. I tried an old Quicktime full install that I had (7.2.0.240) and it worked! I then tried the newer MSI file... and it failed. Wow. By this stage though, the call of the garden was strong, and I decided to admit defeat and download the full installs of both iTunes + Quicktime and reinstall by hand. Bugger using the updates; I'll just have to stomach paying for the redundant downloads.
Which of course worked. Sigh. If there's one thing that I hate worse than the atrocious logging used by the vast majority of lazy programmers that makes life far more difficult for system administrators and support personnel that it should be, it's brain-dead, poorly tested upgrades to software that almost seem to rely upon the trained response in Windows users to just reinstall everything from scratch whenever something goes wrong.
Deep breath. I disabled WSH again, and then started to muse over how well my iPod Nano would stand up to direct sunlight and the occasional bit of dirt thrown at it...
Saturday, 24 November 2007
Proxy Woes With Tiger
For a while now, I've been having an intermittent (and therefore highly annoying) problem with proxy settings with a couple of my Mac machines (10.4.x). Every now and then, certain applications seem to ignore the proxy settings I have defined and attempt to directly connect to the Internet.
I know this because I see the packets bounce off my internal firewall. When this happens, I recheck the proxy settings, and even confirm that they work by firing up Software Update and Safari and see if they can connect. They always do. Even going to the command line and using "scutil --proxy" works as expected.
One of the main culprits is VersionTracker Pro. Launching it starts off a disk scan to find applications that might need updating. It does this by submitting the versions on your machine to be compared with a master list located on the VT web site. This always works. You then get a list of applications that can be updated, and if you click on any of them a preview pane gives you some further info on the application and the update available.
Well, it's supposed to. Most of the time this doesn't work for me, as it tries to make the request for this info directly to the Internet instead of going through the proxy. Sometimes however it does, and up pops the details as expected. This could have been put down to flakiness within the VT application itself (and it certainly might be contributing in some way to the problem), but I've also noticed other flakey behaviour with a couple of other applications on my network; online TV guide updates within various apps spring to mind. Oh, and trying to register tools like Mac Pilot.
Anyway, I've lived with this annoyance for quite a while but recently I decided to do something about it once and for all. I tried poking around the lower level workings of Mac OS X to see if something was up there, but as mentioned above, command line utilities like scutil gave me the results I was expecting. I even tried posting to the online Apple forums, but so far, no joy there.
I did start to notice that perhaps there was some differentiation with the requests due to whether HTTP or HTTP/S was used for the request. In the VT example the first request (that works) is HTTP/S and the second request (that fails) is HTTP.
But there seemed to be no difference in my HTTP settings compared to my HTTP/S settings, so eventually I got sick of trying to nut this OS X flakiness out. And I certainly did not want to just blindly pick holes in my firewall just to let some rogue application and/or OS X flakiness have its way. Then it struck me that I should just transparently proxy these requests and be done with it. I already had a FreeBSD-based firewall running Squid for all web access.
Which worked a treat. I still get to enforce only specific rogue application/sites that are allowed to be transparently proxied, and everything is now working as expected. The rogue applications think they are directly communicating with their sites in question, but I still get to log them through the proxy and leave my firewall intact. It's fairly low maintenance to add a new rule if I ever need to. I just need to add forwarding rules to my firewall such as:
Configuring squid to work as a transparent proxy is a doddle nowadays as well. I found a good description at Leslie Viljoen's wiki called Eclectica, which also happens to run on a Mac Mini (a good sign I thought.) His instructions are for Squid 3 (in beta), but as pointed out by a visitor, they also happily work with the later 2.6.x versions as well (I'm running 2.6.16 myself). In my existing config pretty much all I needed to do was add the "transparent" option to the http_port directive and that was it!
So simple at the end of the day, even though initially I didn't think of it because it offended my sensibilities somewhat that things weren't working as they should. I wanted the proxies to work as advertised! But I guess, like a lot of things in life, sometimes you just have to forget about looking at the trees if you want to enjoy the forest...
I know this because I see the packets bounce off my internal firewall. When this happens, I recheck the proxy settings, and even confirm that they work by firing up Software Update and Safari and see if they can connect. They always do. Even going to the command line and using "scutil --proxy" works as expected.
One of the main culprits is VersionTracker Pro. Launching it starts off a disk scan to find applications that might need updating. It does this by submitting the versions on your machine to be compared with a master list located on the VT web site. This always works. You then get a list of applications that can be updated, and if you click on any of them a preview pane gives you some further info on the application and the update available.
Well, it's supposed to. Most of the time this doesn't work for me, as it tries to make the request for this info directly to the Internet instead of going through the proxy. Sometimes however it does, and up pops the details as expected. This could have been put down to flakiness within the VT application itself (and it certainly might be contributing in some way to the problem), but I've also noticed other flakey behaviour with a couple of other applications on my network; online TV guide updates within various apps spring to mind. Oh, and trying to register tools like Mac Pilot.
Anyway, I've lived with this annoyance for quite a while but recently I decided to do something about it once and for all. I tried poking around the lower level workings of Mac OS X to see if something was up there, but as mentioned above, command line utilities like scutil gave me the results I was expecting. I even tried posting to the online Apple forums, but so far, no joy there.
I did start to notice that perhaps there was some differentiation with the requests due to whether HTTP or HTTP/S was used for the request. In the VT example the first request (that works) is HTTP/S and the second request (that fails) is HTTP.
But there seemed to be no difference in my HTTP settings compared to my HTTP/S settings, so eventually I got sick of trying to nut this OS X flakiness out. And I certainly did not want to just blindly pick holes in my firewall just to let some rogue application and/or OS X flakiness have its way. Then it struck me that I should just transparently proxy these requests and be done with it. I already had a FreeBSD-based firewall running Squid for all web access.
Which worked a treat. I still get to enforce only specific rogue application/sites that are allowed to be transparently proxied, and everything is now working as expected. The rogue applications think they are directly communicating with their sites in question, but I still get to log them through the proxy and leave my firewall intact. It's fairly low maintenance to add a new rule if I ever need to. I just need to add forwarding rules to my firewall such as:
# ipfw add <ruleno> fwd <proxy-ip>,<proxy-port> tcp from <client-ip> to <rogue-site-ip> dst-port 80 setup keep-state
Configuring squid to work as a transparent proxy is a doddle nowadays as well. I found a good description at Leslie Viljoen's wiki called Eclectica, which also happens to run on a Mac Mini (a good sign I thought.) His instructions are for Squid 3 (in beta), but as pointed out by a visitor, they also happily work with the later 2.6.x versions as well (I'm running 2.6.16 myself). In my existing config pretty much all I needed to do was add the "transparent" option to the http_port directive and that was it!
So simple at the end of the day, even though initially I didn't think of it because it offended my sensibilities somewhat that things weren't working as they should. I wanted the proxies to work as advertised! But I guess, like a lot of things in life, sometimes you just have to forget about looking at the trees if you want to enjoy the forest...
Subscribe to:
Posts (Atom)