DNS Zone File record generation script

Posted on June 7, 2007 by dre

In wrote the following as part of my response to this.

#!/usr/bin/perl -w
use strict;

# Place the first three octets here.
my $AddressPrefix = "10.0.1";

# Define the range of numbers, inclusive.
my $range = "2 .. 10";

# Your fqdn suffix here, e.g. "foo.com" or "k12.fl.us.gov"
my $tld = "937";

# Need a backwards representation for PTR records
my $octets = join(".", reverse(split(/\./, $AddressPrefix)));

# For our resulting address and ptr records
my @A, my @PTR = "";

foreach my $n ( eval $range ) {
push @A, "dhcp$n IN A $AddressPrefix.$n";
push @PTR, "$n.$octets.in-addr.arpa. IN PTR dhcp$n.$tld.";
}

print "Forward zone address records:\n";
print "$_\n" for @A;
print "\nReverse zone ptr records:";
print "$_\n" for @PTR;
Posted in OS X Server, scripts | Leave a comment

Eggdrop TCL using Google’s SOAP API

Posted on May 27, 2007 by dre

Link to google-soap

I was helping my brother with a script called incith-google used by one of his IRC bots. It acts as a bridge between IRC and google, allowing IRC users to perform queries against google from the comfort of their IRC client. The script performs the search on the IRC user’s behalf and returns the result back into the IRC channel.

The problem is that it had broken. In investigating, it became readily apparent that it was bound to break, and surely had broken before. This is because the script was making the request to google as if it were a web browser, and receiving html output in return. The IRC client only wants to see a short bit of text, so the script attempts to parse out the juicy bits from the html output. This process of screen scraping is wobbly at best; any subtle formating or presentation change of the google search results web page can break the script entirely. This happens frequently due to the web’s inherent tendency to mix content and presentation semantics; the good news is that the w3c is finally catching on to this.

A more robust way to do these types of interactions would be to use a more rigorous and starndardized process for asking questions and getting answers; in a word: API. A large part of the value of API is that the semantics of exchanging information and interacting witih other pieces of software are ‘locked down’, in the sense that the API vendor wants you to trust that those semantics will continue to work as designed, for the life of the API. It just so happens that Google has several APIs for accessing their various services. Because Eggdrop scripting is done solely in TCL, I started there. It didn’t take long to find Web Services For TCL, which is precisely what I needed.One downside to the Web Services for Tcl library is that there are a significant number of other (mostly non-standard) Tcl libraries on which it is dependant. Tcl has no package / module / library management system that might ease the process of installing these other libraries, so it took me a bit of time to get it all going (and I mostly know what I’m doing). The average Eggdrop user learned unix in order to utilize Eggdrop itself, so they are typically not of the sysadmin variety (as it happens, Eggdrop is what initially got me in to Unix, though I’ve come a bit of a ways since 1995 or so).

A bigger downside is that Google no longer allocates new SOAP API keys, so if you didn’t get one prior to Dec 5, 2006, you are s.o.l. I got one for some reason, even though I’m only really getting around to using it now.

Anyway, after going through all the trouble of getting this library operational, I figured I’d go ahead and bang out a quick eggdrop interface to Google based on Web Services for Tcl, so there you have it.

Posted in development, scripts | Leave a comment

owwie

Posted on May 17, 2007 by dre

Seattle, WA has more elevation changes than Cupertino, CA. Last thursday, while riding my bike home from 15th (capitol hill), I hit a huge pot hole while going downhill, kinda fast. Front wheel went down in it – loud metallic BRRANG as the bike vibrated from the force of the impact with the road; I come to rest in a single moment of impact (no sliding); some lady who saw it yells “aow mai guawd aah you aowkaay?” in a nice bostonian. I managed a VERY strained “I think so”, but it was several minutes before I could stand up, even with the moral support from several other passers by. Yadda. The right arm has been mostly out of commission for the last week; as it turns out, I use that one for a lot of stuff. Anyway, no breakages, just bruises and a bunch of swelling about the elbow and wrist areas. As of recently I can rotate my wrist enough to use a keyboard for shortish periods of time without too much discomfort. It’ll probably be another couple of weeks at least before I regain full range of motion.

Couldn’t have happened at a better time, though. Seriously. I’m self-unemployed, with no real responsibilities to speak of. It’s nice :) My roommates have been graciously helping out with some two-handed manual functions, such as opening food or drink items, or tying my shoes.

Other things:

* Checking out Command and Conquer 3; it’s cool. Mostly I’m doing this because:
* I haven’t played WoW since I left CA. It itches, but I kinda wanted a break, if not a complete ceasing of play. I may get back into it if I can keep it to a reasonable time commitment. It’s not really the game itself I miss as much as my guild. I imagine it’s the social hooks that keep a lot of people playing more than any other single factor.
* I’m not looking for work yet, though I have been occasionally thinking about what I might do. No firm ideas yet.
* My brother is kinda going nuts on the local music scene, championing a newish (sub?) genre called dubstep. Check it.

