Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 218442 - cups does not support symbolic links for configuration files
cups does not support symbolic links for configuration files
Product: Fedora
Classification: Fedora
Component: cups (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2006-12-05 07:00 EST by QingLong
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-12-07 07:32:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
cups related messages from /var/log/audit/audit.log (11.19 KB, text/plain)
2006-12-07 07:17 EST, QingLong
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
CUPS Bugs and Features 2136 None None None Never

  None (edit)
Description QingLong 2006-12-05 07:00:13 EST
Description of problem:
Cups does not generate /etc/printcap file on start.
No, there are no error messages in /var/log/cups/{access,error,page}_log.
But sometimes (rarely) it does regenerate it.
I have failed to find out under what circumstances that had happened. 

Version-Release number of selected component (if applicable):
previous versions had the same bug

How reproducible:

Steps to Reproduce:
1. Change /etc/printers.conf, e.g. add new printer
   (or just remove the /etc/printcap).
2. restart cups service
Actual results:
/etc/printcap remains the same (or is not recreated, if absent).

Expected results:
Should update (or regenerate) printcap in accordance with the printers.conf.

Additional info:
Maybe cupsd is confused by the /etc/cups/cupsd.conf being a symlink?
I have several printers.comf files for different locations (that's a notebook)
and switch between them using symlink.
I believe cupsd shouldn't care about it and must get info about the file
using stat() function which does follow symlinks.
Comment 1 Tim Waugh 2006-12-05 10:37:56 EST
CUPS will only generate /etc/printcap when it believes it needs to.  If you are
changing the printers.conf file by hand CUPS won't know the printcap file is out
of date.  Use 'lpadmin' to add printers, or else use the CUPS web interface or
the system-config-printer tool provided in Fedora.
Comment 2 QingLong 2006-12-06 01:36:39 EST

1. Cups MUST regenerate printcap if it is absent on start/restart.
2. I haven't said that I had edited printers.conf by hand.
   I had tried both ways: delete/readd and change printer via cups web interface,
   as well as to edit printers.cups by hand. None had led to printcap update
   or creation if it had been earlier deleted.

This can be selinux-dealt problem as cups-related messages appear in audit.log.
Comment 3 Tim Waugh 2006-12-06 05:01:18 EST
On start and reload it looks like cupsd does indeed generated a printcap file.

What does 'ls -Z /etc/printcap' say?  And what cups-related messages appear in
Comment 4 QingLong 2006-12-07 07:17:56 EST
Created attachment 143047 [details]
cups related messages from /var/log/audit/audit.log

created by `grep -i 'cups' /var/log/audit/audit.log'
Comment 5 QingLong 2006-12-07 07:20:49 EST
ls -Z /etc/printcap
-rw-r--r--  root root system_u:object_r:cupsd_rw_etc_t /etc/printcap

cat /var/log/audit/audit.log | audit2allow | grep -i 'cups' | sort
allow cupsd_t cupsd_etc_t:lnk_file rename;
allow cupsd_t etc_runtime_t:file write;
allow cupsd_t etc_t:dir write;
allow cupsd_t etc_t:file setattr;
allow cupsd_t user_home_t:file write;
Comment 6 Tim Waugh 2006-12-07 07:32:17 EST
Your printers.conf file seems to have label root:object_r:etc_runtime_t:s0 which
is incorrect.  Perhaps this is as a result of the way you are installing the link.

I don't think it can ever really work to have symbolic links for cupsd_rw_etc_t
files such as cupsd.conf and printers.conf, simply because CUPS will use atomic
rename() when writing changes to them.

I've reported this upstream to see if there is any desire to support this mode
of operation.
Comment 7 Tim Waugh 2006-12-07 08:01:31 EST
So the upstream reply is that you should use a symlink for /etc/cups -- or else
have /etc/cups.profile1, /etc/cups.profile2 etc -- rather than symlinks for the
individual configuration files.
Comment 8 QingLong 2006-12-07 09:17:40 EST
That's very strange (not to say stupid) idea to copy the whole /etc/cups tree
(contains lots of standard stuff) in order to make changes to a couple of files.
Looks like cups team resides in the redmond (WA) vicinity... :-/

Note You need to log in before you can comment on or make changes to this bug.