Mailinglist Archive: opensuse-bugs (13069 mails)

< Previous Next >
[Bug 464364] yast2-printer has no autoyast support
  • From: bugzilla_noreply@xxxxxxxxxx
  • Date: Fri, 9 Jan 2009 07:14:12 -0700 (MST)
  • Message-id: <20090109141412.546CBCC7D4@xxxxxxxxxxxxxxxxxxxxxx>
https://bugzilla.novell.com/show_bug.cgi?id=464364

User jsmeix@xxxxxxxxxx added comment
https://bugzilla.novell.com/show_bug.cgi?id=464364#c4





--- Comment #4 from Johannes Meixner <jsmeix@xxxxxxxxxx> 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.

< Previous Next >
References