From dev-return-35360-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Fri Oct 15 20:22:38 2010 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 73695 invoked from network); 15 Oct 2010 20:22:38 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 15 Oct 2010 20:22:38 -0000 Received: (qmail 98923 invoked by uid 500); 15 Oct 2010 20:22:38 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 98886 invoked by uid 500); 15 Oct 2010 20:22:38 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 98878 invoked by uid 99); 15 Oct 2010 20:22:38 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Oct 2010 20:22:38 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of akarasulu@gmail.com designates 209.85.216.171 as permitted sender) Received: from [209.85.216.171] (HELO mail-qy0-f171.google.com) (209.85.216.171) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Oct 2010 20:22:33 +0000 Received: by qyk9 with SMTP id 9so1770095qyk.16 for ; Fri, 15 Oct 2010 13:22:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=0pgZebpFai6c9/eCNE1dubhUQFoT+pv9+/f7d858gUA=; b=ueY/g+hQmfMpw04wyF9dkDK3/Di9NWHTxfi5bkORemIOAoIXJ/5EmRh0yNE+UC2ohT yYNVCfI0CLz+J1dnTo9CncimoOL4+usVmsuaYjB1FKWSw7KjVe0KfdZiv1wU5TVKqUza a1UbXCmYlVCV6e2ROc+o7L+TWL2/FlDIKvXhs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=ltGgbDhR1AA18pMWCW6Y9cfcMJD3bZWm0RLfNRKONW/5OVkCzzKfMoa1g8jykfGXuD LV+Y4PD7YlTtldjTfdA/z31ig7WNeblRgeZIyXar553x6i1KftZHlNbo+oHv0fphjrGS jntRtXrk+XYbkZtGHzOtdJcOUG2Oix2R64CUE= MIME-Version: 1.0 Received: by 10.229.189.195 with SMTP id df3mr1123250qcb.143.1287174132401; Fri, 15 Oct 2010 13:22:12 -0700 (PDT) Sender: akarasulu@gmail.com Received: by 10.229.239.203 with HTTP; Fri, 15 Oct 2010 13:22:12 -0700 (PDT) In-Reply-To: References: Date: Fri, 15 Oct 2010 23:22:12 +0300 X-Google-Sender-Auth: xI9q4zPeB83hKURhVSrF4N4K3ww Message-ID: Subject: Re: [ApacheDS 2.0] Should we remove the 'System' partition? From: Alex Karasulu To: Apache Directory Developers List Content-Type: multipart/alternative; boundary=00163630ff8fed090c0492ad9450 --00163630ff8fed090c0492ad9450 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 15, 2010 at 3:42 PM, Stefan Seelmann wrote: > Hi Pierre-Arnaud, > > On Fri, Oct 15, 2010 at 2:12 PM, Pierre-Arnaud Marcelot > wrote: > > Hi Dev, > > > > I'm really wondering if we should not remove the 'System' partition. > > > > The only interesting piece of information we're taking from it is the > admin user, especially the its password. > > Wouldn't be more interesting to store this information in the config > partition? > > The admin entry also contains the X.509 certificate and private/public > keys for LDAPS and StartTLS extended operation. But I think the config > partiton is a better place for that information. And it should also be > possible to reference the certificate and keys to a file in > filesystem. > > We should also probably disassociate the server certificate from the admin user. > > Except the Admin user the other entries of that partition look like crap > and legacy from old versions. > > > > The following configuration entries are no longer used: > > - ou=configuration,ou=system > > | - ou=interceptors,ou=configuration,ou=system > > | - ou=partitions,ou=configuration,ou=system > > | - ou=services,ou=configuration,ou=system > Yeah this never really got used. With the new configuration partition we no longer need this. > > I don't know the role of this entry 'prefNodeName=sysPrefRoot,ou=system', > if it still has any role? > > It was to provide a Preferences API implementation with storage in the server. Was at some point considering using it with user specific settings to store on the server when they log in and/or for various OSGi related matters. This is also dead wood. > > The following entries are not very useful too: > > - ou=groups,ou=system > > | - cn=Administrators,ou=groups,ou=system > > - ou=users,ou=system > > AFAIK they are still used from the "simplified" access control system, > has to be checked. > Yes this actually is important. I think we can elevate someone to admin level status by putting them into the Administrator group regardless of which (ACI) access control system is being used. The idea is the admin user should not be used after the first configuration and if people need superpowers they should be doing it under their own DN once put into this group. So this needs to stay. > > Isn't is better that the user creates its users in its own partition? > > Even our admin user is not in the 'ou=users' organizational unit... > > Yeah this might be advantageous. Admin user does not need to be in users that was just an empty container put in there to add users if you like without creating extra partitions. Now we have the schema + config partition in addition to system by default. It's getting expensive memory wise as well. In fact what I wanted to do is create a default (where DN="") centrally rooted partition as soon as we get nestable partitions working. However never got there. So this would allow us to have a AP at the root DN to govern the entire did and also allow us to manage the RootDSE better. If we did away with the system partition we might have an issue with initialization. Have to check this out. There might be some chicken and egg problem to deal with but it might have gone away. Only way to see is to reread the code or just try the change :-). > > As you can see, the only valid information in the whole partition is the > credentials of the admin (should we say default) user. > > That and the Administrators group. > > I really think this information should be placed in the configuration (we > could also allow the redefinition of the admin user DN). > > It would allow the user to edit these settings without having to start > the server (at least) once. > > I'm +1, but keep in mind that we use "ou=system" in many places, > especially in tests. > > Yeah that will be ugly. I wish we made this into a constant somewhere :-). That might be the first step. -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu --00163630ff8fed090c0492ad9450 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Oct 15, 2010 at 3:42 PM, Stefan Seelmann= <seelmann@apac= he.org> wrote:
Hi Pierre-Arnaud,

