Feb 16

Hack a Box To Protect Outdoor Power Supplies

Turtle case LTO-5

When installing network equipment outside, it is not always possible to have the electrical cabling and components on the interior and safe from the elements. This was the case recently for me when I installed some outdoor Ruckus Wireless access points. The buildings I am putting them on don’t have a lot of access to power inside in a way that wouldn’t look bad or be problematic from a water leak issue. So, I decided to go with using the outlets on the roof. But, because these sorts of devices feed with power-over-ethernet (PoE) I really needed to get a power injector and supply up there in a safe location.

You can buy outdoor boxes/enclosures for this sort of thing, but they are pretty pricey and you have to go to vendors you might not have internal accounts with or it is just a pain to deal with. This was the situation for me. So, my initial path was to try and build something myself or ask a student to construct something to handle the dimensions of the power supply and cables I needed to cover in my school’s shops but that would take time and I was eager to get these units up and going ASAP.

Enter the Turtle cases. I bought a few of these a while back to handle LTO media transfer back and forth on off-site backup tape rotation. Specifically, the LTO -5 blue ones. These boxes are pretty reasonable priced $35-$40. But, we have easily surpassed the amount of tapes these guys can handle now and they sat in a pile of tech stuff that was gathering dust. Turtle cases are great. They are a little bulky but that is to protect the media inside. I surmised these would be perfect to use as an enclosure for power adapters and power injectors.

I was lucky enough to have a co-worker (and Technical Arts Department Head) drill a hole in one side of the box below the ridge and attach a piece of thick rubber with a couple of cross-cuts to provide the cable access for inside (Thanks Andrew K!!) You can get much fancier here on gaskets and outlets, etc. but this should cover it for what we are doing.

Here are some pictures of the finished product.

Dec 08

Fixing OS X ‘Dark-Dock’ Without Logout

Since moving to OS X 10.6.5 and switching to 64bit, I have noticed from time to time the Apple Finder Dock can get confused. This usually happens on a right-click or control-click of an icon in the Dock to hide an application, force quit a running application or to use a contextual menu from the app icon in the Dock. This is kind of annoying. If it never happens to you, great and consider yourself lucky. If you also get hit with this every once and while, you know what I mean. You can logout to restart the Dock app or even reboot the computer to get it to restart the Dock, but here is a quick way, even if you never even use Terminal.app to quickly rectify the issue.

Here is what a piece of the OS X Dock looks like on my computer in normal mode

What the OS X Dock Should Look Like in Everyday Use

Here is what the same Dock looks like when it goes into what I call ‘Dark Dock’

What the OS X Dock Looks Like In 'Dark Dock' Mode

They don’t look all that different. Apple did this to mimic the functionality of Expose but for the Dock to try and give you some eye-candy to provide user focus on the icons you are working with which is great for the brief time you might be messing with something, but if you do have magnification on and it gets stuck you lose that as well as it feels like the Dock is frozen and waiting for you to hit an option or select something.

A quick way to restart the Dock and shake it loose is to drop into a Terminal / Console and issue a kill -HUP to the Dock process. This will stop and start the process for the Dock again and kick it back to normal. A quick way to do that is start the Terminal.app (Applications/Utilities) and then issue two commands. Pretty easy to do even if you are console-phobic.

You first need to find what the Dock process is and you can do that via this command.

ps -ef | grep Dock

It will give you the process number of the Dock process. You will need that for the second command to restart it. The process id is the second number. A command to restart the Dock process once you know the ID is

kill -HUP 187

In this example 187 is the number I got back from the first command. Here is a screenshot of my console in Terminal.app running this.

Finding the PID of the Dock then restarting it.

In the screenshot, I got 197 back as the ID of the Dock process. Then, I issued the kill -HUP 197 to toggle the Dock to get it unstuck.

Oct 15

Using Cron In OS X To Restart Symantec Backup Exec 2010 Agent

Don’t get me wrong, I am happy Symantec finally released a Mac OS X 10.6 Agent for Symantec Backup Exec 2010 but it is a little buggy. So much so, that we feel we really need to just have it restart daily on the OS X servers. Here is what we did. This is just a simple cron job.

1. Login via Terminal or SSH to the OS X server
2. su to the root user (or sudo everything if you want)
3. enter ‘crontab -e’

crontab -e on os x

4. insert (i) the cron information because there will probably not be any existing cron information in there

crontab entry for os x for the VRTSralus.init restart

Then press the ‘esc’ and ZZ to save the crontab out. The above crontab entry will restart VRTSralus.init every day at 12:15. You can set it for any time you wish that makes sense or whatever.

After ESC and ZZ to save out of crontab entry

5. You can check to see if it is actually working by going into the /var/VRTSralus directory and looking at the modification dates of the error logs and pid file.

changing directory to /var/VRTSralus

6. Doing an ‘ls’ you can see the modification date/time of the pid and log files. They both get new modification dates whenever the service is started.

VRTSralus log and PID files

So, having the server restart it every day or so seems to make it run a little more reliably. There might just be something in the code that is buggy and perhaps they can fix it next release.

Aug 09

Getting Symantec Backup 2010 R2 Agent on OS X 10.6

Symantec’s Backup Exec 2010 R2 just came out and it was a huge deal for us because we have an Xserve we have had to have on a different backup cycle because Symantec did not support it. So, when R2 was released with 10.6 support, we were eager to get it going. Only problem is, the Agent didn’t install.

After Anthony (works for me at Lick-Wilmerding) banged around on it for a while with Symantec Tech Support, there was still no resolution. We tested on my MacBook and it did install. It had to do with the kernel and 32 bit vs 64 bit. Symantec’s installrams install script checks for x86 and if it doesn’t find it, it kicks up a big ‘Not Supported’

installrams on os x 10.6 (64 bit)

So, one way we got around it was to boot the machine in 32-bit mode for the install. Get into a Terminal and then

# sudo systemsetup -setkernelbootarchitecture i386

sudo systemsetup -setkernelbootarchitecture i386

and reboot. Then re-try the agent install. It will run. After you get some confidence, in backups, etc. you can kick it back to 64 bit

# sudo systemsetup -setkernelbootarchitecture x86_64

sudo systemsetup -setkernelbootarchitecture x86_64

and reboot. The beremote process will run and you will see it as a backup option in your BE Job Creation screens.

DISCLAIMER: Messing around with system internals can cause all kind of bad stuff, so if you are not comfortable with it, there is probably a reason so don’t do it. Switching stuff like this can really do some crazy damage, so you are on your own and we just wanted to put it out there for those who are capable and willing to take the responsibility.