Re: okular lpr et cups-bsd

[Th.A.C]

Merci beaucoup pour toutes ces infos, je vais regarder ca. :-)



Le 23/05/2024 à 06:54, Jean-Claude Marquès a écrit :

Bonjour

J'ai la même version sur un vieux portable :
$ cat /etc/debian_version
10.13
avec xfce comme environnement graphique

La commande :

apt-cache depends okular|grep Dépend|wc

donne le nombre de dépendances strictes de okular, qui est 47, mais j'ai 
peut-être des versions i386 dans le lot, je n'ai pas vérifié.


Cups-bsd est simplement recommandé, donc pas obligatoirement installé (à 
régler dans synaptic je pense) qui vient avec ses dépendances s'il n'est 
pas installé.
texlive-binaries est aussi simplement suggéré, et si texlive n'est pas 
installé, lui aussi dépend de 49 autres paquets.

etc
etc
Donc une centaine de paquets, ce n'est pas étonnant.

De plus :
Le paquet lpr sera enlevé, mais un fichier lpr (dans /usr/bin/ il me 
semble) sera installé en remplacement (voir 
https://packages.debian.org/search?searchon=contents=lpr=exactfilename=bookworm=amd64) si la commande lpr est utilisée sur le système (il ne peut y avoir qu'un démon d'impression sur un système (cups ou lpd) comme il ne peut y avoir qu'un démon de courrier électronique (exim4 ou postfix ou sendmail) etc etc.


Donc on peut très bien installer okular, à condition d'avoir l'espace 
disque nécessaire.


Personnellement, j'utilise okular depuis des années, sous xfce (le 
meilleur logiciel est celui qu'on connaît bien)


Bonne installation

JCM

Le 22/05/2024 à 23:30, Th.A.C a écrit :

Bonjour,

sur une debian 10 sous xfce, je voudrais installer okular pour tester.

A l'install, synaptic veut enlever lpr et mettre cups-bsd à la place, 
plus une centaine de fichiers.


Y a t'il un inconvénient pour lpr et cups-bsd?

Le nombre de fichiers supplémentaires me semble élevé pour une 
installation d'un programme, mais comme c'est le lecteur pdf de kde et 
que je suis sous xfce , je suppose que c'est normal?


Des avis avant de passer à l'action?

Merci :-)

Thierry

Re: okular lpr et cups-bsd

[Jean-Claude Marquès]

Bonjour

J'ai la même version sur un vieux portable :
$ cat /etc/debian_version
10.13
avec xfce comme environnement graphique

La commande :

apt-cache depends okular|grep Dépend|wc

donne le nombre de dépendances strictes de okular, qui est 47, mais j'ai 
peut-être des versions i386 dans le lot, je n'ai pas vérifié.


Cups-bsd est simplement recommandé, donc pas obligatoirement installé (à 
régler dans synaptic je pense) qui vient avec ses dépendances s'il n'est 
pas installé.
texlive-binaries est aussi simplement suggéré, et si texlive n'est pas 
installé, lui aussi dépend de 49 autres paquets.

etc
etc
Donc une centaine de paquets, ce n'est pas étonnant.

De plus :
Le paquet lpr sera enlevé, mais un fichier lpr (dans /usr/bin/ il me 
semble) sera installé en remplacement (voir 
https://packages.debian.org/search?searchon=contents=lpr=exactfilename=bookworm=amd64) 
si la commande lpr est utilisée sur le système (il ne peut y avoir qu'un 
démon d'impression sur un système (cups ou lpd) comme il ne peut y avoir 
qu'un démon de courrier électronique (exim4 ou postfix ou sendmail) etc etc.


Donc on peut très bien installer okular, à condition d'avoir l'espace 
disque nécessaire.


Personnellement, j'utilise okular depuis des années, sous xfce (le 
meilleur logiciel est celui qu'on connaît bien)


Bonne installation

JCM

Le 22/05/2024 à 23:30, Th.A.C a écrit :

Bonjour,

sur une debian 10 sous xfce, je voudrais installer okular pour tester.

A l'install, synaptic veut enlever lpr et mettre cups-bsd à la place, 
plus une centaine de fichiers.


Y a t'il un inconvénient pour lpr et cups-bsd?

Le nombre de fichiers supplémentaires me semble élevé pour une 
installation d'un programme, mais comme c'est le lecteur pdf de kde et 
que je suis sous xfce , je suppose que c'est normal?


Des avis avant de passer à l'action?

Merci :-)

Thierry

okular lpr et cups-bsd

[Th.A.C]

Bonjour,

sur une debian 10 sous xfce, je voudrais installer okular pour tester.

A l'install, synaptic veut enlever lpr et mettre cups-bsd à la place, 
plus une centaine de fichiers.


Y a t'il un inconvénient pour lpr et cups-bsd?

Le nombre de fichiers supplémentaires me semble élevé pour une 
installation d'un programme, mais comme c'est le lecteur pdf de kde et 
que je suis sous xfce , je suppose que c'est normal?


Des avis avant de passer à l'action?

Merci :-)

Thierry

Re: cups error -- SOLVED

[Russell L. Harris]

On Mon, Dec 25, 2023 at 09:36:44PM -0500, Stefan Monnier wrote:

I copied the file to another computer in the LAN, ran LaTeX and dvips,
and sent it to the same printer,  but the file hung at the same spot.


Any chance you can use `pdflatex` instead of `latex + dvips`?
Have you tried to manually convert the PS to PDF before sending to
the printer? or to convert straight from DVI to PDF?
Nowadays PS is becoming a curiosity, so you may have better luck with
PDF (there's a chance the problem is unrelated, of course).


The PDF file produced with pdflatex hung at the same point as did the
PS file produced with dvips.

The PDF file produced with dvipdfm printed the entire file properly.

Many thanks!

RLH

Re: cups error

[Russell L. Harris]

On Mon, Dec 25, 2023 at 09:36:44PM -0500, Stefan Monnier wrote:

I copied the file to another computer in the LAN, ran LaTeX and dvips,
and sent it to the same printer,  but the file hung at the same spot.


Any chance you can use `pdflatex` instead of `latex + dvips`?
Have you tried to manually convert the PS to PDF before sending to
the printer? or to convert straight from DVI to PDF?
Nowadays PS is becoming a curiosity, so you may have better luck with
PDF (there's a chance the problem is unrelated, of course).


Thanks for the suggestion.  I am a dinosaur; I have been running
Debian since A.D.2000, and I have done things pretty much as I was
taught by the guru who got me running.  Are you saying that I can
print to a printer which does not have PostScript?  (All of my
printers, which now are quite old, have PostScript.)

P.S.  I remember using LPR and the switch to LPRNG, and then the
switch to CUPS.  And now driverless CUPS.

RLH

Re: cups error

[Stefan Monnier]

> I copied the file to another computer in the LAN, ran LaTeX and dvips,
> and sent it to the same printer,  but the file hung at the same spot.

Any chance you can use `pdflatex` instead of `latex + dvips`?
Have you tried to manually convert the PS to PDF before sending to
the printer? or to convert straight from DVI to PDF?
Nowadays PS is becoming a curiosity, so you may have better luck with
PDF (there's a chance the problem is unrelated, of course).


Stefan

cups error

[Russell L. Harris]

On a desktop debian 12.2 amd64 system with
HP_LaserJet_P3010_Series_48E436 (ethernet), LaTeX documents composed
with Emacs frequently print only up to a certain point (it varies with
the document), and CUPS prints the error message:

  ERROR: typecheck OFFENDING COMMAND: known

xdvi displays the document perfectly in its entirety.

I copied the file to another computer in the LAN, ran LaTeX and dvips,
and sent it to the same printer,  but the file hung at the same spot.

One time I was able to recover by cutting the section at which
printing hung and pasting from another document.

I have searched the Web but have not found a solution.

RLH

CUPS classes wrecking printing

[Gary Dale]

I've running Debian/Bookworm (stable) on an AMD64 system - a laptop. 
It's a fresh install of Debian from about 6 months back that has been 
kept up to date.


Each December I am involved in an event that requires me to use 3 
photo-printers to print a lot of 4x6 photos. It takes 2 or 3 printers to 
get the throughput so people aren't waiting for their photos.


I've been doing this for a decade using various photo printers. I've 
always just set up a CUPS "photo" class and added the printers to it. 
Then I'd use lpr -P photo  to send the 
output to whichever printer was free. I even did it last year using the 
same laptop and printers and things worked.


This year, because it was a new OS install, I had to connect the 
printers and install them again. This required the gutenprint drivers 
for two of the printers while the newest seems to work "driverless".


All the printers were tested individually and printed the CUPS test page 
perfectly.


However when I sent something to the "photo" class, whichever printer 
received the job just printed a page of bands of colour. I could send a 
picture to an individual printer OK but not send it to the "photo" class.


I got through the event by skipping the lpr -P photo... command and 
manually selecting a printer from Gwenview when I was viewing the 
picture earlier in the workflow (to verify it was worth printing). This 
was not ideal and I only got through it because this year's event was 
less than half its usual size.


This was not an lpr problem because I also couldn't print to the class 
from Gwenview. CUPS classes seem to be broken.

Re: CUPS, Bullseye et Apple

[ajh-valmer]

On Saturday 21 October 2023 16:05:33 Thierry wrote:
> Incidemment, sur l'interface d'administration CUPS sur une Debian 
> Bullseye pur jus, j'ai remarqué cette petite note en bas de page:
> "CUPS et le logo CUPS sont des marques déposée de Apple Inc. CUPS est 
> sous copyright 2017-2019 Apple Inc. Tous droits réservés".
> Pour moi qui suis un tenant du libre et allergique à Apple, de quoi 
> s'inquiéter? Qu'est-ce que cela signifie?

C'est vrai, étonnant.

On lit aussi :
- Ethernet est une marque déposée de Xerox Corporation,
- Mozilla et Firefox sont les marques déposées ou les marques commerciales
  de Mozilla Foundation.

Pas trop Libre tout ça...

Re: CUPS, Bullseye et Apple

[Basile Starynkevitch]

On 10/21/23 16:05, Thierry wrote:

Bonjour,

Incidemment, sur l'interface d'administration CUPS sur une Debian 
Bullseye pur jus, j'ai remarqué cette petite note en bas de page:


" CUPS et le logo CUPS sont des marques déposée de Apple Inc. CUPS est 
sous copyright 2017-2019 Apple Inc. Tous droits réservés".


Pour moi qui suis un tenant du libre et allergique à Apple, de quoi 
s'inquiéter?


Qu'est-ce que cela signifie?



CUPS fonctionne sous Linux. sur https://github.com/apple/cups on peut 
lire la licence suivante:




LEGAL STUFF<https://github.com/apple/cups#legal-stuff>

Copyright © 2007-2021 by Apple Inc. Copyright © 1997-2007 by Easy 
Software Products.


CUPS is provided under the terms of the Apache License, Version 2.0 
with exceptions for GPL2/LGPL2 software. A copy of this license can be 
found in the file |LICENSE|. Additional legal information is provided 
in the file |NOTICE|.


Unless required by applicable law or agreed to in writing, software 
distributed under the License is distributed on an "AS IS" BASIS, 
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 
implied. See the License for the specific language governing 
permissions and limitations under the License.



Et la licence Apache est considérée comme libre.


Le copyright appartient a Apple, qui a probablement payé les salaires 
des dévelopeurs initiaux de CUPS.


Je suis aussi libriste (membre de l'APRIL) et allergique à Apple, mais 
il faut constater qu'il arrive à Apple de salarier des developpeurs de 
logiciels libres intéressants.


(j'ai connu des dévelopeurs salariés, et je l'ai moi-même été, pour le 
compilateur GCC, en particulier -pour les développeurs GCC que j'ai 
rencontrés- payé par IBM ou Google). Le code appartient à l'employeur 
(dans mon cas le CEA), qui délègue le copyright à la FSF. C'est une 
formalité qui m'a été pénible, et m'a probablement coûté des avancements.


Mon projet logiciel libre du moment est le moteur d'inférences RefPerSys 
(sous licence GPLv3+), en cours de développement en 
https://github.com/RefPerSys/RefPerSys/  les contributions y sont 
bienvenues.


--
Basile Starynkevitch
 
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

Re: CUPS, Bullseye et Apple

[NoSpam]

https://fr.wikipedia.org/wiki/Common_Unix_Printing_System

Le 21/10/2023 à 16:05, Thierry a écrit :

Bonjour,

Incidemment, sur l'interface d'administration CUPS sur une Debian 
Bullseye pur jus, j'ai remarqué cette petite note en bas de page:


" CUPS et le logo CUPS sont des marques déposée de Apple Inc. CUPS est 
sous copyright 2017-2019 Apple Inc. Tous droits réservés".


Pour moi qui suis un tenant du libre et allergique à Apple, de quoi 
s'inquiéter?


Qu'est-ce que cela signifie?
Merci

CUPS, Bullseye et Apple

[Thierry]

Bonjour,

Incidemment, sur l'interface d'administration CUPS sur une Debian 
Bullseye pur jus, j'ai remarqué cette petite note en bas de page:


" CUPS et le logo CUPS sont des marques déposée de Apple Inc. CUPS est 
sous copyright 2017-2019 Apple Inc. Tous droits réservés".


Pour moi qui suis un tenant du libre et allergique à Apple, de quoi 
s'inquiéter?


Qu'est-ce que cela signifie?
Merci

Re: cups blowed up again, when do we get a print system that Just Works?

[songbird]

gene heskett wrote:
...
> Thanks.

  when someone ignores common sense after frequently 
shooting themself in the foot there's not much more
i can do for them.

  i suggest a system management approach which involves
snapshots (use git on the whole thing if you have to
or some partition image copier or something).

  when you have a working setup, get that snapshot so
you can always fall back to it.  the other important 
part is being able to get to a reliably repeatable
state from a cold boot.

  always keep those working setups backed up.

  otherwise you are just wasting your time (repeatedly
it seems to me).


  songbird

Re: cups blowed up again, when do we get a print system that JustWorks?

[gene heskett]

On 8/25/23 04:49, gene heskett wrote:

On 8/24/23 13:00, gene heskett wrote:
ping


never mind the ping, I found that ff can't print it even using system 
dialog, but okular can. So thats another data point.

Greeting all;
bookworm, upto date, cups 2.4.2 installed.

I goto print a doc on a 3d printer control card, and can't print a pdf 
from firefox.


So I goto localhost:631, no printers! I had 4 the day before 
yesterday, and used 2 of them.


So I goto add printers, get asked for my passwd, and then all of them 
show up but can't do a test page, no response, so I reconfigure the 
big one for lowwr tray, duplex on duplex copy paper.  Print a test 
page, works, so I configure this same printer a second time for foto 
paper from tray 1, print test page works to expen$ive paper, go back 
to first and resend another test page to see if it still draws paper 
from tray 2, it does.


So since I'm on a roll. configure the b duplex laser printer, send a 
test page, works. 2 copies of that printer so I send a test to it. 
doesn't respond so I delete it. Go back to firefox, select print the 
27 page pdf I'm looking at, no response. Goto journalctl and see it say:

==
Aug 24 12:55:29 coyote firefox-esr[141594]: g_object_ref: assertion 
'G_IS_OBJECT (object)' failed
Aug 24 12:55:35 coyote plasmashell[2495]: libkcups: 
Get-Printer-Attributes last error: 0 successful-ok
Aug 24 12:55:35 coyote plasmashell[2495]: libkcups: 3 
"Brother_MFC_J6920DW_duplex_lowertray_coyote"
Aug 24 12:55:42 coyote kwin_x11[2453]: qt.qpa.xcb: QXcbConnection: XCB 
error: 3 (BadWindow), sequence: 10153, resource id: 90188401, major 
code: 15 (QueryTree), minor code: 0

===

I even added myself to the lp user in /etc/group, still no response.

Where do I look next?

Thanks.

Cheers, Gene Heskett.


Cheers, Gene Heskett.


Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

Re: cups blowed up again, when do we get a print system that Just Works?

[gene heskett]

On 8/24/23 13:00, gene heskett wrote:
ping

Greeting all;
bookworm, upto date, cups 2.4.2 installed.

I goto print a doc on a 3d printer control card, and can't print a pdf 
from firefox.


So I goto localhost:631, no printers! I had 4 the day before yesterday, 
and used 2 of them.


So I goto add printers, get asked for my passwd, and then all of them 
show up but can't do a test page, no response, so I reconfigure the big 
one for lowwr tray, duplex on duplex copy paper.  Print a test page, 
works, so I configure this same printer a second time for foto paper 
from tray 1, print test page works to expen$ive paper, go back to first 
and resend another test page to see if it still draws paper from tray 2, 
it does.


So since I'm on a roll. configure the b duplex laser printer, send a 
test page, works. 2 copies of that printer so I send a test to it. 
doesn't respond so I delete it. Go back to firefox, select print the 27 
page pdf I'm looking at, no response. Goto journalctl and see it say:

==
Aug 24 12:55:29 coyote firefox-esr[141594]: g_object_ref: assertion 
'G_IS_OBJECT (object)' failed
Aug 24 12:55:35 coyote plasmashell[2495]: libkcups: 
Get-Printer-Attributes last error: 0 successful-ok
Aug 24 12:55:35 coyote plasmashell[2495]: libkcups: 3 
"Brother_MFC_J6920DW_duplex_lowertray_coyote"
Aug 24 12:55:42 coyote kwin_x11[2453]: qt.qpa.xcb: QXcbConnection: XCB 
error: 3 (BadWindow), sequence: 10153, resource id: 90188401, major 
code: 15 (QueryTree), minor code: 0

===

I even added myself to the lp user in /etc/group, still no response.

Where do I look next?

Thanks.

Cheers, Gene Heskett.


Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

cups blowed up again, when do we get a print system that Just Works?

[gene heskett]

Greeting all;
bookworm, upto date, cups 2.4.2 installed.

I goto print a doc on a 3d printer control card, and can't print a pdf 
from firefox.


So I goto localhost:631, no printers! I had 4 the day before yesterday, 
and used 2 of them.


So I goto add printers, get asked for my passwd, and then all of them 
show up but can't do a test page, no response, so I reconfigure the big 
one for lowwr tray, duplex on duplex copy paper.  Print a test page, 
works, so I configure this same printer a second time for foto paper 
from tray 1, print test page works to expen$ive paper, go back to first 
and resend another test page to see if it still draws paper from tray 2, 
it does.


So since I'm on a roll. configure the b duplex laser printer, send a 
test page, works. 2 copies of that printer so I send a test to it. 
doesn't respond so I delete it. Go back to firefox, select print the 27 
page pdf I'm looking at, no response. Goto journalctl and see it say:

==
Aug 24 12:55:29 coyote firefox-esr[141594]: g_object_ref: assertion 
'G_IS_OBJECT (object)' failed
Aug 24 12:55:35 coyote plasmashell[2495]: libkcups: 
Get-Printer-Attributes last error: 0 successful-ok
Aug 24 12:55:35 coyote plasmashell[2495]: libkcups: 3 
"Brother_MFC_J6920DW_duplex_lowertray_coyote"
Aug 24 12:55:42 coyote kwin_x11[2453]: qt.qpa.xcb: QXcbConnection: XCB 
error: 3 (BadWindow), sequence: 10153, resource id: 90188401, major 
code: 15 (QueryTree), minor code: 0

===

I even added myself to the lp user in /etc/group, still no response.

Where do I look next?

Thanks.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

Re: CUPS on Bullseye and Bookworm

[Charles Curley]

On Sat, 20 May 2023 08:24:39 +0200
john doe  wrote:

> >
> > .home.arpa ? I had never heard of it until you mentioned it. You are
> > suggesting that I change every reference to localdomain to
> > .home.arpa? Implementing that change is going to be a major pain in
> > the arse.  
> 
> My idea was that .local and .localdomain could be an issue for the
> autodetection of the printer.
> That was simply a suggestion if you were not getting anywhere.

Ah, yes. I had wondered about that. Thanks for the clarification.

> 
> Granted, I should have phrased that in a better way (sorry about
> that).

No worries. That's what asking for clarification is for. :-)

> 
> I also want to point out that you have a domain name, I would use that
> instead of .home.arpa!

True. So any computer becomes foo.charlescurley.com instead of its
current foo.localdomain? That might work, but is still a huge PITA to
implement. I think I have a workable solution in the IP version of the
queue, and the Perl programmer's virtue of laziness suggests I use that.

> 
> Brian has done abetter job in trying to help you out than what I could
> have done!

He has done an excellent job. Thanks again, Brian.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: CUPS on Bullseye and Bookworm

[john doe]

On 5/17/23 21:56, Charles Curley wrote:

On Wed, 17 May 2023 19:21:23 +0200
john doe  wrote:


A few things, that I spotted while reading this thread and Im' not
sure if you got everything working!


Thank you. No, I don't have everything working.



- MDNS is using .local
- .localdomain should be moved to .home.arpa (see RFC)! :)


.home.arpa ? I had never heard of it until you mentioned it. You are
suggesting that I change every reference to localdomain to .home.arpa?
Implementing that change is going to be a major pain in the arse.


My idea was that .local and .localdomain could be an issue for the
autodetection of the printer.
That was simply a suggestion if you were not getting anywhere.

Granted, I should have phrased that in a better way (sorry about that).

I also want to point out that you have a domain name, I would use that
instead of .home.arpa!

Brian has done abetter job in trying to help you out than what I could
have done!

--
John Doe

Re: Bookworm CUPS Printing Revisited

[Charles Curley]

On Wed, 17 May 2023 13:10:21 -0600
Charles Curley  wrote:

> Thanks to Brian  on the thread "Re: CUPS on
> Bullseye and Bookworm" I now have CUPS working on dragon, my bookworm
> i386 architecture laptop.

Dragon being an i386 arch machine, I booted ideapc (AMD 64) to the
Bookworm RC1 XFCE live CD.
(https://cdimage.debian.org/cdimage/bookworm_di_rc1-live/amd64/iso-hybrid/)
I installed nothing. I ran several tests on that.

Using the automagical instant printer: nothing worked, not even using
"lp -d ".

Using the IP address queue, Netscape, Libreoffice and "lp -d" all
worked. At one point the system even told me the printer was out of
paper.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Bookworm CUPS Printing Revisited

[Charles Curley]

On Fri, 19 May 2023 16:07:56 +0100
Brian  wrote:

> On Thu 18 May 2023 at 14:26:13 -0600, Charles Curley wrote:
> 
>  [...]  
> 
> [...]
> 
>  [...]  
>  [...]  
> 
> The PDF queue is not part of the printing system.

|snarky comment omitted.|

> 
> > Firefox also allows printing from the system printer dialog. When I
> > selected that, it showed the same three queues. The two printer
> > queues had error messages.
> > 
> > For HP_Laserjet_MFP_m234sdw_C0FB67, "No destination host name
> > supplied by cups-browserd for printer "HP_Las..."  
> 
> cups-browserd uses mDNS to get the destination host name. OK, it can
> come off the rails at times, but ideapc is happy enough with it.
> 
> I'll again mention that neiher cups-browserd nor a manual queue is
> required for printing; I gave a test of this in another post.
> CUPS should form a temporary queue.

I ran "apt purge cups-browsed", then:

root@dragon:~# lpstat -l -e
HP_LaserJet_MFP_M234sdw_C0FB67 network none 
ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/
M234ip permanent ipp://localhost/printers/M234ip ipp://192.168.100.134/ipp/print
root@dragon:~# lpadmin -x M234ip
root@dragon:~# lpadmin -x HP_LaserJet_MFP_M234sdw_C0FB67
root@dragon:~# lpstat -l -e
HP_LaserJet_MFP_M234sdw_C0FB67 network none 
ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/
root@dragon:~# lp /usr/share/cups/data/form_english.pdf
lp: Error - No default destination.
root@dragon:~# lp -d HP_LaserJet_MFP_M234sdw_C0FB67 
/usr/share/cups/data/form_english.pdf
request id is HP_LaserJet_MFP_M234sdw_C0FB67-24 (1 file(s))
root@dragon:~# 

And nothing happened on the printer.

I then opened a PDF document in evince, opened the print dialog, and
selected that printer. I got a short-lived message, "rejecting jobs". I
turned the printer off. The printer went away in the print dialog. I
turned it back on. The printer re-appeared, along with the same
short-lived "rejecting jobs" message.

I went to Netscape. That printed.

I begin to think the problem is with GTK's printer dialog.

> 
> > For HP_Laserjet_MFP_m234sdw_C0FB67@hpbm234ethernet.local, I got an
> > error message, which disappeared before I could write it down. There
> > is now no error message. I tried printing to that, and this time the
> > printer came up, showed its "busy" indicator, and did nothing.  
> 
> This is often an indication that the dialog is unable to query the
> printer. It shouldn't happen on bookworm.
>   
> > > An alternative URI for M234 is
> > > 
> > >   ipp://192.168.100.134/ipp/print
> > > 
> > > and the previous lpadmin command could be run with this. It's OK
> > > as long as the IP does not change and it also cuts out the moving
> > > part of DNS-SD resolution.  
> > 
> > That worked:
> > 
> > root@dragon:~# lpadmin -p M234ip -v
> > "ipp://192.168.100.134/ipp/print" -E -m everywhere root@dragon:~#
> > lp -d M234ip /usr/share/cups/data/form_english.pdf request id is
> > M234ip-20 (1 file(s)) root@dragon:~# 
> > 
> > It also showed up in Firefox's system printer dialog. I printed to
> > it. Nothing. I then printed from Firefox's internal printer
> > dialog. That worked.  
> 
> The difference between M234 and M234ip is that the latter does not
> need to use resolving to get the IP of the ptinter. The queue should
> work in Abiword too.

I re-installed the M234ip queue. It did not work from abiword.

> 
> > > The problem with the GTK dialog is that it never handled its
> > > relationship with CUUPS correctly before bullseye (APIs and all
> > > that). However, it *always* got along with manually set up queues,
> > > which M234 is.
> > >   
> > 
> > That isn't what I see here.  
> 
> Maybe not, but it is still the case that it was GTK's handling of
> printer discovery that was the issue.
> 
> > John Doe seems to think MDNS doesn't like my network
> > setup. https://lists.debian.org/debian-user/2023/05/msg00767.html  
> 
> I queried hpm234ethernet.localdomain but you seemed happy with it, so
> I let it go.
> 

You asked where it came from, and I replied my DHCP and DNS servers. Is
there a problem with it?

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Bookworm CUPS Printing Revisited

[Brian]

On Thu 18 May 2023 at 14:26:13 -0600, Charles Curley wrote:

> On Thu, 18 May 2023 15:09:00 +0100
> Brian  wrote:

[...]

> > I haven't any idea why M234 does not work from the dialog. It might be
> > an issue with the GTK version. Personally, I would prefer that Firefox
> > was uused to confirm or not.
> 
> I installed xfce and firefox, and ran firefox on the computer (rather
> than over ssh to another computer). Firefox showed three queues: PDF,
> and two printer queues. The PDF one worked. The other two failed
> silently. The printer never woke up for either.

The PDF queue is not part of the printing system.

> Firefox also allows printing from the system printer dialog. When I
> selected that, it showed the same three queues. The two printer queues
> had error messages.
> 
> For HP_Laserjet_MFP_m234sdw_C0FB67, "No destination host name supplied
> by cups-browserd for printer "HP_Las..."

cups-browserd uses mDNS to get the destination host name. OK, it can
come off the rails at times, but ideapc is happy enough with it.

I'll again mention that neiher cups-browserd nor a manual queue is
required for printing; I gave a test of this in another post.
CUPS should form a temporary queue.

> For HP_Laserjet_MFP_m234sdw_C0FB67@hpbm234ethernet.local, I got an
> error message, which disappeared before I could write it down. There
> is now no error message. I tried printing to that, and this time the
> printer came up, showed its "busy" indicator, and did nothing.

This is often an indication that the dialog is unable to query the
printer. It shouldn't happen on bookworm.
  
> > An alternative URI for M234 is
> > 
> >   ipp://192.168.100.134/ipp/print
> > 
> > and the previous lpadmin command could be run with this. It's OK as
> > long as the IP does not change and it also cuts out the moving part
> > of DNS-SD resolution.
> 
> That worked:
> 
> root@dragon:~# lpadmin -p M234ip -v "ipp://192.168.100.134/ipp/print"
> -E -m everywhere root@dragon:~# lp -d M234ip
> /usr/share/cups/data/form_english.pdf request id is M234ip-20 (1
> file(s)) root@dragon:~# 
> 
> It also showed up in Firefox's system printer dialog. I printed to
> it. Nothing. I then printed from Firefox's internal printer
> dialog. That worked.

The difference between M234 and M234ip is that the latter does not
need to use resolving to get the IP of the ptinter. The queue should
work in Abiword too.

> > The problem with the GTK dialog is that it never handled its
> > relationship with CUUPS correctly before bullseye (APIs and all
> > that). However, it *always* got along with manually set up queues,
> > which M234 is.
> > 
> 
> That isn't what I see here.

Maybe not, but it is still the case that it was GTK's handling of
printer discovery that was the issue.

> John Doe seems to think MDNS doesn't like my network
> setup. https://lists.debian.org/debian-user/2023/05/msg00767.html

I queried hpm234ethernet.localdomain but you seemed happy with it, so
I let it go.

-- 
Brian.

Re: Bookworm CUPS Printing Revisited

[Charles Curley]

On Thu, 18 May 2023 15:09:00 +0100
Brian  wrote:

> On Wed 17 May 2023 at 13:10:21 -0600, Charles Curley wrote:
> 
> > Thanks to Brian  on the thread "Re: CUPS on
> > Bullseye and Bookworm" I now have CUPS working on dragon, my
> > bookworm i386 architecture laptop.
> > 
> > Or I should say, CUPS printing is more or less working but something
> > else (GTK printing?) isn't. I can find the driverless printer on the
> > network, create a print queue for it, and print to it.
> > 
> > root@dragon:~# driverless
> > ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/
> > root@dragon:~# lpadmin -p M234 -v
> > "ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/"
> > -E -m everywhere root@dragon:~# lp -d M234
> > /usr/share/cups/data/form_english.pdf request id is M234-3 (1
> > file(s)) root@dragon:~# lp -d M234 /etc/nsswitch.conf request id is
> > M234-4 (1 file(s)) root@dragon:~# 
> > 
> > So far, so good.
> > 
> > I have two problems:
> > 
> > 1) I cannot print from abiword. abiword finds three printer queues:
> > print to file (which works), M234 (as previously set up), and
> > HP_Laserjet_MFP_M234dsw_COFB67. The two printer queues do not work.
> > The former see the printer light up, the "busy" indicator light up
> > briefly, then nothing. The latter evinces no action on the printer
> > at all.  
> 
> I haven't any idea why M234 does not work from the dialog. It might be
> an issue with the GTK version. Personally, I would prefer that Firefox
> was uused to confirm or not.

I installed xfce and firefox, and ran firefox on the computer (rather
than over ssh to another computer). Firefox showed three queues: PDF,
and two printer queues. The PDF one worked. The other two failed
silently. The printer never woke up for either.

Firefox also allows printing from the system printer dialog. When I
selected that, it showed the same three queues. The two printer queues
had error messages.

For HP_Laserjet_MFP_m234sdw_C0FB67, "No destination host name supplied
by cups-browserd for printer "HP_Las..."

For HP_Laserjet_MFP_m234sdw_C0FB67@hpbm234ethernet.local, I got an
error message, which disappeared before I could write it down. There
is now no error message. I tried printing to that, and this time the
printer came up, showed its "busy" indicator, and did nothing.



> 
> An alternative URI for M234 is
> 
>   ipp://192.168.100.134/ipp/print
> 
> and the previous lpadmin command could be run with this. It's OK as
> long as the IP does not change and it also cuts out the moving part
> of DNS-SD resolution.

That worked:

root@dragon:~# lpadmin -p M234ip -v "ipp://192.168.100.134/ipp/print"
-E -m everywhere root@dragon:~# lp -d M234ip
/usr/share/cups/data/form_english.pdf request id is M234ip-20 (1
file(s)) root@dragon:~# 

It also showed up in Firefox's system printer dialog. I printed to
it. Nothing. I then printed from Firefox's internal printer
dialog. That worked.

> 
> The problem with the GTK dialog is that it never handled its
> relationship with CUUPS correctly before bullseye (APIs and all
> that). However, it *always* got along with manually set up queues,
> which M234 is.
> 

That isn't what I see here.

John Doe seems to think MDNS doesn't like my network
setup. https://lists.debian.org/debian-user/2023/05/msg00767.html

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Bookworm CUPS Printing Revisited

[Brian]

On Wed 17 May 2023 at 13:10:21 -0600, Charles Curley wrote:

> Thanks to Brian  on the thread "Re: CUPS on
> Bullseye and Bookworm" I now have CUPS working on dragon, my bookworm
> i386 architecture laptop.
> 
> Or I should say, CUPS printing is more or less working but something
> else (GTK printing?) isn't. I can find the driverless printer on the
> network, create a print queue for it, and print to it.
> 
> root@dragon:~# driverless
> ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/
> root@dragon:~# lpadmin -p M234 -v 
> "ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/" -E -m 
> everywhere
> root@dragon:~# lp -d M234 /usr/share/cups/data/form_english.pdf
> request id is M234-3 (1 file(s))
> root@dragon:~# lp -d M234 /etc/nsswitch.conf
> request id is M234-4 (1 file(s))
> root@dragon:~# 
> 
> So far, so good.
> 
> I have two problems:
> 
> 1) I cannot print from abiword. abiword finds three printer queues:
> print to file (which works), M234 (as previously set up), and
> HP_Laserjet_MFP_M234dsw_COFB67. The two printer queues do not work. The
> former see the printer light up, the "busy" indicator light up briefly,
> then nothing. The latter evinces no action on the printer at all.

I haven't any idea why M234 does not work from the dialog. It might be
an issue with the GTK version. Personally, I would prefer that Firefox
was uused to confirm or not.

An alternative URI for M234 is

  ipp://192.168.100.134/ipp/print

and the previous lpadmin command could be run with this. It's OK as long
as the IP does not change and it also cuts out the moving part of DNS-SD
resolution.

> (I selected abiword rather than LibreOffice because LO is a bit of a
> resource hog.)

LibreOffice has its own dialog with its own issues.
 
> 2) When I print from the command line, I get results printing to M234.
> But when I try printing to the other queue (directly to the printer as
> I understand it), I see:

Strictly speaking CUPS never prints directly to a printer but via a
queue, whether it be manually set up, auto set up or temporary.

> charles@dragon:~$ lp -d HP_Laserjet_MFP_M234dsw_C0FB67 ~/test.document.pdf 
> lp: Error - The printer or class does not exist.
> charles@dragon:~$

Pass on this for the moment.

> I copied the printer name from abiword's list of available printers. Is
> that the correct way to specify a driverless printer? I also tried
> copying and pasting the ipps:// and dnssd:// printers shown by lpinfo
> -v. Same error.
> 
> According to https://wiki.debian.org/CUPSDriverlessPrinting, "the GTK
> print dialog on buster and before (firefox and evince, for example),
> has its own way of dealing with a network printer. Unfortunately,
> applications that print through this dialog do not make use of CUPS'
> temporary queue formation. To have a queue for an IPP printer visible
> and usable, users should manually set up a queue with lpadmin, the CUPS
> web interface or system-config-printer or rely on cups-browsed to do it
> for them. The situation on bullseye and later has improved." Regression?

The problem with the GTK dialog is that it never handled its relationship
with CUUPS correctly before bullseye (APIs and all that). However, it
*always* got along with manually set up queues, which M234 is.

-- 
Brian.

Re: Bookworm CUPS Printing Revisited

[gene heskett]

On 5/18/23 00:28, David Wright wrote:

On Wed 17 May 2023 at 16:15:11 (-0400), gene heskett wrote:


Couple folks rather pointedly asked if I ever read changelogs.  But
before they can be read, they have to be found.  I just spent 2 hours
with mc, punching f3 on changelog.gz's, trolling thru /usr/share/docs
w/o finding an entry for kernels.  So where do I find this famous
changelog I'm supposed to read?  Or are we becoming windoze, and its a
secret?


Google:   linux kernel changelog

Hit 1:https://www.kernel.org/

Select:   5.0.180 chagelog

Edit: Last two characters in address bar s/80/79/

Enjoy.

Cheers,
David.

.
While this might work, it depends on a photographic memory to remember 
all that. At my age of 88, I can't remember what if anything I had for 
breakfast.


What we need is a web script that works something like tail, but shows 
everything newer the $date.  That would be very helpfull if the code is 
well explained and the reader has coding experience which I do. However 
its not with recent 64 and 128 bit stuff. OpenSCAD and rs-274-D gcode 
these days.


Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Bookworm CUPS Printing Revisited

[David Wright]

On Wed 17 May 2023 at 16:15:11 (-0400), gene heskett wrote:

> Couple folks rather pointedly asked if I ever read changelogs.  But
> before they can be read, they have to be found.  I just spent 2 hours
> with mc, punching f3 on changelog.gz's, trolling thru /usr/share/docs
> w/o finding an entry for kernels.  So where do I find this famous
> changelog I'm supposed to read?  Or are we becoming windoze, and its a
> secret?

Google:   linux kernel changelog

Hit 1:https://www.kernel.org/

Select:   5.0.180 chagelog

Edit: Last two characters in address bar s/80/79/

Enjoy.

Cheers,
David.

Re: Bookworm CUPS Printing Revisited

[gene heskett]

On 5/17/23 15:11, Charles Curley wrote:

Thanks to Brian  on the thread "Re: CUPS on
Bullseye and Bookworm" I now have CUPS working on dragon, my bookworm
i386 architecture laptop.

Or I should say, CUPS printing is more or less working but something
else (GTK printing?) isn't. I can find the driverless printer on the
network, create a print queue for it, and print to it.

root@dragon:~# driverless
ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/
root@dragon:~# lpadmin -p M234 -v 
"ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/" -E -m 
everywhere
root@dragon:~# lp -d M234 /usr/share/cups/data/form_english.pdf
request id is M234-3 (1 file(s))
root@dragon:~# lp -d M234 /etc/nsswitch.conf
request id is M234-4 (1 file(s))
root@dragon:~#

So far, so good.

I have two problems:

1) I cannot print from abiword. abiword finds three printer queues:
print to file (which works), M234 (as previously set up), and
HP_Laserjet_MFP_M234dsw_COFB67. The two printer queues do not work. The
former see the printer light up, the "busy" indicator light up briefly,
then nothing. The latter evinces no action on the printer at all.

