[Samba] Update to Printiing Chapter for Samba 3.0 HOWTO Collection available

[Kurt Pfeifle]

Chris Smith wrote:

Hi, Chris,

thanks for your reply and suggestions.

> As section 6.8 is a rework of a post of mine to the CUPS newsgroup
> (subject "[cups.general] PDF Printing" on 4/11/03 - and, yes, used with
> permission via my reply to you in same thread on 4/16/03)

That's right, and I used it in the first place as a "placeholder" for
my own material, which I had written down time ago but can't find
currently. The URI to the MS KB article quoted by me has been in the
old 2.2 Samba HOWTO Collection for ages. When I first saw it, I was
curious and read it. I started to play with it at a customer's site
who's administrator gave me access to their resources (they did run
an NT domain). I took notes about my experiments then; in the meantime
their admin changed jobs and I can't access it any more. My own
environment has no NT domain, so I am a little bit like a "fish outside
the water". That was one reason why I had asked you about it. So
there is *some* prior knowledge about the topic on my side too.

I am glad that you offered your help and advice. (Since you didn't use
a real e-mail address then, I couldn't get in direct touch with you
since. And searching the CUPS newsgroup website is a pain -- dead-slow
and not turning up much; I think I'll file a RFE on the STR site about
it tonight...  ;-)

> I will try to
> clarify some points as some of the changes seem inaccurate.


> Hopefully
> others who see this will be able to assist as well and prevent me from
> leading you down the wrong path by suggesting a change in error.
> 
> It should be mentioned that this technique is not Samba, nor CUPS
> specific.

OK. I'll re-assess the context. (Anyway, I think it is clear that it is
not CUPS specific, since I'm placeing it in the "6." chapter, which is
headlined "'Classical' Printing Support in Samba"....)

> It is Windows sys admin stuff and works just fine, as
> designed, with Windows servers and systems. Because Samba does what it
> does as well as it does this also works with Samba servers regardless of
> the printing subsystem (CUPS, for example, is not necessary).

I'll clarify that more. (I think it is clear already).

> The text follows, I'll preface my comments with "*tcg>".
> ===================================================================
> 6.8. Adding Printers upon Logon without User Interaction
> The ideas sketched out below are inspired by the Microsoft Knowledgbase
> article from:
> 
> *tcg> I've used PrintUIEntry in practice for some time. I'm not sure if
> "ideas sketched out" is apropos.

I used that because the quoted lines are *not* a complete logon script.
As I've lost my own reference and can't verify myself currently, I
prefered a more cautions wording for it. If memory serves me right, I
used the exact same lines in my own tests (you don't have much choice
once you did run it with the "/?" parameter to get taught how to use it).

I tested a little script with the lines I have now in that doc -- though
not as a "logon" script, but rather a standalone printer installation
*.bat script.

> And the example, as I posted it, was
> part of a real logon script currently in use.

I am glad you can confirm that this works for Win2k too.

> <snip>
> 
> A window pops up which shows you all of the options and switches
> available. This is only for Win 2k/XP (I should try and find out how far
> this is possible in WinNT 4.0 -- anyone with knowledge on this field
> reading this??? FIXME). Here's a suggestion what a possible client logon
> script could contain (works if 2k/XP Windows clients access printers via
> Samba):
> 
> *tcg> I'm fairly positive that PrintUIEntry is not available for NT.

Yes -- but I *think* there is something similar on NT too, though it is
not called PrintUIEntry....

One main difference might be that the privileges to perform these actions
may be disparate between Nt and 2k/XP. (WinNT knew only printer drivers
running in Kernal mode, while 2k/XP default to user space printer drivers,
with Kernel mode available only for old drivers in backward compatibility
mode).

> The
> "via Samba" part at the end is not wholly correct (PrintUIEntry can
> install/delete virtually any printer, local

hmmm... *I* didn't get the local ones installed with "rundll32
PrintUIEntry....".

To me it only seemed to work with opening a print path to a printer which
is already installed on a print server.

Might have to do with privileges here too. May be fixed with a change
in the local policy of my XP box. Haven't looked into it.

The "via Samba" I included was meant to confirm that this is *not* just
for a pure MS Win environment, but *also* *works* *with* *Samba*....

> or shared via Samba or
> Windows).
> 
> <snip>
> 
> Here is a list of the used commanline parameters 
> 
> *tcg> typo "commandline".

Thanks, I had fixed this already this morning....  ;-)

> <snip>
> 
> I have tested this with a Samba 2.2.7a installation and Windows XP
> Professional clients. Note that this only works with network printers.
> 
> *tcg> this was not part of my post.

