jasig-cas IRC Logs-2011-04-29

[13:05:23 CDT(-0500)] <serac> Bill, I'm trying to test your NETC patch, but Windows is thwarting me from being productive.
[13:11:23 CDT(-0500)] <wgthom> i hate when that happens
[13:12:11 CDT(-0500)] <serac> Seems to happen more on Windows. But I'm mostly ignorant of best practices these days on Windows, so I guess it's not a fair assessment.
[13:13:23 CDT(-0500)] <forsetti> Hey all - I'm only in for a few minutes. Anything fun and exciting today?
[13:13:32 CDT(-0500)] <wgthom> the only best practice on Windows I know of is install cygwin
[13:13:36 CDT(-0500)] <wgthom> lol
[13:13:41 CDT(-0500)] <serac> heh
[13:13:57 CDT(-0500)] <serac> I thought the VM thread on cas-user was pretty interesting.
[13:14:04 CDT(-0500)] <wgthom> yes, very...
[13:14:23 CDT(-0500)] <serac> Bottom line: folks think CAS is a pain to install, configure, upgrade.
[13:14:31 CDT(-0500)] <wgthom> especially like the pull we're seeing from the instractucture/sysadmin side of the house
[13:14:58 CDT(-0500)] <serac> Yeah, exactly. It's like we've pissed them off with having to learn dev tools.
[13:15:07 CDT(-0500)] <matt_uconn> Agreed. I'm (mostly) in the sysadmin seat, and the commentary has been very good.
[13:15:28 CDT(-0500)] <serac> We want those guys on our side.
[13:15:33 CDT(-0500)] <wgthom> indeed
[13:17:21 CDT(-0500)] <matt_uconn> Some work needs to be done on config/deployment then. There needs to be better separation of the deployable software package and the configuration information (think /usr/bin vs /etc).
[13:17:36 CDT(-0500)] <serac> I'm totally thinking along those lines, Matt.
[13:17:51 CDT(-0500)] <serac> I've done enough work thus far to know it's possible if not ideal.
[13:18:18 CDT(-0500)] <wgthom> yes, instead of build to suit your needs it needs to configure to suit your needs
[13:18:36 CDT(-0500)] <matt_uconn> Also, as CAS finds increased adoption by COTS ( or even F(L)OSS ), developers may not be the target audience. Sysadmins may be deploying on their own, with no developer support , and no Spring/Java/Maven knowledge
[13:18:36 CDT(-0500)] <wgthom> all the handlers, clearpass, etc should just be there already
[13:18:37 CDT(-0500)] <serac> That's what the sysadmins want afaict.
[13:19:02 CDT(-0500)] <serac> I'm pretty sure we can continue to modularize, Bill.
[13:19:02 CDT(-0500)] <wgthom> yep
[13:19:41 CDT(-0500)] <serac> I'm thinking sudo apt-get install cas-server-core cas-server-ldap cas-server-jpa.
[13:19:54 CDT(-0500)] <serac> You then configure files somewhere under /etc and start her up.
[13:20:06 CDT(-0500)] <matt_uconn> If all the handlers, etc, are already in the package, runtime (re)configuration would be huge. Having to recycle the app to read the config feels very ... legacy.
[13:20:41 CDT(-0500)] <serac> You want it to pick up config changes without a restart?
[13:20:50 CDT(-0500)] <serac> HUPing is still pretty common.
[13:20:53 CDT(-0500)] <matt_uconn> I want it all
[13:20:58 CDT(-0500)] <serac> Hah.
[13:21:01 CDT(-0500)] <matt_uconn> I'm thinking one of two things ...
[13:21:04 CDT(-0500)] <serac> We can do it.
[13:21:13 CDT(-0500)] <matt_uconn> either, there is a button in the interface so I can reload the config ...
[13:21:25 CDT(-0500)] <serac> Interesting.
[13:21:32 CDT(-0500)] <matt_uconn> or, I use an interactive UI to implement the config, such that CAS is aware on-the-fly
[13:21:34 CDT(-0500)] <serac> We've now got JMX hooks to do stuff like that.
[13:21:56 CDT(-0500)] <serac> I'm leery of too much GUI (gooey?) goodness.
[13:22:16 CDT(-0500)] <serac> It's hard to do well and is a maintenance pain. I hate UI work, so I guess I'm biased.
[13:22:26 CDT(-0500)] <battags> serac: sys administrators think CAS is a pain to intsall
[13:22:28 CDT(-0500)] <battags> install*
[13:22:29 CDT(-0500)] <serac> But basic controls to reload components, refresh config is totally doable.
[13:22:31 CDT(-0500)] <battags> we should clarify that
[13:22:47 CDT(-0500)] <serac> It's pretty clear that they think it's a pain to upgrade as well.
[13:23:00 CDT(-0500)] <serac> Shoot, it's a pain for me to upgrade.
[13:23:01 CDT(-0500)] <battags> sorry not disagreeing with that
[13:23:13 CDT(-0500)] <battags> my point was we chose a method that is easier for Java developers
[13:23:19 CDT(-0500)] <matt_uconn> Yeah, I'm not a GUI guy (I'm a vi guy) either .... but as I watch this shift from developer-originated deployment to sysadmin-originated deployment, hiding some of the detail (edit XML files? Ugh!) needs to be hidden.
[13:23:31 CDT(-0500)] <matt_uconn> (wow - you guys type waay faster than me)
[13:23:45 CDT(-0500)] <serac> Sure, and it's a good one for folks that are going to extend the product with their own components. But lots of folks don't or can't do it.
[13:24:07 CDT(-0500)] <battags> I have to say though part of it comes down to stubborness also
[13:24:19 CDT(-0500)] <battags> there are a number of people who just refuse to listen when we say its easier if you do it this way
[13:24:34 CDT(-0500)] <serac> Matt – we're on a good path with CAS4 – lots of stuff is just autowired. Less XML – hooray.
[13:24:53 CDT(-0500)] <serac> battags – yeah, lots of stubborn folks.
[13:24:54 CDT(-0500)] <battags> CAS4 also has better modules so loading Hibernate is easier
[13:25:06 CDT(-0500)] <battags> we should just release CAS4 without SAML2 to get it out
[13:25:22 CDT(-0500)] <serac> But in fairness, they're stubborn because Maven and Java are like Greek. Or maybe Sanscrit even.
[13:25:43 CDT(-0500)] <battags> I'm talking about Java developers being stubbotn
[13:25:48 CDT(-0500)] <battags> I can get behind the sys admins
[13:26:04 CDT(-0500)] <serac> Totally agree in that case.
[13:26:36 CDT(-0500)] <battags> luckily it looks like a bunch of the sys admins types are willing to help you
[13:26:54 CDT(-0500)] <battags> I think that's a better path than the VMs
[13:27:18 CDT(-0500)] <serac> I think the VM idea is neat, but it's clear few folks trust them.
[13:27:38 CDT(-0500)] <battags> I don't see how they really help
[13:27:49 CDT(-0500)] <serac> They can wrap up a complete system much better.
[13:28:02 CDT(-0500)] <serac> But for an individual component, e.g. server, no real value.
[13:28:13 CDT(-0500)] <serac> If you want to see how clustering works, end-to-end, VM is pretty powerful.
[13:28:14 CDT(-0500)] <battags> right but a complete system of essentially OS, Container, and CAS?
[13:28:25 CDT(-0500)] <matt_uconn> As a sysadmin, appliances are great, except when they are not. They are rapid deploy, no-config solutions, but keeping an entire system patched and updated as a single atomic unit ... can be painful for the VM maintainer, and so frequency of release is generally low.
[13:28:28 CDT(-0500)] <serac> System in this case is groups of machines.
[13:28:40 CDT(-0500)] <battags> ah
[13:28:51 CDT(-0500)] <serac> It'd be a pain to maintain on our side as well w/r/t updates and maint.
[13:28:59 CDT(-0500)] <battags> my thought though is that you want to build the VM specific to your needs
[13:29:14 CDT(-0500)] <serac> Yeah, and that's where I stopped.
[13:29:17 CDT(-0500)] <battags> us putting up a VM that you then have to go edit to point to your LDAP server?
[13:29:20 CDT(-0500)] <serac> I couldn't figure out how to componentize it.
[13:29:45 CDT(-0500)] <matt_uconn> I htink jumping to a VM Appliance is too far. 1st step is to get the CAS server packaged for Linux distros (.deb and .rpm at least). Then, those packages can be used as a stepping stone to VM appliance.
[13:29:57 CDT(-0500)] <battags> if only CAS didn't need to talk to anything else
[13:29:59 CDT(-0500)] <serac> Good point.
[13:30:13 CDT(-0500)] <serac> Packages first, VM second, if ever.
[13:30:34 CDT(-0500)] <matt_uconn> ok, now that I've poured enough gasoline on the fire, I've gotta run (meetings, damned meeting). See you all on the ML.
[13:30:48 CDT(-0500)] <serac> But having one or more "demo" VMs to see how the components fit together would be powerful.
[13:37:40 CDT(-0500)] <serac> Bill, your patch works for my test case. Want me to commit it?
[13:41:31 CDT(-0500)] <wgthom> that's fine...any thoughts on getting a point release cut?
[13:42:11 CDT(-0500)] <serac> I'm fine with doing now.
[13:42:19 CDT(-0500)] <serac> You can cut or delegate to Scott H.
[13:42:21 CDT(-0500)] <wgthom> me too.
[13:42:24 CDT(-0500)] <wgthom> k
[13:42:30 CDT(-0500)] <wgthom> prolly next week sometime
[13:42:48 CDT(-0500)] <wgthom> need to get him on this chat
[13:43:50 CDT(-0500)] <serac> Yeah, you should invite him.
[13:44:34 CDT(-0500)] <serac> Committed your patch.
[13:45:14 CDT(-0500)] <wgthom> cool. pinged scott...
[13:47:28 CDT(-0500)] <wgthom> you have to add it as a connection
[13:47:35 CDT(-0500)] <wgthom> under Identity & Connections
[13:47:44 CDT(-0500)] <sholodak> I think it worked?
[13:47:57 CDT(-0500)] <serac> Hey sholodak.
[13:47:58 CDT(-0500)] <wgthom> irc.freenode.net
[13:48:03 CDT(-0500)] <sholodak> hi
[13:48:18 CDT(-0500)] <wgthom> nice. welcome aborad
[13:49:06 CDT(-0500)] <sholodak> I'll take a quick look at the patch... hang on a min
[13:49:54 CDT(-0500)] <serac> I was trying to foist the work of cutting a point release onto you, Scott.
[13:50:18 CDT(-0500)] <sholodak> lol.
[13:50:31 CDT(-0500)] <serac> I figured you could do it in half the time, more if you include the NuGet packages.
[13:50:58 CDT(-0500)] <sholodak> yeah.. that makes sense.
[13:51:48 CDT(-0500)] <sholodak> so quick question.. in UriUtil.cs, it looks like you're overriding the CasAuthentication.ServerName
[13:52:23 CDT(-0500)] <wgthom> yes,
[13:52:46 CDT(-0500)]