(I selected abiword rather than LibreOffice because LO is a bit of a
resource hog.)

2) When I print from the command line, I get results printing to M234.
But when I try printing to the other queue (directly to the printer as
I understand it), I see:

charles@dragon:~$ lp -d HP_Laserjet_MFP_M234dsw_C0FB67 ~/test.document.pdf
lp: Error - The printer or class does not exist.
charles@dragon:~$

I copied the printer name from abiword's list of available printers. Is
that the correct way to specify a driverless printer? I also tried
copying and pasting the ipps:// and dnssd:// printers shown by lpinfo
-v. Same error.

According to https://wiki.debian.org/CUPSDriverlessPrinting, "the GTK
print dialog on buster and before (firefox and evince, for example),
has its own way of dealing with a network printer. Unfortunately,
applications that print through this dialog do not make use of CUPS'
temporary queue formation. To have a queue for an IPP printer visible
and usable, users should manually set up a queue with lpadmin, the CUPS
web interface or system-config-printer or rely on cups-browsed to do it
for them. The situation on bullseye and later has improved." Regression?

I started this original thread because I could not get a bullseye client 
to work with this bullseye server but buster clients worked fine..  For 
me, the fix was something that can only be described as serendipity.


Apt had installed a newer kernel about a week back, probably a security 
fix, but since my whole system is behind the best guard dog ever, dd-wrt 
in my router, and I had just rebooted from an overnight freeze up, I 
ignored its blabbing that I needed to reboot until I had another similar 
freeze up Monday morning and had to reboot with the front panel reset 
button. New kernel now running, bullseye server to bullseye client now 
Just Works.


Not supposed to be snarky, but...

Couple folks rather pointedly asked if I ever read changelogs.  But 
before they can be read, they have to be found.  I just spent 2 hours 
with mc, punching f3 on changelog.gz's, trolling thru /usr/share/docs 
w/o finding an entry for kernels.  So where do I find this famous 
changelog I'm supposed to read?  Or are we becoming windoze, and its a 
secret?


Since 1992, a truely complete changelog is quite likely several 
terabytes so a URL link to a tail output would suffice.



Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

Re: CUPS on Bullseye and Bookworm

[Charles Curley]

On Wed, 17 May 2023 19:21:23 +0200
john doe  wrote:

> A few things, that I spotted while reading this thread and Im' not
> sure if you got everything working!

Thank you. No, I don't have everything working.

> 
> - MDNS is using .local
> - .localdomain should be moved to .home.arpa (see RFC)! :)

.home.arpa ? I had never heard of it until you mentioned it. You are
suggesting that I change every reference to localdomain to .home.arpa?
Implementing that change is going to be a major pain in the arse.

> - 9100 (TCP) is LPD AKA LPR

Thanks.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Bookworm CUPS Printing Revisited

[Charles Curley]

Thanks to Brian  on the thread "Re: CUPS on
Bullseye and Bookworm" I now have CUPS working on dragon, my bookworm
i386 architecture laptop.

Or I should say, CUPS printing is more or less working but something
else (GTK printing?) isn't. I can find the driverless printer on the
network, create a print queue for it, and print to it.

root@dragon:~# driverless
ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/
root@dragon:~# lpadmin -p M234 -v 
"ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/" -E -m 
everywhere
root@dragon:~# lp -d M234 /usr/share/cups/data/form_english.pdf
request id is M234-3 (1 file(s))
root@dragon:~# lp -d M234 /etc/nsswitch.conf
request id is M234-4 (1 file(s))
root@dragon:~# 

So far, so good.

I have two problems:

1) I cannot print from abiword. abiword finds three printer queues:
print to file (which works), M234 (as previously set up), and
HP_Laserjet_MFP_M234dsw_COFB67. The two printer queues do not work. The
former see the printer light up, the "busy" indicator light up briefly,
then nothing. The latter evinces no action on the printer at all.

(I selected abiword rather than LibreOffice because LO is a bit of a
resource hog.)

2) When I print from the command line, I get results printing to M234.
But when I try printing to the other queue (directly to the printer as
I understand it), I see:

charles@dragon:~$ lp -d HP_Laserjet_MFP_M234dsw_C0FB67 ~/test.document.pdf 
lp: Error - The printer or class does not exist.
charles@dragon:~$

I copied the printer name from abiword's list of available printers. Is
that the correct way to specify a driverless printer? I also tried
copying and pasting the ipps:// and dnssd:// printers shown by lpinfo
-v. Same error.

According to https://wiki.debian.org/CUPSDriverlessPrinting, "the GTK
print dialog on buster and before (firefox and evince, for example),
has its own way of dealing with a network printer. Unfortunately,
applications that print through this dialog do not make use of CUPS'
temporary queue formation. To have a queue for an IPP printer visible
and usable, users should manually set up a queue with lpadmin, the CUPS
web interface or system-config-printer or rely on cups-browsed to do it
for them. The situation on bullseye and later has improved." Regression?

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: CUPS on Bullseye and Bookworm

[john doe]

On 5/15/23 16:46, Charles Curley wrote:

On Mon, 15 May 2023 07:31:29 -0600
Charles Curley  wrote:


I solved that one. I had closed TCP port 9100. Opening that up on the
server got me running. However, that did not solve the problem for the
other two protocols.


Correction. That didn't solve it. I realized that port 9100 on hawk is
irrelevant because the socket queue goes directly to the printer, not
via hawk. I closed the port on hawk and I can still print to the
printer via that queue.



A few things, that I spotted while reading this thread and Im' not sure
if you got everything working!

- MDNS is using .local
- .localdomain should be moved to .home.arpa (see RFC)! :)
- 9100 (TCP) is LPD AKA LPR

--
John Doe

Re: CUPS on Bullseye and Bookworm

[Brian]

On Mon 15 May 2023 at 18:29:12 +0100, Brian wrote:

> On Mon 15 May 2023 at 16:33:42 +0100, Brian wrote:
> 
> [...]
> 
> > Good. The issue is solved, but how do you feel about being adventurous?
> > 
> > Assuming you have deleted the three non-working queues,'lpstat -a' and
> > s-c-p should show only M234. On dragon do
> > 
> >   systemctl stop cups-browsed
> > 
> > Check that 'lpstat -l -e' still shows the printer as
> > 
> >HP_LaserJet_MFP_M234sdw_C0FB67
> > 
> > * Now print: 'lp -d HP_LaserJet_MFP_M234sdw_C0FB67 /etc/nsswitch.conf'.
> > * Immediately afterwards do 'lpstat -a'. What do you observe?
> > * Run 'lpstat -a' a minute or so later. What do you observe?
> 
> Thinking on: the test can be carried out withoit using papaer and ink.
> For the first step:
> 
> * Execute 'lpoptions -p HP_LaserJet_MFP_M234sdw_C0FB67 -l'.

For illustrative purposes on a machine without cups-browsed:

  brian@test-new:~$ lpstat -a
  lpstat: No destinations added.
  brian@test-new:~$ 

There aren't any local print queues.

  brian@test-new:~$ lpstat -e
  ENVY4500
  ENVY4500_USB
  RX420
  brian@test-new:~$

Shows all available destinations on the local network. These are the names
of prospective (on-demand) queues.

  brian@test-new:~$ lpoptions -p envy4500 -l
  PageSize/Media Size: 100x150mm 111.76x152.4mm 3.5x5 3.5x5.Borderless 3x5
  4x6 4x6.Borderless 5x7 5x7.Borderless 5x8 8x10 8x10.Borderless *A4
  A4.Borderless A5 A6 A6.Borderless B5 Env10 EnvA2 EnvC5 EnvC6 EnvChou3
  EnvChou4 EnvDL EnvMonarch EnvPersonal Executive ISOB5 Legal Letter
  Letter.Borderless Postcard Postcard.Borderless Statement Custom.WIDTHxHEIGHT
  MediaType/Media Type: *Stationery PhotographicGlossy
  cupsPrintQuality/cupsPrintQuality: Draft *Normal High
  ColorModel/Output Mode: *RGB Gray Gray16 DeviceGray DeviceRGB AdobeRGB
  Duplex/Duplex: *None DuplexNoTumble DuplexTumble
  OutputBin/OutputBin: *FaceUp
  brian@test-new:~$

The destination has been contacted and querued for the device's attributes.

  brian@test-new:~$ lpstat -a
  ENVY4500 accepting requests since Tue 16 May 2023 14:50:01 BST
  brian@test-new:~$

A local queue for the ENVY4500 destination has been created. Unlike a queue
created manually or with cups-browsed it is a *temporary* queue. Just over
a minute later:

  brian@test-new:~$ lpstat -a
  lpstat: No destinations added.
  brian@test-new:~$

This is the future of printing and it is here now. No manual queues. No
cups-browsed.

-- 
Brian.

Re: CUPS on Bullseye and Bookworm

[Dan Ritter]

Charles Curley wrote: 
> On Mon, 15 May 2023 20:30:38 -0400
> Timothy M Butterworth  wrote:
> 
> > > I also have an ancient i386 IBM R51 running Bookworm, dragon. On
> > > dragon, using system-config-printer, I can see the printer
> > > automagically discovered. I can open up the queue window for the
> > > printer, and request a test page.
> > >  
> > 
> > If you are trying to run Bullseye on an actual i386 CPU you will have
> > strange problems as the minimum hardware version is i686 Pentium II.
> > That change took place in Debian quite a while ago. The arch still
> > says i386 due to the large number of dependencies it did not make
> > sense to try to change it to i686.
> 
> root@dragon:~# uname -a
> Linux dragon 6.1.0-9-686 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08) 
> i686 GNU/Linux
> root@dragon:~# 

The actually useful thing would be lscpu.

It's not necessary, because "IBM R51" is enough to locate it as
a ThinkPad R51, which has a Pentium M CPU, which is precisely an
i686 by the current nomenclature.

-dsr-

Re: CUPS on Bullseye and Bookworm

[Charles Curley]

On Mon, 15 May 2023 20:30:38 -0400
Timothy M Butterworth  wrote:

> > I also have an ancient i386 IBM R51 running Bookworm, dragon. On
> > dragon, using system-config-printer, I can see the printer
> > automagically discovered. I can open up the queue window for the
> > printer, and request a test page.
> >  
> 
> If you are trying to run Bullseye on an actual i386 CPU you will have
> strange problems as the minimum hardware version is i686 Pentium II.
> That change took place in Debian quite a while ago. The arch still
> says i386 due to the large number of dependencies it did not make
> sense to try to change it to i686.

root@dragon:~# uname -a
Linux dragon 6.1.0-9-686 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08) 
i686 GNU/Linux
root@dragon:~# 


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: CUPS on Bullseye and Bookworm

[Timothy M Butterworth]

On Sun, May 14, 2023 at 1:30 PM Charles Curley <
charlescur...@charlescurley.com> wrote:

> I have an HP HP_LaserJet_MFP_M234sdw_C0FB67_USB_, one of those modern
> "no driver" multifunction printers. It works fine on Bullseye. I have
> the printer hooked up via USB to a server, hawk, and it prints just
> fine.
>
> I have a client, ideapc, which sees the printer and prints to it just
> fine.
>
> I also have an ancient i386 IBM R51 running Bookworm, dragon. On dragon,
> using system-config-printer, I can see the printer automagically
> discovered. I can open up the queue window for the printer, and request
> a test page.
>

If you are trying to run Bullseye on an actual i386 CPU you will have
strange problems as the minimum hardware version is i686 Pentium II. That
change took place in Debian quite a while ago. The arch still says i386 due
to the large number of dependencies it did not make sense to try to change
it to i686.



> Alas, I see the test page in the queue briefly. The queue window says
> "processing - not connected?", then "Printer error". Then the print job
> disappears, leaving no error message. (This is a change in behavior from
> Bullseye. I do not like it.)
>
> The printer does come awake and report an error when I ask for the test
> page. I don't see anything in the printer's logs.
>
> Logging on both machines shows no errors. I am running firewalld on
> dragon, and did enable logging for unicast. firewalld-cmd reports the
> following, among other things:
>
>services: ipp ipp-client mdns samba-client smtp ssh
>
> --
> Does anybody read signatures any more?
>
> https://charlescurley.com
> https://charlescurley.com/blog/
>
>

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

Re: CUPS on Bullseye and Bookworm

[gene heskett]

On 5/15/23 14:32, Charles Curley wrote:

On Mon, 15 May 2023 12:18:56 -0400
gene heskett  wrote:


this is interesting Brian, but how do I adapt it to my brother
printers? All I can get by substituting the queue name M234 is
"printer or class does not exist".


Right. M234 is the name assigned previously. You get the URI(s) of
available printer(s) by running the program driverless. E.g.:

root@dragon:~# driverless
ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/
root@dragon:~#

Then feed that into:

lpadmin -p M234 -v "URI" -E -m everywhere

But edit in a better (for you) name for the printer than M234.

You might get away with something like:

lpadmin -p heskett.printer -v "$(driverless)" -E -m everywhere

but I haven't experimented with that.


And the only printer that shows in the driverless output:
ipp://Brother%20MFC-J6920DW._ipp._tcp.local/
is I believe the only one of 3 references to that physical printer in 
cups, that does not work, it ignores the tray selection passed.  That is 
an expen$ive lack.


Thanks Charles.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

Re: CUPS on Bullseye and Bookworm

[Charles Curley]

On Mon, 15 May 2023 12:18:56 -0400
gene heskett  wrote:

> this is interesting Brian, but how do I adapt it to my brother
> printers? All I can get by substituting the queue name M234 is
> "printer or class does not exist".

Right. M234 is the name assigned previously. You get the URI(s) of
available printer(s) by running the program driverless. E.g.:

root@dragon:~# driverless
ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/
root@dragon:~# 

Then feed that into:

lpadmin -p M234 -v "URI" -E -m everywhere

But edit in a better (for you) name for the printer than M234.

You might get away with something like:

lpadmin -p heskett.printer -v "$(driverless)" -E -m everywhere

but I haven't experimented with that.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: CUPS on Bullseye and Bookworm

[gene heskett]

On 5/15/23 07:10, Brian wrote:

On Sun 14 May 2023 at 20:57:23 -0600, Charles Curley wrote:


On Sun, 14 May 2023 23:30:25 +0100
Brian  wrote:


