From serando at sunrise.ch  Tue Jun  1 05:00:29 2021
From: serando at sunrise.ch (serando)
Date: Tue, 1 Jun 2021 14:00:29 +0200
Subject: [cups] Tea4Cups question
In-Reply-To: <7da461c6-0c23-88cb-3872-4a6c1d519e4c@sunrise.ch>
References: <bd1376d7-1b70-6369-8bbb-d354e2b610ae@sunrise.ch>
 <6742C69D-0391-4164-B893-00A52D961266@web.de>
 <7da461c6-0c23-88cb-3872-4a6c1d519e4c@sunrise.ch>
Message-ID: <1f2aeb84-36ac-9687-2fde-26f1d543498a@sunrise.ch>

Please allow me another Tea4Cups question:


I have created my virtual printer this way:
|lpadmin -p pretendq -v tea4cups:/socket://192.168.7.200:9100 -E -P 
/etc/cups/ppd/ENVY-5540-series.ppd

So I have now a virtual printer, with the same properties like my real 
printer has. And yes, it works ||in principle.
|
|But:
When I set the property of this virtual printer||||to "high quality 
greyscale" (or also "Black only greyscale"), I would expect, that now I 
get in the folder ...
/var/spool/cups/
... a greyscale d-pdf-file.

But it's nevertheless coloured.

Question: Why do the settings |||"high quality greyscale" / "Black only 
greyscale" not have any effect?

|Thank you.
|

From helgeblischke at web.de  Tue Jun  1 06:15:01 2021
From: helgeblischke at web.de (Helge Blischke)
Date: Tue, 1 Jun 2021 15:15:01 +0200
Subject: [cups] Tea4Cups question
In-Reply-To: <1f2aeb84-36ac-9687-2fde-26f1d543498a@sunrise.ch>
References: <bd1376d7-1b70-6369-8bbb-d354e2b610ae@sunrise.ch>
 <6742C69D-0391-4164-B893-00A52D961266@web.de>
 <7da461c6-0c23-88cb-3872-4a6c1d519e4c@sunrise.ch>
 <1f2aeb84-36ac-9687-2fde-26f1d543498a@sunrise.ch>
Message-ID: <EF48C3B0-76CC-4B19-A2F2-8D5CB270C9FA@web.de>



> Am 01.06.2021 um 14:00 schrieb serando <serando at sunrise.ch>:
> 
> Please allow me another Tea4Cups question:
> 
> 
> I have created my virtual printer this way:
> |lpadmin -p pretendq -v tea4cups:/socket://192.168.7.200:9100 -E -P /etc/cups/ppd/ENVY-5540-series.ppd
> 
> So I have now a virtual printer, with the same properties like my real printer has. And yes, it works ||in principle.
> |
> |But:
> When I set the property of this virtual printer||||to "high quality greyscale" (or also "Black only greyscale"), I would expect, that now I get in the folder ...
> /var/spool/cups/
> ... a greyscale d-pdf-file.
> 
> But it's nevertheless coloured.
> 
> Question: Why do the settings |||"high quality greyscale" / "Black only greyscale" not have any effect?
> 
> |Thank you.
> |
> _______________________________________________

Well, the /var/spool/cups directory contains the **original** files. 
The result files are generated by the filter chain which has been set up by the create_job function of cups.

If all settings are correct, the real printout on the real physical printer should be grayscale.

Helge


From guru at unixarea.de  Tue Jun 22 06:11:18 2021
From: guru at unixarea.de (Matthias Apitz)
Date: Tue, 22 Jun 2021 15:11:18 +0200
Subject: [cups] installing and running CUPS as an unprivileged user
Message-ID: <YNHhdphYxwPoCv2e@c720-r368166>


Hello,

The background of my question is, that our IT department does not want
to give us (the development team) root or sudo access to our development
SuSE Linux servers anymore. 

That's why we are undertaking currently an investigation how
our Library Management System could be developed, deployed (also to customers)
and started as an ordinary user (once the DBS PostgreSQL is started as root).

There are still some open questions in our own software, but one mayor issue is
CUPS itself. We are compiling CUPS from source with a destination directory
which can be owned by an ordinary user, so in principle the deployment
could be done that way. Ofc currently some files are set to be owned by
root:lp and some dirs / spooling areas have special perms as well. Also the
standard LISTEN port 631 could also only created by root.

My question here to the group is: was such changes for CUPS already
investigated and changes undertaken by CUPS implementers? Is it worth to
follow such path or should we better say to IT: for CUPS no way (as for
PostgreSQL or Sybase DBS).

Thanks in advance for any comments or pointers.

	matthias (CUPS user since ages)
-- 
Matthias Apitz, ✉ guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
Covid 19 in numbers:
PR of China: 1.900 million habitants / 0,1 million cases /  5.000 cases of death
Germany:        83 million habitants / 3,1 million cases / 90.000 cases of death

From listen at vordruckleitverlag.de  Tue Jun 22 07:02:43 2021
From: listen at vordruckleitverlag.de (=?UTF-8?B?SsO2cmcgVGjDvG1tbGVy?=)
Date: Tue, 22 Jun 2021 16:02:43 +0200
Subject: [cups] installing and running CUPS as an unprivileged user
In-Reply-To: <YNHhdphYxwPoCv2e@c720-r368166>
References: <YNHhdphYxwPoCv2e@c720-r368166>
Message-ID: <8d86b0b8-7d2c-4147-a85a-1625286c47ce@vordruckleitverlag.de>

