Mike Spencer <mds@bogus.nodomain.nowhere> wrote:
> Now venturing to migrate from lprng to CUPS.
> Before I've even read how to start, there seems to be something I
> don't understand about inetd and LAN networking.
> Cups man page says:
> WHERE DO I BEGIN?
> The easiest way to start is by using the web interface to
> configure your printer. Go to "http://localhost:631" and choose
> the Administration tab at the top of the page.
> Okay, but I want to access that (on enoch, the new 15 install box)
> from bogus, my current 14.2 main machine. Try http://enoch:631.
> The connection was refused when attempting to contact enoch:631
> I haven't started ip_tables yet so no firewall.
> cupsd is running:
> enoch% pgrep cupsd
> 1055
> I've tried changing /etc/cups/cupsd.conf and /etc/inetd.conf in
> various ways (and restarting inetd or cupsd after any change) with no
> improvements.
> cupsd.conf:
> # Only listen for connections from the local machine.
> Listen localhost:631
> Listen /var/run/cups/cups.sock
> # mds -- Also listen for conns from bogus;
> Listen 192.168.0.15:631
> Using any of ip address (above), hostname (bogus) or * gives same
> non-result. Moreover, the cupsd.conf directive to listen doesn't show
> up in lsof:
> enoch-root$ lsof -i:631 -sTCP:LISTEN
> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
> cupsd 1055 root 5u IPv6 32275 0t0 TCP localhost:ipp (LISTEN)
> cupsd 1055 root 6u IPv4 32276 0t0 TCP localhost:ipp (LISTEN)
> What about inetd? Adding to /etc/inetd.conf a line like:
> ipp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/cupsd
> doesn't make any difference.
> It seems I'm trying to do something that can't be done. Or that needs
> a magic incantation I don't know about. Can I access cupsd:631 on
> enoch from bogus over the LAN? Or not?
> TIA for any help.

Can't offer any explicit advice, but what kind of printer do you have???
I have several Brother printer models, and the brother homepage has
linux install scripts for all of them that work flawlessly with cups.
Just make sure /etc/rc.d/rc.cups has start'ed, turn on your printer
and make sure it's connected (presumably by wifi nowadays), and then
run the script. The necessary /etc/cups/, /usr/share/cups/, etc gets
automatically edited as needed, and the printers "just work" afterwards.
Not sure what similar linux install scripts other printer manufacturers
provide. But I'd suggest googling around for that first.
--
John Forkosh ( mailto: j@f.com where j=john and f=forkosh )

Am 20.02.2023 schrieb Mike Spencer <mds@bogus.nodomain.nowhere>:

> I gave up on postfix and reverted with complete success to sendmail.

:-)

> cupsd.conf:
>
> # Only listen for connections from the local machine.
> Listen localhost:631
> Listen /var/run/cups/cups.sock
>
> # mds -- Also listen for conns from bogus;
> Listen 192.168.0.15:631
>
>
> Using any of ip address (above), hostname (bogus) or * gives same
> non-result. Moreover, the cupsd.conf directive to listen doesn't show
> up in lsof:
>
> enoch-root$ lsof -i:631 -sTCP:LISTEN
>
> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
> cupsd 1055 root 5u IPv6 32275 0t0 TCP localhost:ipp
> (LISTEN) cupsd 1055 root 6u IPv4 32276 0t0 TCP
> localhost:ipp (LISTEN)
>
> What about inetd? Adding to /etc/inetd.conf a line like:
>
> ipp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/cupsd
>
> doesn't make any difference.

Use either cups itself OR inetd - not both at the same time.

I recommend using CUPS directly if possible.
Please configure and restart the service and run "ss -lutn"

Mike Spencer <mds@bogus.nodomain.nowhere> wrote:
> cupsd.conf:
>
> # Only listen for connections from the local machine.
> Listen localhost:631
> Listen /var/run/cups/cups.sock
>
> # mds -- Also listen for conns from bogus;
> Listen 192.168.0.15:631
>
>
> Using any of ip address (above), hostname (bogus) or * gives same
> non-result. Moreover, the cupsd.conf directive to listen doesn't show
> up in lsof:
>

man cupsd.conf

From cupsd.conf(5):

The Listen directive is similar to the Port directive but
allows you to restrict access to specific interfaces or networks.

So I would use the Port directive instead, and delete all the Listen directives.

Port 631

Marco Moock <mo01@posteo.de> wrote:
> Am 20.02.2023 schrieb Mike Spencer <mds@bogus.nodomain.nowhere>:
>
>> I gave up on postfix and reverted with complete success to sendmail.
>
> :-)

