Utah Open Source Planet

I overhead an exchange between two friends that I thought was interesting. One needed help from the other and asked him to SSH into a machine. The place where the second friend works blocks outgoing port 22, the port SSH lives on. Don't ask me why. The solution? Friend one does a screenshare to friend two who uses the shared machine to SSH. First time I've seen screensharing being used to tunnel SSH.

Tags: osx screenshare leopard ssh networking

How fun is school.

Yeah, it’s not. Especially when you’re starting a new job, too.

The fun part is, I got a dark red 2004 Nissan Maxima. Which I am currently enjoying a great deal.

None of which has to do with Linux. But it’s my blog and I get the liberty of going off topic. At least I’m posting.

So I thought I’d take on the challenge of doing a triple-boot setup on my laptop. Yawn, right? Everyone’s done that.

Except not everyone has done it with Windows Vista, MacOS X Leopard, and OpenSUSE 11.0 all on the same non-Mac machine. A machine much like my Dell Inspiron E1705.

I took said challenge, and it only took about 23 tries before I got it.

Here are some pictures of the machine booting, logging into, and the desktop of each OS:

OpenSUSE 11.0

booting

Click for larger image

login

Click for larger image

desktop

Click for larger image

MacOS Leopard

booting

Click for larger image

login

Click for larger image

desktop

Click for larger image

Windows Vista

booting

Click for larger image

login

Click for larger image

desktop

Click for larger image

Most often, I will be hanging out in the OpenSUSE 11.0 installation. For that annoying software that only runs in Windows, I am forced, completely against my will, to have it on the machine, as well. And, I have recently become interested in the iPhone SDK, which of course only runs in MacOS 10.5.2 (Leopard) or newer. Hence, the need for all three OSes. And, I have just never seen it done, so I thought I’d jump in and do it. Instructions mostly came from here.

Fascinating.

So, back to the off-topic. I am selling a white 2004 Ford Crown Victoria Police Interceptor (click for larger image):

For all the information you could ever want about the car, including lots of pictures, take a look at this page.

Next week we are running a Final Cut Pro 5-day class to prepare students for the Final Cut Pro exam and get more familiar with the software.  It’s great, except the software is huge and doesn’t load into a monolithic system image very well.  As such, I had to find a way to deploy the software in a timely manner without a lot of work or overhead.  

I started first with a modular NetInstall image.  The idea was that I would include the software packages in the install image, it would create the image, and I could install it without worrying about configuration.  Boy was I being hopeful!  At first it would not recognize the software, and then it finally accepted the mounted disk images as I dragged them into the Automator Action.  I thought all was well, until I tested the image.  

It installed the OS just fine, but didn’t include the Final Cut Pro packages.  Well, I thought, I would just need to create a base install, and then deploy the software through a package.  Seemed easy enough, at least..

Mac OS X 10.5 has a great feature with PackageMaker (available with the XCode Tools Development package) that is called a Snapshot Package.  Basically, you can install software on your Macintosh Computer while this is running, and PackageMaker can tell the difference between the original state of the machine and the new improved state.  You can then create a package that would install all the changes across the board, and you would be all set.  

I started by using PackageMaker on the MacBook Pro that I would be using for the class.  I then started the process on the MacBook Pro, installed Final Cut Pro and the Motion Content, and waited.  Once done, I stopped the snapshot, reviewed the changes, and tried to make the package.  PackageMaker crashed on me every time.  I tried three different MacBook Pros, each with the same result.  

At that point, I started to get frustrated.  I tried the same process on my office Mac Pro, and it worked!  I was able to make the snapshot image, and create the package.  I then transferred it to a MacBook Pro computer and started the package.  It ran, told me it was successful, and I was sitting on cloud nine!  Until I tried to run Final Cut Pro, that is.  It would crash every time I tried to run it.  It could have been a permissions issue, but by this time I was running out of time.  I have a busy week with a surprise class and some instructor interviews to conduct, and I needed to come up with a solution quickly.  

So, I tried installing the software on a MacBook Pro from disk images using the installer command from the Command Line.  It worked, installed a bit more than we usually do, but otherwise was successful.  Well, if this would work, surely I could create a script that would mount the images, install the packages, unmount the images, and delete the images to free up space.  It was worth a try. 

The script was easy to write, and is below: 

#!/usr/bin/env bash

# This script should install Final Cut Pro and Motion from disk images.
# The script will need to be run as root, which the package should do
# automatically.
# First it will mount the images, and then it will run the Installer
# scripts for Final Cut Pro, and then Motion.

# The Images are assumed to be in /Users/Shared

hdiutil mount /Users/Shared/Final\ Cut\ Studio.cdr
hdiutil mount /Users/Shared/Motion\ Content.cdr

# Now the Installation will be run.

installer -pkg /Volumes/Final\ Cut\ Studio/Installer/FinalCutStudio.mpkg -target /
installer -pkg /Volumes/Motion\ Content/Installer/MotionContent.mpkg -target /

# Once finished, the script needs to unmount the images.

umount Volumes/Final\ Cut\ Studio
umount Volumes/Motion\ Content

# Now no longer needed, the disk images can be deleted.

