Third party root certificates on the iPhone

For years I've run my own web server on one of my home systems.  I've got a home automation system with a web interface, I use the web interface in Azureus, etc.  Since I tend toward security, I have it all piped through SSL.  But, when I first started, the big vendors weren't offering cheap certs for individuals.  Fortunately, along came CACert, a provider of free certs usable by anyone.  The only drawback to a CACert is their root certificate isn't installed in any mainstream browser.  So, while the actual communications will be encrypted, you'll get a message when first entering your site that the cert can't be trusted.  It's a minor inconvenience, but the fix is even simpler than ignoring the problem: On your desktop, simply browse to CACert's site and click the link for "Root Certificate".  Click the link for "PEM Format" and the browser will ask if you're sure you want to trust certs from CA.  Select the applications you want to trust and hit Ok. 

When I tried to do this in Mobile Safari on my iPhone, I kept being told it couldn't download the PEM file. So, I did some searching and I found the solution: e-mail yourself the cert.  Follow the same steps as above, but instead of clicking the "PEM Format" link, you're going to want to right-click the "DER Format" link and use your browser's method of sending links.  When you get the e-mail open the attachment, accept that you trust the cert and you'll be good to go. 

While the solution was small, can you believe I had to compile it from three different sources to get it to work right? :)

Panic mode: Missing VMDK files for an ESX guest

At my POE, we have a huge VMWare infrastructure.  About 30% of our servers are actually VMs.  This isn't just test servers, but production as well.   Last night, I was performing some routine maintenance on a VM owned by one of our support and test groups.  I was adding a second NIC to their VM so they'd be able to get on the TAN and start restoring production environments so they could duplicate issues.  A relatively simple task, I powered down the VM, added the NIC and powered back on.

 

Or, should I say...hit the power button.  The machine wouldn't come back up, I kept getting  "File not found" error.  So, I tried the logical thing, I removed the NIC and tried again. Same results.  Hmmm..  So, now, I needed to do some real investigating.  Since it was a test machine and getting very late (and I've got a bad cold), I put it off until this morning.  Taking a closer look at the event log, I found the problem: "VMware server cannot find the virtual disk /vmfs/blahblahblah".  Uh-oh.  That disk is the first image in a group of disks that makes up a 450G volume in the VM.  Did I mention this machine wasn't on the TAN, and so not backed up?

 

 I fired up Putty and did some poking around.  This machine actually has 4 disks in it.   And sure enough, all of my flat files were there, but the descriptor files were missing.  For those unfamiliar with the specifics, in newer versions of VMWare, virtual disks are actually made up of two files: disk.vmdk which is just a text file called a descriptor containing the specifics of the disk.  Size, type, geometry, etc.  There's another vmdk file, disk-flat.vmdk that is the actual flat file that holds your data.  Personally, I think it would make more sense if they used different extensions, but that's just me.

 

I did some poking around and found that disappearing descriptors is a relatively common problem these days.  The solution is relatively easy, but not something *I* could do easily.  I had to create a new virtual disk, copy the descriptor from it and just edit it to point to the right flat file.  The problem is, the first disk that was missing its descriptor is 250G and I've got 50G free on this standalone host.  I'd have to recreate on another host, copy over, etc.  But, at the last moment I found this:

 

esXpress Stub Generator

 

Simply enter the size in bytes of the flat file (copy...paste) and the name of the flat file (copy...paste) and it generates a new stub that you can...you guessed it...copy, paste into VI on the host.  I took a moment to try recreating a couple of vmdks that I did have, just to make sure I got exactly the same results using this tool.  I'm not sure if it makes a huge difference or not, but esXpress generator always populates with the line:

 

ddb.toolsVersion = "0"

 

And, all of my descriptors have this one:

 

ddb.toolsVersion = "7299"

 

I don't think it would've made any difference, but I edited all of mine so the version number was 7299.  Fingers crossed, I powered up the VM and it came right up.  Chkdsk found no errors on the volume, and we're back in business.   Thanks so much to esXpress.  You saved me a ton of work this morning!

 

 

Automated Active Directory Distribution List Creation

One of the skills that I've found to be most helpful in my day-to-day as a Windows admin is knowing how to script well.  One of the running gags from most Unix guys is that Windows is completely unscriptable.  They forget, of course, that any scripting language that runs on their OS of choice most likely works on mine.    That being the case, I generally stick to one of the VB variants when doing what I need to do.  I stick to them for a couple of reasons, most particularly that they're very easy to use and learn.  I've also found that most situations I might encounter have been overcome by someone else and I can count on one hand the number of times I've encountered a solution that wasn't written in VB or VBscript (most often it's C# or Powershell).  

The latest little project to cross my desk was a need to create almost four dozen distribution lists in AD.  I could've done them all by hand, but usually it's easier to write a script.  To that end here's my solution, with a bit of info on how it works. 

' Setup some variables for use later on.
strParentDN  = "ou=DistributionGroups,ou=Exchange,dc=domain,dc=com"
strGroupName = "THE_" & Wscript.Arguments.Item(0) & "_DAEL"
strSMTP = strGroupName & "@domain.com"
Const ADS_GROUP_TYPE_UNIVERSAL_GROUP = &h8

set objOU = GetObject("LDAP://" & strParentDN)
set objGroup = objOU.Create("group","cn=" & strGroupName)
objGroup.Put "groupType", ADS_GROUP_TYPE_UNIVERSAL_GROUP
objGroup.Put "sAMAccountName", strGroupName
objGroup.MailEnable

' Here I'm going to "finalize" some of the settings for the DL.  The reason for this
' is I've found that until a group is created and mail enabled, you can't set an
' SMTP address for it.  Guess it makes sense...
objGroup.SetInfo

' But, since the group's already opened as an object, I can simply continue
' to add attributes to it.
strDN = "cn=DL Management,ou=Groups,dc=domain,dc=com"
objGroup.Put "mail", strSMTP
objGroup.put "targetAddress", strSMTP

' This says who can add/remove members from the group.  But, read on...
objGroup.Put "managedBy", strDN
objGroup.SetInfo

Set objShell = CreateObject("Wscript.Shell")

' If you look on the Managed By tab on the DL's Properties sheet, you'll see a checkbox
' "Manager can update membership list".  Just because you've given a user (or in this case a group)
' management of that list doesn't mean they can manage the membership.  Now, we could do this
' the right and approved way, which involves setting up DACLs and ACLs for the object
' and all kinds of other voodoo.  I find it's easier to just use some of the tools provided by MS.

strCMD = "dsacls " & "cn=" & strGroupName & "," & strParentDN & " /G domain\dlmanage:WP;member"
objShell.Run strCMD

' Let the user know it worked!
Wscript.Echo "Successfully created mail-enabled DL."

Not much to it, but someone might find it useful.  And, it certainly demonstrates how easy it really is to script AD.   19 lines of actual code to create 47 distribution lists.  I guess that's a fair trade!