Forget you ever knew me

If you’re moving to a new computer at work and would like to move your C# source code from your old computer—don’t bother.  Seriously.  You’ll give your brain a boil if you try.

In what follows, I am using Visual Studio 2012.  Details may differ if you’re using a different version, but the basic answer remains constant.

To prevent the problem from ever occurring, what you want to do is check in all your changes before you give up the old computer.  On the new machine, start Visual Studio, and, on the Start Page, choose “Connect to Team Foundation Server...” instead of one of the “Recent” items:

Cruise to your project in the Source Control Explorer and select “Get Latest Version” in the right-click menu.  It’ll ask you to map your project to a local folder.  Do so.  It will then check everything out for you into the location on your new computer.  You’re done.

Unless you went ahead and copied your workspace folders over anyway, and are now extremely pissed because you keep getting this message:

If so, here’s how to fix it, even if you’ve spent the last two weeks making uncountable and unrecoverable changes to your local copies that would get you fired if you lost them.

In Visual Studio (2012), at the top of your Source Control Explorer window, you’ll see a Workspace: dropdown.  Select “Workspaces...” from the dropdown.  In the Manage Workspaces dialog that comes up, remove the workspace that you think you’re already connected to.  Workspace, not the local folder on your hard drive.

It’ll try to scare you by telling you the change is permanent.  Ignore the histrionics and just do it.

Restart Visual Studio, and as in the above steps, select “Connect to Team Foundation Server...”  It’ll treat your machine and your copied-over folder as if it were a new tree.  Get Latest Version, map your “new” local folder, resolve local conflicts if there are any, and you’re done.  The reason this works and everything else fails is because the workspace is tracked on your Team Foundation Server, and it is uniquely tied to a machine and a user.  When you copy your folders to a new machine, Visual Studio, the Team Explorer and the Source Control Explorer will conspire to make you think you’re connected—but you’re not.

Deleting (“Forget you ever knew me”) and recreating workspaces, it turns out, are trivial operations.

The Real True skinny on Customizing the Windows 7 login page (OEMBackground)

There are multiple places on the net that tell you how to change the Windows 7 login screen.  There are multiple sites that describe the gotchas.  Here, I will put them all together, as well as provide a pair of registry files that will make customizers’ lives simpler.

I wanted to put a larger version of this image on all my Windows 7 computers:

It’s a photo of the cathedral in downtown Sàigòn (officially named “Thành phố Hồ Chí Minh,” or “Ho Chi Minh City”), which I took in 2002 from the steps of the Post Office.  The yellow pillars belong to the PO.  The cathedral’s name, “Nhà thờ Đức Bà,” is translated as “Notre Dame Cathedral.”  Nhà thờ is the term for any size church, while Đức Bà might be better translated as “Virtuous Lady.”  It’s clearly a cathedral, and out front there’s a tall white statue of the Virgin, so the distance from Virtuous Lady to Our Lady to Notre Dame is small—but present.

Step One:  Add OEMBackground DWORD value to the registry.  Start regedit and cruise to

     HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\Background

and add a new DWORD value, “OEMBackground” with the hex value of 1.  Or use this oembackground.reg file:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\Background]
"OEMBackground"=dword:00000001

Save and double-click the oembackground.reg file.

Step Two: Ensure that your OEMBackground image is a jpg file and less than 256K.  Note that this means “file size on disk,” which can be different from the actual image size.  One byte larger and it won’t work.  Note that the simplest way to make a jpg file smaller in size without changing the dimensions is to edit it in Photoshop Elements and save it with lower “Quality” than usual.  To meet these requirements, I saved my 1920x1080 image with quality set to 3, rather than 12 (the max).  In paint.net, save the file as a jpg, but change the image quality slider.  Naturally, you can use your favorite image editor, such as Gimp, to perform similar tricks.

Step Three:  Ensure that the following path exists (substituting the appropriate drive letter for “C:”):

    C:\Windows\System32\oobe\info\backgrounds

Step Four:  Copy your modified jpg background into that directory and name it “backgroundDefault.jpg” (even though Windows is supposed to be a case-insensitive OS, case is important here).  Do not name it defaultBackground.jpg.  A few sites claim that’s the right name, but they are wrong.

