On 11/02/2011 04:27 PM, brandon wrote: > On 11/02/2011 03:56 PM, Rich Megginson wrote: >> On 11/02/2011 03:49 PM, brandon wrote: >>> So I'm hoping somebody can assist with a confusing problem I am having. >>> >>> I am running 389-ds-1.2.1-1. >> What platform? What version of 389-ds-base? > Redhat Server 5.7; kernel 2.6.18-274.3.1.el5 > > 389-ds-base-1.2.9.9-1 > >> Start with the access log. This will tell you your bind identity and >> the operations invoked by the client. It won't give the exact modify >> arguments for modify operations - use the errorlog level 4 (ARGS) for >> that - see http://directory.fedoraproject.org/wiki/FAQ#Troubleshooting >> (4 Heavy trace output debugging). > My biggest difficulty with the access log is the noise (today alone is > 500M of logs). > > A very nice feature (tangent) would be to be able to qualify logs by > object and a unique tag, along with log level. So you could say any log > regarding this object/node should be tagged with 'Special Call out' and > runs at a higher log level (if not into an alternate file). Please file a bug/RFE. > I will look into higher level debugging, to see if I can digup more > info. The log level 4 will tell you the arguments for the MOD, which are necessary (see below). > The log info so far: > > [02/Nov/2011:18:58:39 +0000] conn=74 fd=69 slot=69 SSL connection from > 55.55.55.10 to 55.55.55.10 > [02/Nov/2011:18:58:39 +0000] conn=74 SSL 256-bit AES > [02/Nov/2011:18:58:39 +0000] conn=74 op=0 BIND > dn="uid=GIR.Interface,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot" > method=128 version=3 > [02/Nov/2011:18:58:39 +0000] conn=74 op=0 RESULT err=0 tag=97 nentries=0 > etime=0 > dn="uid=gir.interface,ou=administrators,ou=topologymanagement,o=netscaperoot" > [02/Nov/2011:18:58:39 +0000] conn=74 op=1 SRCH base="ou=Special > Users,dc=alt" scope=2 filter="(&(uid=test)(objectClass=posixAccount))" > attrs=ALL > [02/Nov/2011:18:58:39 +0000] conn=74 op=1 RESULT err=0 tag=101 > nentries=1 etime=0 > [02/Nov/2011:18:58:39 +0000] conn=74 op=2 MOD dn="uid=test,ou=Special > Users,dc=alt" > [02/Nov/2011:18:58:39 +0000] conn=74 op=2 RESULT err=16 tag=103 > nentries=0 etime=0 csn=4eb192df0000000a0000 > [02/Nov/2011:18:58:39 +0000] conn=74 op=3 MOD dn="uid=test,ou=Special > Users,dc=alt" > [02/Nov/2011:18:58:39 +0000] conn=74 op=3 RESULT err=16 tag=103 > nentries=0 etime=0 csn=4eb192df0001000a0000 > [02/Nov/2011:18:58:39 +0000] conn=74 op=4 MOD dn="uid=test,ou=Special > Users,dc=alt" > [02/Nov/2011:18:58:39 +0000] conn=74 op=4 RESULT err=16 tag=103 > nentries=0 etime=0 csn=4eb192df0002000a0000 > [02/Nov/2011:18:58:39 +0000] conn=74 op=5 UNBIND > [02/Nov/2011:18:58:39 +0000] conn=74 op=5 fd=69 closed - U1 > > There are three modifications that happen at this time, around setting > the password, allowed change time, etc. > > Is there a document somewhere which helps decipher some of these codes? > what is a csn? etc... http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Configuration_and_Command-Line_Tool_Reference/index.html#Access_Log_and_Connection_Code_Reference You probably don't need to worry about csn. > The objectClasses on the object in both sides of the tree are identical > (at least last I checked), so the inheritance of parameters should be > the same (and I can set these attributes with ldapmodify). I will > review/verify again tomorrow. > > What is the definition of no such attribute, in the context of a > modify? It means you are attempting to modify an attribute which does not exist in the entry, or you are attempting to delete a value which does not exist. > If the attribute is allowed on the class, but is not defined on > the object, should it just set it anyway? What is "it" in "should _it_ just set"? > > > > > If all else fails, you could use wireshark/tcpdump to inspect the > packets received and sent by the directory server. > > > > Unfortunately, it is all encrypted. There are ways around that too. > Thanks guys, I do help the assist. > > -Brandon > > -- > 389 users mailing list > 389-users@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
