[ https://issues.apache.org/jira/browse/DIRSERVER-1787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13542269#comment-13542269 ] 

Emmanuel Lecharny commented on DIRSERVER-1787:
----------------------------------------------

The added LDIF files have syntax errors.

The first change should be :


dn: ou=system
changetype: modify
add: administrativeRole
administrativeRole: accessControlSpecificArea
-

The third entry should have :

objectClass: posixAccount

and

homeDirectory: <wwhatever fits your need>

in the entry.



                
> LdifFileLoader does not load a specific LDIF configuration
> ----------------------------------------------------------
>
>                 Key: DIRSERVER-1787
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-1787
>             Project: Directory ApacheDS
>          Issue Type: Bug
>          Components: ldap
>    Affects Versions: 1.5.5, 2.0.0-M8
>            Reporter: Jon Russell
>
> My goal is to create a user with read-only access. 
> I have two ldifs that I use to acheive this, one modifies the area that I want to grant access to:
> version: 1
> dn: ou=system
> changetype: modify
> add: administrativeRole
> administrativeRole: accessControlSpecificArea
> And the other creates the user:
> dn: cn=enableSearchForAllUsers,ou=system
> objectClass: top
> objectClass: subentry
> objectClass: accessControlSubentry
> subtreeSpecification: {}
> cn: enableSearchForAllUsers
> prescriptiveACI: { identificationTag "enableSearchForAllUsers", precedence 14, authenticationLevel simple, itemOrUserFirst userFirst: { userClasses { allUsers }, userPermissions { { protectedItems {entry, allUserAttributeTypesAndValues}, grantsAndDenials { grantRead, grantReturnDN, grantBrowse } } } } }
> # User account
> dn: uid=READER ,ou=users,ou=system
> cn: READER
> sn: Reader
> uid: READER
> uidNumber: 10000
> gidNumber: 10000
> objectClass: top
> objectClass: inetOrgPerson
> objectClass: organizationalPerson
> objectClass: person
> userPassword: secret
> When I import both of these ldifs using Apache Directory Studio, it works as I expect -- the user is created, and it has read only access.
> However, when I load the same files, in the same order, using LdifFileLoader:
>         LdifFileLoader ldifLoader = new LdifFileLoader(service.getAdminSession(), workingSchemaPath);
>         ldifLoader.execute();
> The result is not the same. No error messages are given, the end result is that the user is created, but with no read-only access. Since the user is created, I know that it's loading the ldifs from the proper place, and I haven't had trouble with other modification-based ldifs in the past. Do you know why this discrepancy would be there, and if there's anything I can do to get around it? It is difficult since there don't appear to be any errors, so I'm not sure what to search for...
> For further reference, here is the full function that I use the ldiffFileLoader in:
>  /**
>      * Load a specific LDIF
>      *
>      * @param ldifFileName The name of the LDIF file
>      * @param classloaderPath The classloader accessible path of the ldif file
>      * @throws Exception
>      */
>     public void loadLDIF (String ldifFileName, String classloaderPath) throws Exception {
>         InputStream schemaStream = null;
>         classloaderPath = classloaderPath + "/" + ldifFileName;
>         // support for DEVELOPMENT environment
>         if (EnvironmentalConstants.REPO_TOP != null) {
>             String schemaPath = EnvironmentalConstants.REPO_TOP + "/src/server" + classloaderPath;
>             OfmLogHandler.INFO ("Trying to use ldif at %s", schemaPath);
>             try {
>                 schemaStream = new FileInputStream (schemaPath);
>                 OfmLogHandler.INFO ("Using development ldif at %s", classloaderPath);
>             } catch (Exception e) {
>                 OfmLogHandler.WARNING ("initSchema: Development mode, but cannot find schema file at %s", schemaPath);
>                 OfmLogHandler.WARNING ("Exception: %s", e.getMessage ());
>                 schemaStream = null;
>             }
>         }
>         // support for PRODUCTION environment (or DEVELOPMENT when no schema file is found)
>         if (schemaStream == null) {
>             schemaStream = this.getClass ().getResourceAsStream (classloaderPath);
>             OfmLogHandler.INFO ("Using production ldif at %s", classloaderPath);
>         }
>         // If we can't find the schema using the logic above, we're in serious trouble
>         if (schemaStream == null) {
>             OfmLogHandler.SEVERE ("initSchema: Unable to find schema file.  Cannot proceed.");
>             System.exit(1);
>         }
>         // put contents of the schema stream into the working file
>         String workingSchemaPath = service.getWorkingDirectory() + "/" + ldifFileName;
>         try {
>             FileOutputStream workingSchemaStream = new FileOutputStream (workingSchemaPath);
>             IOUtils.copy (schemaStream, workingSchemaStream);
>             workingSchemaStream.close ();
>         } catch (Exception e) {
>             OfmLogHandler.SEVERE ("initSchema: Unable to write to working schema file (%s).  Cannot proceed.", workingSchemaPath);
>             OfmLogHandler.SEVERE ("Exception: %s", e.getMessage ());
>             e.printStackTrace ();
>             System.exit (1);
>         }
>         OfmLogHandler.DEBUG ("Loading working schema from: %s", workingSchemaPath);
>         LdifFileLoader ldifLoader = new LdifFileLoader(service.getAdminSession(), workingSchemaPath);
>         ldifLoader.execute();
>         OfmLogHandler.INFO("LDAP ldif information loaded from %s", workingSchemaPath);
>     }
> Thanks,
> Jon Russell

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira