Shibboleth-IDP rpm packaging
Philip Prindeville
philip.prindeville at gigamon.com
Mon Jun 17 14:13:12 EDT 2019
That first part sounds about right. We're not doing "containers" (at least not in the "Docker" sense) but VMware, AWS, etc. images to be spun-up in the cloud.
The customer has no ability to update any of the components in the image (indeed, most of the image is read-only, other than the /var partition and we symlink writable configuration files into that directory subtree).
We don't have to use RPM packaging, but since we're building in a CentOS environment that seemed like the preferred way to do modular builds of the various components integrated into our images.
On 6/17/19, 11:55 AM, "dev on behalf of Cantor, Scott" <dev-bounces at shibboleth.net on behalf of cantor.2 at osu.edu> wrote:
On 6/17/19, 1:38 PM, "dev on behalf of Philip Prindeville" <dev-bounces at shibboleth.net on behalf of philip.prindeville at gigamon.com> wrote:
> The "why" is: this is a set of requirements that got dumped in my lap 2 weeks ago to support SSO for an existing product
> (based on Centos 6.6).
Then the actual upstream project aside, you presumably are looking at a tightly controlled situation with the container nailed down and packaged already (or you'd have to include that piece too). Given that, you certainly have the control necessary, and it adds in the constraint that anything we screw up re: upgrades would be identified in testing and Q/A and dealt with via patches in the RPM/etc. to make sure the final result is cleanly going to stop, upgrade, restart to meet the RPM contract.
But anyway, the bottom line is I think you're looking at a scripted "RPM just does what our installer does, or runs it outright" kind of scenario, not a literal translation of all our files into an RPM-controlled package. I think that would be much harder to try to pull off.
-- Scott
--
To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net
This message may contain confidential and privileged information. If it has been sent to you in error, please reply to advise the sender of the error and then immediately delete it. If you are not the intended recipient, do not read, copy, disclose or otherwise use this message. The sender disclaims any liability for such unauthorized use. NOTE that all incoming emails sent to Gigamon email accounts will be archived and may be scanned by us and/or by external service providers to detect and prevent threats to our systems, investigate illegal or inappropriate behavior, and/or eliminate unsolicited promotional emails (“spam”).
More information about the dev
mailing list