OSX Lion Dashboard and Dock

So having recently rebuilt a couple of machines recently I was missing a few of the tweaks that I’d used in the past, so here for my future reference are the commands required to disable the Dashboard and also make the Dock appear to be flat.

Using Terminal (which can be found under applications->utilities):

$ defaults write com.apple.dock no-glass -boolean YES
$ defaults write com.apple.dashboard mcx-disabled -boolean YES
$ killall Dock

And to re-enable

$ defaults write com.apple.dock no-glass -boolean NO
$ defaults write com.apple.dashboard mcx-disabled -boolean NO
$ killall Dock

RVM, Lion and XCode 4.2

Maybe the dullest subject line ever but it took me a while to get Ruby 1.9.3 installed on my laptop and so here to help me in the future is the secret sauce.

This is all on a Lion based machine (clean build, not an upgraded machine)

Download and install XCode from the AppStore (Which is easier these days now that the latest version actually installs itself, rather than just downloads.
Install RVM:
$ bash << (curl -s https://rvm.beginrescueend.com/install/rvm)

Update your .bash_profile
$ echo '[[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm" ' >> ~/.bash_profile

Reload .bash_profile (or close and re-open terminal)
$ source .bash_profile

Install Ruby 1.9.3
$ rvm install 1.9.3 --with-gcc=clang

Set Ruby 1.9.3 to be your default
$ rvm --default 1.9.3

And check using
$ ruby -v

And then install Rails
$ rvm install rails

Update: Since originally writing this post I've switched to using JewelryBox instead, a nice GUI that makes the whole process a lot easier. (Especially if you need to develop off different versions of Ruby for whatever reason)

Adding an SSL cert to an Amazon ELB

So recently I needed to add SSL capability to an Amazon Elastic Load Balancer (ELB) which actually meant :

– Get the certificate, having created a new CSR and Private key on the machine of your choice
– Uploading the Private key, CSR and Certificate into Amazon using Amazon Web Services (AWS) Identity and Access Management service (IAM)

So the first challenge was getting the command line tools and creating the relevant identity files.

Download the AWS command line tools and put them somewhere you want to use them from, I put them in /use/local/IAMCLI which I then added to my .bash_profile using the settings below (this bit is optional, but makes your life easier):

# Added for AWS CLI
export AWS_IAM_HOME=/usr/local/IAMCli
export PATH=${AWS_IAM_HOME}/bin:$PATH
export AWS_CREDENTIAL_FILE=${HOME}/path_to_credential_file/credential_file

The AWS_CREDENTIAL_FILE is as below and the information to put in the file you get from the “Security Credentials” tab under your account settings, add in the ID of the access key you want to use, and click on “show” to reveal the key to use, create the file and ensure you put it in the location you added into your .bash_profile. Observant people will notice this doesn’t work if you deal with multiple AWS accounts, you can always use the optional -aws-credential-file when using the command line tools to point to the credential file you want to use.

AWSAccessKeyId=STUPID_LONG_ID
AWSSecretKey=Stupid_long_key

To upload the certificate:

$ iam-servercertupload -b public-key.pem -c .cert-chain-file.pem -k private-key.pem -s domain.name

To check the certificate is in place:

$ iam-servercertgetattributes -s domain.name

And should you need to delete the certificate:

$ iam-servercertdel -s domain.name

Now when you create the ELB, select “Secure HTTP Server” from the common applications list and save, then when you continue to the next page you should be given the option to “Choose from your existing SSL Certificates”

Adobe Air

So for a while I’d had issues with Adobe Air applications sometimes working other times not, and due to the infrequency with which I used Air based applications I had largely ignored the problem, however today I need to use Mockups and this I meant I had to fix the issue.

The solution turned out to be pretty simple, uninstall Air (for good measure) and then install Mockups, simples.  So open a terminal session and use the following:

sudo /Applications/Utilities/Adobe\ AIR\Uninstaller.app/Contents/MacOS/Adobe\ AIR\ Installer -uninstall

Enter your password when prompted and a few seconds later you get:

Uninstalling Adobe AIR (all versions)
done

Re-install Air, install Mockups, get creative ;-)

Why the dull post on something so simple, well I’ve had to do this several times now and always have to Google for the best way to uninstall Air on OSX so this time I’ve posted here to help me out.

Zimbra Upgrade (Take Two)

Ok going from 6.0.2 -> 6.0.5 NE on RHEL 4.x (Yes I know that the next major version won’t support 4.x) and I was hoping for a nice smooth upgrade, the previous SSL Comercial cert problems now showing as fixed in the bugtracker, however at the end of the process and I’m getting the same “Expired Cert” warning messages from email clients and the like….

So as root

cd /opt/zimbra/ssl/zimbra
/opt/zimbra/bin/zmcertmgr deploycrt comm commercial.6.0.2/commercial/commercial.crt commercial.6.0.2/commercial/commercial_ca.crt

Restart the services using ZMProv and all is good.

VMWare Server Build

Well with the snow came the abuse of the company VPN (will post more about that later) and some sofa / server time.

The least shocking element was the amount of work I could get down with a 3 year old and 6 week old in the house, easier to work from the sofa (no office yet) and less distractions than being the office…

So it was time to build some servers, I’ve got SonicWalls Global Management System and ManageSoft all requiring servers, also as we change things around the way we build and use servers will be changing, so I had three servers to build, (well four when we take into account the new development server for the in house digital team)

1) Windows 2K3 (64Bit) and SQL 2K5 Server for ManageSoft and SGMS usage
2) 2 x Windows 2K3 (32Bit) for ManageSoft ECM and SGMS
3) RHEL 5.4 Server for dev.