No, it wasn't. I only want to present things which I have tested myself.
But I also accept positive confirmations from other people. So I'll
include Win2k too now.

> I have used it with both Win2k and
> WinXP clients. It also works with local printers (the arguments are
> slightly different).

OK -- I'll tell you what I used to try and install printers locally:

    rundll32 printui.dll,PrintUIEntry /if /b "PrinterInstaTest" /f %windir%\inf\ntprint.inf /r "lpt1:" /m "Xerox 3006"

It didn't work. I didn't have a chance to put much energy into debugging
this. I am "Administrator" on this box. I got a message "procedure couldn't
  be completed" (back-translated by myself into English).

>       * Line 1 deletes a possibly existing previous network printer
>         "infotec2105-IPDS" (which had used native Windows drivers with
>         LPRng that were removed from the server which was converted to
>         CUPS). The "/q" at the end eliminates "Confirm" or error dialog
>         boxes popping up. They shouldn't be presented to the user
>         logging on....
>       * Line 2 adds the new printer "infotec2105-PS" (which actually is
>         same physical device but is now run by the new CUPS printing
>         system and associated with the CUPS/Adobe PS drivers). The
>         printer and his driver has been added to Samba via cupsaddsmb
>         and driver is now auto-downloaded to the client PC where the
>         user is about to log in.
>       * Line 3 sets the default printer to this new network printer
>         (which is desired in this case - there are other printers not
>         shown here and some may be local as well). This default printer
>         selection may only be done for specific systems.
> 
> *tcg> my only concern is that someone might assume that only a CUPS
> printer using the CUPS/Adobe driver can be added in this way 

OK -- this isn't really clear from the current wording. As I said, this
paragraph is currently there only as a "placeholder" currently. I agree,
it needs to be made clear that the method is valid for installing *any*
vendor driver into Samba's [print$] share and TDBs and that it is
independent from the underlying UNIX print subsystem.

> (I would
> probably change the example for this HOWTO a little further from my post
> on the CUPS newsgroup than you have.

You are invited to contribute a whole new wording for the entire section
(with me as one of the referees...   ;-)

> As a sidenote, until the CUPS
> driver is fixed (http://www.cups.org/str.php?L29), it may be better to
> stick with a raw queue.

Samba has a few bugs left too, but I don't advocate to "stick with another
OS" therefore....

Seriously, the #29 STR bug hits not *everyone*. It doesn't prevent printing
(it just slows it down under certain circumstances, and if you print
multiple copies).

> This procedure installs printers *per user*, not per client machine
> (since it is bound to the user's personal logon script).
> 
> *tcg> it's not because it is bound to the user's logon script, it's the
> way Windows works.

...or rather because of what the actual commands do which are in the logon
script....  ?

> If PrintUIEntry was used to install a local printer
> it would be per machine, just as local drives and local ports are.

...however this I didn't get to work (as I said above).

> A
> network printer, like a mapped drive, is connected per user.

...and a network printer is what we install here (and that is what's the
purpose of Samba supporting printing, isn't it?).

>  Note that the second line only works if the printer "infotec2105-PS" is
> already installed under that same name on "sambacupsserver" as a UNIX
> printer, and if the printer drivers have sucessfully been uploaded (via
> APW or "cupsaddsmb") into the [print$] driver repository of Samba.
> 
> *tcg> I believe that as long as Samba is exporting(sharing) the printer
> and a valid driver is available the Windows installation will happen -

You *might* be right. However, I remember it for me failing when I tried.
This could have two reasons:

   * my own incompetence
   * the close integration of Samba/CUPS (linking of libcups.so to smbd)
     might lead to Samba checking for the existence of the printqueue
     (I am no programmer and haven't checked if I find comments in the
     source code to this effect.)

However I *know* it works if you proceed like I described.

> even if the printer does not exist in the printing subsystem. The name,
> as well, can also be different.

I am not sure here for CUPS. (And CUPS doesn't support alias names for
printers).

> Generally these cases would exist if one
> is specifying the printers manually and not using the [printers] share.

True.

> <snip>
> ================================================================
> 
> Hopefully I have been as accurate as I have been boring and pedantic.

In the case of discussions about technical documentation I *like* pendantery
and accurateness. They help a lot. They save the time of people who rely
on it.

> At
> least some good may come of it.
> 
> Thank you.
> 
> Chris Smith
> 

Thanks a lot for you feedback, Chris. I hope to see some more detailed
suggestions about the wording of that section.

Bye and cheers,
Kurt