On Sun 14 May 2023 at 14:04:51 -0600, Charles Curley wrote:





We take it that dragon, hawk and the printer are network connected.

Give what you get from dragon with

   avahi-browse -rt _ipp._tcp
   avahi-browse -rt _uscan._tcp
   driverless
   lpstat -l -e

avahi-browse is in the avahi-utils package.



root@dragon:~# avahi-browse -rt _ipp._tcp
+ wlp2s2 IPv4 HP LaserJet MFP M234sdw (C0FB67)  Internet Printer
 local
= wlp2s2 IPv4 HP LaserJet MFP M234sdw (C0FB67)  Internet Printer
 local
hostname = [hpm234ethernet.local]
address = [192.168.100.134]
port = [631]
txt = ["mopria-certified=2.1" "mac=6c:02:e0:c0:fb:67" "usb_MDL=HP LaserJet MFP M232-M237" "usb_MFG=HP" "TLS=1.2" "PaperMax=legal-A4" "kind=document,envelope,photo" "UUID=d532fa73-f559-43ca-9f8e-1eef16972345" 
"Fax=F" "Scan=T" "Duplex=T" "Color=F" "note=" "adminurl=http://hpm234ethernet.local./hp/device/info_config_AirPrint.html?tab=Networking=AirPrintStatus; "priority=10" "product=(HP LaserJet MFP M232-M237)" 
"ty=HP LaserJet MFP M232-M237" "URF=V1.4,CP99,W8,OB10,PQ3-4,DM1,IS1-4,MT1-3-5,RS300-600" "rp=ipp/print" "pdl=application/PCLm,application/octet-stream,image/pwg-raster" "qtotal=1" "txtvers=1"]


Useful data but an aside first:

The pdl= key lacks image/urf. HP claims AirPrint support for the device 
(URF=V1.4,...).
It looks like you have been sold a pup. A firmware update?


root@dragon:~# driverless
ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/


This is the URI for the printer. You will need to substitute it later into an 
lpadmin
command.


root@dragon:~# lpstat -l -e
HP-HP-LaserJet-MFP-M232-M237 permanent 
ipp://localhost/printers/HP-HP-LaserJet-MFP-M232-M237 
dnssd://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipp._tcp.local/?uuid=d532fa73-f559-43ca-9f8e-1eef16972345
HP-HP-LaserJet-MFP-M232-M237-2 permanent 
ipp://localhost/printers/HP-HP-LaserJet-MFP-M232-M237-2 
ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/
HP-LaserJet-MFP-M232-M237 permanent 
ipp://localhost/printers/HP-LaserJet-MFP-M232-M237 
socket://hpm234ethernet.localdomain:9100
HP_LaserJet_MFP_M234sdw_C0FB67 network none 
ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/
root@dragon:~#


The first three entries are print queues (permanent) you have set up. The 
fourth is the
printer.

Execute

   lpadmin -p M234 -v "URI" -E -m everywhere

Test with

   lp -d M234 /etc/nsswitch.conf


this is interesting Brian, but how do I adapt it to my brother printers?
All I can get by substituting the queue name M234 is "printer or class 
does not exist".


Interestingly, a reboot of this machine to bring in a new kernel, seems 
to have fixed cups for armbian bullseye, not 100% tested yet for 
function but ff at localhost:631 on both of the bpi's now has a full 
list of shared printers that are now displayed by geany as target printers.


Thanks Brian.


Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

Re: CUPS on Bullseye and Bookworm

[Brian]

On Mon 15 May 2023 at 08:24:28 -0600, Charles Curley wrote:

> On Mon, 15 May 2023 12:09:33 +0100
> Brian  wrote:

[...]

> Ah, OK. So can I get rid of the three queues and print directly to the
> printer?

Indeed you can! 'lpstat -l -e' should show only the printer on the network
and a working local queue, M234. 
 
> > Execute
> > 
> >   lpadmin -p M234 -v "URI" -E -m everywhere
> > 
> > Test with
> > 
> >   lp -d M234 /etc/nsswitch.conf
> 
> root@dragon:~# lp -d M234 /etc/nsswitch.conf
> lp: Error - The printer or class does not exist.
> root@dragon:~# lpadmin -p M234 -v "URI" -E -m everywhere
> lpadmin: Bad device-uri "URI".
> root@dragon:~# lpadmin -p M234 -v 
> "ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/" -E -m 
> everywhere
> root@dragon:~# lp -d M234 /etc/nsswitch.conf
> request id is M234-25 (1 file(s))
> root@dragon:~# 
> 
> And that printed. And I see a new queue on dragon's
> system-config-printer.

Good. The issue is solved, but how do you feel about being adventurous?

Assuming you have deleted the three non-working queues,'lpstat -a' and
s-c-p should show only M234. On dragon do

  systemctl stop cups-browsed

Check that 'lpstat -l -e' still shows the printer as

   HP_LaserJet_MFP_M234sdw_C0FB67

* Now print: 'lp -d HP_LaserJet_MFP_M234sdw_C0FB67 /etc/nsswitch.conf'.
* Immediately afterwards do 'lpstat -a'. What do you observe?
* Run 'lpstat -a' a minute or so later. What do you observe?

-- 
Brian.

Re: CUPS on Bullseye and Bookworm

[Charles Curley]

On Mon, 15 May 2023 15:42:51 +0100
Brian  wrote:

> On Mon 15 May 2023 at 08:07:12 -0600, Charles Curley wrote:
> 
>  [...]  
>  [...]  
> > 
> > Possibly just legacy habits. I'm not accustomed to this automation.
> >  
>  
> Possibly. You are not alone in this. The thinking appears to be: "I
> have an HP printer; therefore I must use HPLIP". Oftern it is
> downhill from there. Unlees there are special needs, HPLIP is
> redundant with a modern MFP. 

Yup.

I have an older inkjet HP also on hawk, so I have it on hawk and
ideapc. However, I did not put HPLIP on dragon. I've had the inkjet
shut down during these exercises.

>  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
> 
> cups-browsed works well for many users, but can be a little
> temperamental. 

It also can take its time. After this experience I would recommend
waiting three minutes or so to see if it does its magic. dragon is an
ancient IBM (not Lenovo, although manufactured by Lenovo) and on the
slow side these days, so three minutes may be a bit much.

>  [...]  
> 
> [...]
> 
>  [...]  
>  [...]  
> 
> avahi-browse shows hpm234ethernet.local for the hostname.

I conjecture that's an avahi-browse bug. Why would anyone have a 11
letter TLD name? So perhaps a-b truncates it.

> 
> BTW, is hpm234ethernet you setting or HP's?
> 

Mine, via DNS.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: CUPS on Bullseye and Bookworm

[Charles Curley]

On Mon, 15 May 2023 07:31:29 -0600
Charles Curley  wrote:

> I solved that one. I had closed TCP port 9100. Opening that up on the
> server got me running. However, that did not solve the problem for the
> other two protocols.

Correction. That didn't solve it. I realized that port 9100 on hawk is
irrelevant because the socket queue goes directly to the printer, not
via hawk. I closed the port on hawk and I can still print to the
printer via that queue.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: CUPS on Bullseye and Bookworm

[Brian]

On Mon 15 May 2023 at 08:07:12 -0600, Charles Curley wrote:

> On Mon, 15 May 2023 14:22:14 +0100
> Brian  wrote:
> > 
> > Consider: the printer can be discovered via mDNS/DNS-SD by all
> > machines on the network. ideapc does this and hasn't any difficulty
> > printing. So why set up a server when hawk will see the printer as
> > ideapc does? 
> 
> Possibly just legacy habits. I'm not accustomed to this automation.
 
Possibly. You are not alone in this. The thinking appears to be: "I have
an HP printer; therefore I must use HPLIP". Oftern it is downhill from
there. Unlees there are special needs, HPLIP is redundant with a modern
MFP. 
 
> > Additionally, assuming the printer provides the IPP-over-USB protocol,
> > the USB queue will not work. See
> > 
> >   https://wiki.debian.org/CUPSDriverlessPrinting
> > 
> >  [...]  
> > 
> > The two URIs are equivalent.
> > 
> >  [...]  
> > > 
> > > implicitclass://HP_LaserJet_MFP_M234sdw_C0FB67_/  
> > 
> > cups-browsed has automatically set up a queue. Unless it is having an
> > off-day, it should do the same on hawk and dragon.
> 
> I have no idea what's going on here. I now see such a queue on hawk but
> not dragon. Possibly the fact that I rebooted hawk yesterday had
> something to do with it? I will reboot dragon later today and see if
> that makes a difference.

cups-browsed works well for many users, but can be a little temperamental.
  
> >  [...]  
> >  [...]  
> >  [...]  

[...]

> > hpm234ethernet.local?
> 
> Again, the "localdomain" is correct.

avahi-browse shows hpm234ethernet.local for the hostname.

BTW, is hpm234ethernet you setting or HP's?

-- 
Brian.

Re: CUPS on Bullseye and Bookworm

[Charles Curley]

On Mon, 15 May 2023 12:09:33 +0100
Brian  wrote:

> Useful data but an aside first:
> 
> The pdl= key lacks image/urf. HP claims AirPrint support for the
> device (URF=V1.4,...). It looks like you have been sold a pup. A
> firmware update?

I will look into that later today.

> 
> > root@dragon:~# driverless
> > ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/  
> 
> This is the URI for the printer. You will need to substitute it later
> into an lpadmin command.
> 
> > root@dragon:~# lpstat -l -e
> > HP-HP-LaserJet-MFP-M232-M237 permanent
> > ipp://localhost/printers/HP-HP-LaserJet-MFP-M232-M237
> > dnssd://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipp._tcp.local/?uuid=d532fa73-f559-43ca-9f8e-1eef16972345
> > HP-HP-LaserJet-MFP-M232-M237-2 permanent
> > ipp://localhost/printers/HP-HP-LaserJet-MFP-M232-M237-2
> > ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/
> > HP-LaserJet-MFP-M232-M237 permanent
> > ipp://localhost/printers/HP-LaserJet-MFP-M232-M237
> > socket://hpm234ethernet.localdomain:9100
> > HP_LaserJet_MFP_M234sdw_C0FB67 network none
> > ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/
> > root@dragon:~#   
> 
> The first three entries are print queues (permanent) you have set up.
> The fourth is the printer.

Ah, OK. So can I get rid of the three queues and print directly to the
printer?

> 
> Execute
> 
>   lpadmin -p M234 -v "URI" -E -m everywhere
> 
> Test with
> 
>   lp -d M234 /etc/nsswitch.conf

root@dragon:~# lp -d M234 /etc/nsswitch.conf
lp: Error - The printer or class does not exist.
root@dragon:~# lpadmin -p M234 -v "URI" -E -m everywhere
lpadmin: Bad device-uri "URI".
root@dragon:~# lpadmin -p M234 -v 
"ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/" -E -m 
everywhere
root@dragon:~# lp -d M234 /etc/nsswitch.conf
request id is M234-25 (1 file(s))
root@dragon:~# 

And that printed. And I see a new queue on dragon's
system-config-printer.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: CUPS on Bullseye and Bookworm

[Charles Curley]

On Mon, 15 May 2023 14:22:14 +0100
Brian  wrote:

> > Not that I know of.  
> 
> Blocking port 5353 (mdns) is not unknown.

True. It is open (udp) on hawk (server) and ideapc, where I am running
shorewall (iptables). dragon has firewalld, which simply shows the
service, mdns, as open, but does not indicate the protocol. 

>  
>  [...]  
> > 
> > I shut the firewall down ("systemctl stop firewalld"), ran test
> > pages. Same non-results, except that system-control-printer now
> > reports:
> > 
> > Idle - Print job canceled at printer.
> > 
> > 
> > I tried increasing the logging, which involved stopping and
> > restarting the cups service. In the process of doing that, the
> > client and server both managed to forget the printer. I
> > re-installed it. On the server, I have one instance of the printer,
> > protocol:
> > 
> > hp:/usb/HP_LaserJet_MFP_M232-M237?serial=VNB4J02590  
> 
> Consider: the printer can be discovered via mDNS/DNS-SD by all
> machines on the network. ideapc does this and hasn't any difficulty
> printing. So why set up a server when hawk will see the printer as
> ideapc does? 

Possibly just legacy habits. I'm not accustomed to this automation.


> 
> Additionally, assuming the printer provides the IPP-over-USB protocol,
> the USB queue will not work. See
> 
>   https://wiki.debian.org/CUPSDriverlessPrinting
> 
>  [...]  
> 
> The two URIs are equivalent.
> 
>  [...]  
> > 
> > implicitclass://HP_LaserJet_MFP_M234sdw_C0FB67_/  
> 
> cups-browsed has automatically set up a queue. Unless it is having an
> off-day, it should do the same on hawk and dragon.

I have no idea what's going on here. I now see such a queue on hawk but
not dragon. Possibly the fact that I rebooted hawk yesterday had
something to do with it? I will reboot dragon later today and see if
that makes a difference.

>  
>  [...]  
>  [...]  
>  [...]  
> >  
> > I tried setting up a printer manually on the non-working client.
> > 
> > ipp://hawk.localdomain/printers/HP_LaserJet_MFP_M232-M237  
> 
> hawk.local would be the correct hostname.

Nope, it's localdomain. It's all set up in DNS.

> 
> > No test page, and I got:
> > 
> > Processing - The printer may not exist or is unavailable at this
> > time.
> > 
> > However, I checked the CUPS on-line documentation, and did not find
> > any documentation on how to set up a URI, so it's possible I did
> > that incorrectly.
> > 
> > I also enabled "port 9100" printing on the printer, and went
> > directly to it:  
> 
> That had to be explicitly done?

Yes. I may have shut it off back when I first took delivery of the
printer. In any case, there is a page on the printer's web server where
one enables or disables all sorts of things.

>  
> > socket://hpm234ethernet.localdomain:9100  
> 
> hpm234ethernet.local?

Again, the "localdomain" is correct.

As mentioned in another email, I opened that port in the firewall
(doh!), and that now works.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: CUPS on Bullseye and Bookworm

[Charles Curley]

On Sun, 14 May 2023 14:04:51 -0600
Charles Curley  wrote:

> I also enabled "port 9100" printing on the printer, and went directly
> to it:
> 
> socket://hpm234ethernet.localdomain:9100
> 
> The printer spun its wheels, reported an error and stopped without
> printing. Nothing in the event log.

I solved that one. I had closed TCP port 9100. Opening that up on the
server got me running. However, that did not solve the problem for the
other two protocols.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: CUPS on Bullseye and Bookworm

[Brian]

On Sun 14 May 2023 at 14:04:51 -0600, Charles Curley wrote:

> On Sun, 14 May 2023 19:48:07 +0200
> john doe  wrote:
> 
> > On 5/14/23 19:29, Charles Curley wrote:
> >  [...]  
> > 
> > The below, is what I would try:
> > 
> > - On the non-working client, Are you restricting outbound traffic at
> > all
> 
> Not that I know of.

Blocking port 5353 (mdns) is not unknown.
 
> > or for testing  purposes can you disable the FW?
> 
> I shut the firewall down ("systemctl stop firewalld"), ran test pages.
> Same non-results, except that system-control-printer now reports:
> 
> Idle - Print job canceled at printer.
> 
> 
> I tried increasing the logging, which involved stopping and restarting
> the cups service. In the process of doing that, the client and server
> both managed to forget the printer. I re-installed it. On the server, I
> have one instance of the printer, protocol:
> 
> hp:/usb/HP_LaserJet_MFP_M232-M237?serial=VNB4J02590

Consider: the printer can be discovered via mDNS/DNS-SD by all machines
on the network. ideapc does this and hasn't any difficulty printing. So
why set up a server when hawk will see the printer as ideapc does? 

Additionally, assuming the printer provides the IPP-over-USB protocol,
the USB queue will not work. See

  https://wiki.debian.org/CUPSDriverlessPrinting

> On the non-working client, cups discovered two versions of the printer:
> 
> dnssd://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipp._tcp.local/?uuid=d532fa73-f559-43ca-9f8e-1eef16972345
> 
> ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/
> 
> I have been testing both and getting the same results.

The two URIs are equivalent.

> > - How are the working clients connected to the printer (protocol
> > wise)?
> 
> implicitclass://HP_LaserJet_MFP_M234sdw_C0FB67_/

cups-browsed has automatically set up a queue. Unless it is having an off-day,
it should do the same on hawk and dragon.
 
> > - Is the non-working client using that same protocol?
> 
> Clearly not.
> 
> So I had the working client discover the printer again. It offered the
> same two as I have on the non-working client. Both printed test pages.
> 
> ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/
> 
> dnssd://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipp._tcp.local/?uuid=d532fa73-f559-43ca-9f8e-1eef16972345
> 
> 
> > - If you do not use MDNS and point manually to the server, does it
> > work any better?
>  
> I tried setting up a printer manually on the non-working client.
> 
> ipp://hawk.localdomain/printers/HP_LaserJet_MFP_M232-M237

hawk.local would be the correct hostname.

> No test page, and I got:
> 
> Processing - The printer may not exist or is unavailable at this time.
> 
> However, I checked the CUPS on-line documentation, and did not find any
> documentation on how to set up a URI, so it's possible I did that
> incorrectly.
> 
> I also enabled "port 9100" printing on the printer, and went directly to
> it:

That had to be explicitly done?
 
> socket://hpm234ethernet.localdomain:9100

hpm234ethernet.local?

-- 
Brian.

Re: CUPS on Bullseye and Bookworm

[Brian]

On Sun 14 May 2023 at 20:57:23 -0600, Charles Curley wrote:

> On Sun, 14 May 2023 23:30:25 +0100
> Brian  wrote:
> 
> > On Sun 14 May 2023 at 14:04:51 -0600, Charles Curley wrote:
> 
> 
> > 
> > We take it that dragon, hawk and the printer are network connected.
> > 
> > Give what you get from dragon with
> > 
> >   avahi-browse -rt _ipp._tcp
> >   avahi-browse -rt _uscan._tcp
> >   driverless
> >   lpstat -l -e
> > 
> > avahi-browse is in the avahi-utils package.
> > 
> 
> root@dragon:~# avahi-browse -rt _ipp._tcp
> + wlp2s2 IPv4 HP LaserJet MFP M234sdw (C0FB67)  Internet Printer  
>local
> = wlp2s2 IPv4 HP LaserJet MFP M234sdw (C0FB67)  Internet Printer  
>local
>hostname = [hpm234ethernet.local]
>address = [192.168.100.134]
>port = [631]
>txt = ["mopria-certified=2.1" "mac=6c:02:e0:c0:fb:67" "usb_MDL=HP LaserJet 
> MFP M232-M237" "usb_MFG=HP" "TLS=1.2" "PaperMax=legal-A4" 
> "kind=document,envelope,photo" "UUID=d532fa73-f559-43ca-9f8e-1eef16972345" 
> "Fax=F" "Scan=T" "Duplex=T" "Color=F" "note=" 
> "adminurl=http://hpm234ethernet.local./hp/device/info_config_AirPrint.html?tab=Networking=AirPrintStatus;
>  "priority=10" "product=(HP LaserJet MFP M232-M237)" "ty=HP LaserJet MFP 
> M232-M237" "URF=V1.4,CP99,W8,OB10,PQ3-4,DM1,IS1-4,MT1-3-5,RS300-600" 
> "rp=ipp/print" 
> "pdl=application/PCLm,application/octet-stream,image/pwg-raster" "qtotal=1" 
> "txtvers=1"]

Useful data but an aside first:

The pdl= key lacks image/urf. HP claims AirPrint support for the device 
(URF=V1.4,...).
It looks like you have been sold a pup. A firmware update?

> root@dragon:~# driverless
> ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/

This is the URI for the printer. You will need to substitute it later into an 
lpadmin
command.

> root@dragon:~# lpstat -l -e
> HP-HP-LaserJet-MFP-M232-M237 permanent 
> ipp://localhost/printers/HP-HP-LaserJet-MFP-M232-M237 
> dnssd://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipp._tcp.local/?uuid=d532fa73-f559-43ca-9f8e-1eef16972345
> HP-HP-LaserJet-MFP-M232-M237-2 permanent 
> ipp://localhost/printers/HP-HP-LaserJet-MFP-M232-M237-2 
> ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/
> HP-LaserJet-MFP-M232-M237 permanent 
> ipp://localhost/printers/HP-LaserJet-MFP-M232-M237 
> socket://hpm234ethernet.localdomain:9100
> HP_LaserJet_MFP_M234sdw_C0FB67 network none 
> ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/
> root@dragon:~# 

The first three entries are print queues (permanent) you have set up. The 
fourth is the
printer.

Execute

  lpadmin -p M234 -v "URI" -E -m everywhere

Test with

  lp -d M234 /etc/nsswitch.conf

-- 
Brian.

Re: CUPS on Bullseye and Bookworm

[Charles Curley]

On Sun, 14 May 2023 23:30:25 +0100
Brian  wrote:

> On Sun 14 May 2023 at 14:04:51 -0600, Charles Curley wrote:


> 
> We take it that dragon, hawk and the printer are network connected.
> 
> Give what you get from dragon with
> 
>   avahi-browse -rt _ipp._tcp
>   avahi-browse -rt _uscan._tcp
>   driverless
>   lpstat -l -e
> 
> avahi-browse is in the avahi-utils package.
> 

root@dragon:~# avahi-browse -rt _ipp._tcp
+ wlp2s2 IPv4 HP LaserJet MFP M234sdw (C0FB67)  Internet Printer
 local
= wlp2s2 IPv4 HP LaserJet MFP M234sdw (C0FB67)  Internet Printer
 local
   hostname = [hpm234ethernet.local]
   address = [192.168.100.134]
   port = [631]
   txt = ["mopria-certified=2.1" "mac=6c:02:e0:c0:fb:67" "usb_MDL=HP LaserJet 
MFP M232-M237" "usb_MFG=HP" "TLS=1.2" "PaperMax=legal-A4" 
"kind=document,envelope,photo" "UUID=d532fa73-f559-43ca-9f8e-1eef16972345" 
"Fax=F" "Scan=T" "Duplex=T" "Color=F" "note=" 
"adminurl=http://hpm234ethernet.local./hp/device/info_config_AirPrint.html?tab=Networking=AirPrintStatus;
 "priority=10" "product=(HP LaserJet MFP M232-M237)" "ty=HP LaserJet MFP 
M232-M237" "URF=V1.4,CP99,W8,OB10,PQ3-4,DM1,IS1-4,MT1-3-5,RS300-600" 
"rp=ipp/print" "pdl=application/PCLm,application/octet-stream,image/pwg-raster" 
"qtotal=1" "txtvers=1"]
root@dragon:~# avahi-browse -rt _uscan._tcp
+ wlp2s2 IPv4 HP LaserJet MFP M234sdw (C0FB67)  _uscan._tcp 
 local
