cups ldap

[wes]

> You don't want to use browsing?

I want to browse ldap servers in Active Directory, but not register any Linux based servers. In other words, we have a strange app  that requires printing through the windows print queues, we need cups with ldap to discover networked printers, and then be able to print to them.

To get around this we have hardcoded printer definitions using smb:// url's with applicable username and password authentication and associated ppd files. The problem here is having to manage cups to ensure it's not stuck trying to send a job through.

> Alternate way:
> Write a script/programm which do the ldap search and call lpadmin for all changed printers.

Yeah we thought of that, don't want to do it, but may have to.

> This can happen if cups has lost the ldap connection. Restart the cups daemon and the check the logfile again.

Actually we found it was because the server name for ldap didn't have the ldap:// prepended line in front of our global catalogue server reference.

>
> You can find an improved LDAP implementation here:
> http://www.cups.org/str.php?L1962
> (read at least the last three posts)
>
> But this is only beta and will not be included until cups 1.4.x. You can experiment on your own risk.
>

Yeah we may not have a choice but to go with something like this, scares me because we are running everything on RHEL 4u6, so we are outdated anyway.

>
>
> What do you mean with just connect to the remote printer?
> Did mean a remote ipp printer queue (e.g. CUPS server), a "typical" network printer or a smb share?

We defined an smb share in the printers.conf so smb://<win2k3domainname>\username:password@<printserver.domainname.com>/printerName

This way cups talked directly to the windows printer share. We'd rather lookup in ldap, then have cups auto-attach to the windows printer and go from there.

Also, consider this. We were able to get browsing to work, but the classobjects are all backwards between what cups wants and what Active Directory provides (go figure, microsoft doing their thing). So we had to replace the cupsPrinter in the dirsvc.c with printQueue, recompile and we started seeing messages back that stated 386 objects found, but we still couldn't browse. Now come to find out there are about 5 different attributes that cups looks for:

1. printerDescription          --- description
2. printerLocation             --- location??
3. printerMakeAndModel         --- driverName ??
4. printerType                 --- driverName ??
5. printerURI                  --- url??

These are purely guesses on my part, but we are recompiling again. One thought we had was to just pop up an ldap proxy and map the attributes between each other. I just don't have the time right now to get that working.

Thoughts?

-Wes