Step Five:  Log out (or hit Ctrl-Alt-Delete).  If you see your new background on the login page, you can skip the rest.  You’re done.

Step Six:  That obviously failed for you.  (This often happens with Windows 7 Home Premium, or Windows 7 Enterprise [which you’ll most likely encounter at work].)  You need to modify another key in the registry; this is because you need to set a policy that tells Windows to always use the custom background, even if some built-in, or installed, theme overrides the OEM background.  Start regedit and go to:

    HKLM\SOFTWARE\Policies\Microsoft\Windows\System

and add a DWORD value, “UseOEMBackground”, again with the hex value of 1.  Or use this registry file:
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System]
"UseOEMBackground"=dword:00000001


Save it to a file called “alwaysuseoembackground.reg” and double-click it.  Log out, and you should immediately see your new background.

If you don’t, you’ve misspelled something.  Really.  Double-check the spelling (including case) of your saved file, of the directories you created (if they didn’t already exist) and, especially, of the keys you added to the registry.  If you typed them in by hand, it’s likely you misspelled something.  You should save the registry hacks I’ve provided here to files on your drive, rather than type them in by hand.

I’ve found this works even at work, where they impose a rather ugly background on all Windows 7 systems.  Just be sure to use both registry hacks.

How to override HOMEDRIVE in an Active Directory environment

I found this answer on superuser.com, where it was migrated from stackoverflow.com.  On StackOverflow, it was marked as “Off-topic” and closed.  So long as the answer was preserved, we can be grateful.

The superuser.com thread contains much more than I’m covering here, so if what I cover doesn’t address your question, please, follow the yellow brick link.

Suppose you’re working for a company that uses Active Directory to control access to the intranet.  There are many benefits to such an arrangement, but there are also a few disadvantages.  Meaningless group policies that enforce and control individual preferences number among the latter.  The worst one I encountered was a policy that forced my desktop wallpaper picture position to “Stretch.”  Since the policies did not force me to put up with the official Company Wallpaper, there was no earthly reason for such enforcement.  I complained multiple times, but was told that “Oh, we can’t help you, because we get the policies from another Department,” the name of which I was not, apparently, allowed to know (“Section G,” anyone?).

Eventually, they gave that one up, but only for the newer computers on the network.  For my old machine, I was forced to write a bat file (“Euuuwww, ick”) to set the Picture position in the registry.  Luckily, I no longer have to use it on the new machine.

Another meaningless policy (at least for developers) is one that I encountered recently while using PowerShell.  HOMEDRIVE was set to H: instead of the correct C:.  For other environment variables, I could use workarounds in my profile file like this:

    Set-Variable -Force -name HOME "C:\Users\$user"

But I could set that all day and the group policy would instantly override it:

     »  Set-Variable -Force -name HOMEDRIVE "C:"
  »  echo $env:HOMEDRIVE
    H:

And (much worse):

    » resolve-path ~

    Path
    ----
    H:\

Ick.  This meant I couldn’t do simple things like cp foo.bat ~/. which is perfectly legal with PowerShell.  Except that when I tried it, the H: drive would end up with more bytes to mark against my (teensy) quota.

The solution is rather elegant.  All you have to do is add a little bat file to your startup directory.  Here’s where the startup directory is:

For you:
    %userprofile%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

For all users:
    %SystemDrive%:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup

If you can’t find AppData, enable the viewing of hidden files on the Folder Options cmdlet in your Control Panel.

Once you have your startup directory (your own, not the one for all users), create a bat file in it called “homedrive.bat” in it containing the following lines:

     net use h: /delete
    net use h: "\\localhost\C$\Users\%USERNAME%"

That should do it. You can also use %SystemDrive% instead of C, and your login name instead of %USERNAME%. Substitute whatever is appropriate for h:, of course.

What this does is delete the HOMEDRIVE mapping set by the group policy, and replace it with something actually useful.  If you do a net use in your PowerShell command window, you should see something like this:

» net use
New connections will be remembered.


Status       Local     Remote                    Network

-------------------------------------------------------------------------------
OK           H:        \\localhost\C$\Users\ivanlaningham
                                                Microsoft Windows Network

