Great point, Simon. Thank you for sharing that. On Thu, Dec 21, 2017 at 8:26 AM, Simon Baatz <[email protected]> wrote:
> On Tue, Dec 19, 2017 at 12:41:08PM -0500, Dennis Kliban wrote: > > Crane cannot perform a rewrite of the redirect URL at this time. This > > seems like a reasonable feature request. I recommend filing a story - > > we can discuss the feature details on there. > > > > That would be a nice feature indeed. In the meantime, you could try > to let Apache rewrite the "Location" header used for redirection > (using the mod_headers module in Apache 2.4). > > We did not fully test this (let alone use it in production), but for > a test setup with Pulp & crane running in a VM and port forwardings > (Host 5000 -> VM 5000, Host 9443 -> VM 443), we can 'docker pull' on > the host from crane using the following Apache config: > > <VirtualHost *:5000> > Header edit Location "^https://[^/]+"; "https://localhost:9443"; > WSGIScriptAlias / /usr/share/crane/crane.wsgi > <Location /crane> > Require host localhost > </Location> > <Directory /usr/share/crane/> > Require all granted > </Directory> > </VirtualHost> > > For example, without changing "Location", you would get this on > the host: > > $ docker pull 127.0.0.1:5000/busybox:latest > Trying to pull repository 127.0.0.1:5000/busybox ... > Get https://default-bento-centos-74.vagrantup.com/pulp/docker/ > v2/busybox/manifests/list/latest: Not Found > > Using the cofiguration from above, you get: > > $ docker pull 127.0.0.1:5000/busybox:1.27.0-glibc > Trying to pull repository 127.0.0.1:5000/busybox ... > sha256:ebeb530823bf0f229b2e2559a1ea92298d7f1ce2efabd9030c5d2b1deac83af6: > Pulling from 127.0.0.1:5000/busybox > 02b2b239e358: Pull complete > > > - Simon > > > > On Wed, Dec 13, 2017 at 11:29 AM, Mihai Ibanescu > > <[1][email protected]> wrote: > > > > Hi, > > In our current setup, we have a purely internal pulp deployment, that > > publishes to an NFS share. > > HTTP frontend machines handle the cert-based authn/authz and serve the > > content from the NFS share. > > We have an internal set of HTTP frontend machines, and an internal > > customer has access to published content for all development stages > > (dev/test/prod). > > We also have an external set of HTTP frontend machines, that handle > > external customer requests, and only serve the prod stage. Content > from > > the internal NFS share is selectively rsynced into the external disk > > share. > > This all works great for rpm and such. > > I believe there is a problem with docker. We would have one internal > > and one external crane deployment, as expected. Content would be > > rsynced, as usual. However, because the redirect URL is "baked" into > > the redirect json files, the external Crane would redirect to the > > internal system, which is not helpful. > > We would prefer not to republish / recreate the redirect files in our > > transition from internal to external content. > > One way to handle this would be a Crane configuration option that > > directs crane to rewrite the redirect URL. In that case, internal and > > external crane systems would be configured differently. > > The questions: > > * Is there such an option in Crane? (looking at the code, I believe > the > > answer is no) > > * Is there a feature request for something like this already? > > * If not, do you agree what I've described above is a valid customer > > use case, and should I file it as a feature request? > > Thanks! > > Mihai > > > > _______________________________________________ > > Pulp-dev mailing list > > [2][email protected] > > [3]https://www.redhat.com/mailman/listinfo/pulp-dev > > > > References > > > > 1. mailto:[email protected] > > 2. mailto:[email protected] > > 3. https://www.redhat.com/mailman/listinfo/pulp-dev > > > _______________________________________________ > > Pulp-dev mailing list > > [email protected] > > https://www.redhat.com/mailman/listinfo/pulp-dev >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