= wlp2s2 IPv4 HP LaserJet MFP M234sdw (C0FB67)  _uscan._tcp 
 local
   hostname = [hpm234ethernet.local]
   address = [192.168.100.134]
   port = [8080]
   txt = ["mopria-certified-scan=1.3" "note=" "duplex=F" "is=platen,adf" 
"cs=color,grayscale" "pdl=application/pdf,image/jpeg" 
"uuid=d532fa73-f559-43ca-9f8e-1eef16972345" "rs=eSCL" 
"representation=http://hpm234ethernet.local./ipp/images/printer.png; 
"vers=2.63" "usb_MDL=HP LaserJet MFP M232-M237" "usb_MFG=HP" "mdl=LaserJet MFP 
M232-M237" "mfg=HP" "ty=HP LaserJet MFP M232-M237" 
"adminurl=http://hpm234ethernet.local.; "txtvers=1"]
root@dragon:~# driverless
ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/
root@dragon:~# lpstat -l -e
HP-HP-LaserJet-MFP-M232-M237 permanent 
ipp://localhost/printers/HP-HP-LaserJet-MFP-M232-M237 
dnssd://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipp._tcp.local/?uuid=d532fa73-f559-43ca-9f8e-1eef16972345
HP-HP-LaserJet-MFP-M232-M237-2 permanent 
ipp://localhost/printers/HP-HP-LaserJet-MFP-M232-M237-2 
ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/
HP-LaserJet-MFP-M232-M237 permanent 
ipp://localhost/printers/HP-LaserJet-MFP-M232-M237 
socket://hpm234ethernet.localdomain:9100
HP_LaserJet_MFP_M234sdw_C0FB67 network none 
ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/
root@dragon:~# 




-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: CUPS on Bullseye and Bookworm

[Brian]

On Sun 14 May 2023 at 14:04:51 -0600, Charles Curley wrote:

> On Sun, 14 May 2023 19:48:07 +0200
> john doe  wrote:
> 
> > On 5/14/23 19:29, Charles Curley wrote:
> >  [...]  
> > 
> > The below, is what I would try:
> > 
> > - On the non-working client, Are you restricting outbound traffic at
> > all
> 
> Not that I know of.
> 
> > or for testing  purposes can you disable the FW?
> 
> I shut the firewall down ("systemctl stop firewalld"), ran test pages.
> Same non-results, except that system-control-printer now reports:
> 
> Idle - Print job canceled at printer.
> 
> 
> I tried increasing the logging, which involved stopping and restarting
> the cups service. In the process of doing that, the client and server
> both managed to forget the printer. I re-installed it. On the server, I
> have one instance of the printer, protocol:
> 
> hp:/usb/HP_LaserJet_MFP_M232-M237?serial=VNB4J02590
> 
> On the non-working client, cups discovered two versions of the printer:
> 
> dnssd://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipp._tcp.local/?uuid=d532fa73-f559-43ca-9f8e-1eef16972345
> 
> ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/
> 
> I have been testing both and getting the same results.
> 
> > 
> > - How are the working clients connected to the printer (protocol
> > wise)?
> 
> implicitclass://HP_LaserJet_MFP_M234sdw_C0FB67_/
> 
> 
> > - Is the non-working client using that same protocol?
> 
> Clearly not.
> 
> So I had the working client discover the printer again. It offered the
> same two as I have on the non-working client. Both printed test pages.
> 
> ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/
> 
> dnssd://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipp._tcp.local/?uuid=d532fa73-f559-43ca-9f8e-1eef16972345
> 
> 
> > - If you do not use MDNS and point manually to the server, does it
> > work any better?
> 
> 
> 
> I tried setting up a printer manually on the non-working client.
> 
> ipp://hawk.localdomain/printers/HP_LaserJet_MFP_M232-M237
> 
> No test page, and I got:
> 
> Processing - The printer may not exist or is unavailable at this time.
> 
> However, I checked the CUPS on-line documentation, and did not find any
> documentation on how to set up a URI, so it's possible I did that
> incorrectly.
> 
> I also enabled "port 9100" printing on the printer, and went directly to
> it:
> 
> socket://hpm234ethernet.localdomain:9100
> 
> The printer spun its wheels, reported an error and stopped without
> printing. Nothing in the event log.

We take it that dragon, hawk and the printer are network connected.

Give what you get from dragon with

  avahi-browse -rt _ipp._tcp
  avahi-browse -rt _uscan._tcp
  driverless
  lpstat -l -e

avahi-browse is in the avahi-utils package.

-- 
Brian.

Re: CUPS on Bullseye and Bookworm

[Charles Curley]

On Sun, 14 May 2023 19:48:07 +0200
john doe  wrote:

> On 5/14/23 19:29, Charles Curley wrote:
>  [...]  
> 
> The below, is what I would try:
> 
> - On the non-working client, Are you restricting outbound traffic at
> all

Not that I know of.

> or for testing  purposes can you disable the FW?

I shut the firewall down ("systemctl stop firewalld"), ran test pages.
Same non-results, except that system-control-printer now reports:

Idle - Print job canceled at printer.


I tried increasing the logging, which involved stopping and restarting
the cups service. In the process of doing that, the client and server
both managed to forget the printer. I re-installed it. On the server, I
have one instance of the printer, protocol:

hp:/usb/HP_LaserJet_MFP_M232-M237?serial=VNB4J02590

On the non-working client, cups discovered two versions of the printer:

dnssd://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipp._tcp.local/?uuid=d532fa73-f559-43ca-9f8e-1eef16972345

ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/

I have been testing both and getting the same results.

> 
> - How are the working clients connected to the printer (protocol
> wise)?

implicitclass://HP_LaserJet_MFP_M234sdw_C0FB67_/


> - Is the non-working client using that same protocol?

Clearly not.

So I had the working client discover the printer again. It offered the
same two as I have on the non-working client. Both printed test pages.

ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/

dnssd://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipp._tcp.local/?uuid=d532fa73-f559-43ca-9f8e-1eef16972345


> - If you do not use MDNS and point manually to the server, does it
> work any better?



I tried setting up a printer manually on the non-working client.

ipp://hawk.localdomain/printers/HP_LaserJet_MFP_M232-M237

No test page, and I got:

Processing - The printer may not exist or is unavailable at this time.

However, I checked the CUPS on-line documentation, and did not find any
documentation on how to set up a URI, so it's possible I did that
incorrectly.

I also enabled "port 9100" printing on the printer, and went directly to
it:

socket://hpm234ethernet.localdomain:9100

The printer spun its wheels, reported an error and stopped without
printing. Nothing in the event log.


> 
> --
> John Doe
> 



-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: CUPS on Bullseye and Bookworm

[john doe]

On 5/14/23 19:29, Charles Curley wrote:

I have an HP HP_LaserJet_MFP_M234sdw_C0FB67_USB_, one of those modern
"no driver" multifunction printers. It works fine on Bullseye. I have
the printer hooked up via USB to a server, hawk, and it prints just
fine.

I have a client, ideapc, which sees the printer and prints to it just
fine.

I also have an ancient i386 IBM R51 running Bookworm, dragon. On dragon,
using system-config-printer, I can see the printer automagically
discovered. I can open up the queue window for the printer, and request
a test page.

Alas, I see the test page in the queue briefly. The queue window says
"processing - not connected?", then "Printer error". Then the print job
disappears, leaving no error message. (This is a change in behavior from
Bullseye. I do not like it.)

The printer does come awake and report an error when I ask for the test
page. I don't see anything in the printer's logs.

Logging on both machines shows no errors. I am running firewalld on
dragon, and did enable logging for unicast. firewalld-cmd reports the
following, among other things:

services: ipp ipp-client mdns samba-client smtp ssh



The below, is what I would try:

- On the non-working client, Are you restricting outbound traffic at all
or for testing  purposes can you disable the FW?

- How are the working clients connected to the printer (protocol wise)?
- Is the non-working client using that same protocol?
- If you do not use MDNS and point manually to the server, does it work
any better?

--
John Doe

CUPS on Bullseye and Bookworm

[Charles Curley]

I have an HP HP_LaserJet_MFP_M234sdw_C0FB67_USB_, one of those modern
"no driver" multifunction printers. It works fine on Bullseye. I have
the printer hooked up via USB to a server, hawk, and it prints just
fine.

I have a client, ideapc, which sees the printer and prints to it just
fine.

I also have an ancient i386 IBM R51 running Bookworm, dragon. On dragon,
using system-config-printer, I can see the printer automagically
discovered. I can open up the queue window for the printer, and request
a test page.

Alas, I see the test page in the queue briefly. The queue window says
"processing - not connected?", then "Printer error". Then the print job
disappears, leaving no error message. (This is a change in behavior from
Bullseye. I do not like it.)

The printer does come awake and report an error when I ask for the test
page. I don't see anything in the printer's logs.

Logging on both machines shows no errors. I am running firewalld on
dragon, and did enable logging for unicast. firewalld-cmd reports the
following, among other things:

   services: ipp ipp-client mdns samba-client smtp ssh

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Problema amb cups ARREGLAT

[Josep]

Bona tarda, Narcís:

Arreglat seguint el teu consell.

He afegit al fstab:

/usr2/share    /usr/share    none    defaults,bind    0 0

He esborrat l'enllaç i he creat de nou el sots directori /usr/share, he 
creuat els dits i he reiniciat ¡et voilà!, ja puc imprimir com vulgui i 
ja puc entrar al cups a la seva interfície web.


Has tingut, Narcís, molt bona pensada respecte als efectes d'una 
arrancada com la que tenía mitjançant un enllaç pel mig.


Moltes gràcies per l'ajuda.

Ja havia pensat en canviar la mida amb el gparted que tinc al rescatux, 
però em feia molt respecte tocar la partició arrel que, decididament, es 
massa gran, 24 Gb. A la propera em sembla que deixaré de fer particions 
dedicades.


Espero que serveixi d'ajuda pel futur a qualsevol altre que tingui 
"pensades" com les meves.


Repeteixo: moltes gràcies.

Josep Lloret




El 25/4/23 a las 16:40, Narcis Garcia va dir:

Ara m'ho he llegit bé:
L'arrel (/) la tens muntada en una partició, i el directori /usr el 
tens muntat en una altra partició. Aleshores has tornat a moure espai 
amb l'enllaç simbòlic de /usr/share a /usr2/share


La veritat és que no tinc ni idea de si això té implicacions 
negatives, però jo intentaria no fer-ho tant complicat amb 
l'estructura del sistema.
Si tot això és en un mateix disc; No val la pena canviar la mida de 
les particions? Per exemple amb Gparted des d'una arrencada «Live-USB».


Salut;
Narcís


El 25/4/23 a les 14:23, Josep ha escrit:

Bona tarda, Narcís:

Tocar el fstab no em fa por perquè ja ho he fet abans, però sempre 
per particions sense importància.


Entenc que haver fet l'enllaç segur que representa uns segons de 
retard al carregar-se tot i vaig a provar-ho, però voldria estar 
segur de no espifiar-la.


Partint que tinc una partició /usr i que el sots-directori /share el 
tinc físicament a /usr2/share (que físicament es a la partició / ) 
suposo que al fstab hi he d'escriure:


/dev/usr2/share   /dev/usr/share  none  defaults bind 0 0

I primer - i això es el que em fa més por, he de cancel·lar l'enllaç 
perquè si no suposo que es produirà un embolic o un bucle, que sé jo.


¿Es correcte, el que penso?

Moltes gràcies.

Josep Lloret




El 25/4/23 a las 12:19, Narcis Garcia va dir:
Tingues clar que /usr/share estigui disponible amb l'arrencada del 
sistema via /etc/fstab , que no sigui que algun servei tingui coses 
en aquella ruta i encara no les trobi quan està iniciant.


Si el servei està escoltant pel port 631, hauries de tenir aquesta 
pàgina disponible per a revisar-ho tot:

http://localhost:631


https://wiki.gilug.org/index.php/Estructura_de_directoris_del_sistema_GNU 



El 25/4/23 a les 11:13, Josep ha escrit:

Bon dia, Narcís:

Em dona això:

===
sudo systemctl status cups-browsed

cups-browsed.service - Make remote CUPS printers available locally
 Loaded: loaded (/lib/systemd/system/cups-browsed.service; 
enabled; vendor preset: enabled)
 Active: active (running)since Tue 2023-04-25 10:43:16 CEST; 
9min ago

   Main PID: 1713 (cups-browsed)
  Tasks: 3 (limit: 28419)
 Memory: 4.6M
CPU: 148ms
 CGroup: /system.slice/cups-browsed.service
 └─1713 /usr/sbin/cups-browsed

abr 25 10:43:16 STUDI-8 systemd[1]: Started Make remote CUPS 
printers available locally.


===
sudo ss -tulpn | grep -ie cups

udp   UNCONN 0   0    0.0.0.0:631   0.0.0.0:* 
    users:(("cups-browsed",pid=1713,fd=7))
tcp   LISTEN 0   128  0.0.0.0:631   0.0.0.0:* 
users:(("cupsd",pid=1307,fd=7))
tcp   LISTEN 0   5   127.0.0.1:3551 0.0.0.0:* 
users:(("apcupsd",pid=1370,fd=4))
tcp   LISTEN 0   128  [::]:631     [::]:* 
users:(("cupsd",pid=1307,fd=8))


===

Suposo que no hi tindrà res a veure, però per si de cas he de dir 
que fa unes setmanes, per arreglar la manca d'espai de la partició 
dedicada a /usr (14 Gb que van minvant) vaig fer un enllaç del sots 
directori /share a un altre partició (de fet, l'arrel / ) i hi vaig 
traslladar-ho tot i tret d'aquest problema sobtat amb cups no he 
notat cap altre incidència. De totes maneres, el cups fa tres dies 
que no rutlla i el darrer que vaig fer va ser una actualització de 
un parell de programes del sistema, d'aquelles rutinàries, que no 
recordo.


Moltes gràcies.

Josep Lloret



El 25/4/23 a las 8:25, Narcis Garcia va dir:

El servei web està separat. Mira què et donen aquestes dues comandes:

$ sudo systemctl status cups-browsed

$ sudo ss -tulpn | grep -ie cups


El 24/4/23 a les 20:47, Josep ha escrit:

Hola:

Per primera vegada des fa anys em trobo amb que el meu linux 
debian no imprimeix res de res a cap impresora de les dues que 
tinc instal·lades.


Ja fa uns mesos que em feia el boig, però ara cups sembla 
desaparegut, tant es així que si faig localhost:631 la resposta 
del navegador (firefox o chrome, es igual) es que no hi ha resposta.


Tinc una hp laserjet M101-M106 que amb el tripijoc he configura

Re: Problema amb cups

[Narcis Garcia]

Ara m'ho he llegit bé:
L'arrel (/) la tens muntada en una partició, i el directori /usr el tens 
muntat en una altra partició. Aleshores has tornat a moure espai amb 
l'enllaç simbòlic de /usr/share a /usr2/share


La veritat és que no tinc ni idea de si això té implicacions negatives, 
però jo intentaria no fer-ho tant complicat amb l'estructura del sistema.
Si tot això és en un mateix disc; No val la pena canviar la mida de les 
particions? Per exemple amb Gparted des d'una arrencada «Live-USB».


Salut;
Narcís


El 25/4/23 a les 14:23, Josep ha escrit:

Bona tarda, Narcís:

Tocar el fstab no em fa por perquè ja ho he fet abans, però sempre per 
particions sense importància.


Entenc que haver fet l'enllaç segur que representa uns segons de retard 
al carregar-se tot i vaig a provar-ho, però voldria estar segur de no 
espifiar-la.


Partint que tinc una partició /usr i que el sots-directori /share el 
tinc físicament a /usr2/share (que físicament es a la partició / ) 
suposo que al fstab hi he d'escriure:


/dev/usr2/share   /dev/usr/share  none  defaults bind 0 0

I primer - i això es el que em fa més por, he de cancel·lar l'enllaç 
perquè si no suposo que es produirà un embolic o un bucle, que sé jo.


¿Es correcte, el que penso?

Moltes gràcies.

Josep Lloret




El 25/4/23 a las 12:19, Narcis Garcia va dir:
Tingues clar que /usr/share estigui disponible amb l'arrencada del 
sistema via /etc/fstab , que no sigui que algun servei tingui coses en 
aquella ruta i encara no les trobi quan està iniciant.


Si el servei està escoltant pel port 631, hauries de tenir aquesta 
pàgina disponible per a revisar-ho tot:

http://localhost:631


https://wiki.gilug.org/index.php/Estructura_de_directoris_del_sistema_GNU

El 25/4/23 a les 11:13, Josep ha escrit:

Bon dia, Narcís:

Em dona això:

===
sudo systemctl status cups-browsed

cups-browsed.service - Make remote CUPS printers available locally
 Loaded: loaded (/lib/systemd/system/cups-browsed.service; 
enabled; vendor preset: enabled)
 Active: active (running)since Tue 2023-04-25 10:43:16 CEST; 9min 
ago

   Main PID: 1713 (cups-browsed)
  Tasks: 3 (limit: 28419)
 Memory: 4.6M
CPU: 148ms
 CGroup: /system.slice/cups-browsed.service
 └─1713 /usr/sbin/cups-browsed

abr 25 10:43:16 STUDI-8 systemd[1]: Started Make remote CUPS printers 
available locally.


===
sudo ss -tulpn | grep -ie cups

udp   UNCONN 0   0    0.0.0.0:631   0.0.0.0:* 
users:(("cups-browsed",pid=1713,fd=7))
tcp   LISTEN 0   128  0.0.0.0:631   0.0.0.0:* 
users:(("cupsd",pid=1307,fd=7))
tcp   LISTEN 0   5   127.0.0.1:3551 0.0.0.0:* 
users:(("apcupsd",pid=1370,fd=4))
tcp   LISTEN 0   128  [::]:631     [::]:* 
users:(("cupsd",pid=1307,fd=8))


===

Suposo que no hi tindrà res a veure, però per si de cas he de dir que 
fa unes setmanes, per arreglar la manca d'espai de la partició 
dedicada a /usr (14 Gb que van minvant) vaig fer un enllaç del sots 
directori /share a un altre partició (de fet, l'arrel / ) i hi vaig 
traslladar-ho tot i tret d'aquest problema sobtat amb cups no he 
notat cap altre incidència. De totes maneres, el cups fa tres dies 
que no rutlla i el darrer que vaig fer va ser una actualització de un 
parell de programes del sistema, d'aquelles rutinàries, que no recordo.


Moltes gràcies.

Josep Lloret



El 25/4/23 a las 8:25, Narcis Garcia va dir:

El servei web està separat. Mira què et donen aquestes dues comandes:

$ sudo systemctl status cups-browsed

$ sudo ss -tulpn | grep -ie cups


El 24/4/23 a les 20:47, Josep ha escrit:

Hola:

Per primera vegada des fa anys em trobo amb que el meu linux debian 
no imprimeix res de res a cap impresora de les dues que tinc 
instal·lades.


Ja fa uns mesos que em feia el boig, però ara cups sembla 
desaparegut, tant es així que si faig localhost:631 la resposta del 
navegador (firefox o chrome, es igual) es que no hi ha resposta.


Tinc una hp laserjet M101-M106 que amb el tripijoc he configurat 
per tal que rutlli amb wifi i des la pàgina web he pogut imprimir 
la seva configuració a la wifi, així que l'ordinador la veu 
perfectament, però no imprimeix cap altre text.


També tinc una epson xp-850 conectada per usb que de repent tampoc 
imprimeix ni en color ni en B/N.


Porto uns dies buscant per tot arreu i res sembla servir i ja he 
instal·lat el hplip i el cups, amb les seves dependències, dos cops.


Si faig service cups status em dona això:

● cups.service - CUPS Scheduler
  Loaded: loaded (/lib/systemd/system/cups.service; enabled; 
vendor preset: enabled)
  Active: active (running) since Mon 2023-04-24 19:44:14 CEST; 
7min ago

TriggeredBy: ● cups.socket
  ● cups.path
    Docs: man:cupsd(8)
    Main PID: 38518 (cupsd)
  Status: "Scheduler is running..."
   Tasks: 6 (limit: 28419)
  Memory: 5.9M
 CPU: 104ms
  CGroup: /system.slice/

Re: Problema amb cups

[Josep]

Bona tarda, Narcís:

Tocar el fstab no em fa por perquè ja ho he fet abans, però sempre per 
particions sense importància.


Entenc que haver fet l'enllaç segur que representa uns segons de retard 
al carregar-se tot i vaig a provar-ho, però voldria estar segur de no 
espifiar-la.


Partint que tinc una partició /usr i que el sots-directori /share el 
tinc físicament a /usr2/share (que físicament es a la partició / ) 
suposo que al fstab hi he d'escriure:


/dev/usr2/share   /dev/usr/share  none  defaults bind 0 0

I primer - i això es el que em fa més por, he de cancel·lar l'enllaç 
perquè si no suposo que es produirà un embolic o un bucle, que sé jo.


¿Es correcte, el que penso?

Moltes gràcies.

Josep Lloret




El 25/4/23 a las 12:19, Narcis Garcia va dir:
Tingues clar que /usr/share estigui disponible amb l'arrencada del 
sistema via /etc/fstab , que no sigui que algun servei tingui coses en 
aquella ruta i encara no les trobi quan està iniciant.


Si el servei està escoltant pel port 631, hauries de tenir aquesta 
pàgina disponible per a revisar-ho tot:

http://localhost:631


https://wiki.gilug.org/index.php/Estructura_de_directoris_del_sistema_GNU

El 25/4/23 a les 11:13, Josep ha escrit:

Bon dia, Narcís:

Em dona això:

===
sudo systemctl status cups-browsed

cups-browsed.service - Make remote CUPS printers available locally
 Loaded: loaded (/lib/systemd/system/cups-browsed.service; 
enabled; vendor preset: enabled)
 Active: active (running)since Tue 2023-04-25 10:43:16 CEST; 9min 
ago

   Main PID: 1713 (cups-browsed)
  Tasks: 3 (limit: 28419)
 Memory: 4.6M
CPU: 148ms
 CGroup: /system.slice/cups-browsed.service
 └─1713 /usr/sbin/cups-browsed

abr 25 10:43:16 STUDI-8 systemd[1]: Started Make remote CUPS printers 
available locally.


===
sudo ss -tulpn | grep -ie cups

udp   UNCONN 0   0    0.0.0.0:631   0.0.0.0:* 
users:(("cups-browsed",pid=1713,fd=7))
tcp   LISTEN 0   128  0.0.0.0:631   0.0.0.0:* 
users:(("cupsd",pid=1307,fd=7))
tcp   LISTEN 0   5   127.0.0.1:3551 0.0.0.0:* 
users:(("apcupsd",pid=1370,fd=4))
tcp   LISTEN 0   128  [::]:631     [::]:* 
users:(("cupsd",pid=1307,fd=8))


===

Suposo que no hi tindrà res a veure, però per si de cas he de dir que 
fa unes setmanes, per arreglar la manca d'espai de la partició 
dedicada a /usr (14 Gb que van minvant) vaig fer un enllaç del sots 
directori /share a un altre partició (de fet, l'arrel / ) i hi vaig 
traslladar-ho tot i tret d'aquest problema sobtat amb cups no he 
notat cap altre incidència. De totes maneres, el cups fa tres dies 
que no rutlla i el darrer que vaig fer va ser una actualització de un 
parell de programes del sistema, d'aquelles rutinàries, que no recordo.


Moltes gràcies.

Josep Lloret



El 25/4/23 a las 8:25, Narcis Garcia va dir:

El servei web està separat. Mira què et donen aquestes dues comandes:

$ sudo systemctl status cups-browsed

$ sudo ss -tulpn | grep -ie cups


El 24/4/23 a les 20:47, Josep ha escrit:

Hola:

Per primera vegada des fa anys em trobo amb que el meu linux debian 
no imprimeix res de res a cap impresora de les dues que tinc 
instal·lades.


Ja fa uns mesos que em feia el boig, però ara cups sembla 
desaparegut, tant es així que si faig localhost:631 la resposta del 
navegador (firefox o chrome, es igual) es que no hi ha resposta.


Tinc una hp laserjet M101-M106 que amb el tripijoc he configurat 
per tal que rutlli amb wifi i des la pàgina web he pogut imprimir 
la seva configuració a la wifi, així que l'ordinador la veu 
perfectament, però no imprimeix cap altre text.


També tinc una epson xp-850 conectada per usb que de repent tampoc 
imprimeix ni en color ni en B/N.


Porto uns dies buscant per tot arreu i res sembla servir i ja he 
instal·lat el hplip i el cups, amb les seves dependències, dos cops.


Si faig service cups status em dona això:

● cups.service - CUPS Scheduler
  Loaded: loaded (/lib/systemd/system/cups.service; enabled; 
vendor preset: enabled)
  Active: active (running) since Mon 2023-04-24 19:44:14 CEST; 
7min ago

TriggeredBy: ● cups.socket
  ● cups.path
    Docs: man:cupsd(8)
    Main PID: 38518 (cupsd)
  Status: "Scheduler is running..."
   Tasks: 6 (limit: 28419)
  Memory: 5.9M
 CPU: 104ms
  CGroup: /system.slice/cups.service
  ├─38518 /usr/sbin/cupsd -l
  ├─38521 /usr/lib/cups/notifier/dbus dbus://
  ├─38522 /usr/lib/cups/notifier/dbus dbus://
  ├─38523 /usr/lib/cups/notifier/dbus dbus://
  └─38529 /usr/lib/cups/notifier/dbus dbus://

abr 24 19:44:14 STUDI-8 systemd[1]: Starting CUPS Scheduler...
abr 24 19:44:14 STUDI-8 systemd[1]: Started CUPS Scheduler.

I em sembla que tot es correcte, però espero que algú s'hi hagi 
trobat o sàpiga aconsellar-me i pugui imprimir com sempre.


Moltes gràcies.

Re: Problema amb cups

[Narcis Garcia]

Tingues clar que /usr/share estigui disponible amb l'arrencada del 
sistema via /etc/fstab , que no sigui que algun servei tingui coses en 
aquella ruta i encara no les trobi quan està iniciant.


Si el servei està escoltant pel port 631, hauries de tenir aquesta 
pàgina disponible per a revisar-ho tot:

http://localhost:631


https://wiki.gilug.org/index.php/Estructura_de_directoris_del_sistema_GNU

El 25/4/23 a les 11:13, Josep ha escrit:

Bon dia, Narcís:

Em dona això:

===
sudo systemctl status cups-browsed

cups-browsed.service - Make remote CUPS printers available locally
 Loaded: loaded (/lib/systemd/system/cups-browsed.service; enabled; 
vendor preset: enabled)

 Active: active (running)since Tue 2023-04-25 10:43:16 CEST; 9min ago
   Main PID: 1713 (cups-browsed)
  Tasks: 3 (limit: 28419)
 Memory: 4.6M
    CPU: 148ms
 CGroup: /system.slice/cups-browsed.service
 └─1713 /usr/sbin/cups-browsed

abr 25 10:43:16 STUDI-8 systemd[1]: Started Make remote CUPS printers 
available locally.


===
sudo ss -tulpn | grep -ie cups

udp   UNCONN 0   0    0.0.0.0:631   0.0.0.0:* 
    users:(("cups-browsed",pid=1713,fd=7))
tcp   LISTEN 0   128  0.0.0.0:631   0.0.0.0:* 
    users:(("cupsd",pid=1307,fd=7))
tcp   LISTEN 0   5   127.0.0.1:3551 0.0.0.0:* 
    users:(("apcupsd",pid=1370,fd=4))
tcp   LISTEN 0   128  [::]:631     [::]:* 
    users:(("cupsd",pid=1307,fd=8))


===

Suposo que no hi tindrà res a veure, però per si de cas he de dir que fa 
unes setmanes, per arreglar la manca d'espai de la partició dedicada a 
/usr (14 Gb que van minvant) vaig fer un enllaç del sots directori 
/share a un altre partició (de fet, l'arrel / ) i hi vaig traslladar-ho 
tot i tret d'aquest problema sobtat amb cups no he notat cap altre 
incidència. De totes maneres, el cups fa tres dies que no rutlla i el 
darrer que vaig fer va ser una actualització de un parell de programes 
del sistema, d'aquelles rutinàries, que no recordo.


Moltes gràcies.

Josep Lloret



El 25/4/23 a las 8:25, Narcis Garcia va dir:

El servei web està separat. Mira què et donen aquestes dues comandes:

$ sudo systemctl status cups-browsed

$ sudo ss -tulpn | grep -ie cups


El 24/4/23 a les 20:47, Josep ha escrit:

Hola:

Per primera vegada des fa anys em trobo amb que el meu linux debian 
no imprimeix res de res a cap impresora de les dues que tinc 
instal·lades.


Ja fa uns mesos que em feia el boig, però ara cups sembla 
desaparegut, tant es així que si faig localhost:631 la resposta del 
navegador (firefox o chrome, es igual) es que no hi ha resposta.


Tinc una hp laserjet M101-M106 que amb el tripijoc he configurat per 
tal que rutlli amb wifi i des la pàgina web he pogut imprimir la seva 
configuració a la wifi, així que l'ordinador la veu perfectament, 
però no imprimeix cap altre text.


També tinc una epson xp-850 conectada per usb que de repent tampoc 
imprimeix ni en color ni en B/N.


Porto uns dies buscant per tot arreu i res sembla servir i ja he 
instal·lat el hplip i el cups, amb les seves dependències, dos cops.


Si faig service cups status em dona això:

● cups.service - CUPS Scheduler
  Loaded: loaded (/lib/systemd/system/cups.service; enabled; 
vendor preset: enabled)
  Active: active (running) since Mon 2023-04-24 19:44:14 CEST; 
7min ago

TriggeredBy: ● cups.socket
  ● cups.path
    Docs: man:cupsd(8)
    Main PID: 38518 (cupsd)
  Status: "Scheduler is running..."
   Tasks: 6 (limit: 28419)
  Memory: 5.9M
 CPU: 104ms
  CGroup: /system.slice/cups.service
  ├─38518 /usr/sbin/cupsd -l
  ├─38521 /usr/lib/cups/notifier/dbus dbus://
  ├─38522 /usr/lib/cups/notifier/dbus dbus://
  ├─38523 /usr/lib/cups/notifier/dbus dbus://
  └─38529 /usr/lib/cups/notifier/dbus dbus://

abr 24 19:44:14 STUDI-8 systemd[1]: Starting CUPS Scheduler...
abr 24 19:44:14 STUDI-8 systemd[1]: Started CUPS Scheduler.

I em sembla que tot es correcte, però espero que algú s'hi hagi 
trobat o sàpiga aconsellar-me i pugui imprimir com sempre.


Moltes gràcies.








--

Narcis Garcia

__
I'm using this dedicated address because personal addresses aren't 
masked enough at this mail public archive. Public archive administrator 
should fix this against automated addresses collectors.

Re: Problema amb cups

[Josep]

Bon dia, Narcís:

Em dona això:

===
sudo systemctl status cups-browsed

cups-browsed.service - Make remote CUPS printers available locally
Loaded: loaded (/lib/systemd/system/cups-browsed.service; enabled; 
vendor preset: enabled)

Active: active (running)since Tue 2023-04-25 10:43:16 CEST; 9min ago
  Main PID: 1713 (cups-browsed)
 Tasks: 3 (limit: 28419)
Memory: 4.6M
   CPU: 148ms
CGroup: /system.slice/cups-browsed.service
└─1713 /usr/sbin/cups-browsed

abr 25 10:43:16 STUDI-8 systemd[1]: Started Make remote CUPS printers 
available locally.


===
sudo ss -tulpn | grep -ie cups

udp   UNCONN 0   0    0.0.0.0:631   0.0.0.0:* 
   users:(("cups-browsed",pid=1713,fd=7))
tcp   LISTEN 0   128  0.0.0.0:631   0.0.0.0:* 
   users:(("cupsd",pid=1307,fd=7))
tcp   LISTEN 0   5   127.0.0.1:3551 0.0.0.0:* 
   users:(("apcupsd",pid=1370,fd=4))
tcp   LISTEN 0   128  [::]:631     [::]:* 
   users:(("cupsd",pid=1307,fd=8))


===

Suposo que no hi tindrà res a veure, però per si de cas he de dir que fa 
unes setmanes, per arreglar la manca d'espai de la partició dedicada a 
/usr (14 Gb que van minvant) vaig fer un enllaç del sots directori 
/share a un altre partició (de fet, l'arrel / ) i hi vaig traslladar-ho 
tot i tret d'aquest problema sobtat amb cups no he notat cap altre 
incidència. De totes maneres, el cups fa tres dies que no rutlla i el 
darrer que vaig fer va ser una actualització de un parell de programes 
del sistema, d'aquelles rutinàries, que no recordo.


Moltes gràcies.

Josep Lloret



El 25/4/23 a las 8:25, Narcis Garcia va dir:

El servei web està separat. Mira què et donen aquestes dues comandes:

$ sudo systemctl status cups-browsed

$ sudo ss -tulpn | grep -ie cups


El 24/4/23 a les 20:47, Josep ha escrit:

Hola:

Per primera vegada des fa anys em trobo amb que el meu linux debian 
no imprimeix res de res a cap impresora de les dues que tinc 
instal·lades.


Ja fa uns mesos que em feia el boig, però ara cups sembla 
desaparegut, tant es així que si faig localhost:631 la resposta del 
navegador (firefox o chrome, es igual) es que no hi ha resposta.


Tinc una hp laserjet M101-M106 que amb el tripijoc he configurat per 
tal que rutlli amb wifi i des la pàgina web he pogut imprimir la seva 
configuració a la wifi, així que l'ordinador la veu perfectament, 
però no imprimeix cap altre text.


També tinc una epson xp-850 conectada per usb que de repent tampoc 
imprimeix ni en color ni en B/N.


Porto uns dies buscant per tot arreu i res sembla servir i ja he 
instal·lat el hplip i el cups, amb les seves dependències, dos cops.


Si faig service cups status em dona això:

● cups.service - CUPS Scheduler
  Loaded: loaded (/lib/systemd/system/cups.service; enabled; 
vendor preset: enabled)
  Active: active (running) since Mon 2023-04-24 19:44:14 CEST; 
7min ago

TriggeredBy: ● cups.socket
  ● cups.path
    Docs: man:cupsd(8)
    Main PID: 38518 (cupsd)
  Status: "Scheduler is running..."
   Tasks: 6 (limit: 28419)
  Memory: 5.9M
 CPU: 104ms
  CGroup: /system.slice/cups.service
  ├─38518 /usr/sbin/cupsd -l
  ├─38521 /usr/lib/cups/notifier/dbus dbus://
  ├─38522 /usr/lib/cups/notifier/dbus dbus://
  ├─38523 /usr/lib/cups/notifier/dbus dbus://
  └─38529 /usr/lib/cups/notifier/dbus dbus://

abr 24 19:44:14 STUDI-8 systemd[1]: Starting CUPS Scheduler...
abr 24 19:44:14 STUDI-8 systemd[1]: Started CUPS Scheduler.

I em sembla que tot es correcte, però espero que algú s'hi hagi 
trobat o sàpiga aconsellar-me i pugui imprimir com sempre.


Moltes gràcies.

Re: Problema amb cups

[Narcis Garcia]

El servei web està separat. Mira què et donen aquestes dues comandes:

$ sudo systemctl status cups-browsed

$ sudo ss -tulpn | grep -ie cups


El 24/4/23 a les 20:47, Josep ha escrit:

Hola:

Per primera vegada des fa anys em trobo amb que el meu linux debian no 
imprimeix res de res a cap impresora de les dues que tinc instal·lades.


Ja fa uns mesos que em feia el boig, però ara cups sembla desaparegut, 
tant es així que si faig localhost:631 la resposta del navegador 
(firefox o chrome, es igual) es que no hi ha resposta.


Tinc una hp laserjet M101-M106 que amb el tripijoc he configurat per tal 
que rutlli amb wifi i des la pàgina web he pogut imprimir la seva 
configuració a la wifi, així que l'ordinador la veu perfectament, però 
no imprimeix cap altre text.


També tinc una epson xp-850 conectada per usb que de repent tampoc 
imprimeix ni en color ni en B/N.


Porto uns dies buscant per tot arreu i res sembla servir i ja he 
instal·lat el hplip i el cups, amb les seves dependències, dos cops.


Si faig service cups status em dona això:

● cups.service - CUPS Scheduler
  Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor 
preset: enabled)

  Active: active (running) since Mon 2023-04-24 19:44:14 CEST; 7min ago
TriggeredBy: ● cups.socket
  ● cups.path
    Docs: man:cupsd(8)
    Main PID: 38518 (cupsd)
  Status: "Scheduler is running..."
   Tasks: 6 (limit: 28419)
  Memory: 5.9M
     CPU: 104ms
  CGroup: /system.slice/cups.service
  ├─38518 /usr/sbin/cupsd -l
  ├─38521 /usr/lib/cups/notifier/dbus dbus://
  ├─38522 /usr/lib/cups/notifier/dbus dbus://
  ├─38523 /usr/lib/cups/notifier/dbus dbus://
  └─38529 /usr/lib/cups/notifier/dbus dbus://

abr 24 19:44:14 STUDI-8 systemd[1]: Starting CUPS Scheduler...
abr 24 19:44:14 STUDI-8 systemd[1]: Started CUPS Scheduler.

I em sembla que tot es correcte, però espero que algú s'hi hagi trobat o 
sàpiga aconsellar-me i pugui imprimir com sempre.


Moltes gràcies.




--

Narcis Garcia

__
I'm using this dedicated address because personal addresses aren't 
masked enough at this mail public archive. Public archive administrator 
should fix this against automated addresses collectors.

Problema amb cups

[Josep]

Hola:

Per primera vegada des fa anys em trobo amb que el meu linux debian no 
imprimeix res de res a cap impresora de les dues que tinc instal·lades.


Ja fa uns mesos que em feia el boig, però ara cups sembla desaparegut, 
tant es així que si faig localhost:631 la resposta del navegador 
(firefox o chrome, es igual) es que no hi ha resposta.


Tinc una hp laserjet M101-M106 que amb el tripijoc he configurat per tal 
que rutlli amb wifi i des la pàgina web he pogut imprimir la seva 
configuració a la wifi, així que l'ordinador la veu perfectament, però 
no imprimeix cap altre text.


També tinc una epson xp-850 conectada per usb que de repent tampoc 
imprimeix ni en color ni en B/N.


Porto uns dies buscant per tot arreu i res sembla servir i ja he 
instal·lat el hplip i el cups, amb les seves dependències, dos cops.


Si faig service cups status em dona això:

● cups.service - CUPS Scheduler
 Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor 
preset: enabled)

 Active: active (running) since Mon 2023-04-24 19:44:14 CEST; 7min ago
TriggeredBy: ● cups.socket
 ● cups.path
   Docs: man:cupsd(8)
   Main PID: 38518 (cupsd)
 Status: "Scheduler is running..."
  Tasks: 6 (limit: 28419)
 Memory: 5.9M
    CPU: 104ms
 CGroup: /system.slice/cups.service
 ├─38518 /usr/sbin/cupsd -l
 ├─38521 /usr/lib/cups/notifier/dbus dbus://
 ├─38522 /usr/lib/cups/notifier/dbus dbus://
 ├─38523 /usr/lib/cups/notifier/dbus dbus://
 └─38529 /usr/lib/cups/notifier/dbus dbus://

abr 24 19:44:14 STUDI-8 systemd[1]: Starting CUPS Scheduler...
abr 24 19:44:14 STUDI-8 systemd[1]: Started CUPS Scheduler.

I em sembla que tot es correcte, però espero que algú s'hi hagi trobat o 
sàpiga aconsellar-me i pugui imprimir com sempre.


Moltes gràcies.


--
Josep Lloret
Debian 11 & xfce4

Fwd: Problema amb cups

[Josep]

Hola:

Per primera vegada des fa anys em trobo amb que el meu linux debian no 
imprimeix res de res a cap impresora de les dues que tinc instal·lades.


Ja fa uns mesos que em feia el boig, però ara cups sembla desaparegut, 
tant es així que si faig localhost:631 la resposta del navegador 
(firefox o chrome, es igual) es que no hi ha resposta.


Tinc una hp laserjet M101-M106 que amb el tripijoc he configurat per tal 
que rutlli amb wifi i des la pàgina web he pogut imprimir la seva 
configuració a la wifi, així que l'ordinador la veu perfectament, però 
no imprimeix cap altre text.


També tinc una epson xp-850 conectada per usb que de repent tampoc 
imprimeix ni en color ni en B/N.


Porto uns dies buscant per tot arreu i res sembla servir i ja he 
instal·lat el hplip i el cups, amb les seves dependències, dos cops.


Si faig service cups status em dona això:

● cups.service - CUPS Scheduler
 Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor 
preset: enabled)

 Active: active (running) since Mon 2023-04-24 19:44:14 CEST; 7min ago
TriggeredBy: ● cups.socket
 ● cups.path
   Docs: man:cupsd(8)
   Main PID: 38518 (cupsd)
 Status: "Scheduler is running..."
  Tasks: 6 (limit: 28419)
 Memory: 5.9M
    CPU: 104ms
 CGroup: /system.slice/cups.service
 ├─38518 /usr/sbin/cupsd -l
 ├─38521 /usr/lib/cups/notifier/dbus dbus://
 ├─38522 /usr/lib/cups/notifier/dbus dbus://
 ├─38523 /usr/lib/cups/notifier/dbus dbus://
 └─38529 /usr/lib/cups/notifier/dbus dbus://

abr 24 19:44:14 STUDI-8 systemd[1]: Starting CUPS Scheduler...
abr 24 19:44:14 STUDI-8 systemd[1]: Started CUPS Scheduler.

I em sembla que tot es correcte, però espero que algú s'hi hagi trobat o 
sàpiga aconsellar-me i pugui imprimir com sempre.


Moltes gràcies.


--
Josep
Debian 11 & xfce4

Re: cups not sharing printers with other bullseye machines

[Gareth Evans]

On Sat  8 Apr 2023, at 22:12, gene heskett  wrote:
> On 4/8/23 02:40, Gareth Evans wrote:
>> On Sat  8 Apr 2023, at 03:20, gene heskett  wrote:
>>> Greetings all;
>>>
>>> Where do I turn on cups debugging so I'll see every bit of traffic
>>> addressed to cups from my local 192.168/xx.yy network?
>>>
>>> The problem is: other buster machines on this local network can see and
>>> use the two brother printers just as if the printer was local to that
>>> buster machine.
>>>
>>> But no bullseye, debian or armbian can see anything at
>>> localhost:631/printers except the search screen when there are no printers.
>>>
>>> These printers are marked as shared in this bullseye machines /etc/cups
>>> files.
>>>
>>> There's a new roadblock someplace, I've asked about before. I'd like to
>>> find it.
>>>
>>> Buster machines can, other bullseye machines can't.
>>>
>>> Thank you.
>>>
>>> Cheers, Gene Heskett.
>>> -- 
>>> "There are four boxes to be used in defense of liberty:
>>>soap, ballot, jury, and ammo. Please use in that order."
>>> -Ed Howdershelt (Author, 1940)
>>> If we desire respect for the law, we must first make the law respectable.
>>>- Louis D. Brandeis
>>> Genes Web page <http://geneslinuxbox.net:6309/>
>> 
>> Hi Gene,
>> 
>> Not sure if CUPS debugging may be helpful, see eg.
>> 
>> https://sysadminera.com/2020/09/10/linux-how-to-enable-and-capture-cups-debugging-logs/
>> 
> The most intelligent output I can get from the error_log on one of the 
> armbian bullseye machines is a garbled attempt to open a pipe (I think)
> from that log a snippet is attached. Tail end of a cups restart. Looks 
> like something in the name resolution is totally fubar to me.
>
> But, I can send ff to the exact entry in client.conf, and it can see all 
> the shared printers here on this machine. But cups on that machine can't.
>
>> But first, I seem to recall you removed avahi and cups-browsed from Bullseye 
>> machines.  Is that correct?  Do the Buster machines have either or both of 
>> those installed?
>
> avahi and cups-browsed have both been re-installed on that armbian machine.
> And its networking continues to work thru a reboot, something I could 
> not do at the original install.
> Then I check this machines error_log which is flooded with thousands of 
> lines of this from my attempts to get a printer list on the armbian machine:
>
> E [08/Apr/2023:12:25:16 -0400] [Client 18] Returning IPP 
> server-error-version-not-supported for CUPS-Get-Printers (no URI) from 
> 192.168.71.12.
> E [08/Apr/2023:12:25:16 -0400] [Client 18] Returning IPP 
> server-error-version-not-supported for CUPS-Get-Default (no URI) from 
> 192.168.71.12.
> E [08/Apr/2023:12:25:16 -0400] [Client 18] Returning IPP 
> server-error-version-not-supported for CUPS-Get-Printers (no URI) from 
> 192.168.71.12.
> E [08/Apr/2023:12:25:16 -0400] [Client 18] Returning IPP 
> server-error-version-not-supported for CUPS-Get-Default (no URI) from 
> 192.168.71.12.
> E [08/Apr/2023:12:25:16 -0400] [Client 18] Returning IPP 
> server-error-version-not-supported for CUPS-Get-Printers (no URI) from 
> 192.168.71.12.
>
> So the armbian machine is trying, and its this machine that is rejecting 
> its attempts.  That's progress ;o)>
>
> Whats next?
>
> Thanks Gareth, take care and stay well.
>
> Cheers, Gene Heskett.
> -- 
> "There are four boxes to be used in defense of liberty:
>   soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author, 1940)
> If we desire respect for the law, we must first make the law respectable.
>   - Louis D. Brandeis
> Genes Web page <http://geneslinuxbox.net:6309/>
>
> Attachments:
> * cups-error-log

> server-error-version-not-supported for CUPS-Get-Printers (no URI) from 
> 192.168.71.12.

The only reference to this error I could find was this

https://bbs.archlinux.org/viewtopic.php?id=168485

which (a long time ago) seems to have been resolved by using matching cups 
versions.

I find my Brother MFC-L2740DW is only detected on Bullseye if both devices use 
the same wifi band (the printer supports only 2.4GHz).  I'm sure this was never 
a thing in Buster, but I may have switched bands at some point and forgotten 
about having done that.  I imagine it could conceivably be due to a dodgy ISP 
router firmware update too.  

Are either of the printers you want access to from Bullseye currently shared 
via Buster CUPS, or Bullseye CUPS, or just via own wifi?  

HL-L2320D seems to be USB

Re: cups not sharing printers with other bullseye machines

[gene heskett]

On 4/8/23 02:40, Gareth Evans wrote:

On Sat  8 Apr 2023, at 03:20, gene heskett  wrote:

Greetings all;

Where do I turn on cups debugging so I'll see every bit of traffic
addressed to cups from my local 192.168/xx.yy network?

The problem is: other buster machines on this local network can see and
use the two brother printers just as if the printer was local to that
buster machine.

But no bullseye, debian or armbian can see anything at
localhost:631/printers except the search screen when there are no printers.

These printers are marked as shared in this bullseye machines /etc/cups
files.

There's a new roadblock someplace, I've asked about before. I'd like to
find it.

Buster machines can, other bullseye machines can't.

Thank you.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
   soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
   - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>


Hi Gene,

Not sure if CUPS debugging may be helpful, see eg.

https://sysadminera.com/2020/09/10/linux-how-to-enable-and-capture-cups-debugging-logs/

The most intelligent output I can get from the error_log on one of the 
armbian bullseye machines is a garbled attempt to open a pipe (I think)
from that log a snippet is attached. Tail end of a cups restart. Looks 
like something in the name resolution is totally fubar to me.


But, I can send ff to the exact entry in client.conf, and it can see all 
the shared printers here on this machine. But cups on that machine can't.



But first, I seem to recall you removed avahi and cups-browsed from Bullseye 
machines.  Is that correct?  Do the Buster machines have either or both of 
those installed?


avahi and cups-browsed have both been re-installed on that armbian machine.
And its networking continues to work thru a reboot, something I could 
not do at the original install.
Then I check this machines error_log which is flooded with thousands of 
lines of this from my attempts to get a printer list on the armbian machine:


E [08/Apr/2023:12:25:16 -0400] [Client 18] Returning IPP 
server-error-version-not-supported for CUPS-Get-Printers (no URI) from 
192.168.71.12.
E [08/Apr/2023:12:25:16 -0400] [Client 18] Returning IPP 
server-error-version-not-supported for CUPS-Get-Default (no URI) from 
192.168.71.12.
E [08/Apr/2023:12:25:16 -0400] [Client 18] Returning IPP 
server-error-version-not-supported for CUPS-Get-Printers (no URI) from 
192.168.71.12.
E [08/Apr/2023:12:25:16 -0400] [Client 18] Returning IPP 
server-error-version-not-supported for CUPS-Get-Default (no URI) from 
192.168.71.12.
E [08/Apr/2023:12:25:16 -0400] [Client 18] Returning IPP 
server-error-version-not-supported for CUPS-Get-Printers (no URI) from 
192.168.71.12.


So the armbian machine is trying, and its this machine that is rejecting 
its attempts.  That's progress ;o)>


Whats next?

Thanks Gareth, take care and stay well.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>
E [08/Apr/2023:16:37:14 -0400] Unable to open listen socket for address 
[v1.::1]:631 - Cannot assign requested address.
I [08/Apr/2023:16:37:14 -0400] Listening to 127.0.0.1:631 on fd 7...
I [08/Apr/2023:16:37:14 -0400] Listening to /run/cups/cups.sock on fd 3...
I [08/Apr/2023:16:37:14 -0400] Resuming new connection processing...
D [08/Apr/2023:16:37:14 -0400] cupsdSetBusyState: newbusy="Not busy", 
busy="Active clients"
D [08/Apr/2023:16:37:14 -0400] cupsdAddCert: Adding certificate for PID 0
D [08/Apr/2023:16:37:14 -0400] Discarding unused server-started event...
D [08/Apr/2023:16:37:14 -0400] cupsdSetBusyState: newbusy="Not busy", busy="Not 
busy"
D [08/Apr/2023:16:37:15 -0400] Report: clients=0
D [08/Apr/2023:16:37:15 -0400] Report: jobs=0
D [08/Apr/2023:16:37:15 -0400] Report: jobs-active=0
D [08/Apr/2023:16:37:15 -0400] Report: printers=0
D [08/Apr/2023:16:37:15 -0400] Report: stringpool-string-count=334
D [08/Apr/2023:16:37:15 -0400] Report: stringpool-alloc-bytes=5264
D [08/Apr/2023:16:37:15 -0400] Report: stringpool-total-bytes=5696

Re: cups not sharing printers with other bullseye machines

[gene heskett]

On 4/8/23 02:40, Gareth Evans wrote:

On Sat  8 Apr 2023, at 03:20, gene heskett  wrote:

Greetings all;

Where do I turn on cups debugging so I'll see every bit of traffic
addressed to cups from my local 192.168/xx.yy network?

The problem is: other buster machines on this local network can see and
use the two brother printers just as if the printer was local to that
buster machine.

But no bullseye, debian or armbian can see anything at
localhost:631/printers except the search screen when there are no printers.

These printers are marked as shared in this bullseye machines /etc/cups
files.

There's a new roadblock someplace, I've asked about before. I'd like to
find it.

Buster machines can, other bullseye machines can't.

Thank you.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
   soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
   - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>


Hi Gene,

Not sure if CUPS debugging may be helpful, see eg.

https://sysadminera.com/2020/09/10/linux-how-to-enable-and-capture-cups-debugging-logs/


I'll look at this, thank you.


But first, I seem to recall you removed avahi and cups-browsed from Bullseye 
machines.  Is that correct?  Do the Buster machines have either or both of 
those installed?


No for avahi, not sure about browsed. Yes cups-browsed is installed on 
the buster machines. 4 of my machines are still on buster because the 
changes in python3 aren't yet compatible with linuxcnc, which is those 
machines main application. Bookworm will I think fix that.



What are the exact models of the Brother printers "missing" from Bullseye 
systems?


Brother MFC-J6920DW, Brother HL-L2320D_series.
The ink squirter 6920 is a total disaster when cups try's to drive it, 
cups does not acknowledge that it has 2 supply trays and a rear port for 
tabloid paper. Its a monster sized machine, scanner can do tabloid also. 
Let cups drive it, no color controls, and only paper it knows about is 
the 50 cents a sheet glossy photo stuff in the top tray. 300 sheets of 
decent duplex copy paper in the bottom tray is ignored.


In this case, printers not well supported by cups, but which work to 
their full capability's with brothers own linux drivers, which they 
supply for their users. But cups won't allow them to be used unless 
cups-browsed is removed from this machine, it overrides any attempt to 
use the brother drivers. so browsed has been removed from bullseye machines.


Avahi too, but for a different network wrecking reason, it insists on 
assigning your routing address to the non-existent 169.xxx.yy.yy thing. 
So your routing of 192.168 for your local network is out of scope. Most 
frustrating, can't even ping your router, 6 feet of cat6 away...



Do other printers appear on Bullseye systems?

No, its a blank screen with a search line for printers when printers 
menu is selected.
Just to confirm, I just put cups-browsed back on one of the armbian 
machines, localhost:631/printers is empty, rebooted it, still empty.
Also, the avahi bug has been fixed, it no longer overrides your attempt 
to set the local route, so both are running, I checked with htop, but no 
shared printers are seen.



Thanks,
Gareth



Thank you Gareth, take care & stay well.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

Re: cups not sharing printers with other bullseye machines

[Gareth Evans]

On Sat  8 Apr 2023, at 03:20, gene heskett  wrote:
> Greetings all;
>
> Where do I turn on cups debugging so I'll see every bit of traffic 
> addressed to cups from my local 192.168/xx.yy network?
>
> The problem is: other buster machines on this local network can see and 
> use the two brother printers just as if the printer was local to that 
> buster machine.
>
> But no bullseye, debian or armbian can see anything at 
> localhost:631/printers except the search screen when there are no printers.
>
> These printers are marked as shared in this bullseye machines /etc/cups 
> files.
>
> There's a new roadblock someplace, I've asked about before. I'd like to 
> find it.
>
> Buster machines can, other bullseye machines can't.
>
> Thank you.
>
> Cheers, Gene Heskett.
> -- 
> "There are four boxes to be used in defense of liberty:
>   soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author, 1940)
> If we desire respect for the law, we must first make the law respectable.
>   - Louis D. Brandeis
> Genes Web page <http://geneslinuxbox.net:6309/>

Hi Gene,

Not sure if CUPS debugging may be helpful, see eg.

https://sysadminera.com/2020/09/10/linux-how-to-enable-and-capture-cups-debugging-logs/

But first, I seem to recall you removed avahi and cups-browsed from Bullseye 
machines.  Is that correct?  Do the Buster machines have either or both of 
those installed?

What are the exact models of the Brother printers "missing" from Bullseye 
systems?

Do other printers appear on Bullseye systems?  

Thanks,
Gareth

cups not sharing printers with other bullseye machines

[gene heskett]

Greetings all;

Where do I turn on cups debugging so I'll see every bit of traffic 
addressed to cups from my local 192.168/xx.yy network?


The problem is: other buster machines on this local network can see and 
use the two brother printers just as if the printer was local to that 
buster machine.


But no bullseye, debian or armbian can see anything at 
localhost:631/printers except the search screen when there are no printers.


These printers are marked as shared in this bullseye machines /etc/cups 
files.


There's a new roadblock someplace, I've asked about before. I'd like to 
find it.


Buster machines can, other bullseye machines can't.

Thank you.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Sun 26 Feb 2023 at 17:09:51 +0300, Reco wrote:

>   Hi.
> 
> On Sat, Feb 25, 2023 at 11:26:21PM +, Brian wrote:
> > > It's interesting how you bring up DHCP, yet do not mention DHCP option 9
> > > (aka "option lpr-servers" in ISC lingo).
> > > A proper implementation of DHCP options would make DNS-SD (and other
> > > assorted kludges) completely redundant.
> > > But that would be in an ideal world, and in the real world DNS-SD
> > > serves its function (within its inherent limits of course).
> > > If it works, that is.
> > 
> > If the IP address changes, ipp://10.76.172.100/ipp/print as a
> > URI becomes useless. DNS-SD ensures a reachable URI. Got it?
> 
> There's no need to be rude.

Apologies if it came through like that. Note that rfc7472 says

 >...literal IPv4 or IPv6 addresses SHOULD NOT be used...

> Leaving aside changing printer's IP (the main question here is why would
> anyone would do it), how exactly DNS-SD helped Greg to print in that
> environment?

