[cups.bugs] [MOD] STR #3961: remote printers overriding Shared attriubte of local printers

russell-cups.stuart.id russell-cups at stuart.id.au
Tue Oct 18 19:29:01 PDT 2011


DO NOT REPLY TO THIS MESSAGE.  INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR Closed w/Resolution]

> You can't edit printers.conf while cupsd is running.
> If you really want to muck with this file by hand (not recommended

Just so you understand the use case here, the entire CUPS configuration is
generated from a database the describes the printers across the
organisation - cupds.conf, printers.conf, symlinks in ppds, .convs,
..types, custom ppds and filters - the lot.  If you are familiar with how
groups of machines are managed with puppet you will have the idea (but I
happen to use a different tool).  Naturally the configuration tool stops
CUPS before making any to the configuration files, and restarts it
afterwards.

The GUI is only used for restarting jobs and what not.

> that paragraph has been through a LOT of revisions since nobody 
> could understand what was said before (which went into a lot more
> detail)

OK, so your doco is written for a different level of user.  But understand
when I forced to read the source code to get a clue about what is going on
I am *not* happy.  This is not something I have to do with other packages.
 It took me over a day to debug a configuration that used to work, and that
is partially because of the lack of documentation.

I gather you are expecting your typical user to use the command line tools
and not look at the configuration files at all.  If so, you could put the
complete reference documentation into there.  

As it is there are a lot of things left to imagination in the
documentation.  For example, what does @SYSTEM mean in cupds.conf?  I am
guessing it means the user belongs to the /etc/group specified by the
SystemGroup setting, but it would be nice if it said that.  Similarly
@OWNER is a undocumented, but perhaps is a little more obvious.

> your configuration is not typical and *will* cause problems.

If there is a better way to do it, I would appreciate knowing what it is. 
I doubt what I am doing is uncommon in larger organisations.  It makes
sense to give every printer a single unique name which is visible across
the entire organisation.  Files are spooled locally so batch jobs and can
print, safe in the knowledge if there is a temporary network outage the
printing system will take care of it.

> There are a couple ways to "fix" this:

Thank you.  I appreciate you taking the time to tell me what was actually
going on.

Again so you can understand the use case, these are servers, not PC's. 
Programs on them can't print to random printers that come and go, so
picking up printers via browsing isn't any use to them.  I guess the key
concept here is are far as the servers are concerned, there is a static
pool of printers which are maintained by the IT department which the IT
hardware's centrally controlled programs to use, so all neat discovery
features CUPS provides aren't useful to them.  The situation is reversed
for the users PC's of course.  They do use the CUPS browsing features
heavily to discover the local printers - including those provided by the
servers.  Ergo the servers must send browsing information, but not use it
- especially if, as it appears from this case, browsing information from a
miss configured user PC could disrupt the server queues.

Link: http://www.cups.org/str.php?L3961
Version: 1.4.7
Fix Version: None





More information about the cups mailing list