Continue reading ‘The Stars Died So That You Could Be Here Today’ »]]> This is my favorite quote for this dark, rainy time of year…

The amazing thing is that every atom in your body came from a star that exploded. And, the atoms in your left hand probably came from a different star than your right hand. It really is the most poetic thing I know about physics: You are all stardust. You couldn’t be here if stars hadn’t exploded, because the elements – the carbon, nitrogen, oxygen, iron, all the things that matter for evolution – weren’t created at the beginning of time. They were created in the nuclear furnaces of stars, and the only way they could get into your body is if those stars were kind enough to explode. So, forget Jesus. The stars died so that you could be here today.

Quote by Lawrence M. Krauss sourced from Wikiquote.

Continue reading ‘Tips for installing VMware Single Sign-on in vSphere 5.1.0a’ »]]> I’ve lost many hours of my life trying to get VMware Single Sign-on(SSO) installed for an installation of vSphere 5.1.  Here are some of the tips that I used to finally get it installed.

First a few details.  The vSphere install was on a Windows 2008 server, and the database backend was Oracle 11g.

• Read the documentation.  It’s rather long, but most of it isn’t going to be relevant to your situation.  Kudos to VMware for releasing documentation in ePub format.
• Use this link and download the ODAC drivers.  Install everything.
• Don’t use this link.  Could not get these drivers to work.
• Set your %ORACLE_HOME% and %TNS_ADMIN% system (not user) variables.   Oracle was installed on c:\Oracle, and I was installing version 11.2.0.3.20 on a brand new server.  My %ORACLE_HOME% was set to C:\Oracle\product\11.2.0\client_1, and my  %TNS_ADMIN% was C:\Oracle\product\11.2.0\client_1\Network\Admin.  Your  %TNS_ADMIN% is where your sqlnet.ora and tnsnames.ora must live.  You can copy examples from a “Samples” directory for guidance.  The tnsames.ora must be correct for the next step to work.
• Once they are installed, you’ll need to create your ODBC drivers in Windows.  The requirement is for a 64 bit system DSN.  Make sure to use this “Data Sources (ODBC )”, which is found in “Control Panel\All Control Panel Items\Administrative Tools.”  If you use this, you WILL get the 64 bit ODBC drivers, and you’ll find them in the dropdown box under “System DSN -> TNS Service Name.”
• The server must have a PTR (reverse) record.
• IIS must either be uninstalled or disabled.  I’ve disabled it.  In Windows 2008, it’s referred to as “World Wide Web Publishing Service”, not IIS.

Now that you have this done, you’re ready to install SSO service.  You want to get the newest image you can.  There have been several revisions since I started this exercise (5.1, 5.1.0a, and lastly 5.1.0a build 880471.)  There are vast difference between   each of those releases, with improvements and clarifications in each release, as it relates to Single Sign-on, and I would expect the improvements to continue.

Once SSO is installed, the only other error I ran into was a requirement that the database user have additional DBA privileges.  Should this happen, you’ll get a nice, descriptive error box with all the information you need to give your DBA.

Good Luck!!

Continue reading ‘Gmail Security 102’ »]]> Google has a very nice security feature everyone should be using.  It’s called 2-step verification.  It’s relatively simple to setup, and there is a little bit of administrative overhead, but you should do it just the same.    These instructions are for Google Apps, but they should work for everyone.

As a Google App administrator, the first thing you need to do is allow your users to enable 2-step verification.   This step is only for Google App Administrators.

With this enabled, you can now setup 2-step verification for your account.  Everything below should apply to both Google App and regular Gmail users.

Go into Account Settings

And turn 2-step verification on (it defaults to off.)

From the Account > Security, under “2-step verification”, click Edit.  Verify your 2-step verification is ON.

Now that it’s on, let’s go in and setup your access.  When you set this up, Google will send an SMS message to your phone.

From this point on, if you have a “dumb phone”, you can continue to get SMS messages whenever you need access.  I’ve got an iPhone, so this tutorial will focus on that.   You’ll need to get the Google Authenticator in the App Store.   You’ll then need to set it up with this account, and that just involves opening the app, pointing your phone at the on screen barcode, and then entering the resulting code into the web form.    You only have to do that once to set it up.  Afterwards, you’ll need to enter a code once every 30 days for whatever computer you’re on (if you check the “remember me for 30 days” checkbox.”), along with your password for access.

