Hi all,
Thanks for all replies regarding the subject. I took some time to debug the
problem, which resulted in some interesting insights. I started with a clean
printer driver repository, no ntforms, ntprinters and ntdrivers.tdb files.
Then I installed and assigned the drivers to the printers.
First of all: the server is a Solaris 10 machine, which has sendfile support.
Sendfile is compiled in, but not enabled by default. I enabled sendfile in
smb.conf, which should result in less CPU stress.
Second: all printers had an 'invalid users' setting in the share
definition.
It turned out that this considerably stresses the CPU. It took about 10
seconds for the properties to show up for a 'HP 4250PS driver' printer.
While
truss-ing the smbd process, we saw that the smbpasswd file was opened for 85
times (from the click on 'properties' to when the properties appeared).
I
think that's a lot. We have around 4700 entries in the smbpasswd file, so I
can imagine why it takes long for the properties to show up when 6 invalid
users are configured. Only one would expect that the smbpasswd file is opened
just 6 to 10 times, and not 85 times. I guess this won't happen when using a
tdbsam passdb backend (which is not an option for us for now).
After deleting the 'invalid users' setting, the properties showed up in
about
2 seconds. Some more experimenting showed that adding the invalid users to the
security tab (as in: deny user 'a' to print) resulted in about the same
behaviour. Can't explain why the old Samba 2.2 server doesn't suffer
from this
though.
Another thing is that 'guest ok = yes' on the print$ share resulted in
lots of
reads/opens of files as the user 'nobody'. This is unnecessary in our
setup,
since every user is authenticated. Obviously, I configured 'guest ok =
no' now.
Since uploading the drivers to the server is a lot of work in case of 78
printers, I looked for a way to use the 'old' drivers. I deleted all
nt*.tdb
files, copied the drivers and copied the ntdrivers.tdb from the old server. In
the printer properties (advanced -> driver) all drivers showed up. Only the
association with printers was gone (which was expected). I could simply assign
the printers the correct driver.
Then, I did the same as above but not before renaming the server and workgroup
to a temporary name. Assigned the local/domain SID of the original domain with
'net setlocalsid', etc. Assigned the drivers again, applied the correct
settings etc. Then I renamed the server/workgroup to the original name again,
checked if the local/domain SIDs were still OK (Samba apparently caches that).
All associations were still there, with correct settings. This answers my
question if printer-driver-associations survive server/workgroup name changes.
-Remy
> we've been moving an old Samba 2.2.x PDC install to a Samba 3.0.28 PDC
> install. We copied the ntdrivers.tdb and ntprinters.tdb from to old to
> the new server. After the migration, everything was just fine, except
> printing seemed to be somewhat slower. As more and more user logged on,
> the machine got really
> sluggish and printing took quite long. We figured out we've got bitten
by:
>
>
<http://www.usenet-forums.com/samba/311929-re-samba-slow-printing-print-properties-cups-samba.html>
>
>
> The plan is to assign the new server a new 'workgroup' name, which
> divers from the workgroup settings of the old PDC, delete all .tdb
> files, assign the printers drivers and settings again. Then, turn off
> the old PDC, change the workgroup setting of the new PDC to match the
> old PDC, etc. Basically, we build new printing .tdb files.
>
> The question is: is this going to work? Do the .tdb files which have
> something to do with printers have references to the temporary workgroup
> name or do they use domain/local SID's (which are the same on the old
> and new server)? Any other gotcha's? Is there a more proper way to
> accomplish this?
>
> Thanks for your comments,
> Remy
>