[cups.general] [cups.development] [RFE] STR #3344: Cups rewrites configuration files.

Johannes Meixner jsmeix at suse.de
Fri Sep 25 01:13:35 PDT 2009


Hello,

On Sep 24 09:39 Michael Sweet wrote:
>
> [STR Closed w/o Resolution]
>
> The symlink issue is STR #2136 and not to be fixed.
>
> In general, we do not support external management of cupsd configuration
> files. Because cupsd must be stopped and then restarted when changes are
> made to the configuration files, we do not recommend doing this. There are
> users doing this, but they have to stop cupsd, update the configuration
> files, and start cupsd when updating the configuration from a central
> repository (which usually means doing so during down time...)  Moreover,
> since the cupsd.conf file often contains system-specific information, it
> is usually not feasible to share the same cupsd.conf file between systems.
>
> Only cupsd.conf is considered to be user-editable, and even then we
> recommend using the corresponding CUPS commands or APIs to update it so
> that the scheduler can be restarted properly. Updates to cupsd.conf only
> occur when a new cupsd.conf file is pushed to the scheduler.
>
> The printers.conf and classes.conf files are maintained by cupsd and
> should never be edited outside of CUPS unless cupsd is stopped. Updates to
> this file occur when the printer state changes or when a user adds,
> modifies, or deletes a queue.
>
> The information in the various configuration files is not appropriate for
> any of the FHS-defined /var directories - everything is configuration data
> (not spool, cache, or other temporary data) - and so it belongs in /etc.
>
> Link: http://www.cups.org/str.php?L3344
> Version:  -feature
> Fix Version: Will Not Fix


As far as I know there is another config file which
is considered to be user-editable: /etc/cups/client.conf



I think what is missing for system admins is the above information
in a very obvious way because system admins usually assume
that files in /etc/ are static configuration files appropriate
for manual editing or whatever special system management tools.

You may also have a look at
http://en.opensuse.org/SDB:CUPS_in_a_Nutshell
"Command-line Tools"



Currently I run only CUPS v1.3.11 (perhaps it is already improved
for CUPS 1.4) but in CUPS 1.3.11 the headers for printers.conf
and classes.conf are only like
------------------------------------------------------------------
# Printer configuration file for CUPS v1.3.11
# Written by cupsd on 2009-09-24 15:15
------------------------------------------------------------------
and
------------------------------------------------------------------
# Class configuration file for CUPS v1.3.11
# Written by cupsd on 2009-09-24 10:57
------------------------------------------------------------------

In contrast the header in /etc/printcap is
------------------------------------------------------------------
# This file was automatically generated by cupsd(8) from the
# /etc/cups/printers.conf file.  All changes to this file
# will be lost.
------------------------------------------------------------------

I would like to suggest to add such a header for all config files
which are overwritten by the cupsd so that in the end all
those config files could have the same header of the form
------------------------------------------------------------------
# Configuration file for CUPS v1.3.11
# This file was automatically generated
# by cupsd(8) on 2009-09-24 15:15
# Manual changes to this file will be ignored and lost.
------------------------------------------------------------------

Should I file an enhancement STR for this?



At least the CUPS 1.4 documentation should be improved
because currently e.g. the printers.conf documentation
http://www.cups.org/documentation.php/doc-1.4/ref-printers-conf.html
reads:
---------------------------------------------------------------------
If you do choose to edit this file manually, you will need
to restart the scheduler to make them active.
---------------------------------------------------------------------

This is in contradiction to how DirtyCleanInterval works
(as far as I understand it) because after manual edit
a still running cupsd may overwrite it and at least it
would be overwritten during the cupsd shutdown.

Therefore I think the CUPS 1.4 documentation for all config files
which are overwritten by the cupsd should be improved as follows:
---------------------------------------------------------------------
If you do choose to edit this file manually, you will need
to stop the scheduler before you start to edit it
(see DirtyCleanInterval in the cupsd.conf documentation)
and start the scheduler after you finished editing.
---------------------------------------------------------------------

Should I file another enhancement STR for this?



Kind Regards
Johannes Meixner
-- 
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
AG Nuernberg, HRB 16746, GF: Markus Rex





More information about the cups mailing list