From: Frank Brehm Date: Wed, 11 Oct 2017 00:28:42 +0000 (+0200) Subject: saving uncommitted changes in /etc prior to emerge run X-Git-Url: https://git.uhu-banane.net/?a=commitdiff_plain;h=cb198c230a195cba20c3435cb323af5a0ef9671e;p=config%2Fbruni%2Fetc.git saving uncommitted changes in /etc prior to emerge run --- diff --git a/cups/cups-browsed.conf b/cups/cups-browsed.conf index c6613a4b..4d92ca67 100644 --- a/cups/cups-browsed.conf +++ b/cups/cups-browsed.conf @@ -301,6 +301,69 @@ BrowseRemoteProtocols DNSSD,CUPS # DomainSocket Off +# Set HTTP timeout (in seconds) for requests sent to local/remote +# resources Note that too short timeouts can make services getting +# missed when they are present and operations be unneccesarily +# repeated and too long timeouts can make operations take too long +# when the server does not respond. + +# HttpLocalTimeout 5 +# HttpRemoteTimeout 10 + + +# Set OnlyUnsupportedByCUPS to "Yes" will make cups-browsed not create +# local queues for remote printers for which CUPS creates queues by +# itself. These printers are printers advertised via DNS-SD and doing +# CUPS-supported (currently PWG Raster and Apple Raster) driverless +# printing, including remote CUPS queues. Queues for other printers +# (like for legacy PostScript/PCL printers) are always created +# (depending on the other configuration settings of cups-browsed). + +# With OnlyUnsupportedByCUPS set to "No", cups-browsed creates queues +# for all printers which it supports, including printers for which +# CUPS would create queues by itself. Temporary queues created by CUPS +# will get overwritten. This way it is assured that any extra +# functionality of cups-browsed will apply to these queues. As queues +# created by cups-browsed are permanent CUPS queues this setting is +# also recommended if applications/print dialogs which do not support +# temporary CUPS queues are installed. This setting is the default. + +# OnlyUnsupportedByCUPS Yes + + +# With the directives LocalQueueNamingRemoteCUPS and +# LocalQueueNamingIPPPrinter you can determine how the names for local +# queues generated by cups-browsed are generated, separately for +# remote CUPS printers and IPP printers. + +# DNS-SD (the default in both cases) bases the naming on the service +# name of the printer's advertised DNS-SD record. This is exactly the +# same naming scheme as CUPS uses for its temporary queues, so the +# local queue from cups-browsed prevents CUPS from listing and +# creating an additional queue. As DNS-SD service names have to be +# unique, queue names of printers from different servers will also be +# unique and so there is no automatic clustering for load-balanced +# printing. + +# MakeModel bases the queue name on the printer's manufacturer and +# model names. This scheme cups-browsed used formerly for IPP +# printers. + +# RemoteName is only available for remote CUPS queues and uses the +# name of the queue on the remote CUPS server as the local queue's +# name. This makes printers on different CUPS servers with equal queue +# names automatically forming a load-balancing cluster as CUPS did +# formerly (CUPS 1.5.x and older) with CUPS-broadcasted remote +# printers. This scheme cups-browsed used formerly for remote CUPS +# printers. + +# LocalQueueNamingRemoteCUPS DNS-SD +# LocalQueueNamingRemoteCUPS MakeModel +# LocalQueueNamingRemoteCUPS RemoteName +# LocalQueueNamingIPPPrinter DNS-SD +# LocalQueueNamingIPPPrinter MakeModel + + # Set IPBasedDeviceURIs to "Yes" if cups-browsed should create its # local queues with device URIs with the IP addresses instead of the # host names of the remote servers. This mode is there for any @@ -358,8 +421,13 @@ BrowseRemoteProtocols DNSSD,CUPS # Everywhere and Apple Raster) in the local network (native printers, # not CUPS queues) and auto-create print queues for them. +# Set CreateIPPPrinterQueues to "LocalOnly" to auto-create print +# queues only for local printers made available as IPP printers. These +# are for example IPP-over-USB printers, made available via +# ippusbxd. This is the default. + # Set CreateIPPPrinterQueues to "No" to not auto-create print queues -# for IPP network printers. This is the default. +# for IPP network printers. # If queues with PPD file are created (see IPPPrinterQueueType # directive below) the PPDs are auto-generated by cups-browsed based @@ -380,6 +448,7 @@ BrowseRemoteProtocols DNSSD,CUPS # drivers and PPDs. # CreateIPPPrinterQueues No +# CreateIPPPrinterQueues LocalOnly # CreateIPPPrinterQueues Everywhere # CreateIPPPrinterQueues AppleRaster # CreateIPPPrinterQueues Everywhere AppleRaster @@ -413,6 +482,106 @@ BrowseRemoteProtocols DNSSD,CUPS # NewIPPPrinterQueuesShared Yes +# If there is more than one remote CUPS printer whose local queue +# would get the same name and AutoClustering is set to "Yes" (the +# default) only one local queue is created which makes up a +# load-balancing cluster of the remote printers which would get this +# queue name (implicit class). This means that when several jobs are +# sent to this queue they get distributed between the printers, using +# the method chosen by the LoadBalancing directive. + +# Note that the forming of clusters depends on the naming scheme for +# local queues created by cups-browsed. If you have set +# LocalQueueNamingRemoteCUPS to "DNSSD" you will not get automatic +# clustering as the DNS-SD service names are always unique. With +# LocalQueueNamingRemoteCUPS set to "RemoteName" local queues are +# named as the CUPS queues on the remote servers are named and so +# equally named queues on different servers get clustered (this is how +# CUPS did it in version 1.5.x or older). LocalQueueNamingRemoteCUPS +# set to "MakeModel" makes remote printers of the same model get +# clustered. Note that then a cluster can contain more than one queue +# of the same server. + +# With AutoClustering set to "No", for each remote CUPS printer an +# individual local queue is created, and to avoid name clashes when +# using the LocalQueueNamingRemoteCUPS settings "RemoteName" or +# "MakeModel" "@" is added to the local queue name. + +# Only remote CUPS printers get clustered, not IPP network printers or +# IPP-over-USB printers. + +# AutoClustering Yes +# AutoClustering No + + +# Load-balancing printer cluster formation can also be manually +# controlled by defining explicitly which remote CUPS printers should +# get clustered together. + +# This is done by the "Cluster" directive: + +# Cluster : ... +# Cluster + +# If no expressions are given, is used as the first and +# only expression for this cluster. + +# Discovered printers are matched against all the expressions of all +# defined clusters. The first expression which matches the discovered +# printer determines to which cluster it belongs. Note that this way a +# printer can only belong to one cluster. Once matched, further +# cluster definitions will not checked any more. + +# With the first printer matching a cluster's expression a local queue +# with the name is created. If more printers are +# discovered and match this cluster, they join the cluster. Printing +# to this queue prints to all these printers in a load-balancing +# manner, according to to the setting of the LoadBalancing directive. + +# Each expression must be a string of characters without spaces. If +# spaces are needed, replace them by underscores ('_'). + +# An expression can be matched in three ways: + +# 1. By the name of the CUPS queue on the remote server +# 2. By make and model name of the remote printer +# 3. By the DNS-SD service name of the remote printer + +# Note that the matching is done case-insensitively and any group of +# non-alphanumerical characters is replaced by a single underscore. + +# So if an expression is "HP_DeskJet_2540" and the remote server +# reports "hp Deskjet-2540" the printer gets matched to this cluster. + +# If "AutoClustering" is not set to "No" both your manual cluster +# definitions will be followed and automatic clustering of +# equally-named remote queues will be performed. If a printer matches +# in both categories the match to the manually defined cluster has +# priority. Automatic clustering of equally-named remote printers is +# not performed if there is a manually defined cluster with this name +# (at least as the printers do not match this cluster). + +# Examples: + +# To cluster all remote CUPS queues named "laserprinter" in your local +# network but not cluster any other equally-named remote CUPS printers +# use (Local queue will get named "laserprinter"): + +# AutoClustering No +# Cluster laserprinter + +# To cluster all remote CUPS queues of HP LaserJet 4050 printers in a +# local queue named "LJ4050": + +# Cluster LJ4050: HP_LaserJet_4050 + +# As DNS-SD service names are unique in a network you can create a +# cluster from exactly specified printers (spaces replaced by +# underscors): + +# Cluster hrdep: oldlaser_@_hr-server1 newlaser_@_hr-server2 + + # The LoadBalancing directive switches between two methods of handling # load balancing between equally-named remote queues which are # represented by one local print queue making up a cluster of them