|
Bugzilla – Full Text Bug Listing |
| Summary: | puppet update corrupts /etc/sysconfig/puppet | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 13.1 | Reporter: | Forgotten User 0wt-W6srW9 <forgotten_0wt-W6srW9> |
| Component: | Upgrade Problems | Assignee: | Wolfgang Rosenauer <wolfgang> |
| Status: | RESOLVED FIXED | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Major | ||
| Priority: | P5 - None | CC: | astieger, boris, bwiedemann, darin, forgotten_CFuu6fqdt7, kstreitova, nkrinner, rombert, tbechtold, tchatzimichos |
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | openSUSE 13.1 | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
Can I have the output of `zypper se -s puppet` please? Reverting back to the way the puppet.service file was in the original package is also necessary to get the service running again:
ExecStart=/usr/bin/puppet agent --server=${PUPPET_SERVER} --masterport=${PUPPET_PORT} --logdest=${PUPPET_LOG} $PUPPET_EXTRA_OPTS
This way the variables are apparently expanded at a later date and filled in correctly.
Of course: #> zypper se -s puppet Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository --+---------------+------------+-------------+--------+----------- i | puppet | package | 3.7.3-3.4.1 | x86_64 | Updates v | puppet | package | 3.2.4-3.1.1 | x86_64 | OSS v | puppet | package | 3.7.3-3.4.1 | i586 | Updates v | puppet | package | 3.2.4-3.1.1 | i586 | OSS | puppet | srcpackage | 3.7.3-3.4.1 | noarch | Updates | puppet-server | package | 3.7.3-3.4.1 | x86_64 | Updates | puppet-server | package | 3.2.4-3.1.1 | x86_64 | OSS | puppet-server | package | 3.7.3-3.4.1 | i586 | Updates | puppet-server | package | 3.2.4-3.1.1 | i586 | OSS i | puppet-vim | package | 3.7.3-3.4.1 | noarch | Updates Boris, can you take a look at this one please? I suspect it affects rubygem-puppet in factory as well *** Bug 917111 has been marked as a duplicate of this bug. *** Currently I do not see any way to use this package from an Autoyast perspective. The only option the package accepts is $PUPPET_EXTRA_OPTS trying to provide a server through this like: PUPPET_EXTRA_OPTS="--server puppetserver.example.com" results in Mär 13 14:57:36 hostname puppet[19539]: Error: Could not parse application options: invalid option: --server trying this: PUPPET_EXTRA_OPTS="--server=puppetserver.example.com" results in Mär 13 14:58:45 hostname puppet-agent[19548]: Could not request certificate: getaddrinfo: Name or service not known The only way I have now is to provide a complete puppet.conf through a postinstall script or similar. https://build.opensuse.org/request/show/347154 this is not the best solution, as it will still be broken for non-systemd distros the solution I implemented seems to work for me, let me know otherwise please As the change I proposed in comment#2 is not done, your change does little to resolve the matter. There still is no practical way to provide a server and environment to puppet through autoyast except providing a complete conf file through postinst (which currently is also broken, see bnc#961878). See also comment#6. reopening then I am not really sure what you are proposing tbh. Do you want me to remove the whole %post thing, or a specific part of it? Can you give me a diff or an SR of your solution maybe? I'd recommend taking a look at one of the older puppet specs and applying that method. 1. supply and install a puppet.sysconfig 2. push puppet.sysconfig with the %fillup_and_insserv macro 3. Tweak any init script or service file accordingly I fail to see why this is so difficult, since it's been the standard for managing files under /etc/sysconfig for classical SysV init script and systemd. https://build.opensuse.org/package/show/openSUSE:12.3/puppet Of course. You have to do two things:
a) Provide a sysconfig/puppet or sysconfig/puppetagent file that is like this (as in 12.3):
PUPPET_SERVER=puppet
PUPPET_PORT=8140
PUPPET_LOG=/var/log/puppet/puppet.log
PUPPET_EXTRA_OPTS=""
The reason is that according to "man 5 systemd.exec" for Environment variables:
"Variable expansion is not performed inside the strings, however, specifier expansion is possible. The $ character has no special meaning."
This means that you can _not_ supply environment variables inside the sysconfig file variables.
i.e:
PUPPET_SERVER="$HOSTNAME"
is not possible inside the sysconfig file as the "$HOSTNAME" would not be expanded.
b) change ./system/multi-user.target.wants/puppet.service according to this (reverts back to the state of pre 13.1):
diff -Pdpru ./system/multi-user.target.wants/puppet.service-orig ./system/multi-user.target.wants/puppet.service
--- ./system/multi-user.target.wants/puppet.service-orig 2016-01-29 09:21:24.700647029 +0100
+++ ./system/multi-user.target.wants/puppet.service 2016-01-29 09:22:05.197204045 +0100
@@ -6,7 +6,7 @@ After=basic.target network.target puppet
[Service]
EnvironmentFile=-/etc/sysconfig/puppetagent
EnvironmentFile=-/etc/sysconfig/puppet
-ExecStart=/usr/bin/puppet agent ${PUPPET_EXTRA_OPTS} --no-daemonize
+ExecStart=/usr/bin/puppet agent --server=${PUPPET_SERVER} --masterport=${PUPPET_PORT} --logdest=${PUPPET_LOG} $PUPPET_EXTRA_OPTS
[Install]
WantedBy=multi-user.target
This way the variable content from the sysconfig file is filled into the variables on the commandline at a later date.
Other ways of providing the commandline options have failed me (see comment#6).
Did I forget to mention anything?
Unassigning myself since I don't plan to work on this in the near future. Hi Wolfgang, would you please help to have a look at here? Please feel free to reassign if you are not the right assignee, thank you! Technically I cannot really help but I'm also unsure about the status. Are people here aligned what should happen on a technical level? If so I could pick it up for 13.1 and release an update. But I need technical input and someone testing it. (In reply to Wolfgang Rosenauer from comment #16) > Technically I cannot really help but I'm also unsure about the status. > Are people here aligned what should happen on a technical level? If so I > could pick it up for 13.1 and release an update. But I need technical input > and someone testing it. Please see comment #13. Basically the setup has to revert back to pre-13.1 status to work properly with autoyast/sysconfig. Hello Theo, I see two submissions into maintenance: https://build.opensuse.org/request/show/416026 rubygem-puppet version update 3.8.5 -> 3.8.7, and a fix for this bug. https://build.opensuse.org/request/show/416031 same, plus removal of old gem archive But also rubygem-r10k version update to 1.4.1 to 1.5.1 Is the r10k update required for this maintenance update? Hello Andres, both are wrong. I will resubmit them in a few minutes, with also a proper fix for this bug (the fix that is included there is wrong). this is the correct fix for this bug https://build.opensuse.org/request/show/416729 As soon as the SR gets approved, I'll submit it to factory and 42.1. Feel free to backport it to older versions as well This is an autogenerated message for OBS integration: This bug (916005) was mentioned in https://build.opensuse.org/request/show/416781 42.1 / rubygem-puppet Update released. Resolved fixed. openSUSE-RU-2016:2029-1: An update that has one recommended fix can now be installed. Category: recommended (moderate) Bug References: 916005 CVE References: Sources used: openSUSE Leap 42.1 (src): rubygem-puppet-3.8.7-12.1 This is an autogenerated message for OBS integration: This bug (916005) was mentioned in https://build.opensuse.org/request/show/421383 42.2 / rubygem-puppet This is an autogenerated message for OBS integration: This bug (916005) was mentioned in https://build.opensuse.org/request/show/421786 Factory / rubygem-puppet |
The recent update to puppet (3457) executes this in post: %post # Compatibility with old setups if [ -f /etc/sysconfig/puppet ] && [ -z "`grep 'PUPPET_EXTRA_OPTS="' /etc/sysconfig/puppet | grep ' --server=${PUPPET_SERVER} --masterport=${PUPPET_PORT} --logdest=${PUPPET_LOG}"'`" ]; then echo 'PUPPET_EXTRA_OPTS=" --server=${PUPPET_SERVER} --masterport=${PUPPET_PORT} --logdest=${PUPPET_LOG} ${PUPPET_EXTRA_OPTS}"' >> /etc/sysconfig/puppet fi On systems with an existing PUPPET_EXTRA_OPTS="" in /etc/sysconfig/puppet (also with other options in "" ) this adds a second PUPPET_EXTRA_OPTS line, like this: # You may specify other parameters to the puppet client here # PUPPET_EXTRA_OPTS="" PUPPET_EXTRA_OPTS=" --server=${PUPPET_SERVER} --masterport=${PUPPET_PORT} --logdest=${PUPPET_LOG} ${PUPPET_EXTRA_OPTS}" This disrupts operation on a system where PUPPET_EXTRA_OPTS is already set and used. It also leads to a service running like this: /usr/bin/ruby2.0 /usr/bin/puppet agent --server=${PUPPET_SERVER} --masterport=${PUPPET_PORT} --logdest=${PUPPET_LOG} ${PUPPET_EXTRA_OPTS} --no-daemonize Please note that "man 5 systemd.exec" states for Environment variables: "Variable expansion is not performed inside the strings, however, specifier expansion is possible. The $ character has no special meaning." Therefore the line is not usable in Systemd. Reproducible: Always Solution: remove the %post directive.