What has happened is that you’ve just mapped your local C: drive as a network drive. Thus H: is identical to C:. That means cp foo.bat ~/. will do the right thing.

Priceless. And elegant. 

God N Solves “server refused our key”

Perhaps a better title might be “God N googles ‘server refused our key’ and eventually gets the answer he wants.”  Or needs.  Either way, after trying for a week or so, I’m finally able to login to my favorite CentOS 6 servers without typing my username and password.

Originally, I thought I’d note the solution down in my little black book of links, but then I noticed that the linkee was a blog that hadn’t been updated since 2010 and had only three posts.  What if it fell off the net?  Things do.  It’s the reverse of the the 60s building boom in Chicago:  “That building wasn’t there this morning.”  Now it’s, “That page was there ten minutes ago.”  Clearly it was time to start the blog I’d been waffling about for months.

So here are the exact steps to follow religiously if you’re Putty-ing from a Windows® box to a Linux box.  I prefer CentOS over other Linux distributions, but these steps should work for all modern Linuces.

Step Zero:  Remember what Pirsig says.  You’re here because you’re stuck.  You’re probably pissed, if not furious.  Imagine Detective Matt Sikes pounding his steering wheel and headliner while Sam Francisco looks on in amusement.  That’s your state of mind.  Stuck.  What’s Robert Pirsig got to do with anything?  “Cultivate being stuck,” he says.  You’re still pounding your roof.  Why cultivate such a state?

Because you’re not there that often.  Think about it.  When’s the last time you were stuck?  Really stuck, not that wimpy, “Oh, darn, this graphics card is 25mm too long and will bang into my memory” kind of irritation.  Irritation doesn’t count, because in that situation, you know immediately what to do.  Buy low-profile memory.  Full duration of stuckness?  Too brief to measure.  No, what you’re looking at is the kind of stuckness you get when you’ve been (admit it) trying the same exact thing over and over and over again, expecting different results, for at least a week.

Now you’ve eaten all the chocolate in the house.  You’re making trips to 7-11 at midnight to get more, and you don’t really like what you can get there.  You’re here because you’re ready to pop a blood vessel in your brain, and you’re thinking it might not be all bad if it blows.

So.  Live in the moment.  There is no past.  No future (especially if you don’t succeed in getting Putty to log you in with a private key).  Only the present, in which you are Stuck.  In more ways than one.  You’re going nowhere.  In more ways than one.  Cultivate being stuck:  let the problem you’re obsessing about fall out of your consciousness and your mind run loose.  Observe the pain you’re feeling.  Float above it.  Meditate in and on that state.  Stop analyzing every step:  that’s what got you here.  Keep your mind open for solutions to other problems.  “One more google,” you think.  “What can it hurt?”  Well, you might flounder in the red mist, banging your head against the wall for another week or so.  Or, you might run across an ancient Mayan God who’s got the answer.

Here it is.

Step One:  Login to your Linux box conventionally and chmod 755 ~.

Really.  Do it now. If you don't do that first, even if you already KNOW it’s mode 755, then none of the following will work.

Step Two:  While still logged in,

    mkdir .ssh; chmod 700 .ssh; cd .ssh; touch authorized_keys; chmod 600 authorized_keys

You can copy the above line, paste it and hit enter.  Then make SURE that .ssh and .ssh/authorized_keys belong to you.  Do a chown me:mygroup on the directory (~/.ssh) and the file (~/.ssh/authorized_keys).  Do it now so you don’t forget.

Step Three:  On your Windows system (and this should work on any version of Windows on which Putty runs), go to (i.e., “if you’re running Windows 8, jab randomly at the screen until you get a search box”) your Start Menu (Windows key is probably fastest; on Windows 8, it’s the Windows key + S) and type “puttygen” into the search box.  Hit Enter.  If it tells you it doesn’t know what you’re talking about, visit the Putty home page (skip the “improved” variants:  they add nothing of value) and download the Putty installer package.  Even if you’re running Putty as we speak, download the installer package and install it.  It won’t nuke your precious settings:  they’re kept in the registry, and they’re safe.  Once you install, either repeat the search or double-click puttygen.exe because you know where it lives now.  The idea is to run puttygen and get this:

