Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

State information belongs in /var/lib/cups, not /etc/cups #3067

Closed
michaelrsweet opened this issue Jan 20, 2009 · 11 comments
Closed

State information belongs in /var/lib/cups, not /etc/cups #3067

michaelrsweet opened this issue Jan 20, 2009 · 11 comments

Comments

@michaelrsweet
Copy link
Collaborator

@michaelrsweet michaelrsweet commented Jan 20, 2009

Version: 1.3.9
CUPS.org User: lamont

Section 5 of the FHS describes the /var hierarchy, and notes that /var/lib is for "Variable State Information"

"
Purpose

This hierarchy holds state information pertaining to an application or the
system. State information is data that programs modify while they run, and that
pertains to one specific host. Users must never need to modify files in /var/
lib to configure a package's operation.

State information is generally used to preserve the condition of an application
(or a group of inter-related applications) between invocations and between
different instances of the same application. State information should generally
remain valid after a reboot, should not be logging output, and should not be
spooled data."
Looking at /etc/cups/printers.conf, the following variables appear to be State, and NOT configuration:

State
StateTime
StateMessage

The timestamp in the '@ Written by cupsd on YYYY-MM-DD...' line is also far more state-like than configuration, unless the timestamp is specifically because of user configuration changes.

Similar logic can be applied to the other files.

@michaelrsweet
Copy link
Collaborator Author

@michaelrsweet michaelrsweet commented Jan 20, 2009

CUPS.org User: lamont

I hate it when the editor eats my text...

To say what I meant to say... The FHS says:

/etc : Host-specific system configuration

Purpose

The /etc hierarchy contains configuration files. A "configuration file" is a local file used to control the operation of a program; it must be static and cannot be an executable binary. [4]

...

/var/lib : Variable state information

Purpose

This hierarchy holds state information pertaining to an application or the system. State information is data that programs modify while they run, and that pertains to one specific host. Users must never need to modify files in /var/ lib to configure a package's operation.

State information is generally used to preserve the condition of an application (or a group of inter-related applications) between invocations and between different instances of the same application. State information should generally remain valid after a reboot, should not be logging output, and should not be spooled data.

All of the State* variables, in printers.conf are state, not configuration.

The timestamp (and file) should only be written if the user modifies the configuration. (And then only if the configuration edits actually result in changes.)

lamont

Loading

@michaelrsweet
Copy link
Collaborator Author

@michaelrsweet michaelrsweet commented Jan 20, 2009

CUPS.org User: mike

This has been covered before a dozen times since CUPS 1.0, most recently in STR #3018. The FHS DOES NOT have a place for user-editable configuration files that are also updated programmatically. Moreover, we do not want to separate the printer (and class, and scheduler) state from the corresponding configuration files, and users MUST be able to edit the configuration files manually as needed, which is the opposite of what the FHS says about /var/lib.

Not (and never) to be "fixed". If you want to make Ubuntu use /var/lib/cups as the ServerRoot directory for CUPS, feel free to use the --with-serverroot configure option in your packages.

Loading

@michaelrsweet
Copy link
Collaborator Author

@michaelrsweet michaelrsweet commented Jan 16, 2014

CUPS.org User: odyx

The attached patch limits the impact of this bug by dropping the timestamp from the "Written by cupsd �" header lines.

Loading

@michaelrsweet
Copy link
Collaborator Author

@michaelrsweet michaelrsweet commented Jan 16, 2014

"no-conffile-timestamp.patch":

Description: Disable time stamps in conffiles, to avoid ever-changing files in /etc.
Author: Joey Hess joeyh@debian.org
Bug: http://www.cups.org/str.php?L3067
Bug-Debian: http://bugs.debian.org/549673

--- a/scheduler/classes.c
+++ b/scheduler/classes.c
@@ -718,7 +718,7 @@
strftime(temp, sizeof(temp) - 1, "%Y-%m-%d %H:%M", curdate);

cupsFilePuts(fp, "# Class configuration file for " CUPS_SVERSION "\n");

  • cupsFilePrintf(fp, "# Written by cupsd on %s\n", temp);
  • cupsFilePrintf(fp, "# Written by cupsd\n");
    cupsFilePuts(fp, "# DO NOT EDIT THIS FILE WHEN CUPSD IS RUNNING\n");

