[cups] [UNKN] STR #4320: Strange problem with CUPS on a Linux (CentOS 5.10) LAN
Robert Heller
heller at deepsoft.com
Wed Jan 8 08:36:43 PST 2014
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
More information about the cups
mailing list