June 2011

You are currently browsing the monthly archive for June 2011.

This post is probably old news to experienced UNIX sys admins, but I thought the information might be useful to less knowledgeable folks like me. I also hope that the resulting conversation will help uncover even more knowledge we can all put to good use.

I’ve messed around with the screen utility off and on for a while. One thing I’d never quite figured out, though, was how using screen helped with SSH sessions. I kept seeing references to using screen to help keep things running when you needed to disconnect from an SSH session. That seems like a useful feature, so I decided to dig into it and see what I could figure out.

In the end, what I figured out was this:

  • I needed to install screen on the remote host(s). In my case, the remote hosts were OpenBSD (I removed the secret back doors), so a quick pkg_add corrected that issue.
  • I had to recreate my .screenrc file on the remote host(s). Fortunately, my .screenrc is very simple—it only enables the ability to use the iTerm2/Terminal scrollbar to scroll back and increases the scrollback buffer—so that was no big deal.

With these changes in place, you can then use this command to connect to a remote host:

ssh -t <server.domain.name> screen -R

On the first connection, this command will create a new screen session. When you’re done with this SSH session and want to disconnect, just detach from the screen session (typically using Ctrl-a d). That also disconnects the SSH session, but here’s the kicker: your screen session is still running—as are any processes you had running in that session.

When you go to reconnect, use the same command again and it will reconnect you to your existing screen session and you’ll be right back where you left off. Pretty handy!

<aside>By the way, the -t in the SSH command is necessary; without it, you’ll get a “Must be connected to a terminal” error message and it won’t work properly.<aside>

I’m sure this barely scratches the surface of the useful tricks one could perform using screen, so I challenge any and all readers to submit other useful tricks in the comments below. Or, if there is a better way of doing what I’m discussing in this article, please speak up!

Tags: , ,

Last July I wrote an article about editing the vmware-view.rdp file inside the VMware View Open Client for Mac OS X in order to customize the RDP settings. It was one of those articles that I thought would probably appeal to only a very small group but would otherwise go mostly unnoticed.

As it turns out, one reader named Patrick Fergus picked up on that article and started experimenting with it to see if he could enable printer redirection using a similar technique. I’m going to share his findings here, but with one disclaimer: I haven’t actually tested this process myself.

To make printer redirection work on a Mac using the VMware View client, two things need to happen:

  1. First, you need to install the HP LaserJet 4350 PS driver (not the universal driver) on the Windows VMs being used by VMware View.
  2. Second, you need to edit the vmware-view.rdp file to enable printer redirection.

I’ll leave the first task as an exercise for the readers, but for the second task I’ll provide a bit more detail. To enable printer redirection, edit the vmware-view.rdp file and add these lines:

<key>PrinterRedirection</key>
<true/>
<key>RedirectPrinter</key>
<string>all</string>

Once you have the LaserJet 4350 PS printer driver installed on the Windows VM and have this text in the vmware-view.rdp file, printer redirection from the Mac VMware View client should work as expected.

Keep in mind the caveat that I pointed out in the original article: changing the vmware-view.rdp file will affect all connections using the VMware View client, not just one particular connection. It would be great to be able to enable/disable this sort of functionality on a per-connection/per-server basis.

Great work Patrick, and thanks for sharing the information with me. As always, comments are invited!

Tags: , , ,

I’m very fortunate this year to have the opportunity to attend Cisco Live in Las Vegas. This will be my first year at Cisco Live and I’m really looking forward to taking in a lot of new information. I do plan on live-blogging and live-tweeting (is there any other kind of tweeting?) the event to provide as much coverage as possible for my readers.

With that in mind, here’s my schedule for Cisco Live. When I’m not in sessions, I’ll be at the EMC booth. At any point along the way, feel free to stop me and say hello. (And yes, if you have one of my VMware vSphere books with you, I’ll be happy to sign it.)

Monday, July 11

9:30 AM: BRKCRS-2031, Multilayer Campus Architectures and Design Principles
12:30 PM: BRKMPL-1101, Introduction to MPLS

Tuesday, July 12

8:00 AM: BRKCOM-3002, Network Redundancy and Load Balancing Designs for UCS Blade Servers
10:00 AM: GENKEY-4700, General Keynote and Welcome Address with John Chambers
12:30 PM: BRKDCT-2081, Cisco FabricPath Technology and Design
4:00 PM: BRKCOM-2002, UCS Supported Storage Architectures and Best Practices with Storage

Wednesday, July 13