Am 22.06.21 um 15:11 schrieb Matthias Apitz:
> 
> Hello,
> 
> The background of my question is, that our IT department does not want
> to give us (the development team) root or sudo access to our development
> SuSE Linux servers anymore.
> 
> That's why we are undertaking currently an investigation how
> our Library Management System could be developed, deployed (also to customers)
> and started as an ordinary user (once the DBS PostgreSQL is started as root).
> 
> There are still some open questions in our own software, but one mayor issue is
> CUPS itself. We are compiling CUPS from source with a destination directory
> which can be owned by an ordinary user, so in principle the deployment
> could be done that way. Ofc currently some files are set to be owned by
> root:lp and some dirs / spooling areas have special perms as well. Also the
> standard LISTEN port 631 could also only created by root.
> 
> My question here to the group is: was such changes for CUPS already
> investigated and changes undertaken by CUPS implementers? Is it worth to
> follow such path or should we better say to IT: for CUPS no way (as for
> PostgreSQL or Sybase DBS).
> 
> Thanks in advance for any comments or pointers.
> 
> 	matthias (CUPS user since ages)
> 

Hello,

as you mentioned: there are a lot of security issues with this idea. 
I've never heard someone tryin' to circumvent root privileges at this 
place. As printers are treated as (special) files you would have a lot 
of problems to secure this. And as I think, you won't have the right to 
create a special user with the rights to operate cups too, if you aren't 
root. And operate this by ordinary user: I would say: never. Such a user 
would need rights to write directly to special files, what is definitely 
a horrible idea, imagine you have the dev/<disk> files here and other 
devices...

It might be a bad but possible idea to create a special write_to_file 
backend piping to real backends, what does not say, who creates the 
devices for real printing.

You can create the spool dirs in users homedir (man 5 cups.files) and 
you can try to build some autoconfiguring mechanism, which builds an 
cups printer entry by using lpadmin from a own created "printers.conf" 
but this mechanism will need root, at least "lp" privileges.

If there's no way to get root rights: someone must install the servers: 
he shall by advised to install cups with cupsd.conf and cups.files 
templates you created. You put all the privilege excalation things here, 
so your unprivileged user can manage cups then. Ugly...

-- 
cu

jth

Death penalty in numbers:
==========================
PR of China: 1.900 million habitants  / some 100 cases of death, more 
hidden ones...???

Germany: 83 million habitants / 0 cases of death, there may be hidden 
ones by secret services, but a few

From carsten.rose at math.uzh.ch  Fri Jun 25 11:13:59 2021
From: carsten.rose at math.uzh.ch (Carsten Rose)
Date: Fri, 25 Jun 2021 20:13:59 +0200
Subject: [cups] name of shared printers changed between Ubuntu 16.04/CUPS
 v2.1.3 and Ubuntu 20.04/CUPS v2.3.1
Message-ID: <3910e55d-4331-08f7-acb1-92b6e2ef76b8@math.uzh.ch>

Dear all

We're migrating some desktop hosts from Ubuntu 16.04 to 20.04 and 
realized that the printer names changed on Ubuntu 20.04. We use a 
central CUPS printserver and all clients connects to them.

Printserver is `print2` (still Ubuntu 16.04), local printer names are 
k34, k40, k49color and so on.

CUPS client on Ubuntu 16.04 shows (ok): k34, k40, k49color

CUPS client on Ubuntu 20.04 shows (bad):
   K34_HP_LJ_P3015_print2
   K40_HP_LJ_P3015_print2
   K49_HP_OfficeJet_Pro_X451dw_Color_print2

Any hint on how to remove the printer type and print server name from 
the printer name on the CUPS client?

On Ubuntu 16.04: CUPS Version v2.1.3
On Ubuntu 20.04: CUPS Version v2.3.1

Any hints are appreciated.

Thanks
Carsten




From fsjjeff at gmail.com  Mon Jun 28 12:39:57 2021
From: fsjjeff at gmail.com (Jeff Dyck)
Date: Mon, 28 Jun 2021 12:39:57 -0700
Subject: [cups] iOS 15 AirPrint changes
Message-ID: <283A1EC7-224E-4048-931A-21EF27B84853@gmail.com>

Anyone had a look at iOS 15 with a CUPS server yet?  I tried on Friday and it seems iOS has made some big changes to printing this time around, some good but a few issues have come up for me that I’m wondering if anyone else has looked at?

On the positive side, there are a more printer features supported.

On a test Xerox Altalink B8155 shared from CUPS 2.3.3, I get the following new / changed options:

- Paper size: with a huge list of possible page sizes, including things like envelopes
- Orientation: landscape or portrait
- Media and quality:
	- Feed from => Auto, Tray 1 - 5
	- Media Type => Auto, Card stock, Envelope, Labels, Letterhead, etc
	- Print Quality => Draft - Normal - Best
- Finishing Options (Options like staple and hole punch move from a root level check box to a more detailed submenu) 
	- Staple => None, Single (top left), Single (bottom left), Double (left), Double (top)
	- Punch = > None, Double (left), Double (top), Triple (left), Triple (top)
	- Output bins => Right, Auto, Center, Left

Unfortunately, there are also a couple of issues:

- Unlike previous versions of iOS, I don’t get asked for user name / password when I try to print.  Instead I get a dialog saying: Account information required for “printer name” Enter the account information in the print options.  I can’t find anywhere to enter these credentials though, so currently I cannot print.  

- With the new Paper size options, it doesn’t choose something like Letter as the default pages size.  On a test Xerox Altalink B8155 it chooses an Envelope size, and an on a test Altalink C8055 it chooses B6.  I can’t currently print so it may save this after the first time, but currently every time I go to the print dialog I have to redo this choice.

Jeff