/*
--- a/scheduler/job.c
+++ b/scheduler/job.c
@@ -2091,7 +2091,7 @@
strftime(temp, sizeof(temp) - 1, "%Y-%m-%d %H:%M", curdate);

cupsFilePuts(fp, "# Job cache file for " CUPS_SVERSION "\n");

  • cupsFilePrintf(fp, "# Written by cupsd on %s\n", temp);
  • cupsFilePrintf(fp, "# Written by cupsd\n", temp);
    cupsFilePrintf(fp, "NextJobId %d\n", NextJobId);

/*
--- a/scheduler/printers.c
+++ b/scheduler/printers.c
@@ -1377,7 +1377,7 @@
strftime(temp, sizeof(temp) - 1, "%Y-%m-%d %H:%M", curdate);

cupsFilePuts(fp, "# Printer configuration file for " CUPS_SVERSION "\n");

  • cupsFilePrintf(fp, "# Written by cupsd on %s\n", temp);
  • cupsFilePrintf(fp, "# Written by cupsd\n");
    cupsFilePuts(fp, "# DO NOT EDIT THIS FILE WHEN CUPSD IS RUNNING\n");

/*
--- a/scheduler/subscriptions.c
+++ b/scheduler/subscriptions.c
@@ -1108,7 +1108,7 @@
strftime(temp, sizeof(temp) - 1, "%Y-%m-%d %H:%M", curdate);

cupsFilePuts(fp, "# Subscription configuration file for " CUPS_SVERSION "\n");

  • cupsFilePrintf(fp, "# Written by cupsd on %s\n", temp);
  • cupsFilePrintf(fp, "# Written by cupsd\n");

cupsFilePrintf(fp, "NextSubscriptionId %d\n", NextSubscriptionId);

Loading

@michaelrsweet
Copy link
Collaborator Author

@michaelrsweet michaelrsweet commented Feb 9, 2016

CUPS.org User: jhc

One thing I haven't been able to find... what's the downside to living with the existing state of affairs (cups daemon updating /etc/cups/*.conf files with timestamps and what not) and mounting /etc read-only anyway. What happens if cupsd trys to modify an /etc/cups file but can't due to a read-only filesystem? That's a similar effect to trying to maintain a no-timestamp patch, although a read-only /etc may have a problematic effect on other fields than timestamp fields (some day, if not today).

On a side note, is there a way to lock a cups config file so I can edit it by hand and not worry about interfering cupsd (or experiencing problems form cupsd interfered with me)? Just killing the daemon while doing editing would sort of work but is not very satisfying, especially on a multi-user system.

Loading

@ckotte
Copy link

@ckotte ckotte commented May 9, 2018

Why isn't it possible to move State, StateTime, Attribute marker-levels and Attribute marker-change-time from /etc/cups/printers.conf to another file to /var/lib/? It's about the current state of the printer and not about the configuration?

Loading

@imsedgar
Copy link

@imsedgar imsedgar commented May 9, 2018

I confirm that according to Filesystem Hierarchy Standard (FHS) /etc is for (static) configuration files. Administrators can store their configuration files there. Status information like printer state, jobs, dynamic (variable) values like attributes requested from the printer should be stored in a subdirectory of /var, if the information should still be available after a reboot, or a subdirectory of /run (e.g. /run/cups), if the information does not make sence after a reboot (like file or process locks). (/var/run on Fedora is a symlink to /run.)

Fedora cups package already uses some directories in /var:

# rpm -ql cups|grep /var
/var/log/cups
/var/run/cups
/var/run/cups/certs
/var/spool/cups
/var/spool/cups/tmp

But there is no subdirectory like /var/lib/cups for status information. Files like subscriptions.conf, printers.conf, maybe subdirectory ppd too, or at least the dynamic parts of these files, should go to files in /var or /run. /etc should not be modifies by services on a regular basis, only if the administrator requests configuration changes.

I think also the (dynamic) list of printers and there configuration can be stored in something like /var/lib/cups, as long a these files are only written by cups (and cups supplement services like cups-browsed).

Loading

@michaelrsweet
Copy link
Collaborator Author

@michaelrsweet michaelrsweet commented May 9, 2018

OK, so we've had variations of this bug come up many times over the last 20 years.

I'll quote my comment (above) from 2009:

This has been covered before a dozen times since CUPS 1.0, most recently in STR

#3018. The FHS DOES NOT have a place for user-editable configuration files that are also updated programmatically. Moreover, we do not want to separate the printer (and class, and scheduler) state from the corresponding configuration files, and users MUST be able to edit the configuration files manually as needed, which is the opposite of what the FHS says about /var/lib.

Not (and never) to be "fixed". If you want to make Ubuntu use /var/lib/cups as the ServerRoot directory for CUPS, feel free to use the --with-serverroot configure option in your packages.

Loading

@ckotte
Copy link

@ckotte ckotte commented May 9, 2018

Does the state information need to be user-editable? It's just about this information and not about the configuration which should stay in /etc. Just move that state information to /var/lib and everyone is happy.

Loading

@imsedgar
Copy link

@imsedgar imsedgar commented May 9, 2018

Dear Michael,

I think it is a principal design problem to use the same file for user editing the configuration and updates by program. This results in the classic problem with simultaneous writers and readers where one change / write may be lost in some situations.

I see no good reason to mix printer configuration files with status information files, except that your program need to know which information it should read and write to which file. cups need to open some more file (one if it uses a status file for all printers, or more if one file for each printer), and the code needs to be adapted for this change. But that's all.

The advantage would be that configuration files in /etc/cups can be read-only for cups itself, and in can watch for changes and merge them into the runtime configuration, and / or read them at startup. There will be no problem any more if an administrator changes the file while cups is running. Even may cups change the configuration file if an administrator wants to set a configuration option by cli (e.g. lpadmin) or web interface instead of editing the files, that does not contradict the separation of status information.

I only see advantages in separating configuration files and state and dynamic configuration files - apart of the fact, that cups code needs to be changed. Which disadvantages do you see?

Loading

@michaelrsweet
Copy link
Collaborator Author

@michaelrsweet michaelrsweet commented May 9, 2018

Folks, we are not changing how things work in the current implementation of cupsd after 20 years.

In the future, when we make major architectural changes (and those are coming), we will revisit how printer configuration and state information is stored, and take into account all of the various filesystem "standards" that exist.

Loading

@apple apple locked as resolved and limited conversation to collaborators May 9, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants