Category: Computer Stuff


I was just looking through my archives and remembered the Golden Apple Project. Ahhh yes. Well it turns out that the machine was so old it just stopped working altogether. OpenBSD was running just fine on it, but after a year the network card died and when I tried to add a netgear PCI NIC it caused kernel panics. I do have a new apple PPC machine that I have been prepping to handle light duties, her name is aphrodite and she’s a little red iMac. It’s my hope that I can keep at least one PPC box running unix in my little computer family…

Ever see this?

dhcpd: uid lease 192.168.1.150 for client xx:xx:xx:xx:xx:xx is duplicate on 192.168.1/24

or something like it, in your dhcp logs? Well I checked /var/log/messages today and saw that I had thousands of this message repeated over and over (so much so it was spamming my log  and making it harder to find what might be important stuff). I searched around the ‘net and found some hints but nothing conclusive. The hints pointed toward a duplicate lease (duh) but more specifically lead me to check my leases file. Mine was located in /var/db/dhcpd/dhcpd.leases.

It turns out that what caused this error for me was that I had started the machine in question (the MAC address has been altered to protect the innocent haha) before I had the time to create a reservation for it. Then after it already had an address leased to it, I created a reservation for it (for internal DNS purposes, nothing more). Apparently because duplicates are allowed by default in isc dhcpd, when the machine’s networking was restarted and it got it’s new reserved IP, the server kept the original lease (which was that .150 address) and also got a lease from it’s reservation (.80 on my network). Since the .150 lease was still present in the leases file it caused the warning message (over and over and over for a month).

So if you are using isc dhcpd, and you use reservations, and you’re getting these error messages, you might want to check your leases file and make sure that you don’t have a lease for something that also has a reservation under a different IP.

The other pages I found on my search also suggested that you might have a reservation that hands out an address that is within your dynamic scope. You definitely don’t want to do that, so you may need to check that out as well in your dhcpd.conf.

For the curious, I run FreeBSD 7 on a Pentium 4 Dell desktop (I think it’s a dimension series, I haven’t looked at it in a while haha) that sits in my kitchen as a headless DNS/DHCP/Web/Random Unix Fun server. It’s actually making lots of bad noise lately and I think one of it’s fans might be going :( I’ll check that out and report back :)

If you have a mac and use wireless to connect, you might expect that it will automatically join your wireless network after you tell it to “remember this network”. I know on my old powerbook it did, and on my girlfriend’s macbook it auto-joins too. So I started wondering why my macbook pro just wouldn’t do it. I searched the keychain and found my network in the login keychain, so I thought something really bizarre was going on. When I checked console (the console app in /Applications/Utilities) it said my network wasn’t in the system keychain!

To make a long story short (as my mother would say), I found a solution here: http://discussions.apple.com/thread.jspa?messageID=6757490

It turns out that when I moved System Preferences to /Applications/Utilities it broke my mac’s ability to add networks to the system keychain! I moved it back to /Applications, deleted the network from my network preferences and keychain and then joined the network again. This time the network was added to the system keychain and all is well!

The DHCP server at my office was reconfigured yesterday and it started forcing my macbook pro to change it’s name. I like having my host name remain constant for various reasons, so I asked in #macosx and some kind user there pointed me to this blog post:

http://www.elharo.com/blog/software-development/web-development/2005/11/29/setting-a-permanent-host-name-in-mac-os-x/

It works on leopard, in case you’re wondering! Solved my problem after a reboot.

If you installed Security Update 002 for leopard and suddenly ssh tells you “bus error”, the answer lies here:

http://discussions.apple.com/thread.jspa?messageID=6863360#6863360

Apparently the guys at rogue amoeba have some work to do – we need instant hijack!

If you are too lazy to read that thread, the fix is:

sudo /usr/local/hermes/bin/hermesctl unload

thereby uninstalling instant hijack and fixing the problem. Somehow…

… and here’s the fix from Rogue Amoeba:

http://www.rogueamoeba.com/utm/2008/03/19/security-update-2008-002-compatibility-fix/ 

A friend of mine keeps an OpenBSD box up so that we can use it for a shell if we need one (it’s come in handy on more than one occasion, let me tell you!). I was logged in the other day and wanted to add a package. My zsh startup files make it a rather simple process most of the time, partly because of the fact that I set the PKG_PATH variable dynamically. Part of that dynamic value is taken from the OSTYPE variable.

To make a long story short(er) I couldn’t add a package via pkg_add -i, and the reason was that OSTYPE was returning openbsd4.1 even though uname reported “OpenBSD isis.beyondnormal.net 4.2 GENERIC#375 i386″. The local mirror I use doesn’t keep packages around from old releases, so that was part of why this failed. So why was OSTYPE returning 4.1 even though it was OpenBSD 4.2? The answer is that OSTYPE is set at compile time.

Apparently, after upgrading the OS, the packages from OpenBSD 4.1 will work ok with OpenBSD 4.2 (at least in the case of zsh-4.2.6). All I needed to do to get OSTYPE to be correct was to uninstall the zsh package and install the package that was released with OpenBSD 4.2. Now let’s see if we remember when OpenBSD 4.3 is released…

Sed on Mac OS X 10.5 Leopard

Imagine you’re a PHP developer that uses OS X. You’re given 50+ php files that all have a line that needs to be changed. 50 files, one change? Hmmm sounds like maybe I could use automator to do this! Well I don’t know how to use automator ;) Luckily, I’m a unix geek, and even more luckily, OS X has a fairly strong unix back end and a great terminal emulator. So how does that help? Well if you’re a unix geek you know that this sort of problem just screams “SED! use SED! this is what SED IS FOR!” And it’s true. This is where sed is great.

Say you want to change this line:

 $config_file = $_SERVER['DOCUMENT_ROOT']."/dev/config.php";

To this:

 $config_file = "dev/config.php";

As a matter of fact… wait a minute! I don’t want to just change that line… no I want to be able to show what I’ve changed, so that the next person who looks at this can see what it used to say. In this instance it’s also important to show the work I’ve done because I’m making changes to someone else’s work. So what I want to do is comment out the line and then add a new line with my change underneath. Sounds a bit more complicated right? Well it’s not really – unless you’re using OS X (you’ll see why in a minute *sigh*). The goal is to end up with this:

 //$config_file = $_SERVER['DOCUMENT_ROOT']."/dev/config.php";
 $config_file = "dev/config.php";

On the linux machine I keep around the office the command to perform this change on the all php files in the current directory looks like this ( I had to split the line to fit on the site):

sed -i .bak "s/^\$config_file = \
\$_SERVER\['DOCUMENT_ROOT'\]\.\"\/dev\/config\.php\"\;/\/\/\
\$config_file = \$_SERVER\['DOCUMENT_ROOT'\]\.\"\/dev\/config\.php\"\;\
\n\$config_file = \"dev\/config\.php\"\;/g" *.php

The breakdown of the above command is as follows:

sed | the sed command

-i .bak | the -i option means do this change “in place” and copy the original file to originalname.bak

| we use the double quote here to start the sed command because there are single quotes in the command

s/^\$config_file =
\$_SERVER\['DOCUMENT_ROOT'\]\.\”\/dev\/config\.php\”\;/\/\/\$config_file
= \$_SERVER\['DOCUMENT_ROOT'\]\.\”\/dev\/config\.php\”\;\n\$config_file = \”dev\/config\.php\”\;/g
| this is the magic of sed. it looks for the line we want to change, adds // to the beginning of it, adds a new line after it, and then adds the text that we want after the new line. Amazing isn’t it?

| the command ends with the double quote

and, finally:

*.php | represents all of the files that end in .php in the current directory.

Now if you thought that was a mess, check out how that command needs to look in order to work on OS X (10.5.1, possibly other versions)

sed -i .bak "s/^\$config_file = \
\$_SERVER\['DOCUMENT_ROOT'\]\.\"\/dev\/config\.php\"\;/\/\/\
\$config_file = \$_SERVER\['DOCUMENT_ROOT'\]\.\"\/dev\/config\.php\"\;\
\\"$'\n'"\
\$config_file = \"dev\/config\.php\"\;/g" index.php

The crazy part here is the need to use \\”$’\n’”\

What that represents is an escaped version of the literal newline character. With the version of sed currently in OS X, that is the only way (that I could find) to add a newline character with sed. Now you know too.

So that concludes this edition of mac unix geekery… until next time…

I just noticed that when you use the mysql 5 client from MacPorts (installed as /opt/local/bin/mysql5) to connect to a mysql5 server running on localhost that was installed via the package at dev.mysql.com, an error is generated:

ERROR 2002 (HY000): Can’t connect to local MySQL server through socket ‘/opt/local/var/run/mysql5/mysqld.sock’ (2)

This is because the installation of mysql 5 server from the mysql site uses /tmp to hold the socket file. Of course if you read the README you’d know this:

