|
We have a few Jenkins masters behind a firewall that I need to manage, and I would like to know if it's possible to create our own Update Center within our firewall. This will allow us to regulate all the plugins and Jenkins updates for all our Jenkin masters.
Is there a way to do this? I took a look at "simpleupdatesite" plugin, but the instructions are extremely vague. Is there a way to create a custom Jenkins Update Center, and if so, how? Thanks! |
|
This post has NOT been accepted by the mailing list yet.
Sorry for late response.
I'm not a good English speaker so.. I don't know which point make it vague. :-). Could you tell me what make it difficult to install please? I'll put more detailed description if necessary. Actually I don't subscribe Jenkins user email list... so send it to junoyoon at gmail.com. Please. |
|
In reply to this post by grayaii
This seems to be a secret, i alrady asked several times in threads. Single point of hosting seems to be wanted.
2011/10/12 grayaii <[hidden email]> We have a few Jenkins masters behind a firewall that I need to manage, and I |
|
Hi,
You should give us more details about your jenkins machines, but if for example they are ubutu, you could create your own software repository like in http://www.ajatus.in/2011/02/set-up-your-own-ubuntu-repository-using-apt-mirror/ regards didier On Nov 25, 11:16 pm, Fabi <[hidden email]> wrote: > This seems to be a secret, i alrady asked several times in threads. Single > point of hosting seems to be wanted. > > 2011/10/12 grayaii <[hidden email]> > > > > > > > > > We have a few Jenkins masters behind a firewall that I need to manage, and > > I > > would like to know if it's possible to create our own Update Center within > > our firewall. This will allow us to regulate all the plugins and Jenkins > > updates for all our Jenkin masters. > > > Is there a way to do this? I took a look at "simpleupdatesite" plugin, but > > the instructions are extremely vague. Is there a way to create a custom > > Jenkins Update Center, and if so, how? > > > Thanks! > > > -- > > View this message in context: > >http://jenkins.361315.n4.nabble.com/Alternate-Update-Center-tp3898939... > > Sent from the Jenkins users mailing list archive at Nabble.com. |
|
In reply to this post by cforce-2
Go to
http://youjenkins/pluginManager/advanced and enter the URL for the update center location at site within your firewall area. You then need to copy the plugins you want somewhere and generate the JSON that is interpreded by Jenkins (as to the available plugins, versions and URLs) /james From: [hidden email]
[mailto:[hidden email]] On Behalf Of Fabi
This seems to be a secret, i alrady asked several times in threads. Single point of hosting seems to be wanted. 2011/10/12 grayaii <[hidden email]> We have a few Jenkins masters behind a firewall that I need to manage, and I ************************************************************************************** This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the [hidden email] and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary. NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00 ************************************************************************************** |
|
I think the question is not how to point Jenkins to an alternate update center, rather how to create your own update center.
Granted, this is not a high priority for me anymore, but I fired up my windows machine that has a test-dummy-Jenkins-master on it and created a directory that Jenkins can see: C:\Program Files\Apache Software Foundation\Tomcat 6.0\webapps\ROOT\myJenkinsPlugins\ I read the contents of the existing JSON file to try to reverse engineer (and to figure out what JSON file is needed to make Jenkins happy) =================================== import urllib2 response = urllib2.urlopen('http://updates.jenkins-ci.org/update-center.json') fd = open('foo.json','w') fd.write(response.read()) fd.close() =================================== I then copied this file to my "myJenkinsPlugins" folder and tweaked this file by changing all the version information to 9.9.9 (just to see if Jenkins will accept this alternate update center), and no luck. When I point Jenkins to my: http://localhost:8080/myJenkinsPlugins/foo.json and click Submit, no error message occurs, and unfortunately Jenkins seems to be using the old update center URL, not mine. I could not see any error messages in the logs either. I assume the solution is to create a folder that will contain all the hpi files here: C:\Program Files\Apache Software Foundation\Tomcat 6.0\webapps\ROOT\myJenkinsPlugins\*.hpi And then somehow generate a magic JSON file based on the contents of that directory, and finally point Jenkins to this generated JSON file. Didier, I will take a look at that link and try to figure this out. (I think i have to read a lot on JSON too!) ![]() All, thanks for replying! (cforce-2, if you figure anything out too, please post!) |
|
IIRC it needs signing.
Take a poke around http://ci.jenkins-ci.org/view/All/job/infra_update_center/ to see what it does. /James -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of grayaii Sent: 28 November 2011 16:15 To: [hidden email] Subject: RE: Alternate Update Center? I think the question is not how to point Jenkins to an alternate update center, rather how to create your own update center. Granted, this is not a high priority for me anymore, but I fired up my windows machine that has a test-dummy-Jenkins-master on it and created a directory that Jenkins can see: C:\Program Files\Apache Software Foundation\Tomcat 6.0\webapps\ROOT\myJenkinsPlugins\ I read the contents of the existing JSON file to try to reverse engineer (and to figure out what JSON file is needed to make Jenkins happy) =================================== import urllib2 response = urllib2.urlopen('http://updates.jenkins-ci.org/update-center.json') fd = open('foo.json','w') fd.write(response.read()) fd.close() =================================== I then copied this file to my "myJenkinsPlugins" folder and tweaked this file by changing all the version information to 9.9.9 (just to see if Jenkins will accept this alternate update center), and no luck. When I point Jenkins to my: http://localhost:8080/myJenkinsPlugins/foo.json and click Submit, no error message occurs, and unfortunately Jenkins seems to be using the old update center URL, not mine. I could not see any error messages in the logs either. I assume the solution is to create a folder that will contain all the hpi files here: C:\Program Files\Apache Software Foundation\Tomcat 6.0\webapps\ROOT\myJenkinsPlugins\*.hpi And then somehow generate a magic JSON file based on the contents of that directory, and finally point Jenkins to this generated JSON file. Didier, I will take a look at that link and try to figure this out. (I think i have to read a lot on JSON too!) All, thanks for replying! (cforce-2, if you figure anything out too, please post!) -- View this message in context: http://jenkins.361315.n4.nabble.com/Alternate-Update-Center-tp3898939p4115748.html Sent from the Jenkins users mailing list archive at Nabble.com. ************************************************************************************** This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the [hidden email] and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary. NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00 ************************************************************************************** |
|
Thanks for the link, James! I'll take a look at it!
ps. You can ignore my python gobbly gook (it was part of a larger script). You can simply navigate to http://updates.jenkins-ci.org/update-center.json to get contents of the JSON file. |
|
In reply to this post by grayaii
Hi Guys, I meet the same issue.
Then how can I generate an update-center.json JSON file that can be interpreded by Jenkins. We do have several plugins which will be used only inner our group, we do not like to deliver them to jenkins group. As a solution, I think we should put the plugins somewhere, and update the update-center.json to point out these plugin, but jenkins always report a signature or digest error. So my question is can any people head me how to write an update-center.json file that can be interpeded by jenkins. Thanks very much. 在 2011年10月13日星期四UTC+8上午1时52分40秒,grayaii写道: We have a few Jenkins masters behind a firewall that I need to manage, and I |
|
[shameless plug]
note that link will be changing to
CloudBees have an UpdateCenter plugin that allows Jenkins to serve it's own UpdateCenter and allows easy configuring of that update center from other Jenkins instances (i.e. it provides a plugin that you can download and install into the jenkins instances that installs the required trust certs for signed update center metadata)
[/shameless plug] On 17 August 2012 12:02, Hui Shen <[hidden email]> wrote: Hi Guys, I meet the same issue. |
|
I nkew it all the time. This useless signing is just a business case to sell some extra plugin.
JUst remove that signing code and allow opensoucing everything. Just use a plain old maven repo and get plugins via dependecy resolution.
Noone wants cloudbees vendor lock in to plugins update site generation.
2012/8/17 Stephen Connolly <[hidden email]> [shameless plug] |
|
Nope. You can sign your own update center too.
The code for signing the UC is open source. The issue is that for the signing to have meaning you need to have the cert trusted.
There are a number of ways to get the cert trusted. You can drop the cert into a special directory in $JENKINS_HOME (I cannot recall exactly which, but it can be found on the jenkins wiki) There is a set of certs that ships in OSS jenkins. These are tied to the OSS update center. There is a set of certs that CloudBees use to generate our update center (jenkins-updates.cloudbees.com) those certs are installed by our plugins (in the exact same way anyone else can install certs) Here is an example of how we verify that the metadata from our update center comes from our update center: https://github.com/jenkinsci/cloudbees-plugin-gateway/blob/master/src/main/java/com/cloudbees/jenkins/plugins/freeplugins/CloudBeesUpdateSite.java#L250
If you want to issue your own update site, you can use that code but bundle your own cert. Signing is not about vendor lock in... in fact I gave out to KK for introducing the signing as it was a right pain for me when he introduced it and I had to rewrite a chunk of our update center under the clock before a release ;-)
Look at the code and you will see that metadata signing is all above board and actually driven by the community and not CloudBees.... though we do support it. -Stephen On 20 August 2012 23:33, cforce <[hidden email]> wrote: I nkew it all the time. This useless signing is just a business case to sell some extra plugin. |
| Powered by Nabble | Edit this page |
