Yesterday night I’ve discovered that users from one of our domains can no longer establish VPN connections. A mysterious situation indeed — just two days ago everything was working fine, I’ve been doing absolutely nothing critical on either of the VPN server or the domain controller, and yet any connection attempt results in VPN error 691 with a very promising text “Access denied because username and/or password is invalid on the domain.”

After major overhaul of development servers Subversion broke. Checkouts work fine, while checkins fail with the following 403 error in the Apache log:

Access denied: 'username' MKACTIVITY <reponame>:...

Tons of things (all of which seem quite legitimate to me) have changed while servers were rebuilt, and, therefore, I was completely clueless as for what could go wrong. Searching the net revealed many similar cases, but no working resolutions (except for improper case of the repository name, which is not the problem in my situation.) However, looking more carefully at the error message I noticed that the repository name in the Apache log is actually (repo1|repo2). The reason is that I am using LocationMatch directive in Apache configuration file to merge similar settings for different repositories. (I have several groups of repositories that share settings, but not all of them are the same, so I can’t just set settings for the root folder.) When I changed the configuration back to a single repository case, commits started working again. I assume it is AuthzSVNAccessFile that sees wrong repository name and can not apply correct permissions. The simplest resolution would be to place AuthzSVNAccessFile directive into a separate Location section for each repository.

Microsoft Windows never stops surprising me. The subst command was always pain in the a… back, and the trend seems to continue. I am using a substed drive to create the same environment for projects across different machines, which is named D: in this case. Everything went smooth until today when I approached the computer with a USB stick. System happily recognizes the device and says that you can go ahead and use it. Except… you can’t. The “Removable device” becomes listed as D:. But, when you open it, all you can see is the content of the substed folder. You have to delete the substitution point until it allows you to see what is attached to USB. Who would guess?

I was programming and had to peek at some helps when I was stuck in absolutely unexplainable situation. I had these docs in .chm format, so they are actually opening in Internet Explorer, but instead of the text I had to stare at the “Page cannot be displayed” error message. What the hell? My first intents were to blame the security settings in IE (which I do not regularly use and thus have security tied up just in case). So I went and tried all imaginable combinations, relaxing securities to barely protect anything, allowing all possible evils to happen… no luck. Well, there may be some system-wide settings then, so I googled, and googled, and googled… And found absolutely nothing helpful in my case — file was on the local disk, not downloaded from the Internet, permissions were correct — I couldn’t think of anything that should prevent it from opening properly. So I was stuck. Hopelessly I decided to do a very naive thing — to move the file into a different folder — and it worked! Aha, the folder name. There were the C# related docs, so the folder was named C#. I have no idea why but Internet Explorer just hates opening files from folders with # symbol. Ridiculous!

It so happens that I am a happy owner of Logitech MX 3000 Keyboard-Mouse Duo. While on Windows XP I never had any problems, upgrading to Windows 2003 proved to be a challenge. Well, both devices are working fine, but to use advanced features (i.e. hordes of extra buttons) you do need the Logitech SetPoint software to be installed. The original installation package shipped on CD detects my Windows 2003 and refuses to install complaining about not supported OS. Well, it must be an ancient version I thought. To the website we go, just to discover that the latest version claims the compatibility with XP/2000 only. Come on, Logitech guys, 2003 is merely a tiny step away from XP/2000.

Nevermind, I downloaded the installer. To my surprise it ran without any complaints. “It should work after all” — I said to myself… Nope. That piece of crap wonderful software managed to install just a random set of files where most of executables are missing.

So it seemed like it might work if we can trick it into believing it runs on Windows XP. Compatibility mode to the rescue. Once I set Windows XP compatibility mode for the installer, the picture changed dramatically. I saw more files being copied, drivers got installed, etc. For some reason the installation froze at the very end the first time I tried it. But when I killed the process and tried one more time it worked like a charm (prompted for unsigned drivers though). Reboot and enjoy.