[PATCH] winbindd_idmap.c [Re: idmap recovery tool}
Michael Steffens
michael_steffens at hp.com
Tue Feb 12 08:40:26 GMT 2002
"MCCALL,DON (HP-USA,ex1)" wrote:
>
> Hallo Michael,
> very nice work!
Thank you very much! :-)
And being there, here is another one: a postprocessing script
for wbidmap logs, inserting the plaintext name into the third
column.
The very brave ones will execute
wbidmap -d | wbidmap_add_names > dumpfile
However, as there is no clean locking between winbindd and
wbidmap, this might cause incomplete results or inconsistency
warnings (when wbidmap was checking while winbindd was in
progress of adding a new mapping).
The careful ones will therefore
- shut down winbindd
- create a copy windbindd_idmap.tdb
- move winbindd_idmap.log aside (*)
- start winbindd
- execute wbidmap -d -f copy-of-windbindd_idmap.tdb | wbidmap_add_names > dumpfile
- append dumpfile to winbindd_idmap.log (the new one, that
winbindd may have created in the meanwhile for new
mappings).
always looking out for errors and warnings, of course. Without
errors or warnings a complete and consistent backup of all
currently known mappings is created this way, that will be
updated online by winbindd.
(*) may be omitted if one doesn't care for duplicates. They
don't hurt, but maybe the file has got a bit large while
time went by?
If errors occurred, most probably wbidmap is buggy :-) If not,
you will need to dig into the dump/log to see what's wrong.
The plaintext names should help this task.
The restore in case of desaster should work approximately like
this:
a) If windbindd_idmap.tdb is entirely gone
- shut down winbindd
- wbidmap -c < windbindd_idmap.log
- start winbindd
b) If windbindd_idmap.tdb is still there
- shut down winbindd
- check with wbidmap -d >/dev/null
- if errors are reported, I wouldn't trust that file anymore.
Go ahead with a).
- otherwise wbidmap -m < windbindd_idmap.log
- start winbindd
c) If you are suspicious whether windbindd_idmap.log is good
- check for self-consistency by creating a test tdb:
wbidmap -c -f tmp-winbindd_idmap.tdb < windbindd_idmap.log
- If this fails, curse and look into windbindd_idmap.log
- Otherwise try wbidmap -pm < windbindd_idmap.log
- If you know the conflicting entries in the tdb should
be overwritten, do so with wbidmap -om < windbindd_idmap.log
- Otherwise wbidmap -m < windbindd_idmap.log will preserve
such entries.
Case c) should hopefully never happen. One must be at least as
careful with winbindd_idmap.log, as we are currently told to be
with windbindd_idmap.tdb. It is the ID mapping online backup, with
the advantage of being accessed less frequently than the TDB, and
being plain text.
Whenever something evil happened to that file, rebuild it like
described at the beginning.
This is at least how I imagine it to work. :-)
Cheers!
Michael
-------------- next part --------------
#!/bin/sh
#
# wbidmap_add_names - postprocessing script for wbidmap dumps
#
# Author: Michael Steffens <michael_steffens at hp.com>
#
# Read wbidmap dump from stdin and insert human readable user/group
# names into the third column. Print result to stdout.
#
# --- Customize here ---
SAMBA_BINDIR=/usr/local/samba/bin
WINBIND_SEPARATOR='\'
while read line
do
uid=`echo "$line" | cut -d: -f1`
sid=`echo "$line" | cut -d: -f2`
# save additional fields, if any
remainder=`echo "$line" | cut -d: -f4-`
# only process well formatted lines. others are passed unchanged.
if `echo "$uid" | grep -qE '^[GU]ID [0-9]+$'`
then
idtype=`echo "$uid" | cut -d' ' -f1`
id=`echo "$uid" | cut -d' ' -f2`
else
echo "$line"
continue
fi
# lookup full SID by UID/GID. (the domainname/RID pair is not very useful for wbinfo)
case $idtype in
UID)
fullsid=`$SAMBA_BINDIR/wbinfo -U $id`
;;
GID)
fullsid=`$SAMBA_BINDIR/wbinfo -G $id`
;;
esac || {
echo "$line"
continue
}
# lookup plaintext name, strip domain name and type code
name=`$SAMBA_BINDIR/wbinfo -s $fullsid | cut -d$WINBIND_SEPARATOR -f2 | sed 's/ [0-9]*$//'`
echo "$uid:$sid:$name${remainder:+:$remainder}"
done
More information about the samba-technical
mailing list