8:00 AM: BRKSAN-2047, FCoE – Design, Operations and Management Best Practices
10:30 AM: GENKEY-4701, Cisco Technology Keynote with Padmasree Warrior
12:30 PM: BRKCOM-2005, UCS Fabric and VMs – Extending FEX to VMs in UCS
4:00 PM: BRKVIR-3013, Deploying and Troubleshooting the Nexus 1000V Virtual Switch

Thursday, July 14

8:00 AM: BRKDCT-3060, Deployment Challenges with Interconnecting Data Centers
12:00 PM: BRKSAN-3707, Advanced SAN Services
2:30 PM: GENKEY-4702, Closing Keynote with William Shatner
4:00 PM: BRKDCT-9131, Mobility and Virtualization in the Data Center with LISP and OTV

That’s my schedule as it currently stands. If anyone has any feedback on sessions that perhaps I should consider instead of the ones listed above, please let me know! There’s so much information available in so many different sessions it was hard balancing all my interests. As it was I had about half a dozen sessions that I still wanted to attend but couldn’t due to schedule conflicts.

Tags: , ,

Trying iTerm2

In 2007 I posted an article about iTerm, an open source terminal application for Mac OS X. At that time, I gave up on iTerm and switched back to the Apple-supplied Terminal.app. For a while, it seemed as if iTerm was stagnating and development had stalled.

However, I recently learned that some developers forked the original iTerm to create iTerm2. Like the original iTerm, iTerm2 supports AppleScript and tabbed terminals. The tabbed terminals I don’t really care about (I don’t use tabs, generally speaking), but I do like AppleScript support (in case you hadn’t picked that up already). There are also some other interesting features: split panes, a Visor-like window accessible via hotkey, and Growl support.

So I installed the latest build of iTerm2, and so far it’s been very stable. My only complaint has been that you can’t configure iTerm2 to spawn new windows instead of new tabs by default. Key point: I started using the Remote Hosts plug-in for Quicksilver (great plug-in, by the way). Once I reconfigured iTerm2 as the handler for ssh:// URIs, the plug-in stopped spawning Terminal.app windows and starting spawning iTerm2 tabs instead. Unfortunately, I haven’t been able to figure out how to tell it to spawn a new iTerm2 window instead. (Feel free to chime in with ideas.)

I also whipped up a quick AppleScript that I can invoke with FastScripts; the purpose of this script is to open a new iTerm2 terminal window at the same directory as the frontmost Finder window.

I’m going to continue to work with iTerm2 as my primary terminal application for a while to see how it works. If anyone has any tips or tricks to share, please add them in the comments below. Thanks!

Tags: , ,

Chris M Evans (@chrismevans) aka The Storage Architect recently posted an article on his site titled “VAAI – Offloading or Maintaining Control?” The article was a follow-up to a discussion with Nigel Poulton (@nigelpoulton) at HP Discover 2011.

The basic premise of the article as I understand it was a discussion of whether the introduction of VAAI (vStorage APIs for Array Integration), while it does bring benefits to the storage layer, also gives VMware more control. Quoting from the article:

In comparison to NFS, it seems that by implementing VAAI features, VMware are looking to retain even more control over the storage layer than before.

At first glance, it would seem that this conclusion is logical: VMware is using its popularity and large market share to force storage vendors to write to their proprietary “array integration APIs”, thus giving them another layer of control over the storage layer. VMware is the one pushing these integrations, so it seems like a reasonable conclusion, right?

The problem with this conclusion is that it overlooks one simple fact: the vStorage APIs for Array Integration aren’t APIs at all; in fact, they are nothing more than standard SCSI commands. That’s right: VAAI is composed of standard SCSI commands that have been defined and approved by the INCITS T10 committee. (If you’re interested, you can get details on the commands in the SBC-3 standard available from the T10 website.) Any hypervisor or OS running any file system on any array could leverage these commands and their functionality. There’s absolutely nothing specific to VMware or VMFS, VMware’s proprietary clustered file system, that would grant VMware any level of control. Microsoft could add support for these T10 commands and Hyper-V would reap the same benefits as VMware. The open source community could add support for these commands to Xen or KVM, if they so desired, and they would receive the same benefits that vSphere receives.

The flip side is true, too: there’s nothing in any of these SCSI commands that grants a storage vendor a level of control, either. NetApp, EMC, HP, HDS, Dell/Compellent/EqualLogic—anyone of these vendors could (and many did) implement the commands and would support them regardless of the software running on the host.

In my mind, the fact that these commands are completely hypervisor- and OS–agnostic (meaning that any hypervisor or OS could implement them) completely deflates the theory that VAAI gives VMware another form of control at the storage layer.

What do you think? Speak up in the comments.

Tags: , , , ,