Jaharmi’s Irreality renewable hyperlinks with 0% transfat since 1999

A few+posts+on+the+MacEnterprise+mailing+list+have+reported+that+Leopard+does+support+authenticated+printing+with+Active+Directory. This is a good step forward for Mac OS X. However, it’s unclear if it is using Kerberos to do so.

Leopard includes CUPS 1.3.3. I don’t exactly know how to tell this from the command line. There’s no cups -V at all, as the main executable is cupsd. But, there’s no cupsd -V, either. So, I resorted to the CUPS Web administration page, which is found at http://localhost:631/ on any modern Mac.

The What’s new in CUPS page — which as of this writing documents version 1.3 — says that Kerberos is now supported. So it’s reasonable to guess that Kerberos could be in use on Leopard for this type of authenticated printing.

So, I took a moment to ask on the Apple Printing mailing list, and got immediate results. Right away, Michael Sweet posted that no, by default it doesn’t … but it can be activated with the “Negotiate” option in cupsd.conf. There is one caveat: it reportedly doesn’t work with Windows Server 2003R2, however. You need CUPS 1.3.4 for that.

I found out that CUPS 1.3.3 in Leopard can potentially be replaced with version 1.3.4 at your own risk. You should only do that if you are comfortable with compiling applications, if you absolutely need to make Kerberized authenticated printing work with Windows Server 2003R2, and you are willing to test the changes before you deploy it to more than your non-production test computer. Otherwise, the following risk is not worth it. However, if you still feel the need to try CUPS 1.3.4 despite these warnings:

1. Get the CUPS 1.3.4 source and compile it as a “4-way fat” binary with:
   $ ./configure --with-archflags="-arch i386 -arch ppc -arch x86_64 -arch ppc64"
$ make
2. Copy the resulting cups/libcups.2.dylib file to /usr/lib/.
3. Reboot or log out.

The new libcups.2.dylib could then be copied to other computers if your testing with it is successful and it fixes the problem with authenticated printing through Windows Server 2003R2. You’re on your own if you try any of this; I’m not suggesting you do it, and can’t help you if you try. It’s unsupported and YMMV.

(By the way, replacing one key file like this is a really great opportunity to use a Radmind overload, if you’re into that sort of thing.)

Wow, Apple bought the Common UNIX Printing System (CUPS) back in February, and the announcement has just come out. (I have to wonder why the delay … perhaps it has something to do with Leopard?) The software continues to be licensed under its regular terms.

Michael Sweet, one of the principals behind Easy Software Products and developer of CUPS, is now an Apple employee.

I’m sure this all means something.

I’ll admit it: I’m a bit slow when it comes to the shell. I use it a lot, but never feel like I’m using it as well as I could. But today, I figured out how to turn on Z Shell completion system. And it is very, very good.

This guide helped me, leading me to add the following to my .zshrc file:


autoload -U compinit
compinit


Once I’d done that, I could begin completing various commands and parameters. Within a few moments, using the tutorial above, I’d already completed:

• command names
• file and directory paths
• changing a directory with cd, listing only directories
• listing each directory that would be extracted from a tar archive
• ssh destination, including user and host
• changing to a directory three-levels deep with cd, using only the first letter of each of the three paths (i.e. “/u/l/b” for “/usr/local/bin”).

This is cool.

Here is how I colorized my shell environment in Mac OS X Tiger:

1. Added “CLICOLOR” and set it to “1” in the ~/.MacOSX/environment.plist, using the handy environment editor in SSHKeychain
2. Changed my terminal type to “dtterm” in Terminal’s “Preferences” window.NOT FOUND: TerminalZshAndTerm.jpg

I don’t recall exactly how I got to this point, but I’d never seen a hint that provided color with this level of ease — and I recently fell into a pique of wanting but not having colorized shell output.

Based on my reading of the MacEnterprise.org extended knowledgebase article on Mac OS X 10.4.9, some interesting changes have been made. Here are some of my comments on items listed in that article:

