If you’ve read any of the posts I’ve published on my Getting Things Done setup, you’ll know that I used an application called Yojimbo as my “anything bucket.” Yojimbo is a native Mac OS X application that operated as part of the consumption phase of my workflow and provided a way for me to collect and organize all the various bits of information that pass in front of me. Yojimbo is a pretty handy application, and I made it even more handy with some home-grown AppleScripts that made it easier and faster to get information into and then back out of the application.

However, I recently started examining other applications in the same space as Yojimbo, in an effort to ensure that I was using the most effective tools possible. (Consider this a “sharpening the saw” exercise.) I evaluated DEVONthink Pro and EagleFiler, testing each of them within my workflow to see if either of them added some value above and beyond what I currently had with Yojimbo. This was occurring at the same time that I started shifting my text-based formats back to plain text, RTF, and Markdown, and so part of the evaluation process was testing how well those applications fit into this new way of managing my text-based data.

What I found, surprisingly, was that EagleFiler was a great fit for this new workflow. One of my long-time complaints of Yojimbo was that I couldn’t use my preferred applications (Skim for PDFs or TextMate for text-based files), an issue that was even more of a problem now that I was making greater use of TextMate with plain text files and Markdown. I explored ways of using AppleScript to modify Yojimbo’s behavior, but it was beyond my simple AppleScript skills. EagleFiler, on the other hand, simply leveraged the default applications I used with Mac OS X. PDFs opened in Skim, text files opened in TextMate (where I could then use TextMate bundles to convert formats between HTML, plain text, and Markdown), and RTF documents opened in Bean (which I’d adopted as a lightweight editor over the oh-so-bulky Microsoft Word). This made it a great fit for the new way I was working with documents. In addition, EagleFiler came with some useful capture functionality built-in, eliminating the need for some of my home-grown AppleScripts. Finally, EagleFiler used an “open” library format that stored my items as files in the file system. If, for whatever reason, I ever decided to ditch EagleFiler, all my information would be easily accessible. This was a real attraction for me.

So, after only a week or so of testing, I switched completely away from Yojimbo and started using EagleFiler instead. Thus far, I’ve been quite pleased with the results. While it seems simple, I like the ability to mark items as unread (something I couldn’t do in Yojimbo, so I had to approximate that functionality with certain tags). I still prefer the way Yojimbo displays metadata about bookmarks in the same window (in EagleFiler you have to open the Inspection window), but this has not been a significant problem.

I also anticipate that the use of the file system will make integrating tools like Pandoc into my workflow possible; it didn’t seem possible before with Yojimbo. Because EagleFiler’s library is file system-based, it should be possible to use AppleScript to manipulate records by manipulating the underlying files in the file system. This will be an area of exploration for me over the next few months as I also refine my Markdown-Pandoc workflows for document generation.

In my opinion, if you’re considering an “anything bucket” for your Mac to help keep your information organized, EagleFiler should definitely be on your list of applications to consider.

This article was originally posted on blog.scottlowe.org. Visit the site for more information on virtualization, servers, storage, and other enterprise technologies.

Switching to EagleFiler

• My Number One Yojimbo Complaint
• Formatting RTFs with TextSoap
• TextMate
• AppleScripts for Yojimbo, Camino, and Skim
• Revisiting Evernote

I can’t take credit for all of these; most of them were shared with me by Matt Cowger, fellow VCDX and vSpecialist.

If anyone has any additional commands they’d like to share, I encourage you to add them to the comments on this post. Enjoy!

To find the IP address of the default gateway:

netstat -nr -f inet | grep default | grep en | awk '{print $2}'

To find the interface name of the default route:

netstat -nr -f inet | grep default | grep en | awk '{print $6}'

To find the IP address assigned to the interface for the default gateway:

ORGGWIF=`netstat -nr -f inet | grep default | grep en | awk '{print $6}'`
ifconfig $ORGGWIF | grep "inet " | awk '{print $2}'

To find the default gateway network:

ORGGWIF=`netstat -nr -f inet | grep default | grep en | awk '{print $6}'`
netstat -I $ORGGWIF -n | grep -v : | grep $ORGGWIF | awk '{print $3}'

To find the subnet mask for the default gateway network:

ORGGWIF=`netstat -nr -f inet | grep default | grep en | awk '{print $6}'`
system_profiler SPNetworkDataType | grep -A 15 $ORGGWIF | grep "Subnet Masks" | awk '{print $3}'

To convert the subnet mask into CIDR format:

ORGGWIF=`netstat -nr -f inet | grep default | grep en | awk '{print $6}'`
ORGGWMASK=`system_profiler SPNetworkDataType | grep -A 15 $ORGGWIF | grep "Subnet Masks" | awk '{print $3}'`
echo obase=2.$ORGGWMASK | tr . \; | bc | tr -d 0\\n | wc -c | awk '{print $1}'

