OSX Clients not attempting CUPS-Get-PPD operation

Nick Cammorato nick_cammorato at terc.edu
Fri Dec 28 17:55:24 PST 2012


Michael,

Thank you for the reply.  We've thought of a few other things to try to rule out something whacky going on during compilation.  We're going to try a few different versions of everything and a few different distros to see if this is just isolated to our current setup or not.

> I'm pretty sure 10.6 and later explicitly allow virtualization of OS X Server, and both VMWare and Parallels allow you to install OS X in a VM.

Unless the language has changed, you had to use Apple Hardware.  VSphere in particular had a check to prevent you from doing it.  You could patch it out, but that's a little too grey area for us.  I'm hoping that's either changed or is going to change before our choices for some things are run in that grey area or use minis/pros(which while great aren't really servers).  AFP in particular is not something I would like to use Linux for.

> This is just a UI issue - CUPS printers shared via Bonjour show up as Bonjour Shared while network printers show up as Bonjour on OS X.  On Linux there is no distinction made in the current UI.
>

Good to know.  I thought the distinction might be what was triggering the difference in behaviors.  The queues are shared via the share printer interface on the OSX server which I thought might be what was triggering the clients to retrieve the ppds.  The backend is all cups though on both.

> Remember that the AccessLogLevel directive will limit what is reported in the access_log file, but usually we just do a HTTP GET of /printers/printername.ppd instead of using CUPS-Get-PPD (which is used when adding a printer with a local driver).
>

I set both AccessLogLevels to all and LogLevel to debug2 on both servers, and the only appreciable difference was where the OSX server shows a get on /printers/Printername.ppd, the Linux server simply doesn't.  If you go to either manually it just works.

I also tried disabling SSL, implicitly trusting the cert and all your normal TLS things, just in case it was failing on that step.

The local logs also show nothing.  It's like the client doesn't even try.

> However, this should "just work" so if you don't see the GET then please file a bug against OS X:
>
>     http://bugreport.apple.com

Will do.  I'll try to gather as much as I can an repro it in as many ways as possible and then submit a report.

Thanks again for the help,
--Nick




More information about the cups mailing list