Possible to set printer devmode using samba3-python?

daniel.jarboe at custserv.com daniel.jarboe at custserv.com
Wed Nov 12 17:34:15 GMT 2003

> Windows stores these settings in the registry (and not at 
> *one* obvious spot, IIRC).
> Samba stores them in *.tdb files.

Yup, the common link is that on both platforms they are both
via rpc spoolss calls, I shouldn't have to worry about how the backend
stores them.

> > it would be a big time-saver and less error prone.  Also, for new
> > printers to be installed, I'd like our print admin to have the
> > capability of installing/configuring/shareing the printer 
> on a windows
> > pc like they've always done,
> But Samba's support for the "APW" functions in uploading drivers to
> its [print$] share by an Admin sitting in front of his workstation
> already provide for that, no? (There are only minor differences in
> starting/handling the APW which they need to be taught...)

Well, we've had problems with some printer drivers and samba's APW.  And
we already have enough differences to teach (routing print queues, etc),
that if we can leave the add printer process identical except for a
webpage to provide some info and press "Copy Printer", that our
from Windows to a Samba/Linux print server would really be much better
it, I think.

Btw, have you found any way to route print queues on a samba/Cups
installation like w2k?  What I'm resorting to now is the samba queues
pointing to cups classes with a destination printer in the class... and
reroute print for the samba queue one needs to remove the cups printer
that cups class, and add a different printer to the cups class.  Is
a better way?  The bad thing about this, is that whoever will be
responsible for rerouting print will be required to use a different
interface than the windows-style print window they are accostomed to :(.

> > then trigger a process on our samba server
> > to use smbclient to retrieve the drivers from their PC, rpcclient
> > adddriver the printer to samba,
> That's not enough: You need to make sure your print subsystem (CUPS?)
> provides (at least "raw") queues first, and that Samba 
> recognizes these
> queues. Otherwise each "rpcclient setdriver" call will fail (while
> "rpcclient adddriver" may even succeed)..

Yes, you are right, and I know.  I left out the print sub-system part of
this equation because it didn't directly relate to the problems I was

> > Our users require functionality available in vendor-provided print
> > drivers that don't take kindly to being remotely uploaded to a samba
> > server using print$,
> Why? What's the problem? Have you filed any bug report at Samba's
> bugzilla?

The problems usually manifest themselves in one of two ways... in one
case though setting printer properties works fine, print jobs that use
this driver end up with wingdingish looking characters.  More commonly,
"problem" drivers cause the the client's spooler to crash when first
attempting to manipulate the printing properties.  I haven't had any
problems with drivers included with Windows, the current documentation
works well for them, but when the vendor's drivers are required, things
are more prone to failure.  In the past I've been in some communication
with Jerry, but without resolution to the problem :(.  I guess what I'm
trying to do is jump-start these drivers, in a way, by setting
everything to a known-working configuration generated by Windows

> My fear is that if there are still bugs and deficiencies with the
> MS-RPC functions in Samba regarding SPOOLSS, and these are preventing
> your driver from upload and store in the *.tdbs via APW, the same
> bugs might prevent you from "duplicating" the Windows *.reg chunks
> into the Samba *.tdb files...
> Probably the time and effort is better put to use by helping the
> Samba developers to trace down the last major bugs and deficiencies
> in the RPC/SPOOLSS code?

The samba 3 python helpers seem like a good way to find these problems
if they are actually affecting me.

There's more in other messages in this thread, and I think we need info
from Tim Potter :).  Thank you very much for taking the time to dig into
the problem some.  Any ideas about the samba queues and routing cups

~ Daniel


This message is the property of Time Inc. or its affiliates. It may be
legally privileged and/or confidential and is intended only for the use
of the addressee(s). No addressee should forward, print, copy, or
otherwise reproduce this message in any manner that would allow it to be
viewed by any individual not originally listed as a recipient. If the
reader of this message is not the intended recipient, you are hereby
notified that any unauthorized disclosure, dissemination, distribution,
copying or the taking of any action in reliance on the information
herein is strictly prohibited. If you have received this communication
in error, please immediately notify the sender and delete this message.
Thank you.

More information about the samba-technical mailing list