• “Includes iChat support for USB Video Class webcams,” which seems to mean that UVC webcams will work without additional drivers on this version of the OS … so I doubt we’ll see a replacement for the standalone Apple iSight and I wouldn’t doubt we’ll just have to make do with the third-party opportunities this presents.
• “Resolves an issue when using Kerberos authentication with Active Directory if the user is a member of many groups,” which may mean that my problem with binding to Active Directory over UDP using an account with a large TokenGroups attribute is resolved … presumably, if it is fixed, the kpasswd utility now supports TCP as well (although I do not see a change to /usr/bin/kpasswd in a Radmind transcript, the Kerberos framework did change).
• “Adds support for WPA2 encryption in Network Diagnostics,” which is an option that is coming at just the right time for me.
• “Includes updated security certificates,” which should mean that the root SSL certificates database has been updated (I note in a Radmind transcript that both X509Anchors and X509Certificates has changed with this update).
• I’m not exactly hip with whatever change happened in /private/var/db/sudo. Based on what I’m seeing, a subdirectory for each sudo user will appear; so far, I’ve only seen this on Radmind model systems, and so I see one subdirectory with a blank “ttyp1” file inside. I think I might want to put this new directory in a negative transcript for Radmind.

[Via Philip Rinehart on the MacEnterprise.org list.]

Extra Pepperoni: The Apple Keychain is cool, but also strange and problematic. This article obviously caught some attention, since Perry the Cynic is the first poster in the comments. Heh.

[Via Daring Fireball.]

Having just started my previously-described relationship with Site5, it’s taken a bit of time to get used to shared Web hosting and determine how to move my site to their servers. Trying to intertwingle the site move with the higher priorities of parenting and shoveling all of the snow we’ve gotten means that time for the Web site has simply come up short.

No longer. This post is the result of my move (although I’m staying up late so I’m going to suffer for it). The database is imported. My Drupal instance is installed. Irreality is now on Site5 — and assuming I don’t have a problem that requires the use of Site5’s money back guarantee — it’ll be staying here for a while.

I’ve decided to follow Sthomas’ referral to Site5, taking them up on their $5 hosting deal. It simply came down to a price I was willing to pay.

I figure that I’ll probably save around that much electricity per month by not having to run my server at home. I’ll regain some upstream bandwidth on my Internet connection, which can be put to other uses. And, my son will not have so many whirring fans running in his room, since we haven’t finished remodeling the room all the technology is moving to.

I had been hoping to get:

• a several GB storage allotment
• a high bandwidth allotment
• High or unlimited hosted sites
• Full DNS control (for potential use with DNS-SD, perhaps)
• Dedicated IP address
• SSL
• Greater than 5 hosted databases (well, just because)
• SSH/SFTP
• Shell access
• Python 2.3 or later, preferably with mod_python (using FastCGI seems to be a big workaround)
• WebDAV
• QuickTime/Darwin Streaming Server
• Reliable, consistent server performance
• Good customer service (even if you never need it, it should be there)

I had to compromise on several points, but ultimately the price point was important to me. I had to balance some items that I wanted versus what I felt was needed, and consider some items which could be added onto an account locally rather than by the hosting provider.

It’ll take a little time for me to sort it out, but I’ll be moving this site to my new hosting account shortly. Hopefully, I can make it happen without an outage.

I had also considered the following hosting companies, and each had compelling offerings that were just not outweighed by $5 per month. I’ll list some of the benefits and drawbacks for each of these well-reviewed major hosting firms.

• Dreamhost: WebDAV, QuickTime/Darwin Streaming Server, more quota space
• WebFaction: considered very good for Python (including mod_python, which seems to be a rarity) and open source hosting, but had some of the most limited stats (like only three hosted dynamic sites for $7/month with a two year commitment)
• Bluehost: considered good for Python, good stats.

