Re: :Re: repeat of previous question thathasgoneunansweredseveraltimes.
On 2023-05-12 12:08:33 -0400, gene heskett wrote:
> On 5/12/23 07:41, Vincent Lefevre wrote:
> > On 2023-05-12 06:23:56 -0400, gene heskett wrote:
> > > I'm confused. There is not anything wrong with this machine as a Server.
> > > ALL of this muttering and bitching has been because bookworm clients did NOT
> > > work. buster clients work great.
> > >
> > > How many times do I have to say it is/was a CLIENT problem that only exists
> > > for BOOKWORM clients. The elephant in the room that most have ignored.
> >
> > But you said that the problem was "solved" by modifying a setting
> > corresponding to the Listen directives (in /etc/cups/cupsd.conf).
> > These directives concern the *server* only.
> >
> Oh, then how does one tell the CLIENT to even use the SERVER?
I'm not sure what you mean by "use". In the past, I had the following
lines in the /etc/cups/client.conf file of the machine at my lab:
ServerName liqqs.lip.ens-lyon.fr:443
Encryption Required
ValidateCerts Yes
The first line is to tell which server to use, and the other lines
for security. This way of doing means that everything is configured
on the server.
This has been deprecated at my lab, and now, the printers need to be
configured directly on the client side. In case you want something
like that, AFAIK, there are 2 solutions:
Manual: something like
lpadmin -p <name> -v <URI> [ -E ] -m everywhere -L <location>
Automatic with the cups-browsed package:
Description: OpenPrinting CUPS Filters - cups-browsed
This package provides cups-browsed, a daemon which browses the Bonjour
broadcasts of shared remote CUPS printers and makes the printers
available locally, replacing the CUPS broadcasting/browsing which was
dropped in CUPS 1.6.x. This way the old behavior of having the remote
printers available automatically is now re-implemented with Bonjour.
(However, it appears that because of that, on my laptop, I now have
dozens of ghost printers, and this is annoying.)
> It is 100% a "cannot assign requested address error" on the bpi51 as logged
> in/var/log/cups/error_log:
>
> E [12/May/2023:10:32:20 -0500] Unable to open listen socket for address
> 192.168.71.3:631 - Cannot assign requested address.
> E [12/May/2023:10:34:45 -0500] Unable to open listen socket for address
> [v1.::1]:631 - Cannot assign requested address.
I suppose that this is because you already have a server that is
already running and listening on these ports. Or you started the
server too soon after the old one terminated.
> Where its getting the ipv6 addy is a mystery
::1 is the IPv6 loopback. Perhaps listening on it is the default
(this makes sense), and perhaps even if it isn't setup (as this
is unusual).
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Reply to: