Bug 47843 - Switching printer model to "Misc/None" on an already created printer, CUPS stays untouched
Switching printer model to "Misc/None" on an already created printer, CUPS st...
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: Printserver
UCS 4.3
Other Linux
: P5 normal (vote)
: UCS 4.3-3-errata
Assigned To: Felix Botner
Erik Damrose
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-09-20 16:09 CEST by Christina Scheinig
Modified: 2023-08-15 16:36 CEST (History)
4 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 3: Simply Wrong: The implementation doesn't match the docu
Who will be affected by this bug?: 2: Will only affect a few installed domains
How will those affected feel about the bug?: 2: A Pain – users won’t like this once they notice it
User Pain: 0.069
Enterprise Customer affected?:
School Customer affected?: Yes
ISV affected?:
Waiting Support: Yes
Flags outvoted (downgraded) after PO Review:
Ticket number: 2018091421000617
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christina Scheinig univentionstaff 2018-09-20 16:09:03 CEST
When a new  printer share is as model "Misc/None" created the created printer is shown as "Local Raw Printer" in cups. If the printer has already been created with a different model and is then switched to "Misc/None", nothing happens in CUPS. The previously set model is retained.
Switching to a different model or driver, CUPS gets this.
Comment 1 Christina Scheinig univentionstaff 2018-09-21 11:34:18 CEST
This issue is not a real limitation, but it leads to inconsistencies over time and especially to confusion. 

The customer would like to have a fix in 4.3-3. In this case I set the waiting for support flag.
Comment 2 Moritz Bunkus 2018-11-07 09:38:45 CET
I think this issue is a symptom of bug 47435. In current systems there's a symlink "/usr/share/cups/model/ppd" → "/usr/share/ppd". The directory listener module "cups-printers" calls "lpadmin" with the new PPD to install with the relative file name as stated in the LDAP server, e.g. "foomatic-rip/Apple-ImageWriter-iwhi.ppd", which "lpadmin" expands to "/usr/share/cups/model/foomatic-rip/Apple-ImageWriter-iwhi.ppd" — which doesn't exist.

As stated in 46435, "/usr/share/cups/model" should already be a symlink to "/usr/share/ppd", and if it were "lpadmin" would be able to find the PPD.

As it cannot find the PPD, "lpadmin" aborts the printer modification command without applying any of the other changed properties. This means none of the changes made to the printer object in the LDAP directory ends up in "printers.conf".

After manually changing "/usr/share/cups/model" to be a symlink to "/usr/share/ppd" things start working again, both changing the PPD as well as any other property.

My system was set up back in the days of… 4.1 or even 4.0, I don't quite remember. It was updated regularly via "univention-upgrade".

A forum thread describing this issue is [1].

[1]  https://help.univention.com/t/cups-ppd-und-timing-problem/9988
Comment 3 Felix Botner univentionstaff 2018-12-20 16:15:36 CET
set model raw for "None" or "smb"

53807ec93638242027c87b260fd21633c463da84 - univention-printserver
f9f0102e36d4f335c5082d98fd71cdbda3f0098f - yaml
d0463e0ab14e2555725e9645e61fdf72a31d1893 - merged to 4.4-0
Comment 4 Erik Damrose univentionstaff 2019-01-08 12:17:24 CET
OK: setup new printer with misc/{none,smb}
OK: switch existing printer to misc/{none,smb}
OK: switch existing printer from misc/{none,smb} to another model

OK: yaml
OK: merge to 4.4-0, package build

Verified
Comment 5 Arvid Requate univentionstaff 2019-01-09 13:27:09 CET
<http://errata.software-univention.de/ucs/4.3/397.html>
Comment 6 worldscanner 2023-08-15 16:36:53 CEST
Thank you for addressing this issue with switching the printer model to 'Misc/None.' The detailed explanation of the problem and the steps taken to resolve it are much appreciated. I was particularly interested in the symlink solution mentioned by Moritz Bunkus and how it led to the resolution of the problem. It's great to see that the fix has been verified and merged. Could you provide any additional insights into how this fix might impact other related functionalities in the system? Thanks again for your hard work on this! this problem is very relavent to my https://scanse.io/printers/best-11X17-printer/