Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #177141 > unrolled thread

CUPS in stretch Ricoh printer SP112 SP112-su

Started byroba@openmailbox.org
First post2017-01-30 22:50 +0100
Last post2017-02-04 03:00 +0100
Articles 20 on this page of 30 — 6 participants

Back to article view | Back to linux.debian.user


Contents

  CUPS in stretch Ricoh printer SP112 SP112-su roba@openmailbox.org - 2017-01-30 22:50 +0100
    Re: CUPS in stretch Ricoh printer SP112 SP112-su Mark Fletcher <mark27q1@gmail.com> - 2017-01-31 00:00 +0100
      Re: CUPS in stretch Ricoh printer SP112 SP112-su Brian <ad44@cityscape.co.uk> - 2017-01-31 00:10 +0100
    Re: CUPS in stretch Ricoh printer SP112 SP112-su roba@openmailbox.org - 2017-01-31 00:40 +0100
      Re: CUPS in stretch Ricoh printer SP112 SP112-su Brian <ad44@cityscape.co.uk> - 2017-01-31 10:30 +0100
        Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su roba@openmailbox.org - 2017-01-31 23:20 +0100
          Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su Brian <ad44@cityscape.co.uk> - 2017-02-01 00:10 +0100
          Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su roba@openmailbox.org - 2017-02-01 00:50 +0100
            Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su Brian <ad44@cityscape.co.uk> - 2017-02-01 01:00 +0100
            Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su roba@openmailbox.org - 2017-02-01 01:00 +0100
              Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su roba@openmailbox.org - 2017-02-01 01:20 +0100
                Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su Brian <ad44@cityscape.co.uk> - 2017-02-01 11:00 +0100
                  Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su Roba <roba@openmailbox.org> - 2017-02-01 15:20 +0100
                    Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su Brian <ad44@cityscape.co.uk> - 2017-02-01 16:40 +0100
                      Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su Roba <roba@openmailbox.org> - 2017-02-01 23:00 +0100
                        Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su Brian <ad44@cityscape.co.uk> - 2017-02-02 00:30 +0100
                          Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su Brian <ad44@cityscape.co.uk> - 2017-02-02 01:00 +0100
                            Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su Brian <ad44@cityscape.co.uk> - 2017-02-02 21:10 +0100
                              Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su Roba <roba@openmailbox.org> - 2017-02-04 02:30 +0100
                                Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su Roba <roba@openmailbox.org> - 2017-02-04 02:50 +0100
                                  Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su Mark Fletcher <mark27q1@gmail.com> - 2017-02-04 07:00 +0100
                                    Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su Roba <roba@openmailbox.org> - 2017-02-04 13:20 +0100
                                    Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su Brian <ad44@cityscape.co.uk> - 2017-02-04 16:40 +0100
                                      Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su Roba <roba@openmailbox.org> - 2017-02-05 00:10 +0100
                                        Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su Gene Heskett <gheskett@shentel.net> - 2017-02-05 00:50 +0100
                                          Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su Brian <ad44@cityscape.co.uk> - 2017-02-05 01:10 +0100
                                          Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su Roba <roba@openmailbox.org> - 2017-02-05 01:50 +0100
                                            Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su Brian <ad44@cityscape.co.uk> - 2017-02-08 22:00 +0100
                                        Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su Lisi Reisz <lisi.reisz@gmail.com> - 2017-02-23 15:50 +0100
                                Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su Roba <roba@openmailbox.org> - 2017-02-04 03:00 +0100

Page 1 of 2  [1] 2  Next page →


#177141 — CUPS in stretch Ricoh printer SP112 SP112-su

Fromroba@openmailbox.org
Date2017-01-30 22:50 +0100
SubjectCUPS in stretch Ricoh printer SP112 SP112-su
Message-ID<t5rZL-GM-5@gated-at.bofh.it>
I used to try and set up a printer through localhost:631 in Jessie but 
now in stretch it is impossible.  I foung some link about 
/etc/hosts.allow and deny and tried a few things but still no luck.  
Maybe I am not using the correct statement and tried localhost and 
127.0.0.1 but still no luck.
And this is for trying to plug a ppd that was hacked from an other Ricoh 
printer to fit an SP112 SP112-su
I figured what did not work for jessie may work for stretch
I had gotten the same printer to work on an other machine with jessie 
somewhere around 8.5 but not on this one.

Any suggestions on how to reach the blocked :631 link?

[toc] | [next] | [standalone]


#177144

FromMark Fletcher <mark27q1@gmail.com>
Date2017-01-31 00:00 +0100
Message-ID<t5t5v-1iG-13@gated-at.bofh.it>
In reply to#177141
On Mon, Jan 30, 2017 at 10:47:24PM +0100, roba@openmailbox.org wrote:
> I used to try and set up a printer through localhost:631 in Jessie but now
> in stretch it is impossible.  I foung some link about /etc/hosts.allow and
> deny and tried a few things but still no luck.  Maybe I am not using the
> correct statement and tried localhost and 127.0.0.1 but still no luck.
> And this is for trying to plug a ppd that was hacked from an other Ricoh
> printer to fit an SP112 SP112-su
> I figured what did not work for jessie may work for stretch
> I had gotten the same printer to work on an other machine with jessie
> somewhere around 8.5 but not on this one.
> 
> Any suggestions on how to reach the blocked :631 link?
> 

Potentially stupid question -- are you sure the URL is blocked and it's 
not simply that CUPS is not running?

$ ps -ef | grep cups

on my system I get:

root       907     1  0 Jan15 ?        00:00:00 /usr/sbin/cups-browsed
root     31985     1  0 07:35 ?        00:00:00 /usr/sbin/cupsd -f

That is the first possibility to eliminate.

Mark

[toc] | [prev] | [next] | [standalone]


#177146

FromBrian <ad44@cityscape.co.uk>
Date2017-01-31 00:10 +0100
Message-ID<t5tfb-1B3-3@gated-at.bofh.it>
In reply to#177144
On Tue 31 Jan 2017 at 07:54:11 +0900, Mark Fletcher wrote:

> On Mon, Jan 30, 2017 at 10:47:24PM +0100, roba@openmailbox.org wrote:
> > I used to try and set up a printer through localhost:631 in Jessie but now
> > in stretch it is impossible.  I foung some link about /etc/hosts.allow and
> > deny and tried a few things but still no luck.  Maybe I am not using the
> > correct statement and tried localhost and 127.0.0.1 but still no luck.
> > And this is for trying to plug a ppd that was hacked from an other Ricoh
> > printer to fit an SP112 SP112-su
> > I figured what did not work for jessie may work for stretch
> > I had gotten the same printer to work on an other machine with jessie
> > somewhere around 8.5 but not on this one.
> > 
> > Any suggestions on how to reach the blocked :631 link?
> > 
> 
> Potentially stupid question -- are you sure the URL is blocked and it's 
> not simply that CUPS is not running?

It doesn't really matter. Ricoh has the SP 112 down as using the DDST
(whatever that stands for) language to communicate with the device. It
needs a host-based driver on the computer. It is very doubtful there is
a free one in Debian.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]


#177147

Fromroba@openmailbox.org
Date2017-01-31 00:40 +0100
Message-ID<t5tId-1Kd-9@gated-at.bofh.it>
In reply to#177141
On 2017-01-30 22:47, roba@openmailbox.org wrote:
> And this is for trying to plug a ppd that was hacked from an other
> Ricoh printer to fit an SP112 SP112-su
> I figured what did not work for jessie may work for stretch
> I had gotten the same printer to work on an other machine with
> jessie somewhere around 8.5 but not on this one.
> 
> Any suggestions on how to reach the blocked :631 link?

Same printer, not very different AMD64, and based on the hacked ppd 
available on github it worked flawlessly ... I started on 8.6 on this 
one when it was fresh and never got it to work following the same 
procedure.  But localhost:631 worked and the browser hasn't changed much 
(from what I do to it).  I suspect it is running as you say but how do I 
reach it or what is blocking access to it?  Or what do I put in 
host.allow hosts.deny to unblock it if that is the culprit.  And WHY did 
debian change such a thing?  Security security security?  Basic early 
upgrade from stable to testing is the only change that I am responsible 
for.

