jamescartwright: 14:51 Dec 01, 2012
Since upgrading to 1.5.3 (the version in Debian testing), we have been unable to stop cupsd overwriting printers.conf.
The issue is that we have a fair few printers, and our config management system tracks which printers are managed by which hosts, and generates printers.conf accordingly. In version 1.4.4 this worked fine. But with 1.5.3 cupsd insists on overwriting the file. This results in a never-ending battle between our config management system and cupsd over the content of printers.conf.
The version of printers.conf that is generated by cups advises the sysadmin, via a comment near the top of the file, not to edit the file while cupsd is running. So we made sure cupsd was stopped while we put in place the version of the file that we wanted. But on restarting cupsd, it still overwrote printers.conf.
We absolutely do not want to interactively configure cups everywhere via its web interface, nor via lpadmin, and we don't really want to try and script lpadmin in an automated way. It just shouldn't be that hard - we should be able to generate a declaration of the printers in a config file and have cupsd respect that.
|
jamescartwright: 14:56 Dec 01, 2012
By the way, printers.conf(5) says:
It [...] is generated
automatically by the cupsd(8) program when printers are added or
deleted.
so it seems contrary to this manpage that it is being automatically generated when printers are not being added or deleted. The rest of printers.conf(5) reads like a normal section 5 manpage, the clear implication being that the canonical version of the file is maintained by the sysadmin, and the sysadmin's changes should not be backed out automatically by the application.
|
mike: 22:20 Dec 01, 2012
James,
You really can't assume that printers.comf will remain unmodified. We do a lot to minimize the number of changes to the file, but ultimately it is a combined state and configuration file that will change regularly, and has been since CUPS 1.0.
I'm thinking this will end up as a feature request to split the state and config info, something that has been requested before. But I think long term we will migrate to a binary format and provide utilities to export and import config data as needed.
|
mike: 10:29 Jan 11, 2013
Feature request for some future release.
|