[13:53:23 CDT(-0500)] <sholodak> ... was added pre-1.0 to prevent the client from adding :80 to http:// requests and :443 to https:// requests... it was annoying for people who whitelisted the services that could use CAS
[13:54:54 CDT(-0500)] <serac> I guess we could still include that logic, but the main thing is being able to explicitly override the hostname for clustered setups if it's specified in the config. Or at least that's my understanding of the problem.
[13:56:30 CDT(-0500)] <wgthom> i was seeing that behavior with the patch and a servername speciied in the config
[13:56:44 CDT(-0500)] <wgthom> perhaps it happens then ServerName is not specfied?
[13:56:55 CDT(-0500)] <wgthom> i was not seeing...
[13:57:22 CDT(-0500)] <wgthom> when the ServerName was specified. i was using https://hostname/app
[13:57:28 CDT(-0500)] <wgthom> and didn't not get 443 on the url
[13:57:32 CDT(-0500)] <wgthom> on the generated url
[13:58:01 CDT(-0500)] <sholodak> I'm reading lines 294-310 of UriUtil.cs .... I think that the patch is equivalent to:
[13:58:15 CDT(-0500)] <sholodak> oh nevermind..
[13:58:27 CDT(-0500)] <serac> My test environment requires an explicit host and port, so I can't help test the behavior without host/port in config.
[13:58:38 CDT(-0500)] <sholodak> I was getting uriServerName and ub confused
[13:59:32 CDT(-0500)] <wgthom> well like I said...it worked for me
[13:59:36 CDT(-0500)] <sholodak> ok.. so the only thing we'd want to test is that it doesn't unnecessarily append :80 and :443
[13:59:42 CDT(-0500)] <wgthom> yes
[13:59:42 CDT(-0500)] <sholodak> but otherwise, it looks fine.
[14:00:12 CDT(-0500)] <serac> I think it's desirable but not necessary to omit default ports in redirect URL.
[14:00:55 CDT(-0500)] <sholodak> yeah, I agree... it would cause issues when people upgrade if their CAS server is set to require services to be whitelisted.
[14:03:37 CDT(-0500)]