To determine the wireless SSID to which your Mac is currently associated:

/System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport -I | grep SSID | tail -n 1 | awk '{print $2}'

CLI gurus and wizards are encouraged to share other useful commands in the comments below. Thanks!

This article was originally posted on blog.scottlowe.org. Visit the site for more information on virtualization, servers, storage, and other enterprise technologies.

Some Useful UNIX Commands on your Mac

• Changing the IP Address in Solaris 10 U3
• Configuring Inter-VLAN Routing
• Modifying DHCP Client Operation on OpenBSD
• A Couple GeekTool Scripts
• A Quick and Simple Guide to Building an OpenBSD VM

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!

This article was originally posted on blog.scottlowe.org. Visit the site for more information on virtualization, servers, storage, and other enterprise technologies.

Using GNU Screen with SSH

• Trying iTerm2
• VMware Weak Spot
• Giving iTerm a Try
• VMware HA Problem with Update 3
• Details on Transparent RDP Tunneling

That’s why I was surprised when word surfaced that I had been implicated in some sort of conspiracy regarding a plan to place secret backdoors into an OpenBSD cryptographic framework, and that my recent advocacy of OpenBSD was based on my alleged involvement with the FBI.

I don’t know where the person who started this rumor got his information, but he is sadly mistaken regarding my involvement. Perhaps the other Scott Lowe is involved; I don’t know. What I do know is this: I’m not affiliated with, supported by, employed by, associated with, or in support of the FBI in any way, shape, form, or fashion. Quite simply, it wasn’t me.

Feel free to post any additional questions or courteous comments below. I’ll answer all relevant questions openly and honestly.

This article was originally posted on blog.scottlowe.org. Visit the site for more information on virtualization, servers, storage, and other enterprise technologies.

Allegations Regarding FBI Involvement with OpenBSD

• No, Not That Scott Lowe
• Not the Same
• A Quick and Simple Guide to Building an OpenBSD VM
• TA2259 Ask the Experts at VMworld 2009
• OpenBSD 3.8

Note that in order to use this command, you’ll need your bit.ly API key. Your API key is easily accessed from your account settings page.

Here’s the command I tested (works on Mac OS X 10.6.4):

curl 'http://api.bit.ly/v3/shorten?login=<bit.ly login>&apiKey=<bit.ly API key>&longURL=<Long URL to be shortened>&format=txt'

In order to make this truly usable, there are some additional things that have to happen. The long URL has to be properly encoded, as it can’t have any spaces or special characters, for example. But otherwise, this command is a workable solution to shortening a URL from the command line. All I need now is a small AppleScript around this and then I’ll have a URL shortening script I can bind to a hotkey. That should help speed the process up!

This article was originally posted on blog.scottlowe.org. Visit the site for more information on virtualization, servers, storage, and other enterprise technologies.

Shortening URLs via bit.ly from the CLI

• Shortening URLs via bit.ly the Apple Way
• Netsh Shortcuts
• A Couple GeekTool Scripts
• The Perfect Mac Twitter Client
• Converting SSL Certificates with OpenSSL

After a great deal of stumbling and fumbling, I found an obscure reference to a need to use rndc when making manual edits. After some testing, I learned that the “correct” way to make manual edits is as follows:

1. Halt changes to the dynamic DNS zone with the command rndc freeze <zone name>.
2. Make the manual edits to the zone file, being sure to increment the zone serial number.
3. Use the command named-checkzone <zone name> <zone file> to verify the syntax in the zone file.
4. Allow changes to the dynamic DNS zone with the command rndc thaw <zone name>.

If you monitor the appropriate log files (on my system I had to monitor /var/log/daemon), you’ll see zone transfers take place to any secondary name servers, a strong indicator that the change has successfully been accepted and propagated.

A very simple task, I know, but hopefully this post will help me next time I need to do this same task again and hopefully it will help someone else out there in the same situation.

This article was originally posted on blog.scottlowe.org. Visit the site for more information on virtualization, servers, storage, and other enterprise technologies.

Making Manual Edits to Dynamic DNS Zones

• Bulk Adding Entries in DNS
• New User’s Guide to Managing Cisco MDS Zones via CLI
• New User’s Guide to Configuring Cisco MDS Zones via CLI
• Native Kerberos Authentication with SSH
• Using vmware-vim-cmd to Modify a Portgroup

OpenBSD is my OS of choice when it comes to setting up a quick, simple UNIX-based virtual machine (VM). Need a virtual firewall? Use OpenBSD. Need a router? Use OpenBSD. Need a web server or an FTP server? Use OpenBSD. Need to run some network security tools? Use OpenBSD.