C:\ ps -ef | grep cups
roots     361     1  0 Jan30 ?        00:00:00 /usr/sbin/cupsd -l
roots     467     1  0 Jan30 ?        00:00:00 /usr/sbin/cups-browsed
rock     6128  6115  0 01:20 pts/2    00:00:00 grep cups
lp      15797   361  0 Jan30 ?        00:00:00 
/usr/lib/cups/notifier/dbus dbus://

C:\    :)

[toc] | [prev] | [next] | [standalone]


#177160

FromBrian <ad44@cityscape.co.uk>
Date2017-01-31 10:30 +0100
Message-ID<t5CVc-7pw-19@gated-at.bofh.it>
In reply to#177147
On Tue 31 Jan 2017 at 00:34:24 +0100, roba@openmailbox.org wrote:

> On 2017-01-30 22:47, roba@openmailbox.org wrote:
> >And this is for trying to plug a ppd that was hacked from an other
> >Ricoh printer to fit an SP112 SP112-su
> >I figured what did not work for jessie may work for stretch
> >I had gotten the same printer to work on an other machine with
> >jessie somewhere around 8.5 but not on this one.
> >
> >Any suggestions on how to reach the blocked :631 link?
> 
> Same printer, not very different AMD64, and based on the hacked ppd
> available on github it worked flawlessly ... I started on 8.6 on this one
> when it was fresh and never got it to work following the same procedure.
> But localhost:631 worked and the browser hasn't changed much (from what I do
> to it).  I suspect it is running as you say but how do I reach it or what is
> blocking access to it?  Or what do I put in host.allow hosts.deny to unblock
> it if that is the culprit.  And WHY did debian change such a thing?
> Security security security?  Basic early upgrade from stable to testing is
> the only change that I am responsible for.
> 
> C:\ ps -ef | grep cups
> roots     361     1  0 Jan30 ?        00:00:00 /usr/sbin/cupsd -l
> roots     467     1  0 Jan30 ?        00:00:00 /usr/sbin/cups-browsed
> rock     6128  6115  0 01:20 pts/2    00:00:00 grep cups
> lp      15797   361  0 Jan30 ?        00:00:00 /usr/lib/cups/notifier/dbus
> dbus://
> 
> C:\    :)

Debian has changed nothing to account for localhost:631 not being
open to you. 'Webinterface No' in cupsd.conf could be a reason for
your experience, but a browser would inform you of this and offer
a solution.

TCP wrappers controls access from other machines on the network,
not from localhost. In any case, cupsd does not use libwrap.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]


#177190 — Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su

Fromroba@openmailbox.org
Date2017-01-31 23:20 +0100
SubjectRe: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su
Message-ID<t5OWl-6cJ-15@gated-at.bofh.it>
In reply to#177160
Well I sure haven't changed anything other than upgrade packages.  Now 
if some other package interferes with cupsd I don't know.  I know I 
spent some days fighting :631 4-5 months ago to get it (the printer) to 
work.  Cups worked fine then.  I have not tried any other printer since.

Obviously there seem to be other people elsewhere that refer to this 
problem.  Losing contact with cups after a stretch upgrade.  The only 
solution I found I listed but either I don't understand the commands or 
it is not working for me.

I even created a new user, run firefox stock 1st time no plugins ... and 
nothing.  Unreachable it says.  No instructions what so ever.  Even sudo 
firefox didn't reach.  NADA!

I think it is ridiculous after so many months to be holding a Win7 
partition to be able to print stuff and it is not the printer problem 
anymore as a previous generic pc of similar specs printed just fine with 
Jessie.  This one is a stock DELL with no sign of hardware 
incompatibility.  Again, I am on LXDE Stretch, AMD64, and it is a USB 
printer, no network stuff.  The printer settings gui identified the 
correct printer and model.  No way to drive it.


>> On 2017-01-30 22:47, roba@openmailbox.org wrote:
>> >And this is for trying to plug a ppd that was hacked from an other
>> >Ricoh printer to fit an SP112 SP112-su
>> >I figured what did not work for jessie may work for stretch
>> >I had gotten the same printer to work on an other machine with
>> >jessie somewhere around 8.5 but not on this one.
>> >
>> >Any suggestions on how to reach the blocked :631 link?
>> 
>> Same printer, not very different AMD64, and based on the hacked ppd
>> available on github it worked flawlessly ... I started on 8.6 on this 
>> one
>> when it was fresh and never got it to work following the same 
>> procedure.
>> But localhost:631 worked and the browser hasn't changed much (from 
>> what I do
>> to it).  I suspect it is running as you say but how do I reach it or 
>> what is
>> blocking access to it?  Or what do I put in host.allow hosts.deny to 
>> unblock
>> it if that is the culprit.  And WHY did debian change such a thing?
>> Security security security?  Basic early upgrade from stable to 
>> testing is
>> the only change that I am responsible for.
>> 
>> C:\ ps -ef | grep cups
>> roots     361     1  0 Jan30 ?        00:00:00 /usr/sbin/cupsd -l
>> roots     467     1  0 Jan30 ?        00:00:00 /usr/sbin/cups-browsed
>> rock     6128  6115  0 01:20 pts/2    00:00:00 grep cups
>> lp      15797   361  0 Jan30 ?        00:00:00 
>> /usr/lib/cups/notifier/dbus
>> dbus://
>> 
>> C:\    :)

> From: Brian <ad44@cityscape.co.uk>

> Debian has changed nothing to account for localhost:631 not being
> open to you. 'Webinterface No' in cupsd.conf could be a reason for
> your experience, but a browser would inform you of this and offer
> a solution.
> 
> TCP wrappers controls access from other machines on the network,
> not from localhost. In any case, cupsd does not use libwrap.

[toc] | [prev] | [next] | [standalone]


#177195 — Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su

FromBrian <ad44@cityscape.co.uk>
Date2017-02-01 00:10 +0100
SubjectRe: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su
Message-ID<t5PIK-6HT-25@gated-at.bofh.it>
In reply to#177190
On Tue 31 Jan 2017 at 23:06:53 +0100, roba@openmailbox.org wrote:

> Well I sure haven't changed anything other than upgrade packages.  Now if
> some other package interferes with cupsd I don't know.  I know I spent some
> days fighting :631 4-5 months ago to get it (the printer) to work.  Cups
> worked fine then.  I have not tried any other printer since.
> 
> Obviously there seem to be other people elsewhere that refer to this
> problem.  Losing contact with cups after a stretch upgrade.  The only
> solution I found I listed but either I don't understand the commands or it
> is not working for me.
> 
> I even created a new user, run firefox stock 1st time no plugins ... and
> nothing.  Unreachable it says.  No instructions what so ever.  Even sudo
> firefox didn't reach.  NADA!
> 
> I think it is ridiculous after so many months to be holding a Win7 partition
> to be able to print stuff and it is not the printer problem anymore as a
> previous generic pc of similar specs printed just fine with Jessie.  This
> one is a stock DELL with no sign of hardware incompatibility.  Again, I am
> on LXDE Stretch, AMD64, and it is a USB printer, no network stuff.  The
> printer settings gui identified the correct printer and model.  No way to
> drive it.

Please post the output of

 /usr/sbin/lpinfo -l -v

in your next mail here.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]


#177198 — Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su

Fromroba@openmailbox.org
Date2017-02-01 00:50 +0100
SubjectRe: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su
Message-ID<t5Qls-6Un-19@gated-at.bofh.it>
In reply to#177190
Device: uri = cups-pdf:/
         class = file
         info = CUPS-PDF
         make-and-model = Virtual PDF Printer
         device-id = MFG:Generic;MDL:CUPS-PDF Printer;DES:Generic 
CUPS-PDF Printer;CLS:PRINTER;CMD:POSTSCRIPT;
         location =

The rest on the list are pretty blank, nothing assigned.  UNKNOWN and 
blanks after =

> 
>> From: Brian <ad44@cityscape.co.uk>
> 
>> Debian has changed nothing to account for localhost:631 not being
>> open to you. 'Webinterface No' in cupsd.conf could be a reason for
>> your experience, but a browser would inform you of this and offer
>> a solution.
>> 
>> TCP wrappers controls access from other machines on the network,
>> not from localhost. In any case, cupsd does not use libwrap.