In the future, I'm still considering some arrangement with Rsync.net or another off-site backup/storage provider. I think it’s an interesting time to be on the Internet, when you can really start to take advantage of some truly useful hosted services.

Geoff got me thinking about zsh last fall, and it’s on my mind again. I’m pondering a switch to it.

I’m still stuck on tcsh because it’s what I started with for my heavy interactive shell use. All my shell config files and knowledge reside in tcsh, because that’s what you used by default in Mac OS X 10.0. But, I dislike that the tcsh syntax is different than what I’m used to when it comes to shell scripting with bash. Bash is what I learned when I first took up scripting. Well, more to the point, I learned sh, and have grown a bit into using some bash-isms.

So I’m reading more about zsh, which means I’ll probably be firmly rooted in analysis paralysis for a while. But it looks good, and my chances in converting will improve if I can get my .tcshrc custom-tailoring moved over with reasonable ease.

In the meantime, here’s a search for zsh on Del.icio.us.

I wanted to determine how much space I’d save—and what the compression time tradeoff might be—to compress Mac OS X system images with gzip versus bzip2. Both are options in Mac OS X Tiger, but the bzip2 compression is new in that release (and thus not backward compatible with Panther and earlier). Given that Apple’s own disk imaging is the bedrock of almost all imaging solutions from Mac OS X, including those from third party computer management solutions providers, this information is valuable and widely applicable on the Mac platform.

If the time were the same but I saved some disk space, I’d count that as a win for one compression choice or the other. For significant space savings, I’d even sacrifice time to a longer conversion operation because disk image compression and ASR prep can be handled in the background during downtime or operational lulls. A Folder Action or launchd task might be ideal for that, and might even be a useful option if you are just archiving images.

The two disk image formats I tested are UDZO and UDBZ, as defined by the hdiutil command and its man page.

For an UDZO version of the image (gzip compression at level 9—or best),
I got the following results from hdiutil convert:

Elapsed Time: 1h 1m 50.751s
File size: 4226869141 bytes, Checksum: CRC32 $8CF3F127
Sectors processed: 20184610, 19980489 compressed
Speed: 2.6Mbytes/sec
Savings: 59.1%

I ran the hdiutil command with time (a handy utility if you haven’t used it), to get these figures:

real 61m52.133s
user 51m7.575s
sys 2m47.700s

For the same image converted to UDBZ (bzip2 compression):

Elapsed Time: 2h 16m 28.057s
File size: 3956667545 bytes, Checksum: CRC32 $8CF3F127
Sectors processed: 20184610, 19980489 compressed
Speed: 1.2Mbytes/sec
Savings: 61.7%

The time results for that were:

real 136m29.205s
user 106m1.832s
sys 8m30.739s

You may draw your own conclusions, as appropriate to the data and your situation. The source image was the same size, nearly 10 GB, which included Mac OS X Tiger and a suite of applications with a small number of user accounts. The source and converted files were both stored on an external FireWire 400 hard disk, and converted with a 1.5-GHz 12-inch PowerBook G4.

Although the ASR-prepped (i.e. asr --imagescan) gzip and bzip2 images were not that different in the end, the bzip2 version definitely came out smaller. It has in ever test I’ve ever run. However, it did take twice as long to create the image. So, if you’re strapped for disk space to collect your images and CPU time means less to you than storage (which is often the case for me, given that I have access to a lot of G4-class Mac hardware), I would consider bzip2. However, gzip at level 9 is perfectly acceptable (still providing almost 60% savings in this case), is faster to create, and has the benefit of working on older versions of Mac OS X, as well.

I should try gzip at other settings (like levels 1 and 6, for example), because you can’t choose level 9 in the Disk Utility interface; you must use the command line -imagekey flag. (You can get bzip2 from the GUI if you enable the hidden advanced disk image formats, but I still don’t see a way to choose a higher gzip level.)