The Samba-Bugzilla – Bug 1219
need command-line access to all fields in backend, script output from "net rpc vampire"
Last modified: 2005-09-29 07:37:35 UTC
"net rpc vampire" is great but a Windows -> Samba migration is still complex
enough that the system admin needs to fine-tune things afterwards. Also, when
doing a migration, one might want to only migrate a subset of users, or perform
some conversions on the user information.
So I'd like to be able to do everything "net rpc vampire" does with command-line
utilities - that way, instead of running "net rpc vampire", I could run "net rpc
samdump", and use the output of that to enter the data that I want for the new
Samba domain. The "pdbedit" command looks like a good candidate for these
features. It would need options to add / manipulate:
* password hash string (i.e. accepts the encrypted password rather than the
* Unix username of user
Another "nice to have" would be an option to "net rpc vampire" to print out the
commands it would run to import the users rather than actually doing it. The
printout would consist of the calls to the add user/group/machine scripts, and
calls to pdbedit to create the users in the Samba backend. The script output
could then be taken to another machine for testing, and edited as needed for
whatever the admin wants.
One thing I found during my testing for a Samba migration was that you have to
test a LOT. I must have run "net rpc vampire" 20 times trying to get things
right, and each time I had to manually remove the Unix users and groups that
had been added on the previous run. And this was for a domain with only six
I would have preferred that my test machine be on a totally isolated network,
but because I needed to re-run the vampire all the time, I had to have the
test machine on the same network as the Windows server and risk having active
users discovering my test box and trying to use it. I could get away with that
in this instance, but I've worked in places where doing testing on the
production network would be highly frowned upon.
If we want to make it easy to toss your Windows domain controllor into
the trash can, "net rpc vampire" needs to be more flexible and I think script
output as described above is the way to go.
good ideas, but later.