Hi! Excuse me for the way I explain myself (obviously bad). I mean:
1.- I have apply the syntax modification for nsViewFilter like this: ldapadd ... << EOF 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' ) - EOF 2.- I want to revert this change, that is, I wan to use the syntax in the 02common.ldif (the original) for this attribute, and erase the entry in 99user.ldif for this attribute. I can delete it because of the MAY clause in objectClasses. I can't stop the DS and remove the line in the file because of schema replication. Can I perform this??? How??? I need to know how to do this (if possible) due to conflicts with some application or error which could appear. Regards, Moses. 2012/4/30 Rich Megginson <[email protected]> > On 04/30/2012 01:01 AM, Moisés Barba Pérez wrote: > > 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? > > > Recover from what? Where is the definition it is using now? How did you > change it? > > > > 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??? > > > The definition for the mail attribute comes from RFC 4524 - > http://www.ietf.org/rfc/rfc4524.txt > > 2.16. mail > > The 'mail' (rfc822mailbox) attribute type holds Internet mail > addresses in Mailbox [RFC2821] form (e.g., [email protected]). > > ( 0.9.2342.19200300.100.1.3 NAME 'mail' > EQUALITY caseIgnoreIA5Match > SUBSTR caseIgnoreIA5SubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) > > The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax and the > 'caseIgnoreIA5Match' and 'caseIgnoreIA5SubstringsMatch' rules are > described in [RFC4517]. > > > In 389 (current version) this definition is in 05rfc4524.ldif > > Note that if you change this to use DirectoryString (full utf-8 character > range) instead of IA5String (7-bit ascii only) you will leave yourself open > to having interoperability issues with other software that expect the > standard behavior. > > > > 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 > [email protected]https://admin.fedoraproject.org/mailman/listinfo/389-users > > >
-- 389 users mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/389-users
