directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trustin Lee <trus...@gmail.com>
Subject Re: Summer of Code Application
Date Tue, 14 Jun 2005 01:11:56 GMT
+1
 It would be nice if all persons who are interested with Summer of Code are 
looking at this thread!
 Trustin
 2005/6/14, Alex Karasulu <aok123@bellsouth.net>: 
> 
> Enrique Rodriguez wrote:
> 
> > Hi,
> >
> > Regarding the Summer of Code, I'll add a few points on ApacheDS
> > projects and repeat what Trustin noted, for completeness.
> >
> Kudos to you Enrique for getting to this. I was just about to try to
> summarize the candidate projects as promised to Mary in an email.
> Thanks! Let me put some links to the repository where people can
> actually start looking at the code to get some traction. Please look in
> line for links to svn ...
> 
> > 1) DHCP - DHCP codecs work, but without broadcast support in MINA
> > and, fundamentally, in NIO, there isn't much to be done here until
> > NIO2 in (hopefully) JDK 1.6. I stopped here, so the handler workflow
> > isn't totally complete, but should be straight-forward once MINA/NIO
> > supports broadcast. I consider this code dead until then and not a
> > worthwhile project.
> >
> http://svn.apache.org/viewcvs.cgi/directory/protocol-providers/dhcp/
> 
> No common code yet!
> 
> > 2) DNS - DNS codecs and workflow are in good shape. As Trustin
> > mentioned, the handlers need to get wired into the ApacheDS backing
> > store. Right now I have the handler stubbed out to simply echo the
> > DNS query as the response, but it is actually decoding and encoding.
> > Some time ago Alex added the DNS schema to the ApacheDS backend, so
> > that should be ready to go. This is seriously only a couple days
> > work, but we put it on hold for a number of other initiatives and lack
> > of demand. What's missing, but probably not worth a summer of work,
> > are the myriad of RFC's that add record types. I coded in the most
> > widely used ones, the ones supported by the schema, such as A and MX,
> > but there are quite a few more.
> 
> http://svn.apache.org/viewcvs.cgi/directory/protocol-providers/dns/
> 
> No common code yet!
> 
> >
> > 3) Kerberos - Kerberos is also mostly working, and tested for interop
> > with Windows and Linux. The major feature missing from RFC 1510 is
> > cross realm authentication, aka trust relationships. I have this on
> > my plate already, and it is mostly backend work, figuring out now how
> > I want to lay this out in the DIT. From more recent clarifications
> > documents, we are missing more modern encryption types, but these look
> > to be basic assembly based on crypto in the JDK or Bouncy Castle.
> >
> Protocol Provider (MINA):
> http://svn.apache.org/viewcvs.cgi/directory/protocol-providers/kerberos/
> 
> Shared (Common Code):
> http://svn.apache.org/viewcvs.cgi/directory/shared/kerberos/?rev=190518
> 
> > 4) NTP - NTP is pretty much done. It really just needs to be wired
> > into the ApacheDS server at some point. One possible project here is
> > NTP authentication. I didn't do any work on that, but the field is
> > supported by the codecs. NTP has no configuration, so part of tying
> > it into ApacheDS would be to at least make the port configurable.
> >
> > So, same projects that would be good to do over the summer:
> 
> 
> http://svn.apache.org/viewcvs.cgi/directory/protocol-providers/ntp/?rev=190518
> 
> No common code yet!
> 
> >
> >
> > 5) DNS GSS-TSIG - RFC 3645 - Generic Security Service Algorithm for
> > Secret Key Transaction Authentication for DNS (GSS-TSIG). I would be
> > willing to mentor someone on this:
> >
> > http://www.faqs.org/rfcs/rfc3645.html
> >
> > 6) Kerberos RC4-HMAC encryption type. This would be a nice project
> > and would require next to zero messy integration work. The package
> > 
> directory/shared/kerberos/trunk/common/src/java/org/apache/kerberos/crypto
> > has the encryption engines, and you'd be writing a new one of these to
> > produce Kerberos Cipher Text based on the RC4-HMAC algorithm.
> >
> > 
> http://mirror.aarnet.edu.au/pub/samba/specs/draft-brezak-win2k-krb-rc4-hmac-02.txt
> >
> >
> > There are also a couple "new" encryption types based on AES that we
> > don't support, but combined with this RC4-HMAC engine, would add up to
> > a nice-sized project.
> >
> > 7) LDAP ACL - I know we want this but I'm no expert here, just
> > familiar from a usage standpoint with OpenLDAP. In the past Alex has
> > mentioned RFC's 2820, 2829, 3112, and 3062.
> 
> See LDAP section below ...
> 
> > 8) ApacheDS backing store - We don't talk about this much, but I
> > don't think many of us like the JDBM backing store. We've talked
> > about doing versions with Derby or Prevayler. JDBM has not had a
> > release since 2001 and doesn't appear to be in active development. I
> > seem to recall also that the performance stats were poor.
> 
> Also we'd like to see an in memory store but I guess Prevayler covers
> this. WRT Derby I've inquired with DeBruiner (sorry if I spelled the
> name wrong) at last ApCon about efficiency of hierarchical data storage
> and it did not look good ... this was one of the weaker points to Derby
> integration.
> 
> WRT to JDBM I agree its been lagging and is slow especially on writes
> but this is ok. I think there are more efficient ways we can be using
> JDBM too however that needs more exploration. Regardless we have yet
> another option since backends are pluggable: using SleepyCat's JE in
> place of JDBM. A common interface for all BTree based stores can be
> used to switch between JE and JDBM. However this may not be necessary
> since the plugability is achieved at the backend partition level.
> 
> >
> > 9) SASL - SASL has been discussed a bunch on this list. I refer you
> > to the archives. Specifically, we'd like to add GSS-API/Kerberos
> > support.
> 
> General
> =====
> 
> Generally for all ApacheDS backed services I recommend building out a
> configuration OU under the ou=system context/partition. Services like
> Kerberos can use the Preferences API to manage their configuration
> information there on changes to defaults. It's like our own registry.
> Here's the code location for a Preferences implementation within the
> ApacheDS server core:
> 
> 
> http://svn.apache.org/viewcvs.cgi/directory/apacheds/trunk/core/src/main/java/org/apache/ldap/server/prefs/
> 
> ASN.1 Libraries
> ==========
> 
> 1). Runtime
> 
> Currently Emmanuel is working in the sandbox to replace the existing
> ASN.1 libraries. He has a solution that is 8x faster than the present
> implementation. The present implementation implements a digester
> approach (yes like one used in commons for XML) but is based on matching
> patterns in the hierarchy of streaming tags: turns out to be a poor
> approach from a performance standpoint. It uses rules to that push pop
> objects and operate on them. It's dynamic and in theory thought to be
> more flexible. It turned out to be a nightmare in terms of code
> management. A finite state machine is much faster.
> 
> 2). Stub compiler
> 
> Some theories and experiments but we're still deciding on the direction.
> 
> 3). More LDAP controls in Emmanuel's code and in present day library if
> the new code base will take more time.
> 
> People interested in ASN.1 (BER and DER encoding) and a stub compiler
> should connect with Emmanuel Lecharny and Alan Cabrera.
> 
> LDAP Agenda, Direction, Road map etc ...
> =========================
> 
> 1). Subentries
> 
> In short we need to implement the subentries RFC to get to the next
> level where we can introduce Administrative Areas for various aspects:
> authorization, schema, collective attributes, replication etc..
> Administrative Areas are defined by subentries. Kurt Zeilenga from
> OpenLDAP worked on the RFC on subentries which can be found here:
> 
> http://www.faqs.org/rfcs/rfc3672.html
> 
> As you read into this various requirements will become apparent ... I
> have noted some here on the wiki but it is anemic to say the least:
> 
> http://wiki.apache.org/directory/SubtreeRefinements
> 
> I started out by adding code to parse and represent a refinement so they
> can be handled by the server in the shared code base since this might be
> used by clients as well later to interpret subentry information. Here's
> a the new package location in SVN where I had started adding this
> stuff. Not much is there so don't get excited :(.
> 
> 
> http://svn.apache.org/viewcvs.cgi/directory/shared/ldap/trunk/common/src/java/org/apache/ldap/common/subtree/
> 
> TODO:
> 
> * parser needs to be completed with these primitives.
> * add internal representation or data structure for quickly looking up
> an entries inclusion set within subtrees for evaluating different
> aspects of administration
> * add subsystems using interceptors to handle aspects:
> - authorization
> - collective attributes
> - schema
> 
> 2). More backend partition types as noted above by Enrique.
> 
> BTW the Prevayler based in memory backend will save major disk IO down
> the line when used to replace the system backend partition. All major
> subsystems that will be made more robust after subentries are
> implemented will most likely use the system partition to store
> persistent information. Prevayler from my understanding puts an entire
> db into memory loading it on startup. On shutdown changes are
> persisted or synch operations can be made intermittently.
> 
> Right now to solve this problem I usually setup the system partition
> parameters for JDBM to use as much cache as needed. This should result
> in theory to a similar behavior but I have not seen this to be the case.
> 
> 3). Possible replacement for AspectJ.
> 
> The JDK version issues with AspectJ have started to annoy me as they
> will others. Perhaps we can remove the use of aspects all together
> since the point cuts are all static. Don't know. Perhaps we can use
> lower level libraries to achieve this effect with better efficiency.
> AspectJ runtime is not the fastest out there.
> 
> 4). Support for LDAP Controls (implementation in server not in ASN.1
> runtime)
> 
> o Persistent search control
> o Sort control
> o Named References/ManageDsaIT
> 
> 5). The core JNDI provider needs some more work.
> 
> The provider lacks full functionality for referrals and other features.
> It would also be nice to be able to get namespace federation working so
> we can bridge the gap between the Naming code and the ApacheDS core
> code. This way we can traverse namespaces and switch providers
> dynamically between namespaces.
> 
> 6). Better transaction management and ACIDity instead of using buffer
> cache like mechanism with synch method calls
> 
> 7). Triggers, views and stored procedures
> 
> Once subentries are in place I would like to have AAA's managing
> information for trigger, view and proc specifications. Nothing like
> this is formalized yet in LDAP so its great material for potentially new
> IETF standards around these constructs. The RDBMS world has em why not
> LDAP?
> 
> 8). Correct Abandon operation handling
> 
> The Abandon request does not work in the server. Low hanging fruit here
> but it needs to be done right since another thread has to be stopped.
> 
> 9). Correct handling of time and size limits
> 
> The search request currently does not time out search requests that
> exceed these limits. Search filters can be used to limit these for each
> entry requested since entries are streamed out of the server one at a
> time as they are requested by the JNDI. Search does not load all
> candidate entries selected by a filter into memory then return them: the
> server would croak if we did that.
> 
> 10). Complete support for most schema checking constructs
> 
> Everything is in place for schema checking but nothing exists today.
> The reason being I did not waste time on schema subsystem since it would
> need to be revamped once we implemented subentries. Subentries for
> schema AAAs would store the schema info there rather than having one
> schema for the entire DIT mastered by a DSA.
> 
> Basically an interceptor for schema management would use the subentry
> information to check for correct schema usage in different schema AAAs
> in the DIT.
> 
> 11). Better error handling and easily understood messages
> 
> 12). Logging
> 
> I personally did a poor job of this To my credit much of the logging
> lines were added and removed while moving from one IoC container to the
> next during the Avalon days.
> 
> 13). Possible IoC Container Strategy
> 
> ApacheDS does not use a container and we have tried to be container
> independent to avoid introducing specificities.
> 
> We want the server to be as embeddable as possible WRT the existing
> containers out there. Hence we do not want say the Geronimo folks to
> have to introduce container specific code if they want to embed
> ApacheDS. Plus we don't want protocol implementors and committers on
> the core to have to worry about learning a new container and its
> semantics. Things are already hard.
> 
> If we can keep the container code separated from the core then perhaps
> we can ship with a default container for the final executable service.
> Why try? We loose a lot not having a default container. What do we loose:
> 
> Aspects like ...
> 
> o management interfaces
> o logging
> o configuration
> o hot deployment of components
> o ...
> 
> Right now Enrique has attracted my attention to OSGi. He makes
> excellent points about it. It's the container of choice for embedding
> in appliances and other devices. Plus it's got a written specification
> to it endorsed by major companies like IBM, Cisco and many others. This
> is what makes it unique in comparison to the Geronimo GBeans, Spring and
> other Avalon, ComponentHaus productions. All these containers are great
> btw so I'm not putting them down and we still reserve the right to
> integrate with them as well. However OSGi seems like the best candidate
> to Enrique and I.
> 
> Enrique,
> 
> Perhaps (in a separate mail thread) you can elaborate a bit on OSGi
> advantages and the wrapper code you have introduced in the sandbox?
> 
> 14). Language Tags
> 
> I'd like to see language tags implemented for LDAP so pulling an
> attribute based on user profile locale can result in the correct value.
> For more info on language tags look here:
> 
> http://www.faqs.org/rfcs/rfc3866.html
> 
> Yum another fresh new LDAP RFC. Kudos to Zeilenga and friends at
> OpenLDAP. So now the core JNDI provider can be used
> *java.naming.language property and search recall attributes based on a
> language.
> 
> http://java.sun.com/j2se/1.3/docs/api/javax/naming/Context.html#LANGUAGE*
> 
> 15). Support for collective attributes
> 
> K. Zeilenga is unstoppable: another great LDAP specification.
> Unfortunately this is also missing in ApacheDS:
> 
> http://www.faqs.org/rfcs/rfc3671.html
> 
> Again we need subentries implemented first to do this correctly.
> 
> 16). SASL/GSSAPI/Kerberos support
> 
> Nice to have some support for this. Insecure LDAP is not LDAP according
> to the security requirements set forth in v3 specifications. Related
> RFCs in LDAP land specifically include:
> 
> o http://www.faqs.org/rfcs/rfc3062.html
> o http://rfc3829.x42.com/
> 
> 17). DNS-based service location
> 
> o http://www.faqs.org/rfcs/rfc3958.html
> 
> Comments thoughts with LDAP relationship?
> 
> LDAP: Summary
> ==========
> 
> The LDAP space is huge and ripe for the pickings. Directories represent
> a cornerstone technology so it is naturally vast and there are even more
> RFCs out there on LDAP. I just hit upon perhaps a third to one half of
> them either directly or indirectly. Step one is not to freak. Step two
> is to start looking for simple areas where you can start working without
> dependencies. As noted several things are dependent on subentry
> implementation but there are other independent efforts that can be
> concurrently developed as well.
> 
> In General: Summary
> =============
> 
> When looking at these lists try to isolate your interest if any and
> interface with us on the list to see how we can put your feet on the
> ground reading the existing code and formalizing an approach. It's all
> about working together as a community to help one another see the best
> possibilities. Meaning your efforts should not be in a vacuum.
> Otherwise you might be choosing implementation pathways leading to a
> dead end or incorrectly presuming things regarding the current operation
> of the server. We can help you out but cannot read your mind: just your
> emails.
> 
> Ask questions! Post to the list and don't feel self conscious. I know
> many people get intimidated posting to these lists. No one will haze
> you for trying to be involved or if you don't have sufficient
> information. We will try to point you to the proper resources if not
> explain things ourselves hopefully adding to those resources.
> 
> Good luck,
> Alex
> 
> 
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/

Mime
View raw message