[07:23:54 CST(-0600)] <wgthom> what is the Uber WAR in the latest release?
[07:43:19 CST(-0600)] <serac> Good question.
[07:43:47 CST(-0600)] <serac> It came about from a request from an individual at a private defense contractor.
[07:44:34 CST(-0600)] <wgthom> is it just a deployable war with all the extensions available in it? or something else?
[07:44:37 CST(-0600)] <serac> They wanted to support CAS for some defense certification, but it needed to be a particular bundle, and this "Uber WAR" as Scott called it is the result.
[07:44:54 CST(-0600)] <serac> Not all the extensions, but some of the common ones, and in particular the ones this firm wanted.
[07:46:03 CST(-0600)] <wgthom> does it have intrinsic value to the community at large?
[07:46:21 CST(-0600)] <serac> You could argue that it does because the components it contains are common ones.
[07:46:49 CST(-0600)] <wgthom> seems a little out of place in the release...
[07:46:58 CST(-0600)] <serac> Agreed.
[07:47:09 CST(-0600)] <serac> We really do need to look at other deployment methods than Maven WAR Overlay, but this isn't a viable solution.
[07:47:28 CST(-0600)] <wgthom> agree...
[07:47:39 CST(-0600)] <wgthom> there's no sysadmin style deploy
[07:47:47 CST(-0600)] <serac> https://issues.jasig.org/browse/CAS-900
[07:47:49 CST(-0600)] <wgthom> and configu
[07:48:02 CST(-0600)] <serac> Maybe someone at the conference will have Debian packaging experience and will lend a hand.
[07:48:07 CST(-0600)] <serac> I think that's pretty promising.
[07:48:15 CST(-0600)] <wgthom> nice.
[08:14:57 CST(-0600)] <battags> just saw the conversation about Uber WAR
[08:15:04 CST(-0600)] <battags> its actually very useful
[08:15:17 CST(-0600)] <battags> we get people all the time who refuse to use the WAR overlay
[08:15:22 CST(-0600)] <battags> and try to copy dependencies in manually
[08:15:31 CST(-0600)] <battags> if they use this war it includes just about everything and its dependencies
[08:15:39 CST(-0600)] <battags> they just need to change the deployer config files
[08:15:55 CST(-0600)] <wgthom> gotcha...perhaps we need to make a little more noise about it
[08:16:10 CST(-0600)] <serac> I feel a wiki page coming on....
[08:16:17 CST(-0600)] <battags> if only we had a documentation editor 
[08:16:23 CST(-0600)] <wgthom> lol
[08:16:24 CST(-0600)] <serac> ducks
[08:16:42 CST(-0600)] <battags> I can create a "Non-Best Practice" page that describes how to use it
[08:16:52 CST(-0600)] <battags> maybe a "Crappy Practice That Shouldn't Use But you Probably Will So here's how"
[08:17:04 CST(-0600)] <serac> Truth hurts, I guess
[08:17:30 CST(-0600)] <battags> on a positive note, it caused conversation in this chat room
[08:18:25 CST(-0600)] <serac> We need to refactor our deployment documentation anyway, so this seems like good stimulus.
[08:19:04 CST(-0600)] <battags> maybe we should have a community call on deployment practices?
[08:19:13 CST(-0600)] <battags> it could also give us reason/initiative to update the document
[08:19:22 CST(-0600)] <battags> or we could force people at the meetup to improve the document
[08:19:34 CST(-0600)] <wgthom> or both
[08:19:34 CST(-0600)] <battags> and wow my two statements had the same number of letters
[08:19:35 CST(-0600)] <serac> I'd like to make sure any energy we spend on this topic can be applied to https://wiki.jasig.org/display/CASUM/3.+Planning+and+Deployment+Considerations.
[08:19:55 CST(-0600)] <serac> In particular https://wiki.jasig.org/display/CASUM/3.4.+Deployment+Scenarios.
[08:21:00 CST(-0600)] <serac> Sorry to muddy the water, but I'm personally trying to figure out how to keep the new documentation effort alive and growing.
[08:21:06 CST(-0600)] <battags> does configuration maintenance fall under deployment scenarios?
[08:21:15 CST(-0600)] <serac> I certainly think so.
[08:21:39 CST(-0600)] <battags> it just didn't seem to fall under either of those 4
[08:21:42 CST(-0600)] <battags> sub areas
[08:21:52 CST(-0600)] <battags> or were you going to add a new one?
[08:22:04 CST(-0600)] <battags> keeping the new documentation effort alive and growing is important
[08:22:10 CST(-0600)] <battags> I failed at updating documentation before the release
[08:22:22 CST(-0600)] <serac> Pretty forgiveable.
[08:22:42 CST(-0600)] <serac> I agree there's no specific section for configuration management in chapter 3.
[08:22:56 CST(-0600)] <serac> But there's definitely a relationship between your core deployment strategy and configuration maintenance.
[08:23:10 CST(-0600)] <serac> It's the point at which you decide whether maven war overlay is right for you.
[08:23:28 CST(-0600)] <serac> But I was thinking initially it's more about clustering and hardware/network issues.
[08:23:46 CST(-0600)] <serac> So maybe the details don't live there, but it's where you should start thinking about it.
[08:24:24 CST(-0600)] <battags> maybe it just means the section header needs to be massaged a little bit
[08:24:51 CST(-0600)] <battags> you could always (poorly) name it "Your CAS Deployment"
[08:24:57 CST(-0600)] <battags> I wouldn't actually call it that
[08:25:11 CST(-0600)] <battags> but it kind of leads you to believe this is the stuff you should be doing for your deployment
[08:25:52 CST(-0600)] <serac> I'm open to ideas/suggestions.
[08:30:49 CST(-0600)] <battags_> apparently I'm signed in twice
[08:30:53 CST(-0600)] <battags_> sigh network connection
[08:31:11 CST(-0600)] <serac> Now for a limited time, 100% more Scott.
[08:31:43 CST(-0600)] <wgthom> #jasg-cas 2x the Scott
[08:31:56 CST(-0600)] <battags_> as long as none of you say "where in the world is Scott Battaglia"
[08:32:21 CST(-0600)] <wgthom> who is the real Scott Battaglia?
[08:32:23 CST(-0600)] <serac> You've got to admit, it does have that "Carmen San Diego" ring.
[08:37:27 CST(-0600)] <battags_> Marvin, I think you had offered to take lead on the requirements for the new Services Management support
[08:37:40 CST(-0600)] <battags_> I'm thinking we might want that for the next CAS4 milestone
[08:37:43 CST(-0600)] <serac> Yes.
[08:37:55 CST(-0600)] <serac> We started talking about it, then the discussion fizzled.
[08:38:07 CST(-0600)] <battags_> and I say that since the first milestone is approaching completion 
[08:39:30 CST(-0600)] <serac> Other than separating it out as a separate webapp, what are the other core requirements?
[08:42:35 CST(-0600)] <battags_> we need some API for the CAS server itself to get the service meta data
[08:42:48 CST(-0600)] <battags_> in the other CAS4 code I also started to come up with a registration page
[08:42:54 CST(-0600)] <battags_> that could actually produce SAML2 meta data
[08:43:03 CST(-0600)] <serac> About SAML2 metadata....
[08:43:10 CST(-0600)] <serac> I've been thinking about that some.
[08:43:33 CST(-0600)] <battags_> it also generated private and public key pairs
[08:43:36 CST(-0600)] <serac> I would suggest for starters we simplify the configuration and use a single application-wide keypair for signatures.
[08:44:18 CST(-0600)] <serac> In my experience with Shib there is only a single keypair you care about, the one used with InCommon.
[08:45:00 CST(-0600)] <battags_> and I put all that effort into an efficient workflow
[08:45:11 CST(-0600)] <serac> You can of course be a member of multiple federations, but for simplicity in CAS I would imagine that the single federation case will cover 90% of the use cases, maybe more.
[08:45:46 CST(-0600)] <serac> If we go with that, it will dramatically simplify the service setup and we can hopefully get to limited SAML 2 support faster, which I'm warming up to.
[08:46:20 CST(-0600)] <battags_> yeah I want to to
[08:46:22 CST(-0600)] <serac> Like most big specs, 99% of the use cases are in <10% of the features.
[08:46:31 CST(-0600)] <battags_> we have to find a way to effectively manage using OpenSAML2
[08:46:34 CST(-0600)] <serac> Speaking of SAML in particular.
[08:46:43 CST(-0600)] <serac> I think that's doable.
[08:46:46 CST(-0600)] <battags_> if you look at the code for the SAML1.1 support its a mess
[08:46:59 CST(-0600)] <battags_> I haven't tested or really tried to clean it up yet
[08:47:03 CST(-0600)] <serac> I haven't in a while, maybe never. I've looked at some of it.
[08:47:14 CST(-0600)] <serac> Oh, you mean on the CAS side.
[08:47:25 CST(-0600)] <battags_> yeah using the APIs
[08:47:27 CST(-0600)] <battags_> in CAS4
[08:47:31 CST(-0600)] <serac> Definitely.
[08:47:35 CST(-0600)] <serac> Shouldn't be too bad.
[08:47:44 CST(-0600)] <battags_> they use a heck of a lot of builders to get anything done
[08:47:59 CST(-0600)] <battags_> I almost actually went and used JAXB to create bindings that were useable
[08:48:09 CST(-0600)] <serac> heh
[08:48:20 CST(-0600)] <battags_> but I was worried that I would miss something
[08:48:22 CST(-0600)] <serac> We may want to take the core of that idea, though.
[08:48:31 CST(-0600)] <serac> Some utilities that ease the pain.
[08:48:45 CST(-0600)] <battags_> yeah. I want to try implementing a few things to really see the usage pattern
[08:48:49 CST(-0600)] <battags_> before attempting to "fix" it
[08:49:03 CST(-0600)] <serac> Sounds wise.
[08:49:20 CST(-0600)] <serac> Did you see that conversation about saml 1.1b on cas-user?
[08:49:32 CST(-0600)] <serac> May be a good test-the-water case.
[08:56:14 CST(-0600)] <battags_> yes I actually replied to it
[08:56:23 CST(-0600)] <serac> Oh, missed that.
[09:34:49 CST(-0600)] <battags_> I watch the CAS space via email and so now I get a billion emails thanks to this chat room
General
Content
Integrations