puppet master not able to find configdir, how to fix this? - puppet

sudo puppet master --verbose --no-daemonize
When I ran above command
[root#puppetmaster bin]# sudo puppet master --verbose --no-daemonize
/usr/lib/ruby/site_ruby/1.8/puppet/settings.rb:1348:in convert': Error converting value for param 'basemodulepath': Could not find value for $configdir (Puppet::Settings::InterpolationError)
from /usr/lib/ruby/site_ruby/1.8/puppet/settings.rb:1337:ingsub'
from /usr/lib/ruby/site_ruby/1.8/puppet/settings.rb:1337:in convert'
from /usr/lib/ruby/site_ruby/1.8/puppet/settings.rb:1315:ininterpolate'
from /usr/lib/ruby/site_ruby/1.8/puppet/settings.rb:1060:in value'
from /usr/lib/ruby/site_ruby/1.8/puppet/settings.rb:121:in[]'
from /usr/lib/ruby/site_ruby/1.8/puppet.rb:184:in base_context'
from /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:356:inrun'
from /usr/lib/ruby/site_ruby/1.8/puppet/util/command_line.rb:146:in run'
from /usr/lib/ruby/site_ruby/1.8/puppet/util/command_line.rb:92:inexecute'
from /usr/bin/puppet:8
Even I created a environment variable now with $configdir with value /etc/puppet, but still same issue.
Please suggest how to rectify this

Puppet does not ordinarily provide or rely on any "configdir" setting, but it does provide and rely on confdir. Since Puppet is complaining about being able to determine the value of a different parameter, basemodulepath, I infer that,
You are using Puppet 3.8 with directory environments enabled (Ruby 1.8 is not supported in later versions, and basemodulepath is a directory environments thing), and
One of your environment.conf files erroneously specifies a value for its environment's basemodulepath in terms of $configdir instead of $confdir.
Note that Puppet 3.8 is obsolete and unsupported. As I write this, the latest is Puppet 6.12.

Related

Passing global envvar JAVA_HOME to builds through jenkins.war

I administrate a jenkins instance on Linux.
I have been asked to pass a system-wide JAVA_HOME as a global ENV var for jenkins builds (as opposed to just jenkins itself), and I wish to do this through the service/daemon startup script. (Please don't give per-job Jenkinsfile / build pipeline solutions.)
Some plugins like maven-javadoc-plugin apparently require this variable.
(Curiously, this was never before necessary for the existing builds on this jenkins install. Either the used plugins changed, or jenkins did? Since I don't build on this, I can't say which.)
The only way I managed to do make this work for now, is using a fixed string through the GUI at <jenkins-url>/configure under "Global properties > Environment variables".
I understand I can add JDK installations under <jenkins-url>/configureTools/, but this, again, only allows fixed strings, which I can't be bothered to remember correcting on every system update.
What I should be able to do instead, is pass the ENV var to the jenkins service at startup, such as: JAVA_HOME=$(dirname $(dirname $(readlink -f $(which java)))).
jenkins (debian package) in fact brings an /etc/default/jenkins file,
which says you can pass a --javahome=$JAVA_HOME argument; like this:
/usr/bin/java -jar jenkins.war --javahome=/usr/lib/jvm/java-11-openjdk-amd64
However, this seems incorrect and does not work on current jenkins versions. It throws java.lang.IllegalArgumentException: Unrecognized option: --javahome=/usr/lib/jvm/java-11-openjdk-amd64 at winstone.cmdline.CmdLineParser.parse(CmdLineParser.java:52)
Since some other options uses camelCase (like --httpPort), I have also tried --javaHome=$JAVA_HOME instead.
This option is accepted (jenkins doesn't choke on startup), but it also doesn't work, it appears to get ignored?
I didn't manage to figure out if this should be the correct option from the source code either.
Jenkins version: 2.319
Perhaps someone can tell me if this used to work, is a bug, or how to do this if I'm doing it wrong.

Puppet 6.1.0: node.rb missing from installed files?

For testing, I have installed two instances of Ubuntu server 18.04 on VirtualBox. I then installed one with Puppet-server 6.1.0 and one with Puppet-agent 6.1.0, as per the documentation at Puppetlabs for version 6.1. Foreman is not installed.
After registering my agent at the puppetserver and signing the certificate, starting a puppet-run (sudo /opt/puppetlabs/bin/puppet agent --test) fails with the following error:
Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Failed when searching for node puppetagent.fritz.box: Exception while executing '/etc/puppetlabs/puppet/node.rb': Cannot run program "/etc/puppetlabs/puppet/node.rb" (in directory "."): error=2, No such file or directory
I was dumbstruck to find that the script /etc/puppetlabs/puppet/node.rb was indeed missing and was also not included in the packages of puppetserver, puppet-agent or facter (sudo dpkg-query -L ...).
Googling for it, I only found a script of the same name that belonged to Foreman.
The file does also not seem to be present in the puppetserver source-code at github.
Is anyone able to shed some light on this?
Your server configuration seems to be set up to specify use of an external node classifier. This is optional: Puppet does not require an ENC and does not provide one by default. That's part of what makes them "external". If you obtained the result you describe straight out of the box then it probably reflects a packaging flaw that you should report.
In the meantime, you should be able to update the configuration to disable use of an ENC by changing the value of the node_terminus setting to plain. Alternatively, you should be able to just delete both node_terminus and external_nodes from your configuration, because the default for the former is plain.
Tagging on to John's answer, your configuration is probably configured to talk to the Foreman. If you didn't write it yourself or copy it from somewhere and you're sure you don't have any Foreman packages installed, then it's definitely a packaging error that you should report.
That said, puppet repos are almost always the right answer rather than distro packages.

Ansible facter - CentOS - not showing any facter_ variables

I have two boxes:
- CentOS 7.2.x.x vagrant box
and
- Debian/Ubuntu 14.04 trusty vagrant box
On both, I installed Ansible (using their preferred package manager method) and ansible/ansible-playbook commands are working perfectly on both boxes.
On CentOS box, installed Ansible version is:
$ ansible --version
ansible 2.1.2.0
config file = /etc/ansible/ansible.cfg
configured module search path = Default w/o overrides
On Ubuntu box, installed Ansible version is:
ansible 2.2.0.0
On both Ubuntu and CentOS vagrant boxes, When I'm running the following command, it works! i.e. it's spitting out a lot of JSON formatted output hash/values., great:
[vagrant#ip-10-11-12-13 ~/aks/workspace] $ ansible all -m setup -i "`hostname`," --connection=local
Now, as I'm specifically looking for 'facter_someVar' variables (which can give me some meaningful information about the local box), so I tried to grep --> "facter_" word from the output of the previous command.
[vagrant#ip-10-11-12-13 ~/aks/workspace] $ ansible all -m setup -i "`hostname`," --connection=local | grep "facter_"
[vagrant#ip-10-11-12-13 ~/aks/workspace] $
I found that on Ubuntu box, it's showing me a lot of facter_xxxx matching variables (around 71+), but on CentOS box, I'm NOT getting ANY facter_ variable in the output?
I recall, in past, I have used CentOS boxes (vagrant provisioned) and they all showed facter_ variables.
I know there are similar 'ansible_someVar' variables but I'm curious about why facter_xxxxx variables are not showing up here.
OK, I was missing facter package on my other box. The following solved the issue (you may need to get the respective EPEL repo).
sudo yum install facter
Facter is small program that gathers system information such as hardware details, network settings, virtualisation type and kernel/OS information. Seems like Facter was created for Puppet to gather system information (but is also available as a standalone command) so it was not installed for free on the particular vagrant CentOS image I used.

puppet on solaris tries to update vim-enhanced

I have Solaris 10 operating system with puppet agent installed on it.
When I run puppet agent -t I get an Error:
Error: /Stage[main]//Package[vim-enhanced]/ensure: change from absent to latest failed: Could not update: Sun packages must specify a package source
I have no classes regarding updates of vim-enhanced on the master, so where is the error coming from ?
If I do have some classes that I'm not aware of, how do I specify a package source ?
You don't need to any classes, puppet "package" reference solving your problem.
Use this resource:
package {
'vim-enhanced':
ensure => present,
provider => rpm,
source => "puppet:///files/vim-enchanced.rpm";
}
But, only working if you are using puppet default file server!

Simple puppet task fails

I've noted that a simplistic puppet task (an empty file), is failing:
puppet apply init.pp
Results in
Error: Could not run: Could not retrieve facts for xxxxx: no implicit conversion of nil into String
I've changed the init.pp file to an empty file, and the error persists.
Are there any special requirements that puppet 3.4 requires for running puppet standalone deployments?
One simple fix (in the comment above) : Uninstalling puppet modules. But I suspect that there is a "proper" fix to this... so this question is still open.

Resources