Hi, you are absolutely right and I can understand that behaviour with syntax. The thing is: I want to recover the original syntax, the 02common one, how can I do that? I can't use replace obviously, add will not recover the original, Is there some way to procced?
In the mail issue: The entry has the attribute -> mail:mBarbA.MaiL@xxxx The access log [30/Apr/2012:08:41:02 +0200] conn=6019 op=1 SRCH base="xxxx" scope=2 filter="(&(objectClass=posixAccount)(mail=mbarba.mail@xxxx))" attrs=ALL [30/Apr/2012:08:41:02 +0200] conn=6019 op=1 RESULT err=0 tag=101 nentries=0 etime=0 [30/Apr/2012:08:51:52 +0200] conn=6040 op=1 SRCH base="xxxx" scope=2 filter="(&(objectClass=posixAccount)(mail=mBarbA.MaiL@xxxx))" attrs=ALL [30/Apr/2012:08:51:52 +0200] conn=6040 op=1 RESULT err=0 tag=101 nentries=1 etime=0 I can't upgrade the version of DS by the moment, I have the upgrade in mind but not possible yet. Any idea about how to change this to case-insensitive??? Regards, Moses 2012/4/27 Noriko Hosoi <[email protected]> > Hi Moisés, > > Moisés Barba Pérez wrote: > > Hi, > > I have replaced the OID and now there is no syntax error. The ticket is > https://fedorahosted.org/389/ticket/349. > > Thanks! > > > I have perform this ldif: > > dn: cn=schema > changetype: modify > add: attributeTypes > attributeTypes: ( 2.16.840.1.113730.3.1.3023 NAME 'nsViewFilter' DESC > 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 > X-ORIGIN 'Netscape Directory Server' ) > - > > How can I recover the initial configuration of the attributeType???? I > have in my schema files 2 lines for nsViewFilter after apply the indicated > ldif, one with the old OID and in other file one with the new OID. I would > like to know how to delete the newer in case of problems with this OID > change. > > It's normal. Please run the next command line and check nsViewFilter. > You should see just one that you added above. > ldapsearch [...] -b "cn=schema" attributeTypes | grep nsViewFilter > > AttributeTypes nsViewFilter is originally defined in 02common.ldif which > is overridden by your new definition which is stored in the user defined > schema file 99user.ldif. > > > ---- > > In the another hand: in my DS the attribute mail is case-sensitive. If I > perform the same search as you I get nothing for one of my mail attributes > whit upper characters. Maybe 389DS in 1.2.5 is case-sensitive??? > > It cannot be... Could you give us a snippet of your access log > (/var/log/dirsrv/slapd-ID/access), which includes the SRCH options and the > result? > > [27/Apr/2012:10:05:14 -0700] conn=7 op=1 SRCH base="dc=example,dc=com" > scope=2 > filter="([email protected])"<%[email protected]%29>attrs="mail" > [27/Apr/2012:10:05:14 -0700] conn=7 op=1 RESULT err=0 tag=101 > *nentries=1*etime=0 > > [27/Apr/2012:10:05:36 -0700] conn=8 op=1 SRCH base="dc=example,dc=com" > scope=2 > filter="([email protected])"<%[email protected]%29>attrs="mail" > [27/Apr/2012:10:05:36 -0700] conn=8 op=1 RESULT err=0 tag=101 > *nentries=1*etime=0 > > Also, if you think the version 1.2.5 is not working well, could you > upgrade 389-ds-base to the latest and try the same operation? > 389 Directory Server 1.2.10.4 is now available (March 29, 2012) > > 389 Directory Server 1.2.10.4 is now available from the Stable > repositories. > > - See the Release > Notes<http://directory.fedoraproject.org/wiki/Release_Notes>for more > information > > > Thanks, > --noriko > > > How can I solve this??? > > Regards, > Moses. > > > El 26 de abril de 2012 20:41, Noriko Hosoi <[email protected]> escribió: > >> Moisés Barba Pérez wrote: >> >> Hi, >> >> I have several questions about syntax and attributes, hope you can help >> me. >> >> - Why the attribute mail in DS is case sensitive?? Is there any problem >> changing it to non case sensitive? If there is no problem, how can I modify >> it? >> >> The syntax of mail is IA5 String. >> >> If you have >> >> mail: [email protected] >> >> then this command line returns the expected result. That is, not case >> sensitive. >> >> ldapsearch [...] -b 'dc=example,dc=com' >> "([email protected])"<%[email protected]%29>mail >> mail: [email protected] >> >> >> - I have a problem whit the syntax of the nsViewFilter attribute, the >> value of the attribute is: (ou=*ou=D. PERIÓDICO,o=xxxxx,dc=xxxx,dc=xxxx). I >> guess the problem is the character "Ó" but if it is possible to create the >> ou with special characters, should be possible create a nsViewFilter with >> special characters to??? (389DS 1.2.5) >> >> Currently, the syntax of nsViewFilter is IA5 String, which does not >> allow non-ascii characters. >> attributeTypes: ( 2.16.840.1.113730.3.1.3023 NAME 'nsViewFilter' DESC >> 'Netscape defined attribute type' SYNTAX >> *1.3.6.1.4.1.1466.115.121.1.26*X-ORIGIN 'Netscape Directory Server' ) >> >> Indeed, it'd be a needless restriction for nsViewFilter. Please open a >> ticket at https://fedorahosted.org/389/newticket. >> >> In the meantime, could you replace *1.3.6.1.4.1.1466.115.121.1.26* with >> 1.3.6.1.4.1.1466.115.121.1.15, and try? >> >> >> >> - I have read about the attribute nsslapd-allidsthreshold and its use in >> older versions. I have 389DS 1.2.5, have I to use it or it is deprecated??? >> I have search this parameters in my ldap servers and someones have it, and >> others don't, maybe this behaviour is because of actualizations of the DS >> but I would like to know if in 1.2.5 is needed or if i can delete it. >> >> nsslapd-allidsthreshold is replaced with nsslapd-idlistscanlimit in >> 389-ds-base. Not like nsslapd-allidsthreshold, nsslapd-idlistscanlimit is >> used just by the search operation and you can dynamically change the >> value. If the IDlist length is larger than the nsslapd-idlistscanlimit >> value, DS gives up generating the IDlist and uses ALLID, which scans all >> the entries in the primary database. >> >> >> Thank you in advance. >> >> Moses. >> >> >> -- >> 389 users mailing >> [email protected]https://admin.fedoraproject.org/mailman/listinfo/389-users >> >> >> >> -- >> 389 users mailing list >> [email protected] >> https://admin.fedoraproject.org/mailman/listinfo/389-users >> > > > > -- > 389 users mailing > [email protected]https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > -- > 389 users mailing list > [email protected] > https://admin.fedoraproject.org/mailman/listinfo/389-users >
-- 389 users mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/389-users