>From one of Greg Wooledge's previous mails:

  > +   eno1 IPv4 Canon LBP712Cdn (db:c0:d3)
  > +   eno1 IPv4 HP LaserJet P3010 Series [0FCDD7]
  > +   eno1 IPv4 hp LaserJet 4250 [621E13]
 
He did not want to use these printers, but they would be shown in
the print dialog of Evince (say), as would be the non-adverised
printer if it had been set up correctly. A click or two to print.

Alternatively, 'lpstat -l -e' and print with 'lp -d PRINTER FILE'.

> > > > It would also be hoped that port numbers and resource
> > > > paths are on the sheet of paper, otherwise a user will have a
> > > > lot of guessing to do.
> > > 
> > > Nope. RTFM would suffice, as always.
> > 
> > I do not think you understand my argument. A port for an IPP
> > printer need not be on 631 and the resource path need not be
> > ipp/print. RTFM hardly helps when there is an immediate need
> > to print.
> 
> I wish you good luck in "convincing" typical dumb printer firmware in
> performing such feats. Bonus points for "convincing" enterprise-grade
> printer firmware to do the same.

IPP printers need not be physical printers.
 
> The main question here, of course, is why complicate things without the
> need?
> 
> 
> > RTFM? Which ones would you recommend?
> 
> This one is good enough:
> 
> https://www.pwg.org/ipp/ippguide.html
> 
> 
> > Actually, CUPS performed splendidly.
> 
> If CUPS in that configuration did not allow a user to print certain
> amount of pages, then it cannot be called splendid.
 
