Too bad re: #4 though, I guess we're just going to have to live with SUN's
ghetto configuration issues.
On 3/20/07, Alex Karasulu < firstname.lastname@example.org> wrote:
> On 3/19/07, Enrique Rodriguez <email@example.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
> src/main/installers/server.xml file so the installers have the correct
> instead of the old ones. server-main is an assembly with a
> 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
> (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
> 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
> > 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