The windows servers were pretty simple. Build a new server, fully patch, then clone to a template, then join the server to AD with it’s new name and carry on with the specific requirements for the server.

Next server.
Use the fully patched template you’ve just created for your shiny new server, join to AD and you’re done, new server in under 10 minutes, sit back and rejoice at your new power…. repeat.

Three servers created in the time it would take you to create one new server.

Did the same with RHEL, so now I have my four new servers and three templates to enable me to deploy a new instance in under 10 minutes.

Nice having uninterrupted time to get stuff done – also printed out the manuals for the NSA2400 / SGMS / SSL-VPN, time to get reading…. and shortly re-configuring the NSA to make the most of the new power (before deploying to the other new NSA units via SGMS…)

“I have a cunning plan m’lord…”

OSX Migration

So it was time to replace the home Mac Mini, it had done sterling work as the main home machine serving as a home for all of our photos, music and used for general surfing, but it was certainly slowing down, the upgrade to Snow Leopard had gone well and helped prolong its life but the signs were there, time for something new and shiny.

The Mini was sitting on top of 2 x 1Tb Iomega Minimax drives which gave a useful number of extra USB boots and made for a neat tower / shrine. One drive was data the other was the time machine backup, but things had moved on, I now had a QNAP TS-439 with 4 x 2Tb (1863Gb Actual) drives installed and configured as RAID 6 (3664Gb usable) so there was plenty of storage to be had and the potential ability to recover from two drives failing.

I configured a number of iSCSI targets and using the Studio Solutions GlobalSAN iSCSI initiator connected up. This was a very simple, one minutes process and having done the same under Windows using the MicroSoft iSCSI initiator I know which I’d prefer to use in future.

I copied the data across into the relevant targets, music, photos and then setup backup using time machine to do the applications, user account and everything else other than the music and pics. To ensure everything worked I quickly re-opened iTunes and iPhoto and changed the library to the iSCSI targets, all was working lovely. Time taken to setup, 10 minutes, time to copy the data about 4 hours in total.

