Updating jenkins behind a proxy
Closed this issue · 8 comments
Jenksins is installed on a machine behind a proxied firewall.
Wget works fine on the command line (http_proxy env is set, its is also set in /etc/wgetrc)
However:
...
err: /Stage[main]//Node[jenkins-dev]/Jenkins::Plugin[credentials]/Exec[download-credentials]/returns: change from notrun to 0 failed: wget --no-check-certificate http://updates.jenkins-ci.org/latest/credentials.hpi returned 4 instead of one of [0] at /etc/puppet/environments/production/modules/jenkins/manifests/plugin.pp:44
notice: /Stage[main]//Node[jenkins-dev]/Jenkins::Plugin[credentials]/File[/var/lib/jenkins/plugins/credentials.hpi]: Dependency Exec[download-credentials] has failures: true
The puppet manifest is:
jenkins::plugin {
"credentials" : ;
"git" : ;
"github" : ;
"artifactory" : ;
"findbugs" : ;
"jenkinswalldisplay" : ;
}```
Any suggestions on how to troubleshoot this please?
Right now the plugin downloader is just using a shell command to get the plugins. If you need to, right away, you can use the the download center / plugin manager (inside Jenkins) to get the plugins, assuming Jenkins can reach the outside world.
You can also just manually download the files, and place them where they should be..
The real problem is likely that Puppet isn't picking up the wgetrc.
Which OS and version? I can't swear we'll get to fixing this soon, but we can make sure you can do work :)
(Long term, we're looking to move to using the jenkins server to download the plugins directly, as an option... but that might not help you. )
Also, how many jenkins (master) boxes are you looking to make? If it's more than one, or you expect to need to build many over time, you may be better off w/ a local copy of the files. It's something that I've considered for larger sites with many jenkins masters..
Thanks for the quick answer.
I'm only installing one server, but trying to do so in a documented repeatable way, so that when our developers come looking for more it easy to handle.
Your remark made me think ...
I changed the shell of the puppet user (on Ubuntu 12.04) from /bin/false to /bin/sh and then verified that a command line download works as "puppet", also set up a .wgetrc just for that puppet user.
However puppet is still not happy. The exit 4 code in the log is a "network failure", so it looks like you are right, puppet in calling wget is not "seeing" the proxies environment.
Puppet normally runs as root. Puppet shell execution can be weird in conjunction w/ environment variables and such.
I hear the repeatable bit. The best fix is probably to figure out the issue w/ wget.
I have a solution, in manifests/plugin/install.pp change the exec stanza to include an environment:
exec { "download-${name}" : command => "wget --no-check-certificate ${base_url}${plugin}", cwd => $plugin_dir, require => File[$plugin_dir], path => ['/usr/bin', '/usr/sbin',], user => 'jenkins', unless => "test -f ${plugin_dir}/${plugin}", notify => Service['jenkins']; environment => [ "http_proxy=$::http_proxy" ], }
then in the puppet site manifest add a top level variable for the proxy
$http_proxy='http://myproxy.mydomain.com:80'
The global coulöd be used for other modules, but is not very elegant.
That works. Now the question is what way to do this "right" so that you'd accept a pull request?
Yes, i was afraid you'd have to do something like that. Maybe you could just add it as a top or node scope default value in your config, in either your site.pp (or your ENC)
Exec{ environment => [ "http_proxy=$::http_proxy" ] }
?
Node scope should be minimally problematic is my guess on what it sounds like your config is.
Hmm. Nice. that works thanks.
More specifically I just add
Exec{ environment => [ "http_proxy=http://proxy.mydomain.com:80" ] }
thanks!
You can do this from where you have the jenkins::plugin { .... } code, IIRC. :)
Glad it worked, and no need to patch the module.