Bug 990336

Summary: puppet systemd service file does not respect /etc/sysconfig/puppet
Product: [Fedora] Fedora Reporter: Clayton Louden <dFyD0d4hFT0P>
Component: puppetAssignee: Jeroen van Meeuwen <vanmeeuwen+fedora>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: cfeller, fedora, jose.p.oliveira.oss, k.georgiou, mastahnke, mmagr, moses, ohadlevy, tmz, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-02-17 16:27:48 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Clayton Louden 2013-07-31 01:35:36 UTC
Description of problem:
The options to 'puppet agent' are hard-coded into the systemd service file, therefore puppet always gets started with '/usr/bin/puppet agent --server' regardless of the options set in /etc/sysconfig/puppet (most notably the puppet master server)


Version-Release number of selected component (if applicable):
puppet-3.1.1-4.fc19.noarch

How reproducible:
Always

Steps to Reproduce:
1. systemctl start puppetagent.service
2. change anything in /etc/sysconfig/puppet
3. systemctl restart puppetagent.service
  
Actual results:
The agent is always started with an empty server option.

Expected results:
Depending on the environment variables in /etc/sysconfig/puppet the server should be started respecting those options


Additional info:
This should do

[Service]
EnvironmentFile=-/etc/sysconfig/puppet
Type=forking
PIDFile=/run/puppet/agent.pid
ExecStartPre=/usr/bin/install -d -o puppet -m 755 /run/puppet
ExecStart=/usr/bin/puppet agent --server $PUPPET_SERVER --logdest $PUPPET_LOG $PUPPET_EXTRA_OPTS

Comment 1 Clayton Louden 2013-08-06 20:01:53 UTC
ping?

Comment 2 Todd Zullinger 2013-08-06 21:09:53 UTC
Other than the options for multiple ports, which used to change the servertype to mongrel, there should be little, if anything that should be put into /etc/sysconfig.  All the settings should be in /etc/puppet/puppet.conf these days.  What settings do you want to change in the sysconfig file?

We talked on the upstream list about marking those files as deprecated, but I don't think it's ever happened.

Comment 3 Clayton Louden 2013-08-06 21:42:25 UTC
Well, I don't really care where I configure the service. I just had issues because the default behaviour changed without being documented anywhere. In F17 the client started without touching the default config, while now, you have to at least add "server = puppetmaster" to puppet.conf. It took me quite a while to figure out, why the server specified in /etc/sysconfig wasn't used (it was in F17).

My only criticism is why is there even an option to set the server in /etc/sysconfig when it's never actually used. It just confused me, that's all.

And maybe it's a good idea to include server = puppetmaster to the default puppet.conf so that a kickstart install works out of the box. But that could probaly be done with a puppet client module.

Comment 4 Todd Zullinger 2013-08-06 21:58:06 UTC
No argument that the change should be documented.  I don't use systemd so I never worked on that conversion (I'm dreading it when EL7 comes along).

The default server for puppet has always been puppet.  If you change that to puppetmaster, then the onus is on you to change the configuration (without being misled by the presence of a sysconfig file that is not respected, of course).  I don't believe there is anything there that should be changed in the default install.

Comment 5 Clayton Louden 2013-08-06 22:13:07 UTC
I am sorry that I have to contradict, but the F17 default /etc/sysconfig/puppet looks like this:

# The puppetmaster server
PUPPET_SERVER=puppetmaster

# If you wish to specify the port to connect to do so here
#PUPPET_PORT=8140

# Where to log to. Specify syslog to send log messages to the system log.
PUPPET_LOG=/var/log/puppet/puppet.log

# You may specify other parameters to the puppet client here
PUPPET_EXTRA_OPTS=--runinterval=600

and the init script (/etc/init.d/puppet) uses those settings

[...]
[ -f /etc/sysconfig/puppet ] && . /etc/sysconfig/puppet
lockfile=${LOCKFILE-/var/lock/subsys/puppet}
pidfile=${PIDFILE-/var/run/puppet/agent.pid}
puppetd=${PUPPETD-/usr/sbin/puppetd}
RETVAL=0

# Source function library.
. /etc/rc.d/init.d/functions

PUPPET_OPTS=""
[ -n "${PUPPET_SERVER}" ] && PUPPET_OPTS="--server=${PUPPET_SERVER}"
[ -n "$PUPPET_LOG" ] && PUPPET_OPTS="${PUPPET_OPTS} --logdest=${PUPPET_LOG}"
[ -n "$PUPPET_PORT" ] && PUPPET_OPTS="${PUPPET_OPTS} --masterport=${PUPPET_PORT}"
[...]

So the default server in a vanilla fedora installation was puppetmaster.

Comment 6 Todd Zullinger 2013-08-06 22:35:51 UTC
Hmm, I don't see that for f17.  None of the items in /etc/sysconfig/puppet are uncommented by default, nor is the PUPPET_SERVER set to puppetmaster.  What package are you using?

Here's what I see:

$ rpm -qpi puppet-2.7.21-2.fc17.noarch.rpm 
Name        : puppet
Version     : 2.7.21
Release     : 2.fc17
Architecture: noarch
Install Date: (not installed)
Group       : System Environment/Base
Size        : 3274441
License     : ASL 2.0
Signature   : RSA/SHA256, Thu 21 Mar 2013 12:08:30 PM EDT, Key ID 50e94c991aca3465
Source RPM  : puppet-2.7.21-2.fc17.src.rpm
Build Date  : Wed 20 Mar 2013 10:41:13 AM EDT
Build Host  : buildvm-21.phx2.fedoraproject.org
Relocations : (not relocatable)
Packager    : Fedora Project
Vendor      : Fedora Project
URL         : http://puppetlabs.com
Summary     : A network tool for managing many disparate systems
Description :
Puppet lets you centrally manage every important aspect of your system using a
cross-platform specification language that manages all the separate elements
normally aggregated in different files, like users, cron jobs, and hosts,
along with obviously discrete elements like packages, services, and files.

$ rpm -K puppet-2.7.21-2.fc17.noarch.rpm 
puppet-2.7.21-2.fc17.noarch.rpm: rsa sha1 (md5) pgp md5 OK

$ rpmdev-extract -q puppet-2.7.21-2.fc17.noarch.rpm

$ cat puppet-2.7.21-2.fc17.noarch/etc/sysconfig/puppet 
# The puppetmaster server
#PUPPET_SERVER=puppet

# If you wish to specify the port to connect to do so here
#PUPPET_PORT=8140

# Where to log to. Specify syslog to send log messages to the system log.
#PUPPET_LOG=/var/log/puppet/puppet.log

# You may specify other parameters to the puppet client here
#PUPPET_EXTRA_OPTS=--waitforcert=500

Comment 7 Clayton Louden 2013-08-06 22:37:31 UTC
I should cover my bloody bases before making those kind of statements...

I've just looked it up again, and indeed the the default server was puppet in F17. Sorry.

Comment 8 Fedora End Of Life 2015-01-09 19:11:13 UTC
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 9 Fedora End Of Life 2015-02-17 16:27:48 UTC
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.