At this point, your Google account is secure, but you have a single point of failure.  If you lose your phone, you’ve got no way into your account.  Google is a few steps ahead of you.  First, you should add a “Backup phone number.”   This cannot be your iPhone phone number, since you’re using the Google Authenticator.  If you can, use someone close to you – your friends, your kids, your spouse.  Additionally, whoever you designate for your backup phone number should also have 2-step authentication.  If they don’t, you’re not getting the full security that this process provides.  There have been exploits.

The third, and final, way to get into your account is using Printable backup codes.  These are one time use codes that will let you get into your account.   Print two copies out and tape one to the back of your wallet, and keep the other someplace safe at home or work.   There are 10 codes on this printout, and each is a one time use code.  Be aware the next time you generate the printable backup codes, any existing codes are invalidated.

Now that google is secure, you need to get access for those apps that don’t place nice with 2-step authentication (such as the iPhone Mail app and Sparrow.)  To do that, you’ll need to get “Application-specific passwords.”

You’ll want to use a descriptive name for the password you generate.

You’ll get a long one time use password.  My understanding is these passwords don’t expire.

You may want to bookmark this page.  In addition to generating one time use passwords, it has a list of who has authorization to your account, and also allows you to revoke access (I found aol.com was authorized, for some reason.  Not any more!)  Should you lose your phone, you can remove all authorization from all devices.  Handy.

I wish I could say there was more to it.  There isn’t.  It’s remarkably easy, and seemingly robust and definitely secure.

Happy Computing!!

Continue reading ‘Why my iPad 3 has Verizon LTE’ »]]> I was thinking back to an earlier post, about AT&T’s 3G coverage. This time around, I finally had a choice to go with Verizon. It’s LTE, which is a better technology (and AT&T’s LTE is probably similar, but there isn’t LTE in Seattle for AT&T.)  Here’s the results for my new Verizon LTE iPad (ignore where it says iPhone. I’m using the same app on both the iPhone and iPad, but it’s not a universal app.)

Verizon LTE

For comparison, I went back and tested my iPhone again, now with a new 4G icon. The last time I did this, just about two years ago, I was about half a mile away from where I’m at now. Two years, and half a mile closer to Seattle, and I get this.

AT&T 4G

This is much better, but I’m in so close to Downtown Seattle that I was looking at Pike Place Market from the window of my office. For those not familiar, this is about as close to the heart of Seattle as you can be.

Now that the iPad has the same connectivity as I do at home, it’s a true take anywhere device. As an IT guy, I’m glad to be able to work anywhere (even though the iPad isn’t officially supported.)  I don’t think AT&T is quite there yet, but I expect my new Verizon LTE iPhone 5 will be.

Continue reading ‘Push SSH public keys to multiple host’ »]]> I’m starting a new job where I need to have my SSH keys pushed to hundreds of Red Hat servers. The special sauce is a command called ssh-copy-id. However, using this command requires you answering a (yes/no) question, then shortly thereafter enter your password. Painful. Here’s how push your keys without the pain.

The first problem is having to answer (yes/no) for each server. Normally you see this…

The authenticity of host 'myfirsthost.work.cainmanor.com (10.256.33.106)' can't be established.
RSA key fingerprint is fc:40:7c:de:b8:ac:a2:f5:d4:11:d0:0e:b2:77:8a:63.
Are you sure you want to continue connecting (yes/no)? yes

To stop this prompt, we need to edit your ~/.ssh/config file. Add these two lines

StrictHostKeyChecking no
UserKnownHostsFile=/dev/null

Setting your UserKnownHostsFile should only be a temporary fix. After you’ve pushed your keys, you should comment out both of those settings.

Your password is the next problem. We can solve that with sshpass. sshpass takes your password and passes it on when ssh ask for it. There are three ways to do it, all of them insecure. Read the man page and decide which of those you want to use. For my purposes I just put it on the command line – I’m on my personal machine with no other users, and only I know the passwords to the box. Don’t do this on a shared server.

Here is an example of how to push your public key one. Try it on a new server to make sure you get the results you expect.

sshpass -p 'MY_PASSWORD' ssh-copy-id gregc@new_host_with_no_keys

Now that we’ve got the prompts turned off, we’ll wrap a script around this. How you get the list of appropriate hostnames or IP’s is your business.

for X in `cat my_host_that_need_keys`
do
sshpass -p 'MY_PASSWORD' ssh-copy-id gregc@${X}
done

Happy Computing!!