[toc] | [prev] | [next] | [standalone]


#177201 — Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su

FromBrian <ad44@cityscape.co.uk>
Date2017-02-01 01:00 +0100
SubjectRe: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su
Message-ID<t5Qv8-6Xz-9@gated-at.bofh.it>
In reply to#177198
On Wed 01 Feb 2017 at 00:40:53 +0100, roba@openmailbox.org wrote:

> Device: uri = cups-pdf:/
>         class = file
>         info = CUPS-PDF
>         make-and-model = Virtual PDF Printer
>         device-id = MFG:Generic;MDL:CUPS-PDF Printer;DES:Generic CUPS-PDF
> Printer;CLS:PRINTER;CMD:POSTSCRIPT;
>         location =
> 
> The rest on the list are pretty blank, nothing assigned.  UNKNOWN and blanks
> after =
> 
> >
> >>From: Brian <ad44@cityscape.co.uk>
> >
> >>Debian has changed nothing to account for localhost:631 not being
> >>open to you. 'Webinterface No' in cupsd.conf could be a reason for
> >>your experience, but a browser would inform you of this and offer
> >>a solution.
> >>
> >>TCP wrappers controls access from other machines on the network,
> >>not from localhost. In any case, cupsd does not use libwrap.

Considering this thread is about your printer, I assumed you would
plug it in. You appear not to have done so. Please repeat and repost.

-- 
Brian.
 

[toc] | [prev] | [next] | [standalone]


#177202 — Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su

Fromroba@openmailbox.org
Date2017-02-01 01:00 +0100
SubjectRe: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su
Message-ID<t5Qv8-6Xz-15@gated-at.bofh.it>
In reply to#177198
Sorry hear it is again, complete:

Device: uri = https
         class = network
         info = Internet Printing Protocol (https)
         make-and-model = Unknown
         device-id =
         location =
Device: uri = socket
         class = network
         info = AppSocket/HP JetDirect
         make-and-model = Unknown
         device-id =
         location =
Device: uri = ipp14
         class = network
         info = Internet Printing Protocol (ipp14)
         make-and-model = Unknown
         device-id =
         location =
Device: uri = cups-pdf:/
         class = file
         info = CUPS-PDF
         make-and-model = Virtual PDF Printer
         device-id = MFG:Generic;MDL:CUPS-PDF Printer;DES:Generic 
CUPS-PDF Printer;CLS:PRINTER;CMD:POSTSCRIPT;
         location =
Device: uri = lpd
         class = network
         info = LPD/LPR Host or Printer
         make-and-model = Unknown
         device-id =
         location =
Device: uri = http
         class = network
         info = Internet Printing Protocol (http)
         make-and-model = Unknown
         device-id =
         location =
Device: uri = beh
         class = network
         info = Backend Error Handler
         make-and-model = Unknown
         device-id =
         location =
Device: uri = ipp
         class = network
         info = Internet Printing Protocol (ipp)
         make-and-model = Unknown
         device-id =
         location =
Device: uri = serial:/dev/ttyS0?baud=115200
         class = serial
         info = Serial Port #1
         make-and-model = Unknown
         device-id =
         location =
Device: uri = serial:/dev/ttyS1?baud=115200
         class = serial
         info = Serial Port #2
         make-and-model = Unknown
         device-id =
         location =
Device: uri = ipps
         class = network
         info = Internet Printing Protocol (ipps)
         make-and-model = Unknown
         device-id =
         location =
Device: uri = 
usb://RICOH/SP%20112SU%20DDST?serial=X004MB30122&interface=1
         class = direct
         info = RICOH SP 112SU DDST
         make-and-model = RICOH SP 112SU DDST
         device-id = MFG:RICOH ;CMD:GDI;MDL:SP 112SU DDST;CLS:PRINTER;
         location =

> 
> The rest on the list are pretty blank, nothing assigned.  UNKNOWN and
> blanks after =
> 
>> 
>>> From: Brian <ad44@cityscape.co.uk>
>> 
>>> Debian has changed nothing to account for localhost:631 not being
>>> open to you. 'Webinterface No' in cupsd.conf could be a reason for
>>> your experience, but a browser would inform you of this and offer
>>> a solution.
>>> 
>>> TCP wrappers controls access from other machines on the network,
>>> not from localhost. In any case, cupsd does not use libwrap.

[toc] | [prev] | [next] | [standalone]


#177203 — Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su

Fromroba@openmailbox.org
Date2017-02-01 01:20 +0100
SubjectRe: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su
Message-ID<t5QOt-7iX-1@gated-at.bofh.it>
In reply to#177202
Thanks for your help by the way, here is some other weird occurrence.
I run sudo firefox to see if it was a privilege problem and get this:
The screen came up but all links from the main page would run to a 
denial page.
The screen was from a cached page from way back when it was 1.7.5, while 
the current installed cups is 2.2.1-6 ..

When you delete the cached page same thing happens, deny deny deny.
Should I get something like konqueror or opera and try it?  I hate 
downloading stuff and deleting it as I had run into trouble before




> Device: uri = 
> usb://RICOH/SP%20112SU%20DDST?serial=X004MB30122&interface=1
>         class = direct
>         info = RICOH SP 112SU DDST
>         make-and-model = RICOH SP 112SU DDST
>         device-id = MFG:RICOH ;CMD:GDI;MDL:SP 112SU DDST;CLS:PRINTER;
>         location =
> 
>> 
>> The rest on the list are pretty blank, nothing assigned.  UNKNOWN and
>> blanks after =
>> 
>>> 
>>>> From: Brian <ad44@cityscape.co.uk>
>>> 
>>>> Debian has changed nothing to account for localhost:631 not being
>>>> open to you. 'Webinterface No' in cupsd.conf could be a reason for
>>>> your experience, but a browser would inform you of this and offer
>>>> a solution.
>>>> 
>>>> TCP wrappers controls access from other machines on the network,
>>>> not from localhost. In any case, cupsd does not use libwrap.

[toc] | [prev] | [next] | [standalone]


#177223 — Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su

FromBrian <ad44@cityscape.co.uk>
Date2017-02-01 11:00 +0100
SubjectRe: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su
Message-ID<t5ZRL-4h5-3@gated-at.bofh.it>
In reply to#177203
On Wed 01 Feb 2017 at 01:18:40 +0100, roba@openmailbox.org wrote:

> >Device: uri = usb://RICOH/SP%20112SU%20DDST?serial=X004MB30122&interface=1
> >        class = direct
> >        info = RICOH SP 112SU DDST
> >        make-and-model = RICOH SP 112SU DDST
> >        device-id = MFG:RICOH ;CMD:GDI;MDL:SP 112SU DDST;CLS:PRINTER;
> >        location =
> >
> Thanks for your help by the way, here is some other weird occurrence.
> I run sudo firefox to see if it was a privilege problem and get this:
> The screen came up but all links from the main page would run to a denial
> page.
> The screen was from a cached page from way back when it was 1.7.5, while the
> current installed cups is 2.2.1-6 ..
>
> When you delete the cached page same thing happens, deny deny deny.
> Should I get something like konqueror or opera and try it?  I hate
> downloading stuff and deleting it as I had run into trouble before 

You appear to have a browser problem rather than a printing problem.
I believe the advice with Firefox is to move ~/.mozilla out of the
way and restart it. Lynx would be good enough for what you want to
do. Try that to access localhost:631.

Alternatively, put your PPD in /usr/share/ppd/custom and use

lpadmin -p ... -v usb://RICOH/... -E -m /usr/share/ppd/custom/<myppd>

-- 
Brian.

[toc] | [prev] | [next] | [standalone]


#177230 — Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su

FromRoba <roba@openmailbox.org>
Date2017-02-01 15:20 +0100
SubjectRe: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su
Message-ID<t63Vn-70m-3@gated-at.bofh.it>
In reply to#177223
reaching CUPS, as I should be able to, is the problem, not printing
(that is a personal problem).

Again, your help (Brian) is appreciated but it seems as the problem and
the reason I am bringing it up here is not just to solve my own printer
problem, as this I brought into myself last year by buying a cheap
printer with no linux support.

