just to be clear the https url thing is solvable with the intelligent proxy thing just a bit more work and client/library support isn't always great. http://wiki.squid-cache.org/Features/HTTPS
On Tue, Apr 1, 2014 at 4:11 PM, Kapil Thangavelu < [email protected]> wrote: > If your trying to do this in automated fashion, juju supports proxies, and > possibily with intelligent proxy you could do something a bit more > automated. else its going to require alot of auditing. you could even skip > the additional steps of modifying all the charms have the intelligent proxy > work in offline mode with its cache to serve out the files back when > deploying in an offline setup. the issue is going to be https url then. > > > On Tue, Apr 1, 2014 at 4:05 PM, Matt Bruzek > <[email protected]>wrote: > >> Thanks Jorge, >> >> Not sure we want to call them "fat" charms, maybe "enterprise" charms. >> Here is my approach when making a charm work on the enterprise or limited >> networks. >> >> 1) Find out what hook downloads the packages that we are unable to access >> (wget, curl, or special ppa repositories). The enterprise network will >> block these requests often resulting in a charm hook failing. >> 2) Download the necessary packages from system that has access. >> 3) Upload the packages to the locked down system, copying the packages to >> a directory on the local charm. >> 4) Edit the local charm hooks to check for the package in the local >> directory first and if that does not exist, the charm would continue to >> download the files (using wget, or curl, or custom ppa). >> >> I believe we could provide a charm-tools method that does something like >> this and we could use this in charms to create "enterprise" charms that are >> able to be used on limited network environments. >> >> However this creates an interesting problem that I have not figured out a >> good way to resolve yet (your feedback requested). >> >> If the packages exist within the charm the URL will never be used. Some >> charms allow the user to configure the download URL and sha1sum of the >> package. Other charms do not allow this level of customization. >> >> For charms that have a config option for URL we could change it to also >> accept a file:// transport and some kind of $CHARM_DIR variable and use >> http:// or https:// for normal URLs. But what to do with the charms >> that do not allow the URLs to be configurable, or the charms that use a >> custom ppa repository? >> >> - Matthew Bruzek <[email protected]> >> >> >> On Tue, Apr 1, 2014 at 2:07 PM, Jorge O. Castro <[email protected]> wrote: >> >>> Hi everyone, >>> >>> Matt Bruzek and I have been doing some charm testing on a machine that >>> does not have general access to the internet. So charms that pull from >>> PPAs, github, etc. do not work. >>> >>> We've been able to "fatten" the charms by doing things like creating a >>> /files directory in the charm itself and putting the >>> package/tarball/jar file in there, and given the networking issues >>> that we might face in production environments that we should start >>> thinking about best practices for having charms with payloads instead >>> of pulling from a network source. >>> >>> Marco has some ideas on how we can generalize this and he will respond >>> to this thread. >>> >>> -- >>> Jorge Castro >>> Canonical Ltd. >>> http://juju.ubuntu.com/ - Automate your Cloud Infrastructure >>> >>> -- >>> Juju mailing list >>> [email protected] >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/juju >>> >> >> >> -- >> Juju mailing list >> [email protected] >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju >> >> >
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