CUPS did not stop a user from printing. It knew of three
printers (see above). The fourth was hidden from it.
 
> > The OP was on a badly set up, unco-operative network. That was (and
> > probably still is) the root of the issue.
> 
> And here it's you who seem to misunderstand the issue.
> It's a city hall, or something like it. People come there, some are in
> the need of printing.
> 
> We have a confirmed and documented case of CUPS failing to deliver the
> desired result (i.e. printing something) in that environment. Without
> additional user configuration, that is.
> 
> Last time I've checked, they did not provide CUPS on any Android phone
> out of the box, and probably it's the same for Apple phones.
> It's likely that some visitor would bring a laptop with them, and it's
> likely that said laptop would run M$ Windoze (or whatever that
> shovelware is called these days).
> If mobile users or M$ laptop users would encounter any trouble printing
> - surely someone would make something to fix it.
> 
> Yet is was not fixed (for a year at most), so it's likely *it works for
> the users*, so there's nothing to fix. Some user configuration on their
> device may be required, or not, it's not relevant here.
> 
> Does that mean that CUPS is in need of fixing? Of course not.
> Does that mean that DNS-SD is not needed? Of course not.
> Does that mean that the only way of printing something via CUPS is to
> use DNS-SD? You can guess it, it's also not.
> 
> 
> Moreover, printing something at a city hall is a rare (although
> periodic) task. If the printer's IP changes between Greg's vistits there
> - so what?

A few quotes from Greg Wooledge's first mail:
 
  > Whatever I managed to do last year... it's not working this
  > year.  I can only assume that my workplace's lovely IT
  > department...


  
  > When I tried to print this year's tax form to my local
  > printer, I learned that the default print queue I had
  > set up last year is no longer there.

  > This led to a c

Re: CUPS - how to match autodetected printers to physical ones

[Reco]

Hi.

On Sat, Feb 25, 2023 at 11:26:21PM +, Brian wrote:
> > It's interesting how you bring up DHCP, yet do not mention DHCP option 9
> > (aka "option lpr-servers" in ISC lingo).
> > A proper implementation of DHCP options would make DNS-SD (and other
> > assorted kludges) completely redundant.
> > But that would be in an ideal world, and in the real world DNS-SD
> > serves its function (within its inherent limits of course).
> > If it works, that is.
> 
> If the IP address changes, ipp://10.76.172.100/ipp/print as a
> URI becomes useless. DNS-SD ensures a reachable URI. Got it?

There's no need to be rude.
Leaving aside changing printer's IP (the main question here is why would
anyone would do it), how exactly DNS-SD helped Greg to print in that
environment?


> > > It would also be hoped that port numbers and resource
> > > paths are on the sheet of paper, otherwise a user will have a
> > > lot of guessing to do.
> > 
> > Nope. RTFM would suffice, as always.
> 
> I do not think you understand my argument. A port for an IPP
> printer need not be on 631 and the resource path need not be
> ipp/print. RTFM hardly helps when there is an immediate need
> to print.

I wish you good luck in "convincing" typical dumb printer firmware in
performing such feats. Bonus points for "convincing" enterprise-grade
printer firmware to do the same.

The main question here, of course, is why complicate things without the
need?


> RTFM? Which ones would you recommend?

This one is good enough:

https://www.pwg.org/ipp/ippguide.html


> Actually, CUPS performed splendidly.

If CUPS in that configuration did not allow a user to print certain
amount of pages, then it cannot be called splendid.


> The OP was on a badly set up, unco-operative network. That was (and
> probably still is) the root of the issue.

And here it's you who seem to misunderstand the issue.
It's a city hall, or something like it. People come there, some are in
the need of printing.

We have a confirmed and documented case of CUPS failing to deliver the
desired result (i.e. printing something) in that environment. Without
additional user configuration, that is.

Last time I've checked, they did not provide CUPS on any Android phone
out of the box, and probably it's the same for Apple phones.
It's likely that some visitor would bring a laptop with them, and it's
likely that said laptop would run M$ Windoze (or whatever that
shovelware is called these days).
If mobile users or M$ laptop users would encounter any trouble printing
- surely someone would make something to fix it.

Yet is was not fixed (for a year at most), so it's likely *it works for
the users*, so there's nothing to fix. Some user configuration on their
device may be required, or not, it's not relevant here.

Does that mean that CUPS is in need of fixing? Of course not.
Does that mean that DNS-SD is not needed? Of course not.
Does that mean that the only way of printing something via CUPS is to
use DNS-SD? You can guess it, it's also not.


Moreover, printing something at a city hall is a rare (although
periodic) task. If the printer's IP changes between Greg's vistits there
- so what?


> > > How would an ordinary user go on? "Give them a piece of paper" sounds
> > > awfully like "Let them eat cake".
> > 
> > Easy, a user should RTFM. Failing that, a user can use a different
> > device or OS, or *gasp* - just use ipptool. Given the environment, a
> > creative use of samba suite would probably solve the problem too, but
> > let's not get into *that*.
> > And there's that last step - just ask somebody.
> 
> You welcome Big Boss into your office for a $100M deal.

Nope. Either it's the "ordinary user" or it's the "Big Boss".
Please choose one.

Reco

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Sat 25 Feb 2023 at 22:22:55 +0300, Reco wrote:

> On Sat, Feb 25, 2023 at 06:30:28PM +, Brian wrote:
> > On Sat 25 Feb 2023 at 17:44:15 +0300, Reco wrote:
> > 
> > >   Hi.
> > > 
> > > On Fri, Feb 24, 2023 at 12:58:15PM -0500, Greg Wooledge wrote:
> > > > On Fri, Feb 17, 2023 at 05:35:11PM +0300, Reco wrote:
> > > > > Try this next time you're on site:
> > > > > 
> > > > > lpadmin -p D14841 -E -v ipp://10.76.172.100/ipp/print -m everywhere
> > > > 
> > > > This worked.  I printed two copies of the single-page PDF from Chrome
> > > > without any further problems.
> > > 
> > > Just as planned. CUPS autodiscovery is only good for something if you
> > > don't know printer's real IP. This little episode shows us that nothing
> > > beats IP-on-sheet-of-paper discovery.
> >  
> > 99% of users with tablets, smart phones, laptops etc would find
> > DNS-SD more to their liking, especially if DHCP assignment is
> > in place.
> 
> It's interesting how you bring up DHCP, yet do not mention DHCP option 9
> (aka "option lpr-servers" in ISC lingo).
> A proper implementation of DHCP options would make DNS-SD (and other
> assorted kludges) completely redundant.
> But that would be in an ideal world, and in the real world DNS-SD
> serves its function (within its inherent limits of course).
> If it works, that is.

If the IP address changes, ipp://10.76.172.100/ipp/print as a
URI becomes useless. DNS-SD ensures a reachable URI. Got it?

It's as simple as that. Why complicate it with what DHCP can
do or not do?
 
> > It would also be hoped that port numbers and resource
> > paths are on the sheet of paper, otherwise a user will have a
> > lot of guessing to do.
> 
> Nope. RTFM would suffice, as always.

I do not think you understand my argument. A port for an IPP
printer need not be on 631 and the resource path need not be
ipp/print. RTFM hardly helps when there is an immediate need
to print.

RTFM? Which ones would you recommend?

> > In this thread we see how a very experienced user reacted to
> > being denied mdns multicasting.
> 
> Allow me to quote that original e-mail for the sake of completeness:
> 
> > So the printer WORKS.  It is ON THE NETWORK.  I can print TEXT to it
> > using port 9100.
> > 
> > What I CANNOT do is find it in CUPS.  Or avahi-browse, or driverless, or
> > any of these other commands that are so allegedly wonderful.
> > 
> > Is there any way I can tell CUPS "Please set up a queue for a printer
> > whose IP address is 10.76.172.100 even though you can't discover it with
> > your fancy tools"?
> 
> The way I see it, Greg wrote about a CUPS configuration problem.
> The solution of said problem was (and still is btw) at lpadmin(8).
> Of course, to know that the solution just lies there, waiting to be
> implemented, that requires one to have a knowledge of CUPS administration.
> Luckily we have debian-user for last one.

Your interpretation of the OP's situation is misguided. He was
confused and, as such users do sometimes, lashed out at anything
in sight. There was not any CUPS missconfiguration.

Actually, CUPS performed splendidly. The OP was on a badly set
up, unco-operative network. That was (and probably still is) the
root of the issue.

> > How would an ordinary user go on? "Give them a piece of paper" sounds
> > awfully like "Let them eat cake".
> 
> Easy, a user should RTFM. Failing that, a user can use a different
> device or OS, or *gasp* - just use ipptool. Given the environment, a
> creative use of samba suite would probably solve the problem too, but
> let's not get into *that*.
> And there's that last step - just ask somebody.

You welcome Big Boss into your office for a $100M deal.

  Big Boss: Contract's on my phone. Let's print it and I'll sign.
What's the printer name?

  You: GimmeMoney

  Big Boss: Can't see it.

  You: Just let me read the manual and do a bit of network probing.

  Big Boss: (10 minutes later). Any joy?

  You: No. I'll go ask someone. Give me half an hour.

  Big Boss: I'm a busy woman with other options. Goodbye.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[Reco]

On Sat, Feb 25, 2023 at 06:30:28PM +, Brian wrote:
> On Sat 25 Feb 2023 at 17:44:15 +0300, Reco wrote:
> 
> > Hi.
> > 
> > On Fri, Feb 24, 2023 at 12:58:15PM -0500, Greg Wooledge wrote:
> > > On Fri, Feb 17, 2023 at 05:35:11PM +0300, Reco wrote:
> > > > Try this next time you're on site:
> > > > 
> > > > lpadmin -p D14841 -E -v ipp://10.76.172.100/ipp/print -m everywhere
> > > 
> > > This worked.  I printed two copies of the single-page PDF from Chrome
> > > without any further problems.
> > 
> > Just as planned. CUPS autodiscovery is only good for something if you
> > don't know printer's real IP. This little episode shows us that nothing
> > beats IP-on-sheet-of-paper discovery.
>  
> 99% of users with tablets, smart phones, laptops etc would find
> DNS-SD more to their liking, especially if DHCP assignment is
> in place.

It's interesting how you bring up DHCP, yet do not mention DHCP option 9
(aka "option lpr-servers" in ISC lingo).
A proper implementation of DHCP options would make DNS-SD (and other
assorted kludges) completely redundant.
But that would be in an ideal world, and in the real world DNS-SD
serves its function (within its inherent limits of course).
If it works, that is.


> It would also be hoped that port numbers and resource
> paths are on the sheet of paper, otherwise a user will have a
> lot of guessing to do.

Nope. RTFM would suffice, as always.


> In this thread we see how a very experienced user reacted to
> being denied mdns multicasting.

Allow me to quote that original e-mail for the sake of completeness:

> So the printer WORKS.  It is ON THE NETWORK.  I can print TEXT to it
> using port 9100.
> 
> What I CANNOT do is find it in CUPS.  Or avahi-browse, or driverless, or
> any of these other commands that are so allegedly wonderful.
> 
> Is there any way I can tell CUPS "Please set up a queue for a printer
> whose IP address is 10.76.172.100 even though you can't discover it with
> your fancy tools"?

The way I see it, Greg wrote about a CUPS configuration problem.
The solution of said problem was (and still is btw) at lpadmin(8).
Of course, to know that the solution just lies there, waiting to be
implemented, that requires one to have a knowledge of CUPS administration.
Luckily we have debian-user for last one.


> How would an ordinary user go on? "Give them a piece of paper" sounds
> awfully like "Let them eat cake".

Easy, a user should RTFM. Failing that, a user can use a different
device or OS, or *gasp* - just use ipptool. Given the environment, a
creative use of samba suite would probably solve the problem too, but
let's not get into *that*.
And there's that last step - just ask somebody.


> > > I've gotta say, though, this option is a disaster:
> > > 
> > >   -E  When specified before the -d, -p, or -x options, forces the use of
> > >   TLS encryption on the connection to the scheduler. Otherwise, 
> > > enables
> > >   the destination and accepts jobs; this is the same as running the
> > >   cupsaccept(8) and cupsenable(8) programs on the destination.
> > > 
> > > Whoever decided to overload that option in that way... yikes.
> > 
> > Back in the day Apple's slogan was "think different". The whole CUPS
> > suite is a living proof of that.
> 
> Wrong target! -E was there in its present form well before Apple
> acquired CUPS.

I stand corrected here.

Reco

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Sat 25 Feb 2023 at 17:44:15 +0300, Reco wrote:

>   Hi.
> 
> On Fri, Feb 24, 2023 at 12:58:15PM -0500, Greg Wooledge wrote:
> > On Fri, Feb 17, 2023 at 05:35:11PM +0300, Reco wrote:
> > > Try this next time you're on site:
> > > 
> > > lpadmin -p D14841 -E -v ipp://10.76.172.100/ipp/print -m everywhere
> > 
> > This worked.  I printed two copies of the single-page PDF from Chrome
> > without any further problems.
> 
> Just as planned. CUPS autodiscovery is only good for something if you
> don't know printer's real IP. This little episode shows us that nothing
> beats IP-on-sheet-of-paper discovery.
 
99% of users with tablets, smart phones, laptops etc would find
DNS-SD more to their liking, especially if DHCP assignment is
in place. It would also be hoped that port numbers and resource
paths are on the sheet of paper, otherwise a user will have a
lot of guessing to do.

In this thread we see how a very experienced user reacted to
being denied mdns multicasting. How would an ordinary user go
on? "Give them a piece of paper" sounds awfully like "Let them
eat cake".
 
> > I've gotta say, though, this option is a disaster:
> > 
> >   -E  When specified before the -d, -p, or -x options, forces the use of
> >   TLS encryption on the connection to the scheduler. Otherwise, enables
> >   the destination and accepts jobs; this is the same as running the
> >   cupsaccept(8) and cupsenable(8) programs on the destination.
> > 
> > Whoever decided to overload that option in that way... yikes.
> 
> Back in the day Apple's slogan was "think different". The whole CUPS
> suite is a living proof of that.

Wrong target! -E was there in its present form well before Apple
acquired CUPS.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[Reco]

Hi.

On Fri, Feb 24, 2023 at 12:58:15PM -0500, Greg Wooledge wrote:
> On Fri, Feb 17, 2023 at 05:35:11PM +0300, Reco wrote:
> > Try this next time you're on site:
> > 
> > lpadmin -p D14841 -E -v ipp://10.76.172.100/ipp/print -m everywhere
> 
> This worked.  I printed two copies of the single-page PDF from Chrome
> without any further problems.

Just as planned. CUPS autodiscovery is only good for something if you
don't know printer's real IP. This little episode shows us that nothing
beats IP-on-sheet-of-paper discovery.


> I've gotta say, though, this option is a disaster:
> 
>   -E  When specified before the -d, -p, or -x options, forces the use of
>   TLS encryption on the connection to the scheduler. Otherwise, enables
>   the destination and accepts jobs; this is the same as running the
>   cupsaccept(8) and cupsenable(8) programs on the destination.
> 
> Whoever decided to overload that option in that way... yikes.

Back in the day Apple's slogan was "think different". The whole CUPS
suite is a living proof of that.

Reco

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Fri 24 Feb 2023 at 12:58:15 -0500, Greg Wooledge wrote:

> On Fri, Feb 17, 2023 at 05:35:11PM +0300, Reco wrote:
> > Try this next time you're on site:
> > 
> > lpadmin -p D14841 -E -v ipp://10.76.172.100/ipp/print -m everywhere
> 
> This worked.  I printed two copies of the single-page PDF from Chrome
> without any further problems.

Good.

As I have previous indicated, this works because the vendor
has not used ipp/canon as the resource, which it is at
liberty to do so.

A previous off-target comment was

  > My burning hatred of printers and this printing system
  > remains unquenched.

Your hatred is aimed at completely the wrong target. How
is it expected to have CUPS discover a printer when mdns
multicasting is turned off on the printer by an incompetent
sysadmin?

> I've gotta say, though, this option is a disaster:
> 
>   -E  When specified before the -d, -p, or -x options, forces the use of
>   TLS encryption on the connection to the scheduler. Otherwise, enables
>   the destination and accepts jobs; this is the same as running the
>   cupsaccept(8) and cupsenable(8) programs on the destination.
> 
> Whoever decided to overload that option in that way... yikes.

I could tell you, but perthaps you might want to find out for
yourself instead of griping. Reporting (or searching) an issue
at

  https://github.com/OpenPrinting/cups/issues

might be easier than tackling the staff of your Help Desk.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[Greg Wooledge]

On Fri, Feb 17, 2023 at 05:35:11PM +0300, Reco wrote:
> Try this next time you're on site:
> 
> lpadmin -p D14841 -E -v ipp://10.76.172.100/ipp/print -m everywhere

This worked.  I printed two copies of the single-page PDF from Chrome
without any further problems.

I've gotta say, though, this option is a disaster:

  -E  When specified before the -d, -p, or -x options, forces the use of
  TLS encryption on the connection to the scheduler. Otherwise, enables
  the destination and accepts jobs; this is the same as running the
  cupsaccept(8) and cupsenable(8) programs on the destination.

Whoever decided to overload that option in that way... yikes.

Re: CUPS - how to match autodetected printers to physical ones

[Max Nikulin]

On 16/02/2023 22:41, Greg Wooledge wrote:


2) Also suggested: avahi-browse -rt _ipp._tcp
This year, the output of that command no longer contains my printer's
IP address.  Last year, it did.  I have no idea why this has changed.


Avahi was mentioned in the ipv6 thread, so I decided to read links on 
the Debian wiki page


https://en.wikipedia.org/wiki/Avahi_%28software%29

Avahi's performance resembles that of Bonjour, sometimes exceeding it;
however Avahi can lose services when managing large numbers of requests
simultaneously.[3]
3. Analysis of Peer-to-Peer Protocols Performance for Establishing a
Decentralized Desktop Grid Middleware
http://lipn.fr/~cerin/documents/PresentationSGS08heithem.pdf


Unsure if it is relevant


4) Also mentioned: port 9100.
For grins, I did "telnet 10.76.172.100 9100" and after that connected
I typed "HELLO WORLD", then pressed Enter, then Ctrl-] q Enter to
close the telnet session.


I am curious if there is some tool convenient to get report concerning 
various service service discovery protocols provided at some ip 
(mDNS-SD, uPnP, etc.).



Queue \\SPS\S010NEURD14841M


Does anyone know what technology is used by windows nowadays (Simple 
Service Discovery Protocol, SSDP?) and which tools can be used in Linux 
to get list of services?

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Fri 17 Feb 2023 at 09:05:39 -0500, Greg Wooledge wrote:

> On Fri, Feb 17, 2023 at 11:18:32AM +, Brian wrote:

[...]

> >   avahi-browse -rt _ipp._tcp
> >   avahi-browse -rt _uscan._tcp
> > 
> > (I would find that data useful for my records).
> 
> wooledg:~$ avahi-browse -rt _ipp._tcp 2>&1 | grep -A5 db:c0:d3
> +   eno1 IPv4 Canon LBP712Cdn (db:c0:d3)Internet Printer  
>local
> +   eno1 IPv4 HP LaserJet P3010 Series [0FCDD7] Internet Printer  
>local
> +   eno1 IPv4 hp LaserJet 4250 [621E13] Internet Printer  
>local
> =   eno1 IPv4 Canon LBP712Cdn (db:c0:d3)Internet Printer  
>local
>hostname = [dhcp-10-76-173-174.local]
>address = [10.76.173.174]
>port = [631]
>txt = ["mopria-certified=1.2" "print_wfds=T" 
> "kind=document,envelope,postcard" 
> "URF=ADOBERGB24,CP255,DM1,FN3,IS1-4,OB10,PQ4,RS300,SRGB24,V1.4,W8-16" "Fax=F" 
> "Scan=F" "TLS=1.2" "usb_CMD=LIPSLX" 
> "UUID=15904ba4-fe8c-3bee-5d53-cb5f72ea86b2" "PaperMax=legal-A4" "Punch=0" 
> "Staple=F" "Sort=T" "Collate=T" "Bind=F" "PaperCustom=T" "Duplex=T" 
> "Copies=T" "Color=T" "TBCP=F" "Binary=F" "Transparent=F" "usb_MDL=LBP712C UFR 
> II" "usb_MFG=Canon" "adminurl=https://dhcp-10-76-173-174.local/airprint.html; 
> "pdl=application/octet-stream,image/urf,image/pwg-raster,image/jpeg,application/pdf"
>  "product=(CNLBP712C)" "ty=Canon LBP712C" "priority=10" "qtotal=1" "note=" 
> "rp=ipp/print" "txtvers=1"]
> =   eno1 IPv4 hp LaserJet 4250 [621E13] Internet Printer  
>local

Assuming the machine at 10.76.172.100 is identical with this one
at 10.76.173.174, it too will have a TXT record with

  
pdl=application/octet-stream,image/urf,image/pwg-raster,image/jpeg,application/pdf

A PDF sent directly to it should print if an open port 9100 exists
on the printer:

  netcat 10.76.172.100 9100 < taxform.pdf

> wooledg:~$ time avahi-browse -rt _uscan._tcp
> real 1.023  user 0.004  sys 0.004
> 
> (No other output.)

No prolem here. The LBP712Cdn does not have a scanner.

It looks like mdns multcasting has been disabled on the printer
at 10.76.172.100. This is unfortunate and unnecessary. Perhaps
someone should inform your helpful Help Desk that its Bonjour
name can be changed to distinguish it from similare devices on
the network.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[Reco]

Hi.

On Thu, Feb 16, 2023 at 10:41:33AM -0500, Greg Wooledge wrote:
> So the printer WORKS.  It is ON THE NETWORK.  I can print TEXT to it
> using port 9100.
> 
> What I CANNOT do is find it in CUPS.  Or avahi-browse, or driverless, or
> any of these other commands that are so allegedly wonderful.
> 
> Is there any way I can tell CUPS "Please set up a queue for a printer
> whose IP address is 10.76.172.100 even though you can't discover it with
> your fancy tools"?

Try this next time you're on site:

lpadmin -p D14841 -E -v ipp://10.76.172.100/ipp/print -m everywhere

Reco

Re: CUPS - how to match autodetected printers to physical ones

[Greg Wooledge]

On Fri, Feb 17, 2023 at 11:18:32AM +, Brian wrote:
> On Thu 16 Feb 2023 at 15:32:47 -0500, Greg Wooledge wrote:
> 
> > wooledg:~$ cat /etc/debian_version 
> > 11.6
> > wooledg:~$ lpstat -l -e
> > Canon_LBP712C_UFR_II_ permanent 
> > ipp://localhost/printers/Canon_LBP712C_UFR_II_ 
> > ipp://Canon%20LBP712Cdn%20(db%3Ac0%3Ad3)._ipp._tcp.local/
> 
> This is a print queue, set up using Canon drivers.
> 
> > Canon_LBP712Cdn_db_c0_d3_ network none 
> > ipp://Canon%20LBP712Cdn%20(db%3Ac0%3Ad3)._ipp._tcp.local/
> 
> This is not a print queue. CUPS has discovered the printer via
> mdns/DNS-SD and enumetated it. It should be seen with
> 
>   avahi-browse -rt _ipp._tcp
>   avahi-browse -rt _uscan._tcp
> 
> (I would find that data useful for my records).

wooledg:~$ avahi-browse -rt _ipp._tcp 2>&1 | grep -A5 db:c0:d3
+   eno1 IPv4 Canon LBP712Cdn (db:c0:d3)Internet Printer
 local
+   eno1 IPv4 HP LaserJet P3010 Series [0FCDD7] Internet Printer
 local
+   eno1 IPv4 hp LaserJet 4250 [621E13] Internet Printer
 local
