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:
$ ./configure --with-archflags="-arch i386 -arch ppc -arch x86_64 -arch ppc64"
The new libcups.2.dylib could then be copied to other computers if your testing with it is successful and it ﬁxes 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 ﬁle 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 ﬁgured 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 ﬁle:
autoload -U 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:
This is cool.
Here is how I colorized my shell environment in Mac OS X Tiger:
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:
[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 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:
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.
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
Elapsed Time: 1h 1m 50.751s
File size: 4226869141 bytes, Checksum: CRC32 $8CF3F127
Sectors processed: 20184610, 19980489 compressed
I ran the
hdiutil command with
time (a handy utility if you haven’t used it), to get these figures:
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
The time results for that were:
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.)