directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jon Russell (JIRA)" <j...@apache.org>
Subject [jira] [Created] (DIRSERVER-1787) LdifFileLoader does not load a specific LDIF configuration
Date Wed, 02 Jan 2013 16:48:12 GMT
Jon Russell created DIRSERVER-1787:
--------------------------------------

             Summary: 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: 2.0.0-M8, 1.5.5
            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

Mime
View raw message