“The installation layout is similar to that of a `tar’ file binary
distribution; all MySQL binaries are located in the directory
`/usr/local/mysql/bin’. The MySQL socket file is created as
`/tmp/mysql.sock’ by default.”

I, of course, did not read the README first, and so I wondered what I was doing wrong. The fix is easy, just add

-S /tmp/mysql.sock

to your mysql5 command to use it without any configuration (i.e. changing the location of the socket).

Xserve's new iLo (LOM)

I was looking for a way to configure iLo (itegrated lights out) on the new Xserve. Funny thing is after googe and yahoo and searching like crazy all over the place, the one site I should have checked first had the answers 1 few clicks away. I found this doc on apple’s site in the support section: http://docs.info.apple.com/article.html?artnum=304896

Which describes the 3 methods of setting up what Apple calls LOM (lights out management). I was searching all over for ilo when it was called LOM the whole time. Hopefully this will help someone else who searches for how to set up/configure ilo on the apple xserve.

What follows is a rant/review of Yellow Dog Linux 5.0.2. It’s the second part of the “Golden Apple Project” article series, which tells the tale of my quest to transform a formerly unused Apple PowerMac G4 (450Mhz, AGP Video) into something more useful than an unused OS 9 machine.

After a somewhat discouraging attempt at installing NetBSD (see the first article in the series), I decided to try the OS that first showed me how nice the PPC architecture is for Linux – Yellow Dog. I figured that since Yellow Dog was great when I tried it about 2 or 3 years ago it would be even better now, especially with all the support Terra Soft has been getting from Sony. What I found, however, was that YDL was not quite what I had hoped. In fact I was very disappointed.

When I install an operating system I look for a few basic things, the first of which being a quick and reliable way to install. I’ve installed several operating systems and several distributions of Linux and so far Yellow Dog is the only one that requires either a 3+GB DVD or 6 CD’s to install. 6 CD’s and every one is required? That is simply insane. What if I just want to try the OS for a while? What if I only need a minimal system? What if I don’t have enough hard disk space to install every application under the sun? Yellow Dog Linux was not designed with these “what if’s” in mind.

After a few unsuccessful attempts at downloading the DVD ISO image (each attempt stalled at or near 2/3 completion, which is not YDL’s fault but still not fun) I decided to get all 6 CD images burned instead. At least this way I would be able to download the distribution in smaller chunks. I thought that since I already downloaded everything that the install would go fairly quickly. I was wrong. It took about 2 and a half hours to install from the CDs. Granted, it’s an old 450Mhz machine with a slow FSB and 256K ram, etc. but still – 2 and a half hours is a long time. I moved forward though… swapping discs when asked and watching anxiously as the installer showed me that it was copying package after package of open source software (none of which I was allowed to choose or not choose).

When I tell you I watched anxiously, I am being very literal. The install process consisted primarily of watching the installer. It didn’t ask me any questions. It didn’t let me make any choices. It only prompted me to insert CD after CD. After disc 6 I was finally asked for the root password and was invited to create a user account for myself. I expected to be asked for some networking information at least, but was not. Root password and user account name and password. That’s it. I tried to tell myself that it was a hassle-free install (again since I don’t count the download as YD’s fault, really), but I couldn’t get over the fact that there was no way to configure the network during the install. Normally I would configure the network first, and use it to install the operating system over the network via FTP or HTTP. With YDL network installs are not an option but I would have liked to have my network configuration done before first boot.

So far YDL had already been an unusual experience, and I hadn’t even gotten to first boot. As the machine restarted I told myself that the worst was over and that after I logged in and configured the network everything would be fine. Wrong again. I logged in with the user account I created during the install and saw a very nice looking E17 desktop. I must admit – E17 is coming along nicely. The only word I could use to describe it right now is… pimp! hahaha :) I mean wow. It’s one gorgeous desktop. Kudos to the E17 team. Unfortunately however, this desktop was basically for my viewing pleasure only. No program would start that was not already running for me, neither from a launcher, nor a menu. Not even the “run command” box worked for me. Seems the user account was running as a different user than X and had no permission to the display. Nothing would work as the regular user except logging in and logging out. The word that best describes this is LAME. If you are keeping track of the adjectives so far you’ll see that the negatives outweigh the positives already.

At this point I had basically lost faith in the YDL distribution. I have seen desktop Linux come a long way over the past few years and YDL took me back to a time when I could undoubtedly expect more problems than ease with Linux. Yet, I logged in as root just so I could at least take a tour and see what all of that downloading and waiting and watching would get me.

As root, launchers worked and the menu too. Firefox started and was very responsive, even with the limited resources. Even OpenOffice’s writer and spreadsheet programs worked fairly quickly. I was reminded that the PPC architecture is great, even without OS X. This moment of happiness was short lived – I found out soon after opening Firefox that there was no flash support for Apple PPC Linux. There will most likely never be official Adobe Flash support for Apple PPC Linux. That saddens me but not to the point where I’m going to give up on the whole project.

I looked around some more and found some more things I didn’t like (while trying to find things to like). Apache came pre-installed and so did Java and Python. PHP and Ruby were left out though, and those are my two favorite languages to code with. Some Gnome games were installed, but not Gnome sudoku (which is awesome, btw).

In summation, if you add up all the adjectives you get this – Yellow Dog Linux on Apple PPC is a disappointing, lame, pimp (remember that E17 is PIMP). A disappointing lame pimp that saddens and frustrates the user, but looks so nice. What else can I say? At least it’s better than OS 9? I’m not sure I can even say that. I guess any Linux is more fun to use than OS 9… but a crippled desktop is a crippled desktop, pimped out or not.

So where does this leave the Golden Apple Project? To paraphrase the beautiful Joss Stone… My hopes for this old PowerMac G4 are “Bruised but not broken”. I’m going to try OpenBSD… and I have plans to revisit NetBSD as well. There is no giving up on this quest! Stay tuned…