<sholodak> if (!((uriServerName.Scheme == "http" && uriServerName.Port == 80) || (uriServerName.Scheme == "https" && uriServerName.Port == 443))

Unknown macro: { ub.Port = uriServerName.Port; }

[14:03:57 CDT(-0500)] <sholodak> in place of line 308 maybe?
[14:04:02 CDT(-0500)] <wgthom> i don't think it is needed
[14:04:08 CDT(-0500)] <sholodak> ok...
[14:05:13 CDT(-0500)] <wgthom> the behavior I saw with the patch is the dersireable one. no default port # if they were not specified.
[14:05:25 CDT(-0500)] <wgthom> it would be nice to have independent verification though....
[14:05:52 CDT(-0500)] <serac> agreed
[14:07:26 CDT(-0500)] <sholodak> ok.. you want me to cut a 1.1 release?
[14:08:30 CDT(-0500)] <wgthom> that would be fine... is there anything else we might want ina 1,1?
[14:09:14 CDT(-0500)] <sholodak> we're not going to be doing a ton of 1.x releases, so it wouldn't hurt to have a 1.2 or 1.3 down the road
[14:09:25 CDT(-0500)] <sholodak> the 2.x will be the WIF stuff, if necessary I think
[14:10:20 CDT(-0500)] <wgthom> agreed...I wasn't hung up on the numbering...just wondering if there is anything else that is close or easy that could go into 1.1
[14:13:44 CDT(-0500)] <serac> I'm not aware of anything.