net rpc vampire performance

[Ingo Steuwer]

Am Donnerstag, 26. Mai 2005 20:48 schrieb Donald W Watson:
> I am working with Jim McDonough on the IBM Samba team, and have been
> looking into performance enhancements for net rpc vampire.  While vampire
> to a tdbsam backend runs reasonably quickly, vampire to an ldapsam backend
> with a large number of users could be speeded up.  I have designed and
> written some preliminary code which creates ldif files and runs
> ldapadd/ldapmodify against them.  It runs much faster than the original
> code, but has raised the following issues on which I would like community
> input:

We'd be happy to see some speed-enhancements with "net rpc vampire", in larger 
environments vampire needs too much time for an "easy" takeover (which means 
"more than a weekend").

> 1. I used smbldap-populate for the initial database population. It might be
> nice to be independent of the smbldap tools, but performing the initial
> database population in the Samba code will involve some substantial string
> manipulation with all its attendant wide character ramifications.  This is
> a result of needing to parse the character strings returned by the
> lp_ldap_*_suffix functions to get reasonable values for some of the ldap
> object attributes (for example: o: and ou:).  The smbldap-populate script
> is written in perl, so this is easy for them.  Samba's util_str.c module
> might need some additional string functions.
>
> 2. Should the code simply produce an ldif file(s) against which the user
> can run ldapadd/ldapmodify, or should it produce temporary ldif files, run
> ldapadd and ldapmodify, and then delete the temporary files?  The later
> case mimics more accurately the way the current code works.

Wouldn't it be better to produce a more "general" output? Samba has options to 
use external Scripts for creating Users, Group relationships etc. Producing 
ldifs would mean that it's not possible to use user-defined LDAP-Structures 
(i.e. position, modify of existing accounts/groups).

I think flat files (maybe csv), one for accounts and one for groups, would be 
more flexible. It gives the possibility to produce ldifs like yours in a 
second step (or modify the LDAP directly) but leaves the "freedom of choice" 
to use your own structure (or even a different backend).

Greetings
Ingo Steuwer


> 3. How should the user activate the new code from the command line?
> Currently I'm using an additional option:  "net rpc vampire ldif -S
> <domain>".
>
> Sincerely,    Don Watson
> Linux Technology and Solutions; Beaverton, OR
> 503-578-4861/TL: 775-4861; dwatson at us.ibm.com

-- 
Ingo Steuwer       steuwer at univention.de         fon: +49 421 22 232- 0
Entwicklung        Linux for Your Business
Univention GmbH    http://www.univention.de/     fax: +49 421 22 232-99