The problem is this: once I get an OpenBSD system up and running, it runs so well that I rarely have to go set up another one. Because there is then this length of time between installations, I always find myself forgetting the steps to take when installing an OpenBSD system. Thus, the need for this post and why I say it’s really for my benefit more than anything else. Next time I need to install OpenBSD in a VM for some reason, I can quickly come back and reference my list. (I will say that the installation of OpenBSD in recent versions has gotten much simpler than it was in the past.)

Oh, another disclaimer is probably necessary here, too: this is not to be considered some sort of “best practices” guide, so please don’t hammer the comments with stuff like “You know, you really should…”. This is just a quick and simple setup.

With those disclaimers out of the way, here’s the installation procedure. This was written for use with OpenBSD 4.6:

1. Boot from the OpenBSD installation ISO image. When prompted, choose “i” to install.
2. Press Enter for the default keyboard layout (unless you need a different layout, naturally).
3. Enter the system’s hostname in short form.
4. Enter the name of the network interface to configure. When installing on VMware Fusion 3.0.2 on my Macintosh, the default interface is em0. On VMware vSphere 4, the default interface is vic0.
5. Enter the IPv4 address or press Enter to use DHCP.
6. Enter the IPv6 address or press Enter to not assign an IPv6 address.
7. Press Enter to complete the configuration of network interfaces.
8. Press Enter not to perform any manual network configuration.
9. Enter and confirm the root password.
10. Press Enter to start sshd by default.
11. Press Enter not to start ntpd by default.
12. Enter “no” to indicate that you will not be running the X Window System.
13. Press Enter not to change the default console to com0.
14. Press Enter not to create an additional user. (I generally prefer to create an additional user after installation is complete.)
15. Press Enter to accept the default disk as the root disk. On my Mac running VMware Fusion 3.0.2, the default disk is wd0.
16. Press Enter to use the whole disk.
17. Press Enter to use auto layout of partitions on the disk. (I’m not sure what version of OpenBSD added this feature, but it is quite handy for simple installations.)
18. Press Enter to use the CD to install the sets. The CD in the VM should be mapped to the ISO image of the OpenBSD 4.6 install CD.
19. Press Enter to use the default CD (which showed up as cd0 on my system).
20. Press Enter to use the default path to the sets.
21. Remove the X Window System sets by entering “-x*” and pressing Enter.
22. Verify that the X Window System sets (xbase46.tgz, xetc46.tgz, xshare46.tgz, xfont46.tgz, and xserv46.tgz) are unselected, then press Enter to complete set selection. OpenBSD will start installing the sets.
23. Enter the timezone, such as “US/Eastern”.
24. Enter reboot to reboot your new OpenBSD VM. You should now be ready to perform final configuration of OpenBSD, such as using pkg_add to install packages or editing rc.conf.local to control what daemons are launched at startup. (Of course, those are tasks for an entirely different blog post).

That’s it. Again, this not a best practice/ideal installation. It’s just a “drop dead simple” installation in a VM for when you need to get something done quickly.

This article was originally posted on blog.scottlowe.org. Visit the site for more information on virtualization, servers, storage, and other enterprise technologies.

A Quick and Simple Guide to Building an OpenBSD VM

• OpenBSD as a Simple NAT Router
• New Folders with Quicksilver
• Not the Same
• OpenBSD 4.1 on ESX Server 3.0.1
• OpenBSD pcn0 Driver Issue Resolved

I use Mac OS X’s network location support extensively. I have separate locations for home (where I have a proxy server) and when I’m out and about (where there generally is no proxy server). So it’s important for me to be able to tell, quickly, which location is active. If the wrong location is active, then network connectivity is impaired.

To help, I use this command with GeekTool to display the network location on my desktop:

echo "Location: `networksetup -getcurrentlocation 2>&1 | tail -n 1`"

Note that if you are running as an administrative user on your Mac (which I don’t in order to reduce potential security risks), then the networksetup command I use above will probably behave differently for you. Since I’m not running as an administrative user, networksetup would throw an error at the command line. Thus why I had to redirect STDERR to STDOUT and filter it using tail. Now, a quick F11 to show the desktop and I can immediately see which network location is active.

I also recently added a script to show me what proxy servers are currently active. This is in anticipation of starting my new job at EMC. I don’t know if they have proxy servers on their network, but in the event they do I thought this next command might be handy:

echo "HTTP Proxy: `scutil --proxy | grep HTTP | sort | sed -n '3,3p' | awk '{print $3}'`"

This command displays the HTTP proxy host configured in your network settings. So, again, a quick F11 allows me to see which proxy hosts are configured and active on my Mac.