Posted in bit bucket | Tagged | Leave a comment

Apple airport base station monitor

Posted on April 27, 2007 by dre

Download.

{1} andre@dude [~] % airport -h
Program Options:
      -h           print this help
      -d           output in comma delimited format
                   (base station ID lines are designated by '*')
      -v           verbose mode
                   (stacks up to 3 times)
      --encode     Specify plaintext to retrieve the base64 encoding.
                   This should be used to store the SNMP community name near
                   the top of this script.
                   
Output Field Specification
   Each of these letters represents a piece of available information about a
   wireless device associated to the base station. The order in which the tokens
   are specified is used as the output field order. Do not prefix these tokens
   with "-" or "--".
       n       wirelessPhysAddress
       y       wirelessType
       s       wirelessStrength
       r       wirelessRate
       o       wirelessNoise
       t       wirelessNumTX
       e       wirelessNumRX
       T       wirelessNumTXErrors
       E       wirelessNumRXErrors
       a       wirelessTimeAssociated
       i       wirelessLastRefreshTime

Default output is equivalent to "nysroai".

Examples:
Debug mode with default fields:
airport -v

Comma-delimited mode with field specification:
airport -d nsroteTE

Sample run (polling two base stations in a wds configuration):

{19} andre@donk [~] % airport
10.0.1.3 (dreness) WLAN clients: 2  DHCP clients: 0
  Name or Address     Type   Str    Rate   Noise   Connected    Idle       
  boop                wds    -66    54     -91     3 23:58:56   0  0:00:00  
  dude                sta    -81    5      -94     3 23:34:03   0  0:20:22  
10.0.1.1 (Boop) WLAN clients: 7  DHCP clients: 8
  Name or Address     Type   Str    Rate   Noise   Connected    Idle       
  peperoni            sta    -85    5      -98     3  5:05:08   0  0:00:00   
  dude                sta    -57    54     -93     3  5:04:49   0  0:00:00  
  dreness             wds    -56    54     -88     3  5:05:08   0  0:00:00  
  hughe               sta    -50    27     -90     3  5:04:21   0  0:00:00  
  pandabank           sta    -72    24     -100    3  5:04:15   0  0:00:17  
  00 11 24 ED 4A E5   sta    -63    54     -96     3  5:04:21   0  0:00:00
Posted in OS X, scripts | 4 Comments

Now accepting applications

Posted on March 15, 2007 by dre

https://jobs-prz.apple.com/index.ajs?BID=1&method=mExternal.showJob&RID=5997&CurrentPage=1

If you know any hot to trot mac server geeks, this would be a good job. Though I’m intentionally vacating it for reasons including “I don’t want to do it anymore”, I would still recommend it as a good way to skill up, meet interesting people, or even just to bank a few greenbacks. Drawbacks include: running into bugs all the time and wearing a pager. If interested, act quickly.

Me? I’m drawing ever closer to my impending exit. With significant anticipation :)

Posted in bit bucket | Tagged , | 2 Comments

Thomas Dolby

Posted on March 12, 2007 by dre

Saw Thomas Dolby last night at the Little Fox Theater in Redwood city. First set was solo, and included a bit of storytelling along with the tunes. Second set included the Jazz Mafia Horns, which worked out surprisingly well. Lots of fun! Highly recommended!

He’s touring for another couple weeks; go see the show if you’re into it! Here is the current tour schedule.

Posted in bit bucket | Tagged , | Leave a comment

The opposite of split is cat.

Posted on January 2, 2007 by dre

/usr/bin/split and /bin/cat, that is. Why is this useful information? Let’s imagine a wonderful world in which your web host gives you oodles of bandwidth and disk quota, and then one day secretly enacts a policy that disallows access to files over a certain (largish) size. Say, something like:
[Tue Jan 02 13:07:24 2007] [error] [client x.x.x.42] (75)Value too large for defined data type: access to /some/big/file.omg failed

Let’s also suppose that this file is indeed really big, and you totally don’t want to go through the pain of segmenting it locally and then uploading it again. If the server and client(s) are unixy, here is your salvation:

split -b 500m BigFile BigFileParts_

This will segment your file into chunks that are 500 MB in size (though obviously the last one will probably be less). You will end up with files named BigFileParts_aa, BigFileParts_ab, and so on. Now you can download them, presuming 500 MB is beneath the threshold of the policy which blocks big file xfers; adjust accordingly.

Once downloaded, put them back together with cat, appending from the back to the front:
cat BigFileParts_ac >> BigFileParts_ab
cat BigFileParts_ab >> BigFileParts_aa
mv BigFileParts_aa BigFile

