directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Perelman <mikhail_perel...@hotmail.com>
Subject RE: ldif import works in studio, fails with LdifFileLoader
Date Tue, 24 Feb 2015 18:30:24 GMT
I looked at the issue that you have opened on this matter, and it seems to suggest that the
workaround entails splitting the .ldif file into two .ldif files -- one for content and another
for actions. I i went ahead and isolated the following entry into its own separate .ldif file:

dn: dc=mycompany,dc=com
changetype: modify
add: administrativeRole
administrativeRole: accessControlSpecificArea

But that still does not add administrativeRole to my partition. Could you please provide a
more detailed description of the workaround? Thanks!

> Date: Tue, 24 Feb 2015 18:04:23 +0800
> Subject: Re: ldif import works in studio, fails with LdifFileLoader
> From: kayyagari@apache.org
> To: users@directory.apache.org
> 
> On Tue, Feb 24, 2015 at 3:54 PM, Michael Perelman <
> mikhail_perelman@hotmail.com> wrote:
> 
> > Ok, I understand the need for proper order within an .ldif file when
> > loading one via LdifFileLoader, thanks!
> >
> > What I am still not clear about is how to properly add administrativeRole
> > entry. I have modified my .ldif file to look like this:
> >
> > dn: dc=mycompany,dc=com
> > objectclass: domain
> > objectclass: top
> > objectclass: extensibleObject
> > dc: mycompany
> > ou: mycompany
> >
> > dn: dc=mycompany,dc=com
> > changetype: modify
> > add: administrativeRole
> > administrativeRole: accessControlSpecificArea
> >
> > LDIF is not allowed to contain both entries and changesets, however Studio
> allows this and we may support[1] this mode in
> server as well.
> 
> For now, the workaround is to add this attribute during that entry
> creation
> 
> [1] https://issues.apache.org/jira/browse/DIRAPI-222
> 
> > dn: cn=allowUserSelfMod,dc=mycompany,dc=com
> > objectClass: subentry
> > objectClass: accessControlSubentry
> > objectClass: top
> > cn: allowUserSelfMod
> > prescriptiveACI: { identificationTag "", precedence 0, authenticationLevel
> > s
> >  imple, itemOrUserFirst userFirst: { userClasses { thisEntry },
> > userPermissi
> >  ons { { protectedItems { entry }, grantsAndDenials { grantBrowse,
> > grantRetu
> >  rnDN, grantModify, grantRead } }, { protectedItems { allAttributeValues {
> > u
> >  serPassword } }, grantsAndDenials { grantRemove, grantAdd } } } } }
> > subtreeSpecification: { }
> >
> > dn: ou=people,dc=mycompany,dc=com
> > objectClass: organizationalUnit
> > objectClass: top
> > ou: people
> >
> > This is still not loading properly via LdifFileLoader. In your previous
> > response, you stated that administrativeRole must be added to the entry
> > immediately, yet I was still not able to make it work. Please show me the
> > proper way to configure it.
> >
> > To answer your last question, I am using an admin session to import the
> > .ldif file.
> >
> > Thanks!
> >
> > On 11/02/15 19:26, Michael Perelman wrote :
> > > Hi. My case involves an embedded instance of ADS-M17 where I load a
> > simple .ldif file
> > during start-up using LdifFileLoader instance. I always use the Studio to
> > perform initial
> > tests, and it works in this particular case. But when I use
> > LdifFileLoader, the security-related
> > entities are never created. Here is what the .ldif looks like:
> >
> > LdapStudio will order the LDIF before injecting it. The LdifLoader wont.
> > Typically, here, the dc=myCompany,dc=com is not the first entry, and the
> > loader will yell at you because it's messing when it will try to load
> > the first entry (ou=people,dc=mycompany,dc=co).
> >
> > Another thing : why are you modifying the entry you just injected before
> > (dc=mycompany,dc=com)? It's a better idea to add the administrativeRole
> > attribute to the entry immediately.
> >
> > Last, not least: which user are you using to inject the entries ?
> >
> > >
> > > dn: ou=people,dc=mycompany,dc=com
> > > objectClass: organizationalUnit
> > > objectClass: top
> > > ou: people
> > >
> > > dn: dc=mycompany,dc=com
> > > objectclass: domain
> > > objectclass: top
> > > objectclass: extensibleObject
> > > dc: mycompany
> > > ou: mycompany
> > >
> > > dn: dc=mycompany,dc=com
> > > changetype: modify
> > > add: administrativeRole
> > > administrativeRole: accessControlSpecificArea
> > >
> > > dn: cn=allowUserSelfMod,dc=mycompany,dc=com
> > > objectClass: subentry
> > > objectClass: accessControlSubentry
> > > objectClass: top
> > > cn: allowUserSelfMod
> > > prescriptiveACI: { identificationTag "", precedence 0,
> > authenticationLevel s
> > >  imple, itemOrUserFirst userFirst: { userClasses { thisEntry },
> > userPermissi
> > >  ons { { protectedItems { entry }, grantsAndDenials { grantBrowse,
> > grantRetu
> > >  rnDN, grantModify, grantRead } }, { protectedItems { allAttributeValues
> > { u
> > >  serPassword } }, grantsAndDenials { grantRemove, grantAdd } } } } }
> > > subtreeSpecification: { }
> > >
> > > The dc=mycompany,dc=com partition and its ou=people org unit are created
> > successfully
> > when using either the Studio or the LdifFileLoader. Yet partition's
> > administrativeRole and
> > accessControlSubentry are only created when using the Studio, while
> > importing via LdifFileLoader
> > does not! And no exceptions are thrown at any time.
> > >
> > > Thanks!
> > >
> 
> 
> 
> 
> -- 
> Kiran Ayyagari
> http://keydap.com
 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message