On 12/11/08 3:08 PM, "Terry Spaulding" <[email protected]> wrote:
> David replied: > >> The printers do not have to support IPP at all. That's why you define the >> printers to the *CUPS server* as LPR printers, not have the clients bypass >> the CUPS server and talk to the printers directly, which (unless I'm > missing >> something entirely) is what the setup you're describing seems to do. > > The Win/XP are printing to the SAMBA server directly not to the printers. > Sorry I was not clear about that. > > I thought that when you create the printer on the desktop that IPP was the > preferred way to define the printer on > Windows when setting it up to print to SAMBA/CUPS. > > I should be defining them as an LPR setup on Windows when setting up to > print to SAMBA/CUPS ? No. From your earlier note, I thought you had set up the Windows clients to talk directly to the printer with LPR. The clients should only be talking to the server, and should be using IPP only. > On the authentication we did not implement any of the SAMBA security. Only > the SAMBA and CUPS admin user > ids were implemented. We are trying to set this up as a very simple > SAMBA/CUPS setup not requiring us to define > everyone's userids in order to print to SAMBA. You do need to tell Samba what ids are allowed to administer it (you tried to do that with 'print admin', which failed for some reason. Same with CUPS. > I will have to look into the wind bind access to AD to see if there are any > problems there. > The cupsadm user id is the same admin userid on SAMBA and CUPS in the > ntadmin group. You have to have some way for Samba and CUPS to figure out who's allowed to do things to them. Having the userid be the same is meaningless if Samba and CUPS can't figure out if they're allowed to permit that user to do something. > If I could use the existing windows server setup to auto setup install the > printer driver on the Win/XP desktop and > create the printer on the Win/XP desktop I would I think prefer to try that > as all the printers and drivers are on a > windows server today. We are only testing/experimenting with a small number > of printers on SAMBA/CUPS. The problem (my best guess) is that Samba can't figure out whether you're allowed to do printer admin things, so it's doing the Right Thing and telling you that you're not allowed to do that. Fix the authentication problem and then look in the Windows server docs for uploading printer drivers to remote printer servers. As long as Samba and CUPS can determine if the userid logged into the Windows domain is authorized to act as a printer administrator, you should be able to use the Windows GUI to update the printer drivers just like Samba was a remote Windows server. Make sure the permissions on the Samba printer driver directory are correct and are writable by the Samba userid. > > Thanks for the quick reply and info. Much appreciated. > > Regards, > Terry L. Spaulding > [email protected] > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
