kill the noise

I’ve been asked by a few people how I keep up with everything going on in Twitter and Facebook.  Simple answer: I don’t.  It’s impossible, and I would completely wear myself out trying to wade through all the noise in those worlds to ever hope of finding something of value. If you want to use Facebook or Twitter as tools of communication and connectivity, you have to be intentional about killing off the noise.

Here are some guidelines that I follow to keep noise down.  If you have any to add, feel free to speak up.

On Twitter:

I use Twitter clients that allow me to sort people I follow into groups. I have 4 groups: Friends/Locals, NewPointe staff, people that I want to learn from, and CITRT folks.  Not everyone that I’m following is in those groups either, and that’s OK.  If someone posts a tweet that’s a big deal, chances are that it’ll get re-tweeted enough to the point where I’ll see it.

Rarely will I “follow back,” or follow someone simply because they started following me. You may think that’s rude and self-centered, and you’re certainly entitled to your opinion.

I turn off email notifications (except for direct messages). I mean, it’s cool that I’m getting followed by one more person, but I don’t need an email to tell me that, and it’s just as likely that someone un-followed within the same 10 minutes.

On Facebook:

My Facebook status is synced to Twitter.  Let me stress that the ONLY reason my Facebook status gets updated is because Twitter Facebook app does it for me, otherwise my feed would be a barren wasteland of “…”

I became extremely intentional about cutting the noise out of my main Facebook feed.  If someone’s feed contains a consistent array of low-to-no-value stuff (“wondering what type of ice cream to buy!”), a barrage of silly apps (“What kind of <insert_noun_here> are you?”), or if they constantly invite me to be a pirate or gangster or whatever, chances are I’ll hide them from my feed.  I’m also a big fan of “blocking all invitations” from people who love to invite their whole friends list (or spamvite) to take a quiz or become a fan of something.

I receive absolutely NO email notifications from Facebook. None. I mean, have you SEEN that list of email notifications you can possibly receive from Facebook? Good grief, you could DROWN in that amount of email. Do yourself a favor and turn that stuff off.

Adding SSL to ServiceDesk

One of this year’s short-term projects was getting our installation of ServiceDesk plus set up with SSL.  I had an opportunity do to this last night with a cheap SSL cert from GoDaddy ($25 for a 2-year cert…can’t argue with that), so I thought I’d go through the process here in case anyone wants to go this route, or in case I ever need to go this route a second time.

- cd to <ServiceDesk_Home>\jre\bin ( if you’re running Windows, ServiceDesk_Home will be commonly C:\AdventNet\ME\ServiceDesk)

- Generate your keystore:

keytool -genkey -alias <your_alias_name> -keyalg RSA -keystore sdp.keystore

Note: Your alias can be whatever you want it to be, just be sure to remember what it is because you’ll need to reference it later.  For simplicity’s sake, we’ll name the alias domain.com for now.

When you create your keystore, you’ll get a few prompts along the way.  A couple of them are worth talking about:

Enter keystore password: Put a password here.  This will allow the Tomcat web server to access your keystore.
What is your first and last name? DON’T put your first and last name here. This is actually where your common name (CN) goes.  As always with common names, use the EXACT FQDN that your users will type to access your site. (servicedesk.domain.com)

The rest of the prompts will be standard SSL questions — organizational unit, organization name, city, state, and country.

- Next, you need to generate the CSR:

keytool -certreq -keyalg RSA -alias <your_alias_name> -file certreq.csr -keystore sdp.keystore

This will generate a CSR and put the file in <ServiceDesk_Home>\jre\bin.  Use that CSR to get your cert from GoDaddy.  Make sure you select ‘Tomcat’ as your web server when downloading your certificate.

The ZIP file that contains your certificate will also contain three other files:

gd_bundle.crt – GoDaddy bundle certificate (we won’t be using this)
gd_cross_intermediate.crt – GoDaddy cross-intermediate certificate
gd_intermediate.crt – GoDaddy intermediate certificate
servicedesk.domain.com – The SSL certificate for your server

You’re also going to need GoDaddy’s root certificate.  I used the Legacy ValiCert root certificate and had zero problems.  You get get it here. Now we’re ready to start importing certificates.