Let's say I buy another printer with linux drivers available, would CUPS
be reachable.  To sum it up, there are others out there with Debian
upgrade to testing that experienced the same and although they pin point
the problem to /etc/hosts PARANOIA I have not been able to do the same
as I can not find the correct syntax for making exceptions.

LYNX did not work, same unreachable response (wow it is still alive?)
I will not try to rename ~/.mozilla as I already said that I created a
new user and started ff from scratch new - no-plugins  No difference.
Running browser as root did not reach.  I am suspecting a more serious
problem than it appears.

Here is another output if that helps:
$ ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.015 ms
$ ping 127.0.0.1:631
ping: 127.0.0.1:631: Name or service not known

ftp or telnet was not responsive either

I also run LXDE, going to X or openbox had the same exact results.

Brian:
> On Wed 01 Feb 2017 at 01:18:40 +0100, roba@openmailbox.org wrote:
> 
>>> Device: uri = usb://RICOH/SP%20112SU%20DDST?serial=X004MB30122&interface=1
>>>        class = direct
>>>        info = RICOH SP 112SU DDST
>>>        make-and-model = RICOH SP 112SU DDST
>>>        device-id = MFG:RICOH ;CMD:GDI;MDL:SP 112SU DDST;CLS:PRINTER;
>>>        location =
> 
> You appear to have a browser problem rather than a printing problem.
> I believe the advice with Firefox is to move ~/.mozilla out of the
> way and restart it. Lynx would be good enough for what you want to
> do. Try that to access localhost:631.
> 
> Alternatively, put your PPD in /usr/share/ppd/custom and use
> 
> lpadmin -p ... -v usb://RICOH/... -E -m /usr/share/ppd/custom/<myppd>
> 

[toc] | [prev] | [next] | [standalone]


#177234 — Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su

FromBrian <ad44@cityscape.co.uk>
Date2017-02-01 16:40 +0100
SubjectRe: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su
Message-ID<t65aO-7Hf-29@gated-at.bofh.it>
In reply to#177230
On Wed 01 Feb 2017 at 14:13:00 +0000, Roba wrote:

> reaching CUPS, as I should be able to, is the problem, not printing
> (that is a personal problem).

It gives you a way of setting up the printer without the web interface.

> Again, your help (Brian) is appreciated but it seems as the problem and
> the reason I am bringing it up here is not just to solve my own printer
> problem, as this I brought into myself last year by buying a cheap
> printer with no linux support.
> 
> Let's say I buy another printer with linux drivers available, would CUPS
> be reachable.  To sum it up, there are others out there with Debian
> upgrade to testing that experienced the same and although they pin point
> the problem to /etc/hosts PARANOIA I have not been able to do the same
> as I can not find the correct syntax for making exceptions.

/etc/hosts has nothing to do with /etc/hosts.allow (which was mentioned
earlier).

> LYNX did not work, same unreachable response (wow it is still alive?)
> I will not try to rename ~/.mozilla as I already said that I created a
> new user and started ff from scratch new - no-plugins  No difference.
> Running browser as root did not reach.  I am suspecting a more serious
> problem than it appears.
> 
> Here is another output if that helps:
> $ ping 127.0.0.1
> PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
> 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.015 ms
> $ ping 127.0.0.1:631
> ping: 127.0.0.1:631: Name or service not known

The last command will fail for 100% of users.

Please post the outputs of

  systemctl status cups

and

  netstat -tulpan

-- 
Brian.

[toc] | [prev] | [next] | [standalone]


#177262 — Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su

FromRoba <roba@openmailbox.org>
Date2017-02-01 23:00 +0100
SubjectRe: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su
Message-ID<t6b6x-3hm-1@gated-at.bofh.it>
In reply to#177234
I hope you don't mind helping me still even most of this makes little
sense to me.  I still don't want all my ip stuff going out to the list
So here is the output

Brian:$ systemctl status cups
�� cups.service - CUPS Scheduler
   Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor
preset: ena
   Active: active (running) since Wed 2017-02-01 @@T; xh ymin ago
     Docs: man:cupsd(8)
 Main PID: 353 (cupsd)
    Tasks: 2 (limit: 4915)
   CGroup: /system.slice/cups.service
           ������ 353 /usr/sbin/cupsd -l
           ������5428 /usr/lib/cups/notifier/dbus dbus://

Feb 01 zzzzz systemd[1]: Started CUPS Scheduler.

$ netstat -tulpan
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address
State       PID/Program name
tcp        0      0 0.0.0.0:38837           0.0.0.0:*
LISTEN      -
tcp        0      0 0.0.0.0:22              0.0.0.0:*
LISTEN      -
tcp        0      0 127.0.0.1:9050          0.0.0.0:*
LISTEN      -
tcp        0      0 127.0.0.1:2013          0.0.0.0:*
LISTEN      -
tcp        0      0 127.0.0.1:7070          0.0.0.0:*
LISTEN      -
tcp        0      0 127.0.0.1:1984          0.0.0.0:*
LISTEN      -
tcp        0      0 0.0.0.0:46465           0.0.0.0:*
LISTEN      -
tcp        0      0 0.0.0.0:2049            0.0.0.0:*
LISTEN      -
tcp        0      0 0.0.0.0:51395           0.0.0.0:*
LISTEN      -
tcp        0      0 0.0.0.0:48197           0.0.0.0:*
LISTEN      -
tcp        0      0 127.0.0.1:9000          0.0.0.0:*
LISTEN      -
tcp        0      0 127.0.0.1:9001          0.0.0.0:*
LISTEN      -
tcp        0      0 0.0.0.0:111             0.0.0.0:*
LISTEN      -
tcp        0      0 192.168.1.45:53730      93.184.220.29:80
TIME_WAIT   -
tcp        0      0 127.0.0.1:34794         127.0.0.1:9001
ESTABLISHED -
tcp        0      0 127.0.0.1:9001          127.0.0.1:34794
ESTABLISHED -
tcp        0      0 192.168.1.45:53728      93.184.220.29:80
TIME_WAIT   -
tcp        0      0 192.168.1.45:53998      93.184.220.29:80
TIME_WAIT   -
tcp        0      0 127.0.0.1:9000          127.0.0.1:44002
ESTABLISHED -
tcp        0      0 127.0.0.1:44002         127.0.0.1:9000
ESTABLISHED -
tcp        0      0 192.168.1.45:48406      54.192.217.183:443
TIME_WAIT   -
tcp        0      0 192.168.1.45:45126      54.192.217.224:443
TIME_WAIT   -
tcp        0      0 192.168.1.45:48584      54.192.217.207:443
TIME_WAIT   -
tcp6       0      0 :::36915                :::*
LISTEN      -
tcp6       0      0 :::22                   :::*
LISTEN      -
tcp6       0      0 :::60153                :::*
LISTEN      -
tcp6       0      0 :::2049                 :::*
LISTEN      -
tcp6       0      0 :::51429                :::*
LISTEN      -
tcp6       0      0 :::50731                :::*
LISTEN      -
tcp6       0      0 :::111                  :::*
LISTEN      -
tcp6       0      0 2a02:2149:864a:4d:47310 2a00:1450:4017:803:::80
TIME_WAIT   -
tcp6       0      0 2a02:2149:864a:4d:42114 2a00:1450:4017:804::443
TIME_WAIT   -
tcp6       0      0 2a02:2149:864a:4d:33574 2a00:1450:4017:803::443
TIME_WAIT   -
tcp6       0      0 2a02:2149:864a:4d:46414 2a00:1450:4017:803::443
TIME_WAIT   -
udp        0      0 0.0.0.0:33645           0.0.0.0:*
       -
udp        0      0 0.0.0.0:927             0.0.0.0:*
       -
udp        0      0 0.0.0.0:5353            0.0.0.0:*
       -
udp        0      0 0.0.0.0:48658           0.0.0.0:*
       -
udp        0      0 0.0.0.0:34484           0.0.0.0:*
       -
udp        0      0 0.0.0.0:2049            0.0.0.0:*
       -
udp        0      0 0.0.0.0:68              0.0.0.0:*
       -
