jasig-cas IRC Logs-2011-09-23

[07:31:33 CDT(-0500)] <ries> Good morning, I have a other related question to CAS. Is it up to CAS to allow/dely access to specific applications, even though the user is logged in. or is ut up to the application to say 'I know Scott, but you cannot access me'.
[07:31:48 CDT(-0500)] <ries> I am trying the understand the wiki here : https://wiki.jasig.org/display/CAS/Home
[07:31:59 CDT(-0500)] <ries> but it doesn't mention that
[07:32:47 CDT(-0500)] <wgthom> authZ is up to the app
[07:34:47 CDT(-0500)] <ries> wgthom: ok thanks…
[09:02:11 CDT(-0500)] <kickehy> I'm having trouble getting ssl to work with tomcat (using guide http://tinyurl.com/3v94ayy ) The only thing that i'm confused about in the server.xml file is the keystoreFile part...i imported my cert into cacerts and copied that file over to the conf tomcat folder (as the example did), but when I stop/start tomcat, I absolutely can't get to https://server:8443 Now, if I go to http://server:8080 it works, I must be missing something
[09:02:44 CDT(-0500)] <kickehy> I don't even get a response back from my cas server
[09:03:35 CDT(-0500)] <wgthom> make sure you have the ssl connecter in server.xml uncommented
[09:03:38 CDT(-0500)] <kickehy> and i changed the keystore to "conf/cacerts"
[09:03:51 CDT(-0500)] <kickehy> i'll double check here...
[09:04:27 CDT(-0500)] <kickehy> all good
[09:04:35 CDT(-0500)] <serac> The output of $TOMCAT_HOME/logs/localhost.log will have details.
[09:05:42 CDT(-0500)] <serac> I need to add a note to that page that discusses filesystem permissions for the keystore file.
[09:05:52 CDT(-0500)] <serac> It contains a private key, so security matters.
[09:06:10 CDT(-0500)] <serac> That's fundamentally different from the system key/truststore that contains exclusively certs by default.
[09:09:21 CDT(-0500)] <kickehy> localhost logs are empty :/
[09:09:49 CDT(-0500)] <serac> catalina.out?
[09:10:27 CDT(-0500)] <kickehy> hey there we go
[09:11:06 CDT(-0500)] <serac> (smile)
[09:11:17 CDT(-0500)] <kickehy> w00t must of made my cert wrong then
[09:11:42 CDT(-0500)] <serac> What OS are you running?
[09:11:55 CDT(-0500)] <kickehy> Windows server 2008 r2
[09:12:20 CDT(-0500)] <serac> Wanna be a guinea pig?
[09:12:25 CDT(-0500)] <kickehy> haha sure
[09:12:50 CDT(-0500)] <serac> Generate a pfx file containing your cert/key pair.
[09:13:44 CDT(-0500)] <serac> PFX is mostly the same as a PKCS#12 container.
[09:14:01 CDT(-0500)] <kickehy> from the ca or local computer?
[09:14:23 CDT(-0500)] <serac> I assumed you used the certificate console to generate the cert. Is that correct?
[09:15:02 CDT(-0500)] <kickehy> yes, but this is where certs start to get over my head....i wasn't completely sure what type of template to request the cert as
[09:15:05 CDT(-0500)] <kickehy> so
[09:15:24 CDT(-0500)] <kickehy> i wasn't able to select the "mark as exportable" for the private key
[09:15:42 CDT(-0500)] <kickehy> or is that not what you're talking about?
[09:16:14 CDT(-0500)] <serac> How'd you get the key out for your JKS keystore file, then?
[09:16:37 CDT(-0500)] <serac> You must have the private key in your keystore.
[09:16:51 CDT(-0500)] <serac> (would explain failure if not)
[09:17:39 CDT(-0500)] <kickehy> well rather than using the example's ca (portecle) i used our server 2008 CA
[09:17:45 CDT(-0500)] <kickehy> to make it "official"
[09:18:16 CDT(-0500)] <kickehy> just an fyi, a lot of this is very new to me (tongue)
[09:18:23 CDT(-0500)] <serac> Sure, it's tough.
[09:18:38 CDT(-0500)] <kickehy> so i'm not sure how the .jks file works in all this
[09:18:44 CDT(-0500)] <kickehy> i assume i don't have one
[09:19:05 CDT(-0500)] <kickehy> as i imported the cert into the cacerts keystore, i assumed i would use that instead of the .jks file
[09:19:08 CDT(-0500)] <serac> conf/ssoServer.jks
[09:19:18 CDT(-0500)] <serac> ssoServer.jks = cacerts
[09:19:22 CDT(-0500)] <kickehy> ok
[09:19:41 CDT(-0500)] <serac> If you just imported the cert, you have only half of what's needed to configure an SSL server.
[09:20:04 CDT(-0500)] <serac> A server needs to possess the private key in order to encrypt an assertion that's sent to the client side that is decrypted with the public key.
[09:20:11 CDT(-0500)] <serac> Sans private key, SSL will never work.
[09:20:20 CDT(-0500)] <serac> So you must generate a key that's exportable.
[09:20:27 CDT(-0500)] <kickehy> ok
[09:20:29 CDT(-0500)] <serac> I use OpenSSL for this generally.
[09:20:39 CDT(-0500)] <serac> You should use whatever you're comfortable with.
[09:21:06 CDT(-0500)] <kickehy> have any experience setting up a CA on Windows?
[09:21:10 CDT(-0500)] <serac> Certificate MMC snap-in is a good choice, but I'm honestly only vaguely familiar with it. Mostly just guessing what to do.
[09:21:16 CDT(-0500)] <kickehy> heh
[09:21:30 CDT(-0500)] <serac> I use it for development/testing on Windows.
[09:21:36 CDT(-0500)] <serac> But no production experience.
[09:21:46 CDT(-0500)] <kickehy> my problem is that all my templates don't show up for my CA when i request a cert from the web interface
[09:22:17 CDT(-0500)] <serac> Yeah, can't help you there.
[09:22:22 CDT(-0500)] <kickehy> heh
[09:22:27 CDT(-0500)] <serac> All I can say is that you need to be able to export the private key.
[09:22:39 CDT(-0500)] <serac> PFX is the appropriate format on Windows.
[09:22:45 CDT(-0500)] <serac> From there should be easy.
[09:22:52 CDT(-0500)] <kickehy> mmmk I'll see if i can get that working first and i'll get back to ya
[09:23:01 CDT(-0500)] <serac> Sounds good.
[09:23:06 CDT(-0500)] <kickehy> thanks (smile)
[09:26:35 CDT(-0500)] <kickehy> one other thought, do i need to import the ca's cert into the store?
[09:27:23 CDT(-0500)] <serac> Yes. The exported PFX file should contain the complete certificate chain.
[09:27:33 CDT(-0500)] <kickehy> ok
[09:27:51 CDT(-0500)] <serac> While many browsers will blithely work without the full validation path, it's best practice.
[10:06:51 CDT(-0500)] <ries> Gents, if I go to : http://192.168.1.194:37210/cas/logout then I see Logout successful, should all my other apps be logged out?
[10:07:09 CDT(-0500)] <wgthom> it depends.
[10:07:23 CDT(-0500)] <wgthom> generally, no
[10:08:32 CDT(-0500)] <wgthom> unless you've configured all of your applications to deal with the SLO callback. and even then it's a crap shoot
[10:08:40 CDT(-0500)] <ries> ic...
[10:09:08 CDT(-0500)] <ries> I just quit my browsers, and one application showed the login, and the other app showed up again
[10:09:22 CDT(-0500)] <serac> Do you have session restore enabled? Firefox perhaps?
[10:09:46 CDT(-0500)] <ries> serac: Safari, I even have no idea how to turn it off (big grin)
[10:09:47 CDT(-0500)] <serac> Additionally, I'd recommend you treat "crap shoot" as hyperbole.
[10:11:08 CDT(-0500)] <serac> You should investigate the session storage behavior of Safari. I can't say for certain with Safari, but it's a known issue with FF for a particular configuration.
[10:11:25 CDT(-0500)] <ries> I wonder how you can logout somebody reliable...
[10:11:34 CDT(-0500)] <wgthom> logout of what?
[10:11:39 CDT(-0500)] <serac> It's a fundamentally hard problem.
[10:11:54 CDT(-0500)] <serac> To log out of everything accessed in an SSO session.
[10:11:54 CDT(-0500)] <ries> wgthom: logout, so that I get the login screen again
[10:12:16 CDT(-0500)] <ries> serac: I can imagine you need to go through each application and do some for of redirect...
[10:12:17 CDT(-0500)] <wgthom> logout of the application session? logout of cas sso session?
[10:13:09 CDT(-0500)] <serac> Some CAS clients have support for single sign out, but there are issues and limitations as wgthom implied.
[10:13:11 CDT(-0500)] <ries> application session 'I think'...
[10:13:15 CDT(-0500)] <wgthom> s/hard problem/crap shoot/
[10:13:27 CDT(-0500)] <ries> I can imagine it's a problem...
[10:13:46 CDT(-0500)] <ries> I am trying to setup a demo where my 'boss' can test it.. I am sure he wants to see a logout function somehow
[10:14:56 CDT(-0500)] <serac> You'll need to configure the clients single sign-out capability.
[10:15:01 CDT(-0500)] <serac> Java, php, .NET, what?
[10:15:17 CDT(-0500)] <ries> Java
[10:15:17 CDT(-0500)] <ries> +
[10:15:25 CDT(-0500)] <ries> only JSP pages for testing
[10:15:36 CDT(-0500)] <wgthom> re logout you'll have to thinking about what you want the behavior to be between app logout and sso "logout"
[10:15:39 CDT(-0500)] <serac> Have you read https://wiki.jasig.org/display/CASUM/Single+Sign+Out?
[10:16:02 CDT(-0500)] <serac> Here's the setup for Java client, https://wiki.jasig.org/display/CASC/Configuring+Single+Sign+Out.
[10:16:23 CDT(-0500)] <ries> thanks for the links
[10:16:27 CDT(-0500)] <wgthom> one perspective if CAS a psuedo application session manager. that's SLO
[10:16:28 CDT(-0500)] <serac> np
[10:17:01 CDT(-0500)] <wgthom> another is CAS as enterprise WebSSO where the app sessions are more independent of CAS
[10:18:05 CDT(-0500)] <ries> baby steps…. baby steps…. (smile)
[10:32:26 CDT(-0500)] <ries> is it required to use the fqdn? I currently only have IP addresses for these servers..
[10:37:26 CDT(-0500)] <wgthom> yes for ssl to work.
[10:39:23 CDT(-0500)] <wgthom> you could try putting entries in /etc/hosts or where that file is on windows
[10:50:24 CDT(-0500)] <ries> wgthom: I am currently testing without SSL… that shouldn't matter, right?
[10:54:05 CDT(-0500)] <wgthom> SSL is required for CAS. i woudn't test without it
[10:54:12 CDT(-0500)] <serac> +1
[10:55:07 CDT(-0500)] <ries> wgthom: for production we will use it… but so far I don't see CAS complaining without SSL
[10:55:53 CDT(-0500)] <serac> SSO will not work without SSL. (by default anyway)
[10:56:02 CDT(-0500)] <ries> ic ic...
[10:56:44 CDT(-0500)] <ries> Since I didn't see anything in the log file I thought I should have been fine
[12:57:03 CDT(-0500)] <apetro> ries, what version of CAS? Latest should have nagged you on login screen that SSO would not work w/o SSL
[13:00:40 CDT(-0500)] <apetro> Checking in.
[13:00:46 CDT(-0500)] <serac> My clock reads 1400. It's dev chat time.
[13:01:04 CDT(-0500)] <wgthom> hola amigos
[13:01:45 CDT(-0500)] <serac> ¡Hola!
[13:01:54 CDT(-0500)] <apetro> Agenda bash?
[13:02:03 CDT(-0500)] <serac> I have nothing.
[13:02:11 CDT(-0500)] <serac> Maybe some questions on status.
[13:02:21 CDT(-0500)] <ries> apetro: I am using 3.4.2
[13:02:33 CDT(-0500)] <serac> e.g. 3.4.11 release timeframe
[13:02:38 CDT(-0500)] <serac> Markdown progress
[13:02:48 CDT(-0500)] <serac> unconference
[13:04:13 CDT(-0500)] <apetro> Ok. 3.4.11 release planning, CAS manual, UnConference. What else?
[13:05:09 CDT(-0500)] <apetro> Roadmap and 3.5 strike that 4.0 development and release planning?
[13:06:09 CDT(-0500)] <serac> Sure.
[13:06:12 CDT(-0500)] <apetro> Sounds like an agenda, at least enough to get started on.
[13:06:31 CDT(-0500)] <serac> On 3.4.11...
[13:06:46 CDT(-0500)] <apetro> I see Scott addressed the default Order for the match-all default services.
[13:06:47 CDT(-0500)] <serac> I think we've presently got enough for a point release.
[13:07:01 CDT(-0500)] <serac> He hit a ton of Jira issues this weekend.
[13:07:38 CDT(-0500)] <serac> I merge in the non-printing character fix yesterday.
[13:07:51 CDT(-0500)] <apetro> I think this is the relevant JIRA report: https://issues.jasig.org/secure/IssueNavigator.jspa?reset=true&amp;jqlQuery=project+%3D+CAS+AND+fixVersion+%3D+%223.4.11%22+AND+status+%3D+Resolved+ORDER+BY+priority+DESC&amp;mode=hide
[13:08:14 CDT(-0500)] <wgthom>
[13:08:50 CDT(-0500)] <wgthom> should changing the default behavior of match-all trigger a 3.5?
[13:09:16 CDT(-0500)] <apetro> wgthom, I wouldn't think so. It's not a behavior change, it's a default data set change.
[13:09:18 CDT(-0500)] <serac> I don't think so.
[13:09:47 CDT(-0500)] <wgthom> a default data set change…that changes default behavior?
[13:09:59 CDT(-0500)] <apetro> Should make it slightly less annoying to folks trying out the in-memory services registry, or naively seeding their JPA registry going with the data they saw in the default configu, which is an understandable thing to do.
[13:10:17 CDT(-0500)] <serac> I think it's a good change.
[13:10:37 CDT(-0500)] <apetro> wgthom, that's my understanding of the change that was requested in JIRA, but I haven't reviewed the actual commit so I'm not sure how the issue was addressed
[13:10:37 CDT(-0500)] <serac> The intention is that these are catch-all entries that should naturally be at the end.
[13:10:43 CDT(-0500)] <apetro> in seconds I will know, though – looking for the commit
[13:10:54 CDT(-0500)] <serac> I reviewed the commit – looks good.
[13:11:07 CDT(-0500)] <serac> Just set order=<very high number> on default entries.
[13:11:32 CDT(-0500)] <apetro> precisely. Currently, a deployer trying out CAS has like a 50-50 chance that an entry they add to the default registry will do anything, because they're not going to immediately have a robust strategy for using Order field.
[13:11:46 CDT(-0500)] <serac> We've been doing this for ages here @ VT.
[13:11:50 CDT(-0500)] <apetro> and with this fix, if they don't try very hard, they'll get the effect they were looking for when they add a new entry.
[13:12:17 CDT(-0500)] <serac> I think it's a non-issue.
[13:12:20 CDT(-0500)] <apetro> yup. I still like the idea of making Order unnecessary through more sophisticated matching strategy, but this is fine to make the default less annoying.
[13:12:21 CDT(-0500)] <wgthom> how will if effect someone with 3.4.10 who does a mvn clean deploy?
[13:12:24 CDT(-0500)] <serac> w/r/t change in behavior
[13:12:46 CDT(-0500)] <apetro> it won't affect any existing deployers, since 100% of existing deployers will have their own deployerConfigContext.xml (smile)
[13:12:50 CDT(-0500)] <serac> I'd imagine it would have no effect in most cases.
[13:12:58 CDT(-0500)] <wgthom> ok
[13:13:01 CDT(-0500)] <serac> Right, they don't use the defaults anyway.
[13:13:14 CDT(-0500)] <apetro> and the changed default data by itself has exactly the same behavior as before
[13:13:26 CDT(-0500)] <wgthom> got it
[13:13:30 CDT(-0500)] <apetro> it's just better set up to accomodate a deployer adding an additional service registration.
[13:13:39 CDT(-0500)] <apetro> yup. Very minor polish.
[13:13:56 CDT(-0500)] <apetro> this one, for anyone reviewing the log : https://issues.jasig.org/browse/CAS-1007
[13:13:58 CDT(-0500)] <apetro> let's move on
[13:14:12 CDT(-0500)] <apetro> so 3.4.11 release. Doing the RC first this time?
[13:14:34 CDT(-0500)] <serac> We should just get in the habit.
[13:14:57 CDT(-0500)] <apetro> k, 3.4.11 RC and then GA when everyone loves it.
[13:14:58 CDT(-0500)] <wgthom> big +1 for RC
[13:15:07 CDT(-0500)] <apetro> nice to get a release out that addresses that non-printing-characters-thingy
[13:15:14 CDT(-0500)] <serac> Indeed.
[13:15:31 CDT(-0500)] <serac> Want to demonstrate prompt response.
[13:15:54 CDT(-0500)] <apetro> Cool.
[13:16:05 CDT(-0500)] <apetro> Who's doing what work to cut this 3.4.11 RC on what timeline? (smile)
[13:16:05 CDT(-0500)] <serac> battags – you following?
[13:16:35 CDT(-0500)] <serac> We need to clarify whether anything special is needed for the PGP key used to sign maven artifacts in Maven central.
[13:16:53 CDT(-0500)] <serac> I don't think so, but wanted battags to confirm.
[13:17:02 CDT(-0500)] <serac> If there's no special requirement, anyone can do the release.
[13:17:34 CDT(-0500)] <serac> I'd really like some "formal" discussion on any committer doing release.
[13:18:02 CDT(-0500)] <serac> If nothing else it's a departure from our practice of past several years with lead dev doing them (aka battags).
[13:18:40 CDT(-0500)] <serac> Seems like the "right thing" to at least make a proposal for this change and then vote. I'd meant to do this in the past weeks, but we know about good intentions.
[13:19:37 CDT(-0500)] <apetro> eh. I don't think it's a formal departure. Any committer should be able to propose doing and, with the support of the committers, execute on, doing a release.
[13:19:42 CDT(-0500)] <serac> The proposal will be tit for tat: add release voting and allow any active committer to release. The release voting is a check/balance on releasing.
[13:19:54 CDT(-0500)] <serac> Andrew: it's a departure from what we've been doing.
[13:19:57 CDT(-0500)] <serac> it's a simple fact
[13:20:16 CDT(-0500)] <serac> I'm just saying we should all agree on this change. It's no big deal.
[13:20:26 CDT(-0500)] <apetro> sure. but not a departure from what we should have been doing. (smile) Discuss away, vote away, but I don't think it's an issue. Agreed it's no big deal.
[13:20:26 CDT(-0500)] <serac> Just a change in process.
[13:21:19 CDT(-0500)] <apetro> so, pending formal discussion of any committer doing this release, serac, you cutting this RC?
[13:21:21 CDT(-0500)] <serac> I'll send that out this weekend, then hopefully we can cut the RC next week.
[13:21:24 CDT(-0500)] <wgthom> so we are talking abotu procedural issues
[13:21:26 CDT(-0500)] <wgthom> http://www.apache.org/foundation/voting.html
[13:21:38 CDT(-0500)] <serac> We all know how voting works.
[13:22:05 CDT(-0500)] <wgthom> is there anyone against sharing the release cutting load?
[13:22:26 CDT(-0500)] <serac> I don't believe so, but process decisions are made on cas-dev.
[13:24:05 CDT(-0500)] <wgthom> just pointing out if there's no objections then a vote isn't really needed
[13:24:14 CDT(-0500)] <serac> None of us speaks for another.
[13:24:17 CDT(-0500)] <serac> Scott's not here.
[13:24:50 CDT(-0500)] <serac> The dev list is a good way to allow opinions and input from folks that aren't here now, including but not limited to Scott.
[13:24:57 CDT(-0500)] <wgthom> sure
[13:24:59 CDT(-0500)] <wgthom> of course
[13:25:00 CDT(-0500)] <serac> This is a fairly new channel, after all.
[13:25:16 CDT(-0500)] <wgthom> wasn't looking for a roll call…
[13:25:17 CDT(-0500)] <serac> Anyway, let's move on.
[13:25:23 CDT(-0500)] <apetro> sounds like a fine thing to discuss on cas-dev, maybe more with the discussing and less with the voting.
[13:25:25 CDT(-0500)] <serac> RC next week regardless.
[13:25:45 CDT(-0500)] <apetro> alright. 3.4.11 RC next week, ideally with serac doing it thereby demonstrating that multiple committers can do releases.
[13:25:56 CDT(-0500)] <serac> Sounds good.
[13:26:01 CDT(-0500)] <apetro> Markdown progress?
[13:26:07 CDT(-0500)] <serac> Yeah, how's it going?
[13:26:21 CDT(-0500)] <wgthom> don't we need Scott to vote on the release? lol
[13:26:22 CDT(-0500)] <apetro> it's here https://github.com/apetro/CAS-Documentation
[13:27:00 CDT(-0500)] <apetro> no one's forked and pull requested yet, which in most ways is too bad because it would demonstrate folks trying out the markdown format and determining if it would meet documentation formatting needs.
[13:27:23 CDT(-0500)] <serac> I'll try to at least review it next week if not fork.
[13:27:33 CDT(-0500)] <apetro> I haven't had time to circle back and merge in CAS SAML protocol support documentation, something I'd like to do since I had to dig into that stuff recently for a support case
[13:27:47 CDT(-0500)] <apetro> I still think it has more going for it than does DocBook, on balance
[13:27:59 CDT(-0500)] <serac> Do you have a reasonable solution for pdf?
[13:28:12 CDT(-0500)] <apetro> nope. I have an unreasonable solution for PDF generation.
[13:28:17 CDT(-0500)] <serac> haha
[13:28:22 CDT(-0500)] <serac> What about build integration?
[13:28:33 CDT(-0500)] <serac> i.e. generate docs as part of build
[13:28:39 CDT(-0500)] <apetro> it generates a PDF for me, example here: http://cloud.github.com/downloads/apetro/CAS-Documentation/casmanual.en.pdf
[13:29:10 CDT(-0500)] <apetro> no build integration. For one thing, the build is unreasonable, so it's not going to work in the generic Maven builder case anyway
[13:29:18 CDT(-0500)] <apetro> but even if it did, there's no Maven integration to fire it off
[13:29:46 CDT(-0500)] <serac> How do you do styling, graphics, etc?
[13:29:56 CDT(-0500)] <serac> The pdf is very, how do you say, white?
[13:29:56 CDT(-0500)] <apetro> laid out some of these considerations in that thread on cas-dev
[13:30:03 CDT(-0500)] <apetro> whitespace is good for the soul
[13:30:15 CDT(-0500)] <serac> In reasonable measure, sure.
[13:30:21 CDT(-0500)] <apetro> it's a very minimal syntax.
[13:30:23 CDT(-0500)] <serac> But I'm going snowblind here (wink)
[13:30:39 CDT(-0500)] <serac> Ok, I see graphics now.
[13:30:59 CDT(-0500)] <apetro> Yes, you can do insertion of images, as demonstrated in PDF. They go here: https://github.com/apetro/CAS-Documentation/tree/master/media and are referenced via a