I know.  You’ve done all this.  That’s OK.  You’re cultivating being stuck, remember?

Step Four:  Hit the Generate button.  Wiggle your mouse to make the green bar move across the pane.  Once it gets enough randomness, it will generate a public key, which you can see in the “Public key for pasting ...” window.

Step Five:  Type your passphrase into the appropriate input box.  Do it BEFORE you save the private key.  Pick a phrase that you can easily remember, and one that you can ALWAYS spell the same way.  If you pick one that has a word that might end in either a consonant or a vowel and the phrase makes sense either way, PICK A DIFFERENT PHRASE.  Seriously.  Pick a phrase that you can be confident that you can type without error.  If you forget and misspell, nothing will work—and you’ll end up here again, only this time I’ll say “I told you so.”  And I’m not very good at forbearance.

Step Six:  Hit “Save private key.”  That’s it.  Name the file something that ends in .ppk that you can remember and find again later.

Step Seven:  Copy the public key from the “Public key for pasting...” window.

Step Eight:  On your Linux box, use your favorite editor to edit the authorized_keys file that you touched in your ~/.ssh directory.  I use vim, so my command would be “vim authorized_keys” (or whatever alias you use: I alias “vi” to “gvim”).


Step Nine:  Paste what you copied in step Seven into the authorized_keys file.  Make certain it’s all on one line.  Contrary to other pages/posts, do include the comment.  That’s the part after the ‘== ’ near the end.  Save the authorized_keys file and exit from your editor.  Check that the permissions on the file are still 600.

Step Ten:  Start pageant.  This is one of the accessory programs in the Putty installer package that you should have downloaded in step three.  You should be able to figure out how to run it by now (hint: it’ll be in the same directory as puttygen).  You’ll see this:

Step Eleven:  Press the “Add Key” button.  Browse to where you saved your private key file.  (Note: you’ll have to do this every time you run the program.  More about this later.)  Double-click your private key file.  You should see something like this:

Step Twelve:  Click the “Close” button.  Don’t worry, pageant will keep running in the background.

Step Thirteen:  Start putty.  Load the values for whatever linux system you want to login to without using a password.  The system I want to login to is named “Ta-Witz” (shit mountain in Ch’ol, one of the 60+ Mayan languages.  More later).

Step Fourteen:  Cruise to Connection->Data, and fill in your username on your server in the “Auto-login username” field:

Step Fifteen:  Select Connection->SSH->Auth, and make sure that “Attempt authentication using Pageant” is selected (that’s the default, so it should be):

Step Sixteen:  Select Session, and push “Save.”

Step Seventeen:  At this point, you should be able to double-click the appropriate host name in the Putty window (or double-click your previously created desktop shortcut), and see the following:

If you don't see your shell prompt, you did something wrong.  Go back through all previous steps and fix each problem as you come to it.  Don’t worry, you’ll see it.  Eventually.

Step Eighteen:  You’ll need to create a shortcut in your Windows startup directory.  In the “Location” field, type the following, with appropriate substitutions for your system:

   C:\Putty\PAGEANT.EXE "C:\Users\<yourname>\latest-key.ppk"

What this will do is ask you for your secret passphrase when you start Windows (or login).  You won’t have to type it again until you restart.

To apply to other Linux systems, all you should have to do it copy your authorized_keys file over to them.  You can, if you desire, then disable the ability to login with passwords.  This is only a good idea if you are certain that no one else will need to use a password.

If you’re still having trouble, I can only tell you the following anecdote, about giving a 1975 Gremlin a minor tuneup.  I’d done many tuneups before, and they usually took about an hour.  Two weeks after I started, I tightened down the bolts on the head after having installed a new gasket.  I turned the key and listened to the engine, for perhaps the 400th time.  “Still runs like shit,” I told my brother.  He shrugged as helplessly as I felt.

I decided that the only thing left was that I had accidentally constricted the exhast system during the “tuneup.”  It was a (very) long shot, but it was all I had.  I drove the car, sputtering and banging and shimmying to beat the band, to Midas Mufflers, where they dutifully sold me a new muffler system.  I started it up.  “Shit,” I said, “it’s still running terribly.”

“That sounds like firing order,” said the head mechanic.