udp        0      0 0.0.0.0:111             0.0.0.0:*
       -
udp        0      0 0.0.0.0:35347           0.0.0.0:*
       -
udp        0      0 0.0.0.0:35403           0.0.0.0:*
       -
udp        0      0 0.0.0.0:631             0.0.0.0:*
       -
udp6       0      0 :::927                  :::*
       -
udp6       0      0 :::5353                 :::*
       -
udp6       0      0 :::40494                :::*
       -
udp6       0      0 :::42937                :::*
       -
udp6       0      0 :::2049                 :::*
       -
udp6       0      0 :::111                  :::*
       -
udp6       0      0 :::47399                :::*
       -
udp6       0      0 :::49449                :::*
       -
udp6       0      0 :::41524                :::*
       -

as root

netstat -tulpan
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address
State       PID/Program name
tcp        0      0 0.0.0.0:38837           0.0.0.0:*
LISTEN      963/rpc.mountd
tcp        0      0 0.0.0.0:22              0.0.0.0:*
LISTEN      957/sshd
tcp        0      0 127.0.0.1:9050          0.0.0.0:*
LISTEN      1123/tor
tcp        0      0 127.0.0.1:2013          0.0.0.0:*
LISTEN      1803/bitmask
tcp        0      0 127.0.0.1:7070          0.0.0.0:*
LISTEN      1803/bitmask
tcp        0      0 127.0.0.1:1984          0.0.0.0:*
LISTEN      1803/bitmask
tcp        0      0 0.0.0.0:46465           0.0.0.0:*
LISTEN      -
tcp        0      0 0.0.0.0:2049            0.0.0.0:*
LISTEN      -
tcp        0      0 0.0.0.0:51395           0.0.0.0:*
LISTEN      963/rpc.mountd
tcp        0      0 0.0.0.0:48197           0.0.0.0:*
LISTEN      963/rpc.mountd
tcp        0      0 127.0.0.1:9000          0.0.0.0:*
LISTEN      1803/bitmask
tcp        0      0 127.0.0.1:9001          0.0.0.0:*
LISTEN      1803/bitmask
tcp        0      0 0.0.0.0:111             0.0.0.0:*
LISTEN      327/rpcbind
tcp        0      0 127.0.0.1:34794         127.0.0.1:9001
ESTABLISHED 1803/bitmask
tcp        0      0 127.0.0.1:9001          127.0.0.1:34794
ESTABLISHED 1803/bitmask
tcp        0      0 127.0.0.1:9000          127.0.0.1:44002
ESTABLISHED 1803/bitmask
tcp        0      0 127.0.0.1:44002         127.0.0.1:9000
ESTABLISHED 1803/bitmask
tcp6       0      0 :::36915                :::*
LISTEN      -
tcp6       0      0 :::22                   :::*
LISTEN      957/sshd
tcp6       0      0 :::60153                :::*
LISTEN      963/rpc.mountd
tcp6       0      0 :::2049                 :::*
LISTEN      -
tcp6       0      0 :::51429                :::*
LISTEN      963/rpc.mountd
tcp6       0      0 :::50731                :::*
LISTEN      963/rpc.mountd
tcp6       0      0 :::111                  :::*
LISTEN      327/rpcbind
udp        0      0 0.0.0.0:33645           0.0.0.0:*
       963/rpc.mountd
udp        0      0 0.0.0.0:927             0.0.0.0:*
       327/rpcbind
udp        0      0 0.0.0.0:5353            0.0.0.0:*
       357/avahi-daemon: r
udp        0      0 0.0.0.0:48658           0.0.0.0:*
       -
udp        0      0 0.0.0.0:34484           0.0.0.0:*
       357/avahi-daemon: r
udp        0      0 0.0.0.0:2049            0.0.0.0:*
       -
udp        0      0 0.0.0.0:68              0.0.0.0:*
       683/dhclient
udp        0      0 0.0.0.0:111             0.0.0.0:*
       327/rpcbind
udp        0      0 0.0.0.0:35347           0.0.0.0:*
       963/rpc.mountd
udp        0      0 0.0.0.0:35403           0.0.0.0:*
       963/rpc.mountd
udp        0      0 0.0.0.0:631             0.0.0.0:*
       442/cups-browsed
udp6       0      0 :::927                  :::*
       327/rpcbind
udp6       0      0 :::5353                 :::*
       357/avahi-daemon: r
udp6       0      0 :::40494                :::*
       -
udp6       0      0 :::42937                :::*
       357/avahi-daemon: r
udp6       0      0 :::2049                 :::*
       -
udp6       0      0 :::111                  :::*
       327/rpcbind
udp6       0      0 :::47399                :::*
       963/rpc.mountd
udp6       0      0 :::49449                :::*
       963/rpc.mountd
udp6       0      0 :::41524                :::*
       963/rpc.mountd





> On Wed 01 Feb 2017 at 14:13:00 +0000, Roba wrote:
>
>> reaching CUPS, as I should be able to, is the problem, not printing
>> (that is a personal problem).
>
> It gives you a way of setting up the printer without the web interface.
>
>> Again, your help (Brian) is appreciated but it seems as the problem and
>> the reason I am bringing it up here is not just to solve my own printer
>> problem, as this I brought into myself last year by buying a cheap
>> printer with no linux support.
>>
>> Let's say I buy another printer with linux drivers available, would CUPS
>> be reachable.  To sum it up, there are others out there with Debian
>> upgrade to testing that experienced the same and although they pin point
>> the problem to /etc/hosts PARANOIA I have not been able to do the same
>> as I can not find the correct syntax for making exceptions.
>
> /etc/hosts has nothing to do with /etc/hosts.allow (which was mentioned
> earlier).
>
>> LYNX did not work, same unreachable response (wow it is still alive?)
>> I will not try to rename ~/.mozilla as I already said that I created a
>> new user and started ff from scratch new - no-plugins  No difference.
>> Running browser as root did not reach.  I am suspecting a more serious
>> problem than it appears.
>>
>> Here is another output if that helps:
>> $ ping 127.0.0.1
>> PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
>> 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.015 ms
>> $ ping 127.0.0.1:631
>> ping: 127.0.0.1:631: Name or service not known
>
> The last command will fail for 100% of users.
>
> Please post the outputs of
>
>   systemctl status cups
>
> and
>
>   netstat -tulpan

Brian:
> On Wed 01 Feb 2017 at 14:13:00 +0000, Roba wrote:
> 
>> reaching CUPS, as I should be able to, is the problem, not printing
>> (that is a personal problem).
> 
> It gives you a way of setting up the printer without the web interface.
> 
>> Again, your help (Brian) is appreciated but it seems as the problem and
>> the reason I am bringing it up here is not just to solve my own printer
>> problem, as this I brought into myself last year by buying a cheap
>> printer with no linux support.
>>
>> Let's say I buy another printer with linux drivers available, would CUPS
>> be reachable.  To sum it up, there are others out there with Debian
>> upgrade to testing that experienced the same and although they pin point
>> the problem to /etc/hosts PARANOIA I have not been able to do the same
>> as I can not find the correct syntax for making exceptions.
> 
> /etc/hosts has nothing to do with /etc/hosts.allow (which was mentioned
> earlier).
> 
>> LYNX did not work, same unreachable response (wow it is still alive?)
>> I will not try to rename ~/.mozilla as I already said that I created a
>> new user and started ff from scratch new - no-plugins  No difference.
>> Running browser as root did not reach.  I am suspecting a more serious
>> problem than it appears.
>>
>> Here is another output if that helps:
>> $ ping 127.0.0.1
>> PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
>> 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.015 ms
>> $ ping 127.0.0.1:631
>> ping: 127.0.0.1:631: Name or service not known
> 
> The last command will fail for 100% of users.
> 
> Please post the outputs of
> 
>   systemctl status cups
> 
> and
> 
>   netstat -tulpan
> 

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[toc] | [prev] | [next] | [standalone]


#177265 — Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su

FromBrian <ad44@cityscape.co.uk>
Date2017-02-02 00:30 +0100
SubjectRe: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su
Message-ID<t6cvE-4hs-9@gated-at.bofh.it>
In reply to#177262
On Wed 01 Feb 2017 at 21:55:00 +0000, Roba wrote:

