Does determining which TAO file goes with which driver object on which server cause you grief? Let's work on that a little bit.
Here's a quickie for all of you who are on a real OS. For those stuck on Windows, you'll need to find a decent command-line calculator to have the same fun. For everybody everywhere, you can always use any calculator app (gcalctool, kcalc, calc (windows), bc (this example), etc.
So what we're going to learn today is how to interpret those pesky TAO files. If you don't know already, each driver has a TAO file which stores events from the engine that are pending for that driver. For example, if a user's given name changes it needs to be sent to the eDirectory and Microsoft Active Directory (MAD) systems. If the driver is busy doing something else, that event is written to the TAO file to prevent it from getting lost (technically I think it's written there regardless, but I'm making a point here). As the engine gets finished, the new event is read from the TAO file, processed, and eventually removed (various algorithms exist across IDM versions for when the TAO file is rewritten).
So the problem many administrators find quickly is determining which TAO file goes with which driver. They are all in the eDirectory DIB directory, and they all have decimal-number names that don't go with the object names at all. Several TIDs explain that the TAO file name is actually the eDirectory object's Entry ID (EID) converted from hexadecimal to decimal (base 16 to base 10). This conversion is trivial in a calculator, but having one open and then comparing them with the EIDs in iMonitor just makes for a lot of steps. To do the conversion in one less window, a simple script can be whipped up. SLED/SLES come with "bc", which is "An arbitrary precision calculator language" according to its man page.
1. Create a new file ("d2h" will be my file name) in a part of the filesystem that is in your user's path. This could be the "bin" directory in your user's home directory, or it could be something as universal as /usr/bin or /usr/local/bin (you'll need "root" rights to do this in a univeral path).
2. Make the file executable ("chmod +x /path/to/theFileYouCreated").
3. Edit it, placing the following line inside the file:
echo "obase=16;$1" | bc
4. Save the file and now test it:
Tada! You gave the command-line file a parameter (the TAO file name was 45050.TAO) and it gave you the EID to find in iMonitor. From here, all kinds of fun things can happen. First, let's get the reverse down - just in case it's useful (it's a little more tricky):
1. Create a new file again, called "h2d" (hex to decimal), with the following contents:
echo "obase=10; ibase=16; $1" | bc
2. Do the opposite of the command above:
Wonderful, so we have the basic conversion licked. Playing with "bc" on your own time can be a very rewarding experience, so I recommend it. It is important at this point to note that EIDs are server-specific (unlike GUIDs which are universally unique). So if you have drivers on multiple servers (one active, one dormant), they will probably have a different EID on every server. Also, two drivers on different servers (whether the same driver object or not) could have the same EID between those two servers. Just make sure you realize that the EID is only unique on that one server.
When using iMonitor to view the EID of the driver object, be sure you have pointed iMonitor to the server on which you are viewing the TAO file (in case multiple servers have the driver as mentioned above). Otherwise you'll pull your hair out trying to figure out why the values don't match up.
For somebody who is a scripting wizard, it wouldn't be too difficult to write something like "lstao" that, when it finds a file like 45050.TAO, automatically converts it to the hex number while leaving the other data behind. I may work on this, but it's late - so not tonight.
PS - Yes, you can get the EID directly (and in decimal form as it turns out). All you need to do is use ldapsearch (or whatever), specify the filter to find your driver(s), and then request just the localentryid attribute.
For example, to get my admin user's EID from one box:
ab@abbox:~> ldapsearch -h 22.214.171.124 -p 389 -D cn=admin,dc=user,dc=system -x -W cn=admin localentryid
Enter LDAP Password:
# extended LDIF
# base with scope subtree
# filter: cn=admin
# requesting: localentryid
# admin, user.system
Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).
It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.