directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: [SASL] SASL configuration, committed.
Date Wed, 21 Mar 2007 03:54:29 GMT
Too bad re: #4 though, I guess we're just going to have to live with SUN's
ghetto configuration issues.

Alex

On 3/20/07, Enrique Rodriguez <enriquer9@gmail.com> wrote:
>
> On 3/20/07, Alex Karasulu <akarasulu@apache.org> wrote:
> > ...
> > On 3/19/07, Enrique Rodriguez <enriquer9@gmail.com> wrote:
> > > ...
> > > 1)  In getting the configuration sorted out, w.r.t. Spring, for SASL
> > > and Kerberos, I had to make the same changes to all the protocol
> > > providers.  So, all the protocol providers are now enabled for Spring
> > > bean configuration.  I checked in a new server.xml that has beans for
> > > all the protocols, to server-main.  This server.xml is the best place
> > > to look to get an overview of what changed.  Note that DNS could also
> > > be enabled, but since ServerContextFactory never included it, I
> > > haven't added it in.
> >
> > Some comments:
> >
> > (1) You might also want to copy the new server.xml over to the
> > server-installers/
> > src/main/installers/server.xml file so the installers have the correct
> > server.xml
> > instead of the old ones.  server-main is an assembly with a
> > main(String[]args)
> > based bootstrapper for the assembly.  It's not really used all that
> much.
>
> The server.xml I checked-in to server-main was designed to "show off"
> the new protocol provider configs.  For installers we'll likely want
> something more stripped down that just does LDAP, maybe Kerberos.  We
> should review the server-main server.xml to determine what should
> really ship.
>
> > (2) Can we have a couple confluence pages for the 1.5 branch that
> describes
> > these configuration changes in terms of spring?
>
> NP, probably this coming weekend.
>
> > (3) Can we have a SASL how to for the server before we merge this code
> > into the trunk?
>
> NP, mostly already in the Sandbox.  I'll move to the 1.5 doco.
>
> > (4) Should we add the code to enable DNS into the server?  It might give
> > people the ability to start playing with the DNS protocol and that way
> we
> > can
> > attract more users/committers?
>
> Yeah, I was thinking the same thing.  The default for every protocol
> except LDAP is to be disabled.  No harm in at least allowing DNS to be
> enabled.
>
> > > 2)  Since config is all working, I updated and checked in my SASL
> > > GSSAPI integration test.  This test case uses Sun's Kerberos client,
> > > which, unfortunately, doesn't allow you to set the port.  I checked
> > > the test case in anyway for review but since the port is hard-coded
> > > for "88" it will fail for non-root users.  We'll have to comment it
> > > out in the server-unit POM, I guess.
> >
> > That stinks yeah.  Would be nice to have the integration test run every
> time
> > when we want to validate that SASL code is not broken for a release.  Is
> > there absolutely no work around for this?
>
> Only work around is external config, eg for *nix a krb5.conf.  Would
> be OS dependent.
>
> On a side note, Sun used a colon as the delimiter for having multiple
> KDC's when you config in code.  Nice!  As you know, the colon is the
> typical delimiter for the port, hence no port config in code.
>
> On a side-side note, the SASL GSSAPI code demonstrates a lovely
> trifecta of JDK API's:  JAAS KDC's are colon-delimited, SASL QoP
> levels are comma-delimited, and SASL realms are space-delimited!
> Naturally, we will use something consistent in our config ...
>
> > > 3)  I still have code local for Start TLS.  I can commit to
> > > protocol-ldap and enable it in the server once the grant is
> > > acknowledged.
> >
> > I have my fax machine setup now as of yesterday.  I will fax this
> > today and check with Jim.
>
> That would be great.  I got Start TLS working before I was aware of
> Trustin's version, but his version does authentication downgrade.
> This is only 16 lines of code difference and it's not exactly IP and
> nearly identical to how we get contexts elsewhere.  The rest is pretty
> much by the book JDK SSL code and looks nearly identical to mine (open
> cert store, initialize SSL context, etc.).  But, I've looked at the
> Safehaus Start TLS code so I still think a fax is in order.  Plus, the
> test case might be useful.  It's smaller than many patches; maybe you
> could attach it to the Start TLS issue in JIRA and check the grant
> checkbox if you can't get a fax by the weekend.
>
> > > 4)  I have notes on what changed and will put together all new config
> > > doco for the 1.5 guides.
> >
> > Ahhhh ok very cool I did not read this far when making my comments above
> > under your note #1.
>
> I will get the doco up by the end of this weekend.  I'll add the doco
> somewhere intuitive in the 1.5 docs and move what's currently in the
> sandbox.
>
> Enrique
>

Mime
View raw message