Rather than try to summarize this problem, let me just start in with the symptoms and workarounds, which seem related. Background: about 12 FC3 workstations, printing via CUPS with a samba connection to a printer shared by a Win2K server. We use a dummy print user "linuxprint" as the username to connect to the shared printer.
Symptom/Workaround 1: when we tried to add this printer to each workstation, we thought we could just ssh over and copy in a new /etc/cups/printers.conf file. Upon restarting CUPS, for example by restarting the computer, we expected users to be able to print to the new printer. But they couldn't; we had to login as root, go into the GUI printers config (System Settings--Printers), and edit the printer. We didn't have to change anything, only go into the printer and click OK. Then they could print.
Symptom/Workaround 2: recently we reinstalled some of our Windows servers after a crash, and we forgot, at first, to recreate this "linuxprint" user. So Linux users were getting the NT_STATUS_LOGON_FAILURE message. We recreated the linuxprint user, with the same password as before. Upon restarting CUPS, for example by restarting the computer, we expected this login failure message to go away and for people to be able to print. But again, only by editing the printer and clicking OK (not making any changes) could we get people printing.
Is this normal? If so, how can I remotely fix people's CUPS settings? I don't want to keep visiting every station and running the printer config as root every time we have to change something. If it's not normal, what could be going wrong?
Thanks, Matt
On Thu, Jun 02, 2005 at 11:36:58AM -0400, Matt Morgan wrote:
Symptom/Workaround 1: when we tried to add this printer to each workstation,
Here's the first odd thing: why are you adding the queue definition to every workstation, rather than just letting CUPS browsing distribute the queue definition for you?
In system-config-printer on the server, make the queue 'shared'. Then it's just a case of making sure that the iptables rules on the clients allow incoming UDP port 631 traffic.
we thought we could just ssh over and copy in a new /etc/cups/printers.conf file.
This is the second odd thing -- the assumption that the entire CUPS configuration is stored in /etc/cups/printers.conf. It is not, by a long way.
You can use 'printconf-tui --Xexport' to export the configuration as XML, and 'printconf-tui --Xclear; printconf-tui --Ximport' to import it.
Tim. */
On 6/2/05, Tim Waugh twaugh@redhat.com wrote:
On Thu, Jun 02, 2005 at 11:36:58AM -0400, Matt Morgan wrote:
Symptom/Workaround 1: when we tried to add this printer to each workstation,
Here's the first odd thing: why are you adding the queue definition to every workstation, rather than just letting CUPS browsing distribute the queue definition for you?
In system-config-printer on the server, make the queue 'shared'. Then it's just a case of making sure that the iptables rules on the clients allow incoming UDP port 631 traffic.
This is a Windows server sharing the printer, not RH. Is there a Windows equivalent?
I'm going to guess that it's already broadcasting, and it's a matter of opening port 631 on the clients. But then how do users connect it? You must be root to get into System Settings--Printers. And I don't want them to connect all the browseable printers, that's too many.
we thought we could just ssh over and copy in a new /etc/cups/printers.conf file.
This is the second odd thing -- the assumption that the entire CUPS configuration is stored in /etc/cups/printers.conf. It is not, by a long way.
You can use 'printconf-tui --Xexport' to export the configuration as XML, and 'printconf-tui --Xclear; printconf-tui --Ximport' to import it.
Cool, thanks!
I'm still left with the login issue. Why wouldn't that start working as soon as we recreated the linuxprint account and restarted CUPS on the clients?