2nd attempt: Modify location of printerdriverfiles
Message: 2 > Subject: 2nd attempt: Modify location of printerdriverfiles Date: Thu, 28 Nov 2002 11:21:47 +0100 From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> > 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! My question/problem: 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 driverinstall. 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 are gone... Greetings Ralf 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. [:(] Greetings Ralf Hi, Ralf, 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 overcome easily. 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. Cheers, Kurt
Re: 2nd attempt: Modify location of printerdriverfiles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 28 Nov 2002, "Kätzler, Ralf" wrote: > 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 Can you give more details on how you came up with this conclusion? > - great!! - ! So only the last installed printer works flawless, because > the dll for the other model is overwritten during driverinstall. My This is basically a Windows design flaw which driver manufacturers have to very careful with. > 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 > are gone... No. Not really, but what you would need to do is to modify the DRIVER_INFO_3 structure to reflect where you placed the files. > Calling the printermanufactor is hopeless. The only answer I got is: > This must be a problem with your OS... thanks for your help. :( Was this HP? If so contact me off list. cheers, jerry -- Hewlett-Packard- http://www.hp.com SAMBA Team -- http://www.samba.org GnuPG Key http://www.plainjoe.org/gpg_public.asc ISBN 0-672-32269-2 "SAMS Teach Yourself Samba in 24 Hours" 2ed "You can never go home again, Oatman, but I guess you can shop there." --John Cusack - "Grosse Point Blank" (1997) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iD8DBQE95iMjIR7qMdg1EfYRAmkWAJ9zynR81D2ZwbabzanjNkun01J3QACfdYAA fIhCGZWa/nmZXLFTXUNvA8U= =9lxJ -END PGP SIGNATURE-
Re: RE RE: 2nd attempt: Modify location of printerdriverfiles
Uhm not sure either if this will work, but you could try to use %S as substitution This way you may have a directory for each printer name ... of course if you rename a printer you may get into troubles, but it is unlikely that you like changing printer names every day :-) Here it is a list of macros you may think to try: These substitutions are mostly noted in the descriptions below, but there are some general substitutions which apply whenever they might be relevant. These are: %S the name of the current service, if any. %P the root directory of the current service, if any. %u user name of the current service, if any. %g primary group name of %u. %U session user name (the user name that the client wanted, not necessarily the same as the one they got). %G primary group name of %U. %H the home directory of the user given by %u. %v the Samba version. %h the Internet hostname that Samba is running on. %m the NetBIOS name of the client machine (very use- ful). %L the NetBIOS name of the server. This allows you to change your config based on what the client calls you. Your server can have a "dual personality". Note that this paramater is not available when Samba listens on port 445, as clients no longer send this information %M the Internet name of the client machine. %N the name of your NIS home directory server. This is obtained from your NIS auto.map entry. If you have not compiled Samba with the --with-automount option then this value will be the same as %L. %p the path of the service's home directory, obtained from your NIS auto.map entry. The NIS auto.map entry is split up as "%N:%p". %R the selected protocol level after protocol negotia- tion. It can be one of CORE, COREPLUS, LANMAN1, LANMAN2 or NT1. %d The process id of the current server process. %a the architecture of the remote machine. Only some are recognized, and those may not be 100% reliable. It currently recognizes Samba, WfWg, Win95, WinNT and Win2k. Anything else will be known as "UNKNOWN". If it gets it wrong then sending a level 3 log to [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]> should allow it to be fixed. %I The IP address of the client machine. %T the current date and time. %$(envvar) The value of the environment variable envar. There are some quite creative things that can be done with these substitutions and other smb.conf options. On Thu, 2002-11-28 at 12:16, "Kätzler, Ralf" wrote: > I think the workaround will not work. I can´t predict which user on which machine >will use which printer. > Our users have in most case max. two networkprinters connected - for our luck long >physikal ways prevent the "need" to connect to more printers. > We have created a small script which erases all printerrelated registry-entries and >files on the client. > A user or admin can run this script and the client is clean for a new >printer-installation. This way we work around the naming-problem on the client. (The >users *theoretical* know which printers cannot be installed at the same time). > Of course this works not on the printserver :)). > > If there is no other solution, we have to "fight" another skirmish with HP ... maybe >we can convince them to take more care when naming there files.. > ... on the other hand maybe someone is happy to implement the needed variables to >the samba-core?? :) > The moto would be: Power is nothing without control > > Simo: Thanks for your answer. > > Have a nice day. > Ralf > > > -Ursprüngliche Nachricht- > > Von: Simo Sorce [mailto:[EMAIL PROTECTED]] > > Gesendet: Donnerstag, 28. November 2002 11:34 > > An: Kätzler, Ralf > > Cc: [EMAIL PROTECTED] > > Betreff: Re: 2nd attempt: Modify location of printerdriverfiles > > > > > > That would change nearly nothnig, because the printer drivers will be > > copyed in the same structure on the client and there you will find the > > same naming problem. > > > > It is a known windows problem (just faces some day ago with > > drivers for > > 2 HP laser printers on a windows 98 :-/) > > > > If the Printer Manufacturer tell you so she is both right an wro
RE RE: 2nd attempt: Modify location of printerdriverfiles
I think the workaround will not work. I can´t predict which user on which machine will use which printer. Our users have in most case max. two networkprinters connected - for our luck long physikal ways prevent the "need" to connect to more printers. We have created a small script which erases all printerrelated registry-entries and files on the client. A user or admin can run this script and the client is clean for a new printer-installation. This way we work around the naming-problem on the client. (The users *theoretical* know which printers cannot be installed at the same time). Of course this works not on the printserver :)). If there is no other solution, we have to "fight" another skirmish with HP ... maybe we can convince them to take more care when naming there files.. ... on the other hand maybe someone is happy to implement the needed variables to the samba-core?? :) The moto would be: Power is nothing without control Simo: Thanks for your answer. Have a nice day. Ralf > -Ursprüngliche Nachricht- > Von: Simo Sorce [mailto:[EMAIL PROTECTED]] > Gesendet: Donnerstag, 28. November 2002 11:34 > An: Kätzler, Ralf > Cc: [EMAIL PROTECTED] > Betreff: Re: 2nd attempt: Modify location of printerdriverfiles > > > That would change nearly nothnig, because the printer drivers will be > copyed in the same structure on the client and there you will find the > same naming problem. > > It is a known windows problem (just faces some day ago with > drivers for > 2 HP laser printers on a windows 98 :-/) > > If the Printer Manufacturer tell you so she is both right an wrong. > > Right it is an OS problem, A windows OS problem. > > Wrong the manufacter must know this issue and try not to make drivers > with overlapping names. > > > However you may try just a workaround. If any of your clients will use > only one printer, you may try some symlink + macro expansion tricks to > use different directories, but it may not work or corrupt badly your > printer settings and prnting related tdb file, so at your own risk: > > - you may use a macro expansion on the print$ share path and > then make a > number of directories that match that macro expansion > > eg: > path = /usr/share/samba/%G/drivers > > and have a pool of printers per group or other parameter. > > Simo. >
Re: 2nd attempt: Modify location of printerdriverfiles
That would change nearly nothnig, because the printer drivers will be copyed in the same structure on the client and there you will find the same naming problem. It is a known windows problem (just faces some day ago with drivers for 2 HP laser printers on a windows 98 :-/) If the Printer Manufacturer tell you so she is both right an wrong. Right it is an OS problem, A windows OS problem. Wrong the manufacter must know this issue and try not to make drivers with overlapping names. However you may try just a workaround. If any of your clients will use only one printer, you may try some symlink + macro expansion tricks to use different directories, but it may not work or corrupt badly your printer settings and prnting related tdb file, so at your own risk: - you may use a macro expansion on the print$ share path and then make a number of directories that match that macro expansion eg: path = /usr/share/samba/%G/drivers and have a pool of printers per group or other parameter. Simo. On Thu, 2002-11-28 at 11:21, "Kätzler, Ralf" wrote: > 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! > > > >My question/problem: > >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 driverinstall. > >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 are gone... > > > >Greetings > >Ralf > > 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. :( > > Greetings > Ralf -- Simo Sorce - [EMAIL PROTECTED] Xsec s.r.l. via Durando 10 Ed. G - 20158 - Milano tel. +39 02 2399 7130 - fax: +39 02 700 442 399 signature.asc Description: This is a digitally signed message part
2nd attempt: Modify location of printerdriverfiles
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! > >My question/problem: >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 driverinstall. >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 are gone... > >Greetings >Ralf 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. :( Greetings Ralf
Modify location of printerdriverfiles
Hello, Samba-Team, hello samba-freaks! Hey! World-Hello-Day was yesterday, but today is although a good day to say "hello"! My question/problem: 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 ok, because the dll for the other model is overwritten during driverinstall. 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 are gone... Greetings Ralf