Showing posts with label ITPro. Show all posts
Showing posts with label ITPro. Show all posts

Wednesday, September 2, 2009

Static Routes on Snow Leopard

Snow Leopard seems to be a mixed bag of core changes to underlying infrastructure. Adding static routes appears to be one of those changes. See the end of this post if you just want to see the new syntax.

Welcome to another sporadic and completely random tech update. This will be a short one as I just have a little bit of info to share that I couldn't quickly find on the interwebs with the google. Turns out there are some slight changes to the terminal command to add a static route.

I am currently running OS X Snow Leopard (10.6) on my work MacBook. The update was not pretty and I essentially had to completely wipe my OS X partition and start over. Along with that comes a few incompatibilities, most notably for me, MS Live Mesh doesn't work any more, which is how I had intended to get my data back onto my MacBook after I had to clean install, oops!

But here's a slightly obscure change that probably affects very few people:
The basic command to add a static route has changed slightly. I use a static route to connect to a split tunnel VPN (bad practice I know, but it's a long story).

The old command I used to use:
sudo route add -net 192.168.x.0 192.168.y.z
Appeard to work as it used to, but no traffic would actually route through the VPN tunnel. I searched around and saw no references other than a blog comment from today (Sep 2) saying the command in that how-to wouldn't work for them.

So it seemed to me that somehow the way static routes were added changed a little bit. I broke down and read the man page for route (man route) to see if I could figure anything out. Granted I never read it before so I have no idea if there was a difference, but I noticed the following optional parameters that could be used in the route command like static (indicate a static route) and interface (which tells it the interface is directly connected already). I was then able to successfully create a static route using the following command:

sudo route add -net 192.168.x.0 192.168.y.z -static -interface



Wednesday, May 27, 2009

How To: Connect a DroboPro to a VMWare ESX host via iSCSI

Originally I was going to publish an article talking about my trials and tribulations (and really rudimentary performance info) around testing a DroboPro in my work VMWare infrastructure. Well, I found myself burning a bunch of time figuring out how to just get VMWare to see the Drobo. I figured the steps were worthy of mention as there's a couple of things on the VMWare side I missed that caused issues. I opened a ticket to Drobo, but have yet heard back from them on the matter yet, so I don't know if they have it documented or not. I also didn't see anything Drobo specific on the interwebs, so I thought maybe there's others out there who would be able to benefit from my misery.

Also an apology, being as this relates to a Drobo Pro and VMWare ESX, this clearly has no business on a blog about free stuff. However, for a small business, this could potentially allow for the use of big boy technology at a fraction of the cost of enterpise class gear. (My DroboPro as configured is about 10% the cost of a similarly sized EMC unit).

Now onto the details. This article assumes you have an ESX server licensed to use iSCSI, an available NIC port, and of course a DroboPro with some drives in it.

After a little bit of reasearch and experimenting, I have successfully gotten an ESX host to talk to the DroboPro. Below are the basic steps required.

  1. Attach the Pro to a Windows or Mac desktop via USB or Firewire. Install the Drobo Dashboard per the included documentation
  2. Configure the volumes on the unit to not exceed 2TB (the limit for VMWare) using the wizard.
  3. Once attached and configured, go into the advanced settings in the drobo dashboard to configure a static IP address for iSCSI
  4. Reboot the unit and test ethernet connectivity
  5. Connect the unit to a dedicated NIC port on the ESX host either direct cable or via a switch (reccommend jumbo frames and flow control if using a switch)
  6. On the ESX host, create a new network segment for the DroboPro. Under the networking tab, click add networking, select VMKernel, click next. Select the appropriate NIC, and follow the rest of the steps to add an IP address on the same segment as the Drobo. Save the changes
  7. (This is the step that got me, as it's not obvious.) Click the newly created network and select properties. Click Add and add Service Console. Assign the Service Console a unique IP in the same subnet as the drobo and VMkernel settings. Edit the original VMkernel network to allow VMotion. Save the changes.
  8. If you are running a version of ESX prior to 3.5 you will need to add a firewall exception under security for outbound traffic for the iSCSI client. This is done for you in 3.5 and newer.
  9. Under configuration for the ESX host, select Storage adapters. Click on the iSCSI adapter then click properties in the detail window below.
  10. In the general tab of the pop up window, click configure and then check enable to turn on iSCSI. The name is not important.
  11. Under the dynamic discovery tab, click Add and enter the IP information for the drobo unit. Click OK and close the wizard. A dialogue will come up asking to rescan all storage, click no.
  12. Right click the iSCSI adapter in the adapter list and click rescan. Wait patiently this could take several minutes
  13. If all went well you should now see the number of targets change to 1. This indicates the host is successfully talking to the Drobo.
  14. In the hardware section of the configuration pane, select storage. Click Add storage. The available volumes on the Drobo should appear in the window. Select one of the LUNS and follow the wizard to configure as desired.

Saturday, May 2, 2009

Some mini updates and random thoughts

Ok, it's been a while since I've updated the blog. To my one reader, I apologize for my slacker tendencies. The family is about to embark on a vacation to Orlando for a couple nights then a 3 night Disney cruise with a baby and a really rambunctious toddler, should be entertaining. Which of course there's another week with out an article. I am planning on tweeting photos as I go (during the non-international roaming parts of the trip.) So if you're interested, play along on Twitter

In the mean time, I'm just going to throw out a few notes on the great TiVo crisis and a couple of articles I have bouncing around in my head.

TiVo crisis update: After a lot of troubleshooting which involved ripping apart the Western Digital TiVo extender (really an over glorified mybook eSATA drive) as well as the TiVo itself to run extensive hard drive tests from WD. Both tests came back clean which was odd. So that essentially left either the SATA cable, the CableCard (yikes!) or some actual hardware issue. Unfortunately the next option I had was to disconnect the extender and let the TiVo divorce it (therefore deleting all of my videos).

This test so far has proven successful, no issues, and my wife's American Idol episodes actually recorded. For some reason Idol was the first program that started showing signs of distress and it ALWAYS got screwed up after that. The unit has been crusing along for over a week with no signs of distress, so I am calling the issue as a bad SATA cable (or connector on one of the units, we'll soon find out when I order a new cable.

In the pipeline.
One the IT Pro font, I've gotten approval for the Drobo Pro to extend the Dell NAS server we use for our disk to disk backup system. Before I attach it there, I'd like to slap it on a workstation to play with it a little and get some peliminary performance numbers. Then I want to see if I can get it talking with a VMWare ESX host as an iSCSI device. If I can I'll then try to run some numbers on it vs. direct storage and our 2gbps fibre channel SAN. I don't expect a lot on the VMWare front as I think the unit will probably take a beating on I/O. But if it can actually work, it might be a good solution for guest machines that don't hit the disk system a lot or are low use type machines.

Finally, some iPhone love is in the works too. I went crazy and downloaded a ton of apps trying to win the billionth app contest (alas I lost). They were all free apps, and I've been culling the ones I deem crappy. When the reckoning is finally over, I'll write about what's left as I did find a couple of cool, or at least amusing (I'm talking about you, iPity (link opens to random review I found on Google)) apps.

That's it for now folks, time to find some sandals to pack!

Wednesday, April 1, 2009

Turn a cheap router into an easy wireless hotspot (with a few limitations)

There are a few different solutions running around out there if you have some need to run a wireless hotspot. Seeing how this is the free stuff blog, I’ll skip right over the commercial offerings, but know of course there are tons of those out there. We are responsible for providing wireless access for an entire multi-tenant office building. The goal was to have authenticated, but free, wireless internet for tenants and guests and whatnot.

We had been using the ZoneCD hotspot for quite a while. It ran on a virtual machine using a bootCD and a virtual floppy with config files, pretty small footprint, and it was a fairly stable solution. There were a couple of show stoppers with that solution that have cropped up recently. First is that it’s based on NoCatAuth which uses an annoying pop-up window to keep the user authorized against the hotspot and caused no shortage of support requests to get the stupid thing working right on strange laptops running 7 pop-up blockers.

ZoneCD was also configured to use a community authentication and configuration service, which is kind of neat and one less thing for us to worry about. The problem is that at least the free version (publicIP.net as opposed to publicIP.com, which is the paid service) is pretty much abandonware. The e-mail verification system stopped working some time ago, and now it appears the SSL certificate for the login page has expired as of Feb 2009.

Thus begun the search for a suitable replacement access point. There are a few different hotspot packages out there that offer different functionality. I looked at way more solutions than I can possibly recall and tested two different solutions, 2hotspot by Antamedia and CoovaAP.

2HotSpot is a Windows based solution which uses ICS (internet connection sharing) on a dual-homed windows XP or 2003 box. The software supports both free and paid access to your hotspot. If you require a paid hotspot, you’ll have to go through Antamedia’s payment services (paying them a cut of every transaction) or pay a fee if you wish to bring your own merchant services.

As we were rolling out free services, we didn’t require a hotspot that could handle payment options and the added overhead that went with having a deidicated Windows server to manage the hotspot. There were also a few other reasons that kept me looking around, but to be honest, I can’t remember what they were at the moment. Which brings us to:

CoovaAP is a custom firmware that runs directly on certain Linksys and other wirless routers. CoovaAP is based on a couple of different open source projects: OpenWRT for the actual router OS and Coova-Chilli to handle the hotspot duties. Coova-Chilli is the apparent successor to ChilliSpot which is a popular but no abandoned open source hotspot.

The first thing to address when going with a bult in hotspot is to make sure the router has sufficient storage and hackability to actually handle running third party software. Older incarnations of the Linksys WRT54G (revision 4 and earlier) work well for this purpose. However, Linksys downgraded the WRT line several years ago, and anything newer than revision 4 lacks the horsepower (and memory) to pull this off. Fortunately Linksys figured out they could sell the old router for more money so they rolled out the special “Linux” edition, the WRT54GL which has the same specs as the older versions of the hardware. Even the more expensive incarnation of the router can be had for under 50 bucks if you find it on sale somewhere.

The Good:

With the hardware acquired, setting up the software is painfully easy. You basically run the firmware upgrade from the Coova.org site on the router, log in, and start configuring. The firmware offers a number of different hotspot options, you can use the built in coova-chilli implementation like we did, or you can use your own ChilliSpot or WiFiDog servers. Heck you can even use FaceBook or Drupal as your authentication mechanisim.

If you go with the built-in hotspot, you have a number of options for handling user accounts. You can do a basic TOS agreememnt page with no authentication, you can allow only pre-configured users to authenticate, or you can setup a self-service registration page. Similarly, there are a few different options for where your user accounts can actually come from. The simplest option is to use a built-in flat user file, this is where self-registered users wind up. You can also use Coova’s own RADIUS/AAA service, your own Radius server (handy if you have Active Directory, but with a couple of gotchas), or even OpenID.

There are also options in the system to customize the login pages, setp a “walled garden” of allowed sites without authenticating. You can do a number of advanced features like a super-annoying top frame in all browser windows and traffic shaping when the appropriate additional components are added.

The bad:

There’s only a couple of things that really put me off about this solution. The first one is fairly minor, but it goes against completely basic security design. When you click on the link within the admin interface to view the local user database, it shows you a complete list of users with passwords in plain text. Also on the security front, there is an option to use SSL for the captive login, but it only appears to support a self-signed certificate, which means client browsers are going to freak out and throw a certificate security warning. Most providers will probably want to run simple HTTP to cut down on the panic.

The last issue I have with this thing is probably the one that really bugs me the most about a lot of open-source, and particularly Linux-based projects. Out of the box, pass-through doesn’t work for PPTP (read Windows) VPNs. After spending literally the better part of a day Googling on the subject, I gave up in utter frustration ranting about software devloped by hippies. There were two forum posts on the subject, one which was very helpful, but offered no information on how to accomplish the steps required to make this work. The other post was a quote of the first post asking if anyone could provide more info on how to follow the steps… of course there were no replies.

So… if you know the answer to this question by all means let me know, you will restore my faith in open source.

Despite its few shortcomings, CoovaAP is about as simple as it gets when it comes to setting up a wireless hotspot. I also didn’t mention that you also get to add a few advanced features to that little Linksys router thanks to the built-in functionality of OpenWRT. If you need a simple AP, and the villagers won’t hunt you down because they can’t make a PPTP VPN connection, this may be a great solution for you.

Recommendation: Buy (See what I did there, funny).

RD Tabs

RD Tabs by Avian Waves is one of those applications that I have to download before I can even thing about using my work computer to accomplish anything resembling work.

On the surface, RD Tabs is a remote desktop application that gives you a tabbed interface for multiple remote desktop windows. When you have to have multiple remote machines up on your desktop simultaneously, this thing is a godsend.

The application is also packed with other handy goodness for presenting remote windows. You can have your window dynamically sized based on the application window. You can use global settings so that every connection by default will disable audio for example. Settings can also be managed on an individual connection basis. There is also the ability to save connections as favorites, as well as a handy drop down of your most recently accessed remote desktops.

RD Tabs also supports the newer versions of the RDP protocol found in Vista and server 2k8. The application was created by a Windows administrator to handle daily admin tasks. You can grab a copy (or read more) over at http://www.avianwaves.com under the tech section. You can also check out the other applications (I’ll do a writeup on XS BAP in the future) as well as original music written and performed by the developer.

Spiceworks

We actually have a ton of system management and monitoring tools running around at the office, like MOM and some of the GFI stuff. The one we seem to keep coming back to is Spiceworks. It’s the most competively priced (Free) of them and it actually provides a ton of features and a fairly decent reporting interface.

Spiceworks can monitor any number of different things, such as disk space, up time, event logs, pings and so on. Especially on Windows boxes, it has some great inventory capability, and I often use the installed software reports to make sure the user base isn’t installing verboten items. The reporting interface is alright, there are a few things I wish it could do a little better (some of the queries are hard coded, unless you want to write the SQL yourself) and it has limited me in the kinds of reports I wanted to run.

There’s a good sized user community, and is updated very frequently as well. A number of things I’ve taken issue with in the past (such as duplicate machines) tend to go away in future releases.

The free version is ad-supported, but actually runs on your own hardware, so your intimate network data isn’t sent to the mother ship. For shops that take exception to the ad-based scheme, there is a fee-based version that removes all the ads. Either way it’s an excellent choice for a smaller shop with limited resources (that’s pretty much every small shop I think).

Really Useful SharePoint Designer Workflows

Switching gears to work stuff this morning…

CodePlex is a repository of open source code similar to Source Forge, and features a lot of code projects for Microsoft stuff. One of my favorite things form there is the Useful Sharepoint designer workflow activities (that’s a mouthful) or SPDActivities for short. This extends the built in workflow activities you can select when creating custom workflows from within SharePoint designer (which you’d be using if you were fairly serious about custom workflows, but not quite a developer using Visual Studio).

SPDActivities adds some, well, useful functionality that should be built into SharePoint out of the box. There are several including some Infopath stuff that I don’t really use. There are a few of the activities I just can live without.

My personal faves let you tinker with list item permissions, start a different workflow from within your work flow, and copy list items to lists that aren’t even on the same subsite (or even application or farm).

I tend to get completely lost if I start trying to build workflows on a farm where I haven’t installed these extensions.

http://spdactivities.codeplex.com/