2nd attempt: Modify location of printerdriverfiles
kpfeifle at danka.de
Thu Nov 28 21:18:00 GMT 2002
> Message: 2
> Subject: 2nd attempt: Modify location of printerdriverfiles
> Date: Thu, 28 Nov 2002 11:21:47 +0100
> From: <Ralf.Kaetzler at SenGSV.verwalt-berlin.de>
> To: <samba-technical at lists.samba.org>
> Hi! Maybe this time someone can give me a hint - or is my english that
> bad - so that nobody can catch the point - or my question is posted to
> the false list? Please each answer is welcome! Thank you!
>>Hello, Samba-Team, hello samba-freaks!
>>I like to use a samba-server as printer-server for about >500 users
>>with ~ 40 different printers.
>>The client OS is NT4 or XP. The problem I encountered is that there are
>>printerdrivers out there which use for different models dlls with the
>>same name but the dlls are not compatible - great!! - ! So only the
>>last installed printer works flawless, because the dll for the other
>>model is overwritten during
>>My question: Is there a tool, which allows save tempering with the
>>*.tdb, to change the path to the driverfiles or to change the behavior
>>to rpc "getdriverinfo"?
>>This way it would be possible to create an own
>>driver-directory-structur and all those printerdriver related problems
> Btw.: Redhat 8.0 and latest Samba.
> Calling the printermanufactor is hopeless. The only answer I got is: =
> This must be a problem with your OS... thanks for your help. [:(]
may I suggest a radically different approach to your problem?
* Let the Windows Clients use a PostScript driver, to produce
PostScript as their print output sent towards the Samba print
server (just like any Linux or Unix Client would also use
PostScript to send to the server...)
* make the Unix printing subsystem which is underneath Samba
convert the incoming PostScript files to the native print
format of the target printers (would likely be PCL?
I understand you have mainly HP models?)
* You're afraid, that this would just mean a *Generic* PostScript
driver for the clients? With no Simplex/Duplex selection,
no paper tray choice? But you need them to be able to set up
their jobs, ringing all the bells and whistles of the printers?
--> Not possible with traditional spooling systems!
--> But perfectly supported by CUPS (which uses "PPD" files to
describe how to control the print options for PostScript and
non-PostScript devices alike...
CUPS PPDs are working perfectly on Windows
clients who use Adobe PostScript drivers (or the new CUPS
PostScript driver for Windows NT/2K/XP). Clients can use
them to setup the job to their liking and CUPS will use
the received job options to make the (PCL-, ESC/P- or
PostScript-) printer behave as required.
* You want to have the additional benefit of page count logging
and accounting? In this case the CUPS PostScript driver
is the best choice (better than the Adobe one).
* You want to make the drivers downloadable for the clients?
"cupsaddsmb" is your friend. It will setup the [print$]
share on the Samba host to be ready to serve the clients
for a "point and print" driver installation...
"What strings are attached?", I hear you asking...
You are right, there are some. But, given the sheer CPU power
you can buy nowadays in German supermarkets, these can be
The strings: Well, if the
CUPS/Samba side will have to print a *lot* onto 40 printers
serving 500 users, you probably will need to set up a second
server (which can do automatic load balancing with the first
one, plus a degree of fail-over mechanism). Converting the
incoming PostScript jobs, "interpreting" them for
non-PostScript printers, amounts to the work of a "RIP"
(Raster Image Processor) done in software. This requires
more CPU and RAM than for the mere "raw spooling" task
your current setup is solving... It all depends on the
avarage and peak printing load the server should be
able to handle....
If you want, I can point you to or give you more more
info in private mail.
More information about the samba-technical