Bug 51605

Summary:	cleanup /var/cache/univention-printserver/ after release update
Product:	UCS	Reporter:	Dirk Schnick <schnick>
Component:	Printserver	Assignee:	UCS maintainers <ucs-maintainers>
Status:	NEW ---	QA Contact:	UCS maintainers <ucs-maintainers>
Severity:	normal
Priority:	P5	CC:	botner, markus.daehlmann, requate, scheinig, schwardt
Version:	UCS 4.4
Target Milestone:	---
Hardware:	Other
OS:	Linux
What kind of report is it?:	Bug Report	What type of bug is this?:	4: Minor Usability: Impairs usability in secondary scenarios
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.091	Enterprise Customer affected?:	Yes
School Customer affected?:	Yes	ISV affected?:
Waiting Support:		Flags outvoted (downgraded) after PO Review:
Ticket number:	2020070121000506, 2016030807000045, 2016031421000328, 2022090621000553	Bug group (optional):
Max CVSS v3 score:
Bug Depends on:	40904
Bug Blocks:

Description Dirk Schnick

2020-07-03 10:35:36 CEST

+++ This bug was initially created as a clone of Bug #40904 +++

Seen in several customer environments. 

Somehow some old printer change commands survived in the cups command cache /var/cache/univention-printserver/, e.g.

/var/cache/univention-printserver/1437651522.287814.sh
/usr/sbin/univention-lpadmin '-u' 'allow:all' '-o' 'auth-info-required=none' '-p' 'printer1' '-m' 'postscript/Kyocera/es/Kyocera_Mita_FS-1900_es.ppd.gz' '-
v' 'socket://10.15.1.1:9100' '-E'

The ppd 'postscript/Kyocera/es/Kyocera_Mita_FS-1900_es.ppd.gz' is totally outdated and lpadmin fails. 

During start of /etc/init.d/cups these commands are executed and removed if successful, but as the ppd is outdated and lpadmin fails, the command above never gets removed but restarted every time executed the cupsd is (re)started.

Now somebody makes a change on printer1 (activates quota, changes ip address), after some time cups is restarted and the command cache executed. Although the command in the cups cache fails, it still reverts some changes of printer1.

We may need to cleanup /var/cache/univention-printserver/ at some point.
Not sure when.

Ticket 2016030807000045
Ticket 2016031421000328

Comment 1 Dirk Schnick

2020-07-03 10:38:53 CEST

One of the first customers reports the problem today. Due to years of using UCS, various "corpses" have accumulated, which (want to) set outdated configurations. Details see Ticket

Comment 2 Sönke Schwardt-Krummrich

2021-10-18 13:13:30 CEST

One of our customers reported that even if the lpadmin command fails, some printer settings might get changed or printers get recreated. And since the files in /var/cache/univention-printserver/ do not get removed automatically, manual changes to printers are regulary overwritten resp. unwanted printers get recreated every time when cups is restarted (→ logrotate).

Reported again by the same customer as in ticket 2020070121000506.

Comment 3 Sönke Schwardt-Krummrich

2021-10-18 13:14:21 CEST

Maybe we should implement a diagnosis module that warns about these files?

Comment 4 Markus Dählmann 2022-09-08 12:23:07 CEST

Still an everyday PITA here....
Maybe this could be solved when support for driverless printing support is (hopefully) added to UCS?
On the LDAP side it would be as simple as the last comment in this bug, we already use that "hack":
https://forge.univention.org/bugzilla/show_bug.cgi?id=51681

It would probably just require some adjustments and better error handling to the cups-printers listener module.