=   eno1 IPv4 Canon LBP712Cdn (db:c0:d3)Internet Printer
 local
   hostname = [dhcp-10-76-173-174.local]
   address = [10.76.173.174]
   port = [631]
   txt = ["mopria-certified=1.2" "print_wfds=T" 
"kind=document,envelope,postcard" 
"URF=ADOBERGB24,CP255,DM1,FN3,IS1-4,OB10,PQ4,RS300,SRGB24,V1.4,W8-16" "Fax=F" 
"Scan=F" "TLS=1.2" "usb_CMD=LIPSLX" "UUID=15904ba4-fe8c-3bee-5d53-cb5f72ea86b2" 
"PaperMax=legal-A4" "Punch=0" "Staple=F" "Sort=T" "Collate=T" "Bind=F" 
"PaperCustom=T" "Duplex=T" "Copies=T" "Color=T" "TBCP=F" "Binary=F" 
"Transparent=F" "usb_MDL=LBP712C UFR II" "usb_MFG=Canon" 
"adminurl=https://dhcp-10-76-173-174.local/airprint.html; 
"pdl=application/octet-stream,image/urf,image/pwg-raster,image/jpeg,application/pdf"
 "product=(CNLBP712C)" "ty=Canon LBP712C" "priority=10" "qtotal=1" "note=" 
"rp=ipp/print" "txtvers=1"]
=   eno1 IPv4 hp LaserJet 4250 [621E13] Internet Printer
 local

wooledg:~$ time avahi-browse -rt _uscan._tcp
real 1.023  user 0.004  sys 0.004

(No other output.)

> Its URI will be
> 
>   ipp://10.76.172.100/ipp/print
> 
> Execute
> 
>   lpadmin -p mycanonprinter -v URI -E -m everywhere
> 
> Test printing with
> 
>   lp -d mycanonprinter /etc/nsswitch.conf

Any physical tests will have to wait, at least a week.

Oh, one other thing in case you were confused: the netmask there is
/23 not /24.  10.76.172.x and 10.76.173.x are both on that subnet.
Each subnet is assigned to one physical floor of a building.  That
particular subnet covers the 10th floor of building S, which is...
not an enormous space, but not small either.  At full capacity, there
could be a few dozen people working there, and the space is divided into
separate sections, each behind its own locked door(s).

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Thu 16 Feb 2023 at 15:32:47 -0500, Greg Wooledge wrote:

> wooledg:~$ cat /etc/debian_version 
> 11.6
> wooledg:~$ lpstat -l -e
> Canon_LBP712C_UFR_II_ permanent 
> ipp://localhost/printers/Canon_LBP712C_UFR_II_ 
> ipp://Canon%20LBP712Cdn%20(db%3Ac0%3Ad3)._ipp._tcp.local/

This is a print queue, set up using Canon drivers.

> Canon_LBP712Cdn_db_c0_d3_ network none 
> ipp://Canon%20LBP712Cdn%20(db%3Ac0%3Ad3)._ipp._tcp.local/

This is not a print queue. CUPS has discovered the printer via
mdns/DNS-SD and enumetated it. It should be seen with

  avahi-browse -rt _ipp._tcp
  avahi-browse -rt _uscan._tcp

(I would find that data useful for my records).

It can be printed to with

  lp -d "Canon_LBP712Cdn_db_c0_d3_" FILE

Where the job  physically ends up is outside the scope of
CUPS.

Let's assume the printer you ar interested in is not being
multicast. It exists at 10.76.172.100. Let us guess that
the resource to access on the printer is ipp/print. This is
a pretty good guess because most vendors use it nowadays.

Its URI will be

  ipp://10.76.172.100/ipp/print

Execute

  lpadmin -p mycanonprinter -v URI -E -m everywhere

Test printing with

  lp -d mycanonprinter /etc/nsswitch.conf

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[Greg Wooledge]

On Thu, Feb 16, 2023 at 03:51:47PM -0500, gene heskett wrote:
> I hate to ask the obvious, but is the net cable plugged into that printer?

See below.

On Thu, Feb 16, 2023 at 10:41:33AM -0500, Greg Wooledge wrote:
> 4) Also mentioned: port 9100.
>For grins, I did "telnet 10.76.172.100 9100" and after that connected
>I typed "HELLO WORLD", then pressed Enter, then Ctrl-] q Enter to
>close the telnet session.
> 
>That actually printed the words HELLO WORLD on a sheet of paper.
> 
> So the printer WORKS.  It is ON THE NETWORK.  I can print TEXT to it
> using port 9100.

Re: CUPS - how to match autodetected printers to physical ones

[gene heskett]

On 2/16/23 16:09, Bob McGowan wrote:

On 2/16/23 12:01 PM, Brian wrote:

On Thu 16 Feb 2023 at 11:27:25 -0800, Bob McGowan wrote:


On 2/16/23 11:14 AM, Brian wrote:

On Thu 16 Feb 2023 at 11:52:21 -0500, Stefan Monnier wrote:


[1]to...@tuxteam.de  [2023-02-16 16:53:02] wrote:

Just for kicks: have you tried sending a PS (or *gasp* PDF) file
down that alley (e.g. with socat)?

For That One Form in the Year this might be just sufficient...

Hint: start with a small one :)

I don't think "a small one" can be small enough in case it misfires.
Instead, I usually make sure there's only 1 sheet of paper in the tray
when I send the test (usually a sheet that I already used :-)

Producind a PDF with the line "This is a test" in it is
incredibly easy. Jumping through hoops is not needed.


However, the PDF file created (I used LibreOffice 'cause its fast and
easy) was 7,335 characters long, according to 'wc', which also reported
367 "words" and 139 "lines".

Given that a standard US letter size sheet (8.5 by 11 inches) has 66
lines per page, that is just over 2 pages.

So putting only one used sheet of paper in the printer would save a
couple of sheets of paper. ;)

Not much but why waste paper for a simple test?

I have no desire or intention to investigate how LibreOffice
deals with a single line text file converted to a PDF. This
works to not waste paper when fileout.pdf is printed:

  /usr/lib/cups/filter/texttopdf 1 1 1 1 1 filein.txt > fileout.pdf


The point is that conversion to PDF results in a larger file than some 
might expect.


Depends on the content. recent activity in adding gfx content to it has 
expanded it quite a bit this file is now 1316 pages long on dead tree:


rw-r--r-- 1 root root 25471049 Feb 14 09:50 LinuxCNC_Documentation.pdf

But for whats in it gfx-wise today, just over 25 megabytes is really 
good compression.


And we don't know if the printer actually does understands PDF 
directly.  If it does not, it would attempt to print the entire contents 
of the file as plain text.  At least, this is how I understood the 
comment I was responding to.


In the case of your command (which, by the way, requires some "esoteric" 
knowledge of CUPS), the resulting file, according to 'wc', is: 85  181 
1020 fileout.pdf


Not as big as the LibreOffice file, but still more than one page of 
output if printed as plain text.


And 99% of that "small" file is non-printed mode commands to the 
printer, telling it how to present that one line of text. 25+ years ago 
when ghostscript tried to be all, both ps v1.3 and v1.2 pdf at about 
v5.1, I'm the one who compiled it for the amiga's, even devising a 
couple bash scripts that made a simplex printer do duplex. I tried to 
wear out a xerox 1650-ro, the fastest daisy wheel ever, failed, it still 
works but no ribbons today.


Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

Re: CUPS - how to match autodetected printers to physical ones

[Bob McGowan]

On 2/16/23 12:01 PM, Brian wrote:

On Thu 16 Feb 2023 at 11:27:25 -0800, Bob McGowan wrote:


On 2/16/23 11:14 AM, Brian wrote:

On Thu 16 Feb 2023 at 11:52:21 -0500, Stefan Monnier wrote:


[1]to...@tuxteam.de  [2023-02-16 16:53:02] wrote:

Just for kicks: have you tried sending a PS (or *gasp* PDF) file
down that alley (e.g. with socat)?

For That One Form in the Year this might be just sufficient...

Hint: start with a small one :)

I don't think "a small one" can be small enough in case it misfires.
Instead, I usually make sure there's only 1 sheet of paper in the tray
when I send the test (usually a sheet that I already used :-)

Producind a PDF with the line "This is a test" in it is
incredibly easy. Jumping through hoops is not needed.


However, the PDF file created (I used LibreOffice 'cause its fast and
easy) was 7,335 characters long, according to 'wc', which also reported
367 "words" and 139 "lines".

Given that a standard US letter size sheet (8.5 by 11 inches) has 66
lines per page, that is just over 2 pages.

So putting only one used sheet of paper in the printer would save a
couple of sheets of paper. ;)

Not much but why waste paper for a simple test?

I have no desire or intention to investigate how LibreOffice
deals with a single line text file converted to a PDF. This
works to not waste paper when fileout.pdf is printed:

  /usr/lib/cups/filter/texttopdf 1 1 1 1 1 filein.txt > fileout.pdf


The point is that conversion to PDF results in a larger file than some 
might expect.


And we don't know if the printer actually does understands PDF 
directly.  If it does not, it would attempt to print the entire contents 
of the file as plain text.  At least, this is how I understood the 
comment I was responding to.


In the case of your command (which, by the way, requires some "esoteric" 
knowledge of CUPS), the resulting file, according to 'wc', is: 85  181 
1020 fileout.pdf


Not as big as the LibreOffice file, but still more than one page of 
output if printed as plain text.

Re: CUPS - how to match autodetected printers to physical ones

[gene heskett]

On 2/16/23 15:33, Greg Wooledge wrote:

On Thu, Feb 16, 2023 at 06:57:46PM +0200, Teemu Likonen wrote:

Here is my version which I suggest turning into a shell alias, function
or script:

 avahi-browse -atrp 2>/dev/null | awk -F\; \
 '$1 == "=" { printf "%-23s %-26s %5s %s\n",$7,$8,$9,$5 }'

It should print lines like these:

 SEC00159939FFD2.local   192.168.0.11 631 Internet Printer
 mithlond.local  192.168.0.2  631 Internet Printer


wooledg:~$ avahi-browse -atrp 2>/dev/null | awk -F\; '$1 == "=" { printf "%-23s 
%-26s %5s %s\n",$7,$8,$9,$5 }'
dhcp-10-76-173-174.local 10.76.173.174631 Internet Printer
wooledg.local   fe80::9e7b:efff:fe24:4213445 Microsoft Windows 
Network
wooledg.local   fe80::9e7b:efff:fe24:4213  0 Device Info
wooledg.local   10.76.172.189445 Microsoft Windows 
Network
wooledg.local   10.76.172.189  0 Device Info
wooledg.local   127.0.0.1445 Microsoft Windows 
Network
wooledg.local   127.0.0.1  0 Device Info
NPI0FCDD7.local 10.76.173.60 631 Internet Printer
NPI0FCDD7.local 10.76.173.60 515 UNIX Printer
NPI0FCDD7.local 10.76.173.60 631 Internet Printer
NPI0FCDD7.local 10.76.173.60 515 UNIX Printer
A09-LBT2-HPLJ4250-01.local 10.76.172.120631 Internet Printer
A09-LBT2-HPLJ4250-01.local 10.76.172.120515 UNIX Printer
dhcp-10-76-173-174.local 10.76.173.174515 UNIX Printer
dhcp-10-76-173-174.local 10.76.173.174 80 Web Site
dhcp-10-76-173-174.local 10.76.173.174   9100 PDL Printer
NPI0FCDD7.local 10.76.173.609100 PDL Printer
NPI0FCDD7.local 10.76.173.60  80 Web Site
NPI0FCDD7.local 10.76.173.60  21 FTP File Transfer
NPI0FCDD7.local 10.76.173.60  23 Telnet Remote Terminal
NPI0FCDD7.local 10.76.173.609100 PDL Printer
NPI0FCDD7.local 10.76.173.60  80 Web Site
NPI0FCDD7.local 10.76.173.60  21 FTP File Transfer
NPI0FCDD7.local 10.76.173.60  23 Telnet Remote Terminal
A09-LBT2-HPLJ4250-01.local 10.76.172.120   9100 PDL Printer
A09-LBT2-HPLJ4250-01.local 10.76.172.120 80 Web Site
A09-LBT2-HPLJ4250-01.local 10.76.172.120 21 FTP File Transfer
A09-LBT2-HPLJ4250-01.local 10.76.172.120 23 Telnet Remote 
Terminal

It does not report the printer at 10.76.172.100.  I imagine that it would
have reported it a year ago.  I don't know what changed.


I would try to add manually one of these connection addresses:

 http://10.76.172.100:631
 ipp://10.76.172.100:631


I can try that next time I'm physically there, usually once a week.

On Thu, Feb 16, 2023 at 06:54:18PM +, Brian wrote:

On Thu 16 Feb 2023 at 10:41:33 -0500, Greg Wooledge wrote:

[...]


3) Also suggested: driverless
Here's what I get this year:

wooledg:~$ driverless
ipp://Canon%20LBP712Cdn%20(db%3Ac0%3Ad3)._ipp._tcp.local/

That's all.  And no, that's not the right printer.  That's the one
that has the right model number, but isn't *mine*.  I can only imagine
it's somewhere else on this floor, and that someone is very confused
upon seeing income tax forms coming out of it.


How do you know it it does not point to the right printer?


It's got that "db:c0:d3" suffix.  The printer with that suffix in CUPS
is the black hole where whatever I send doesn't get printed by my printer.
I assume it's another Canon LBP712Cdn somewhere else on the 10th floor,
or at least something claiming to be a Canon LBP712Cdn.

I still have no idea what the db:c0:d3 means.


Your machine has bullseye, we suppose? Give what you gat for

   lpstat -l -e


wooledg:~$ cat /etc/debian_version
11.6
wooledg:~$ lpstat -l -e
Canon_LBP712C_UFR_II_ permanent ipp://localhost/printers/Canon_LBP712C_UFR_II_ 
ipp://Canon%20LBP712Cdn%20(db%3Ac0%3Ad3)._ipp._tcp.local/
Canon_LBP712Cdn_db_c0_d3_ network none 
ipp://Canon%20LBP712Cdn%20(db%3Ac0%3Ad3)._ipp._tcp.local/
Cups_PDF_oc3261540276 permanent ipp://localhost/printers/Cups_PDF_oc3261540276 
file:///dev/null
hp_LaserJet_4250_621E13_ permanent 
ipp://localhost/printers/hp_LaserJet_4250_621E13_ 
implicitclass://hp_LaserJet_4250_621E13_/
HP_LaserJet_P3010_Series_0FCDD7_ permanent 
ipp://localhost/printers/HP_LaserJet_P3010_Series_0FCDD7_ 
implicitclass://HP_LaserJet_P3010_Series_0FCDD7_/
PostScript_oc3261540276 permanent 
ipp://localhost/printers/PostScript_oc3261540276 file:///dev/null


Is there any way I can tell CUPS "Please set up a queue for a printer
whose IP address is 10.76.172.100 even though you can't discover 

Re: CUPS - how to match autodetected printers to physical ones

[Greg Wooledge]

On Thu, Feb 16, 2023 at 06:57:46PM +0200, Teemu Likonen wrote:
> Here is my version which I suggest turning into a shell alias, function
> or script:
> 
> avahi-browse -atrp 2>/dev/null | awk -F\; \
> '$1 == "=" { printf "%-23s %-26s %5s %s\n",$7,$8,$9,$5 }'
> 
> It should print lines like these:
> 
> SEC00159939FFD2.local   192.168.0.11 631 Internet Printer
> mithlond.local  192.168.0.2  631 Internet Printer

wooledg:~$ avahi-browse -atrp 2>/dev/null | awk -F\; '$1 == "=" { printf "%-23s 
%-26s %5s %s\n",$7,$8,$9,$5 }'
dhcp-10-76-173-174.local 10.76.173.174631 Internet Printer
wooledg.local   fe80::9e7b:efff:fe24:4213445 Microsoft Windows 
Network
wooledg.local   fe80::9e7b:efff:fe24:4213  0 Device Info
wooledg.local   10.76.172.189445 Microsoft Windows 
Network
wooledg.local   10.76.172.189  0 Device Info
wooledg.local   127.0.0.1445 Microsoft Windows 
Network
wooledg.local   127.0.0.1  0 Device Info
NPI0FCDD7.local 10.76.173.60 631 Internet Printer
NPI0FCDD7.local 10.76.173.60 515 UNIX Printer
NPI0FCDD7.local 10.76.173.60 631 Internet Printer
NPI0FCDD7.local 10.76.173.60 515 UNIX Printer
A09-LBT2-HPLJ4250-01.local 10.76.172.120631 Internet Printer
A09-LBT2-HPLJ4250-01.local 10.76.172.120515 UNIX Printer
dhcp-10-76-173-174.local 10.76.173.174515 UNIX Printer
dhcp-10-76-173-174.local 10.76.173.174 80 Web Site
dhcp-10-76-173-174.local 10.76.173.174   9100 PDL Printer
NPI0FCDD7.local 10.76.173.609100 PDL Printer
NPI0FCDD7.local 10.76.173.60  80 Web Site
NPI0FCDD7.local 10.76.173.60  21 FTP File Transfer
NPI0FCDD7.local 10.76.173.60  23 Telnet Remote Terminal
NPI0FCDD7.local 10.76.173.609100 PDL Printer
NPI0FCDD7.local 10.76.173.60  80 Web Site
NPI0FCDD7.local 10.76.173.60  21 FTP File Transfer
NPI0FCDD7.local 10.76.173.60  23 Telnet Remote Terminal
A09-LBT2-HPLJ4250-01.local 10.76.172.120   9100 PDL Printer
A09-LBT2-HPLJ4250-01.local 10.76.172.120 80 Web Site
A09-LBT2-HPLJ4250-01.local 10.76.172.120 21 FTP File Transfer
A09-LBT2-HPLJ4250-01.local 10.76.172.120 23 Telnet Remote 
Terminal

It does not report the printer at 10.76.172.100.  I imagine that it would
have reported it a year ago.  I don't know what changed.

> I would try to add manually one of these connection addresses:
> 
> http://10.76.172.100:631
> ipp://10.76.172.100:631

I can try that next time I'm physically there, usually once a week.

On Thu, Feb 16, 2023 at 06:54:18PM +, Brian wrote:
> On Thu 16 Feb 2023 at 10:41:33 -0500, Greg Wooledge wrote:
> 
> [...]
> 
> > 3) Also suggested: driverless
> >Here's what I get this year:
> > 
> >wooledg:~$ driverless
> >ipp://Canon%20LBP712Cdn%20(db%3Ac0%3Ad3)._ipp._tcp.local/
> > 
> >That's all.  And no, that's not the right printer.  That's the one
> >that has the right model number, but isn't *mine*.  I can only imagine
> >it's somewhere else on this floor, and that someone is very confused
> >upon seeing income tax forms coming out of it.
> 
> How do you know it it does not point to the right printer?

It's got that "db:c0:d3" suffix.  The printer with that suffix in CUPS
is the black hole where whatever I send doesn't get printed by my printer.
I assume it's another Canon LBP712Cdn somewhere else on the 10th floor,
or at least something claiming to be a Canon LBP712Cdn.

I still have no idea what the db:c0:d3 means.

> Your machine has bullseye, we suppose? Give what you gat for
> 
>   lpstat -l -e

wooledg:~$ cat /etc/debian_version 
11.6
wooledg:~$ lpstat -l -e
Canon_LBP712C_UFR_II_ permanent ipp://localhost/printers/Canon_LBP712C_UFR_II_ 
ipp://Canon%20LBP712Cdn%20(db%3Ac0%3Ad3)._ipp._tcp.local/
Canon_LBP712Cdn_db_c0_d3_ network none 
ipp://Canon%20LBP712Cdn%20(db%3Ac0%3Ad3)._ipp._tcp.local/
Cups_PDF_oc3261540276 permanent ipp://localhost/printers/Cups_PDF_oc3261540276 
file:///dev/null
hp_LaserJet_4250_621E13_ permanent 
ipp://localhost/printers/hp_LaserJet_4250_621E13_ 
implicitclass://hp_LaserJet_4250_621E13_/
HP_LaserJet_P3010_Series_0FCDD7_ permanent 
ipp://localhost/printers/HP_LaserJet_P3010_Series_0FCDD7_ 
implicitclass://HP_LaserJet_P3010_Series_0FCDD7_/
PostScript_oc3261540276 permanent 
ipp://localhost/printers/PostScript_oc3261540276 file

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Thu 16 Feb 2023 at 11:27:25 -0800, Bob McGowan wrote:

>On 2/16/23 11:14 AM, Brian wrote:
> 
> On Thu 16 Feb 2023 at 11:52:21 -0500, Stefan Monnier wrote:
> 
> 
> [1]to...@tuxteam.de [2023-02-16 16:53:02] wrote:
> 
> Just for kicks: have you tried sending a PS (or *gasp* PDF) file
> down that alley (e.g. with socat)?
> 
> For That One Form in the Year this might be just sufficient...
> 
> Hint: start with a small one :)
> 
> I don't think "a small one" can be small enough in case it misfires.
> Instead, I usually make sure there's only 1 sheet of paper in the tray
> when I send the test (usually a sheet that I already used :-)
> 
> Producind a PDF with the line "This is a test" in it is
> incredibly easy. Jumping through hoops is not needed.
> 
> 
>However, the PDF file created (I used LibreOffice 'cause its fast and
>easy) was 7,335 characters long, according to 'wc', which also reported
>367 "words" and 139 "lines".
> 
>Given that a standard US letter size sheet (8.5 by 11 inches) has 66
>lines per page, that is just over 2 pages.
> 
>So putting only one used sheet of paper in the printer would save a
>couple of sheets of paper. ;)
> 
>Not much but why waste paper for a simple test?

I have no desire or intention to investigate how LibreOffice
deals with a single line text file converted to a PDF. This
works to not waste paper when fileout.pdf is printed:

 /usr/lib/cups/filter/texttopdf 1 1 1 1 1 filein.txt > fileout.pdf

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[Bob McGowan]

  
  
On 2/16/23 11:14 AM, Brian wrote:


  On Thu 16 Feb 2023 at 11:52:21 -0500, Stefan Monnier wrote:


  
to...@tuxteam.de [2023-02-16 16:53:02] wrote:


  Just for kicks: have you tried sending a PS (or *gasp* PDF) file
down that alley (e.g. with socat)?

For That One Form in the Year this might be just sufficient...

Hint: start with a small one :)



I don't think "a small one" can be small enough in case it misfires.
Instead, I usually make sure there's only 1 sheet of paper in the tray
when I send the test (usually a sheet that I already used :-)

  
  
Producind a PDF with the line "This is a test" in it is
incredibly easy. Jumping through hoops is not needed.



However, the PDF file created (I used LibreOffice 'cause its fast
  and easy) was 7,335 characters long, according to 'wc', which also
  reported 367 "words" and 139 "lines".
Given that a standard US letter size sheet (8.5 by 11 inches) has
  66 lines per page, that is just over 2 pages.
So putting only one used sheet of paper in the printer would save
  a couple of sheets of paper. ;)
Not much but why waste paper for a simple test?

Bob

  

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Thu 16 Feb 2023 at 11:52:21 -0500, Stefan Monnier wrote:

> to...@tuxteam.de [2023-02-16 16:53:02] wrote:
> > Just for kicks: have you tried sending a PS (or *gasp* PDF) file
> > down that alley (e.g. with socat)?
> >
> > For That One Form in the Year this might be just sufficient...
> >
> > Hint: start with a small one :)
> 
> I don't think "a small one" can be small enough in case it misfires.
> Instead, I usually make sure there's only 1 sheet of paper in the tray
> when I send the test (usually a sheet that I already used :-)

Producind a PDF with the line "This is a test" in it is
incredibly easy. Jumping through hoops is not needed.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Thu 16 Feb 2023 at 10:41:33 -0500, Greg Wooledge wrote:

[...]

> 3) Also suggested: driverless
>Here's what I get this year:
> 
>wooledg:~$ driverless
>ipp://Canon%20LBP712Cdn%20(db%3Ac0%3Ad3)._ipp._tcp.local/
> 
>That's all.  And no, that's not the right printer.  That's the one
>that has the right model number, but isn't *mine*.  I can only imagine
>it's somewhere else on this floor, and that someone is very confused
>upon seeing income tax forms coming out of it.

How do you know it it does not point to the right printer?

> 4) Also mentioned: port 9100.
>For grins, I did "telnet 10.76.172.100 9100" and after that connected
>I typed "HELLO WORLD", then pressed Enter, then Ctrl-] q Enter to
>close the telnet session.
> 
>That actually printed the words HELLO WORLD on a sheet of paper.
> 
> So the printer WORKS.  It is ON THE NETWORK.  I can print TEXT to it
> using port 9100.

The printer understands text.

> What I CANNOT do is find it in CUPS.  Or avahi-browse, or driverless, or
> any of these other commands that are so allegedly wonderful.

Your machine has bullseye, we suppose? Give what you gat for

  lpstat -l -e

> Is there any way I can tell CUPS "Please set up a queue for a printer
> whose IP address is 10.76.172.100 even though you can't discover it with
> your fancy tools"?

Yes, but it should not be needed and involves guessing.(Please
try to avoid unhelpful, judgemental adjectives).

[...]

> My burning hatred of printers and this printing system remains unquenched.

Calm down! Understanding a situation (like the operation of a
shell script) requires being able to focus.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[tomas]

On Thu, Feb 16, 2023 at 11:52:21AM -0500, Stefan Monnier wrote:
> to...@tuxteam.de [2023-02-16 16:53:02] wrote:
> > Just for kicks: have you tried sending a PS (or *gasp* PDF) file
> > down that alley (e.g. with socat)?
> >
> > For That One Form in the Year this might be just sufficient...
> >
> > Hint: start with a small one :)
> 
> I don't think "a small one" can be small enough in case it misfires.
> Instead, I usually make sure there's only 1 sheet of paper in the tray
> when I send the test (usually a sheet that I already used :-)

:-)

-- 
t


signature.asc
Description: PGP signature

Re: CUPS - how to match autodetected printers to physical ones

[Teemu Likonen]

* 2023-02-16 10:41:33-0500, Greg Wooledge wrote:

> 1) Someone suggested: avahi-discover -r _print-caps._tcp
>When I tried it last year, it simply hung with no visible output
>until Ctrl-C'ed.

Here is my version which I suggest turning into a shell alias, function
or script:

avahi-browse -atrp 2>/dev/null | awk -F\; \
'$1 == "=" { printf "%-23s %-26s %5s %s\n",$7,$8,$9,$5 }'

It should print lines like these:

SEC00159939FFD2.local   192.168.0.11 631 Internet Printer
mithlond.local  192.168.0.2  631 Internet Printer

The SEC00159939FFD2.local is my printer. The printer gets its IP through
DHCP but I don't use the IP address anywhere, because the .local name
works automatically. Make sure to install (almost) all packages which
CUPS and Avahi recommend.

> Is there any way I can tell CUPS "Please set up a queue for a printer
> whose IP address is 10.76.172.100 even though you can't discover it with
> your fancy tools"?

