Bug 181966 - cups configuration updates destroy symlinks
cups configuration updates destroy symlinks
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: cups (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-17 19:34 EST by JW
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:
Environment:
Last Closed: 2006-12-12 12:42:34 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Here is an lrename() function that should be used instead of rename() (1.45 KB, text/plain)
2006-03-04 21:51 EST, JW
no flags Details


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

  None (edit)
Description JW 2006-02-17 19:34:57 EST
Description of problem:
If any of the files classes.conf, printers.conf, cupsd.conf are symlinks then
they get broken when scheduler rewrites them.

Version-Release number of selected component (if applicable):
cups-1.1.23-15.1

How reproducible:
always

Steps to Reproduce:
1.ln -s something printers.conf
2.run/configure cupsd
3.
  
Actual results:
symlink destroyed

Expected results:
symlinks preserved

Additional info:
I have a patch but it needs a library copy() routine which strangely enough libc
does not provide.  Yet there is a libc rename(). Weird.
There are several rename()'s in scheduler/{classes,client,printers}.c which
should be changed to copy().  And somebody should write a
POSIX-committee-sanctioned filecopy() or fcopy() or copy() for libc.
Comment 1 Tim Waugh 2006-02-18 06:18:43 EST
Why are you making them symlinks?  What's the use-case for this?  Seems an
unusual thing to do, and not something that I would expect to be accepted upstream.
Comment 2 JW 2006-02-18 06:45:48 EST
(In reply to comment #1)
> Why are you making them symlinks?  What's the use-case for this?  Seems an
> unusual thing to do, and not something that I would expect to be accepted
upstream.

Would you like to know what I use my computer for, and how long I use it every
day first?

What does anybody use symlinks for?  They shouldn't use them - or at least they
should justify their use of them to RedHat officals first ;-)

Look mate, over here in Australia we use our computers as sophisticated and
clever machines ... well, not quite as sophisticated as programmers, but I think
you get my drift.

Say, for example, you have 1000 machines for which you create predefined
configurations which you put on a single DVD. You have a choice - either run
scripts at boot time which dynamically configure each host, or instead use symlinks.

In our case we have this hierarchy (somewhat simplified for your benefit):

    /M/etc/cups/cupsd.conf:host1
    /M/etc/cups/cupsd.conf:host2
    /CHG.host1/etc/cups/cupsd.conf => /M/etc/cups/cupsd.conf:host1
    /CHG.host2/etc/cups/cupsd.conf => /M/etc/cups/cupsd.conf:host2
    /etc/cups/cupsd.conf => /CHG/etc/cups/cupsd.conf
    /CHG => /CHG.host1 (or whatever)

So you see - the file /etc/cups/cupsd.conf is a fixed symlink.
Now by simply changing the top level symlink (eg /CHG => /CHG.host2)
you can instantly change the entire configuration of the host to whatever
is appropriate .. and it takes less than 1mS.  In fact on the kernel
command-line you can pass a HOST=host2 and have rc.sysconfig set the configuration.

It works brilliantly.  I can configure 1000 hosts in a few hours, and it is dead
simple to maintain. (Given a couple of scripts to maintain/create the symlink
hierarchies).

Hope you aren't sorry that you asked.
Comment 3 JW 2006-03-04 21:51:32 EST
Created attachment 125653 [details]
Here is an lrename() function that should be used instead of rename()

This is a lrename() function which differs from rename() in that it attempt to
follow a destination symbolic link.  It is as atomic as rename().  Using this
function instead of rename(P) will ensure that symbolic links are preserved if
possible, on the grounds that people create symbolic links intentionally and
they really want all file reading/writing to go to the symlink target and not
the symlink itself.

Symbolic links should be transparent as far as possible.
Comment 4 Tim Waugh 2006-12-12 12:42:34 EST
This patch will never get accepted upstream.  The policy is that for this sort
of application you need to use a separate directory root instead of symbolic links.
Comment 5 JW 2006-12-12 17:35:27 EST
(In reply to comment #4)
> This patch will never get accepted upstream.

Preemptive negativity?

> The policy is that for this sort
> of application you need to use a separate directory root instead of symbolic
links.

That might be your policy but you are wrong to try to impose it on others. 
Besides, it wouldn't work!

Comment 6 Tim Waugh 2006-12-13 05:05:22 EST
See upstream bug report I filed about this only recently:
http://cups.org/str.php?L2136

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