Now the migration, shut down the mac mini, spend an hour moving all the kit around and tidying up the wires and then for the moment of truth. Fire up the new mac, register and ignore the migration assistant for now. Once the mac is running I downloaded the initiator and installed, setup the connections to the iSCSI targets, open iPhoto and iTunes and point the applications to the iSCSI data and all was good. Just the application migration to go.

I opened up the ever so handy OSX Migration Assistant, pointed it at the time machine backup and recovered the old account data and applications on to the machine as a new account, logged out, logged in as the recovered account and the migration was done.

Work done, about 10 minutes, time taken 5 hours of data transfer backwards and forwards.

Job done, no problems and no fuss, technology as it should be.

Zimbra upgrade

Note: I originally posted this on a different website, but have since re-purposed that site, and having had this post help me out twice I figure it was worth keeping ;-)

Update: Bug 41683 is now showing as fixed in 6.0.4

So last night was the chosen time to upgrade the Zimbra install at work, all offices were shut, most people shouldn’t be working and if they were then an hour without email shouldn’t be too much to have to cope with.

With offices in San Francsico and also Dubai the time when server changes that impact everyone can be made is from midnight Friday through to 05:00 on Sunday morning (Dubai has Friday and Saturday as its weekend)

All seemed to go fine with the upgrade until I checked the installed certificate, this had reverted to an earlier, now expired cert.  Using the admin interface to attempt a reinstall with newer server certificate failed with:

Invalid Request
Message: invalid request: missing required attribute: server Error code: service.INVALID_REQUEST Method: GetCertRequest Details:soap:Sender

So a quick hunt around the support forums, a bit of googling later and with no obvious answer found (and an impending deadline) it was time to log a support ticket.

Shortly the landline rang and it was time to give over access of the mail server to Zimbra support to have a look and fix the problem. 10 Minutes later and all was sorted.  It was a known bug (42216 / 41683) which is due to be fixed in 6.0.4

However the interim solution is to redeploy the commercial cert.
cd /opt/zimbra/ssl/zimbra/commercial
/opt/zimbra/bin/zmcertmgr verifycrt comm ./commercial.key ./commercial.crt ./commercial_ca.crt

Then if all looks good:
/opt/zimbra/bin/zmcertmgr deploycrt comm ./commercial.crt ./commercial_ca.crt

And you’re back up and running with the correctly installed commercial certificate.

Hopefully this is useful to someone, will probably need this again for the 6.0.3 upgrade

VMWare-tastic

So I finally managed to spend some time over the last few days on sorting out the 7 VMWare servers we have in the London (Main) office and more specifically get a free server available so that I could retire a VMWare server that couldn’t be upgraded to the latest version of VSPhere.

Course of action was simple.

– Install a new management server as a physical machine
– Move all existing VMWare servers under the control of the new management server
– Profit.

Not quite that simple, until I had upgraded a server to VSPhere it couldn’t be managed by the new VCenter Server as it didn’t have the old 3.5x license server running.

So it took a bit of moving instances around the various servers and gradually upgrading all servers to VSPhere.

Once I’d worked out the correct order to move all of the servers around without killing anything it was time to get started, I moved all of the already upgraded servers under the control of the new VCenter Server, and then migrated the BDC and PDC from VMWare servers that needed upgrading, this meant I was left with two 3.5x boxes to upgrade one of which was running the old VCenter Server with the 3.5 license manager.

I shut down the old VCenter Server and migrated into on to an already upgraded VMWare Server then set to work upgrading the last two servers.

All very simple, just required a bit of planning to ensure I didn’t end up with a 3.5x server that I couldn’t do anything with as the license server wasn’t available (I’ve got around this issue before using an emergency local license but it is a problem best avoided.)

So I now have 7 VMWare servers all running the latest version of VSPhere (well 3 of them will be auto updating using the update manager over the weekend) and a physical install of the Virtual Center Server.

I’m happier that the main management machine is a physical box as it makes life easier doing updates.

Now to set about getting in the extra kit to go HA ;-)