Skip to Content.
Sympa Menu

shibboleth-dev - RE: [Shib-Dev] Packaging embedded DS

Subject: Shibboleth Developers

List archive

RE: [Shib-Dev] Packaging embedded DS


Chronological Thread 
  • From: "Rod Widdowson" <>
  • To: <>
  • Subject: RE: [Shib-Dev] Packaging embedded DS
  • Date: Wed, 6 Apr 2011 14:01:17 +0100
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=steadingsoftware.com; h=from:to :references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding; q=dns; s= steadingsoftware.com; b=cS/DbdyRNsYJpCzlkajf2JDB2AN8BFggiWwX4XnI pamI3ybcQhTgNHnYj8vh5rhR/vaXl+PPfAE53JlhMON9Yqg9WA3mYes6hjok7hU3 rJNox6z39cCCQGqIkrmHtMKd8t/jKvoqBewBMd8P4dg3VTagb/XB7oC3gAOSwCkd jfk=

> It looks to me like of the files included in the "built" kit, probably all
> but the LICENSE and the
> actual compressed idpselect.js script may need to be editable by the
> deployer.

In theory only the config file should be edited, the index.html file being
looked at and then ignored. In practice I imagine that
people will edit the index.html file. The CSS is currently minified on the
assumption that most web people would include it as is.
AFAICS, and I am not an expert, most web page designers are not stressed by
including multiple web files in any one page...

If we do expect people to edit the CSS then we probably do not want to minify
it.

No arguments about the rest, but I do not claim any insight on this game.

Rod

> -----Original Message-----
> From:
>
>
> [mailto:]
> On Behalf Of
> Cantor, Scott E.
> Sent: 05 April 2011 22:31
> To:
>
> Subject: [Shib-Dev] Packaging embedded DS
>
> This is directed mainly at Rod, but since there are experienced Unix admins
> on the list, I'm widening
> the conversation.
>
> I'm helping to put together an install story and an RPM package for the
> emebedded DS scripts, and need
> to verify some assumptions.
>
> It looks to me like of the files included in the "built" kit, probably all
> but the LICENSE and the
> actual compressed idpselect.js script may need to be editable by the
> deployer. The config.js obviously
> is, and I assume the CSS would be and the index.html is just an example
> that would obviously be either
> modified or ignored.
>
> So we have at minimum:
>
> - doc files that would normally go into docdir
> - editable files that have to be web-visible
> - a non-editable file that also has to be web visible
>
> We could separate the latter two filesets, and put the non-editable script
> into
> /usr/share/html/<package>, but we can't put editable files there, so I
> wonder if there's much point in
> bothering.
>
> There's no great place for the editable files but probably the best of the
> bad choices is to use
> configdir (meaning etc/<package>) with a package-controlled Apache config
> to do the aliasing. The
> editable files would be config(noreplace), so people can change them and if
> they upgrade, they'd keep
> their changes but get .rpmnew copies of the updates. The non-editable file
> would be config(replace) so
> that it would be controlled by the package during upgrades.
>
> I'm not sure there's much point to putting 1-2 text files into a docdir off
> in /usr/share/doc vs. just
> sticking them into etc and not worrying about it, but I suppose I could be
> convinced otherwise.
>
> So long story short, I don't see much of a choice but to stick them in
> etc/shibboleth-ds or something
> like that and just autoinstall some Apache aliases. It seems ugly, but the
> alternative would be to
> just not do it, since obviously the install here amounts to "copy a few
> files into a web folder".
>
> -- Scott




Archive powered by MHonArc 2.6.16.

Top of Page