> I hope you don't mind helping me still even most of this makes little
> sense to me.  I still don't want all my ip stuff going out to the list
> So here is the output
> 
> Brian:$ systemctl status cups
> �� cups.service - CUPS Scheduler
>    Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor
> preset: ena
>    Active: active (running) since Wed 2017-02-01 @@T; xh ymin ago
>      Docs: man:cupsd(8)
>  Main PID: 353 (cupsd)
>     Tasks: 2 (limit: 4915)
>    CGroup: /system.slice/cups.service
>            ������ 353 /usr/sbin/cupsd -l
>            ������5428 /usr/lib/cups/notifier/dbus dbus://
> 
> Feb 01 zzzzz systemd[1]: Started CUPS Scheduler.

This shows that the main managing process, cupsd, is running. Without
it, you can do no printing. It looks good up to now. But see later.
 
> $ netstat -tulpan
> (Not all processes could be identified, non-owned process info
>  will not be shown, you would have to be root to see it all.)
> Active Internet connections (servers and established)
> Proto Recv-Q Send-Q Local Address           Foreign Address
> State       PID/Program name
> tcp        0      0 0.0.0.0:38837           0.0.0.0:*
> LISTEN      -
> tcp        0      0 0.0.0.0:22              0.0.0.0:*
> LISTEN      -
> tcp        0      0 127.0.0.1:9050          0.0.0.0:*
> LISTEN      -
> tcp        0      0 127.0.0.1:2013          0.0.0.0:*
> LISTEN      -
> tcp        0      0 127.0.0.1:7070          0.0.0.0:*
> LISTEN      -
> tcp        0      0 127.0.0.1:1984          0.0.0.0:*
> LISTEN      -
> tcp        0      0 0.0.0.0:46465           0.0.0.0:*
> LISTEN      -
> tcp        0      0 0.0.0.0:2049            0.0.0.0:*
> LISTEN      -
> tcp        0      0 0.0.0.0:51395           0.0.0.0:*
> LISTEN      -
> tcp        0      0 0.0.0.0:48197           0.0.0.0:*
> LISTEN      -
> tcp        0      0 127.0.0.1:9000          0.0.0.0:*
> LISTEN      -
> tcp        0      0 127.0.0.1:9001          0.0.0.0:*
> LISTEN      -
> tcp        0      0 0.0.0.0:111             0.0.0.0:*
> LISTEN      -
> tcp        0      0 192.168.1.45:53730      93.184.220.29:80
> TIME_WAIT   -
> tcp        0      0 127.0.0.1:34794         127.0.0.1:9001
> ESTABLISHED -
> tcp        0      0 127.0.0.1:9001          127.0.0.1:34794
> ESTABLISHED -
> tcp        0      0 192.168.1.45:53728      93.184.220.29:80
> TIME_WAIT   -
> tcp        0      0 192.168.1.45:53998      93.184.220.29:80
> TIME_WAIT   -
> tcp        0      0 127.0.0.1:9000          127.0.0.1:44002
> ESTABLISHED -
> tcp        0      0 127.0.0.1:44002         127.0.0.1:9000
> ESTABLISHED -
> tcp        0      0 192.168.1.45:48406      54.192.217.183:443
> TIME_WAIT   -
> tcp        0      0 192.168.1.45:45126      54.192.217.224:443
> TIME_WAIT   -
> tcp        0      0 192.168.1.45:48584      54.192.217.207:443
> TIME_WAIT   -
> tcp6       0      0 :::36915                :::*
> LISTEN      -
> tcp6       0      0 :::22                   :::*
> LISTEN      -
> tcp6       0      0 :::60153                :::*
> LISTEN      -
> tcp6       0      0 :::2049                 :::*
> LISTEN      -
> tcp6       0      0 :::51429                :::*
> LISTEN      -
> tcp6       0      0 :::50731                :::*
> LISTEN      -
> tcp6       0      0 :::111                  :::*
> LISTEN      -
> tcp6       0      0 2a02:2149:864a:4d:47310 2a00:1450:4017:803:::80
> TIME_WAIT   -
> tcp6       0      0 2a02:2149:864a:4d:42114 2a00:1450:4017:804::443
> TIME_WAIT   -
> tcp6       0      0 2a02:2149:864a:4d:33574 2a00:1450:4017:803::443
> TIME_WAIT   -
> tcp6       0      0 2a02:2149:864a:4d:46414 2a00:1450:4017:803::443
> TIME_WAIT   -
> udp        0      0 0.0.0.0:33645           0.0.0.0:*
>        -
> udp        0      0 0.0.0.0:927             0.0.0.0:*
>        -
> udp        0      0 0.0.0.0:5353            0.0.0.0:*
>        -
> udp        0      0 0.0.0.0:48658           0.0.0.0:*
>        -
> udp        0      0 0.0.0.0:34484           0.0.0.0:*
>        -
> udp        0      0 0.0.0.0:2049            0.0.0.0:*
>        -
> udp        0      0 0.0.0.0:68              0.0.0.0:*
>        -
> udp        0      0 0.0.0.0:111             0.0.0.0:*
>        -
> udp        0      0 0.0.0.0:35347           0.0.0.0:*
>        -
> udp        0      0 0.0.0.0:35403           0.0.0.0:*
>        -
> udp        0      0 0.0.0.0:631             0.0.0.0:*
>        -
> udp6       0      0 :::927                  :::*
>        -
> udp6       0      0 :::5353                 :::*
>        -
> udp6       0      0 :::40494                :::*
>        -
> udp6       0      0 :::42937                :::*
>        -
> udp6       0      0 :::2049                 :::*
>        -
> udp6       0      0 :::111                  :::*
>        -
> udp6       0      0 :::47399                :::*
>        -
> udp6       0      0 :::49449                :::*
>        -
> udp6       0      0 :::41524                :::*
>        -
> 
> as root
> 
> netstat -tulpan
> Active Internet connections (servers and established)
> Proto Recv-Q Send-Q Local Address           Foreign Address
> State       PID/Program name
> tcp        0      0 0.0.0.0:38837           0.0.0.0:*
> LISTEN      963/rpc.mountd
> tcp        0      0 0.0.0.0:22              0.0.0.0:*
> LISTEN      957/sshd
> tcp        0      0 127.0.0.1:9050          0.0.0.0:*
> LISTEN      1123/tor
> tcp        0      0 127.0.0.1:2013          0.0.0.0:*
> LISTEN      1803/bitmask
> tcp        0      0 127.0.0.1:7070          0.0.0.0:*
> LISTEN      1803/bitmask
> tcp        0      0 127.0.0.1:1984          0.0.0.0:*
> LISTEN      1803/bitmask
> tcp        0      0 0.0.0.0:46465           0.0.0.0:*
> LISTEN      -
> tcp        0      0 0.0.0.0:2049            0.0.0.0:*
> LISTEN      -
> tcp        0      0 0.0.0.0:51395           0.0.0.0:*
> LISTEN      963/rpc.mountd
> tcp        0      0 0.0.0.0:48197           0.0.0.0:*
> LISTEN      963/rpc.mountd
> tcp        0      0 127.0.0.1:9000          0.0.0.0:*
> LISTEN      1803/bitmask
> tcp        0      0 127.0.0.1:9001          0.0.0.0:*
> LISTEN      1803/bitmask
> tcp        0      0 0.0.0.0:111             0.0.0.0:*
> LISTEN      327/rpcbind
> tcp        0      0 127.0.0.1:34794         127.0.0.1:9001
> ESTABLISHED 1803/bitmask
> tcp        0      0 127.0.0.1:9001          127.0.0.1:34794
> ESTABLISHED 1803/bitmask
> tcp        0      0 127.0.0.1:9000          127.0.0.1:44002
> ESTABLISHED 1803/bitmask
> tcp        0      0 127.0.0.1:44002         127.0.0.1:9000
> ESTABLISHED 1803/bitmask
> tcp6       0      0 :::36915                :::*
> LISTEN      -
> tcp6       0      0 :::22                   :::*
> LISTEN      957/sshd
> tcp6       0      0 :::60153                :::*
> LISTEN      963/rpc.mountd
> tcp6       0      0 :::2049                 :::*
> LISTEN      -
> tcp6       0      0 :::51429                :::*
> LISTEN      963/rpc.mountd
> tcp6       0      0 :::50731                :::*
> LISTEN      963/rpc.mountd
> tcp6       0      0 :::111                  :::*
> LISTEN      327/rpcbind
> udp        0      0 0.0.0.0:33645           0.0.0.0:*
>        963/rpc.mountd
> udp        0      0 0.0.0.0:927             0.0.0.0:*
>        327/rpcbind
> udp        0      0 0.0.0.0:5353            0.0.0.0:*
>        357/avahi-daemon: r
> udp        0      0 0.0.0.0:48658           0.0.0.0:*
>        -
> udp        0      0 0.0.0.0:34484           0.0.0.0:*
>        357/avahi-daemon: r
> udp        0      0 0.0.0.0:2049            0.0.0.0:*
>        -
> udp        0      0 0.0.0.0:68              0.0.0.0:*
>        683/dhclient
> udp        0      0 0.0.0.0:111             0.0.0.0:*
>        327/rpcbind
> udp        0      0 0.0.0.0:35347           0.0.0.0:*
>        963/rpc.mountd
> udp        0      0 0.0.0.0:35403           0.0.0.0:*
>        963/rpc.mountd
> udp        0      0 0.0.0.0:631             0.0.0.0:*
>        442/cups-browsed
> udp6       0      0 :::927                  :::*
>        327/rpcbind
> udp6       0      0 :::5353                 :::*
>        357/avahi-daemon: r
> udp6       0      0 :::40494                :::*
>        -
> udp6       0      0 :::42937                :::*
>        357/avahi-daemon: r
> udp6       0      0 :::2049                 :::*
>        -
> udp6       0      0 :::111                  :::*
>        327/rpcbind
> udp6       0      0 :::47399                :::*
>        963/rpc.mountd
> udp6       0      0 :::49449                :::*
>        963/rpc.mountd
> udp6       0      0 :::41524                :::*
>        963/rpc.mountd