I wonder whether the OP wants to run a mail server himself or he
relies on an external SMTP server. Running an mailserver nowadays is
not so easy nowadays, as many mailservers (especially those controlled
by MS like Yahoo or corporate Exchange servers) will drop the received
messages without warning for the silliest reason.

If he relies on an external SMTP server an userland based solution like
ssmtp should be easier

Javier <invalid@invalid.invalid> writes:

> Marco Moock <mo01@posteo.de> wrote:
>
> > Am 20.02.2023 schrieb Mike Spencer <mds@bogus.nodomain.nowhere>:
>>
>>> I gave up on postfix and reverted with complete success to sendmail.
>>
>> :-)
>
> I wonder whether the OP wants to run a mail server himself or he
> relies on an external SMTP server. Running an mailserver nowadays is
> not so easy nowadays, as many mailservers (especially those controlled
> by MS like Yahoo or corporate Exchange servers) will drop the received
> messages without warning for the silliest reason.

No, no, I don't want to run a mail server.

Just nattering, for the record, if anyone is interested...

I only need three things from sendmail:

1. Hand outgoing mail to a smarthost that requires AUTH (the
deafult)

2. Occasionally hand outgoing mail to a different smarthost that
doesn't require AUTH.

3. Deliver mail from the kernel to root to a mailbox on localhost.

