SCRIPT_NAME=`basename $0`
if [ `pgrep -c ${SCRIPT_NAME}` -gt 1 ]
then
  echo "Error: An instance of this script is already running!"
  exit 1
fi

This fragment uses pgrep to count the number of running processes with the same name as the currently running script. If the number of these processes is greater than one (the current script will always be counted), then we know that another instance is already running.

As far as I know (and I hope someone will correct me if I’m wrong), this technique avoids the race conditions associated with lock/PID files. It also avoids the possibility of orphaned lock/PID files in the event that your script doesn’t complete and is unable to clean up after itself.

I’ve actually been a DynDNS customer since the late nineties or so (I have free custom DNS service for life for making a donation to them back when they were a much smaller company), so I had looked at Dyn.com‘s products before. I just must have gotten confused with all their different websites and DNS products, because I somehow got the impression that the DynDNS API wasn’t powerful enough to do what I wanted to do. I was absolutely wrong. After having written command line clients for both APIs (see ultradns4r, and now dynectr4), I think I speak from authority when I say the Dynect API is every bit as powerful as UltraDNS’s. And at 1/10th – 1/25th the cost of UltraDNS, going with Dynect is a no-brainer. But I’ve digressed long enough.

I wrote dynect4r for the same reason I wrote ultradns4r; I wanted to be able to manage all my DNS records via the command line. And now that I’ve learned how to package Ruby projects as gems, you can simply…

gem install dynect4r

and then do things like…

dynect4r-client -n test.example.org 1.1.1.1

Since the key feature of this project is the command line client, the actual library behind it is a pretty simple wrapper around rest-client. If you’re looking for something a bit more powerful to use in your own Ruby projects, you may be interested in dynect_rest by Adam Jacob from Opscode. We actually discovered each other’s projects last night in #chef, and realized that it would probably be a good idea to pool our efforts eventually.

The first thing I did was create an iptables cookbook with a default recipe that simply ensures that the iptables package is installed:

package "iptables" do
  package_name "iptables"
end

Next, I used the definitions documentation on the Opscode wiki to write the actual definition. What I’m basically doing here is accepting a few Iptables-specific parameters (table, chain, options) and dynamically building the execute resources to run the appropriate Iptables commands:

define :iptables_rule, :action => :create, :table => "filter", :chain => nil, :options => nil do
 
  include_recipe "iptables"
 
  if params[:table].empty?
    raise ArgumentError, "Missing required argument: table"
  end
  if params[:chain].nil? or params[:chain].empty?
    raise ArgumentError, "Missing required argument: chain"
  end
  if params[:options].nil? or params[:options].empty?
    raise ArgumentError, "Missing required argument: options"
  end
 
  iptables_bin = "/sbin/iptables"
  rule_id = "Chef Rule: #{params[:name]}"
  comment = "-m comment --comment \"#{rule_id}\""
 
  if params[:action] == :delete
    execute "delete_iptables_rule-#{params[:name]}" do
      command "#{iptables_bin} --table #{params[:table]} -D #{params[:chain]} #{params[:options]} #{comment}"
      only_if "#{iptables_bin} --table #{params[:table]} -S #{params[:chain]} | /bin/grep \"#{rule_id}\""
    end
  else
    execute "create_iptables_rule-#{params[:name]}" do
      command "#{iptables_bin} --table #{params[:table]} -A #{params[:chain]} #{params[:options]} #{comment}"
      not_if "#{iptables_bin} --table #{params[:table]} -S #{params[:chain]} | /bin/grep \"#{rule_id}\""
    end
  end
end

So now when I want to manage an Iptables rule with chef, I can just do something like this:

iptables_rule "jetty_port_80" do
  table "nat"
  chain "PREROUTING"
  options "--proto tcp --dport 80 --jump REDIRECT --to-port 8080"
end

I am pleased to announce ultradns4r; a Ruby library and command line client for the Neustar UltraDNS SOAP API. I created this tool to alleviate the pain in dealing with EC2′s dynamic hostnames and IP addresses. Since it allows editing of arbitrary DNS records via the command line, it can be used to make EC2 instances update their own DNS records.

Lessons Learned

• If you need to do SOAP in Ruby, just use Savon. Trust me on this.
• WSSE authentication is a complete pain in the ass. I was unable to find any SOAP library (Ruby, Python, or Perl) that could authenticate with the UltraDNS API servers out of the box (Savon included). I ended up having to build the entire WSSE header manually in order to generate the exact XML needed.
• Apparently, element order sometimes matters with SOAP! This is something I never expected, considering that (last I knew) the XML spec does not even allow you to enforce element or attribute order. This was also the cause of a lot of my WSSE problems. I found that for example, if the Password element came after the Nonce and Created elements (which is the case if you use Savon’s built-in WSSE authentication), then authentication would fail. Could this have been the result of having a buggy XML parser on the server side? In any case, this is one of those annoying issues to be aware of.

• moddisk.py
• moddisk.pyconf

This module reads a list of mounted file systems from a file (probably /proc/mounts) and creates a metric for each one, allowing you to graph disk usage for each file system separately. Enjoy!

Update: It appears that multidisk.py does the same thing, and is probably already included with your distribution. Oops! ;-)

• modtokyotyrant.py
• modtokyotyrant.pyconf

Enjoy!

warning: peer certificate won't be verified in this SSL session

There is a very simple (but very poorly documented) fix for this. After instantiating your XMLRPC::Client object…

server = XMLRPC::Client.new3( ... )

Add the following line:

server.instance_variable_get(:@http).instance_variable_get(:@ssl_context).instance_variable_set(:@verify_mode, OpenSSL::SSL::VERIFY_NONE)

Now do your XML-RPC calls as usual:

result = server.call( ... )

def bsearch(array, search, start_ix=0, end_ix=array.length)
    mid_ix = start_ix + ((end_ix-start_ix)/2).ceil
    if array[mid_ix] == search then
        puts "%d found at position %d" % [ search, mid_ix]
    elsif start_ix == mid_ix then
        puts "%d not found" % [ search ]
    elsif array[mid_ix] < search
        bsearch(array, search, mid_ix, end_ix)
    elsif array[mid_ix] > search then
        bsearch(array, search, start_ix, mid_ix)
    end
end
 
bsearch([10, 20, 30, 40, 50, 60, 70, 80, 90], ARGV[0].to_i)

It’s probably not by best work, and I’m pretty doubtful that I could have done it in the same amount of time under the stress of a job interview. But it works, and that’s good enough for me, considering that I haven’t been a full time programmer in quite some time and haven’t written anything like this since college. ;-)