When cupsd starts (as yours has done) it listens for incoming connections
on port 631 for tcp and tcp6. Print jobs are sent to port 631. A browser
connects to tcp port 631. Your netstat output shows no listening on tcp
port 631. No wonder http://localhost:631 will not work.

Reason? No idea, but that is problem. It could lie with your cupsd.conf
in /etc/cups. Or something you have done with the networking setup.

You have cups-browsed listening on udp port 631 but it has nothing to do
with cupsd.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]


#177266 — Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su

FromBrian <ad44@cityscape.co.uk>
Date2017-02-02 01:00 +0100
SubjectRe: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su
Message-ID<t6cYF-4rB-9@gated-at.bofh.it>
In reply to#177265
On Wed 01 Feb 2017 at 23:21:00 +0000, Brian wrote:

> When cupsd starts (as yours has done) it listens for incoming connections
> on port 631 for tcp and tcp6. Print jobs are sent to port 631. A browser
> connects to tcp port 631. Your netstat output shows no listening on tcp
> port 631. No wonder http://localhost:631 will not work.
> 
> Reason? No idea, but that is problem. It could lie with your cupsd.conf
> in /etc/cups. Or something you have done with the networking setup.

The default cupsd.conf has the line

 Listen localhost:631

Does yours?

-- 
Brian.

[toc] | [prev] | [next] | [standalone]


#177306 — Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su

FromBrian <ad44@cityscape.co.uk>
Date2017-02-02 21:10 +0100
SubjectRe: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su
Message-ID<t6vRD-aV-9@gated-at.bofh.it>
In reply to#177266
On Wed 01 Feb 2017 at 23:58:15 +0000, Brian wrote:

> On Wed 01 Feb 2017 at 23:21:00 +0000, Brian wrote:
> 
> > When cupsd starts (as yours has done) it listens for incoming connections
> > on port 631 for tcp and tcp6. Print jobs are sent to port 631. A browser
> > connects to tcp port 631. Your netstat output shows no listening on tcp
> > port 631. No wonder http://localhost:631 will not work.
> > 
> > Reason? No idea, but that is problem. It could lie with your cupsd.conf
> > in /etc/cups. Or something you have done with the networking setup.
> 
> The default cupsd.conf has the line
> 
>  Listen localhost:631
> 
> Does yours?

A simple enough question. Well?

-- 
Brian.

[toc] | [prev] | [next] | [standalone]


#177369 — Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su

FromRoba <roba@openmailbox.org>
Date2017-02-04 02:30 +0100
SubjectRe: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su
Message-ID<t6XkS-1yT-7@gated-at.bofh.it>
In reply to#177306
Let us see.
I HAVE explained I have done nothing to alter what existed from "stock"
in Jessie (when cups) did work from the browser, right?
Now it does not and I HAVE DONE NOTHING other than upgrading from stable
to testing.  And cups does not work.  Now how would your question
address this issue?

You want to see output published here on the list but your email does
not really exist, so you read the list from elsewhere.  That makes me
wonder with who or what am I talking to.

$ whereis cupsd.conf
cupsd: /usr/sbin/cupsd /usr/share/man/man8/cupsd.8.gz

$ ls -al /usr/sbin/cup*
-rwxr-xr-x 1 root root 174416 Jan 19 15:44 /usr/sbin/cups-browsed
-rwxr-xr-x 1 root root  27980 Feb 16  2016 /usr/sbin/cups-genppdupdate
-rwxr-xr-x 1 root root  10232 Jan 18 15:06 /usr/sbin/cupsaccept
-rwxr-xr-x 1 root root  10232 Jan 18 15:06 /usr/sbin/cupsaddsmb
-rwxr-xr-x 1 root root  10232 Jan 18 15:06 /usr/sbin/cupsctl
-rwxr-xr-x 1 root root 416328 Jan 18 15:06 /usr/sbin/cupsd
lrwxrwxrwx 1 root root     10 Jan 18 15:06 /usr/sbin/cupsdisable ->
cupsaccept
lrwxrwxrwx 1 root root     10 Jan 18 15:06 /usr/sbin/cupsenable ->
cupsaccept
-rwxr-xr-x 1 root root  26920 Jan 18 15:06 /usr/sbin/cupsfilter
lrwxrwxrwx 1 root root     10 Jan 18 15:06 /usr/sbin/cupsreject ->
cupsaccept

Anything else I can help you with?
Because it doesn't seem any more that I am seeking help from someone who
wants to help but from someone who wants to interrogate and arrogantly
wants to make anybody seem inferior.  If that really matters to you, I
do not know and I do not wish to compete with any experts for the
position of the expert.  It is not even that extreme for me to make the
damn printer work.

BUT

