IT

Migrating an iPod or iPhone to a new computer

Posted by Admin on May 02, 2010
IT / No Comments

So I mentioned in a previous post that I recently upgraded the hard drive and reimaged my MBP with Snow Leopard.  There have been a few headaches along the way, but none that couldn’t be worked through with google and a little tenacity.

The latest issue is: how to sync iPhone and iPod to the newly imaged computer?  Thanks to parasitic organizations like the RIAA, the manufacturers of mp3 players have to design the devices so that music can be uploaded to, and not downloaded from the device.  This has been standard operating procedure since the aforementioned parasitic RIAA sued the Diamond corporation after it introduced the first commercial quality mp3 player.  They claimed that it could be used to distribute copyrighted materials.  They used the same argument used against VCRs in the 1980s, but Diamond settled by making the device writable to by not readable from, so they would be able to release their product.  I digress.

Continue reading…

MAC OSX and remembered wireless networks

Posted by Admin on April 07, 2010
IT, Travel / 1 Comment

So I just upgraded the hard drive in my generation-1 MacBookPro, from the 160GB that it came with to a groovy new 500GB drive.  I took advantage of the opportunity to do a clean install of SnowLeopard; I figured that enough people have probably struggled through getting their old apps to work on the new OS that I could probably quickly Google whatever didn’t just work for me right from the get go.  Well, I needed to install new versions of most apps for them to work right.

An unfortunate and secondary effect walking around with a pristine and clean new install was that all the previously memorized WiFi networks (and encryption keys) were all lost.  Fortunately, I still have my original 160GB drive as an external USB.  It turns out that all the previously “remembered” WiFi networks are basically in an XML format in the following .plist file:

/Library/Preferences/SystemConfiguration/com.apple.airport.preferences.plist

Simply recover that file, drop it in the correct path (you’ll have to use sudo if you’re a command-line jockey) and *bang*… it works.  Unfortunately, you can’t simply extract the WEP or WPA credentials, they’re stored in some <key> format.  *sigh*

Still, this saved me a lot of time and headache!

How to convert a .dmg file to a .iso file

Posted by Admin on November 07, 2009
IT, Personal / No Comments

As always, googling found the answer to my problem, and to save myself having to look for it again, I figured I’d document it here.

Open a terminal window and:

hdiutil convert /path/to/mac_image_file.dmg -format UDTO -o /path/to/standard_image.iso

How to use a Netgear WGR614 wireless router as a bridge

Posted by Admin on October 04, 2009
IT, Personal / 6 Comments

WGR614The short answer, don’t plug your uplink into the internet slot, instead plug it into one of the four internal ports. This page on Netgear’s web site does a so-so job explaining, but the diagram is pretty good.

Before you do this, make sure you’ve configured the LAN IP of your WGR614 to be a member of your IP network, preferably with a Static IP rather than as a DHCP client, so you can find the device later should you want to admin its setup.  Technically though, that’s not really necessary as a network bridge will simply pass the traffic regardless if it is addressable or not!  This can make your Access Point very secure by only being addressable on another logical IP network (although security through obscurity is probably not the only thing you should rely on).  Also, don’t forget to deactivate the built-in DHCP server, unless you actually want to use it in which case make sure your DHCP scope is consistent with your existing network and doesn’t overlap with the scopes of other DHCP servers… but if you’ve read this far and know what I’m talking about, you probably knew that.  We can simply ignore the WAN setup since it’s not at all used.

If you’re at all curious why I did this, here’s the full story…

Continue reading…

Tags:

OpenFiler and ESX

Posted by Admin on July 09, 2009
IT / 4 Comments

So I decided it was finally time to set up a little ESX cluster with OpenFiler. Everything was going smoothly until it came time to configure OpenFiler… being that I’m not a storage guy. Then the OpenFiler people seem to want to make money off selling the admin guide. *sigh*. Fortunately, there is a *great* little howto here. Thank you Lee Wynne.

Then I got the first ESX host connected no problem, but the second wasn’t connecting despite every bit of troubleshooting I tried. Fortunately, it seems that other people have not only done this before me, but they’re smarter than me. Crumpuppet figured it out here. (scoll down into the thread.) Basically, it looks like a bug – either with ESX or with OpenFiler.  The fix is in the /etc/initiators-allow and /etc/initiators-deny files, a TCPwrappers sorta way of controlling access by iSCSI initiators. It basically only lets the first one in and rejects everything else. Nice. I wasted 2 hours of my life on this one. The fix, in a nutshell:

I was scratching through the openfiler settings on the console, and found two files – initiators.allow, and initiators.deny. I did a couple of tests on OF in adding initiators to the local network. When adding one, it added an entry for it in the “allow” file, as you would expect.

But – the deny file had one single entry that looks like this:

iqn.2006-01.com.openfiler:tsn.6ef258ca57df ALL

I figured, the allow one gets processed after this one, so my “allowed” initiators will be given access anyway. This was not the case. Every time I made a change to the list of initiators on the OF web interface, this line was added to initiators.deny. I put a comment in front of it and restarted the iscsi-target service. I finally managed to discover my iSCSI target on my esx hosts.

So remember to check these files! If you also have the “ALL” line in initiators.deny, just put a # in front of it, and run:

service iscsi-target restart

This will probably have to be done every time you add a host. I’m not prepared to write-protect the initiators.deny file for in case OF cries about it, but can anyone think of a fix for this?

I recommend you read the entire thread and consider the security implications of this hack. For now at least, I’m up and running.