Posted in OS X, OS X Server | Leave a comment

Installing perl modules locally

Posted on December 6, 2006 by dre

Dealing with CPAN has always felt a little weird. Today I found a nice shortcut for getting perl modules installed in a home directory, which is really useful for when you don’t have admin on the box, or if you simply prefer to keep your custom perl stuff all cinched up in a tidy homedir for ease of administration (or if you have to use custom modules on a machine with no dev tools; you can build them on a dev box and then just scp the entire ~/perl directory to where it’s needed).

LocalModInstall is a script that generates a modified Makefile for a perl module you wish to install, suitable for installing it into your home directory.

{42} andre@werk [work/perl-ldap-0.33] % perl ~/bin/LocalModInstall.pl
/usr/bin/perl Makefile.PL PREFIX=/Users/andre/perl \
INSTALLMAN1DIR=/Users/andre/perl/usr/share/man/man1 \
INSTALLMAN3DIR=/Users/andre/perl/usr/share/man/man3
*** ExtUtils::AutoInstall version 0.59
*** Checking for dependencies...
[Core Features]
- Convert::ASN1   ...loaded. (0.19 >= 0.07)
[SASL authentication]
- Authen::SASL    ...loaded. (2.09 >= 2)
- Digest::MD5     ...loaded. (2.33)
[LDAP URLs]
- URI::ldap       ...loaded. (1.11 >= 1.1)
[LDAPS]
- IO::Socket::SSL ...missing. (would need 0.81)
==> Auto-install the 1 optional module(s) from CPAN? [n] n
[Read/Write DSML files]
- XML::SAX::Base  ...loaded. (1.04)
[Read/Write LDIF files]
- MIME::Base64    ...loaded. (3.05)
*** ExtUtils::AutoInstall configuration finished.
Writing Makefile for Net::LDAP

Don't forget to

  use lib
  qw(
      /Users/andre/perl/System/Library/Perl/5.8.6/darwin-thread-multi-2level
      /Users/andre/perl/System/Library/Perl/5.8.6
      /Users/andre/perl/Library/Perl/5.8.6/darwin-thread-multi-2level
      /Users/andre/perl/Library/Perl/5.8.6
  );

in your scripts (prior to any other "use" statements) or to set

  PERL5LIB="/Users/andre/perl/System/Library/Perl/5.8.6/darwin-thread-multi-2level"
  PERL5LIB="$PERL5LIB:/Users/andre/perl/System/Library/Perl/5.8.6"
  PERL5LIB="$PERL5LIB:/Users/andre/perl/Library/Perl/5.8.6/darwin-thread-multi-2level"
  PERL5LIB="$PERL5LIB:/Users/andre/perl/Library/Perl/5.8.6"
  export PERL5LIB

in your shell (or shell configuration file) and to set

  MANPATH="$MANPATH:/Users/andre/perl/usr/share/man/man1"
  MANPATH="$MANPATH:/Users/andre/perl/usr/share/man/man3"
  export MANPATH

in your shell (or shell configuration file).

You would then ‘make’ and ‘make install’ like normal.

However, the ‘use lib’ suggestion that is supplied does not work in Mac OS X. The goods seem to be installed in ~/perl/lib/perl5/site_perl, which is not included in the suggested paths. Instead, I use:

use lib  qw(
/path/to/home/perl/lib/perl5/site_perl );
Posted in development, OS X, OS X Server, scripts | Leave a comment

OpenLDAP and SSL (and Mac OS X Server and you)

Posted on November 13, 2006 by dre

Mac OS X Server, as of Tiger, has a spiffy little UI in the Server Admin tool for creating SSL certificate requests, importing certs, or creating self-signed certs. It’s pretty easy to make it all work for http or LDAP using the GUI tools.

There is also the command-line ‘serveradmin’ tool, which attempts to mirror the functionality of the Server Admin GUI tool. I was preparing procedures to enable SSL for some Open Directory servers, so I was banging through the various alternatives to see which one is best, when I came upon an interesting scenario.

It seems that when using the command-line ‘serveradmin’ tool to enable SSL, it would only work sometimes. On a test machine, configured as an OD server, I created a valid self-signed SSL cert, then used ‘serveradmin’ to make the appropriate settings, as suggested in the man page. I created a file that contains the settings I want, then load it into serveradmin. I named the file ssl_config, and the contents are:

dirserv:LDAPSettings:LDAPSSLKeyPath = "/etc/certificates/dirt.apple.com.key"
dirserv:LDAPSettings:LDAPSSLCertificatePath = "/etc/certificates/dirt.apple.com.crt"
dirserv:LDAPSettings:useSSL = yes

This configuration can then be loaded by executing:

sudo serveradmin settings < ssl_config