I actually wrapped several of these commands together into a shell script that you can download here if you’d like. I’m sure there is probably some bash black magic that could produce this output in a more efficient way; feel free to post suggestions for improvement if you have any!

Of course, I also have a few other scripts running with GeekTool—one that displays system information, one that produces IP addresses and Airport (wireless LAN) information, etc.—but these two are probably most useful to me so far.

This article was originally posted on blog.scottlowe.org. Visit the site for more information on virtualization, servers, storage, and other enterprise technologies.

A Couple GeekTool Scripts

• HTTP Proxies and Command-Line Utilities
• GPMC Scripts
• Windows 7, Microsoft Security Essentials, and Proxy Servers
• Some Useful UNIX Commands on your Mac
• Next-Gen Stuff: Verifying the SHA-1 Fingerprint

Reader Bill had this to say:

How on earth would Cisco respond if Sun started introducing products with better performance, at a fraction of the price, built on high volume open source adoption?

As I responded, that’s the real $64,000 question, isn’t it? That’s the premise upon which this entire thing is built—that by using commodity hardware and open source components, Sun can produce high-quality, high-performing network equipment that they can sell for far less than Cisco.

Reader Ed, on the other hand, questioned the validity of this kind of move:

I would think that partnering with a Juniper or Foundry-type company and OEMing equipment from those companies would be a more prudent move than venturing on their own to create new network devices.

Normally, I would agree with Ed if we were talking about a company that was merely interested in entering a market in order to become a more complete supplier to their customers. That’s not Sun’s purpose. Sun’s purpose is, I think, to fundamentally change the nature of the networking hardware market. How successful they’ll be…well, that’s another question.

My original article also prompted a response elsewhere on the Internet. Christofer Hoff thought my use of the work “distracted” in describing Cisco and Project “California” wasn’t appropriate, and in one sense he’s correct—”California” is absolutely a natural evolution of Cisco’s products and technologies and it does make sense for them. As I pointed out to Hoff, though, being successful with this new solution (I can’t call it a server!) will take focus, and while Cisco is focused on “California” Sun has their opportunity.

And it looks like they are definitely going to take that opportunity:

As I’ve said before, general purpose microprocessors and operating systems are now fast enough to eliminate the need for special purpose devices. That means you can build a router out of a server – notice you cannot build a server out of a router, try as hard as you like. The same applies to storage devices.
 
To demonstrate this point, we now build our entire line of storage systems from general purpose server parts, including Solaris and ZFS, our open source file system. This allows us to innovate in software, where others have to build custom silicon or add cost. We are planning a similar line of networking platforms, based around the silicon and software you can already find in our portfolio.

The emphasis on that last sentence is mine, just to emphasize the clarity of where Sun is headed. Clearly, it is their intention to leverage OpenSolaris, Crossbow, ZFS, Solaris Zones, etc., to compete directly against Cisco. And Cisco appears to be their primary target, judging from this sentence:

That means you can build a router out of a server – notice you cannot build a server out of a router, try as hard as you like.

To me, that looks like a direct jab at “California”.

So, I guess the question of whether Sun is going to take on Cisco is settled. Hoff, get your popcorn!

This article was originally posted on blog.scottlowe.org. Visit the site for more information on virtualization, servers, storage, and other enterprise technologies.

This Pretty Much Answers That Question

• Is Sun Preparing to Take on Cisco?
• Active Directory Integration Index
• Twitter Follow-Up: How to Manage a Default Route?
• Authenticating to Cisco IOS via Active Directory
• No Such Thing as an End-to-End FCoE Solution

In any case, an astute reader picked up on my mention of Crossbow and pointed me to this article by Jonathan Schwartz of Sun, and in particular this phrase:

You’re going to see an accelerating series of announcements over the coming year, from amplifying our open source storage offerings, to building out an equivalent portfolio of products in the networking space…

That seemingly innocuous mention was then coupled with this blog post and the result was this question: is Sun preparing to take on Cisco? Is Sun getting ready to try to use commodity hardware and open source software to penetrate the networking market in the same way that they are using commodity hardware and open source software to try to further penetrate the storage market with their open storage products (in particular, the 7000 series)?

It’s an interesting thought, to say the least. Going up against Cisco is a bold move, though, and I question Sun’s staying power in that sort of battle. Of course, with Cisco potentially distracted by the swirling rumors regarding the networking giant’s entry into the server market, now may be the best time to make this move.

Thoughts?

This article was originally posted on blog.scottlowe.org. Visit the site for more information on virtualization, servers, storage, and other enterprise technologies.

Is Sun Preparing to Take on Cisco?

• This Pretty Much Answers That Question
• Open Source Virtualization Thoughts
• SUNW to JAVA
• Open Source Hardware
• Open Virtual Disk Formats