Understanding the export printer driver feature

[Kurt Pfeifle]

Chris Howells wrote:
> Hi,
> 
> On Sunday 26 January 2003 14:11, Kurt Pfeifle wrote:
> 
> 
>>The "download area" is the "print$" share of the Samba server (or, any NT
>>print server). Win clients are hardcoded to retrieve printer drivers from a
>>share named "print$". It *must* appear in the smb.conf with a [print$]
>>heading, and the "path" defined in there *must* exist on Unix.
> 
> 
> I think that bit is OK, my smb.conf has a section like the following:
> 
> [print$]
>   comment = Printer Drivers
>   path = /usr/local/samba/drivers
>   browseable = yes
>   #guest only = yes
>   guest ok = no
>   read only = yes
>   write list = root
> 
> (note that I have samba largely configured for anonymous access using guest 
> only = yes)
> 
> Can the path section be anywhere?

Basically yes. (It shouldn't be in the *spool* directory or at other
stupid places though...)

> On FreeBSD, the smb.conf file is under 
> /usr/local/etc, so I didn't quite know where to set it to.
> 
> <snip lots of useful info>
> 
> 
>>  * Can you check if the "0" and "2" subdirs are created?
> 
> 
> They aren't.

Bad.

Check the access rights for the "/usr/local/samba/drivers/" dir.

>>  * What are the ac by the "rpcclient adddriver" command; the initializition
> 
> (setting the acess rights?
> 
> I don't understand this bit unfortunately.

I don't either. It's not what I have written. Something got garbled on your
side. My outgoing folder copy reads OK, the arrived copy on
http://lists.kde.org/?l=kde-print&m=104359044307902&w=2 too...

>>  * What are the access rights for their parent dirs ("<print$>",
> 
> 
> su-2.05b# cd /usr/local/samba/
> su-2.05b# ls -l
> total 2
> drwxrwxr-x  4 root  wheel  512 Jan 25 18:53 drivers
> su-2.05b# cd drivers/
> su-2.05b# ls -l
> total 4
> drwxrwxr-x  2 root  wheel  512 Jan 25 18:53 W32X86
> drwxrwxr-x  2 root  wheel  512 Jan 25 18:53 WIN40

Looks OK.

> 
>>    "<print$>/W32X86", <print$>/WIN40") ?  (You could do "smbclient
>>    //localhost/print\$ -U root%root" and see if you get the "smb: \>"
>>prompt; if yes, try to see what's in and if you can move there: "dir" ; "cd
>>2"; "dir".
> 
> 
> I get the smb prompt, and I can dir, cd and even mkdir.
> 
> 
>>  * What do you see as the respective content of the subdirs?
> 
> 
> su-2.05b# find . -name "*"
> .
> ./W32X86
> ./W32X86/hpdj3820.PPD
> ./W32X86/ADOBEPS5.DLL
> ./W32X86/ADOBEPSU.DLL
> ./W32X86/ADOBEPSU.HLP
> ./WIN40
> ./WIN40/hpdj3820.PPD
> ./WIN40/ADFONTS.MFM
> ./WIN40/ADOBEPS4.DRV
> ./WIN40/ADOBEPS4.HLP
> ./WIN40/DEFPRTR2.PPD
> ./WIN40/ICONLIB.DLL
> ./WIN40/PSMON.DLL

Right. This is the situation as it should be after the "smbclient put"
command transfered the driver files to [print$].

Now you could try and execute the "rpcclient adddriver" command manually,
with a higher debug level for Samba.

You can set a different debug level with the "smbcontrol" command for
Samba "on the fly" (no need to restart the daemons) and watch everything
going into the logfiles with "tail -f".

The commands should read like this:

    smbcontrol smbd debug 3     # sets debuglevel 3 (may be 0 - 100, but you
                                # really don't want to go further than 10  ;-)

    rpcclient localhost -N -U'root%root' -c 'adddriver "Windows NT x86" \
                        "hpdj3820:ADOBEPS5.DLL:hpdj3820.PPD:ADOBEPSU.DLL:ADOBEPSU.HLP:NULL:RAW:NULL"'

    rpcclient localhost -N -U'root%root' -c 'adddriver "Windows 4.0" \
                        "hpdj3820:ADOBEPS4.DRV:hpdj3820.PPD:NULL:ADOBEPS4.HLP:PSMON.DLL:RAW:ADFONTS.MFM,DEFPRTR2.PPD,ICONLIB.DLL"'


Put the last two commands all in one line (see "man rpcclient" for *some*
additional info). I remember once to have done this manually with success.

If this fails. create "W32X86/2" and "WIN40/0" manually and put the
driver files in there:

  W32X86/2 -- should have hpdj3820.PPD, ADOBEPS5.DLL, ADOBEPSU.DLL,
              ADOBEPSU.HLP
  WIN40/0  -- should have hpdj3820.PPD, ADFONTS.MFM, ADOBEPS4.DRV,
              ADOBEPS4.HLP, DEFPRTR2.PPD, ICONLIB.DLL, PSMON.DLL


Then you could try the "rpcclient setdriver" command:

   rpcclient localhost -N -U'root%root' -c 'setdriver hpdj3820 hpdj3820'

and also watch for errors in the Samba logs when you execute it...

(My hope is low, though -- just curious, what the results would be...)


>>  * Is it really true that there is nothing there in the "download area"? )
> 
> I don't think so :)
> 
>>You could try and start with a *clean* Samba environment. To cleanse that
>>environment for the purpose....
>>
>>   ...delete all existing files and subdirs underneath [print$], and
> 
> Done.
> 
>>   ...delete all *.tdb files created by Samba (possibly in
>>"/var/lib/samba/", "/var/lock/samba/", "/var/cache/samba/",
>>"/usr/var/lib/samba/", or "/usr/var/cache/samba/" or
>>"/usr/var/lock/samba/", depending on your distro...
> 
> OK, I deleted all the tdb files apart from /usr/local/private/secrets.tdb.
> 
>>and restart Samba. (NOTE, that all user auth info might be lost -- if you
>>need it back up the files first, or just delete the "ntprinters.tdb",
>>"printing.tdb" and "ntdrivers.tdb" files selectively.)
> 
> Restarted samba -> still doesn't work :(
> 
>>I noticed you are using Samba 2.2.7a (that's OK -- it's the latest). What
>>is the version of CUPS you are running (This could be very relevant,
>>because IIRC, there were some incompatibilities and/or bugs between certain
>>CUPS and certain Samba versions...?
> 
> I'm running Cups 1.1.15, from FreeBSD packages. I wonder if it's just 
> completely broken on FreeBSD, since I can't see anything wrong :(

Hmmm... I'd try to compile 1.1.18 from sources and use the CUPS PostScript
Drivers for Win NT/2K/XP (they are for NT/2K/XP clients *only*  -- use the
"old" Adobe drivers for the WIN40 clients). The CUPS PostScript are in the
"cups-samba.tar.gz" tarball in the download area on www.cups.org.... Note
that this also has a new version of cupsaddsmb with a new man page...

> Thanks very much for the ideas.
> 

Cheers,
Kurt