If it worked, serveradmin will echo the new settings when they are applied. After doing this, servermgr knows that slapd has to be restarted, and does so. In my case, slapd would only sometimes reload successfully. Other times, the slapd startup would fail with the following (which you could see by starting slapd in debug mode; sudo /usr/libexec/slapd -d 99 -f /etc/openldap/slapd.conf)

TLS: could not use key file `/etc/certificates/dirt.apple.com.key'.
TLS: error:0D07207B:asn1 encoding routines:ASN1_get_object:header too long asn1_lib.c:140
main: TLS init def ctx failed: -1

... yet when I would revert the SSL configuration back to default, and use the GUI Server Admin to select the same certificate, it would work! What the crap?!? Furthermore, why did it only fail *sometimes*?

Turns out that the failure cases were all ones in which I had supplied a password for the SSL private key, which creates an encrypted private key file. In order to use this key, the password must be supplied to decrypt it before it can be loaded.

Apple does this for apache using an Apple tool located at /etc/httpd/getsslpassphrase. Based on my admitedly layman's understanding of a string dump of this tool, it appears to look for the SSL key password in /etc/httpd/servermgr_web_httpd_config.plist so that apache can use it to unlock the key and start the service.

But we're not talking Apache, we're talking OpenLDAP. Without configuring any Apache vhosts for SSL, that file doesn't contain the private key password, and yet slapd is still able to start successfully.

Digging deeper, if we look at the /etc/openldap/slapd_macosxserver.conf config file after a successful SSL configuration (e.g. using Server Admin), we see:

# This file should NOT be world readable.
# This file is maintained by Server Admin.
...
TLSCertificateFile      /etc/certificates/dirt.apple.com.crt
TLSCertificateKeyFile   /etc/certificates/dirt.apple.com.key
TLSCertificatePassphraseTool    /etc/httpd/getsslpassphrase dirt.apple.com:636 RSA

How mysterious! Gee, I wonder how that got there.

There are three strange / unwanted behaviors here. First is that the command-line 'serveradmin' does NOT have functional parity with the GUI Server Admin with respect to enabling SSL for OpenLDAP. The second is that a tool clearly positioned for Apache is being used by OpenLDAP. The third is that I have no idea where the getsslpassphrase looks for the SSL key password other than /etc/httpd/servermgr_web_httpd_config.plist. The getsslpassphrase tool does link against the Security framework, so I suppose it's possible that it's fishing it out of the System Keychain or something.

[[passage of time]]

Yep. There's an item in the System keychain called certificateManager of type 'application password' with 'Account' set to the fqdn used in the SSL certificate 'common name' attribute. Open that keychain entry and hit the 'show password' checkbox to display the SSL key password.

So then, the magic appears to be supplied by the OpenLDAP configuration directive "TLSCertificatePassphraseTool" and by the /etc/httpd/getsslpassphrase tool. Googling, we see that TLSCertificatePassphraseTool exists exactly once on all of the Internets: right here; clearly this is an Apple addition.

So now you should have all the pieces required to enable SSL for OpenLDAP from the command line:

  • Import or create an SSL cert using Server Admin (this could probably also be done with the command line 'security' tool, but that's left as an exercise for the reader)
  • Add the appropriate configuration to the slapd_macosxserver.conf file as shown above
  • Add the appropriate configuration using the 'serveradmin' cli tool as shown above. This should cause slapd to restart using SSL (note that I haven't actually gone through each of these steps in this manner... wait for it...)

I found a much easier way to accomplish all this from the command line:

sudo slapconfig -setldapconfig -ssl on -sslcert /etc/certificates/dirt.apple.com.crt \\
-sslkey /etc/certificates/dirt.apple.com.key -ssldomain dirt.apple.com

At this point you're probably wishing I had just lead with that instead of dragging you through the mud first. Hey, it builds character :)

Finally I should note that on one of two test servers, the creation of the self-signed cert using Server Admin didn't totally work. What's supposed to happen is that it creates System keychain entries and then 'exports' those for use by OpenSSL, which looks for the files in /etc/certificates. The exporting part didn't seem to work properly on one server, however after executing 

sudo certadmin export dirt.apple.com

the required files are published into /etc/certificates, and life is grand.

Posted in OS X Server | Leave a comment

the rushbot

Posted on November 4, 2006 by dre

On the 10/30 Colbert Report, there was a segment about Rush Limbaugh who was recently claiming that Michael J Fox was exaggerating his Parkinson’s disease and ‘shilling for a Democrat politician’ in a series of TV ads for stem cell research. Roight, well anyway, after that segment, just before the commercial, they rolled this little gem:

… which inspired me to clean up the audio and make a few creative extensions. iMovie ftw.

https://dreness.com/bits/funny/rushbot.mov

I don’t know if this is really that funny, but I sure had a blast making it. Enjoy :)

Posted in bit bucket | Tagged | 1 Comment