Possible to set printer devmode using samba3-python?

[Kurt Pfeifle]

daniel.jarboe at custserv.com wrote:

>>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
> retrieved/set via rpc spoolss calls,

As you see from my previous postings, I wasn't aware that any such
functionality (retrieve/place print option settings) were anywhere
near completion in rpcclient command(s) or spoolss calls (nor that
somebody had worked on this at all).

> 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
> transition
> from Windows to a Samba/Linux print server would really be much better
> for
> it, I think.
> 
> Btw, have you found any way to route print queues on a samba/Cups
> installation like w2k? 

I am not exactly sure what you mean by "route print queues". Could
you please explain?

> What I'm resorting to now is the samba queues
> all
> pointing to cups classes with a destination printer in the class... and
> to
> reroute print for the samba queue one needs to remove the cups printer
> for
> that cups class, and add a different printer to the cups class.  Is
> there
> 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 :(.
> 

If you teach them to use a KDEPrint interface, they will be very
easily taught to re-direct a (not yet finished) printjob to another
printer. [This provides even for changing print options, allowing
even to change from a PostScript to a PCL- or InkJet-Printer -- if
you use the CUPS PostScript driver on the clients, not the vendor-
provided ones. If you have the vendor-drivers, it works of course
only for a re-route printer which is equal or similar as the original
target.]

The most easy setup for this is to install one box with a current
KDE. Here, use the "NX server" from www.nomachine.com to provide
remote X access. The clients need the "NX client". It can be setup
to only start the "kjobviewer" on the KDE box and display it in a
native Window on the Win clients. kjobviewer can be connected to
the CUPS/Samba server (which may be installed without any trace
of KDE present there). kjobviewer allows users to right-click on
any queued job and re-directing it to another printerqueue. No need
to change any setup of CUPS.... No need for CUPS classes containing
a single printer....

You can set it up for Win users or admins to just have 1 icon on
their desktops named "Printqueue Administration". They don't even
need to be aware that it is a remote Linux application that they
are seeing and running....

Nomachine's development work to compress remote X and make it
so much more efficient is really impressive. (I can even run a
fullscreen KDE session over a 9600 baud GSM modem link and it
is faster than a local crosslink TightVNC session. With an ISDN
or 56.000 baud modem link it is hardly distinguishable from a
local session, and you can have OpenOffice, e-Mail and a web
browser running/displaying at full speed).

[ Oh, and by the way, their core libraries and extensions to the
X protocol are GPL. Plus they are offering all active developers
of other OpenSource/GPL projects free (as in beer) licenses of
their commercial product. So, you Samba developers, after you
testdrove it, just write a mail to Gian Fillipo Pinzari,
<pinzari at nomachine.com> if you are interested.....]

I can send you a screenshot of kjobviewer on a native WinXP
desktop, running over "NX" connection, if you give me 1 day or
2..... Just tell.

> 
>>>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
> experiencing.
> 
> 
>>>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. 

What are "problem" drivers in your experience? How many of them do you
know?

Is there any common trace to be aware of? Like "all of them are PCL
drivers, running in Kernel mode (version 2 drivers)" or some such?
Can you name them (if you want in private mail)?

> 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
> client/servers.
> 
> 
>>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
> print?
> 
> Thanks,
> ~ Daniel

Cheers,
Kurt