[cups] [UNKN] STR #4320: Strange problem with CUPS on a Linux (CentOS 5.10) LAN
Robert Heller
heller at deepsoft.com
Tue Jan 14 16:55:03 PST 2014
At Tue, 14 Jan 2014 15:06:50 -0500 Michael Sweet <msweet at apple.com> wrote:
>
>
> Robert,
>
> You can also setup raw queues on the client, or if you have a single server
How are raw queues setup?
> just set the ServerName directive in /etc/cups/client.conf.
We effectively have two servers: the main server, which manages the two main
printers (a pair of network connected laser printers) and one of the clients
has a USB receipts printer attached and is used by that client and one of the
other clients, so I guess setting the ServerName might not be a good idea.
>
>
> On Jan 14, 2014, at 2:52 PM, Robert Heller <heller at deepsoft.com> wrote:
>
> > OK, What I have done is to 'punt': I copied the ppd files from the server's
> > /etc/cups/ppd to the client /etc/cups/ppd and replicated the server's
> > printers.conf file to the clients' /etc/cups/, changing the device URI to
> > ipp://serverIP/printers/<queuenameonserver>. This should short-curcuit the
> > browse broadcast and hard-wire the printers, whether the browse broadcast
> > works or not. It (obviously) has the downside of not automagically propagating
> > any changes to the printer configuration (things like stopping and starting
> > print queues) and if something about the printer(s) changes, I will have to
> > manually propagate the updates. Note: because the /etc/cups directory on the
> > clients is on a read-only file system it is NOT possible to use any of the
> > normal utilities (including the web-interface) on the clients to update the
> > configuration. It all has to be done by manually [text] editing the files on
> > the server.
> >
> > This should 'solve' the problem my masking it. Probably not anything like
> > really solving anything (or even figuring out what is really going wrong),
> > more like a 'bash to fit, file to hide, and cover with paint' solution...
> >
> > At Mon, 13 Jan 2014 16:25:17 -0500 Robert Heller <heller at deepsoft.com> wrote:
> >
> >>
> >>
> >> Ok, the problem is back. I'm thinking that there is some gremlin on the LAN
> >> (and I have no real clue where) that is interfering *specificly* with CUPS
> >> broadcasts to this one machine. I have captured its error_log
> >> (loglevel=debug2) and will attach it to this message.
> >>
> >> What is the alternitive to broadcast browsing? Do I have to *manually*
> >> configure the printers? It looks like this is something I am going to have to
> >> do.
> >>
> >> At Wed, 8 Jan 2014 11:36:43 -0500 Robert Heller <heller at deepsoft.com> wrote:
> >>
> >>>
> >>> OK, I power cycled the switch, moved the machine to a different port, and
> >>> rebooted the machine. Things are now behaving. I will keep an eye on it and
> >>> post here if the problem reappears.
> >>>
> >>> Question: If/when we upgrade to a newer version of CUPS (eg if/when we move to
> >>> CentOS 6) and the broadcast browsing is discontinued, what exactly is the
> >>> replacement stratagy? That is, what is the 'trick' (if any) to get client
> >>> machines to automagically pick on on available print queues? Or do I have to
> >>> configure the printers on each client machine (well really on one logical
> >>> machine, since all of the clients will have a common (NFS shared)
> >>> printers.conf file)?
> >>>
> >>> At Mon, 6 Jan 2014 18:11:21 -0500 Robert Heller <heller at deepsoft.com> wrote:
> >>>
> >>>>
> >>>> At Mon, 06 Jan 2014 13:19:45 -0500 Michael Sweet <msweet at apple.com> wrote:
> >>>>
> >>>>>
> >>>>>
> >>>>> Robert,
> >>>>>
> >>>>> On the switch there might have been same stale ARP info that prevented it from delivering the broadcast packets to that port.
> >>>>>
> >>>>> On the machine it could have been some stale DHCP information, although I would have expected it to hand out the wrong address vs. experiencing that kind of issue.
> >>>>
> >>>> Since the client machine(s) were cold re-booted and the DHCP daemon on the
> >>>> server was restarted, it seems unlikely that there was any stale DHCP
> >>>> information. But stale state info on the switch is possible (or at least
> >>>> plausable). If the problem shows up again, we'll reboot (power cycle) the
> >>>> switch. Note: the librarian *always* shuts her machine down when she leaves
> >>>> for the day and cold boots it in the morning...
> >>>>
> >>>>>
> >>>>> Like I said, I'm stumped at this point...
> >>>>>
> >>>>>
> >>>>> On Jan 6, 2014, at 12:36 PM, Robert Heller <heller at deepsoft.com> wrote:
> >>>>>
> >>>>>> At Mon, 06 Jan 2014 12:00:42 -0500 Michael Sweet <msweet at apple.com> wrote:
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Robert,
> >>>>>>>
> >>>>>>
> >>>>>>> I'm stumped. Short of some stale state on the switch or machines, I wouldn't
> >>>>>>> expect this to happen.
> >>>>>>
> >>>>>> The client machines have no 'stale state' (no persistant memory other than the
> >>>>>> BIOS config). Not sure what sort of stale state on the switch is possible.
> >>>>>> *Maybe* the switch port that the problem machine is on is going bad (in some
> >>>>>> odd specialized way?). I guess the only remaining option is to declare that
> >>>>>> port 'bad' and more the problem machine to another port and see if the problem
> >>>>>> goes away permanently. Or maybe just power cycle the switch (it has not been
> >>>>>> power cycled in quite some time, thanks to a APC UPS).
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Jan 4, 2014, at 11:52 AM, Robert Heller <heller at deepsoft.com> wrote:
> >>>>>>>
> >>>>>>>> I just did an experiement:
> >>>>>>>>
> >>>>>>>> I swapped the MAC (hardware ethernet) address of the problem machine with a
> >>>>>>>> working machine in the DHCP daemon's config file and restarted the DHCP daemon
> >>>>>>>> (both machines are otherwise identical) and rebooted both machines. Printers
> >>>>>>>> showed up on both machines. I did NOT physically move either machine, so they
> >>>>>>>> remained on the same Ethernet cables, same ports on the switch, etc. I then
> >>>>>>>> swapped the MAC (hardware ethernet) addresses back. And the printers are now
> >>>>>>>> shown. At least for now.
> >>>>>>>>
> >>>>>>>> What can possibly cause this weirdness?
> >>>>>>>>
> >>>>>>>> I have pretty much eliminated everything. The *only* possiblity is something
> >>>>>>>> really odd in the backported security patches Red Hat applied. It is still
> >>>>>>>> weird that the problem is selective (only one machine is affected) and
> >>>>>>>> intermittent (it is affected only *sometimes*). I am considering pulling the
> >>>>>>>> older version of cups from the 'vault' and downgrading it and filing a bug
> >>>>>>>> report either with CentOS or RedHat (or both).
> >>>>>>>>
> >>>>>>>> At Sun, 22 Dec 2013 13:00:48 -0500 Robert Heller <heller at deepsoft.com> wrote:
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> At Sun, 22 Dec 2013 11:59:09 -0500 Michael Sweet <msweet at apple.com> wrote:
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Firewall?
> >>>>>>>>>
> >>>>>>>>> There is none on the LAN. The diskless clients don't run iptables at all and
> >>>>>>>>> the server has two NICs and functions as a firewall router to the non-LAN NIC
> >>>>>>>>> to the outside Internet. Actually I run a 'standard' RedHat IPTables firewall
> >>>>>>>>> on my Laptop, and it has no problem seeing the shared printers, either at the
> >>>>>>>>> library or on my home LAN (my office Desktop also runs as a firewall router,
> >>>>>>>>> but to a PPP connection, using a dialup analog modem as the 'public' Internet
> >>>>>>>>> connection).
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Sent from my iPad
> >>>>>>>>>>
> >>>>>>>>>>> On Dec 22, 2013, at 12:38 AM, Robert Heller <heller at deepsoft.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> At Sat, 21 Dec 2013 19:13:35 -0500 Michael Sweet <msweet at apple.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Robert,
> >>>>>>>>>>>>
> >>>>>>>>>>>>> On Dec 21, 2013, at 5:59 PM, Robert Heller <heller at deepsoft.com> wrote:
> >>>>>>>>>>>>> ...
> >>>>>>>>>>>>> I'm off as well. We are stuck at 1.3.7, since that is the version supplied by
> >>>>>>>>>>>>> RHEL/CentOS 5. If browsing is dropped, how does printer sharing via cups
> >>>>>>>>>>>>> work? Do you have to explicitly configure the shared printers? Why was
> >>>>>>>>>>>>> browsing dropped?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Bonjour (DNS-SD) is used exclusively in 1.6 and later and was available as far back as 1.1.17 (assuming your OS vendor enabled it).
> >>>>>>>>>>>>
> >>>>>>>>>>>> Browsing was dropped because the simple heartbeat broadcasts used by CUPS
> >>>>>>>>>>>> browsing were really bad for network performance (particularly on wireless
> >>>>>>>>>>>> LANs), it only worked with IPv4, it didn't like network changes, and it
> >>>>>>>>>>>> needed either hardcoded IPs or working DNS. Bonjour doesn't have that
> >>>>>>>>>>>> problem and, for larger network installs, you can use regular DNS (vs.
> >>>>>>>>>>>> multicast DNS) fairly easily.
> >>>>>>>>>>>
> >>>>>>>>>>> The machine has always had a hard-coded IPv4 address. We only ever use
> >>>>>>>>>>> regular DNS.
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> ...
> >>>>>>>>>>>>> What sort of network configuration error that only affects *one* machine.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Address configuration issues come to mind - a bad interface address,
> >>>>>>>>>>>> broadcast address, or netmask will cause problems with broadcast-based
> >>>>>>>>>>>> protocols but often does not affect TCP-based protocols.
> >>>>>>>>>>>
> >>>>>>>>>>> This is all via DHCP and all of that is correct.
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> The
> >>>>>>>>>>>>> diskless clients get the network set up via DHCP in the init ramdisk and they
> >>>>>>>>>>>>> all use the same init ramdisk, so either they are all wrong (in which case
> >>>>>>>>>>>>> none should work) or are all right (in which case they should all work). With
> >>>>>>>>>>>>> only one have *intermittent* problems, it is strange. As you suggested, a
> >>>>>>>>>>>>> *physical* network problem would cause other (very obvious) problems, which
> >>>>>>>>>>>>> don't *seem* to be happening. The problem is very specific, which *suggests*
> >>>>>>>>>>>>> a specific problem, but nother pops up.
> >>>>>>>>>>>>
> >>>>>>>>>>>> One possibility - was the machine (or the MAC address of the machine)
> >>>>>>>>>>>> previously associated on the network with a different address? Then the DHCP
> >>>>>>>>>>>> server might be handing it an old address instead of an address from the
> >>>>>>>>>>>> current space?
> >>>>>>>>>>>
> >>>>>>>>>>> No, all of that is sane. I did change the address from one address to
> >>>>>>>>>>> another. The problem vanished, but came back.
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> _________________________________________________________
> >>>>>>>>>>>> Michael Sweet, Senior Printing System Engineer, PWG Chair
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> This message contains data in an unrecognized format, application/pkcs7-signature,
> >>>>>>>>>>>> which is being decoded and written to the file named "/home/heller/Mail/Attachments/423-smime.p7s".
> >>>>>>>>>>>> If you do not want this data, you probably should delete that file.
> >>>>>>>>>>>> Wrote file /home/heller/Mail/Attachments/423-smime.p7s
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> Robert Heller -- 978-544-6933 / heller at deepsoft.com
> >>>>>>>>>>> Deepwoods Software -- http://www.deepsoft.com/
> >>>>>>>>>>> () ascii ribbon campaign -- against html e-mail
> >>>>>>>>>>> /\ www.asciiribbon.org -- against proprietary attachments
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Robert Heller -- 978-544-6933 / heller at deepsoft.com
> >>>>>>>> Deepwoods Software -- http://www.deepsoft.com/
> >>>>>>>> () ascii ribbon campaign -- against html e-mail
> >>>>>>>> /\ www.asciiribbon.org -- against proprietary attachments
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> _________________________________________________________
> >>>>>>> Michael Sweet, Senior Printing System Engineer, PWG Chair
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> This message contains data in an unrecognized format, application/pkcs7-signature,
> >>>>>>> which is being decoded and written to the file named "/home/heller/Mail/Attachments/434-smime.p7s".
> >>>>>>> If you do not want this data, you probably should delete that file.
> >>>>>>> Wrote file /home/heller/Mail/Attachments/434-smime.p7s
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Robert Heller -- 978-544-6933 / heller at deepsoft.com
> >>>>>> Deepwoods Software -- http://www.deepsoft.com/
> >>>>>> () ascii ribbon campaign -- against html e-mail
> >>>>>> /\ www.asciiribbon.org -- against proprietary attachments
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> _________________________________________________________
> >>>>> Michael Sweet, Senior Printing System Engineer, PWG Chair
> >>>>>
> >>>>>
> >>>>>
> >>>>> This message contains data in an unrecognized format, application/pkcs7-signature,
> >>>>> which is being decoded and written to the file named "/home/heller/Mail/Attachments/435-smime.p7s".
> >>>>> If you do not want this data, you probably should delete that file.
> >>>>> Wrote file /home/heller/Mail/Attachments/435-smime.p7s
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
> > --
> > Robert Heller -- 978-544-6933 / heller at deepsoft.com
> > Deepwoods Software -- http://www.deepsoft.com/
> > () ascii ribbon campaign -- against html e-mail
> > /\ www.asciiribbon.org -- against proprietary attachments
> >
> >
> >
>
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
>
>
> This message contains data in an unrecognized format, application/pkcs7-signature,
> which is being decoded and written to the file named "/home/heller/Mail/Attachments/443-smime.p7s".
> If you do not want this data, you probably should delete that file.
> Wrote file /home/heller/Mail/Attachments/443-smime.p7s
>
>
--
Robert Heller -- 978-544-6933 / heller at deepsoft.com
Deepwoods Software -- http://www.deepsoft.com/
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments
More information about the cups
mailing list