- Import your root certificate:

keytool -import -alias root -keystore sdp.keystore -trustcacerts -file valicert_class2_root.cer

- Import your cross intermediate certificate:

keytool -import -alias cross -keystore sdp.keystore -trustcacerts -file gd_cross_intermediate.crt

- Import your intermediate certificate:

keytool -import -alias intermed -keystore sdp.keystore -trustcacerts -file gd_intermediate.crt

- Finally, import your server’s SSL certificate:

keytool -import -alias <your_alias_name> -keystore sdp.keystore -trustcacerts -file servicedesk.domain.com.crt

- Move the sdp.keystore file you created from <ServiceDesk_Home>\jre\bin to <ServiceDesk_Home>\server\default\conf

- cd to <ServiceDesk_Home>\bin and run the following command to change the port and protocol that Service Desk’s web server runs on”

changeWebServerPort.bat 443 https

-Finally, fire up your favorite text editor and open <ServiceDesk_Home>\server\default\deploy\jbossweb-tomcat50.sar\server.xml.  Find the single occurrence of “keystorepass” and change its parameter to the password you used when you created your keystore.

- Restart your ServiceDesk Plus installation.

That should be it.  Open up a web browser and go to the FQDN of your ServiceDesk server (don’t forget your https://)  You should get your login page without any certificate prompts. Congratulations!

One little extra I did on our ServiceDesk installation was to install IIS on the server and have it answer port 80 and forward it to https://servicedesk.ourdomain.com … that way I don’t have to tell users to remember their https, thus making the change as transparent as possible.

I hope this works for anyone who decides to use it.

WiFi-enabled thin clients for F1 Check-In

With the increase of visitors at NewPointe, we decided a few weeks ago to deploy additional check-in stations to help with traffic flow.  One of the challenges in this project was to make these stations wireless so that they could be moved as needed.

To make this happen, I ordered 4 HP t5730 thin clients with PCI expansion units, Proxim 802.11a/b/g PCI cards, and all the usual F1 Check-In goodies. Most of our office staff is out on vacation this week (which is a great time to IT guys to get projects done), so I decided yesterday to put one of the stations together so I could create a master image and also so I could document the process.

So, for your geeky reading pleasure, here is the build process for making/imaging/prepping a F1 Check-In station our of a HP t5730 thin client with WiFi capabilities.

A couple thoughts before reading:

• Fellowship Technologies does not support Windows XPe, and therefore the processes described below come with no guarantee or warranty from Fellowship Technologies or myself.  I’m just telling you what’s worked for me.
• Proxim WiFi cards are not a must.  I used them because we use Proxim APs. However, an 802.11a wireless connection is a must if you want to have any hope of F1′s Check-In app working well in a crowded room.
• I did not discover all this by myself.  Credit is heavily due to the following folks:
  • Sid Emory from Fellowship Technologies for hanging in #citrt and helping to bring all this about.
  • Justin Moore, for creating/blogging the original documentation on for F1 Check-In on t5730s.
  • Ian Beyer, for killing off several brain cells while discovering how to get .NET 3.5 to install on his t5730.

That being said, let’s get started.

1. Attach the PCI expansion unit to the thin client using the included instructions.
2. Get all your peripherals connected except for the Zebra printer…we’ll do that later.
3. Power up. Hold the shift key down when you see the Windows boot logo and keep it held down until you see a login prompt.
4. Log in as Administrator. Password is ‘Administrator’.
5. Change the Administrator password.
6. Disable the Sygate Security Agent, and don’t turn it back on. Ever.
7. Disable EWF. Commit the overlay if prompted, and reboot.
8. Log in as Administrator again.
9. Download and install drivers for your WiFi PCI card. For our Proxim a/b/g cards, I installed both the drivers and the Proxim Client utility, but elected to use Windows Zero Config to make the actual WiFi connection. It works quite well, and you can still use the Proxim Utility to get diagnostic info from the card.
10. Get your WiFi card pointed at the proper SSID. In my experience so far, once you do this with Windows Zero Config, your selection will stick even when you image the system.
11. If you need to, download and install drivers for your touch screen.
12. Download drivers for the Zebra printer. Open the self-extracting file so that you can extract the driver files, but cancel the installer program once it starts. Connect your printer via USB and use the Add Hardware Wizard to load the driver files.
13. If you want to make any other minor adjustments, this is a good time to do it. This is where I turned on SNMP and set the community string so I can monitor these units readily if the need arises. Also, go ahead and set the machine’s hostname if you’re not planning on imaging it.
14. Reboot. While you’re at it, go find yourself a flash drive that is at least 2GB. You’re about to need it.
15. Log in as Administrator again (if you logged in as User accidently, you can just hold the shift key down while logging out, and you’ll get a login prompt.)
16. Insert your flash drive and make note of what drive letter gets assigned to it.
17. In Control Panel > System, click on the Advanced tab and open your Environment Variables. Make the following changes:
    1. In User Variables, change your TEMP and TMP values to ‘d:\’ (where d: is the drive letter that was assigned to your flash drive.
    2. In System Variables, change your TEMP and TMP values to ‘d:\’ (where d: is the drive letter that was assigned to your flash drive.
18. Go to http://support.microsoft.com/ph/548 and download the latest version of the .NET Framework. Run the installer. Installation will be SLOW, but it should work. Why? The .NET install package is 200-some MB when it’s compressed, and when the install process tries to expand that payload to TEMP/TMP, it chokes up the flash drive. However, since we changed the location of TEMP and TMP in our environment variables, the installer has a whole 2GB of space to work with.
19. Go grab a cup of coffee or a Danish (or both) while the install runs. You’ve earned it.
20. Once the .NET installation is done, reboot.
21. Download and install the F1 check-in application. Do NOT start the F1 check-app after installation. From a working check-in station you need to grab “C:\Program Files\Fellowship Technologies\Fellowship One Check-in 2.5\<latest version>? and copy that over to your thin client. The folder <latest version> will be comprised of 4 numbers separated by decimals, such as “2.5.0.9”
22. On your thin client, remove any shortcuts automatically created by the F1 installer and create a new shortcut to “C:\Program Files\Fellowship Technologies\Fellowship One Check-in 2.5\<latest version>\FellowshipTech.Application.Windows.CheckIn.exe” I dropped this shortcut in “C:\Documents and Settings\All Users\Desktop” so that it was universal.

Side note: If you’re a geek (and you must be if you’re still reading), you want to know why we just did the last two steps.  Justin Moore explains it well…

By default, the F1 check-in application launches AppStart.exe which runs an update process to grab any patches/fixes from the F1 servers. This update process relies on the BITS service in Windows, which is NOT included in the HP t5730 XP Embedded image.

23. Enable EWF and reboot. Let the system automatically log in as User this time.
24. Start the F1 Check-In app and verify that it works. You’ll most-likely get an error about a printer not being available. This is because F1 defaults to LPT1 to look find a printer. Once you get to the menu, you’ll be able to select the printer you want to use. You may want to set up a “test activity” or adjust the schedule of an existing activity so that you can do just that.

Once you’ve tested everything to satisfaction, your thin client is ready to be imaged! There are a lot of different ways to go about this. I went the easy/slower route and used the HP ThinState Capture utility in the Control Panel. Do use ThinState, you’ll need a flash drive that’s 2GB or larger. Simply follow the instructions and you’ll be good to go. Also note that once you image your master machine, it will automatically sysprep on the next boot, so you’ll need to follow the prep instructions below as if you were copying the image to a new system.

When you build a new check-in station using this image, there’s some light prep work that will need to be done before it’s ready. Here’s what you’ll need to do.

1. While windows is starting, hold down the Shift key until you get a login prompt. This will give you a login prompt instead of automatically logging you back in as User.
2. Log in as Administrator using the password you picked out before imaging. (You DID change your password, right?)
3. Verify that your WiFi card is connected to the proper SSID.  It may take a minute or two.
4. Change the hostname of your thin client if you need to.
5. Right-click the EWF icon in the System Tray and select Commit.  Reboot the machine.
6. When the thin client reboots, let it log back in automatically as User.
7. Start the F1 Check-In app. You’ll be asked to verify your church. Do so and then open an activity so that you can print a couple test labels.
8. Exit the Check-In app. Log out of Windows while holding the shift key.
9. Log in as Administrator.
10. Right-click the EWF icon in the System Tray and select Commit. What this does is commit to flash any changes that were made while the system was running. This is important because the credentials you entered at the church verification screen fall into this category. If you didn’t commit this info to flash, you’d have to enter F1 credentials every time you start Check-In.

All done! Your check-in station is now ready for action.

I’d love to know whether or not this works for you, and I’d also love to know if you tweaked this process to make it better.  Drop a comment if that’s the case.

More Wi-Fi and More Check-In

Lately we’ve been faced with a great problem to have in a church: More and more people are showing up, and as a result we now have some bottleneck issues to deal with.  Call it what you will, but when systems and processes at a church need changed because more people are showing up, I think that’s a great thing!

One of the solutions we are going to implement is putting additional check-in stations in play so that more people can be checked in at once.  To add flexibility, we will be giving these new check-in stations wireless capability so that they can be repositioned as necessary.

To prepare for this, I needed to do some beefing-up of our wireless infrastructure. Until this past week we only had 2 active wireless APs in the building, which made for quite a few dead zones.  Our original plan was to add 4 Proxim AP-4000s in key areas where we would be checking people in.  Before heading to a retailer though, I did some shopping on Ebay and managed to come up extremely lucky: 6 AP-4000s for about $1900 total…you can’t pass up a deal like that!

I spent Tuesday morning updating and configuring the new APs… the ability to do CLI over serial and conduct TFTP config file downloads makes for decently-fast mass configuration, considering the fact that there’s no central management involved.  Through Tuesday night and Wednesday, cabling was pulled or repositioned to make way for installation, and by Wednesday evening 5 of the 6 new APs were up and running.

The plan for wireless check-in is to use the Proxim’s 802.11a radio to talk to the check-in stations. (If you’re curious as to why I’m not using 802.11b/g, read Jason’s post on the matter.)  Each check-in station will have a Proxim 802.11a-capable radio, as well.

I’m hoping to see out hardware coming in over the next couple of weeks.  Once we have a couple stations build and ready to go, I will come back with Wi-Fi performance results.  I’m hoping to see great things!

Disk doctor update…

I could have sworn I posted this earlier in the week,  but I don’t see it in my blog anywhere.  So, here it is for real.

Last week we were in what I could call a “very dangerous position.” … our RAID controller on our VM host began throwing PCI parity errors, which REALLY doesn’t go over well on our Linux host OS.  This past Saturday night, I was able to take the host machine down and make it right.  I shut our VMs down and copied them over to a separate disk array to keep them safe.  Once that was done I went ahead and swapped the High Point RR2320 card out for an Adaptec 3805.  The Adaptec card got very good reviews from other Newegg customers, and the price/features balance was a deal maker.

After getting the build started on the new RAID 50 array (w00t for background builds), I did a reinstall of Fedora 8, formatted the new array, and started bringing our VMs back.  After installing VMware server and the web UI, I took a deep breath and pressed the start button to begin bringing the VMs online.  I got more and more relieved as each VM came back to life, and I probably broke out in cheer once we were 100% back online.  All that was left after that was to install NRPE so that our Nagios box could monitor the health of the VM host.

Some thoughts from this project…

- This couldn’t have timed out any better… since there was no church on Sunday, I was able to take 75% of our systems down with minimal impact on our users.

- I was REALLY wrestling with the thought of trying ESXi out on the host instead of Fedora…I imagine it would have worked.  However, the ability to monitor the host’s hardware with Dell OpenManage is trump.  Although OM is not supported on Fedora, it will run if all the dependencies are satisfied.

- I’m glad we’ve got a coffee machine in the church…I wouldn’t have made it through the night otherwise.

- My initial plan was to install CentOS on the this server, but I had problems with GRUB hanging at boot time after the installation.  I went back to Fedora because I just didn’t have time to mess around.

- I’m very thankful that my fiance (or wife, depending on when you read this) understands what I do and accepts the fact that I’m passionate about this stuff.

- Our server room’s AC works very well… almost too well.  Again, hot coffee was a plus.