If CUPS worked and one does nothing to affect it (consciously at least
because I'd rather do work than be fiddling with debian bugs) and after
some upgrade/update it doesn't I suspect it is a bug on behalf of the
system and not MY PROBLEM.  Because if I had left the damn thing alone
unupdated in its old stable state I wouldn't be here asking questions.

I suspect this is not what DEBIAN as a community want or expect.

Now if we can address the issue and not the bearer of the symptom we can
become constructive again.






Brian:
> On Wed 01 Feb 2017 at 23:58:15 +0000, Brian wrote:
> 
>> On Wed 01 Feb 2017 at 23:21:00 +0000, Brian wrote:
>>
>>> When cupsd starts (as yours has done) it listens for incoming connections
>>> on port 631 for tcp and tcp6. Print jobs are sent to port 631. A browser
>>> connects to tcp port 631. Your netstat output shows no listening on tcp
>>> port 631. No wonder http://localhost:631 will not work.
>>>
>>> Reason? No idea, but that is problem. It could lie with your cupsd.conf
>>> in /etc/cups. Or something you have done with the networking setup.
>>
>> The default cupsd.conf has the line
>>
>>  Listen localhost:631
>>
>> Does yours?
> 
> A simple enough question. Well?
> 

[toc] | [prev] | [next] | [standalone]


#177370 — Re: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su

FromRoba <roba@openmailbox.org>
Date2017-02-04 02:50 +0100
SubjectRe: CUPS in stretch does NOT WORK - Ricoh printer SP112 SP112-su
Message-ID<t6XEd-1GS-3@gated-at.bofh.it>
In reply to#177369
/etc/cups/cupsd.conf  (I thought whereis would have found it, I am wrong)

# Show general information in error_log.
LogLevel warn
MaxLogSize 0
Listen /var/run/cups/cups.sock
Listen /var/run/cups/cups.sock
Browsing On
BrowseLocalProtocols dnssd
DefaultAuthType Basic
WebInterface Yes
<Location />
  Order allow,deny
</Location>
<Location /admin>
  Order allow,deny
</Location>
<Location /admin/conf>
  AuthType Default
  Require user @SYSTEM
  Order allow,deny
</Location>
<Policy default>
  JobPrivateAccess default
  JobPrivateValues default
  SubscriptionPrivateAccess default
  SubscriptionPrivateValues default
  <Limit Create-Job Print-Job Print-URI Validate-Job>
    Order deny,allow
  </Limit>
  <Limit Send-Document Send-URI Hold-Job Release-Job Restart-Job
Purge-Jobs Set-Job-Attributes Create-Job-Subscription Renew-Subscription
Cancel-Subscription Get-Notifications Reprocess-Job Cancel-Current-Job
Suspend-Current-Job Resume-Job Cancel-My-Jobs Close-Job CUPS-Move-Job
CUPS-Get-Document>
    Require user @OWNER @SYSTEM
    Order deny,allow
  </Limit>
  <Limit CUPS-Add-Modify-Printer CUPS-Delete-Printer
CUPS-Add-Modify-Class CUPS-Delete-Class CUPS-Set-Default CUPS-Get-Devices>
    AuthType Default
    Require user @SYSTEM
    Order deny,allow
  </Limit>
  <Limit Pause-Printer Resume-Printer Enable-Printer Disable-Printer
Pause-Printer-After-Current-Job Hold-New-Jobs Release-Held-New-Jobs
Deactivate-Printer Activate-Printer Restart-Printer Shutdown-Printer
Startup-Printer Promote-Job Schedule-Job-After Cancel-Jobs
CUPS-Accept-Jobs CUPS-Reject-Jobs>
    AuthType Default
    Require user @SYSTEM
    Order deny,allow
  </Limit>
  <Limit Cancel-Job CUPS-Authenticate-Job>
    Require user @OWNER @SYSTEM
    Order deny,allow
  </Limit>
  <Limit All>
    Order deny,allow
  </Limit>
</Policy>
<Policy authenticated>
  JobPrivateAccess default
  JobPrivateValues default
  SubscriptionPrivateAccess default
  SubscriptionPrivateValues default
  <Limit Create-Job Print-Job Print-URI Validate-Job>
    AuthType Default
    Order deny,allow
  </Limit>
  <Limit Send-Document Send-URI Hold-Job Release-Job Restart-Job
Purge-Jobs Set-Job-Attributes Create-Job-Subscription Renew-Subscription
Cancel-Subscription Get-Notifications Reprocess-Job Cancel-Current-Job
Suspend-Current-Job Resume-Job Cancel-My-Jobs Close-Job CUPS-Move-Job
CUPS-Get-Document>
    AuthType Default
    Require user @OWNER @SYSTEM
    Order deny,allow
  </Limit>
  <Limit CUPS-Add-Modify-Printer CUPS-Delete-Printer
CUPS-Add-Modify-Class CUPS-Delete-Class CUPS-Set-Default>
    AuthType Default
    Require user @SYSTEM
    Order deny,allow
  </Limit>
  <Limit Pause-Printer Resume-Printer Enable-Printer Disable-Printer
Pause-Printer-After-Current-Job Hold-New-Jobs Release-Held-New-Jobs
Deactivate-Printer Activate-Printer Restart-Printer Shutdown-Printer
Startup-Printer Promote-Job Schedule-Job-After Cancel-Jobs
CUPS-Accept-Jobs CUPS-Reject-Jobs>
    AuthType Default
    Require user @SYSTEM
    Order deny,allow
  </Limit>
  <Limit Cancel-Job CUPS-Authenticate-Job>
    AuthType Default
    Require user @OWNER @SYSTEM
    Order deny,allow
  </Limit>
  <Limit All>
    Order deny,allow
  </Limit>
</Policy>
JobPrivateAccess default
JobPrivateValues default
SubscriptionPrivateAccess default
SubscriptionPrivateValues default
PreserveJobHistory No


Roba:
> Let us see.
> I HAVE explained I have done nothing to alter what existed from "stock"
> in Jessie (when cups) did work from the browser, right?
> Now it does not and I HAVE DONE NOTHING other than upgrading from stable
> to testing.  And cups does not work.  Now how would your question
> address this issue?
> 
> You want to see output published here on the list but your email does
> not really exist, so you read the list from elsewhere.  That makes me
> wonder with who or what am I talking to.
> 
> $ whereis cupsd.conf
> cupsd: /usr/sbin/cupsd /usr/share/man/man8/cupsd.8.gz
> 
> $ ls -al /usr/sbin/cup*
> -rwxr-xr-x 1 root root 174416 Jan 19 15:44 /usr/sbin/cups-browsed
> -rwxr-xr-x 1 root root  27980 Feb 16  2016 /usr/sbin/cups-genppdupdate
> -rwxr-xr-x 1 root root  10232 Jan 18 15:06 /usr/sbin/cupsaccept
> -rwxr-xr-x 1 root root  10232 Jan 18 15:06 /usr/sbin/cupsaddsmb
> -rwxr-xr-x 1 root root  10232 Jan 18 15:06 /usr/sbin/cupsctl
> -rwxr-xr-x 1 root root 416328 Jan 18 15:06 /usr/sbin/cupsd
> lrwxrwxrwx 1 root root     10 Jan 18 15:06 /usr/sbin/cupsdisable ->
> cupsaccept
> lrwxrwxrwx 1 root root     10 Jan 18 15:06 /usr/sbin/cupsenable ->
> cupsaccept
> -rwxr-xr-x 1 root root  26920 Jan 18 15:06 /usr/sbin/cupsfilter
> lrwxrwxrwx 1 root root     10 Jan 18 15:06 /usr/sbin/cupsreject ->
> cupsaccept
> 
> Anything else I can help you with?
> Because it doesn't seem any more that I am seeking help from someone who
> wants to help but from someone who wants to interrogate and arrogantly
> wants to make anybody seem inferior.  If that really matters to you, I
> do not know and I do not wish to compete with any experts for the
> position of the expert.  It is not even that extreme for me to make the
> damn printer work.
> 
> BUT
> 
> If CUPS worked and one does nothing to affect it (consciously at least
> because I'd rather do work than be fiddling with debian bugs) and after
> some upgrade/update it doesn't I suspect it is a bug on behalf of the
> system and not MY PROBLEM.  Because if I had left the damn thing alone
> unupdated in its old stable state I wouldn't be here asking questions.
> 
> I suspect this is not what DEBIAN as a community want or expect.
> 
> Now if we can address the issue and not the bearer of the symptom we can
> become constructive again.
> 
> 
> 
> 
> 
> 
> Brian:
>> On Wed 01 Feb 2017 at 23:58:15 +0000, Brian wrote:
>>
>>> On Wed 01 Feb 2017 at 23:21:00 +0000, Brian wrote:
>>>
>>>> When cupsd starts (as yours has done) it listens for incoming connections
>>>> on port 631 for tcp and tcp6. Print jobs are sent to port 631. A browser
>>>> connects to tcp port 631. Your netstat output shows no listening on tcp
>>>> port 631. No wonder http://localhost:631 will not work.
>>>>
>>>> Reason? No idea, but that is problem. It could lie with your cupsd.conf
>>>> in /etc/cups. Or something you have done with the networking setup.
>>>
>>> The default cupsd.conf has the line
>>>
>>>  Listen localhost:631
>>>
>>> Does yours?
>>
>> A simple enough question. Well?
>>
> 
> 

[toc] | [prev] | [next] | [standalone]


Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user


csiph-web