Novell Directory Services Q & A
Articles and Tips: article
Developer Support Engineer
Developer Support
01 Jan 1997
Novell Directory Services Q & A
Q. How can I save the context I am in when switching between different trees in a multi-tree environment?
A. When moving to a different tree, you could follow this procedure. First find out if there is a default context stored for the current tree already. You would do this by retrieving the tree name from the current context using NWDSGetContextwith a DCK_TREE_NAME key, then pass it to NWDSGetDefNameContext to check if a default context was already stored. If not, you can do it now by calling NWDSSetDefNameContext with your current context.
You would then change to the new tree, assuming that its name is known at this point, by calling NWDSSetContext with a DCK_TREE_NAME key for the new tree. Now you are prepared to retrieve the context for the new tree by means of NWDSGetDefNameContext. If this succeeds, all you need to do is establish the returned context string using NWDSSetContextwith the key DCK_NAME_CONTEXT and the context you just learned.
Q. What is the impact of storing large files as a schema extension in NDS?
A. The answer to this question depends on the size and projected use of the attribute. The current design allows attributes with a size up to roughly 64KB to be stored in an octet string. Anything bigger than this must be stored in a stream attribute. The following discussion affects only stream attributes.
Stream attributes are stored in separate files along with the NDS database files. The first obvious limitation to the attributes therefore is the disk space on the SYS volume. However, this should normally not present a problem. During synchronization, stream attributes are again treated according to their nature as files. This means that they are loaded into the file cache of the server providing synchronization, and transferred to the file cache of the server consuming synchronization. This is the most critical point in the evaluation, as servers are a bit sensitive to memory shortages.
The decision whether to store the attribute in NDS depends on how many instances of the attribute may need to be synchronized at the same time.
Q. I have a list operation that performs correctly in all parts of the tree, except for the root of the current partition, where I keep getting an error -626. What does this mean?
A. The first request issued in any operation is a ResolveName against the target object, which in the case of the partition root is the container object holding the partition. The client therefore has to access the partition superior to the current one.If the request can not be satisfied by the server holding the current partition, it will return referrals to servers supposed to hold a copy of the parent partition. If these servers are down or unreachable, the library will return the above error. The target object may still name a valid DS object, but its validity cannot be definitely determined in the current environment.
Q. What happens if I try to restore an NDS object that uses a schema extension for an attribute, and this schema extension has been deleted in the time since the object was backed up?
A. First of all, it is not possible to remove attribute definitions while there are still instances of them, i.e., objects using these attributes. You would always receive an error of -644, ERR_SCHEMA_IS_IN_USE. Also, it is currently not possible to remove any attributes that were added to class definitions that are part of the pre-installed base schema. That is, if the attribute could be deleted, it was only employed by classes that are extensions themselves. As our object used the attribute, it has to be an instance of a schema extension.
Now it is also not possible to delete an attribute while there still are any class definitions depending on it. Again, you would get an error -644. This means that the definition of the class used to create our object must have been deleted before the attribute was deleted.
What should happen is this: The object is restored as an "Unknown" object, all attributes will still be restored, but the attribute extensions will have their syntax set to SYN_UNKNOWN. There is one special case in which the object will have a defined class. If Directory Services has been re-installed on the server since the backup, and the object is an instance of a class belonging to the base schema, say "User," it will have all of its attributes restored, with the extension attribute turning unknown again.
So far for the theory. I did some testing with 4.11 and DS version 573, and discovered the following: NDS does not restore any attributes or classes that were part of a schema extension, if it does not know about that schema extension at restore time. Instead it will fail the request with an error -603, ERR_NO_SUCH_ATTRIBUTE, or -604, ERR_NO_SUCH_CLASS, respectively. While this does not work quite as documented, it makes sense, as you would certainly have a problem storing the values for attributes whose syntax is now unknown.
Q. I have some code that searches for an object in the tree. I know it is there, though the server I am querying may not have a copy of the object. Now when I call NWDSSearch, the call succeeds, but the following NWDSGetObjectCountreturns 0 objects. What does this mean?
A. Let's assume the object lives in partition P, and the server you are talking to has no replica of P. It will therefore return a list of servers that it thinks are closer to the partition, i.e., "Hmm, I don't know, ask one of these guys". You are getting a referral.
In the NDS Developer's Guide there is a short mentioning of referrals in Appendix F. Unfortunately, it only talks about servers, but you may get referrals on the client, too. Now how should the library behave if it is given a referral? One option would be to continue and query the servers it was given. This may be fine in a LAN, but could turn out to be expensive when it required an ISDN link to be brought up. Also it will probably look to the user as if his application died, when in fact it is waiting for a network response. So there should be a way to let you assume control and maybe respond to the user who is desperately clicking the "Cancel" button. This is what the zero count does. It indicates the current server returned a referral. You may either accept it and enter the next iteration, querying other servers, or you may quit by calling NWDSCloseIteration.
Q. Fine, and how do you prevent dead loops in this case?
A. This refers to building the list of servers to refer the caller to. There are two possible directions for the search to continue. If the current server has no copy of P, it may still hold a copy of its parent (or an ancestor) in the tree. This can be determined by looking at the name of the object looked for. If that is the case, there will be a subordinate reference entry of P in the parent partition. This entry has the addresses of all the servers in the replica ring of P, and this is the referral the server will return to the caller.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.