Install "Non-Stable" PEAR Packages

Posted on Friday, October 3rd, 2008 at 1:39pm by Rob Wilkerson

Today I needed to install two PEAR packages on my machine. When I did, I got this:

me@mine [~] $ sudo pear install ole
Failed to download pear/ole within preferred state "stable", latest release is version 1.0.0RC1, stability "beta", use "channel://pear.php.net/ole-1.0.0RC1" to install
Cannot initialize 'channel://pear.php.net/ole', invalid or missing package file
Package "channel://pear.php.net/ole" is not valid
install failed

I’d seen this message before, but never at a time or place where it was important for me to dig in and figure out a way around it. Today I needed to do just that and I found that there are two ways.

Install This Beta Package, This One Time

To do this, simply follow the instructions in the error message:

$ sudo pear install channel://pear.php.net/ole-1.0.0RC1

By explicitly defining the channel from which to install the unstable package, PEAR seems to assume that you know exactly what you’re doing and leaves you alone to do it.

Allow Non-Stable Packages Without Complaining

The ability to “tinker” with libraries is somewhat inherent to a development environment so this is the direction I chose to go. I learned that PEAR recognizes the following application states (though I’m not sure exactly how each is defined):

1. stable
2. beta
3. alpha
4. devel
5. snapshot

This information can be shown by running the pear executable’s config-help command:

$ pear config-help preferred_state

I decided to lower my standards gradually in order to protect some level of stability while still getting the functionality I needed. I opted to lower my preferred_state to beta.

$ pear config-set preferred_state beta

Now I can install beta packages normally (i.e. I no longer have to specify a channel) without all of the whining. PEAR doesn’t make this information as easy to find as I’d have liked, so maybe this will help someone else.

php, pear, configuration, shell 0 Comments

Random Access Command Line History

Posted on Wednesday, October 1st, 2008 at 2:41pm by Rob Wilkerson

This afternoon I found out that I knew something I didn’t know I knew (say what?).

I was spending a lot of time opening and closing SSH sessions and some of those were connecting to an IP address that I couldn’t remember. To assist my memory, I was grep’ing my history and then copying and pasting what I needed. At some point in the course of doing that, I had this memory of a way to re-issue a particular command from the history:

me@mine [~] $ history | grep ssh
   13  ssh rob@rob
  297  ssh rob@rwilkerson
  298  ssh rob@rwilkerson1
  299  ssh rob@rwilkerson
  301  ssh rob@rwilkerson-old
  303  ssh rob@10.168.159.174
  432  ssh rob@10.168.159.184
  434  ssh rob@10.168.159.184
  465  history | grep ssh
  466  ssh rob@10.168.159.174
  467  history | grep ssh
  468  ssh rob@10.168.159.174
  501  history | grep ssh
me@mine [~] $ !468
ssh rob@10.168.159.174
rob@10.168.159.174's password:

The first command displays the entire history buffer and pipes it through a grep for the ssh command. The second executes the 468th command in the history buffer, in this case ssh rob@10.168.159.174, without having to retype it or even paste it. Now that I remember that I know how to do this, I suspect it’ll play a larger role in my terminal operations.

linux, shell 0 Comments

Migrating from tcsh to bash

Posted on Monday, August 18th, 2008 at 8:21pm by Rob Wilkerson

My move to Linux in the workplace almost necessarily entails a shell change. I’ve been using tcsh for years, going back to the days before bash added tab completion, if memory serves, but in the last year or so, I’ve been considering a switch to bash for several reasons:

1. It’s the default shell on the Mac and most CLI help articles reference bash.
2. Every Unix variant I can think of seems to ship with bash as the default shell.
3. Some Unix variants don’t even bother to ship with tcsh.

Ubuntu, my distro of choice, is one of those variants that doesn’t ship with tcsh. Yeah, I know I can install tcsh easily enough, but that seems like a recipe for repetition over time as I work on new machines running other distros that may or may not include a tcsh install. For the sake of universal access, I think I’d rather just conform.

This past weekend I began the process of migrating my well-worn, painstakingly accumulated .tcshrc login script to its bash counterpart, .bash_profile. What I’m finding is that it’s not all that simple.

Read More »

shell, bash, tcsh, linux 0 Comments

