Archived Posts from: Computer Stuff


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…

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).

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.

The picture says it all…

Internal Error: Success

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…

The other day I acquired a hardly used PowerMac G4 from someone who was going to throw it out. Imagine that? It’s got a 450Mhz PPC CPU, 256MB of RAM, a 20GB hard drive, and AGP video. Certainly this nice little machine can be used for something… But what?

Though I could probably get away with an install of OS X Tiger, I knew in my heart that it would be wrong to use the Tiger install disk that I have to install it on a second machine. Actually I just thought it would probably run too slow, but hey it’s still illegal and that’s not how I do things… right? Right. So it was just a question of whether it would be Linux, NetBSD, OpenBSD, or some other free OS. I decided to try NetBSD first.

NetBSD has supported PPC for a while, just one of the many architectures supported by the ultra portable BSD. The story here is fairly short and somewhat funny – I was able to install the OS but never figured out how to get it to boot. Lesson learned: Knowledge of Open Firmware is essential when you’re dealing with an Apple PPC machine like the PowerMac G4. I found this site and this site to be helpful, as well as the install notes for NetBSD. Oddly though, even following the notes to the letter I was unable to boot the OS. I gave up after seeing that my Open Firmware 2.4 system might not be supported at all due to what might be a “broken” Open Firmware. In hindsight I think I was just using the wrong device designation in my boot command. I might try it again.

In part II of the Golden Apple Project I try out Terra Soft’s Yellow Dog Linux. Which operating system will win the right to run on my shiny old G4? Stay tuned to find out!

« Previous PageNext Page »