Bug 127174

Could you please attach the output of 'printconf-tui --Xexport',
making sure to edit out any passwords it contains?  I want to be sure
about the cause of this.

Thanks.

Created attachment 101613 [details]
output of 'printconf-tui --Xexport'

I guess that the troublesome 'Listen' directive was inherited from the previous

version (cups update was installed very recently) and was associated with
"Shared" property; which also got somehow "inherited" and never explicitely set

by me.	It vanished when I turned off "shared" and was replaced by
"Listen *:631" when I turned that back on.  But when I tried to limit sharing
to a given subnetwork then again a specific IP address got into that 
directive while this indeed could be a print server, referenced from clients
by its name, and a Dynamic DNS in use.

/etc/printcap in all cases has a local machine in 'rm=...'.  Ugh!

Thanks.

There are three unrelated issues here, so I'll go through them one at
a time.

1. Printcap contents

Okay, 'dyna0.home.front' in this case is the name that cupsd decided
to use instead of 'localhost' -- it does not refer to the remote
queue, but the local CUPS server.  And technically, it *is* right
since submitting a job to 'lp' on that machine will end up at the
right place.

The contents of /etc/printcap are informational only.  I'm not sure
why it doesn't use 'localhost', but in any case you can configure the
string it puts there by adjusting the ServerName variable in
/etc/cups/cupsd.conf.

2. Listen directives not being updated for dynamic address changes

Yes, this limitation is known about but not yet addressed.

3. Listen directives appearing in the first place

I'm not clear about when you exported the configuration data you
attached -- can you clarify it please?  Did you change a setting
before exporting and attaching it?

It sounds, from what you're saying, as though a queue became
automatically set to be available for other computers to use without
your explicit say-so -- this is not meant to happen.

These refer to
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127174#c3

Ad 1.  Changing a name of a local printer indeed is changing
a name used by ':rp=...'; but this is a very stretched interpretation
to make that "technically correct".  Is this truly broken model one
of reasons why lpq is shot?  See bug #90619.  The later is a real
BIG PAIN on an installation with a busy printer and many clients.

Ad 3.  I experimented with configurations before I got a request
for a 'printconf-tui --Xexport' output.  The one attached is from
a situation when "Shared" property was explicitely turned off.
Here is the only real difference between that and a situation when
sharing is on but explicitely limited to a local network (and when
a troublesome "Listen" with a specific address shows up again):

@@ -44,6 +44,9 @@
               </foomatic_defaults>
             </filter_data>
           <filter_type TYPE="STRING" VALUE="MAGICFILTER"/>
+          <sharing ANONYMOUS="TRUE" TYPE="LIST">
+            <hosts1 TYPE="STRING" VALUE="192.168.23.0/255.255.255.0"/>
+            </sharing>
           <jobsheets TYPE="LIST">
             <start TYPE="STRING" VALUE="none"/>
             <end TYPE="STRING" VALUE="none"/>

I seem to have a related problem: my cupsd also dies with "Child
exited with status 99!" 

I have two 10/100 interfaces on my MB, and one died recently, so I
have the dead eth0 at 192.168.0.13 with onboot=no, and the live eth1
at 192.168.0.14.

Somebody keeps ifup'ing eth0 which may be another problem.

After reading above I discovered that /etc/cupsd.conf had "Listen
192.168.0.13:631" in it, who put that in there?

Removing that line allows cups to start.

Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.