Dynamic DNS Updates

Posted on Saturday, March 15th, 2008 at 6:40pm by Rob Wilkerson

Okay, so my OpenDNS configuration wasn’t perfect. OpenDNS liked it just fine, but DynDNS was another story. They tagged me as an abuser and blocked my host name. Oops.

When I built my script using cURL to call the DNS-O-Matic API, I didn’t build in any intelligence. I created a cron job that ran every half hour and call my script. The script simply passed my current IP address to DNS-O-Matic who, in turn, passed it to DynDNS. My approach was the obvious one and at the same time, a bit brutish. If nothing has changed, then no harm, no foul…right?

Understandably, DynDNS didn’t think so. They consider it abuse if their system is getting pinged too often without a change actually being made. By those rules, I was most definitely playing the role of abuser. Today I made a few changes to my script so that it’s a bit more intelligent, while maintaining a degree of simplicity. I also added some output so I could track what was happening if I ever need to do so.

 touch updatedns.log

 echo “”
 echo “========================= `date` =====================”
 echo “”

 # 
 # If a file named updatedns.current doesn’t exist, then retrieve
 # the current network IP address and write it to that file.  Then
 # set the $lastip value to something that we know won’t match.
 # 
 # If the file does exist, then read its contents into the value of 
 # $lastip.
 # 
 if [ ! -e “updatedns.current” ]; then
   echo “updatedns.current does not exist.”
   curl -s -m 60 http://myip.dnsomatic.com/ > updatedns.current
   echo “updatedns.current created.”

   lastip=“UNKNOWN”
 else
   lastip=`cat updatedns.current`
 fi

 # 
 # Retrieve the network IP as it exists right this moment.
 # 
 currentip=`curl -s -m 60 http://myip.dnsomatic.com/`

 echo “Last known IP was $lastip.”
 echo “Current IP verified as $currentip.”

 # 
 # If the last and current IPs are different, then tell
 # DNS-O-Matic to broadcast an update.
 # 
 if [ “$currentip” != “$lastip” ]; then
   echo “$currentip != $lastip.  Updating DNS-O-Matic.”
   curl -m 60 -k -u myusername:mycrazystrongpassword \
        https://updates.dnsomatic.com/nic/update
        ?hostname=all.dnsomatic.com&myip=$ip
        &wildcard=NOCHG&mx=NOCHG&backmx=NOCHG
   echo $currentip > updatedns.current
 else
   echo “IP address has not changed. No action was taken.”
 fi

 exit 0

Note that the URI in the curl statement must be on one line. It’s split here due to space limitations. And the cron job? It looks like this:

*/5 * * * * /usr/local/bin/updatedns.sh >> /usr/local/bin/updatedns.log

Since I’m now determining whether an update needs to be done, I’m running the script every 5 minutes instead of every half hour. Might as well have less lag time when an update is needed, right?

opendns, networking, cron, shell 0 Comments

Configuring OpenDNS for a Complex Network

Posted on Thursday, March 13th, 2008 at 4:17pm by Rob Wilkerson

For a while now, I’ve been monkeying about with using OpenDNS as my DNS service provider rather than rather than using my ISP‘s name servers in order to take advantage of some of the great additional features offered by OpenDNS. In a simple scenario, configuring OpenDNS name server support is easy – just tell your network or machine to use their name servers and go on about your day. Easy. Except that my network architecture isn’t that simple. The other night I decided to put in the time to get myself sorted out and commit to OpenDNS.

In a nutshell, here’s what my home network architecture and usage looks like:

• I connect to the internet via DSL service.
• I do not have a static IP. It would make life easier (see problem #3 below), but I’m not willing to pay the premium.
• Behind a couple of firewalls, I run a LAN.
• I have an internal name server for resolving the IP addresses of other machines on the LAN.
• I have a DHCP server that broadcasts the name servers to be used by the other machines on the LAN in addition to assigning their IP addresses.
• I have an account with DynDNS that allows me to connect to my home network by name even though it has a dynamic IP that changes with some frequency.
• I often have to connect to work through a VPN to access corporate resources.

In the course of configuring OpenDNS for use in my environment, I bumped into a number of problems that I needed to solve.

Read More »

networking, opendns, shell, cron 0 Comments