Canarie Installer suitability for Shib "quick start"?

[Marlena Merrin-Erdos]

Hi Scott,

but there are no short term plans to change anything about our installation
process and there are no apparent resources from TIER to do so, so what are
we really talking about?

I have two distinct things to say in response:

1) There's absolutely a resource from TIER!   Paul Caskey.

How much of his time is available is not decided.  If there are specific
tasks he could do that improve the install/initial
config/test-along-the-way experience, he could estimate the hours, and then
Steve Z and Ann West could decide on whether he can go forward.

Given this, what can "we" do that improves the install/initial
config/test-along-the-way experience?

Paul: Please weigh in here.

2) You seemed to agree to the "success factors" I put forth in the Success
Factors
<https://docs.google.com/document/d/13CQyHMD0ZAvLwZLD6RZSQ03ebrB5K-qE8DlsHhxwzNw/edit?usp=sharing>
doc that was input to the last Dev call:  Here are both what I wrote as
"factors"  and my notes on what people said:


   -

   Test application for LDAP and database connectivity. Application
   retrieves and then displays a set of attributes.
   -

      Looks like IdP hosted tool can meet this (as per Scott and others)



   -

   Test SP with "hello world" application. Should display attributes from
   the IdP.  This allows for testing of attribute filter rules and attribute
   resolver transformations.
   -

      Installation of the V3 IDP also installs its metadata in the test SP,
      and vice versa. Whether this is done as part of keygen or later doesn’t
      matter (to me). ‘
      -

      Looks like IdP hosted tool can meet this (as per Scott and others)


If you are saying "yes" to this but aren't calling it a change to the
installation procedure, then that's another matter.  If you are saying
"no," then what has changed?

**

Perhaps "getting started" is the term of art you want here.

Thank you for the suggestion but that phrase seems to imply the inclusion
of "Concepts & Basics Info" -- which as you know is a task awaiting funding
:-).

**
I'm going to leave aside comment on your other responses until we can get
some clarity on how the overall install/config/test-along-the-way process
can be enhanced -- with Paul as a resource.

I'm pretty set on having the "Success Factors" above met (e.g. "test ldap"
capability) so that may be a point of contention, but let's see!  I'm
hoping we just have a misunderstanding about what "enhance the installation
procedure means."   To clarify, I mean enhance the overall overall
install/config/test-along-the-way process.  I don't care which piece is
"in" the installer and which piece is separate.

Thanks,
Marlena


On Tue, Feb 28, 2017 at 8:06 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 2/28/17, 4:21 PM, "dev on behalf of Marlena Merrin-Erdos" <
> dev-bounces at shibboleth.net on behalf of marlena.erdos at gmail.com> wrote:
>
> > Our big problems (IMO) are:
>
> > * deciding on "audience": what type of user and institution are we
> targeting; who are we consciously leaving out
> > * deciding what the installer does that might make an audience member's
> life easier.
> > * differentiating  what's a Quick Start Guide, and what's in a System
> Administration Guide
>
> I think there's a more fundamental issue here that I'm missing. I can
> understand asking what should be in a Deployer's (or Installer's) Guide,
> but if we're talking software here, I don't see how that's in scope for
> this conversation. We have a long term plan to look at how we can integrate
> better with the CANARIE installer, but there are no short term plans to
> change anything about our installation process and there are no apparent
> resources from TIER to do so, so what are we really talking about?
>
> What we have is what we have. That's it. And I don't think that's a
> problem. People don't have problems installing Shibboleth, the problems
> come with the next steps. They just get lost. That's a documentation
> problem, and doesn't really require new code.
>
> > This is a great point -- but not a damning one given that TIER is
> funding the work.   A "Quick Start Guide for TIER
> > Institutions" would likely suit TIER just fine.  This is especially so
> given that TIER is expecting an influx of community
> > colleges and K-12 schools who will want IdPs (according to Paul Caskey).
>
> Only insofar as TIER accepts the responsibility to maintain it. I have no
> problem with that, but I do have a problem with more community-specific
> documentation that is stale and that I have to tell people to ignore if
> they want my help. So that's my only real concern over it. If we're
> expected to maintain it, then it would be non-specific to InCommon.
>
> I'm fine with either outcome but I don't think it's an unreasonable
> position for us to take.
>
> > * Most of this ongoing maintenance of the IdP belongs in a System
> Administration Guide, not a Deployment Guide (IMO).
> > (The "Deployer's Guide" really should be called "Installer's Guide" to
> avoid confusion due to the larger meaning of
> > "deploy" vs"install."  I might advocate for this.)
>
> Perhaps "getting started" is the term of art you want here.
>
> > * If a school brings up an IdP and demonstrates its value --- say by
> allowing for a connection to HathiTrust (a library
> > resource) -- then the school might (might) be able to get funds to
> support "doing the IdP right" in an ongoing way
>
> My experience is that if you adopt the software internally at scale,
> you're forced to care about doing it well, and if not, you tend to have a
> lot of trouble devoting the necessary time to it. That's the dividing line
> I've routinely encountered: federation-only vs. enterprise. It doesn't grow
> out of supporting isolated use cases.
>
> > Given that, the question (it seems to me) is "what is the installation
> process that goes along with the Quick Start
> > Installation Guide"?
>
> If you're asking us, the answer is that it's the current installation
> process, and I don't think that materially inhibits your exercise.
>
> You asked about the CANARIE installer. I think it's useful and I think
> TIER should be reusing it if they want to go in a similar direction
> functionally, but I don't think it is in scope for your documentation
> effort unless you want to have that conversation with TIER and couple the
> proposal to an additional, currently unspecified, piece of work.
>
> -- Scott
>
>
> --
> To unsubscribe from this list send an email to
> dev-unsubscribe at shibboleth.net
>



-- 
617-216-6563 (cell via Google Voice) or 857-308-6986 (direct cell)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20170301/eb31aae3/attachment.html>