Configuration-as-code-plugin: No way to access CASC_JENKINS_CONFIG or other configuration variables when running Jenkins as a Linux service on a VM

[robincsmith]

Jenkins version: 2.150.1
Configuration as Code Plugin version: 1.4
OS: Centos 7.6.1810

When running Jenkins as a Linux service using service jenkins start, all environment variables including CASC_JENKINS_CONFIG are stripped away and the jenkins.yaml configuration file is not loaded.

This can be worked around by moving jenkins.yaml from its generic location to $JENKINS_ROOT/jenkins.yaml, but the problem remains for other CasC configuration accessed through environment variables, such as CASC_VAULT_FILE and other Vault-related values.

Could these config options be provided to Jenkins in another way, e.g. in a config file or by providing arguments to the Jenkins run command?

[jetersen]

Sounds like a basic question of how to set environment variables for a service.

https://unix.stackexchange.com/questions/374398/environment-variables-for-daemons

[robincsmith]

Thanks - I had been messing around with the configuration variables in /etc/sysconfig/jenkins for a long time to no avail. Happy for this to be closed

[chhex]

@jetersen Even though closed, i think this STILL is a very valid and elementary point:

1. Your pointer is simply wrong . At least on Centos 7 as of Jenkins Version 2.235.1 installed as rpm
2. It is not so much : - Look ma , no hands. But: Damn ma, many hands or even the left hand, doesn't know what the right hand is doing.

Concerning 1:

sudo more /etc/centos-release
CentOS Linux release 7.8.2003 (Core)

rpm -qa | grep jenkins 
jenkins-2.222.3-1.1.noarch



md5-85c1fbf7c55691598ca92b1af2541941



systemctl status jenkins.service                                                                                                                                            
jenkins.service - LSB: Jenkins Automation Server
Loaded: loaded (/etc/rc.d/init.d/jenkins; bad; vendor preset: disabled)Active: active (running) since Don 2020-06-18 18:54:39 CEST; 39min ago

So there is no jenkins.service unit installed, where yes it would be easier to introduce a Environment variable , as suggested, but a legacy init.d script, which doesn't take environment variables and where in the end you do have to fiddle with the /etc/sysconfig/jenkins file

But 2:
Most jenkins drops come pre packaged like as rpm and package formats. So definitely very distinct groups people packaging, are nstalling and configuring and then using jenkins, with very different privileges. The packaging is done in the normal cases by the jenkins projekt, seehttps://github.com/jenkinsci/packaging. The installation is done by operation of a provider of the end user or in-house operations, the configuration by DevOps of the site.

So in order to use Jcasc, i have to go and fiddle with a rpm produced file, which may or not may be be updated, when doing an update via yum / rpm. Also i have to go and ask Operations, please, please....

I don't get why here , where it would be really easy, Convention over Configuration is not used. Like for instance a given relative directory within JENKINS_HOME. So DevOps only needs write privileges for that folder.....

Naturally even neater would that the users DevOps could package Jenkins more easily and flexible according to their on site requirements .... https://github.com/jenkinsci/custom-war-packager pointing in the right direction. Which is not a totally different discussion...

But still: keep up with the great work.

[timja]

@chhex, when we ran our instance on linux I found it far easier to set the system property in the sysconfig file than anything else:

https://github.com/jenkinsci/configuration-as-code-plugin/blob/739cc3025da9724f3850ed88602f89ce625d44e9/plugin/src/main/java/io/jenkins/plugins/casc/ConfigurationAsCode.java#L106

Env variables didn't work for me through the packaged RPM either

Help would be welcomed on packaging to deliver a modern systemd unit as well.

[chhex]

@timja So you set the for the JENKINS_JAVA_OPTIONS additionally something like-Dcasc.jenkins.config=/var/lib/jenkins/casc_configs/.
I did a CASC_JENKINS_CONFIG="/var/lib/jenkins/casc_configs"in the same file.
Wouldn't a default be the easiest?. If you don't like the convention you can still configure it.

[jetersen]

The default is $JENKINS_HOME/jenkins.yaml

[jetersen]

1. It is not so much : - Look ma , no hands. But: Damn ma, many hands or even the left hand, doesn't know what the right hand is doing.

I am sorry but we cannot be held responsible for bad packaging on the CentOS repos.
If you want something well supported, try https://github.com/jenkinsci/docker.

[chhex]

@jetersen ok, much noise about nothing ....
But still i would actually prefer a default like $JENKINS_HOME/casc_configs, because then the privileges could be opened for that folder, while maintaining restricted $JENKINS_HOME

[chhex]

@jetersen Who is doing the centos packaging then? Is that not the Jenkins Project https://github.com/jenkinsci/packaging?
And docker works for somethings great, for other not so.... we are running on a vm fleet.

[chhex]

@jetersen @timja All that said: yep , keep up with the great work.
I think this project as also https://github.com/jenkinsci/custom-war-packager have great potential to make things easier for DevOps.

[jetersen]

@jetersen Who is doing the centos packaging then? Is that not the Jenkins Project jenkinsci/packaging?

Perhaps but I am simply a plugin maintainer.

Not going to argue the merit of docker or even custom-war-packager.

[timja]

It is that repo for packaging, no one is working on it (outside of changes required for the release automation project)

But anyone who is on the core team can merge PRs

[chhex]

@timja ok, that explains the state of that repo. It actually doing very valuable things use by many people. and does it good ...but lags somewhat behind the current state of affairs ..... due to missing volunteers. I personally think docker is certainly very valuable, but not the answer to all problems... a more "traditional" approach to packaging is still needed.

[hoshsadiq]

Not sure what the issue is, I'm getting the same on ubuntu (which defaults to /etc/default/jenkins), and it's the same there. CASC doesn't see the CASH_JENKINS_CONFIG. This is likely a Jenkins issue rather than a package maintainer issue. As I double check the same environment that runs the java -jar... command, definitely has access to the correct env var. Something happens inside Jenkins that removes this.

Anyway, I've gone around the issue by using -Dcasc.jenkins.config=/bla/.

[jetersen]

CASC doesn't see the CASH_JENKINS_CONFIG.

Hopefully just a typo? 🤔 Should read CASC_JENKINS_CONFIG

[hoshsadiq]

Heh. Definitely a typo. In my configuration I had copied the env var name