I get 1. & 2. by having 2 sets of files for /etc/mail/*, one
configured for 1., the other configured for 2. If the the server for
1. is down, I can swap those files and restart sendmail.

3. seems to happen automatically without my having to do anything.

Setting up smarthosting, long ago, was so easy that I just manually
edited sendmail.cf before I knew you weren't supposed to do that.
Enabling AUTH was harder but I had earlier invested in the great, fat
O'Reilly Bat Book and could figure it out, use m4.

So sendmail is a Winnebago with all the dealer options, a Zodiac on
the roof, dirt bike strapped to the back and a 2-door Hyundai in tow.
And the config is written in cuneiform that you need a Rosetta stone
(m4) to deal with it.

Postfix is supposed to be better and easier. My take is that it's
also A Winnebago, but without the dealer options or Zodiac. To
stretch the metaphor, the config is written in Chaucerian English so
you only need hours of study, not a Rosetta stone, to sort out and
disable all the details and features meant for a full-on SMTP server
and get just the simple behavior above.

Worse, documentation is in numerous files. And there's no Bat Book.

> If he relies on an external SMTP server an userland based solution like
> ssmtp should be easier

Maybe. More bother? Sendmail is doing what I want in 15.0.

(Back to my problem with CUPS later, in another post.)

--
Mike Spencer Nova Scotia, Canada

On 2/21/23 4:50 PM, Mike Spencer wrote:
> 1. Hand outgoing mail to a smarthost that requires AUTH (the deafult)

This may become more of a problem as more and more providers are
disabling traditional authentication methods, including SMTP Auth that
you're talking about, in favor of OAUTH.

I'm not aware of any MTA supporting this on smart hosts. Perhaps they
do and I'm just ignorant of it.

--
Grant. . . .
unix || die

On 2/21/23 00:29, Mike Spencer wrote:

> It seems I'm trying to do something that can't be done. Or that needs
> a magic incantation I don't know about. Can I access cupsd:631 on
> enoch from bogus over the LAN? Or not?
>

Yes, you can, although if you do not have a browser that runs on enoch
it may be a nightmare.

Best way is to start http://localhost:631 on enoch and follow the
instructions to configure the printer leaving as required step to check
'Allow remote administration' and 'Share printers connected to this
system' on the main 'Administration' page. After that the printer will
be 'http://enoch:631/' from any machine on LAN.

I have a server without X services (it does non even have a display,
only ssh access). With older versions of cups I could use lynx but now
cups uses java scripts and the only method is the command line interface
and a few tweaks to the configuration file to insert the the server name.

If you cannot use a browser you need to use same method using command
line interface. Involved are 'lpadmin' and 'lpoptions' and their
options. Remember that encryption does not work in latest version (at
least on my machines).

## Create default printer
lpadmin -p ml1210 -v "http://milena.home.net.it:631/printers/raw" -D
"Samsung ML-1210 Laser Printer" -L "Local at MONICA" -P
"/etc/cups/Samsung-ML-1210-gdi.ppd"
lpadmin -p ml1210 -o printer-is-shared=false
lpadmin -d ml1210

## Set as user default
lpoptions -d ml1210
lpoptions -p ml1210 -o media=A4

This is an example to create a printer 'ml1210' that prints to a remote
queue 'raw' a pass-thru queue accessible from LAN. You have to modify
the arguments to your needs

Ciao
Giovanni
--
A computer is like an air conditioner,
it stops working when you open Windows.
< https://giovanni.homelinux.net/ >

Groovy hepcat Mike Spencer was jivin' in alt.os.linux.slackware on Tue,
21 Feb 2023 10:29 am. It's a cool scene! Dig it.

> Cups man page says:
>
> WHERE DO I BEGIN?
>
> The easiest way to start is by using the web interface to
> configure your printer. Go to "http://localhost:631" and choose
> the Administration tab at the top of the page.
>
> Okay, but I want to access that (on enoch, the new 15 install box)
> from bogus, my current 14.2 main machine. Try http://enoch:631.

And can you ping enoch? You don't need a FQDN (enoch.private or
enoch.mynet or something like that)?

> The connection was refused when attempting to contact enoch:631
>
> I haven't started ip_tables yet so no firewall.
>
> cupsd is running:
>
> enoch% pgrep cupsd
> 1055
>
> I've tried changing /etc/cups/cupsd.conf and /etc/inetd.conf in
> various ways (and restarting inetd or cupsd after any change) with no
> improvements.
>
> cupsd.conf:
>
> # Only listen for connections from the local machine.
> Listen localhost:631
> Listen /var/run/cups/cups.sock
>
> # mds -- Also listen for conns from bogus;
> Listen 192.168.0.15:631

The only Listen line my cupsd.conf has is the cups.sock one. It also
has a Port line:

Port 631

Does yours have that?

> Using any of ip address (above), hostname (bogus) or * gives same
> non-result. Moreover, the cupsd.conf directive to listen doesn't show
> up in lsof:
>
> enoch-root$ lsof -i:631 -sTCP:LISTEN
>
> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
> cupsd 1055 root 5u IPv6 32275 0t0 TCP localhost:ipp
> (LISTEN)
> cupsd 1055 root 6u IPv4 32276 0t0 TCP localhost:ipp
> (LISTEN)
>
> What about inetd? Adding to /etc/inetd.conf a line like:
>
> ipp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/cupsd

I don't have any reference to cups or printing at all in my
inetd.conf.

> doesn't make any difference.
>
> It seems I'm trying to do something that can't be done. Or that needs
> a magic incantation I don't know about. Can I access cupsd:631 on
> enoch from bogus over the LAN? Or not?

Sure you can. I find cups a bit persnickety, though, especially about
network hostnames. When I try to print using my server's hostname in
the client setup, it often doesn't work. But if I use the IP address,
it has a much higher chance of success.
Yes, I know, you haven't even got to that stage yet. You're still
trying to configure the server itself. But anyhow...
Still, just now, for a test, I tried accessing my cups server by
hostname with firefox, and it failed with "Bad request". So I tried
again using the IP address instead, and it worked perfectly.

> I have to go make ginger chicken.

Who's this Ginger? If I see him/her running in terror, I'll know you
were successful.

--

----- Dig the NEW and IMPROVED news sig!! -----

-------------- Shaggy was here! ---------------
Ain't I'm a dawg!!

Groovy hepcat Rich was jivin' in alt.os.linux.slackware on Tue, 21 Feb
2023 01:55 pm. It's a cool scene! Dig it.

> ethernet interface as well. And, what is the IP address you have on
> the second Listen? The IP that goes there would need to be the IP of
> the machine the cupsd was running on, not the IP the connections would
> be coming from.

Technically, it's the IP address of the /interface/, not the whole
machine. The computer doesn't have an address; the network interface
does.

--

----- Dig the NEW and IMPROVED news sig!! -----

-------------- Shaggy was here! ---------------
Ain't I'm a dawg!!

Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> wrote:
> Groovy hepcat Rich was jivin' in alt.os.linux.slackware on Tue, 21 Feb
> 2023 01:55 pm. It's a cool scene! Dig it.
>
>> ethernet interface as well. And, what is the IP address you have on
>> the second Listen? The IP that goes there would need to be the IP of
>> the machine the cupsd was running on, not the IP the connections would
>> be coming from.
>
> Technically, it's the IP address of the /interface/, not the whole
> machine. The computer doesn't have an address; the network interface
> does.

While true, I doubt the OP has a multi-interface machine such that the
distinction would have done any good besides add to his confusion.