Friday May 18, 2007 | cn=Directory Manager All about Directory Server |
OpenDS 0.9.0-build001 is now availableI have just uploaded OpenDS 0.9.0-build001, built from revision 1918 of our source tree, to our weekly builds folder. The direct link to download the core server is: https://opends.dev.java.net/files/documents/4926/58055/OpenDS-0.9.0-build001.zip. The direct link to download the DSML gateway is: https://opends.dev.java.net/files/documents/4926/58056/OpenDS-0.9.0-build001-DSML.war.I have also updated the archive that may be used to install OpenDS via Java Web Start. You may launch that using the URL http://builds.opends.org/install/QuickSetup.jnlp, or visit https://www.opends.org/wiki/page/OverviewOfTheQuickSetupTool for more information. Note that starting with this build, we have changed our build numbering system to be more consistent with other projects. The base build number is the build of the next official release we are working toward (in our case 0.9.0, since 0.8.0 was released last week), rather than what we had been using in the past, which was the number of the last official release. Some of the changes that have been incorporated since the 0.8.0 release build include:
OpenDS and Other Sun-Sponsored Open Source ProjectsLast night, I gave a talk at CACTUS (the Capital Area Central Texas UNIX Society, http://www.cactus.org/). Since it was a UNIX-focused group, the first part of the talk was about general open source projects that Sun is involved with, including OpenSolaris, OpenSPARC, and OpenJDK. The second part of the talk was more specific to OpenDS, including general information, information about its current state and what still needs to be done, and how people can get involved.As requested, I have uploaded the slides for my presentation. [UPDATE] -- We have now posted the slides and an MP3 recording of the presentation to the OpenDS documentation wiki. You can find them at https://www.opends.org/wiki/page/OpenDSPresentations. Posted by cn_equals_directory_manager ( May 18 2007, 11:17:47 AM CDT ) Permalink The OpenDS Virtual Attribute SubsystemOne of the key OpenDS components that makes virtual static groups possible is the virtual attribute subsystem. Virtual attributes are those attributes whose values are computed on the fly rather than actually being stored in the database. There are a number of uses for virtual attributes in the server, and there is an API (org.opends.server.api.VirtualAttributeProvider) that can be used to create new types of virtual attributes.
Some of the virtual attribute providers we have defined in OpenDS include:
Virtual Attribute ConfigurationVirtual attributes are configured below "cn=Virtual Attributes,cn=config". These entries need to have the ds-cfg-virtual-attribute object class, which requires the following attributes:
With only the above configuration attributes, the virtual attribute may be generated for all entries. If you wish to pare down the set of entries in which the virtual attribute may be present, you can use one or more of the additional configuration attributes (all of which are multivalued):
User-Defined Virtual AttributesUser-defined virtual attributes can be used to supply specific administrator-supplied values to entries matching the virtual attribute criteria. The net effect is essentially the same as what you can get using the Class of Service (CoS) capabilities of the Sun Java System Directory Server, but I think that the implementation and configuration is much more straightforward (although I may be a bit biased since I wrote the code).In order to create a user-defined virtual attribute, add a new entry to the server configuration. It should contain the ds-cfg-user-defined-virtual-attribute object class (which extends the ds-cfg-virtual-attribute class and therefore takes all of the configuration attributes that it uses as described above), and it should also have at least one value for the ds-cfg-virtual-attribute-value attribute to specify the value that entries matching the criteria should be given. The ds-cfg-virtual-attribute-class should be set to " org.opends.server.extensions.UserDefinedVirtualAttributeProvider".
For example, the following configuration entry assigns a default postalCode value for everyone in the Austin office (although if they already have a postalCode value in their entry, it will be used instead of the virtual value): dn: cn=Austin postalCode,cn=Virtual Attributes,cn=config objectClass: top objectClass: ds-cfg-virtual-attribute objectClass: ds-cfg-user-defined-virtual-attribute cn: Austin postalCode ds-cfg-virtual-attribute-class: org.opends.server.extensions.UserDefinedVirtualAttributeProvider ds-cfg-virtual-attribute-enabled: true ds-cfg-virtual-attribute-type: postalCode ds-cfg-virtual-attribute-value: 78727 ds-cfg-virtual-attribute-conflict-behavior: real-overrides-virtual ds-cfg-virtual-attribute-base-dn: ou=People,dc=example,dc=com ds-cfg-virtual-attribute-filter: (&(l=Austin)(st=Texas)) Note that because of the way that virtual attributes are implemented in OpenDS, you can use them to supply values for pretty much any kind of attribute, including operational attributes. For example, you could use it to set the ds-pwp-password-policy-dn operational attribute to give users a custom password policy, ds-rlim-size-limit to define a custom size limit, or ds-privilege-name to assign one or more privileges. For example, the following virtual attribute configuration entry gives a special set of privileges to everyone on the "Administrators" group: Posted by cn_equals_directory_manager ( May 14 2007, 01:31:47 PM CDT ) Permalinkdn: cn=Administrator Privileges,cn=Virtual Attributes,cn=config objectClass: top objectClass: ds-cfg-virtual-attribute objectClass: ds-cfg-user-defined-virtual-attribute cn: Administrator Privileges ds-cfg-virtual-attribute-class: org.opends.server.extensions.UserDefinedVirtualAttributeProvider ds-cfg-virtual-attribute-enabled: true ds-cfg-virtual-attribute-type: ds-privilege-name ds-cfg-virtual-attribute-value: modify-acl ds-cfg-virtual-attribute-value: config-read ds-cfg-virtual-attribute-value: config-write ds-cfg-virtual-attribute-value: ldif-import ds-cfg-virtual-attribute-value: ldif-export ds-cfg-virtual-attribute-value: backend-backup ds-cfg-virtual-attribute-value: backend-restore ds-cfg-virtual-attribute-value: password-reset ds-cfg-virtual-attribute-value: update-schema ds-cfg-virtual-attribute-conflict-behavior: merge-real-and-virtual ds-cfg-virtual-attribute-group-dn: cn=Administrators,ou=Groups,dc=example,dc=com Virtual Static Groups in OpenDSBig static groups (with tens or hundreds of thousands of members, or more) are a problem in many large enterprise directories. Since a static group contains an explicit list of the DNs of its members, the more members it contains, the larger the entry will become. Maintaining these groups can become a management problem and isn't very efficient, and some types of searches involving them can be slow as well. Dynamic groups are much better when the groups contain thousands or millions of members, but the problem is that many client applications don't support them. It's easy to understand why, since the client does have a significant amount of work to do in order to determine whether a given user is a member of a dynamic group, but it's also unfortunate because it leads to a lot of cases in which directories are forced to end up with large static groups just to suit those applications.OpenDS provides an interesting solution to this problem in the form of virtual static groups. It's a special type of entry that behaves like a static group, but all operations which attempt to determine membership are passed through behind the scenes to another group. In many cases, virtual static groups can give you the management and scalability benefits that dynamic groups provide while still maintaining compatibility with clients that only support static groups. In order to use virtual static groups, you first need a dynamic group that will provide the membership criteria. For the purposes of this example, let's say that we have the following entry: This group will automatically include any user with a location of Austin and a state of Texas. It's a much better choice for a dynamic group than a static group because the set of members will be automatically adjusted as new users are added, existing users are removed, or if someone moves from one place to another.dn: cn=Austin Users,ou=Groups,dc=example,dc=com objectClass: top objectClass: groupOfURLs cn: Austin Users memberURL: ldap:///ou=People,dc=example,dc=com??sub?(&(l=Austin)(st=Texas)) To create a virtual static group that allows clients to interact with the Austin Users group in a static manner, add the following entry: With this group,dn: cn=Virtual Static Austin Users,ou=Groups,dc=example,dc=com objectClass: top objectClass: groupOfUniqueNames objectClass: ds-virtual-static-group cn: Virtual Static Austin Users ds-target-group-dn: cn=Austin Users,ou=Groups,dc=example,dc=com uniqueMember will be treated as a virtual attribute (if we had used the groupOfNames instead of groupOfUniqueNames, then the member attribute would have been used instead). The key here is the ds-virtual-static-group auxiliary object class and the corresponding ds-target-group-dn attribute. OpenDS sees this and knows that it should treat the entry like a virtual static group.
Now, consider that the following users exist in the directory: With thiese entries, the user "nawilson" will be considered a member of the group because he is located in Austin, Texas, whereas user "bowendk" will not. A quick test withdn: uid=nawilson,ou=People,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson uid: nawilson givenName: Neil sn: Wilson cn: Neil Wilson l: Austin st: Texas dn: uid=bowendk,ou=People,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson uid: bowendk givenName: Don sn: Bowen cn: Don Bowen l: Peoria st: Illinois ldapsearch confirms this:
Note that while dynamic groups are very efficient for determining whether a given user is a member, they can be very inefficient when it comes to retrieving the entire set of members. This is also the case with virtual static groups that use dynamic groups to get their membership information. If you were to actually retrieve the$ bin/ldapsearch -b 'cn=Virtual Static Austin Users,ou=Groups,dc=example,dc=com' \ -s base --countEntries '(uniqueMember=uid=nawilson,ou=People,dc=example,dc=com)' 1.1 dn: cn=Virtual Static Austin Users,ou=Groups,dc=example,dc=com # Total number of matching entries: 1 $ bin/ldapsearch -b 'cn=Virtual Static Austin Users,ou=Groups,dc=example,dc=com' \ -s base --countEntries '(uniqueMember=uid=bowendk,ou=People,dc=example,dc=com)' 1.1 # Total number of matching entries: 0 uniqueMember attribute to list all of the members, that could be a very expensive operation. OpenDS provides a way to deal with this in the form of the ds-cfg-allow-retrieving-membership configuration attribute. It defaults to "false", which means that queries like those above which try to determine whether a given user is a member of the group will succeed, but the uniqueMember attribute won't be included in the resulting entry even if it's requested by the client. Most well-behaved clients won't ask for the membership attribute anyway, and of those that do many of them don't use it in any way, so this doesn't cause a problem. However, if you do have an application that expects to retrieve the membership attribute and won't behave properly if it isn't returned, then you're probably stuck with a traditional static group.
Also note that there's no requirement that virtual static groups be used only with dynamic groups. You can actually use it with any type of group (other than another virtual static group, to avoid circular references) that OpenDS supports (right now, we've only got static and dynamic groups, but we may add other types in the future). For example, if you've got a static group based on the groupOfUniqueNames object class but your client only supports groups with the groupOfNames class, then you could create a virtual static group with the groupOfNames structural object class and point the ds-target-group-dn attribute at the static group with the groupOfUniqueNames class.
Posted by cn_equals_directory_manager ( May 11 2007, 11:45:17 AM CDT ) Permalink OpenDS builds on OpenJDK on OpenSolarisSun announced today that OpenJDK is now fully-buildable. Aside from a few third-party components that Sun doesn't have the right to open source (which are currently available in binary-only form until that can be resolved), the entire JDK codebase is GPLv2 with the classpath exception. I decided to take a shot and see what it takes to build it. It turns out, it's a pretty simple process.There are instructions available for building with NetBeans, but honestly I don't use NetBeans and didn't particularly want to install it just for this. Plus, if you really do need to have NetBeans to build it, then that somehow doesn't seem fair. At any rate, I didn't find not using NetBeans to be a problem. The system that I was using was an Ultra 40 Workstation running Solaris Nevada (Sun's OpenSolaris distribution -- see http://www.opensolaris.org/os/community/on/ and http://www.opensolaris.org/os/project/onnv/ for details) build 61. I already had the Sun Studio 11 compilers installed, and the Subversion client is included as part of Nevada. Here's what I did to build OpenJDK and then use that to build OpenDS:
./build.sh all" to perform a full build of OpenDS including the DSML gateway, Javadoc documentation, and running all 34,000+ unit tests. Everything passed with flying colors. As far as OpenDS is concerned, there is no distinguishable difference between the OpenJDK build that I just created and the real Java 1.6.0_01-b06 build that you can download from http://java.sun.com/.
Posted by cn_equals_directory_manager ( May 08 2007, 05:02:19 PM CDT ) Permalink OpenDS 0.8 Is Now AvailableOpenDS has been public for about nine months now, and for all of that time we have tagged it with a 0.1. With our latest build, we're bumping it up to 0.8. In a few months, we'll go to 0.9, and then 1.0 a couple after that.The easiest way to get OpenDS 0.8 is to use our Java Web Start installer (read more about it at https://www.opends.org/wiki/page/OverviewOfTheQuickSetupTool). Alternately, you can download the full server zip file at https://opends.dev.java.net/files/documents/4926/57426/OpenDS-0.8.zip. We also have a DSML gateway available as a WAR file at https://opends.dev.java.net/files/documents/4926/57427/OpenDS-0.8-DSML.war. If you haven't looked at OpenDS recently, here are some of the things we've added in the last few months:
OpenDS Documentation WikiIt seems that I've gone through another span of not writing much here, but as usual I've been busy with other things. OpenDS is coming along quite nicely, and we've added lots of new features and done a lot of cleanup work. One of the things that we've been focusing on recently is documentation. We've just recently moved all of our documentation to a wiki, and in the process we have updated things that were out of date and added lots of new content. You can find it at https://www.opends.org/wiki.Some of the notable content that on the wiki includes:
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||