https://bugzilla.novell.com/show_bug.cgi?id=464364 User jsmeix@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=464364#c4 --- Comment #4 from Johannes Meixner <jsmeix@novell.com> 2009-01-09 07:14:11 MST --- Michal, some thoughts what I think how it should be implemented: According to http://www.suse.com/~ug/autoyast_doc/Profile.html "The control file ... consists of sets of resources ... including support for ... large embedded ..." I think the easiest and most reliable way to clone a CUPS config which was made by YaST is to simply have the files /etc/cups/cupsd.conf /etc/cups/printers.conf /etc/cups/client.conf /etc/cups/ppd/*.ppd embedded in the AutoYaST control file and a binary value whether or not the cupsd should be started during system boot. The current YaST writes only to those files. Perhaps it is better to be future-proof and save that it also works when non-YaST tools were used (in particular after manual changes) to simply tar all files in /etc/cups/ I would perefer this if the AutoYaST control file can hold such big amounts of data. I think the biggest amount of data is /etc/cups/ppd/*.ppd when there are many queues set up. To save space in the AutoYaST control file one could somehow compress the files (but the compressed data must be valid to be included in a XML file). Then on the target system all what is to do is to make backups of the existing files on the target system and then replace them with the files from the AutoYaST control file and finally restart the cupsd or stop and disable it depending on the binary value whether or not the cupsd should be started during system boot. Currently I don't know what is better: Overwrite only the content (and keep owner, group and permissions of the original files of the target system) or store also owner, group and permissions in the AutoYaST control file and set those? Currently I know about the following special case: It must be done for usb and hp DeviceURIs for USB printers like usb://HP/DESKJET%20950C?serial=ES03T1C1NVJM and hp:/usb/DeskJet_950C?serial=ES03T1C1NVJM Even when the same model is connected to the target system, each particular device will have a different serial number so that this DeviceURIs cannot work on the target system. I tested if it also works without the serial number, i.e.: usb://HP/DESKJET%20950C and hp:/usb/DeskJet_950C Regarding usb:/ DeviceURIs: Unfortunately usb://HP/DESKJET%20950C does no longer work. The usb backend simply waits forever. Regarding hp:/usb/ DeviceURIs: Unfortunately hp:/usb/DeskJet_950C does also no longer work. I get in /var/log/messages ----------------------------------------------------------- Jan 9 14:49:21 nelson DeskJet_950C: io/hpmud/musb.c 1058: unable to open hp:/usb/DeskJet_950C ----------------------------------------------------------- Therefore queues with usb:/ or hp:/usb/ DeviceURIs cannot be supported by AutoYaST. This means that no queues for USB printers can be supported by AutoYaST. All what belongs to such queues might therefore be either excluded from the AutoYaST control file (which is a bit complicated to be implemented). Or we have all stuff in the AutoYaST control file and show a notification message to the user which DeviceURIs cannot work on the target system and that he must adapt them on the target system to the actual value there via [Edit] in the YaST printer module. I prefer the latter because [Edit] is easy to do and all the rest (in particular the selected driver and perhaps whatever driver specific settings in the PPD file in /etc/cups/ppd/*.ppd are not lost for the user. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.