!image!

or so syntax in Markdown
[13:31:14 CDT(-0500)] <apetro> you can embed HTML, so in principle you can do lots of things, but in practice that would get painful fast.
[13:31:26 CDT(-0500)] <apetro> so, in practice, there is no styling, only very minimal markup.
[13:31:40 CDT(-0500)] <apetro> It's very different from DocBook.
[13:31:45 CDT(-0500)] <serac> Yeah, get that.
[13:32:02 CDT(-0500)] <serac> With XML you have XSLT, which opens up a world of possibilities for stying.
[13:32:10 CDT(-0500)] <apetro> Nonetheless. Working for Pro Git.
[13:32:12 CDT(-0500)] <serac> With markdown, I have no idea about options.
[13:32:33 CDT(-0500)] <apetro> Well, the real option is to use the Ruby libraries that github is using.
[13:32:37 CDT(-0500)] <serac> Pro Git is nice.
[13:32:44 CDT(-0500)] <serac> That's all the styling we need.
[13:33:07 CDT(-0500)] <apetro> but most of the pitch is that you don't need libraries, you just need a reasonable facility with scripting, and you just do it because the syntax is so darn simple. That's the pitch, anyway.
[13:33:17 CDT(-0500)] <apetro> It depends on what our goal is here.
[13:33:19 CDT(-0500)] <serac> Sounds good.
[13:33:28 CDT(-0500)] <apetro> if building documentation to PDF needs to be part of the Maven build, there's some engineering to do.
[13:33:31 CDT(-0500)] <serac> We just need support for some simple HTML styling.
[13:33:34 CDT(-0500)] <serac> It needs to look handsome.
[13:33:48 CDT(-0500)] <serac> We need some kind of build integration. PDF is optional in my mind.
[13:33:56 CDT(-0500)] <apetro> if the requirement is only that a PDF of the manual be released frequently, then we can cheat and use external tooling.
[13:34:12 CDT(-0500)] <serac> Seems we should release for all formats in one fell swoop.
[13:34:22 CDT(-0500)] <serac> But there's nothing to say PDF can't be manual post-release process.
[13:35:36 CDT(-0500)] <apetro> there is promising progress in tools that work with Markdown. If I can ever fit a Mac into the home budget, then I'll get this: http://www.iawriter.com/ , and then I image the process for producing a beautiful manual would look something like: munge all the chapters into one text file, open in IAWriter, press Print, print to PDF.
[13:36:00 CDT(-0500)] <apetro> Also, Trello uses Markdown for comments on cards, so Markdown must be cool...
[13:36:11 CDT(-0500)] <serac> No one said otherwise (wink)
[13:36:16 CDT(-0500)] <apetro> indeed
[13:36:21 CDT(-0500)] <serac> Whether it's cool for us lusers is another matter.
[13:36:32 CDT(-0500)] <apetro> so where do we tactically go
[13:36:40 CDT(-0500)] <serac> I think this is the right direction.
[13:36:49 CDT(-0500)] <apetro> there's certainly work to do on improving / investigating documentation "build" automation
[13:37:04 CDT(-0500)] <apetro> which could eventually get to Maven integration, though I would think there are a bunch of steps before that, like generating HTML at all
[13:37:08 CDT(-0500)] <serac> The need to escape XML configuration snippets is reason enough to eschew XML/DocBook.
[13:37:14 CDT(-0500)] <apetro> indeed
[13:37:26 CDT(-0500)] <serac> I'll take the build integration if/when we get there.
[13:37:34 CDT(-0500)] <apetro> while there's shortcomings on this Markdown stab, I feel like it's already more "alive" than is the DocBook work in Trunk
[13:37:48 CDT(-0500)] <serac> I think that impression is meaningful.
[13:38:08 CDT(-0500)] <serac> Writing documentation should be painless if not enjoyable, if for nothing else to give you the energy to do it.
[13:38:15 CDT(-0500)] <apetro> I mean, but for my working on it, this was dead, right? https://github.com/Jasig/cas/tree/master/cas-server-documentation
[13:38:19 CDT(-0500)] <serac> If this adds to your joy, awesome.
[13:38:30 CDT(-0500)] <serac> Dormant, not dead.
[13:38:33 CDT(-0500)] <apetro> not that we couldn't make it alive again with a bunch of work
[13:39:01 CDT(-0500)] <serac> Maybe Rip-Van-Winkle dormant, but not dead. We owe you for breathing life back into the effort in general.
[13:39:04 CDT(-0500)] <apetro> alright. Dormant. Needs work to make active. Well, Markdown needs work to make active too. The actual content in the Markdown is already a superset of what's there in the DocBook
[13:39:26 CDT(-0500)] <serac> I'm just interested in the content in the end.
[13:39:34 CDT(-0500)] <serac> I can make either one work, but pleasure helps.
[13:39:41 CDT(-0500)] <apetro> so, tactically, at what point does https://github.com/Jasig/cas/tree/master/cas-server-documentation stop being DocBook and start being Markdown?
[13:39:50 CDT(-0500)] <serac> Whenever you cut over (wink)
[13:40:01 CDT(-0500)] <apetro> I think we're rapidly approaching that point, because the Markdown content is already better.
[13:40:03 CDT(-0500)] <serac> We've got history, so np.
[13:40:17 CDT(-0500)] <serac> Make the switch at your convenience.
[13:40:28 CDT(-0500)] <serac> I'm not sold on those diagrams.
[13:40:41 CDT(-0500)] <serac> If you've got a UI guy you want to throw at it, I'd be grateful.
[13:40:43 CDT(-0500)] <apetro> alright, how do I do that? Fork jasig/cas master , replace the DocBook doco, and submit pull request?
[13:41:02 CDT(-0500)] <serac> Just pull master into your local copy, switch, then push.
[13:41:17 CDT(-0500)] <apetro> the diagrams need work, and I do think Unicon can pull in efforts of webdev / ux professionals on this over the medium term, yes.
[13:41:49 CDT(-0500)] <serac> You good on the steps?
[13:42:03 CDT(-0500)] <serac> There are actually lots of ways. Whatever works best for you.
[13:42:03 CDT(-0500)] <apetro> no, but I might figure it out
[13:42:09 CDT(-0500)] <apetro> what's next on the agenda?
[13:42:17 CDT(-0500)] <serac> UnConf
[13:42:33 CDT(-0500)] <serac> I will figure out a way to go if battags goes, even if it means camping.
[13:43:02 CDT(-0500)] <apetro> Tentatively I'll be there, I believe wgthom will as well.
[13:43:06 CDT(-0500)] <serac> I really want to use it as a dev summit opportunity for CAS.
[13:43:14 CDT(-0500)] <serac> Need battags for that to really be effective.
[13:43:14 CDT(-0500)] <wgthom> yep
[13:43:37 CDT(-0500)] <serac> Not that we can't be productive otherwise, but more productive with everyone in the same room.
[13:43:59 CDT(-0500)] <serac> I'd consider coming in any case if VT would foot the bill. Haven't seriously asked yet.
[13:44:13 CDT(-0500)] <serac> I will bug battags over weekend to see where he's at.
[13:44:30 CDT(-0500)] <wgthom> so northeast cas meetup in MA
[13:44:38 CDT(-0500)] <serac> Yeah
[13:46:09 CDT(-0500)] <apetro> k. I imagine fleshing out the set of CAS folks attending will make the event more attractive to potential attendees
[13:46:57 CDT(-0500)] <apetro> there's the UnConference piece of it and then the dev days piece. A little interesting to think about which days are what activities, especially if e.g. battags is constrained as to how many days he can be there.
[13:47:50 CDT(-0500)] <serac> I thought it was paint your own pottery style anyway, so I'm not sure what distinction there is between the two.
[13:48:02 CDT(-0500)] <serac> That said, I've never been. Thoughts?
[13:49:58 CDT(-0500)] <wgthom> it's pretty free flowing…i'm sure we can work around schedules if need be
[13:50:07 CDT(-0500)] <serac> What I'm thinking.
[13:51:10 CDT(-0500)] <serac> Think that's enough on that.
[13:51:13 CDT(-0500)] <serac> Roadmap?
[13:53:10 CDT(-0500)] <apetro> yeah. So, I guess where I thought the discussion went two weeks ago in IRC or so
[13:53:36 CDT(-0500)] <serac> Went where?
[13:53:39 CDT(-0500)] <serac> Not following.
[13:53:51 CDT(-0500)] <apetro> was that there'd be a 4.0 release on a winter timeframe, called 4.0 to accomodate the new session storage (aka TicketRegistry) API and implementations, thereby dodging deadlock issues
[13:54:16 CDT(-0500)] <Ozy_work2> i can't make the unconfrence, simply because I cannot sell my management on it without some sort of outline/agenda
[13:54:23 CDT(-0500)] <apetro> So I guess I thought we were at the stuff in 3.5 on that roadmap page https://wiki.jasig.org/display/CAS/CAS+Roadmap being called 4.0 and including that feature.
[13:55:16 CDT(-0500)] <apetro> but I may have misapprehended. Are we at a winter 3.5 release not including the SessionStorage API but including the other items, which look good?
[13:55:24 CDT(-0500)] <serac> Whatever version the session storage API changes make will be a new major rev.
[13:55:44 CDT(-0500)] <apetro> yup. That's the way I remember the 2-weeks-ago discussion.
[13:55:45 CDT(-0500)] <serac> Your last comment is my understand.
[13:56:04 CDT(-0500)] <wgthom> me too.
[13:56:13 CDT(-0500)] <serac> There's enough stuff in there to merit a minor release sooner than later.
[13:56:18 CDT(-0500)] <wgthom> yep
[13:56:23 CDT(-0500)] <serac> So 3.5 then 4.0 with session API changes.
[13:56:36 CDT(-0500)] <apetro> are the TicketRegistry deadlock issues bad enough that they need to be fixed sooner rather than later?
[13:56:40 CDT(-0500)] <serac> Timeframe for 4.0 TBD, but before 2012 sounds good.
[13:56:45 CDT(-0500)] <serac> They're bad.
[13:56:51 CDT(-0500)] <serac> But hard to fix.
[13:57:25 CDT(-0500)] <serac> I believe I have a design for the tables, but that's a bottom-up design that's mostly a non-starter.
[13:57:47 CDT(-0500)] <serac> So I need the new API to dig in and work with.
[13:58:24 CDT(-0500)] <serac> The good news is that I have a very reliable test harness to evaluate designs.
[13:58:36 CDT(-0500)] <serac> Anyway, it's a pretty big feature that's later than sooner by my estimate.
[13:59:28 CDT(-0500)] <apetro> alright. Lacking resources to pull that feature in sooner, CAS 3.5 soon without it sounds sensible.
[13:59:49 CDT(-0500)] <serac> I think so.
[13:59:59 CDT(-0500)] <apetro> so, next steps?
[14:00:12 CDT(-0500)] <apetro> Further fleshing out of 3.5 writeup in roadmap?
[14:00:12 CDT(-0500)] <serac> Continue work toward 3.4.11, 3.5.
[14:00:21 CDT(-0500)] <serac> I think it's fairly well fleshed out.
[14:00:24 CDT(-0500)] <apetro> where's the branch of source control working towards 3.5?
[14:00:29 CDT(-0500)] <serac> master
[14:01:15 CDT(-0500)] <kickehy> may i just say that trying to get permissions right on a windows ca is absolutely annoying
[14:01:18 CDT(-0500)] <serac> We can create a separate branch if needed, but let's just start throwing stuff in there as it develops.
[14:01:52 CDT(-0500)] <apetro> master sounds right, I hadn't realized it was marching towards 3.5
[14:01:56 CDT(-0500)] <serac> We still have the lppe branch to finish up that work.
[14:02:09 CDT(-0500)] <serac> The other stuff seems perfectly evolutionary.
[14:02:20 CDT(-0500)] <serac> At some point lppe will presumably be merged into master.
[14:02:27 CDT(-0500)] <serac> Any idea on timeframe?
[14:02:31 CDT(-0500)] <wgthom> yes, that would be the plan
[14:02:45 CDT(-0500)] <wgthom> soon i hope
[14:02:46 CDT(-0500)] <wgthom> (smile)"
[14:03:00 CDT(-0500)] <wgthom> still need to step thru some scenarios
[14:03:15 CDT(-0500)] <wgthom> and i'd like to get a code review if possible
[14:03:27 CDT(-0500)] <wgthom> but the code is pretty close
[14:04:26 CDT(-0500)] <serac> With github, it's very easy to review and comment on commits.
[14:05:01 CDT(-0500)] <serac> I'll try to go back and make some notes on previous commits, and I'm following the RSS feed on the Jasig/cas repo, so I'll get the ones going forward. Hopefully with feedback.
[14:05:15 CDT(-0500)] <wgthom> right…not always easy to find time, eye balls
[14:05:23 CDT(-0500)] <wgthom> cool
[14:05:36 CDT(-0500)] <serac> I'd recommend all committers follow commits however they like, but RSS is a good solution absent other preferences.
[14:05:43 CDT(-0500)] <wgthom> yep
[14:07:56 CDT(-0500)] <apetro> out of time, anything else?
[14:08:07 CDT(-0500)] <serac> Nothing here. Have a good weekend folks.
[14:08:12 CDT(-0500)] <wgthom> u to
[14:08:22 CDT(-0500)] <wgthom> can you make the rain stop?
[14:08:31 CDT(-0500)] <serac> I'll see what I can do (wink)
[14:15:50 CDT(-0500)] <kickehy> does anyone have experience on setting up a CA on server 2008 r2?
[14:16:26 CDT(-0500)] <serac> No, but do you really need to do that?
[14:16:47 CDT(-0500)] <kickehy> well it's already implemented in our environment
[14:17:01 CDT(-0500)] <kickehy> that's why i'm attempting to use it
[14:17:30 CDT(-0500)] <serac> So if it's already implemented, what's to set up.
[14:17:31 CDT(-0500)] <serac> ?
[14:17:35 CDT(-0500)] <kickehy> well
[14:18:17 CDT(-0500)] <kickehy> the web console you request from requires you to create templates that you use to request a cert
[14:18:32 CDT(-0500)] <kickehy> the problem is that non of the default templates do what i need it to
[14:18:34 CDT(-0500)] <serac> Ah, I see. Not familiar with that part.
[14:18:59 CDT(-0500)] <kickehy> and I think I may need Windows 2008 enterprise to make it work
[14:19:06 CDT(-0500)] <kickehy> but i wanted to confirm that
[14:41:51 CDT(-0500)] <kickehy> www.dbq.edu <---wow
[14:41:58 CDT(-0500)] <kickehy> and i thought loras' site was dumb
[14:52:06 CDT(-0500)] <kickehy> oh whoops
[14:52:07 CDT(-0500)] <kickehy> lol
[14:52:10 CDT(-0500)] <kickehy> wrong channel
[14:52:11 CDT(-0500)] <kickehy> my bad
[14:55:32 CDT(-0500)] <apetro> What that site needs is an opportunity to login via CAS.
[14:55:41 CDT(-0500)] <serac> (wink)
[14:56:04 CDT(-0500)] <kickehy> hehe
[15:00:35 CDT(-0500)] <kickehy> at least i'm learning a lot about certs (tongue)
[15:01:29 CDT(-0500)] <serac> These days that's a good thing for your own safety on the Web if nothing else.
[15:04:59 CDT(-0500)] <kickehy> if i could easily type out what i've gone through in the past two weeks trying to reconcile a server 2000 CA and this server 2008 CA...you would understand why i'm going crazy about this
[15:05:12 CDT(-0500)] <kickehy> and why microsoft blows
[15:05:41 CDT(-0500)] <serac> Feel free to punt on this and just use openssl to generate a key/cert.
[15:05:52 CDT(-0500)] <serac> Should be straightforward to import an existing keypair.
[15:06:01 CDT(-0500)] <serac> Done that lots.
[15:07:16 CDT(-0500)] <kickehy> i very well may get to that point...heh
[15:13:39 CDT(-0500)] <ries> apetro: thanks for the advice, the SSL item was indeed a issue where SSO didn't work
[15:14:01 CDT(-0500)] <ries> apetro: is it possible to use CAS (out of the box) with a self signed certificate?
[15:14:51 CDT(-0500)] <wgthom> yes. but you have to set up trust yourself but importing the certs into the jvm
[15:15:25 CDT(-0500)] <ries> wgthom: Ok… I was just curious about that, luckily we had a domain left over where we had SSL enabled..
[15:15:41 CDT(-0500)] <serac> To be clear, the trust setup occurs on the clients.
[15:16:08 CDT(-0500)] <ries> Ahh yes, that makes it clear....
[15:16:24 CDT(-0500)] <ries> Need to do more reading around car and glassfish still…
[15:16:51 CDT(-0500)] <ries> Currently I use the org.jasig.cas.client.authentication.Saml11AuthenticationFilter and org.jasig.cas.client.validation.Saml11TicketValidationFilter
[15:17:11 CDT(-0500)] <serac> SAML is good.
[15:17:12 CDT(-0500)] <ries> Not sure if that's currect for gf… but ….baby steps… baby steps (smile)
[15:17:29 CDT(-0500)] <serac> Choice of protocol is really independent of container.
[15:17:45 CDT(-0500)] <ries> I do however crashed a couple of neurons, but I guess that comes with the job (big grin)
[15:17:53 CDT(-0500)] <ries> that's good to know..
[15:19:00 CDT(-0500)] <ries> I am going to celebrate weekend… I will keep hanging around… thanks a million guys!
[15:19:16 CDT(-0500)] <serac> Sure. Later.
[15:19:21 CDT(-0500)] <wgthom> sarac: if he's using self signed certs on the applications, he'll have to get those certs into the jvm of the cas server, if he wants to do PTs
[15:19:58 CDT(-0500)] <serac> True, but I always consider proxy tickets a more advanced case. This feels like initial setup.
[15:26:56 CDT(-0500)] <apetro> he'll need to get those certs into the JVM of the CAS server also if he wants CAS to successfully execute the single log-out callbacks, right?
[15:27:31 CDT(-0500)] <serac> Again, true. I understood him to mean self-signed on CAS server, but maybe he meant more generally.