“Nah.  It’s 1-5-6-3-2-4.  That’s the first thing I checked.”

“Let’s look at the manual.”  He opened the book, popped the hood, looked at the page, swapped the two middle spark plug wires and said, “Start it up again.”

Never has an American Motors straight 6 run so smoothly.  Or caused greater embarrassment to a shade-tree mechanic.  35 years later, I still remember the correct order:  1-5-3-6-2-4.  Hang on, I better check the manual again.

---

Note

According to Nick Hopkins, a respected linguist and Mayanist, “Ta-witz” does not mean “Shit mountain.”  Instead, it’s “shit of the mountain,” a rather different proposition.  I had modelled the construction on a statement I read somewhere by Sir J.E.S Thompson to the effect that the Mayan name for the common vulture was “ta’ hol,” “shit head.”  Here’s what Nick has to say:

“Ta’-hol” for vulture derives from an earlier tan-hol, “ash-head,” as in some other languages, referring to the gray head and neck of the common vulture (as opposed to the red-headed turkey vulture). It’s all too easy to go from tan-hol to ta-hol (lose the n) to ta’-hol (add the glottal stop in a “folk etymology”).

Since it’s way too late for me to change the name of the server to the correct (in Ch’ol), “tya’-bä witz” (“mountain made of shit”), I’m just going to live with it.  I should’ve checked with Nick five or six years ago when I named it.

God N Solves “Failed to connect to configuration server”

When I heard about the heartbleed bug, I updated my CentOS 6.3 server’s openssl library.  The next day, I tried to run meld.  Here’s the traceback (emphasis added):

Traceback (most recent call last):
  File "/usr/local/bin/meld", line 138, in <module>
    main()
  File "/usr/local/bin/meld", line 129, in main
    from meld.meldapp import app
  File "/usr/local/lib/meld/meld/meldapp.py", line 199, in <module>
    app = MeldApp()
  File "/usr/local/lib/meld/meld/meldapp.py", line 113, in __init__
    self.prefs = preferences.MeldPreferences()
  File "/usr/local/lib/meld/meld/preferences.py", line 265, in __init__
    super(MeldPreferences, self).__init__("/apps/meld", self.defaults)
  File "/usr/local/lib/meld/meld/util/prefs.py", line 93, in __init__
    self._gconf.add_dir(rootkey, gconf.CLIENT_PRELOAD_NONE)
glib.GError: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://projects.gnome.org/gconf/ for information. (Details -  1: Failed to get connection to session: /bin/dbus-launch terminated abnormally without any error message)

What I found after a great deal of research (and the usual head-banging) is that the error means exactly what it says.

Almost.

It turned out that /bin/dbus-launch did not exist, not that it terminated abnormally.  “Why not?” I asked.

I finally found the answer in Redhat bug 172231.  They moved it.  Back in 2005 (or before).

Meld, installed and working on my system for years (well, for a minimum of 444 days, to be exact, which was when I finally dumped the frustrating SuSE distro and installed CentOS 6.3), suddenly stopped working by throwing the above exception, after openssl was updated.  And they moved a file it depends upon in 2005?

Where does it live now?  Inside the dbus-x11 package, which I didn’t have (the server can compile and run X programs, but the display is on a different system, and I don’t have a desktop installed—thus, no Gnome, no KDE). To fix the problem, I did the following:

    $ yum install dbus-x11

Then,

    $ whence dbus-launch
    $ /usr/bin/dbus-launch

Finally,

  $ ln -s /usr/bin/dbus-launch /bin/dbus-launch
  $ meld

God N is happy.  Or as happy as he gets.  Until the next problem.

One does wonder:  where did /bin/dbus-launch go?  When I updated openssl, there was a long list of dependencies that would be installed and updated—and possibly deleted—which I, like everyone else, never read.  I suspect that the dbus package was updated, which removed /bin/dbus-launch.  The lesson is, always read the list of dependencies before hitting the Y key.

Will I learn from this mistake?  Maybe.  At least this time I wrote down the answer.

---

Note:  In case you’re wondering, “ORBit” is is a CORBA 2.4 compliant Object Request Broker (ORB), originally written to serve as middleware for the GNOME project.