[Jenkins-infra] secured jenkins mirrors

Greg Swift greg.swift at RACKSPACE.COM
Wed Jun 14 03:43:20 UTC 2017


replies also inline

On Tue, 2017-06-13 at 15:14 -0700, R. Tyler Croy wrote:
> (replies inline)
> 
> On Mon, 12 Jun 2017, Greg Swift wrote:
> 
> > 
> > Hey all.
> > 
> > I work at Rackspace and as we are building out our newest
> > environments
> > we've started blocking port 80 explicitly.  The Jenkins systems in
> > that
> > environment are failing on downloading plugins due to a 302
> > redirect
> > from https to http.  I'd rather avoid having to open an exception
> > for
> > downloading updates and plugins from the Jenkins mirrors. 
> > 
> > So the url:
> > 
> > https://updates.jenkins-ci.org/download/plugins/htmlpublisher/lates
> > t/ht
> > mlpublisher.hpi
> > 
> > redirects to http://mirrors.jenkins-ci.org/plugins/htmlpublisher/la
> > test
> > /htmlpublisher.hpi
> > 
> > which may redirect out to any number of non-ssl'd mirrors.
> > 
> > If i add https:// to the mirrors.jenkins-ci I get a cert mismatch
> > with
> > pkgs.jenkins.io which seems to only do platform specific package
> > repos.
> > 
> > So I guess my question is, is it possible for the secured
> > pkgs.jenkins.io to also have the plugins and update center
> > packages? Or
> > can we go about mirroring the content to Rackspace's internal
> > mirrors?
> > 
> > Rackspace runs a set of mirrors both internally and for our
> > customers[1]. Our preference for running a mirror is to use rsync,
> > but
> > looking through your documentation i did not see any rsync links,
> > so I
> > wanted to reach out and discuss this with y'all.  
> 
> 
> We do have an rsync option, for secondary mirrors, but that's not
> over SSL
> either :P

That would work. Having a single set of systems mirror over port 80 to
your rsync options is very doable, whereas having random boxes being
spun up inside large IP ranges needing outbound port 80 is strongly
discouraged.  

> 
> 
> We're in the process of moving distribution into Azure storage, which
> would
> then be end-to-end SSL (core releases from https://pkg.jenkins.io
> currently get
> redirected through Azure).
> 

Long term that would negate our need to mirror, but considering we have
quite a few jenkins it isn't a horrible thing for us to offset that
load.

To confirm a few things..

1) Do you want us as a public mirror too? or just have us act as an
internal mirror for outselves?
2) I assume if you want us as a public mirror that we have consent to
redistribute. Is there any restrictions we need to be aware of?
3) Is there anything else you would need from us to get things rolling?

thanks

greg


More information about the Jenkins-infra mailing list