On Fri, Oct 15, 2010 at 2:12 PM, Pierre-Arnaud Marcelot <pa@marcelot.net> wrote:
> Hi Dev,
>
> I'm really wondering if we should not remove the 'System' = partition.
>
> The only interesting piece of information we're taking from it is = the admin user, especially the its password.
> Wouldn't be more interesting to store this information in the conf= ig partition?

The admin entry also contains the X.509 certificate and private/publi= c
keys for LDAPS and StartTLS extended operation. But I think the config
partiton is a better place for that information. And it should also be
possible to reference the certificate and keys to a file in
filesystem.


We should also= probably disassociate the server certificate from the admin user.
=A0
> Except the Admin user the other entries of that partition look like cr= ap and legacy from old versions.
>
> The following configuration entries are no longer used:
> - ou=3Dconfiguration,ou=3Dsystem
> =A0| - ou=3Dinterceptors,ou=3Dconfiguration,ou=3Dsystem
> =A0| - ou=3Dpartitions,ou=3Dconfiguration,ou=3Dsystem
> =A0| - ou=3Dservices,ou=3Dconfiguration,ou=3Dsystem

Yeah this never really got used. With the new confi= guration partition we no longer need this.
=A0
> I don't know the role of this entry 'prefNodeName=3DsysPrefRoo= t,ou=3Dsystem', if it still has any role?


It was to provide a Preferences API implementation with st= orage in the server. Was at some point considering using it with user speci= fic settings to store on the server when they log in and/or for various OSG= i related matters.=A0

This is also dead wood.
=A0
> The following entries are not very useful too:
> - ou=3Dgroups,ou=3Dsystem
> =A0| - cn=3DAdministrators,ou=3Dgroups,ou=3Dsystem
> - ou=3Dusers,ou=3Dsystem

AFAIK they are still used from the "simplified" access cont= rol system,
has to be checked.

Yes this actually is= important. I think we can elevate someone to admin level status by putting= them into the Administrator group regardless of which (ACI) access control= system is being used. The idea is the admin user should not be used after = the first configuration and if people need superpowers they should be doing= it under their own DN once put into this group.

So this needs to stay.


> Isn't is better that the user creates its users in its own partiti= on?
> Even our admin user is not in the 'ou=3Dusers' organizational = unit...


Yeah this might be ad= vantageous. =A0Admin user does not need to be in users that was just an emp= ty container put in there to add users if you like without creating extra p= artitions.

Now we have the schema + config partition in addition t= o system by default. It's getting expensive memory wise as well.
<= div>
In fact what I wanted to do is create a default (where D= N=3D"") centrally rooted partition as soon as we get nestable par= titions working. However never got there. So this would allow us to have a = AP at the root DN to govern the entire did and also allow us to manage the = RootDSE better.=A0

If we did away with the system partition we might have = an issue with initialization. Have to check this out. There might be some c= hicken and egg problem to deal with but it might have gone away. Only way t= o see is to reread the code or just try the change :-).

=A0
> As you can see, the only valid information in the whole partition is t= he credentials of the admin (should we say default) user.


That and the Administrators group.
=A0
> I really think this information should be placed in the configuration = (we could also allow the redefinition of the admin user DN).
> It would allow the user to edit these settings without having to start= the server (at least) once.

I'm +1, but keep in mind that we use "ou=3Dsystem" in m= any places,
especially in tests.


Yeah that will be ugly. I wish we made= this into a constant somewhere :-). That might be the first step.=A0=A0


--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://d= irectory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu
--00163630ff8fed090c0492ad9450--