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

[John H Terpstra]

Chris,

Please summarise to me direct, anything that you believe that is NOT
directly printing related, but that ought to go into the HOWTO collection.
I will find a place for it.

- John T.

On Fri, 2 May 2003, Chris Smith wrote:

> On Fri, 2003-05-02 at 08:55, Kurt Pfeifle wrote:
>
> > 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...  ;-)
>
> Actually it was a real email address, just munged with words in all caps
> (like NO and SPAM) to slow down the spammers in their automated address
> gathering.
> As for searching the CUPS newsgroup from the web interface you are right
> - it is dog slow. I tried it today to find some information while at a
> clients, finally gave up the ghost and set up an account in a newsreader
> app to find it.
>
> > > 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 really belongs in Windows docs<g>. Sometimes it seems you can learn
> more about Windows reading the Samba list than you can reading a Windows
> list. Maybe there should be a special place in the docs for such
> material as, "Windows stuff that you should know" and "Windows stuff
> you'd like to know"; misc. information that helps one use Samba
> effectively but yet is not Samba specific.
>
> > > 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.
>
> In the specific case I used them they were not the complete logon script
> but they could be a complete logon script. There's no requisite
> information missing that would prevent such a script from running.
>
> > > 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.
>
> If the user doesn't have the rights to do it manually then PrintUIEntry
> will fail as well. A person with straight "Domain User" privileges
> cannot install a local printer but can make a connection to a network
> printer.
>
> If an admin (user logged on with admin rights), from the console, adds a
> local printer it will be available to all users, if the admin adds a
> network printer it will only be available to that user. The use of
> PrintUIEntry in a logon script does not change the basic way these
> operations work.
>
> > > 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).
>
> You may want to examine the example in the quoted MS text:
>
> ==========================================================
> This example adds an Agfa printer driver and creates a logical printer
> on a computer named SERVER.
>
> rundll32 printui.dll,PrintUIEntry /ia /c\\server /m "AGFA-AccuSet v52.3"
> /h "Intel" /v "Windows 2000" /f %windir%\inf\ntprint.inf
>
> rundll32 printui.dll,PrintUIEntry /if /b "Test Printer" /c\\SERVER /f
> "%windir%\inf\ntprint.inf" /r "lpt1:" /m "AGFA-AccuSet v52.3"
> ==========================================================
>
> ...first the driver is installed, then the printer. Also the computer is
> directly named.
>
> > You are invited to contribute a whole new wording for the entire section
> > (with me as one of the referees...   ;-)
>
> If I get the time to come up with something I'll send it to you.
>
> > > 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....
>
> Right, you work around the bugs. I'm still using CUPS, just a raw queue
> instead of their PS driver.
>
> > 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).
>
> But multiple copies in kind of volume environment will produce terrible
> backlogs and tie the queue up for a long time (too long). It was just an
> aside to give a heads up to those who experience this, not know why, and
> replace CUPS as the solution, instead of just using a raw queue.
>
> > > 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....  ?
>
> No, as above, it works the same way if you add printers sitting at the
> console.
>
> > ...and a network printer is what we install here (and that is what's the
> > purpose of Samba supporting printing, isn't it?).
>
> Yes, but this is really Windows stuff here, nothing Samba specific.
>
> > >  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.
>
> It works as I stated. Just tested it to make sure.
>
> > > 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).
>
> I'm sure because I've done this. In fact it was even with the CUPS
> drivers and using cupsaddsmb. The very last command of cupsaddsmb failed
> because it assumes the printer names are the same (as they would be if
> one is using the [printers] share). So I just manually ran the last
> rpcclient setdriver command, adjusting the names appropriately.
>
> Best regards,
>
> Chris
>
>

-- 
John H Terpstra
Email: jht at samba.org