I would try to add manually one of these connection addresses:

http://10.76.172.100:631
ipp://10.76.172.100:631

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462


signature.asc
Description: PGP signature

Re: CUPS - how to match autodetected printers to physical ones

[Stefan Monnier]

to...@tuxteam.de [2023-02-16 16:53:02] wrote:
> Just for kicks: have you tried sending a PS (or *gasp* PDF) file
> down that alley (e.g. with socat)?
>
> For That One Form in the Year this might be just sufficient...
>
> Hint: start with a small one :)

I don't think "a small one" can be small enough in case it misfires.
Instead, I usually make sure there's only 1 sheet of paper in the tray
when I send the test (usually a sheet that I already used :-)


Stefan

Re: CUPS - how to match autodetected printers to physical ones

[Fred]

On 2/16/23 08:41, Greg Wooledge wrote:

It's tax season again, so once again I am putting myself through the
utter hell that is attempting to print my city's Income Tax Forms.

(Yes, this is mandatory.  No, they do not accept electronic submissions.
You must use paper and ink.  Yes, they require you to print your own
forms.  No, they will not mail you a form.)

Whatever I managed to do last year... it's not working this year.  I can
only assume that my workplace's lovely IT department has taken even more
drastic steps in their eternal war against anything that isn't blessed
by Microsoft, and isn't under their control.

When I tried to print this year's tax form to my local printer, I learned
that the default print queue I had set up last year is no longer there.

This led to a complete rerun of everything from last year -- going up to
the printer, looking at the piece of paper attached to the front of it
which has the IP address (same one -- 10.76.172.100), attempting to
find a queue in CUPS which matches up with that, sending print jobs to
what *appears* to be the correct printer, having no paper come out, etc.

Eventually I unearthed this thread, which had some advice which worked
in the past.

It is not working today.

Here's a run-down:

1) Someone suggested: avahi-discover -r _print-caps._tcp
When I tried it last year, it simply hung with no visible output
until Ctrl-C'ed.

This year, I ran it while physically present in the workplace, so now
I know why it hangs.  It pops up an X11 window.  Only after you close
that X11 window does it print results on the terminal.

That's extremely difficult to detect or deal with when you're ssh-ing
in, running commands in a screen session.

2) Also suggested: avahi-browse -rt _ipp._tcp
This year, the output of that command no longer contains my printer's
IP address.  Last year, it did.  I have no idea why this has changed.

3) Also suggested: driverless
Here's what I get this year:

wooledg:~$ driverless
ipp://Canon%20LBP712Cdn%20(db%3Ac0%3Ad3)._ipp._tcp.local/

That's all.  And no, that's not the right printer.  That's the one
that has the right model number, but isn't *mine*.  I can only imagine
it's somewhere else on this floor, and that someone is very confused
upon seeing income tax forms coming out of it.

4) Also mentioned: port 9100.
For grins, I did "telnet 10.76.172.100 9100" and after that connected
I typed "HELLO WORLD", then pressed Enter, then Ctrl-] q Enter to
close the telnet session.

That actually printed the words HELLO WORLD on a sheet of paper.

So the printer WORKS.  It is ON THE NETWORK.  I can print TEXT to it
using port 9100.

What I CANNOT do is find it in CUPS.  Or avahi-browse, or driverless, or
any of these other commands that are so allegedly wonderful.

Is there any way I can tell CUPS "Please set up a queue for a printer
whose IP address is 10.76.172.100 even though you can't discover it with
your fancy tools"?

Or do I need to use a Windows PC/Laptop to print this stupid form?

Oh, and if it's any help, here's everything that's on the piece of paper
attached to the printer (I took a picture of it with a cell phone, and
carried the phone back to my desk so I can type it all out):

D#: D14841
P#:
IP: 10.76.172.100
Queue \\SPS\S010NEURD14841M
Model # Canon LBP712Cdn
Serial # NGDA008248
Bldg: S
Flr: 10
Zone: Main
Room: 007
Epic ID
Notes B9754

My burning hatred of printers and this printing system remains unquenched.


HI,

I use ftp to send postscript files to my Lexmark printer.  I am not sure 
cups is even installed.  You might also try netcat since you have the ip 
address of the printer.

Best regards,
Fred

Re: CUPS - how to match autodetected printers to physical ones

[tomas]

On Thu, Feb 16, 2023 at 10:41:33AM -0500, Greg Wooledge wrote:

[...]

> 4) Also mentioned: port 9100.
>For grins, I did "telnet 10.76.172.100 9100" and after that connected
>I typed "HELLO WORLD", then pressed Enter, then Ctrl-] q Enter to
>close the telnet session.
> 
>That actually printed the words HELLO WORLD on a sheet of paper.

\o/

Just for kicks: have you tried sending a PS (or *gasp* PDF) file
down that alley (e.g. with socat)?

For That One Form in the Year this might be just sufficient...

Hint: start with a small one :)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: CUPS - how to match autodetected printers to physical ones

[Greg Wooledge]

It's tax season again, so once again I am putting myself through the
utter hell that is attempting to print my city's Income Tax Forms.

(Yes, this is mandatory.  No, they do not accept electronic submissions.
You must use paper and ink.  Yes, they require you to print your own
forms.  No, they will not mail you a form.)

Whatever I managed to do last year... it's not working this year.  I can
only assume that my workplace's lovely IT department has taken even more
drastic steps in their eternal war against anything that isn't blessed
by Microsoft, and isn't under their control.

When I tried to print this year's tax form to my local printer, I learned
that the default print queue I had set up last year is no longer there.

This led to a complete rerun of everything from last year -- going up to
the printer, looking at the piece of paper attached to the front of it
which has the IP address (same one -- 10.76.172.100), attempting to
find a queue in CUPS which matches up with that, sending print jobs to
what *appears* to be the correct printer, having no paper come out, etc.

Eventually I unearthed this thread, which had some advice which worked
in the past.

It is not working today.

Here's a run-down:

1) Someone suggested: avahi-discover -r _print-caps._tcp
   When I tried it last year, it simply hung with no visible output
   until Ctrl-C'ed.

   This year, I ran it while physically present in the workplace, so now
   I know why it hangs.  It pops up an X11 window.  Only after you close
   that X11 window does it print results on the terminal.

   That's extremely difficult to detect or deal with when you're ssh-ing
   in, running commands in a screen session.

2) Also suggested: avahi-browse -rt _ipp._tcp
   This year, the output of that command no longer contains my printer's
   IP address.  Last year, it did.  I have no idea why this has changed.

3) Also suggested: driverless
   Here's what I get this year:

   wooledg:~$ driverless
   ipp://Canon%20LBP712Cdn%20(db%3Ac0%3Ad3)._ipp._tcp.local/

   That's all.  And no, that's not the right printer.  That's the one
   that has the right model number, but isn't *mine*.  I can only imagine
   it's somewhere else on this floor, and that someone is very confused
   upon seeing income tax forms coming out of it.

4) Also mentioned: port 9100.
   For grins, I did "telnet 10.76.172.100 9100" and after that connected
   I typed "HELLO WORLD", then pressed Enter, then Ctrl-] q Enter to
   close the telnet session.

   That actually printed the words HELLO WORLD on a sheet of paper.

So the printer WORKS.  It is ON THE NETWORK.  I can print TEXT to it
using port 9100.

What I CANNOT do is find it in CUPS.  Or avahi-browse, or driverless, or
any of these other commands that are so allegedly wonderful.

Is there any way I can tell CUPS "Please set up a queue for a printer
whose IP address is 10.76.172.100 even though you can't discover it with
your fancy tools"?

Or do I need to use a Windows PC/Laptop to print this stupid form?

Oh, and if it's any help, here's everything that's on the piece of paper
attached to the printer (I took a picture of it with a cell phone, and
carried the phone back to my desk so I can type it all out):

D#: D14841
P#:
IP: 10.76.172.100
Queue \\SPS\S010NEURD14841M
Model # Canon LBP712Cdn
Serial # NGDA008248
Bldg: S
Flr: 10
Zone: Main
Room: 007
Epic ID
Notes B9754

My burning hatred of printers and this printing system remains unquenched.

Re: CUPS printer on Debian 11.6

[Brian]

On Sun 05 Feb 2023 at 20:52:42 +, Russell L. Harris wrote:

> Fresh installation of Debian 11.6 on Dell Vostro 200 (Intel Core 2).
> 
> The Vostro 200 is being added to a home LAN with Debian 11.6 running
> on a nondescript desktop (amd64) and a HP Laserjet P3015 Postscript
> (Ethernet).  The amd64 machine works perfectly with the P3015.
> 
> The printer configuration on both machines appears identical:
> 
>DRIVER: HP LaserJet Series PCL 6 CUPS (grayscale)
>Connection:  socket://192.168.1.211:9100
> 
> (1) The printer installs on Vostro 200 but does not print.

Symptoms of not printing? Provide outputs for 'lpstat -t'
and 'lpinfo -v'.
 
> (2) Should I install the P3015 as generic Postscript printer?

Unlikely to have any effect.
 
> (3) I cannot make sense of the new CUPS "driverless" scheme.
> Does it make my Postscript printers obsolete?

No.

-- 
Brian.

Re: CUPS printer on Debian 11.6

[john doe]

On 2/5/23 21:52, Russell L. Harris wrote:

Fresh installation of Debian 11.6 on Dell Vostro 200 (Intel Core 2).

The Vostro 200 is being added to a home LAN with Debian 11.6 running
on a nondescript desktop (amd64) and a HP Laserjet P3015 Postscript
(Ethernet).  The amd64 machine works perfectly with the P3015.

The printer configuration on both machines appears identical:

    DRIVER: HP LaserJet Series PCL 6 CUPS (grayscale)
    Connection:  socket://192.168.1.211:9100

(1) The printer installs on Vostro 200 but does not print.

(2) Should I install the P3015 as generic Postscript printer?

(3) I cannot make sense of the new CUPS "driverless" scheme.
Does it make my Postscript printers obsolete?





You might have better luck on the Cups mailing list! ;^)

--
John Doe

CUPS printer on Debian 11.6

[Russell L. Harris]

Fresh installation of Debian 11.6 on Dell Vostro 200 (Intel Core 2).

The Vostro 200 is being added to a home LAN with Debian 11.6 running
on a nondescript desktop (amd64) and a HP Laserjet P3015 Postscript
(Ethernet).  The amd64 machine works perfectly with the P3015.

The printer configuration on both machines appears identical:

   DRIVER: HP LaserJet Series PCL 6 CUPS (grayscale)
   
   Connection:  socket://192.168.1.211:9100


(1) The printer installs on Vostro 200 but does not print.

(2) Should I install the P3015 as generic Postscript printer?

(3) I cannot make sense of the new CUPS "driverless" scheme.
Does it make my Postscript printers obsolete?



--
He turneth rivers into a wilderness, and the watersprings into dry
ground; a fruitful land into barrenness, for the wickedness of them
that dwell therein. - Psalm 107:33-34

[Résolu] soucis avec cups

[Jean-Marc]

Le 13/01/23 à 12:55, NoSpam a écrit :

Pas étonnant que cela tombe en panne. sid reste sid


Et bien, non, ce n'était pas la cause du soucis.

En passant en mode debug, j'ai vu ces messages dans le fichier error.log :
D [13/Jan/2023:12:14:22 +0100] [Job 982] Printer credentials: 
192.168.1.57 (issued by SEIKO EPSON CORP.) / Sat, 08 Jan 2033 18:57:58 
GMT / RSA-SHA1 / 9643B28F917E30AB1969EE67366CF068
D [13/Jan/2023:12:14:22 +0100] [Job 982] Stored credentials: 192.168.0.2 
(issued by SEIKO EPSON CORP.) / Fri, 30 Dec 2022 00:00:00 GMT / RSA-SHA1 
/ D89D66587AE24B3617A6D8C54F5446D2
D [13/Jan/2023:12:14:22 +0100] [Job 982] update_reasons(attr=0(), 
s=\"-cups-pki-invalid,cups-pki-changed,cups-pki-expired,cups-pki-unknown\")
D [13/Jan/2023:12:14:22 +0100] [Job 982] update_reasons(attr=0(), 
s=\"+cups-pki-invalid\")

D [13/Jan/2023:12:14:22 +0100] [Job 982] STATE: +cups-pki-invalid

Apparement, cups stocke des certificats en local.

Un tour rapide dans /etc/cups/ssl et je trouve un fichier 
EPSON4ECDE5.local.crt.  Je l'ai gzippé, relancé une impression et ...


Ça fonctionne à nouveau !

Et cups a stocké un nouveau certificat pour mon imprimante.

C'est très tordu, documenté nulle part, aucunement indiqué par cups dans 
un fichier de log.


Merci à Didier pour sa tentative d'aide.

Allez, bonne journée à toutes et à tous !

--
Jean-Marc


OpenPGP_signature
Description: OpenPGP digital signature

Re: soucis avec cups

[didier gaumet]

Bonjour ou avahi ;-)

regarde si tu n'as pas un paramétrage de cette imprimante qui la stoppe
après une tentative d'impression ratée (printer-error-policy=stop-
printer), il me semble même que c'est le comportement par défaut (de
mémoire, et elle n'est pas fantastique). ça ne t'expliquera pas
pourquoi l'impression se plante mais ça ne stoppera plus l'imprimante
pour ça. Pour avopir plus de détails dans le log relatifs au planatge,
tu peux activer momentanément le debugging (cupsctl --debug-logging)

cf https://www.cups.org/doc/admin.html

Re: soucis avec cups

[NoSpam]

Le 13/01/2023 à 12:40, Jean-Marc a écrit :



Le 13/01/23 à 10:18, NoSpam a écrit :

Bonjour.

Quelle version Debian ? testing ? Sid ?


Debian sid
cups 2.4.2-1+b2

Pas étonnant que cela tombe en panne. sid reste sid


J'ai le problème depuis des années avec une Samsung, ce qui 
fonctionne sans soucis c'est socket:// comme connexion


Tu configures ça comment dans cups ?

AppSocket

Re: soucis avec cups

[Jean-Marc]

Le 13/01/23 à 10:18, NoSpam a écrit :

Bonjour.

Quelle version Debian ? testing ? Sid ?


Debian sid
cups 2.4.2-1+b2

J'ai le problème depuis des années avec une Samsung, ce qui fonctionne 
sans soucis c'est socket:// comme connexion


Tu configures ça comment dans cups ?

--
Jean-Marc


OpenPGP_signature
Description: OpenPGP digital signature

Re: soucis avec cups

[NoSpam]

Bonjour.

Quelle version Debian ? testing ? Sid ?

J'ai le problème depuis des années avec une Samsung, ce qui fonctionne 
sans soucis c'est socket:// comme connexion


Le 13/01/2023 à 10:00, Jean-Marc a écrit :

salut la liste,

J'ai un gros soucis avec cups.

Impossible d'envoyer quoi que ce soit à mon imprimante.

En résumé, j'ai plusieurs PCs avec Debian sid et une imprimante epson 
wf-3640 branchée sur le réseau.
Cette imprimante s'annonce sur le réseau via le protocole bonjour et 
est détectée par avahi.
Elle est ensuite configurée de manière automatique par cups qui 
supporte de manière native le protocole IPP utilisé dans ce cas.

Tout cela a fonctionne parfaitement jusqu'il y a peu.

Depuis quelques jours, quand j'essaie d'imprimer quelque chose, cups 
bascule l'imprimante en disable.


Je peux la remettre en enable tant que je veux, cups la passe tout le 
temps en disable.


Pour savoir si c'est l'imprimante ou la communication entre 
l'imprimante et le PC qui posent problème, j'ai utilisé l'outil 
ipptool (cf. paquet https://packages.debian.org/sid/ippsample) et là, 
pas de soucis.  Je peux envoyer des fichiers à l'imprimante qui a 
fonctionne normalement.


Je vais essayer de montrer, par l'exemple, ce qu'il se passe.

Avant d'allumer l'imprimante, un lpstat ne donne rien; normal :

jim@deb-sid:~$ lpstat -t
scheduler is running
no system default destination
lpstat: Aucune destination ajoutée.
lpstat: Aucune destination ajoutée.
lpstat: Aucune destination ajoutée.
lpstat: Aucune destination ajoutée.

Dès que l'imprimante est démarrée et que le système l'a détectée, elle 
est reconnue et configurée :


jim@deb-sid:~$ lpstat -t
scheduler is running
system default destination: EPSON_WF_3640_Series
matériel pour EPSON_WF_3640_Series : 
implicitclass://EPSON_WF_3640_Series/

EPSON_WF_3640_Series accepte des requêtes depuis ven 13 jan 2023 08:26:40
printer EPSON_WF_3640_Series is idle.  enabled since ven 13 jan 2023 
08:26:40


Le simple envoi d'un fichier la fait  basculer en statut disable :

jim@deb-sid:~$ lp fichier.txt
request id is EPSON_WF_3640_Series-981 (1 file(s))
jim@deb-sid:~$ lpstat -t
scheduler is running
system default destination: EPSON_WF_3640_Series
matériel pour EPSON_WF_3640_Series : 
implicitclass://EPSON_WF_3640_Series/

EPSON_WF_3640_Series accepte des requêtes depuis ven 13 jan 2023 08:26:59
printer EPSON_WF_3640_Series disabled since ven 13 jan 2023 08:26:59 -
cause inconnue
EPSON_WF_3640_Series-981 jim   3072   ven 13 jan 2023 
08:26:58



Je peux dire à cups de la remettre dispo, ça ne marche pas :

jim@deb-sid:~$ cupsenable  EPSON_WF_3640_Series
jim@deb-sid:~$ lpstat -t
scheduler is running
system default destination: EPSON_WF_3640_Series
matériel pour EPSON_WF_3640_Series : 
implicitclass://EPSON_WF_3640_Series/

EPSON_WF_3640_Series accepte des requêtes depuis ven 13 jan 2023 08:27:22
printer EPSON_WF_3640_Series disabled since ven 13 jan 2023 08:27:22 -
cause inconnue
EPSON_WF_3640_Series-981 jim   3072   ven 13 jan 2023 
08:26:58


Les fichiers de log de cups montre que l'envoi de la commande pour 
remettre l'imprimante dispo semble fonctionner mais elle bascule en 
disable à chaque fois :


jim@deb-sid:~$ cd /var/log/cups/ && tail -f access.log error.log
[...]
==> access_log <==
localhost - - [13/Jan/2023:08:29:03 +0100] "POST /admin/ HTTP/1.1" 401 
164 Resume-Printer successful-ok
localhost - jim [13/Jan/2023:08:29:03 +0100] "POST /admin/ HTTP/1.1" 
200 164 Resume-Printer successful-ok
localhost - root [13/Jan/2023:08:29:03 +0100] "POST /admin/ HTTP/1.1" 
200 279 CUPS-Add-Modify-Printer successful-ok


==> error_log <==
W [13/Jan/2023:08:29:03 +0100] [Job 981] Backend returned status 4 
(stop printer)


==> access_log <==
localhost - - [13/Jan/2023:08:29:14 +0100] "POST /admin/ HTTP/1.1" 401 
164 Resume-Printer successful-ok
localhost - jim [13/Jan/2023:08:29:14 +0100] "POST /admin/ HTTP/1.1" 
200 164 Resume-Printer successful-ok
localhost - root [13/Jan/2023:08:29:14 +0100] "POST /admin/ HTTP/1.1" 
200 279 CUPS-Add-Modify-Printer successful-ok


==> error_log <==
W [13/Jan/2023:08:29:14 +0100] [Job 981] Backend returned status 4 
(stop printer)


==> access_log <==
localhost - - [13/Jan/2023:08:29:42 +0100] "POST /admin/ HTTP/1.1" 401 
164 Resume-Printer successful-ok
localhost - jim [13/Jan/2023:08:29:42 +0100] "POST /admin/ HTTP/1.1" 
200 164 Resume-Printer successful-ok
localhost - root [13/Jan/2023:08:29:42 +0100] "POST /admin/ HTTP/1.1" 
200 279 CUPS-Add-Modify-Printer successful-ok


==> error_log <==
W [13/Jan/2023:08:29:43 +0100] [Job 981] Backend returned status 4 
(stop printer)


Si je vire le job d'impression et que je remets l'imprimante en 
enable, elle va y rester jusqu'à la prochaine impression :


jim@deb-sid:~$ lprm 981
jim@deb-sid:~$ cupsenable  EPSON_WF_3640_Series
jim@deb-sid:

soucis avec cups

[Jean-Marc]

salut la liste,

J'ai un gros soucis avec cups.

Impossible d'envoyer quoi que ce soit à mon imprimante.

En résumé, j'ai plusieurs PCs avec Debian sid et une imprimante epson 
wf-3640 branchée sur le réseau.
Cette imprimante s'annonce sur le réseau via le protocole bonjour et est 
détectée par avahi.
Elle est ensuite configurée de manière automatique par cups qui supporte 
de manière native le protocole IPP utilisé dans ce cas.

Tout cela a fonctionne parfaitement jusqu'il y a peu.

Depuis quelques jours, quand j'essaie d'imprimer quelque chose, cups 
bascule l'imprimante en disable.


Je peux la remettre en enable tant que je veux, cups la passe tout le 
temps en disable.


Pour savoir si c'est l'imprimante ou la communication entre l'imprimante 
et le PC qui posent problème, j'ai utilisé l'outil ipptool (cf. paquet 
https://packages.debian.org/sid/ippsample) et là, pas de soucis.  Je 
peux envoyer des fichiers à l'imprimante qui a fonctionne normalement.


Je vais essayer de montrer, par l'exemple, ce qu'il se passe.

Avant d'allumer l'imprimante, un lpstat ne donne rien; normal :

jim@deb-sid:~$ lpstat -t
scheduler is running
no system default destination
lpstat: Aucune destination ajoutée.
lpstat: Aucune destination ajoutée.
lpstat: Aucune destination ajoutée.
lpstat: Aucune destination ajoutée.

Dès que l'imprimante est démarrée et que le système l'a détectée, elle 
est reconnue et configurée :


jim@deb-sid:~$ lpstat -t
scheduler is running
system default destination: EPSON_WF_3640_Series
matériel pour EPSON_WF_3640_Series : implicitclass://EPSON_WF_3640_Series/
EPSON_WF_3640_Series accepte des requêtes depuis ven 13 jan 2023 08:26:40
printer EPSON_WF_3640_Series is idle.  enabled since ven 13 jan 2023 
08:26:40


Le simple envoi d'un fichier la fait  basculer en statut disable :

jim@deb-sid:~$ lp fichier.txt
request id is EPSON_WF_3640_Series-981 (1 file(s))
jim@deb-sid:~$ lpstat -t
scheduler is running
system default destination: EPSON_WF_3640_Series
matériel pour EPSON_WF_3640_Series : implicitclass://EPSON_WF_3640_Series/
EPSON_WF_3640_Series accepte des requêtes depuis ven 13 jan 2023 08:26:59
printer EPSON_WF_3640_Series disabled since ven 13 jan 2023 08:26:59 -
cause inconnue
EPSON_WF_3640_Series-981 jim   3072   ven 13 jan 2023 08:26:58


Je peux dire à cups de la remettre dispo, ça ne marche pas :

jim@deb-sid:~$ cupsenable  EPSON_WF_3640_Series
jim@deb-sid:~$ lpstat -t
scheduler is running
system default destination: EPSON_WF_3640_Series
matériel pour EPSON_WF_3640_Series : implicitclass://EPSON_WF_3640_Series/
EPSON_WF_3640_Series accepte des requêtes depuis ven 13 jan 2023 08:27:22
printer EPSON_WF_3640_Series disabled since ven 13 jan 2023 08:27:22 -
cause inconnue
EPSON_WF_3640_Series-981 jim   3072   ven 13 jan 2023 08:26:58

Les fichiers de log de cups montre que l'envoi de la commande pour 
remettre l'imprimante dispo semble fonctionner mais elle bascule en 
disable à chaque fois :


jim@deb-sid:~$ cd /var/log/cups/ && tail -f access.log error.log
[...]
==> access_log <==
localhost - - [13/Jan/2023:08:29:03 +0100] "POST /admin/ HTTP/1.1" 401 
164 Resume-Printer successful-ok
localhost - jim [13/Jan/2023:08:29:03 +0100] "POST /admin/ HTTP/1.1" 200 
164 Resume-Printer successful-ok
localhost - root [13/Jan/2023:08:29:03 +0100] "POST /admin/ HTTP/1.1" 
200 279 CUPS-Add-Modify-Printer successful-ok


==> error_log <==
W [13/Jan/2023:08:29:03 +0100] [Job 981] Backend returned status 4 (stop 
printer)


==> access_log <==
localhost - - [13/Jan/2023:08:29:14 +0100] "POST /admin/ HTTP/1.1" 401 
164 Resume-Printer successful-ok
localhost - jim [13/Jan/2023:08:29:14 +0100] "POST /admin/ HTTP/1.1" 200 
164 Resume-Printer successful-ok
localhost - root [13/Jan/2023:08:29:14 +0100] "POST /admin/ HTTP/1.1" 
200 279 CUPS-Add-Modify-Printer successful-ok


==> error_log <==
W [13/Jan/2023:08:29:14 +0100] [Job 981] Backend returned status 4 (stop 
printer)


==> access_log <==
localhost - - [13/Jan/2023:08:29:42 +0100] "POST /admin/ HTTP/1.1" 401 
164 Resume-Printer successful-ok
localhost - jim [13/Jan/2023:08:29:42 +0100] "POST /admin/ HTTP/1.1" 200 
164 Resume-Printer successful-ok
localhost - root [13/Jan/2023:08:29:42 +0100] "POST /admin/ HTTP/1.1" 
200 279 CUPS-Add-Modify-Printer successful-ok


==> error_log <==
W [13/Jan/2023:08:29:43 +0100] [Job 981] Backend returned status 4 (stop 
printer)


Si je vire le job d'impression et que je remets l'imprimante en enable, 
elle va y rester jusqu'à la prochaine impression :


jim@deb-sid:~$ lprm 981
jim@deb-sid:~$ cupsenable  EPSON_WF_3640_Series
jim@deb-sid:~$ lpstat -t
scheduler is running
system default destination: EPSON_WF_3640_Series
matériel pour EPSON_WF_3640_Series : implicitclass://EPSON_WF_3640_Series/
EPSON_WF_3640_Series accepte des requêtes depuis ven 13 jan 2