rm -rf /Users/Shared/*.cdr

The Script worked on my inital testing, as long as it was run in sudo (installer needs to be run as root).  So I took it a step further and set it up as a package.  I opened PackageMaker again, added both the disk images to it and set the install location to the /Users/Shared directory.  I then added the script to the last package (in this case Motion) as a postinstall script, so that it would run after the Motion image was copied.  I created the images without any errors, and tried the deployment:  Success!  It installed just fine, and everything worked in Final Cut Pro that was expected to work.  

So, I then figured that if this worked, surely it would work if I added it to a NetInstall image, right?  So I created a new NetInstall image workflow that would add this image to the NetInstall.  I then tested it out, and it still didn’t install the package.  So, I copied the package to the server, shared it out, sent the package to each machine, and installed it manually from there.  In the end, I got the deployment working, and the total deployment (not counting the time taken to try and create images and such) took about half the amount of time it would have if I installed everything with the CD’s.  It could have taken even less time if I had Apple Remote Desktop installed and used it to deploy the image.  

So, that was my experience.  I’m going to look at the NetInstall workflow to see if I missed something in how I placed the Automator Action for the package install.  Until then, I still have a very viable deployment solution that takes less time than I would have expected.  ^_^

I’m back from the Chicagoland area, and It’s good to be back home.  The trip home was mostly without incident, with both planes actually arriving on time (or earlier).  The trip was pleasant, and I made some really great friends with other instructors and developers out there within the ranks of the Apple Certified Instructor network.  

So, what about the training?  

Directory Services:  The Directory Services class was phenomenal.  It focused on connecting to various directory systems out there (both Active Directory and OpenLDAP), using the built in GUI tools, third party tools, and using the command line utility.  

We spent a lot of time demoting and promoting our servers to Open Directory Masters, while connecting to another directory system and making an Open Directory Replica.  

I learned a lot of new things at the training, mostly on how to replicate and create backup Directory systems for failover.  I’ll start covering each chapter in more detail as time permits, but needless to say it was a very useful class.  

Overall the flow was well designed.  The material was a little lacking in that some work in the workbook was not available or mentioned in the reference guide.  But other than that, it was well done.  The cognitive load was well managed with the timing of the class, and the constructivist method was well represented in this material.  Arek Dreyer, who wrote the reference guide, did a great job with the work.  I hope he works on the material again with the new 10.6 materials for which Apple Training is already planning.  

Advanced System Administration:  I want to preface this review by mentioning how this class was originally conceived.  When 10.5 came out, Apple Training looked at the existing certification and noticed that an Apple Certified Systems Administrator could go the whole certification process without once taking anything more than Server Essentials.  

Apple wanted to make the certification more meaningful, and so decided that knowing how to set up the environment was more important than knowing how to manage an Xsan or Podcast Producer.  And, quite honestly, they were right.  A Systems Administrator needed to focus on the core system that allows for Xsan and Podcast Producer to work well with the rest of the system, and not just the peripheral systems.  

So, basically, anything that didn’t fit into Deployment (system imaging and image maintenance) and Directory Services needed to be dumped into this class.  As such, the class is 5 days long and still too short for the material.  It’s also a fairly new class, as it is the only class that was not recreated from Tiger classes.

So, what do I think of it?  It definitely shows the signs of a kitchen sink class.  If you don’t have experience in the Command Line and didn’t take any of the other classes, you would be totally lost on this one.  It is completely designed to be a capstone course, and allow the student to design their own solution while completing the class.  

But there are problems:  If you don’t focus on the on-going narration (which the instructor had better be creating along the way for the sanity of the learners), then you can easily get lost in the details.  There is a lot of focus on current UNIX solutions, potential issues, tools that are still in development, and proprietary command line tools that Apple has created to manage their utilities.  All this is thrown at the student in four pillars:  Planning and Implementation, Networking, Administration (monitoring, security, and automation), and Troubleshooting.  

The narration is thus:  You have just been hired as the new PretendCo Systems Administrator, and the company is on the cusp of huge growth.  You find out that the company, up to now, has been running on one server, set up as a Standard configuration system for convenience.  You now have to do some real management to scale up the system you put in place in order to cope with the new growth expectations.  

For me, it’s going to be a challenge to teach this in a For-Credit schedule, if just because the course narration will be really difficult to keep in the student’s mind.  When I offer this class, I’ll be spending a lot of time focusing on the instructor notes, so that I can keep that narration flowing.  I may need to build the narration into some online exercises as well.  

So, overall, Directory Services was a hit, and a blast to teach.  Advanced System Administration was great, but I was honestly only able to keep up because of what I had already known having both taken all the previous Apple classes, and my experience with Linux.  I’m thinking that I may make the Linux Fundamentals a prerequisite for taking this class.  That way I can know that my students have had time to whet their experience on a UNIX environment in the command line.

This week I finish up with my T3’s for Apple with Advanced Server Administration.  This class is focused primarily on running the ADDIE process (Analyze, Design, Develop, Implement, and Evaluate) throughout the IT  infrastructure of a company, and build it up using both the GUI and Command Line tools.  Because it is assumed that you have been learning the GUI tools up to this point (this is the capstone course), it primarily focuses on the command line tools available to the Mac.  

I’m not sure when we will offer the class at the U, as much depends on other training offerings and any additional infrastructure we would need, but I already have a lot of people interested in this class.  Most of them are Linux administrators who are going to be supporting the Apple platform, and want to do so with SSH (just as they would with Linux).  I already have a list of people who would love to take that class.  

Anyway, it all hinges on whether or not I’m judged “good enough” to train.  Partly judged by my peers, partly judged by the Master Trainer, my fate rests in their hands.  At this point, however, I’m less concerned.  I’m rather more concerned with how my family is doing back home.  I’m literally counting the days until I fly out.  But I will miss the Chicago area.  

Anyway, more details on the classes I attended during this trip sometime next week.  I’ll give a teaser for the classes, and give you my opinion of the materials and flow of the class.  

As promised, here is my review for the Mac OS X Deployment 10.5 T3 that I attended this last week.  

First, the location.  Of course I’m biased, but I have always loved Chicago, and as such enjoyed the trip Villa Park and Oakbrook Terrace.  The hotel was nice, and the location of the training facility was fairly easy to get to.  The only problem:  no sidewalks.  It makes it difficult to walk when you don’t have sidewalks, and there isn’t enough room to walk on the street (without getting hit).  Other than that, the location was nothing to complain about. 

The materials:  There are quite a lot of material for this class, and I was a little concerned that it would be impossible to fit it all into a 2 day training.  Luckily, that was the thought of the course developers as well, and as such the training was extended to 3 days.  That fits in perfectly with my training schedule I have planned for the University, so I didn’t complain. 

The Subject Matter:  There was still a lot that I wanted to cover but couldn’t in the class, mostly those focusing around the command line.  But then, there is a separate class for that, which I will be attending in two weeks.  ^_^  But those important topics, such as deploying through the command line, and imaging through the command line, were covered in depth.  Also planning, scaling, and third party utilities for managing a deployment option was well covered.  

One really nice thing I liked about the class was a mandate for the student to immediately apply what they have learned to a real world situation.  They do this through a Deployment planning sheet, which the trainer should have printed out for each student.  We didn’t have it, but it was made available to us in PDF form, and there is a link that comes with the learning materials to PeachPit’s website for the same PDF.  Once the form is filled out, the last chapter talks about real world solutions in many large companies, school districts, and training centers, and gives the student time to go through their document to see what they find useful, and what they don’t need, in their deployment of OS X.  

The Requirements:  It is essential the student have a command of both the Mac OS X GUI and have command line experience before starting this course.  Basically, students would need to have completed at least the Server Essentials course, and be able to manage a UNIX command line experience.  Why?  Because at the beginning of the course you are just expected to set up your computers with little assistance from the book.  At this point, it is expected that the student knows already how to set up a brand new install of Mac OS X. 

The command line experience would be more along the lines of familiar with syntax of commands.  Most, if not all, of the commands used are Mac OS X Utilities and not your typical UNIX commands, yet the syntax is the same and therefore the student needs to be familiar with that syntax.  There may be some situations when troubleshooting is necessary, and as such the student will need to know how to get to the man pages.  

Something else that would be important before taking this class is having troubleshooting knowledge, and an understanding of what you are being prepared to learn.  This way if something doesn’t quite work they way it’s written in the book, you can step outside of the given examples and find alternatives.  That’s part of learning, something that many students I have had in the past didn’t quite understand.  It requires reading/studying ahead of time, asking questions, and being attentive.  

The Pace:  Unlike both Support and Server Essentials where we pend a lot of time trying to catch the class up after some really long first setup exercises, this class is paced just right for the materials.  We as a training class (of 10 trainers) finished with plenty of time on the last day to cover some topics more in depth, and that was with us doing the majority of the optional exercises.  So with a typical class at this level, the pacing will be such that students will have some time to play with some configuration, or perhaps have a long lunch as a thank you for coming to the class.  

Overall, it is the best designed Apple training course I have attended so far.  The materials are well designed, the pace is just right (low to medium cognitive load), and the course talks well to adult students (through Constructivist methods).  This is a class that may not run often here in Utah, but will most likely be a well attended class when it does.  It is by far my most favorite class to date.  ^_^  

Also, I’d like to say thanks to everyone that attended, because they gave me some very welcomed constructive criticism, and the Master Trainer was a great host.  If only the Cubs could have won all three games I was there, rather than just one of the two.  Oh well, there is always next time.  

I thought I would post this, as we had a similar situation within our class with this issue. At times, when you try to start Kerberos in Mac OS X 10.5 Server, the domain gives you trouble. The first thing you should do is check the host name with changeip, and determine the issue with your DNS. Then, you can fix your Kerberos issues with the following steps as found here on Apple’s documents page:

1. Fix Your DNS: This is necessary, otherwise steps below will not work.

2. Fix your /etc/hosts file: Best done in Terminal. Run sudo bash and authenticate to get to root, and then run vi /etc/hosts. Once in there, add your server’s IP Address and fully qualified domain name, like this: 10.1.0.1 mainserver.pretendco.com

3. Set your Host Name: This can be done as root with the following command: scutil –set HostName mainserver.pretendco.com. Replace the Mainserver entry with your own domain name in this step, and all subsequent steps you see.

4. Initialize Kerberos: This requires three steps (and being logged in as root):
slapconfig -kerberize diradmin MAINSERVER.PRETENDCO.COM (diradmin would be the directory admin login name)
sso_util configure -r MAINSERVER.PRETENDCO.COM -f /LDAPv3/127.0.0.1 -a diradmin -p diradmin_password -v 1 all (replace diradmin and diradmin_password with your directory admin and password)
sso_util configure -r MAINSERVER.PRETENDCO.COM -f /LDAPv3/127.0.0.1 -a diradmin -p diradmin_password -v 1 ldap

Once you finish these steps, reboot the machine, and check your Server Admin utility. You should see that you have all your services running on your Open Directory Master.

Even with this trouble, Kerberos seems really simple to set up with a Mac server. I’ve never tried it on a Linux server, but from the expressions on some friend’s faces when I suggest it, it doesn’t seem to be very simple. I’m not sure how it’s implemented in Active Directory either, though I do know it’s just as frustrating when it doesn’t work.

I thought I would post this, as we had a similar situation within our class with this issue. At times, when you try to start Kerberos in Mac OS X 10.5 Server, the domain gives you trouble. The first thing you should do is check the host name with changeip, and determine the issue with your DNS. Then, you can fix your Kerberos issues with the following steps as found here on Apple's documents page:

1. Fix Your DNS: This is necessary, otherwise steps below will not work.

2. Fix your /etc/hosts file: Best done in Terminal. Run sudo bash and authenticate to get to root, and then run vi /etc/hosts. Once in there, add your server's IP Address and fully qualified domain name, like this: 10.1.0.1 mainserver.pretendco.com

3. Set your Host Name: This can be done as root with the following command: scutil --set HostName mainserver.pretendco.com. Replace the Mainserver entry with your own domain name in this step, and all subsequent steps you see.

4. Initialize Kerberos: This requires three steps (and being logged in as root):
slapconfig -kerberize diradmin MAINSERVER.PRETENDCO.COM (diradmin would be the directory admin login name)
sso_util configure -r MAINSERVER.PRETENDCO.COM -f /LDAPv3/127.0.0.1 -a diradmin -p diradmin_password -v 1 all (replace diradmin and diradmin_password with your directory admin and password)
sso_util configure -r MAINSERVER.PRETENDCO.COM -f /LDAPv3/127.0.0.1 -a diradmin -p diradmin_password -v 1 ldap

Once you finish these steps, reboot the machine, and check your Server Admin utility. You should see that you have all your services running on your Open Directory Master.

Even with this trouble, Kerberos seems really simple to set up with a Mac server. I've never tried it on a Linux server, but from the expressions on some friend's faces when I suggest it, it doesn't seem to be very simple. I'm not sure how it's implemented in Active Directory either, though I do know it's just as frustrating when it doesn't work.

For my musical notation needs, I use LilyPond.

LilyPond is to music as LaTeX is to writing. I prefer to edit LilyPond files in Vim and compile them with lilypond at the command line. However, on OS X LilyPond.app is a front end to the compiler. An IDE of sorts. Not a spectacular one, in my opinion, but it does have one thing going for it: when you click on a note in the PDF preview, it takes you that note in your LilyPond source file in the IDE.

On Leopard, LilyPond is severely broken. The IDE will "start", but there is no menu. Further, if you are on Intel, when you try to run it at the command line, it just keels over and does nothing. It so happens that the workaround to this problem and using LilyPond without the IDE are almost identical solutions, so I'll describe them as one and the same.

First, and this is the only difference between Leopard brokenness and just wanting to run on the command-line, you want the powerpc version of LilyPond.app, not the Intel version. So go over to the download page and get the ppc version (the one that says it's for G3, G4, G5 Macs).

lilypond and its friends are in Lilypond.app/Contents/Resources/bin. You could add this to your PATH, but some of the binaries in there are things that I have installed elsewhere (e.g. with MacPorts), and I don't want them overriding my PATH. Likewise, I want lilypond to be able to find the binaries it expects, and since they're taking up disk space anyway let's help it along. So I wrote a script. A LilyPond launcher if you will. I call it ly and put it in my path, and then I call e.g. ly lilypond foo.ly. Here's the code:

#! /bin/sh
APP=/Applications/LilyPond.app
PATH=$APP/Contents/Resources/bin:$PATH
exec "$@"

Customize APP to point wherever you want to keep LilyPond.app. This will load up the environment that will give lilypond the best chance of success. You can run any of the binaries in that directory with ly, but the most common case is to run lilypond. So I recommend putting this in your .bashrc:

alias lilypond='ly lilypond'

The first time you run the ppc version of LilyPond, or anything else, on an Intel machine, it will seem to take forever while Rosetta fires up. Be patient. Subsequent invocations are quick enough.

For my musical notation needs, I use LilyPond.

LilyPond is to music as LaTeX is to writing. I prefer to edit LilyPond files in Vim and compile them with lilypond at the command line. However, on OS X LilyPond.app is a front end to the compiler. An IDE of sorts. Not a spectacular one, in my opinion, but it does have one thing going for it: when you click on a note in the PDF preview, it takes you that note in your LilyPond source file in the IDE.

On Leopard, LilyPond is severely broken. The IDE will "start", but there is no menu. Further, if you are on Intel, when you try to run it at the command line, it just keels over and does nothing. It so happens that the workaround to this problem and using LilyPond without the IDE are almost identical solutions, so I'll describe them as one and the same.

First, and this is the only difference between Leopard brokenness and just wanting to run on the command-line, you want the powerpc version of LilyPond.app, not the Intel version. So go over to the download page and get the ppc version (the one that says it's for G3, G4, G5 Macs).

lilypond and its friends are in Lilypond.app/Contents/Resources/bin. You could add this to your PATH, but some of the binaries in there are things that I have installed elsewhere (e.g. with MacPorts), and I don't want them overriding my PATH. Likewise, I want lilypond to be able to find the binaries it expects, and since they're taking up disk space anyway let's help it along. So I wrote a script. A LilyPond launcher if you will. I call it ly and put it in my path, and then I call e.g. ly lilypond foo.ly. Here's the code:

#! /bin/sh
APP=/Applications/LilyPond.app
PATH=$APP/Contents/Resources/bin:$PATH
exec "$@"

Customize APP to point wherever you want to keep LilyPond.app. This will load up the environment that will give lilypond the best chance of success. You can run any of the binaries in that directory with ly, but the most common case is to run lilypond. So I recommend putting this in your .bashrc:

alias lilypond='ly lilypond'

The first time you run the ppc version of LilyPond, or anything else, on an Intel machine, it will seem to take forever while Rosetta fires up. Be patient. Subsequent invocations are quick enough.

growlnotify is a little program that comes with Growl which allows you to submit Growl notifications from the command line or from scripts. Unfortunately, it doesn't seem to work properly in Leopard—the notification only shows up maybe ⅓ of the time. There's a hint in the logs, but I have no idea what it means:

2008-02-13 10:09:15 GrowlHelperApp[17821] *** -[NSMachPort handlePortMessage:]: dropping incoming DO message because the connection or ports are invalid

Apparently the devs are pretty clueless about the problem too, as it's been reported but not yet fixed. The folk(s) over at hasseg.org came up with a workaround, which is all well and good, but I observed a simpler workaround than using the network (which requires configuring growl to allow network connections, if I'm not wrong). This little wrapper script does the trick, at least in my initial tests:

#!/bin/sh
wrappee=/usr/local/bin/growlnotify
exec $wrappee -w "$@" &

Basically we tell it to wait for notification from growl that the message is now off the screen, and then go in the background so we don't have to actually wait for it. This has the side effect of essentially rendering the -w option useless when using the wrapper, so I've decided to wrap it with a different name instead of a transparent wrapper. I call it growl, which is both shorter to type and not nearly as ugly as growlnotify. Enjoy.

As those who read this blog know, I have a love-hate relationship with Apple. The other night I completely finished a great blog entry on Facebook releasing its own Platform Architecture, similar to OpenSocial Containers, and Bebo being the first to utilize it. Well, I hit “publish”, and realized Leopard had killed my internet connection again! This, after I just installed another update that was supposed to fix everything.

I’m about fed up with Leopard, the problem is there’s not much better elsewhere. Every Operating System has its strengths and every Operating System has its flaws. I like Vista for its new interface and Entertainment (Media Center) Center capabilities. I love Linux as a server. I love Mac as my desktop because it gives me a great combination of both worlds and has a pretty interface. Unfortunately, Vista is bloated, Linux takes too much configuration to get up and running as a decent desktop, and Apple’s flaw? They can’t do a launch right, but continue to make fun of the competition. I had the same issues with Tiger when it launched, now I’m having problems with Leopard - DNS dying, internet randomly going down, applications crashing, grey screens of death. It’s driving me nuts! I just wish they’d stop picking on Microsoft and fix their own operating system! Frankly, I’m beginning to feel sorry for the poor Microsoft business man (the PC) that guy from Die Hard keeps making fun of in Apple’s commercials.

Great - my internet connection just went down again — Now What???

Share this article with a friend...

Now that I have things pretty much under control back home, I promised that I would post my impressions on the Apple Training upgrade to 10.5 that I attended for the past two weeks.

The Design
Overall, the design actually follows some instructional design techniques, unlike the Tiger materials. The student, as they progress through the course, must utilize the techniques, steps, and knowledge they had acquired in previous chapters. Building upon the previous material the students are reinforced in that material, and are not treated as mindless children that can't learn. Constructivist theories at the heart of it, which makes me happy. THe command line is no longer separate from the individual events that the commands apply to, but rather you learn the command line all through the book. Finally, the training becomes professional, and therefore something I am proud to offer at the University.

The Materials
The materials are being published through PeachPit, though the student kits will only be available to an Apple Authorized Training Center. They are very well done, with bits of the lecture in with the slide presentations. They no longer follow the Reference book, which has additional assignments should someone want to continue on with their learning in another direction. The only thing that I currently see wrong is having a place for notes, should the instructor choose to cover a specific topic in more detail. Other than that, it will be professionally bound, and cost less than the workbooks that were available from Apple. ^_^ Good news for any Apple Authorized Training Center.

The Test
now that I have taken both tests, I can say that the tests are written a little better than the previous test, though I took the longer version than will be available for everyone else. The test will be designed to have someone sit for 2 hours (mine was designed for someone to sit for 2.5 hours), and instead of killing all the easy questions, both easy and hard questions will be removed from the test. This way the test results will be generally higher, and passing will also need to be higher. For now, it will still be multiple choice, but they are looking into some real application and development along that front. What I would like to see is a practical sit-down test, similar to Red Hat's exams, which no one can just memorize an answer without learning something. Apple Training would like to see it as well, so it's good to see that we are on the same page. ^_^

The Staff
Apple Training has gone through a lot of changes recently, with most of the staff being laid off. This comes from a common belief that the Macintosh platform is so easy to use, there shouldn't need to be any training for it (i.e., the Apple Executives that don't want to pay for a Training Department). Unfortunately, this is the way many companies are moving, and leads us into a longer rant about the importance of training, and the quick decisions to axe training in corporate environments to save money. Anyway, those that are left are really the cream of the crop, and being led by someone that really has a fantastic vision for the direction training should go.

Final Thoughts
My trip to Austin was bumpy, my trip back was agitated. I had more bad experiences in Austin than I have had in just about any other city, but all in all I liked it. I'm actually making a plan to head down to San Antonio in a couple of years, as we plan a trip to Oklahoma to visit some family. So it wasn't the worst experience I have ever had in traveling (that would be the time I was in JFK and a baggage car rammed into our plane, delaying us 5 hours). All in all, it was productive, and this Spring we can start with the 10.5 materials. In the meantime, I am going to see if it's possible to set up a testing environment for the Macintosh that will let me grade someone on the progress they have setting up a machine, both at the Computer and Server level.

I just finished the first week of Leopard Training for Support Essentials. It was an interesting ride, and there is a lot that I like about it, and some that I'm not too happy with.

What I Liked
I have to hand it to Apple: When they contract to people to write their training materials, they do a good job. The three instructors that we had all wrote the materials in the Student Workbook, and the workbook now looks like it is worth the money you pay for it.

The course does eliminate the need for a key chapter that was my most popular when I taught the class: The Command Line. Now, instead of having a single chapter, we introduce it bit by bit, integrating it with each of the chapters. So now instead of just getting a quick look at how to play with the command line, you are using it actively in each chapter.

How is this better? Well, for those that are looking to integrate a quick remote method of troubleshooting on the Mac and don't want to bother with the bandwidth required for a VNC connection, they can quickly perform pretty telling troubleshooting tasks. In fact, I would say that more Command Line content is included in this course than in the previous course.

Other great things are the lack of Apple Remote Desktop (yay!), more focus on the core open source technologies available, and a focus on BootCamp (which is now integrated into Leopard). It's also nice to be able to repartition your drive, live, with Disk Utility without having to use a third-party application. Sure, linux could do that for years, but with Windows and previous versions of Mac you would need a third party app to get it done.

What I Didn't Like
The weakest point in the Apple training is perhaps the testing. It always has been, because there has never been a bank of questions, just one set of questions for each time you take the test. So, it's not a real evaluation of your knowledge. It's also problematic because in order to compensate, they provide obscure questions that require a constant study of the reference material instead of practical application. But then, it is a multiple choice test, and what else can you do?

The good news is that it's possible that new testing methods could be on it's way. I'm hoping for a more Flash-based virtual environment that will simulate the experience. Another possibility would be to have the training centers set up a physical exam, much the same way as RedHat exams, and allow the instructor/training center to deliver it. Of course it runs into consistency issues (from one AATC to another), but that is another topic all together.

Other than that, it was a good training situation. We got a quick peek at the future new exams that are coming down the pipe, and I'm really impressed with them. Finally, it feels like Apple is getting some real quality back into their training materials.

I'm really excited for next week, when we go over Server Essentials!

One of the benefits of being an Apple Certified Trainer is that I get neat updates from the Apple training staff regarding all aspects of the OS. Today, I got an update from Apple on the UNIX compliant status of Leopard from their site here. While I knew that 64-bit processing was a big thing for Apple in general, and I knew that the new Terminal was a sweet deal, I didn't know they had made a change to NFS, namely to make it Kerberized.

For those of you not familiar with the NFS (Network File System), you may not know why the change to NFS is so important. Sure, single sign on is a great thing in principle, but what's the big deal, right? Well, let's take you through the world of NFS.

NFS is a UNIX native file sharing protocol used to quickly share files back and forth. What makes it so quick? There is no user name and password authentication. Authentication is done through the UNIX UID. This is great in a Directory-specified network where everyone has their own unique ID, but what if you are logging onto the file share from your locally authenticated machine? Chances are you are logging in from a UID assigned to your local machine that will be assigned to another user. Take this scenario:

Tech A creates his server, and shares his files with NFS. His first account he creates is the Administrator account, which was assigned the UID of 501 (standard Admin UID for Apple, by the way). He then creates various other accounts, starting at UID 1025 and going up.

Marketing Director A gets a new machine and creates their first account, which is again an Admin account for that machine and also assigned the UID of 501. They then connect to the file server Tech A created with their account. They don't have to worry about authentication, because NFS authenticates from the UID. In this case, the Marketing Director has Admin access to the file server. Problem? Yes, most definitely. Also considering that anyone that creates a local account on their machine, be they a director or lowly janitor.

Apple had seen this coming, and in Tiger Server made it possible to map all NFS connections to the nobody user, and make all access read only. That did some good, but still lacked the benefits and security of authentication.

Now enter Kerberos. Because of the Ticket system that it utilizes, and the fact that authentication is not necessary once the KDC has authenticated the user on the network, there is no speed reduction in authenticating through Kerberos for an NFS file share. It also adds just one more service that is Kerberized for a Mac OS X Server. I am hard-pressed to think of one service that is not Kerberized with the new Leopard install. This, and the fact that starting a Kerberos KDC is so easy to do with Mac OS X Server makes it a good choice with small to medium-sized businesses.

So, in the end, NFS has finally come full circle. Created initially as a method to quickly transfer files for server-level processing (i.e., imaging and thin-client use), it now has the ability of secure authentication though Kerberos. Of course, if you don't want to use Kerberos, you can still use AFP, SMB, or Kerberized FTP for your file sharing needs. ^_^

For those couple people that have been following my blog for a while (thank you both!), you will probably remember me posting my woes and eventual triumphs regarding tribooting a MacBook Pro. I was trying to install a total lab image that would allow any instructor to teach a given class on their chosen platform without worrying about lab restrictions. It took a week, beating my head against a brick wall, and a lot of forum/blog readings to do it, but I finally managed to complete my mission.

If you remember, I also tried to use Fedora 7, but failed to get it to install properly. I then installed Ubuntu, which managed to install with a lot less coaxing than Fedora 7. Of course, the Linux classes that the University of Utah will be offering for credit (starting this spring! Two registered already! ^_^) will be focusing on either Red Hat or SuSE. Well, technically we could probably get away with Ubuntu, but I want the experience to be as close to the real thing as possible. That means getting Fedora to work.

The Download, Partitioning, Mac and Windows Install
I managed to find several repositories of the DVD iso for both i386 and x86_64 releases, so I downloaded them both. The final FTP mirror I used was located here on campus, so I was able to download both at about 7 minutes each (I love being at the U!). I then followed all the steps I outlined in September for the inital Mac 10.5 and Windows install. Yes, I am still using XP, if only because Vista isn't being used in our labs (and if our network guys have their say, it never will).

Fedora 8 x86_64 Install
I started the Fedora install by testing the disk. After the fiasco that was my Mac 10.5 upgrade, I'm playing it safe. ^_^ I then started the basic installation process. From what I remember of 7, Fedora 8 has a much more streamlined install process, more like Ubuntu Feisty. I was really impressed! I walked through the process, set up a partition as ext3 for Fedora, and then selected the software.

Then, I got worried. It not only didn't ask me what bootloader I wanted, but it didn't ask me where I wanted to install it. Bugger! Would I have to reinstall Windows, and compile Grub on my own? I really didn't want to do that, because it would be a mess. Well, we would just have to see. I started to sweat, worried that I would be in for another huge project that I had hoped would only take me a couple of hours.

I finished the install, and then rebooted the machine. Refit came up with all three images, which was a good thing (that didn't work with Fedora 7). Then I selected Windows. I would know if Grub had messed with the Windows MBR if it came up as I tried to boot. The screen went blank, my heart raced.. and Windows booted! I was thrilled!

I then rebooted to get into Fedora. The setup was beautiful, the boot clean. The desktop looks a lot like a cross between Tiger and Leopard, with a splash of Windows in there. Happy that the installation worked well enough for a Lab machine, I turned the machine off. Is everything working? I have no idea. Does everything need to work? Not at all! This isn't a machine that needs to run audio content, play games, or chat via the internet. This machine is meant to be a test environment for students to learn about the core OS.

Maybe, if time allows (after updating all the machines to both 10.5 and Fedora) I am interested in getting the Fedora install working at 100%, I will do that. But for now, I give a huge Kudos to the Fedora team for creating a boot installer that installs Grub on the destination Root partition, instead of the MBR for Windows. ^_^

Well, I finally got the Leopard upgrade, and I was really excited! The system works great, and I'm really excited to be using leopard (I've missed my virtual desktops!). But the upgrade wasn't all candy and roses. Let me spin my tale of woe, heartbreak, anxiety, and final triumph.

The Powerbook G4
I first installed the upgrade on a Powerbook G4 because I was impatient. This old machine has been my pride and joy for years, works like a horse, and takes a beating like an old Model T Ford. Well, at least it did before I updated. ^_^ My son has had this habit of finding something on a chair or bed, and pulling it off. The one time I forgot to leave the computer bag on the floor, he pulled it off the bed for me.

The fall must have done something to the drive, because when Leopard tried to upgrade, it couldn't read the drive. I no longer could read it in Target Disk Mode either. So, I ended up running a full install. Most everything was already backed up (except for the second draft of my book, but it was crap anyway), so I didn't lose anything important.

The install was clean, cleared out a lot of libraries of failed attempts by me to compile things, and I came up with the leopard setup wizard. It is an easier setup than Tiger, but only because it doesn't ask you as many questions.

The Mac Pro
The Mac Pro was a different situation all together. This is my work machine, and when I tried to install the update, the disk I had was bad. So I got just so far, and it died on me. No longer able to boot, but the files staying in tact, I tried another install disc from our IT guys. The install failed again, but why I don't know, and so I tried a third time. This time it finished, and started logging into the GUI. I was excited, until I saw the login window: no accounts. My entire NetInfo directory of two accounts was completely gone.

Not wanting to believe it, I booted up into the install DVD again, and tried to change the password. It let me, so I thought I could try booting again. No go, it still didn't have any users. Argh! I was afraid I would have to do a full install, and this time the IT guys took the disk back. So, I tried some things in the Command Line. After all, it's based on BSD, right?

Well, the only way to add a user that I could see was to add them in Open Directory. To do that, I needed access to the command dscl. I booted up into Single User Mode, and gave it a try. It wouldn't run without a particular library setting executed first. It even told me the command to run. So I did, and it still didn't work. Argh! What was going on? I was worried I would have to run a full install on the machine.

The next day, I checked online again, looking for anything that would give me some sort of access to the machine. Then I came across two articles, Here, explaining the issue I was experiencing, and here, outlining how to add a new user.

Now, I tried the first fix, but the original user was completely gone. My guess is that when it was importing the new account information from NetInfo (no longer used in Leopard) to the LDAP system in Open Directory, the system failed. The original NetInfo information was still there, but wasn't imported properly. So, I needed to create a new account.

Once the new account was created, it worked like a charm! Because I had to search for the fix for two days, here are the steps that I took, should anyone else need to perform the same fix:

1. Restart in Single User mode (hold Command-S during startup)
2. At the prompt, type: mount -uw /
3. Press Return
4. Type:
launchctl load /System/Library/LaunchDaemons/com.apple.DirectoryServices.plist
Press Return
5. Create a new entry in the local (/) domain under the category /users.
dscl . -delete /Users/[username]

6. Create and set the shell property to bash.
dscl . -delete /Users/[username] UserShell /bin/bash

7. Create and set the user’s full name.
dscl . -delete /Users/[username] RealName "Real Name"

8. Create and set the user’s ID.
dscl . -delete /Users/[username] UniqueID 501 (default System Admin for Mac OS X)

9. Create and set the user’s group ID property.
dscl . -delete /Users/[username] PrimaryGroupID 1000

10. Create and set the user home directory.
dscl . -delete /Users/[username] NFSHomeDirectory /Users/[username]

11. Set the password.
dscl . -passwd /Users/[username] PASSWORD

or

passwd [username]

12. If you would like Dr. Harris to be able to perform administrative functions:
dscl . -append /Groups/admin GroupMembership [username]

This worked just fine for me. Hopefully it would be helpful to someone else, if nothing else then to find it easier. ^_^

The iMac
My wife's computer worked without a hitch, which was good because I didn't have time to back up everything, just the images. I was hurt, because her machine didn't have a problem. What's wrong with me? ^_^

Anyway, I hope this helps those of you upgrading to Leopard, and have trouble with missing accounts.

One of the more drool-inducing features of Leopard (for geeks, anyway) is Spaces, Apple's virtual desktop implementation. I'm a big virtual desktop fan, and I'm glad to see it working its way into the mainstream. And all things considered, Spaces is a decent (and beautiful) implementation.

But there are some bugs. I hope that we will see them worked out. Some of the bugs are in Spaces itself, some are probably with 3rd party applications. The most notable, and annoying, problem is buggy application switching. When you cmd-tab to switch applications, you are taken to the space with that application. This is good, but it must have given the Apple developers heartburn because in some ways it flies in the face of the "Apple Way", which thinks of an application as a whole not as independent windows. That's why the menu bar is at the top, and it's behind the design of the dock. But what happens when there's a Terminal window on this Space, and on that Space? The natural thing should be, switch to the terminal window in this Space. If that's not what the user wanted, well you can't be expected to read minds. But when I cmd-tab to Terminal, I am always taken to what Leopard apparently thinks is the master Terminal Space, regardless of whether I have a Terminal window in this space, which Terminal window I last used, etc. Bad news. As a workaround, I just put Terminal on all spaces and thank my lucky stars it has tabs now. This affects most multi-window applications to some degree, but it's most annoying with Terminal and Adium.

On a related note, I'd expect cmd-` to switch between windows of the same app on different Spaces, but it only switches between windows on the current space.

Some applications, especially Firefox and to a lesser extent Thunderbird, have focus bugs that may be related to spaces. Sometimes when I switch to Firefox (with cmd-tab), the window is not in focus and is not brought to the foreground. The menu bar reflects that I'm in Firefox, and I may have moved spaces to get there, but it's in the background. I have to switch to it with cmd-` (or, horror of horrors, with the mouse). I imagine this is the sort of thing that Apple and/or Mozilla will hammer out soon. There are other Firefox irritations but they're for another post—if they haven't been fixed by then.

So far, nothing too surprising. Virtual desktops is hard to get perfect, and various Linux window managers have been floundering for years or even decades. Overall, I'd say they're off to a smashing start. I have two other more minor irritations. First, I'd like the current application to stay the current application when I switch spaces with the keyboard, instead of switching to the topmost application in the new space. This is because I often want to choose an application (by cmd-tabbing to it), then navigate to another space where I want to open a new window (e.g. Terminal). This is a design decision, of course, and one that people tend to fall on either side with about 50% probability. The second is keybindings. I'd like to switch spaces with cmd-ctrl-hjkl (Vim keybindings). Maybe we'll find a way. I'd also like to have more keyboard operations, especially "move me and this window to the {left,right,up,down} space".

I had a chance to try out Leopard over the weekend, and there's quite a bit to like. In the end, though, I restored my backup (which was a lot more difficult than it usually is, but that's another story), and I'll be sticking with Tiger for at least the next few weeks.

I should probably start off by mentioning the good parts. I didn't get to use the system for long, but already I like the ability to use tabs in Terminal, and I can see that Spaces and Time Machine are going to be great. The new dock looks nice, and I'm sure I'm going to like stacks.

I had a few annoyances, too, though, and one complete show-stopper (which I'll save for last).

MySQL

I'm not sure exactly why, but I had to recompile the MySQL server. Not a problem, I do that often enough with new upgrades that I've got my configure arguments saved in a script so it's fairly automatic, but unexpected. The real annoyance here was that MySQL Pref Pane stopped working, and claimed that it wasn't compatible with a PowerPC-based Mac. Odd, I had just been running it on a PPC Mac in Tiger and it worked fine.

That's not a show stopper, since I can still run MySQL from StartupItems and it works fine, but it's a bother not to have it work in System Preferences.

Lighttpd

A long time ago, I switched from the built-in Apache 1.3 in Tiger to my own build of Apache 2.0, and more recently from Apache 2 to lighttpd. I never have had any success with the lighttpd launchd script that shows up all over, but that doesn't matter: anyone who's switched out Apache will have learned that you can replace Apple's default /usr/sbin/apachectl with a symbolic link to your own apachectl script, and your new Apache will magically Just Work with the Personal Web Sharing control in System Preferences. Turns out, that works just fine if your "apachectl" script happens to run lighttpd instead of Apache, too.

Not so in Leopard, unfortunately. I was able to get lighttpd to run from StartupItems, and with a few more days to play with it, I'd probably have had it working in System Preferences too, but not yet. (On the good side, though, Apple has finally switched to Apache 2, so if I were to give up on playing with lighttpd, it would be fairly simple to drop in my Apache 2 httpd.conf and run with the software that comes built in in Leopard.)

PHP

I had to recompile my FastCGI build of PHP. Again, I'm not sure why it stopped working, since it wasn't installed in the same place as Apple's default PHP. Not a serious problem, but a bother.

Terminal

I mentioned before that I really like tabs in Terminal. They don't even begin to make up for Terminal's new window sizing behavior, though.

In Tiger, I can set the size and position of my Terminal window, and once I do, it stays how I set it. That seems fairly obvious. Leopard, unfortunately, missed that obvious behavior. Every time I open a new terminal window or switch between two terminal windows, Leopard's Terminal decides that It Knows Better and moves and resizes my window. That's completely unacceptable, and I was almost ready to go back to Tiger just for that.

Apple has generally done a good job of picking sane defaults for window sizes and locations, but when I put a window somewhere and size it how I want it, I had a reason for doing it, and the system had better respect that. If I weren't already bald, this one would have had me pulling all my hair out within the first five minutes. When (if?) I do switch to Leopard again, I'll be looking for a different Terminal program. Suggestions, anyone?

And finally,

The show-stopper

I really should have checked before trying Leopard, but it never occurred to me. Verizon won't be releasing updated software for my EVDO card until sometime in November, and the old software doesn't work in Leopard. That means, of course, that Leopard is dead in the water until November as far as I'm concerned. Game over.

I'll probably upgrade after the new EVDO software comes out. I'll probably decide I really like Leopard (I already do, in fact, despite the foregoing). I'm thinking I'll do a clean system build rather than try to upgrade, because I've been wanting to re-do the way I've got PHP and a few other utilities installed anyway, and this will be a good chance to start from scratch. But I'm not touching this again without two full backups, and probably not without already finding a good replacement for Terminal.

This week has been exciting with regards to Apple. They announced the release date of Mac OS X v.10.5 "Leopard", and the iPhone SDK for open and accepted developers.

Leopard
I have been a proponent of Leopard for a long time, because the cool features within Leopard (and Leopard Server) have had me drooling. Not because they are anything new, but because many of the open source programs that are out there have a easy way to manage them. It also means that I get more training for the Apple Certification classes that are coming up in the Spring. All I can say is I can't wait to start playing with the OS once it's released. ^_^

iPhone SDK
Yes, Steve Jobs and his group finally saw the light based on the outcry of the iPhone 1.1.1 update that killed a lot of hacked iPhones. iPhone users want an Apple PDA, not just a phone with a new interface. Now, just as I had hoped, after the iPod Touch was released, the iPhone will be opened with an SDK to developers that are issued a specific key (probably, anyway).

The only problem I would have with it is: what are the criteria for the key? There are currently a lot of developers using the Jailbreak hack and SDK that was developed by hackers out there at the iPhone Dev Wiki. Will they be eligible for the key? Will it be handled the way the Widget program was handled, allowing just about anyone to develop as long as the software is virus free? I hope so. It would make life that much easier for the current developers, and will basically incorporate all the cool apps that already exist.

February will be an exciting time for Apple, if they do it right. Let's hope they do.