Hopefully I won’t run into any more issues, but if I do and find ways to fix them, I’ll try to let everyone know.

Oh, one more thing. I was happy to discover that iChat now has the option to automatically rejoin chat rooms. That was a big hassle for me in the last version of iChat.

Here are some of the more interesting stats:
Of the students living in the dorms, as of right now (7pm on 9-12-06):
93% of all 1st years, 94% of all 2nd years, 91% of all 3rd years, and 88% of all seniors years have registered at least one computer on the network.

I personally was surprised that the percent for upperclassmen was so high, because when they entered college the percentage was quite a bit lower. (Although our statistics weren’t as good back then.)

Other stats of interest:
The percentage of students with computers with at least one OSX computer is 17% for 1st years, 13% for 2nd years, 15% for 3rd years, and 12% for seniors.

There are also interesting patterns in whether students have registered a computer on the wireless and/or wired networks. A surprising number of students still haven’t bothered to register their wired ethernet card.

year (wired%/wireless%) 1st year (68%/77%) 2nd year (78%/69%) 3rd year (78%/56%) 4th year (77%/51%)

As you can see, there are still 49% of all freshmen who have registered their wireless card but not their wired card. The spread was even more drastic as students moved in.

If you’re curious about other statistics, feel free to comment on this post (or stop by) and ask!

[UPDATE]  Ok, so I found another temporary fix just short of rebooting.  If I kill the coreaudiod process and start up iChat again, I get my sound effects a.k.a. alerts back.  To do that, I opened up Terminal, ran:

ps -aux | grep coreaudio

To get the process ID as can be seen here:

root        32   0.3  0.2    29808   1816  ??  Ss   Tue02PM   1:10.80 /usr/sbin/coreaudiod

The process ID is 32.  So then I quit iChat, and ran this to kill the coreaudiod process:

sudo kill 32

Then start iChat and you should hear the familiar alert sounds again.  Yay!

First, we enabled ssh and ARD on all the computers and restricted who could access those services. For ssh we added a line like this to the end of /etc/sshd_config:

AllowUsers ourAdminUsername

Once we were able to ssh into each computer, we wanted to be able to have a script be able to do that. It makes it much easier if that script does not need a password. To do that, we placed a copy of authorized_keys with our servers ssh key in it in /var/root/.ssh/

Once that file is in place, we can now ssh from our server into any of our OS X machines and run any command. So, lets say we want to run Software Update on a computer. All we have to do now is this:

ssh "root@hostname.example.com" "/usr/sbin/softwareupdate -i -a"

To do this to a large number of computers, you just need a script that will run that command once for each of your systems. Right now we do that with a simple text file containing a list of IP addresses for each system, loop over them and run that command. In the future we plan to generate that list of IP’s from an inventory database so that they are always up to date.

One other issue is that if the computer is not awake when we want to do the maintanance, ssh won’t work. So before we ssh we need to run ether-wake on our linux box that has an interface on each subnet on campus. From there it can send a magic packet to each computer and tell it to wake up. Once it is awake, we can ssh in and run our maintanance script.

This setup has also allowed us to update Firefox on all the Mac’s since all we have to do is scp the application. For example we did it something like this:

/usr/bin/scp -pr /tmp/Firefox-test.app "root@hostname.example.com:/Applications/";
/usr/bin/ssh "root@hostname.example.com" "mv /Applications/Firefox.app /Applications/Firefox-old.app";
/usr/bin/ssh "root@hostname.example.com" "mv /Applications/Firefox-test.app /Applications/Firefox.app";
/usr/bin/ssh "root@hostname.example.com" "rm -rf /Applications/Firefox-old.app";

And just like that, the computer has a new version of Firefox all ready to use. Of course it is best to do the upgrade when no one is using Firefox. To help with that we use Apple’s Remote Desktop software which will easily allow you to see if someone is logged in to the computer and let you know what they are running.

However, I did still run into a problem. The server I am publishing to has a self signed certificate. iCal does not like the self signed certificate and just tosses up an error message about the servers name not matching the certificate or something like that. To work around that probem I visited the site with Safari, looked at the details of the certificate, checked the box to remember that I want to trust this certificate, changed all the other trust things at the bottom of the screen. Then when I revisit the webite it no longer bugs me about the certificate. Next I restarted iCal, and now I can publish my calendar again. Yay!