[Puppet - Feature #2408] It should be possible to assign a definition to a node in an external nodes tool
Issue #2408 has been updated by Raffael Schmid.
I thought about this when taking a shower this morning. From a sysadmin point
of view, it would be the easiest if we could provide a yaml which looks like:
pre
classes:
common:
apt:
resources:
- add local repo:
type: apt::repo
ensure: present
content: deb localrepo.magpie.lan/ubuntu lucid vendor
- touch restart.txt:
type: exec
user: root
command: touch /var/www/rails/tmp/restart.txt
unless: /var/www/rails/tmp/restart.txt
require:
- file: /var/www/
- file: /var/www/rails
/pre
This would evaluate to something like this:
pre
irb pp YAML.load(File.open(/tmp/l))
{resources=
[{type=apt::repo,
content=deb localrepo.magpie.lan/ubuntu lucid vendor,
ensure=present,
add local repo=nil},
{command=touch /var/www/rails/tmp/restart.txt,
type=exec,
require=[{file=/var/www/}, {file=/var/www/rails}],
unless=/var/www/rails/tmp/restart.txt,
user=root,
touch restart.txt=nil}],
classes={common=nil, apt=nil}}
/pre
Is this something you meant? Or did you mean something else by helping to
define a plan? :)
Feature #2408: It should be possible to assign a definition to a node in an
external nodes tool
https://projects.puppetlabs.com/issues/2408
Author: Pieter Barrezeele
Status: Needs More Information
Priority: High
Assignee:
Category:
Target version: Telly
Affected Puppet version: 0.24.8
Keywords:
Branch:
Until now, only classes/modules and parameters can be assigned to nodes in an
external nodes tool.
It would be very useful to be able to assign a definition, such as:
pre
node ws1 inherits webserver {
apache::vhost{www.example.com}
}
/pre
to a node using yaml. The only other way to do now, seems to be writing wrapper
classes.
Thanks,
Pieter.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[MCollective - Feature #8466] When identities are supplied on the command line, do not do discovery
Issue #8466 has been updated by R.I. Pienaar. Branch set to ripienaar/ticket/master/8466 Ticket has morphed a bit out of initial scope, the mentioned branch includes: * Forced direct requests when enabled in the config and for MC::Message's of type :direct_request * Multiple identity filters in a request are now OR and not AND. AND makes no sense as a host can only have 1 identity * The MC::RPC::Client#discover call can now be given JSON or a list that will override discovery and force direct requests * If identities are provided on the CLI using -i then direct requests are forced and NO discovery is done - significant user facing speedup * The rpc application can now take JSON on its STDIN which will override discovery. Feature #8466: When identities are supplied on the command line, do not do discovery https://projects.puppetlabs.com/issues/8466 Author: R.I. Pienaar Status: Accepted Priority: Normal Assignee: R.I. Pienaar Category: Core Target version: 1.3.x Keywords: Branch: ripienaar/ticket/master/8466 Affected mCollective version: When identities are supplied on the CLI using -I or in filters programmatically and non of them are regex then bypass discovery completely. This will require: * RPC::Client#discover to set @discovered_agents based on options[:filter][identity] * The identity filter to be an OR rather than AND - there's no sense in identity filters being AND anyway as each node has only one identity * TTLs being supported in #8325 A POC of this is in ripienaar/marionette-collective/poc_no_discovery -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[MCollective - Feature #9399] (Accepted) The TTL on message should be adjustable
Issue #9399 has been reported by R.I. Pienaar. Feature #9399: The TTL on message should be adjustable https://projects.puppetlabs.com/issues/9399 Author: R.I. Pienaar Status: Accepted Priority: Normal Assignee: R.I. Pienaar Category: Core Target version: 1.3.x Keywords: Branch: Affected mCollective version: Both the default ttl and ttl on individual messages should be adjustable, it should be accessible from CLI and the API. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[MCollective - Feature #9383] (Accepted) Create an mcollective-client gem
Issue #9383 has been updated by R.I. Pienaar. Category set to Packaging Status changed from Unreviewed to Accepted Feature #9383: Create an mcollective-client gem https://projects.puppetlabs.com/issues/9383 Author: Zachary Stevens Status: Accepted Priority: Normal Assignee: Category: Packaging Target version: Keywords: Branch: Affected mCollective version: When installing mcollective via operating system packages, the ruby library is only available to clients using the system ruby. It should be possible to write client applications using an alternative ruby, while still sharing the configuration and plugins from the system mcollective install. Discussion on #mcollective: zts I'm currently installing mcollective using the RPMs, which was cool until I started needing to write clients that run under a different ruby to the system one zts it feels like what I want is the mcollective client bits as a gem that I can install into different rubies, but I'm prepared to hear that I'm wrong zts what's the best approach to dealing with this requirement? Volcane could potentially do the client stuff as a gem - but not appropriate for the server bits Volcane still leaves the problem of distributing your applications, security plugins etc Volcane since those cant really go into gems easily I'd think zts yeah, I'm happy managing configurations and plugins at the system level, and the behaviour I'd want is for all clients to share the same configuration, plugins etc Volcane nods Volcane yeah a gem for the client isnt a bad idea chrisa2 a client gem would be very useful where you're embedding a client into an app that uses bundler chrisa2 because you can express the dependency in the usual way, rather than relying on a system mcollective, or just vendoring the stuff in the app Volcane make a feature request pls Volcane might be awkward matching up gem versions and plugins etc but i guess everything has some cost -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[MCollective - Feature #9360] (Accepted) Don't exit on exception in MCollective::RPC.rpcclient()
Issue #9360 has been updated by R.I. Pienaar. Category changed from Core to SimpleRPC Status changed from Unreviewed to Accepted Target version set to 1.3.x Feature #9360: Don't exit on exception in MCollective::RPC.rpcclient() https://projects.puppetlabs.com/issues/9360 Author: Ken Simon Status: Accepted Priority: Normal Assignee: Category: SimpleRPC Target version: 1.3.x Keywords: Branch: Affected mCollective version: Using mcollective as a library in a web app, I'd prefer that any Exceptions that happen in rpcclient() get raised normally instead of swallowed and exit()'ed. I've created a fork on github that patches the rpcclient() function to accept an :exit_on_failure option. It's true by default, to preserve previous behavior. I've tested it and it appears to work well. If you'd like, you can merge it (https://github.com/ninkendo/marionette-collective/commit/de3d0d55ecf36de80a266ffcd9a3e82e883d41da) or similar functionality can be written. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[MCollective - Feature #9230] (Duplicate) TTL should be settable per message
Issue #9230 has been updated by R.I. Pienaar. Status changed from Unreviewed to Duplicate #9399 Feature #9230: TTL should be settable per message https://projects.puppetlabs.com/issues/9230 Author: R.I. Pienaar Status: Duplicate Priority: Normal Assignee: Category: Target version: Keywords: Branch: Affected mCollective version: When creating requests - either via the CLI or the API - users should be able to set a specific TTL per request -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #9337] OS X Lion group membership not updated
Issue #9337 has been updated by David Thompson.
On second thought, there is still a bug here. I can't apply the following
class on Lion:
class users_test {
group { 'dt-grp' :
ensure = present,
gid= 1539,
members = [ 'dt' ],
}
user { 'dt' :
ensure = present,
managehome = false,
membership = inclusive,
uid= 1539,
gid= 1539,
shell = '/bin/bash',
home = '/home/dt',
comment= 'David Thompson',
}
}
The user auto-requires the group. The group add fails because the user doesn't
exist, and the user doesn't add because the group dependency had failures.
Would I guess correctly that this is why the group memberships are specified in
the User records (usually)? What's the solution here?
Bug #9337: OS X Lion group membership not updated
https://projects.puppetlabs.com/issues/9337
Author: David Thompson
Status: Closed
Priority: Normal
Assignee: Nigel Kersten
Category: OSX
Target version:
Affected Puppet version: 2.7.3
Keywords: lion
Branch:
Switching to puppet (2.7.3) for managing my OS X Lion systems, I'm finding
group membership not being updated. Couldn't find a dup for this, hope the
information helps...
Starting out, user dt is not a member of group dt-grp:
pre
# dscl . read /groups/dt-grp | grep GroupMembership
GroupMembership:
/pre
...Run puppet, says it adds to the group:
pre
# puppet agent --test --environment production
info: Caching catalog for cypress.keck.waisman.wisc.edu
info: Applying configuration version '1315332406'
notice: /Stage[main]/Users_test/User[dt]/groups: groups changed '' to 'dt-grp'
notice: Finished catalog run in 0.89 seconds
/pre
...but the user still isn't part of the group:
pre
# dscl . read /groups/dt-grp | grep GroupMembership
GroupMembership:
/pre
...Hrm, let's add the user manually...just like the puppet code does...
pre
# dseditgroup -o edit -n . -a dt dt-grp
# dscl . read /groups/dt-grp | grep GroupMembership
GroupMembership: dt
/pre
...But puppet still tries to add the user to the group...
pre
# puppet agent --test --environment production
info: Caching catalog for cypress.keck.waisman.wisc.edu
info: Applying configuration version '1315332406'
notice: /Stage[main]/Users_test/User[dt]/groups: groups changed '' to 'dt-grp'
notice: Finished catalog run in 0.83 seconds
/pre
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[MCollective Plugins - Bug #9212] Results of mc-rpc puppetral actions do not print to terminal
Issue #9212 has been updated by R.I. Pienaar. I believe the recent commits to the ral agent solved this? Can you confirm? Bug #9212: Results of mc-rpc puppetral actions do not print to terminal https://projects.puppetlabs.com/issues/9212 Author: Joshua Lifton Status: Unreviewed Priority: Normal Assignee: Category: Target version: Keywords: Branch: Affected mCollective version: On Ubuntu 11.04 running a Stomp server and using Collective Builder, the results of puppetral actions are not printed to terminal even though the Stomp server logs indicate the results are being returned. Calls to mc-ping print the results correctly. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[MCollective - Feature #8324] (Closed) Add TTL support to messages
Issue #8324 has been updated by R.I. Pienaar. Status changed from Accepted to Closed Superseded by #9400 Feature #8324: Add TTL support to messages https://projects.puppetlabs.com/issues/8324 Author: R.I. Pienaar Status: Closed Priority: Normal Assignee: R.I. Pienaar Category: Core Target version: 1.3.x Keywords: Branch: Affected mCollective version: With queuing we need to add a maximum lifetime to RPC requests to avoid machines getting really old requests past maintenance windows for example. We'd need to add this as a new value in the MC message structures as not all middleware have a concept of TTL on messages. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[MCollective - Feature #7133] (Closed) Get MCollective more sysadmin-friendly
Issue #7133 has been updated by R.I. Pienaar.
Status changed from Unreviewed to Closed
This has all been done:
* the work in #7226 made piping results from one rpc to the next a reality
* discovery is now pluggable, work on a generic set of discovery sources is
planned
* exit statuses have been unified in the mco application framework - though
this is very app specific really. The more appropriate case is to check the
individual statuscodes in replies.
closing
Feature #7133: Get MCollective more sysadmin-friendly
https://projects.puppetlabs.com/issues/7133
Author: Yuri Arabadji
Status: Closed
Priority: Normal
Assignee:
Category:
Target version:
Keywords:
Branch:
Affected mCollective version:
In order to bring MC to sysadmin world, there should be possibility to call it
via various CLI options. For example, a very necessary feature is to have it
iterate over a list of supplied hosts, like -I but OR'ed -- just doing cat
/tmp/hosts | xargs -i{} mc -I {} blah nullifies MQ distributed paradigm that
it implements. Also, there should be possibility to reinvoke it on found
results. That is, we do a process search, for example, get list of hosts, then
supply that list to the next MC command, like kill processes on those hosts,
but only those that match another criteria and so forth.
Another thing to consider is mc's exit status - for example, you're updating
packages and want to know the exit status so you stop your script in case of
any update errors occured on hosts.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #9401] (Unreviewed) pkgdmg.ru can install from .iso images
Issue #9401 has been reported by David Thompson. Feature #9401: pkgdmg.ru can install from .iso images https://projects.puppetlabs.com/issues/9401 Author: David Thompson Status: Unreviewed Priority: Normal Assignee: Category: OSX Target version: Affected Puppet version: 2.7.3 Keywords: pkgdmg OSX package iso Branch: The same code that installs packages from .dmg images can also install from .iso images. The attached patch allows pkgdmg to mount either .dmg or .iso disk images. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[MCollective - Feature #7043] (Closed) filtering on agent version
Issue #7043 has been updated by R.I. Pienaar. Status changed from Needs Decision to Closed This cannot be done, however the new pluggable discovery, json output, pipeable input to the rpc application and a combination of other tools like jgrep makes this totally feasible so I consider this solved closing. Feature #7043: filtering on agent version https://projects.puppetlabs.com/issues/7043 Author: Ken Barber Status: Closed Priority: Normal Assignee: Category: Core Target version: Keywords: Branch: Affected mCollective version: (from training) It would be nice to be able to filter mco commands based on agent revision. This is so we can have a partially upgraded environment and execute commands conditionally in this scenario ... also the interface may have changed and this might be a neat workaround for it. It would also be useful to see the revisions running out in the wild as well. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[MCollective - Feature #6938] (Closed) Clients should be able to specify a specific reply destination in requests
Issue #6938 has been updated by R.I. Pienaar. Status changed from Accepted to Closed This has been done as part of the messaging rework elsewhere Feature #6938: Clients should be able to specify a specific reply destination in requests https://projects.puppetlabs.com/issues/6938 Author: R.I. Pienaar Status: Closed Priority: Normal Assignee: R.I. Pienaar Category: Core Target version: Keywords: Branch: Affected mCollective version: At present replies simply go to collectivename.agent.reply this is not great in cases where many consumers are using mcollective and you have 1000s of machines, users will get each others replies and simply ignore them. We've not used temp topic or unique topics due to bugs in ActiveMQ but these are slowly going away so should start supporting custom reply destinations. This should be a configurable setting that sets it for the whole client but individual requests should just be able to add an optional member int he request hash declaring a response destination. If none is supplied it should work in a backward compat way and this should be the default behavior. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[MCollective - Bug #9402] (Accepted) Remove deprecated mc-* scripts
Issue #9402 has been reported by R.I. Pienaar. Bug #9402: Remove deprecated mc-* scripts https://projects.puppetlabs.com/issues/9402 Author: R.I. Pienaar Status: Accepted Priority: Normal Assignee: R.I. Pienaar Category: Plugins Target version: 1.3.x Keywords: Branch: Affected mCollective version: Most things are now in mco, remove them during 1.3.x with a view on them being completely gone in 1.4.0 -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #9192] service (launchd) provider fails on OS X 10.7 (Lion)
Issue #9192 has been updated by Gary Larizza.
I actually optimized this a bit this morning. I'll have to do another pull and
see if I can get it in there
https://github.com/glarizza/puppet-1/commit/eb515fd4b3c7fccca7483597bda58d04f205db95
Bug #9192: service (launchd) provider fails on OS X 10.7 (Lion)
https://projects.puppetlabs.com/issues/9192
Author: Clay Caviness
Status: In Topic Branch Pending Merge
Priority: Normal
Assignee: Gary Larizza
Category: OSX
Target version: 2.7.x
Affected Puppet version:
Keywords: lion
Branch: https://github.com/glarizza/puppet-1/tree/tickets/2.7.x/9192_launchd_fix
$ sudo puppet apply --debug
service { 'com.company.corp.somejob': ensure = running, enable = true, }
[...]
debug: Puppet::Type::Service::ProviderLaunchd: Executing '/usr/bin/plutil
-convert xml1 -o /dev/stdout
/Library/LaunchDaemons/com.company.corp.somejob.plist'
debug: Service[com.company.corp.somejob](provider=launchd): Executing
'launchctl load /Library/LaunchDaemons/com.company.corp.somejob.plist'
err: /Stage[main]//Service[com.company.corp.somejob]/ensure: change from
stopped to running failed: Unable to start service: com.company.corp.somejob at
path: /Library/LaunchDaemons/com.company.corp.somejob.plist
debug: Finishing transaction 2277069800
debug: Storing state
debug: Stored state in 0.13 seconds
notice: Finished catalog run in 1.27 seconds
Yet another instance where there an OS X version check. Lines 214, 239, and 254
of launchd.rb
(http://projects.puppetlabs.com/projects/puppet/repository/revisions/master/entry/lib/puppet/provider/service/launchd.rb):
if self.class.get_macosx_version_major == 10.6
10.7 _also_ uses the launchd overrides plist.
I'm using Mac OS X 10.7.1, Puppet 2.7.3.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #9337] OS X Lion group membership not updated
Issue #9337 has been updated by Nigel Kersten.
The user won't actually auto-require the group, because we're just setting gid
numerically.
This does kind of suck, but you can solve this like this:
pre
group { 'dt-grp' :
ensure = present,
gid= 1539,
members = [ 'dt' ],
require = User['dt'],
}
user { 'dt' :
ensure = present,
uid= 1539,
gid= 1539,
shell = '/bin/bash',
home = '/home/dt',
comment= 'David Thompson',
}
/pre
We should probably have the mac group provider auto-require any users who are
specified as members.
Note another thing we don't support is the fact OS X can support nested groups,
where groups are members of groups.
There are lots of conceptual problems here, but it does work once you get your
head around it ;)
Bug #9337: OS X Lion group membership not updated
https://projects.puppetlabs.com/issues/9337
Author: David Thompson
Status: Closed
Priority: Normal
Assignee: Nigel Kersten
Category: OSX
Target version:
Affected Puppet version: 2.7.3
Keywords: lion
Branch:
Switching to puppet (2.7.3) for managing my OS X Lion systems, I'm finding
group membership not being updated. Couldn't find a dup for this, hope the
information helps...
Starting out, user dt is not a member of group dt-grp:
pre
# dscl . read /groups/dt-grp | grep GroupMembership
GroupMembership:
/pre
...Run puppet, says it adds to the group:
pre
# puppet agent --test --environment production
info: Caching catalog for cypress.keck.waisman.wisc.edu
info: Applying configuration version '1315332406'
notice: /Stage[main]/Users_test/User[dt]/groups: groups changed '' to 'dt-grp'
notice: Finished catalog run in 0.89 seconds
/pre
...but the user still isn't part of the group:
pre
# dscl . read /groups/dt-grp | grep GroupMembership
GroupMembership:
/pre
...Hrm, let's add the user manually...just like the puppet code does...
pre
# dseditgroup -o edit -n . -a dt dt-grp
# dscl . read /groups/dt-grp | grep GroupMembership
GroupMembership: dt
/pre
...But puppet still tries to add the user to the group...
pre
# puppet agent --test --environment production
info: Caching catalog for cypress.keck.waisman.wisc.edu
info: Applying configuration version '1315332406'
notice: /Stage[main]/Users_test/User[dt]/groups: groups changed '' to 'dt-grp'
notice: Finished catalog run in 0.83 seconds
/pre
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #9401] (Requires CLA to be signed) pkgdmg.ru can install from .iso images
Issue #9401 has been updated by James Turnbull. Status changed from Unreviewed to Requires CLA to be signed Assignee set to David Thompson Hi David - before we can review and merge your patch we need to get you to sign a Contributor License Agreement - see the link in the top right menu. Thanks! Feature #9401: pkgdmg.ru can install from .iso images https://projects.puppetlabs.com/issues/9401 Author: David Thompson Status: Requires CLA to be signed Priority: Normal Assignee: David Thompson Category: OSX Target version: Affected Puppet version: 2.7.3 Keywords: pkgdmg OSX package iso Branch: The same code that installs packages from .dmg images can also install from .iso images. The attached patch allows pkgdmg to mount either .dmg or .iso disk images. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[MCollective - Feature #9403] (Accepted) Release 1.3.1
Issue #9403 has been reported by R.I. Pienaar. Feature #9403: Release 1.3.1 https://projects.puppetlabs.com/issues/9403 Author: R.I. Pienaar Status: Accepted Priority: Normal Assignee: R.I. Pienaar Category: Releases Target version: Keywords: Branch: Affected mCollective version: Release 1.3.1, aiming @ roughly 13/09/2011 -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Facter] 'Wiki' wiki page has been updated
The 'Wiki' wiki page has been updated by Matthaus Litteken. Wiki: https://projects.puppetlabs.com/projects/facter/wiki/Wiki View differences: https://projects.puppetlabs.com/projects/facter/wiki/Wiki/diff/8 -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Facter] 'Wiki' wiki page has been updated
The 'Wiki' wiki page has been updated by Matthaus Litteken. Wiki: https://projects.puppetlabs.com/projects/facter/wiki/Wiki View differences: https://projects.puppetlabs.com/projects/facter/wiki/Wiki/diff/9 -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #9374] (Needs More Information) Hash Members Cannot be Used in Resource Names and Throws Confusing Error
Issue #9374 has been updated by James Turnbull.
Category set to language
Status changed from Unreviewed to Needs More Information
Assignee set to Brice Figureau
Brice - this seems odd? Any ideas?
Bug #9374: Hash Members Cannot be Used in Resource Names and Throws Confusing
Error
https://projects.puppetlabs.com/issues/9374
Author: Brad Krane
Status: Needs More Information
Priority: Normal
Assignee: Brice Figureau
Category: language
Target version:
Affected Puppet version: 2.7.1
Keywords:
Branch:
The following snippet exhibits unexpected behavior.
pre
class foo {
define bar ( $val ) {
notice(bar($val))
}
}
$some_hash = { 'name' = some_name }
foo::bar { $some_hash['name']: }
/pre
The result of this is the very confusing and incorrect error message below:
pre
Puppet::Parser::AST::Resource failed with error ArgumentError: Invalid resource
type foo::bar at puptest.pp:8 on node www-cms-dev
/pre
What makes this especially odd and inconsistent is that the following works as
you would expect:
pre
$some_hash = { 'name' = some_name }
notice($some_hash['name'])
/pre
So, a hash member is treated differently in the two cases contrary to the
principle of least surprise. In the former the member value is not expanded
and passed on to the resource as it's name as you would expect, but it is
expanded in the case of the notice example.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #9382] AIX cron non root user fails
Issue #9382 has been updated by James Turnbull. Description updated Bug #9382: AIX cron non root user fails https://projects.puppetlabs.com/issues/9382 Author: Mike Rawse Status: Unreviewed Priority: Normal Assignee: Category: Target version: Affected Puppet version: Keywords: Branch: Changing crontab entries for non root users on AIX does not work. The problem is that Util.execute sets the effective UID before the UID. This causes the setreuid system call to fail with EPERM because the effective UID is not root when trying to set the uid. Fix is to reverse the calls in Util.execute. pre # diff -c util.rb.orig util.rb *** util.rb.origThu Sep 8 11:40:48 2011 --- util.rb Thu Sep 8 11:43:22 2011 *** *** 312,319 Process.gid = arguments[:gid] unless @@os == Darwin end if arguments[:uid] - Process.euid = arguments[:uid] Process.uid = arguments[:uid] unless @@os == Darwin end ENV['LANG'] = ENV['LC_ALL'] = ENV['LC_MESSAGES'] = ENV['LANGUAGE'] = 'C' if command.is_a?(Array) --- 312,319 Process.gid = arguments[:gid] unless @@os == Darwin end /pre if arguments[:uid] Process.uid = arguments[:uid] unless @@os == Darwin + Process.euid = arguments[:uid] end ENV['LANG'] = ENV['LC_ALL'] = ENV['LC_MESSAGES'] = ENV['LANGUAGE'] = 'C' if command.is_a?(Array) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #9382] (Requires CLA to be signed) AIX cron non root user fails
Issue #9382 has been updated by James Turnbull. Description updated Category set to cron Status changed from Unreviewed to Requires CLA to be signed Assignee set to Mike Rawse Hi Mike - Can I please get you to sign a Contributor License Agreement so we can review and merge your patch? See the link in the top right menu. Also what Puppet version does this patch apply to? Many Thanks Bug #9382: AIX cron non root user fails https://projects.puppetlabs.com/issues/9382 Author: Mike Rawse Status: Requires CLA to be signed Priority: Normal Assignee: Mike Rawse Category: cron Target version: Affected Puppet version: Keywords: Branch: Changing crontab entries for non root users on AIX does not work. The problem is that Util.execute sets the effective UID before the UID. This causes the setreuid system call to fail with EPERM because the effective UID is not root when trying to set the uid. Fix is to reverse the calls in Util.execute. pre # diff -c util.rb.orig util.rb *** util.rb.origThu Sep 8 11:40:48 2011 --- util.rb Thu Sep 8 11:43:22 2011 *** *** 312,319 Process.gid = arguments[:gid] unless @@os == Darwin end if arguments[:uid] - Process.euid = arguments[:uid] Process.uid = arguments[:uid] unless @@os == Darwin end ENV['LANG'] = ENV['LC_ALL'] = ENV['LC_MESSAGES'] = ENV['LANGUAGE'] = 'C' if command.is_a?(Array) --- 312,319 Process.gid = arguments[:gid] unless @@os == Darwin end if arguments[:uid] Process.uid = arguments[:uid] unless @@os == Darwin + Process.euid = arguments[:uid] end ENV['LANG'] = ENV['LC_ALL'] = ENV['LC_MESSAGES'] = ENV['LANGUAGE'] = 'C' if command.is_a?(Array) /pre -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #7999] Add a service provider that manages systemd services
Issue #7999 has been updated by Robin Powell. Is there any version (dev or otherwise) of puppet that has these changes rolled in? Puppet is not reliably managing my Fedora 15 systems because of this (for example, ntpd was not set to start on boot!). -Robin Feature #7999: Add a service provider that manages systemd services https://projects.puppetlabs.com/issues/7999 Author: Jeff Ollie Status: Accepted Priority: Normal Assignee: Category: Target version: Affected Puppet version: Keywords: Branch: systemd is the default system/service manager in Fedora 15 and will likely become the default on other Linux distributions in the future. While systemd provides a compatibility layer that allows the standard redhat Puppet service provider to manage some services on a systemd system, as more services are converted to native systemd services the compatibility layer will become less and less useful. For more information on systemd see: http://www.freedesktop.org/wiki/Software/systemd -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #9051] StoreConfig backend is hard-coded; it should be possible to change to another storage engine.
Issue #9051 has been updated by Daniel Pittman. Nick Lewis wrote: Additional changes merged via pull request #98 in commit:74cffa087aa35d31b331033870b026d41e40cb07. Specifically, the previous changes missed one limitation of the current StoreConfigs code: previously, the Puppet parser would fail while evaluating the AST when you tried to collect exported resources on more than one condition. This is a fairly arbitrary limit that is really only drawn from the current StoreConfigs implementation. So, the changeset moved the limitation out of the parser, and implemented it instead in the terminus. That will fail a bit later in the process, but it will still fail cleanly during compilation if the StoreConfig feature is used in ways that are not supported, and the net effect will be pretty much identical. Feature #9051: StoreConfig backend is hard-coded; it should be possible to change to another storage engine. https://projects.puppetlabs.com/issues/9051 Author: Daniel Pittman Status: Merged - Pending Release Priority: Normal Assignee: Daniel Pittman Category: stored configuration Target version: 2.7.4 Affected Puppet version: 0.22.1 Keywords: Branch: https://github.com/daniel-pittman/puppet/commits/feature/2.7.x/9051-storeconfig-backend-should-be-configurable At the moment the StoreConfig backend is hard-coded within Puppet to use an ActiveRecord based database store. It would be great to be able to easily substitute in a new storage engine without having to patch the core, ideally in the same way you can pick another terminus for the `node` indirection to integrate with your ENC. This needs to provide feature parity with the current feature. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #7999] (In Topic Branch Pending Merge) Add a service provider that manages systemd services
Issue #7999 has been updated by James Turnbull. Category set to service Status changed from Accepted to In Topic Branch Pending Merge Assignee set to Nigel Kersten Priority changed from Normal to High Target version set to 2.7.x Branch set to https://github.com/jcollie/puppet/tree/feature%2Fmaster%2F7999-systemd-services Nigel - think this should go into a 2.7.x release? Feature #7999: Add a service provider that manages systemd services https://projects.puppetlabs.com/issues/7999 Author: Jeff Ollie Status: In Topic Branch Pending Merge Priority: High Assignee: Nigel Kersten Category: service Target version: 2.7.x Affected Puppet version: Keywords: Branch: https://github.com/jcollie/puppet/tree/feature%2Fmaster%2F7999-systemd-services systemd is the default system/service manager in Fedora 15 and will likely become the default on other Linux distributions in the future. While systemd provides a compatibility layer that allows the standard redhat Puppet service provider to manage some services on a systemd system, as more services are converted to native systemd services the compatibility layer will become less and less useful. For more information on systemd see: http://www.freedesktop.org/wiki/Software/systemd -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #2408] It should be possible to assign a definition to a node in an external nodes tool
Issue #2408 has been updated by Nigel Kersten.
No, that's a great start. Would you like to take this to the puppet-users list
for comment?
Although it's possible to put naked resources into site.pp at the top level,
we've generally been moving away from that as a community towards
classes/modules for everything, and this does modify that somewhat.
To be clear, I'm not opposed to this, it fits reasonably well, I just haven't
convinced myself that we've considered all the aspects :)
Feature #2408: It should be possible to assign a definition to a node in an
external nodes tool
https://projects.puppetlabs.com/issues/2408
Author: Pieter Barrezeele
Status: Needs More Information
Priority: High
Assignee:
Category:
Target version: Telly
Affected Puppet version: 0.24.8
Keywords:
Branch:
Until now, only classes/modules and parameters can be assigned to nodes in an
external nodes tool.
It would be very useful to be able to assign a definition, such as:
pre
node ws1 inherits webserver {
apache::vhost{www.example.com}
}
/pre
to a node using yaml. The only other way to do now, seems to be writing wrapper
classes.
Thanks,
Pieter.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Facter - Feature #9404] Add dragonfly bsd
Issue #9404 has been updated by Adrien Thebo. Branch set to https://github.com/puppetlabs/facter/pull/10 Feature #9404: Add dragonfly bsd https://projects.puppetlabs.com/issues/9404 Author: Adrien Thebo Status: Accepted Priority: Normal Assignee: Adrien Thebo Category: library Target version: 1.6.x Keywords: Branch: https://github.com/puppetlabs/facter/pull/10 Affected Facter version: -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #9337] OS X Lion group membership not updated
Issue #9337 has been updated by David Thompson. File puppet-users-mac.pp added I'm getting a dependency cycle when I run this with my full user list: err: Could not apply complete catalog: Found 1 dependency cycle: (Group[dusers] = User[law] = Group[nccamgrp] = User[nondahl] = Group[dusers]) Try the '--graph' option and opening the resulting '.dot' file in OmniGraffle or GraphViz I've attached the whole user list if you really want to try applying it... Bug #9337: OS X Lion group membership not updated https://projects.puppetlabs.com/issues/9337 Author: David Thompson Status: Closed Priority: Normal Assignee: Nigel Kersten Category: OSX Target version: Affected Puppet version: 2.7.3 Keywords: lion Branch: Switching to puppet (2.7.3) for managing my OS X Lion systems, I'm finding group membership not being updated. Couldn't find a dup for this, hope the information helps... Starting out, user dt is not a member of group dt-grp: pre # dscl . read /groups/dt-grp | grep GroupMembership GroupMembership: /pre ...Run puppet, says it adds to the group: pre # puppet agent --test --environment production info: Caching catalog for cypress.keck.waisman.wisc.edu info: Applying configuration version '1315332406' notice: /Stage[main]/Users_test/User[dt]/groups: groups changed '' to 'dt-grp' notice: Finished catalog run in 0.89 seconds /pre ...but the user still isn't part of the group: pre # dscl . read /groups/dt-grp | grep GroupMembership GroupMembership: /pre ...Hrm, let's add the user manually...just like the puppet code does... pre # dseditgroup -o edit -n . -a dt dt-grp # dscl . read /groups/dt-grp | grep GroupMembership GroupMembership: dt /pre ...But puppet still tries to add the user to the group... pre # puppet agent --test --environment production info: Caching catalog for cypress.keck.waisman.wisc.edu info: Applying configuration version '1315332406' notice: /Stage[main]/Users_test/User[dt]/groups: groups changed '' to 'dt-grp' notice: Finished catalog run in 0.83 seconds /pre -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #7141] (Needs More Information) puppetd runs fail in 'daemon' mode when stat'ing /proc files
Issue #7141 has been updated by Daniel Pittman.
Category set to file
Status changed from Investigating to Needs More Information
Target version set to 2.7.x
Affected Puppet version set to 2.6.5
CentOS 5 is a 2.6.18 kernel all the way through; the IO#read bug was only
before 2.6.13, so it shouldn't be the same problem. That said, I can't
trivially reproduce this. Matt, can you confirm which kernel version you are
running on your system? Is this an upgraded CentOS 4 machine still using the
older kernel?
Bug #7141: puppetd runs fail in 'daemon' mode when stat'ing /proc files
https://projects.puppetlabs.com/issues/7141
Author: Matt Wise
Status: Needs More Information
Priority: Normal
Assignee: Ben Hughes
Category: file
Target version: 2.7.x
Affected Puppet version: 2.6.5
Keywords:
Branch:
I accidentally had a tree that Puppet was watching (auditing) with a few files
that pointed to the /proc filesystem. Manual puppet runs worked perfectly, but
background 'daemon' runs would hang. After a bit of stracing, I found that the
hang started as soon as the puppet process tried to look at these /proc
symlinked files. Again, manual puppet runs worked perfectly, but the daemon
background runs are the ones that failed. Removing the symlinks solves the
problem, but this is a bug of some kind.. I'm just not sure where.
OS: CentOS 5.5
Puppet Ver: 2.6.5
pre
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
lstat(/apps/kickstart/rhel55-x64-generic/test/etc/mtab,
{st_mode=S_IFLNK|0777, st_size=12, ...}) = 0
readlink(/apps/kickstart/rhel55-x64-generic/test/etc/mtab, /proc/mounts...,
100) = 12
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
stat(/usr/lib/ruby/site_ruby/1.8/digest/md5.rb, 0x7fffa4070a00) = -1 ENOENT
(No such file or directory)
stat(/usr/lib/ruby/site_ruby/1.8/digest/md5.so, 0x7fffa4070a00) = -1 ENOENT
(No such file or directory)
stat(/usr/lib64/ruby/site_ruby/1.8/digest/md5.rb, 0x7fffa4070a00) = -1 ENOENT
(No such file or directory)
stat(/usr/lib64/ruby/site_ruby/1.8/digest/md5.so, 0x7fffa4070a00) = -1 ENOENT
(No such file or directory)
stat(/usr/lib64/ruby/site_ruby/1.8/x86_64-linux/digest/md5.rb,
0x7fffa4070a00) = -1 ENOENT (No such file or directory)
stat(/usr/lib64/ruby/site_ruby/1.8/x86_64-linux/digest/md5.so,
0x7fffa4070a00) = -1 ENOENT (No such file or directory)
stat(/usr/lib/ruby/site_ruby/digest/md5.rb, 0x7fffa4070a00) = -1 ENOENT (No
such file or directory)
stat(/usr/lib/ruby/site_ruby/digest/md5.so, 0x7fffa4070a00) = -1 ENOENT (No
such file or directory)
stat(/usr/lib64/ruby/site_ruby/digest/md5.rb, 0x7fffa4070a00) = -1 ENOENT (No
such file or directory)
stat(/usr/lib64/ruby/site_ruby/digest/md5.so, 0x7fffa4070a00) = -1 ENOENT (No
such file or directory)
stat(/usr/lib64/site_ruby/1.8/digest/md5.rb, 0x7fffa4070a00) = -1 ENOENT (No
such file or directory)
stat(/usr/lib64/site_ruby/1.8/digest/md5.so, 0x7fffa4070a00) = -1 ENOENT (No
such file or directory)
stat(/usr/lib64/site_ruby/1.8/x86_64-linux/digest/md5.rb, 0x7fffa4070a00) =
-1 ENOENT (No such file or directory)
stat(/usr/lib64/site_ruby/1.8/x86_64-linux/digest/md5.so, 0x7fffa4070a00) =
-1 ENOENT (No such file or directory)
stat(/usr/lib64/site_ruby/digest/md5.rb, 0x7fffa4070a00) = -1 ENOENT (No such
file or directory)
stat(/usr/lib64/site_ruby/digest/md5.so, 0x7fffa4070a00) = -1 ENOENT (No such
file or directory)
stat(/usr/lib/ruby/1.8/digest/md5.rb, 0x7fffa4070a00) = -1 ENOENT (No such
file or directory)
stat(/usr/lib/ruby/1.8/digest/md5.so, 0x7fffa4070a00) = -1 ENOENT (No such
file or directory)
stat(/usr/lib64/ruby/1.8/digest/md5.rb, 0x7fffa4070a00) = -1 ENOENT (No such
file or directory)
stat(/usr/lib64/ruby/1.8/digest/md5.so, 0x7fffa4070a00) = -1 ENOENT (No such
file or directory)
stat(/usr/lib64/ruby/1.8/x86_64-linux/digest/md5.rb, 0x7fffa4070a00) = -1
ENOENT (No such file or directory)
stat(/usr/lib64/ruby/1.8/x86_64-linux/digest/md5.so, {st_mode=S_IFREG|0755,
st_size=8776, ...}) = 0
open(/usr/lib64/ruby/1.8/x86_64-linux/digest/md5.so, O_RDONLY) = 8
close(8)= 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
open(/apps/kickstart/rhel55-x64-generic/test/etc/mtab, O_RDONLY) = 8
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
select(9, [5 8], [], [], {0, 796826}) = 0 (Timeout)
select(9, [5 8], [], [], {0, 0})= 0 (Timeout)
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
select(9, [8], [], [], {0, 0}) = 0 (Timeout)
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)
[Puppet - Bug #7141] puppetd runs fail in 'daemon' mode when stat'ing /proc files
Issue #7141 has been updated by Matt Wise.
definitely running 2.6.18 with cents 5.3-5.6...
Bug #7141: puppetd runs fail in 'daemon' mode when stat'ing /proc files
https://projects.puppetlabs.com/issues/7141
Author: Matt Wise
Status: Needs More Information
Priority: Normal
Assignee: Ben Hughes
Category: file
Target version: 2.7.x
Affected Puppet version: 2.6.5
Keywords:
Branch:
I accidentally had a tree that Puppet was watching (auditing) with a few files
that pointed to the /proc filesystem. Manual puppet runs worked perfectly, but
background 'daemon' runs would hang. After a bit of stracing, I found that the
hang started as soon as the puppet process tried to look at these /proc
symlinked files. Again, manual puppet runs worked perfectly, but the daemon
background runs are the ones that failed. Removing the symlinks solves the
problem, but this is a bug of some kind.. I'm just not sure where.
OS: CentOS 5.5
Puppet Ver: 2.6.5
pre
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
lstat(/apps/kickstart/rhel55-x64-generic/test/etc/mtab,
{st_mode=S_IFLNK|0777, st_size=12, ...}) = 0
readlink(/apps/kickstart/rhel55-x64-generic/test/etc/mtab, /proc/mounts...,
100) = 12
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
stat(/usr/lib/ruby/site_ruby/1.8/digest/md5.rb, 0x7fffa4070a00) = -1 ENOENT
(No such file or directory)
stat(/usr/lib/ruby/site_ruby/1.8/digest/md5.so, 0x7fffa4070a00) = -1 ENOENT
(No such file or directory)
stat(/usr/lib64/ruby/site_ruby/1.8/digest/md5.rb, 0x7fffa4070a00) = -1 ENOENT
(No such file or directory)
stat(/usr/lib64/ruby/site_ruby/1.8/digest/md5.so, 0x7fffa4070a00) = -1 ENOENT
(No such file or directory)
stat(/usr/lib64/ruby/site_ruby/1.8/x86_64-linux/digest/md5.rb,
0x7fffa4070a00) = -1 ENOENT (No such file or directory)
stat(/usr/lib64/ruby/site_ruby/1.8/x86_64-linux/digest/md5.so,
0x7fffa4070a00) = -1 ENOENT (No such file or directory)
stat(/usr/lib/ruby/site_ruby/digest/md5.rb, 0x7fffa4070a00) = -1 ENOENT (No
such file or directory)
stat(/usr/lib/ruby/site_ruby/digest/md5.so, 0x7fffa4070a00) = -1 ENOENT (No
such file or directory)
stat(/usr/lib64/ruby/site_ruby/digest/md5.rb, 0x7fffa4070a00) = -1 ENOENT (No
such file or directory)
stat(/usr/lib64/ruby/site_ruby/digest/md5.so, 0x7fffa4070a00) = -1 ENOENT (No
such file or directory)
stat(/usr/lib64/site_ruby/1.8/digest/md5.rb, 0x7fffa4070a00) = -1 ENOENT (No
such file or directory)
stat(/usr/lib64/site_ruby/1.8/digest/md5.so, 0x7fffa4070a00) = -1 ENOENT (No
such file or directory)
stat(/usr/lib64/site_ruby/1.8/x86_64-linux/digest/md5.rb, 0x7fffa4070a00) =
-1 ENOENT (No such file or directory)
stat(/usr/lib64/site_ruby/1.8/x86_64-linux/digest/md5.so, 0x7fffa4070a00) =
-1 ENOENT (No such file or directory)
stat(/usr/lib64/site_ruby/digest/md5.rb, 0x7fffa4070a00) = -1 ENOENT (No such
file or directory)
stat(/usr/lib64/site_ruby/digest/md5.so, 0x7fffa4070a00) = -1 ENOENT (No such
file or directory)
stat(/usr/lib/ruby/1.8/digest/md5.rb, 0x7fffa4070a00) = -1 ENOENT (No such
file or directory)
stat(/usr/lib/ruby/1.8/digest/md5.so, 0x7fffa4070a00) = -1 ENOENT (No such
file or directory)
stat(/usr/lib64/ruby/1.8/digest/md5.rb, 0x7fffa4070a00) = -1 ENOENT (No such
file or directory)
stat(/usr/lib64/ruby/1.8/digest/md5.so, 0x7fffa4070a00) = -1 ENOENT (No such
file or directory)
stat(/usr/lib64/ruby/1.8/x86_64-linux/digest/md5.rb, 0x7fffa4070a00) = -1
ENOENT (No such file or directory)
stat(/usr/lib64/ruby/1.8/x86_64-linux/digest/md5.so, {st_mode=S_IFREG|0755,
st_size=8776, ...}) = 0
open(/usr/lib64/ruby/1.8/x86_64-linux/digest/md5.so, O_RDONLY) = 8
close(8)= 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
open(/apps/kickstart/rhel55-x64-generic/test/etc/mtab, O_RDONLY) = 8
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
select(9, [5 8], [], [], {0, 796826}) = 0 (Timeout)
select(9, [5 8], [], [], {0, 0})= 0 (Timeout)
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
select(9, [8], [], [], {0, 0}) = 0 (Timeout)
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
select(9, [5 8], [], [], {2, 0})= 0 (Timeout)
select(9, [5 8], [], [], {0, 0})= 0 (Timeout)
select(9, [8], [], [], {0, 0}) = 0 (Timeout)
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
select(9, [5 8], [], [], {1, 99}) = 0 (Timeout)
select(9, [5 8], [], [], {0, 0})= 0 (Timeout)
select(9, [8],
[Puppet Dashboard - Feature #8878] (Merged - Pending Release) Add nodes to group from group property editor
Issue #8878 has been updated by Matthaus Litteken. Status changed from In Topic Branch Pending Merge to Merged - Pending Release Target version set to 1.2.1 Feature #8878: Add nodes to group from group property editor https://projects.puppetlabs.com/issues/8878 Author: Dan Hogland Status: Merged - Pending Release Priority: Normal Assignee: Matt Robinson Category: Target version: 1.2.1 Keywords: Branch: https://github.com/mmrobins/puppet-dashboard/tree/ticket/1.2rc/8878_add_nodes_from_group_page Affected URL: Affected Dashboard version: Manageability and usability does not scale only being able to add a group on a per node basis -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet Dashboard - Feature #8878] (Closed) Add nodes to group from group property editor
Issue #8878 has been updated by Matthaus Litteken. Status changed from Merged - Pending Release to Closed Released in 1.2.1rc1 Feature #8878: Add nodes to group from group property editor https://projects.puppetlabs.com/issues/8878 Author: Dan Hogland Status: Closed Priority: Normal Assignee: Matt Robinson Category: Target version: 1.2.1 Keywords: Branch: https://github.com/mmrobins/puppet-dashboard/tree/ticket/1.2rc/8878_add_nodes_from_group_page Affected URL: Affected Dashboard version: Manageability and usability does not scale only being able to add a group on a per node basis -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet Dashboard - Bug #8803] (Closed) A single report page has a header with too much padding
Issue #8803 has been updated by Matthaus Litteken. Status changed from Merged - Pending Release to Closed Target version changed from 1.3 to 1.2.1 Released in 1.2.1rc1 Bug #8803: A single report page has a header with too much padding https://projects.puppetlabs.com/issues/8803 Author: Randall Hansen Status: Closed Priority: Normal Assignee: Daniel Sauble Category: Target version: 1.2.1 Keywords: Branch: djsauble2:master Affected URL: Affected Dashboard version: This is trivial to fix. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #7999] Add a service provider that manages systemd services
Issue #7999 has been updated by Jeff Ollie. Ooops, I requested the wrong branch be pulled, so I closed the old request and opened up a new one: https://github.com/puppetlabs/puppet/pull/103 Feature #7999: Add a service provider that manages systemd services https://projects.puppetlabs.com/issues/7999 Author: Jeff Ollie Status: In Topic Branch Pending Merge Priority: High Assignee: Nigel Kersten Category: service Target version: 2.7.x Affected Puppet version: Keywords: Branch: https://github.com/jcollie/puppet/tree/feature%2Fmaster%2F7999-systemd-services systemd is the default system/service manager in Fedora 15 and will likely become the default on other Linux distributions in the future. While systemd provides a compatibility layer that allows the standard redhat Puppet service provider to manage some services on a systemd system, as more services are converted to native systemd services the compatibility layer will become less and less useful. For more information on systemd see: http://www.freedesktop.org/wiki/Software/systemd -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #9407] (Accepted) Use platform-appropriate defaults for `:vardir`, etc.
Issue #9407 has been reported by Daniel Pittman. Feature #9407: Use platform-appropriate defaults for `:vardir`, etc. https://projects.puppetlabs.com/issues/9407 Author: Daniel Pittman Status: Accepted Priority: High Assignee: Nigel Kersten Category: usability Target version: Telly Affected Puppet version: 0.25.5 Keywords: Branch: In #3962 we found that Puppet wouldn't start on anything that didn't ship `/var/lib` out of the box, notably OS-X and Solaris. These platforms all have sensible places that, like `/var/lib` on Linux, are where we *should* store our state, databases, etc. We should enhance Puppet so that the default `:vardir`, and every other similar path, is rooted somewhere platform-appropriate. This will fix the underlying cause of #3962, as well as making us a nicer citizen of the various platforms we manage. This is a pretty big usability issues for platforms that are not Linux. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #9388] Agent not respecting environment
Issue #9388 has been updated by Nigel Kersten.
For those of you affected, are you running your master under webrick?
passenger? unicorn? mongrel?
Bug #9388: Agent not respecting environment
https://projects.puppetlabs.com/issues/9388
Author: Cody Robertson
Status: Needs More Information
Priority: Urgent
Assignee: Nigel Kersten
Category:
Target version:
Affected Puppet version: 2.7.1
Keywords: environment
Branch:
I recently upgraded my agents from 2.6.9 to 2.7.1 and it seems to have broke my
environments (not using them). I've posted on the mailing list and have
confirmed to some degree that it was working previously
https://groups.google.com/forum/#!topic/puppet-users/spAGSaUJhfc
Here is the relavent files which seem to work on 2.6.9 (and previous) agents:
puppet.conf
pre
[main]
confdir = /etc/puppet
manifest = $confdir/manifests/site.pp
vardir = /var/lib/puppet
logdir = /var/log/puppet
rundir = /var/run/puppet
ssldir = $vardir/ssl
modulepath = $confdir/modules
[development]
modulepath = $confdir/environments/development/modules
manifest = $confdir/environments/development/manifests/site.pp
[master]
templatedir = /var/lib/puppet/templates
storeconfigs = true
dbadapter = mysql
dbuser = puppet_configs
dbpassword = pass
dbserver = localhost
dbsocket = /var/lib/mysql/mysql.sock
dbname = puppet
reports = log, foreman
pluginsync = true
#external_nodes =
/usr/share/foreman/extras/puppet/foreman/files/external_node.rb
#node_terminus = exec
#reporturl = http://10.8.1.222:3000/reports/upload
facts_terminus = yaml
/pre
environments/development/manifests/site.pp
pre
# site.pp
import modules
import nodes
import ../definitions/*.pp
filebucket { main: server = puppet }
# Defaults
File { backup = main }
Exec { path = /usr/bin:/usr/sbin:/bin:/sbin:/usr/local/bin:/usr/local/sbin }
stage { pre: before = Stage[main] }
Package {
provider = $operatingsystem ? {
centos = yum,
RedHat = yum,
}
}
/pre
When I run the agent with __puppet agent --test --environment development__ it
still is hitting my main __site.pp__ and not the development one and as a
result is trying to send information from the main master environment.
One strange behavior I noticed is as it sends modules from the master
environment it's denying REST calls from the node that usually work (if I don't
specify an environment):
pre
# Only exists in the primary master environment site.pp file
err: /Stage[pre]/Yum-repos/File[epel-gpg]: Failed to generate additional
resources using 'eval_generate: Error 400 on SERVER: Not authorized to call
search on /file_metadata/yum-repos/keys/RPM-GPG-KEY-EPEL with
{:checksum_type=md5, :recurse=true, :links=manage}
/pre
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #6309] (Closed) Mount type should check mount state as well as fstab
Issue #6309 has been updated by Daniel Pittman.
Status changed from Accepted to Closed
The overall decision is that this will be resolved by splitting the mount type
into two parts, one that handles `/etc/fstab` and one that handles mounting
things. This should make it easier to resolve the issue.
Thanks for the report.
Bug #6309: Mount type should check mount state as well as fstab
https://projects.puppetlabs.com/issues/6309
Author: Zach Leslie
Status: Closed
Priority: High
Assignee:
Category: mount
Target version: 2.6.x
Affected Puppet version: 0.25.5
Keywords:
Branch:
When changing the manifest for a mount resource, puppet only checks to see if
fstab is out of sync, and does not actually check the mount status to verify
that its state is what the manifest says it should be. Affected versions are
0.25.5-2.6.4.
Steps to reproduce the issue:
1. mount a nfs filesystem on a host.
2. generate a mount manifest with ralsh mount /mnt, write it to a file (See [1]
Output)
3. pick a different server which should export to the same mountpoint, change
the manifest device= attribute to it
4. cd a login shell into the mountpoint (so 'umount /mnt' fails with mount
point busy)
5. run the manifest once. puppet detects the change (because fstab is out of
sync with the manifest), changes fstab and attempts to sync the mountpoint but
cannot (see [5] output)
6. run the manifest again 'n' times. puppet never re-attempts the mount due to
the mounted? method returning OK. (See [6] Ouput). This is the error. Puppet
should detect that not only is the *fstab* out of sync with the manifest, but
*the actual mounted filesystem* is also out of sync.
pre
[1] Output
[user@srv01 ~]$ ralsh mount /opt/mnt
mount { '/opt/mnt':
pass = '0',
device = 'filer01:/vol/vol01',
ensure = 'mounted',
options = 'rw,hard,proto=tcp',
dump = '0',
target = '/etc/fstab',
fstype = 'nfs'
}
[2] Output - note I changed '01' to '02' (these are the ids of two of our
integration environments)
[user@srv01 /opt/mnt/etc]$ cat ~user/mount.pp
mount { '/opt/mnt':
pass = '0',
device = 'store02:/vol/vol02',
ensure = 'mounted',
options = 'rw,hard,proto=tcp',
dump = '0',
target = '/etc/fstab',
fstype = 'nfs'
}
[5] Output
notice: //Mount[/opt/mnt]/device: device changed 'store01:/vol/vol01' to
'store02:/vol/vol02'
debug: Flushing mount provider target /etc/fstab
debug: Finishing transaction 23456250360860 with 0 changes
info: Filebucket[/var/lib/puppet/clientbucket]: Adding
/etc/fstab(9531774952409006d66ceb78097023)
notice: //Mount[/opt/mnt]: Refreshing self
debug: Puppet::Type::Mount::ProviderParsed: Executing '/bin/mount'
info: Mount[/opt/mnt](provider=parsed): Remounting
debug: Puppet::Type::Mount::ProviderParsed: Executing '/bin/umount /opt/mnt'
err: //Mount[/opt/mnt]: Failed to call refresh on Mount[/opt/mnt]: Execution of
'/bin/umount /opt/mnt' returned 1: umount: /opt/mnt: device is busy
umount: /opt/mnt: device is busy
[6] Output
debug: Prefetching parsed resources for mount
info: Applying configuration version '1297711427'
debug: Puppet::Type::Mount::ProviderParsed: Executing '/bin/mount'
debug: Finishing transaction 23456250586940 with 0 changes
/pre
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #9388] Agent not respecting environment
Issue #9388 has been updated by Florian Koch.
Hi,
mongrel with nginx as loadbalancer frontend
rgds flo
Bug #9388: Agent not respecting environment
https://projects.puppetlabs.com/issues/9388
Author: Cody Robertson
Status: Needs More Information
Priority: Urgent
Assignee: Nigel Kersten
Category:
Target version:
Affected Puppet version: 2.7.1
Keywords: environment
Branch:
I recently upgraded my agents from 2.6.9 to 2.7.1 and it seems to have broke my
environments (not using them). I've posted on the mailing list and have
confirmed to some degree that it was working previously
https://groups.google.com/forum/#!topic/puppet-users/spAGSaUJhfc
Here is the relavent files which seem to work on 2.6.9 (and previous) agents:
puppet.conf
pre
[main]
confdir = /etc/puppet
manifest = $confdir/manifests/site.pp
vardir = /var/lib/puppet
logdir = /var/log/puppet
rundir = /var/run/puppet
ssldir = $vardir/ssl
modulepath = $confdir/modules
[development]
modulepath = $confdir/environments/development/modules
manifest = $confdir/environments/development/manifests/site.pp
[master]
templatedir = /var/lib/puppet/templates
storeconfigs = true
dbadapter = mysql
dbuser = puppet_configs
dbpassword = pass
dbserver = localhost
dbsocket = /var/lib/mysql/mysql.sock
dbname = puppet
reports = log, foreman
pluginsync = true
#external_nodes =
/usr/share/foreman/extras/puppet/foreman/files/external_node.rb
#node_terminus = exec
#reporturl = http://10.8.1.222:3000/reports/upload
facts_terminus = yaml
/pre
environments/development/manifests/site.pp
pre
# site.pp
import modules
import nodes
import ../definitions/*.pp
filebucket { main: server = puppet }
# Defaults
File { backup = main }
Exec { path = /usr/bin:/usr/sbin:/bin:/sbin:/usr/local/bin:/usr/local/sbin }
stage { pre: before = Stage[main] }
Package {
provider = $operatingsystem ? {
centos = yum,
RedHat = yum,
}
}
/pre
When I run the agent with __puppet agent --test --environment development__ it
still is hitting my main __site.pp__ and not the development one and as a
result is trying to send information from the main master environment.
One strange behavior I noticed is as it sends modules from the master
environment it's denying REST calls from the node that usually work (if I don't
specify an environment):
pre
# Only exists in the primary master environment site.pp file
err: /Stage[pre]/Yum-repos/File[epel-gpg]: Failed to generate additional
resources using 'eval_generate: Error 400 on SERVER: Not authorized to call
search on /file_metadata/yum-repos/keys/RPM-GPG-KEY-EPEL with
{:checksum_type=md5, :recurse=true, :links=manage}
/pre
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #6775] (Needs More Information) puppet master --genconfig bug
Issue #6775 has been updated by Daniel Pittman. Status changed from Accepted to Needs More Information Assignee deleted (Matt Robinson) G'day. It isn't entirely clear from the report what the actual issue is here, so we can't be confident of reproducing it so it can be fixed. Valdis, can you give us the content of the configuration files in `/etc/puppet` and `/etc/puppet2` directories, or confirm that they are both empty directories? Can you confirm that your expectation is that the files 1, 2, and 3 are all identical except for the timestamp? If I read correctly that is what you wanted, but it didn't happen, right? Thanks. Bug #6775: puppet master --genconfig bug https://projects.puppetlabs.com/issues/6775 Author: Valdis Vitayaudom Status: Needs More Information Priority: High Assignee: Category: executables Target version: Affected Puppet version: Keywords: Branch: looks like --confdir and --vardir is inconsistent and other variables miss declared default $ puppet master --genconfig --server config1350vm0.dev.orbitz.net 1 $ puppet master --genconfig --server config1350vm0.dev.orbitz.net --vardir /var/lib/puppet --confdir /etc/puppet 3 $ diff 1 3 10c10 # Generated on Fri Mar 18 14:34:08 -0500 2011. --- # Generated on Fri Mar 18 14:34:19 -0500 2011. BUT $ puppet master --genconfig --server config1350vm0.dev.orbitz.net --vardir /var/lib/puppet2 --confdir /etc/puppet2 | sed 's/puppet2/puppet/g' 2 $ diff 1 2 bug.txt 254c254 reports = http, store --- # reports = store 263c263 # bindaddress = --- bindaddress = 0.0.0.0 319c319 masterlog = /var/log/puppet/puppetmaster.log --- masterlog = /var/lib/puppet/log/puppetmaster.log 363c363 pidfile = /var/run/puppet/master.pid --- pidfile = /var/lib/puppet/run/master.pid 371c371 ssldir = /var/lib/puppet/ssl --- ssldir = /etc/puppet/ssl 398c398 privatekeydir = /var/lib/puppet/ssl/private_keys --- privatekeydir = /etc/puppet/ssl/private_keys 407c407 hostcsr = /var/lib/puppet/ssl/csr_config1350vm0.dev.orbitz.net.pem --- hostcsr = /etc/puppet/ssl/csr_config1350vm0.dev.orbitz.net.pem 416c416 hostpubkey = /var/lib/puppet/ssl/public_keys/config1350vm0.dev.orbitz.net.pem --- hostpubkey = /etc/puppet/ssl/public_keys/config1350vm0.dev.orbitz.net.pem 449c449 pluginsync = true --- # pluginsync = false -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #7823] (Closed) Puppet variables in templates are intermittently unset
Issue #7823 has been updated by Daniel Pittman.
Status changed from Needs More Information to Closed
Nigel Kersten wrote:
Jeff, any input? Targeting at 2.7.x unless we discover this is urgent and
critical.
Since we don't have a way to reproduce this, closing. If you can demonstrate
it we are very happy to reopen and resolve the problem.
Bug #7823: Puppet variables in templates are intermittently unset
https://projects.puppetlabs.com/issues/7823
Author: Jeff McCune
Status: Closed
Priority: High
Assignee: Jeff McCune
Category: templates
Target version: 2.7.x
Affected Puppet version: 2.6.7
Keywords: template variable scope unset blank
Branch:
# Impact data #
This affected a large, paying customer today. It is an ongoing issue and I
haven't isolated the root cause or figured out how to reliably reproduce the
issue. It does happen often on their systems, however.
This also appears to be affecting other puppet users as reported on the users
mailing list:
* [Module variables missing during some puppet
runs](http://groups.google.com/group/puppet-users/browse_thread/thread/86cb0dd6c6e074c4/f240c923cac01bf2?lnk=gstq=template#f240c923cac01bf2)
# Overview #
Working with a Puppet 2.6.7 master, I'm noticing templates _sometimes_ do not
provide access to Puppet DSL variables. Consider the following template:
%
enable_pluginsync = scope.lookupvar('enable_pluginsync') || 'true'
puppet_server_real = scope.lookupvar('puppet_server_real') || 'puppet'
puppetversion = scope.lookupvar('::puppetversion')|| '0.24.8'
-%
# Puppet Version: [%= puppetversion %]
% if puppetversion =~ /^0.2/ -%
[puppetd]
% else -%
[agent]
% end -%
ssldir = /etc/puppet/ssl
% if enable_pluginsync then -%
factpath = $libdir
pluginsync = true
% end -%
certname = jeff
server= %= puppet_server_real %
The problem I'm seeing is that _sometimes_ puppetversion is the empty string
(not nill) and as a result the regular expression check fails. This causes the
puppet.conf file to have an agent block rather than a puppetd block and orphans
all 0.24.8 nodes since agent is not a valid configuration section.
# Expected Behavior #
Puppet DSL variables should always be accessible.
# Actual Behavior #
Puppet DSL variables are not always accessible.
# Steps to reproduce #
TBD. I'm currently working on a way to reproduce this in a way I can easily
convey to the RD team. In the meantime, is remote desktop access feasible?
I know this affects 2.6.7 and 2.6.8 has been reported on the puppet-users list.
I'm not sure if earlier versions are affected.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[MCollective - Feature #7133] Get MCollective more sysadmin-friendly
Issue #7133 has been updated by Yuri Arabadji.
Thanks! You are a great man!
Feature #7133: Get MCollective more sysadmin-friendly
https://projects.puppetlabs.com/issues/7133
Author: Yuri Arabadji
Status: Closed
Priority: Normal
Assignee:
Category:
Target version:
Keywords:
Branch:
Affected mCollective version:
In order to bring MC to sysadmin world, there should be possibility to call it
via various CLI options. For example, a very necessary feature is to have it
iterate over a list of supplied hosts, like -I but OR'ed -- just doing cat
/tmp/hosts | xargs -i{} mc -I {} blah nullifies MQ distributed paradigm that
it implements. Also, there should be possibility to reinvoke it on found
results. That is, we do a process search, for example, get list of hosts, then
supply that list to the next MC command, like kill processes on those hosts,
but only those that match another criteria and so forth.
Another thing to consider is mc's exit status - for example, you're updating
packages and want to know the exit status so you stop your script in case of
any update errors occured on hosts.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Cloud-Provisioner - Bug #9408] (Accepted) jenkins test failure - file path expansion issue
Issue #9408 has been reported by Dan Bode.
Bug #9408: jenkins test failure - file path expansion issue
https://projects.puppetlabs.com/issues/9408
Author: Dan Bode
Status: Accepted
Priority: Immediate
Assignee: Dan Bode
Category:
Target version:
Keywords:
Branch:
The jenkins build failed with the following error:
pre
1) Puppet::CloudPack::Installer when searching for file location should be
able to use a lib version
Failure/Error: installer_klass.find_template('puppet-enterprise').should
== File.join(scripts_dir, 'puppet-enterprise.erb')
expected: /home/jenkins/workspace/Cloud Provisioner
Unit/lib/puppet/cloudpack/scripts/puppet-enterprise.erb
got: /home/jenkins/workspace/Cloud Provisioner
Unit/spec/../lib/puppet/cloudpack/scripts/puppet-enterprise.erb (using ==)
# ./spec/unit/puppet/cloudpack/installer_spec.rb:32
pre
The problem is that the spec_helper is messing with the load path which causes
__FILE__ to return a relative path.
The best fix is just to update the test to expand_path.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet Dashboard - Bug #9409] (Unreviewed) DJ doesn't work in a multi-server environment
Issue #9409 has been reported by Andrew Forgue. Bug #9409: DJ doesn't work in a multi-server environment https://projects.puppetlabs.com/issues/9409 Author: Andrew Forgue Status: Unreviewed Priority: Normal Assignee: Category: Target version: Keywords: Branch: Affected URL: Affected Dashboard version: We are testing dashboard 1.2 and notice that it's use of delayed_jobs isn't bound to any node, therefore, if the YAML report isn't on the server that happened to start processing the job, the YAML file can't be found. There are 2 ways to rectify this: 1 - put the spool directory on NFS. I'd rather not introduce network dependency since if NFS goes away my reports are lost. 2 - Configure DJ to only process the import when the DJ detects the file, or on the same node that the job was scheduled. What is PuppetLabs desired action? This kind of seriously limits the scalability of the dashboard since now the spool directory must be shared among all the nodes. One server isn't enough to handle our load. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet Dashboard - Bug #9409] DJ doesn't work in a multi-server environment
Issue #9409 has been updated by Andrew Forgue. Affected Dashboard version set to 1.2.0 Bug #9409: DJ doesn't work in a multi-server environment https://projects.puppetlabs.com/issues/9409 Author: Andrew Forgue Status: Unreviewed Priority: Normal Assignee: Category: Target version: Keywords: Branch: Affected URL: Affected Dashboard version: 1.2.0 We are testing dashboard 1.2 and notice that it's use of delayed_jobs isn't bound to any node, therefore, if the YAML report isn't on the server that happened to start processing the job, the YAML file can't be found. There are 2 ways to rectify this: 1 - put the spool directory on NFS. I'd rather not introduce network dependency since if NFS goes away my reports are lost. 2 - Configure DJ to only process the import when the DJ detects the file, or on the same node that the job was scheduled. What is PuppetLabs desired action? This kind of seriously limits the scalability of the dashboard since now the spool directory must be shared among all the nodes. One server isn't enough to handle our load. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #2408] (Accepted) It should be possible to assign a definition to a node in an external nodes tool
Issue #2408 has been updated by Nigel Kersten.
Status changed from Needs More Information to Accepted
Assignee set to Nigel Kersten
I'm convinced. I'd still like to see some discussion on the user list about
this though.
Feature #2408: It should be possible to assign a definition to a node in an
external nodes tool
https://projects.puppetlabs.com/issues/2408
Author: Pieter Barrezeele
Status: Accepted
Priority: High
Assignee: Nigel Kersten
Category:
Target version: Telly
Affected Puppet version: 0.24.8
Keywords:
Branch:
Until now, only classes/modules and parameters can be assigned to nodes in an
external nodes tool.
It would be very useful to be able to assign a definition, such as:
pre
node ws1 inherits webserver {
apache::vhost{www.example.com}
}
/pre
to a node using yaml. The only other way to do now, seems to be writing wrapper
classes.
Thanks,
Pieter.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Facter - Feature #2157] External fact support in /etc/facter.d
Issue #2157 has been updated by Ken Barber. Okay - so I've made paths configurable on the command line now, and I'm dealing with automatically working them out depending on the OS. The remaining tasks are largely: * Dealing with creation of external script dir during installation. * Handling of TypeError as per Nigel's comments above. * Updating documentation on docs.puppetlabs.com. Not counting more general testing/bugfixing. Feature #2157: External fact support in /etc/facter.d https://projects.puppetlabs.com/issues/2157 Author: Paul Nasrat Status: In Topic Branch Pending Merge Priority: Normal Assignee: Ken Barber Category: Target version: 2.0.0 Keywords: Branch: kbarber/tickets/master/2157-external_fact_support Affected Facter version: Facter should support non-ruby facts, preferably in /etc/facter.d. It should support these facts being either executable, in which case the result is the value of the named fact, or in a data format such as yaml, in which case the data file is read in and interpreted as the fact value. It probably makes sense to initially stick to yaml for data formats, since json doesn't ship with ruby, and to also allow executable facts to return either a plain string or yaml. Note that we can do this without supporting any kind of overriding, but it'd be much better if we supported multiple (configurable?) fact directories, with a search path. Thus, if Facter shipped with /etc/facter.d/myfactname and you wanted to override it, you could do so by creating a new file and putting it in a higher-priority location rather than editing a file distributed with the core. Given we're adding structured data support, namespaced facts would be supported with directory structures; e.g., /etc/facter.d/my/fact/name would resolve to my::fact::name. Ideally, the long-term direction here would be not to require any pure-ruby facts, such that the Facter library could be rewritten in any other language and it would function the same, because all of its actual data is outside of ruby. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #2744] (In Topic Branch Pending Merge) Provide an option to send back diff of txt files in reports
Issue #2744 has been updated by Daniel Pittman. Status changed from Accepted to In Topic Branch Pending Merge There were a handful more changes, to ensure that all our diff printing went to the right destination, but the heart of this was right: https://github.com/puppetlabs/puppet/pull/104 Now, the logs will all get a copy of the diff, which includes syslog when configured - but, generally, showing diffs is not enabled, so this shouldn't result in substantial log spam, etc, for people. Feature #2744: Provide an option to send back diff of txt files in reports https://projects.puppetlabs.com/issues/2744 Author: Yimin Li Status: In Topic Branch Pending Merge Priority: Normal Assignee: Category: Target version: Telly Affected Puppet version: 0.24.8 Keywords: Branch: When a txt file get replaced, only md5 of the new file is sent back to server. If there is an option that can be enabled to send back diff between new file and old file, then you can know what get changes in the reports/mails. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #2896] `puppet parser validate` does not check resource parameters
Issue #2896 has been updated by Daniel Pittman.
Subject changed from --parseonly does not check resource parameters to `puppet
parser validate` does not check resource parameters
Description updated
The specific functionality, `--parseonly`, has been deprecated in favour of
`puppet parser validate`, but the underlying issue remains.
The actual challenge is that we really need almost an entire parser run to
achieve the second half (defined types), and for the user to supply *all* the
data the compiler would have.
Just doing parameter checking for known types would almost be easy, except that
same issue applies when custom types and providers come on the scene.
Feature #2896: `puppet parser validate` does not check resource parameters
https://projects.puppetlabs.com/issues/2896
Author: Dan Bode
Status: Accepted
Priority: Normal
Assignee:
Category: parser
Target version: 2.7.x
Affected Puppet version: 0.25.1
Keywords:
Branch:
#puppet --parseonly
does not show an error when parsing:
file{'name': bad_owner = 'invalid'}
This should also work for resource definitions.
my_def($param_a='_UNSET_') {}
my_def{
'my_def_1':
pram_a = 'foo';
}
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #3910] Server is not authoritative over client environment when specified in an ENC
Issue #3910 has been updated by Nigel Kersten.
+1
Bug #3910: Server is not authoritative over client environment when specified
in an ENC
https://projects.puppetlabs.com/issues/3910
Author: Nigel Kersten
Status: Accepted
Priority: High
Assignee: Nick Lewis
Category: plumbing
Target version: 2.7.x
Affected Puppet version: 0.25.4
Keywords:
Branch:
See:
http://groups.google.com/group/puppet-dev/browse_thread/thread/b609965e377392ec
To summarize, when the client specifies one environment and the classifier
specifies another, classes are evaluated from the server-specified environment,
and yet files are retrieved from the client-specified environment.
3 environments defined, each with a single class base.
*/etc/puppet/puppet.conf*
pre
...snip...
[one]
modulepath = /etc/puppet/environments/one/modules
[two]
modulepath = /etc/puppet/environments/two/modules
[three]
modulepath = /etc/puppet/environments/three/modules
/pre
*/etc/puppet/environments/one/modules/base/manifests/init.pp*
pre
class base {
notify { hardwired one: }
notify { variable $environment: }
file { /tmp/environment_test:
source = puppet:///base/tester,
}
}
/pre
*/etc/puppet/environments/two/modules/base/manifests/init.pp*
pre
class base {
notify { hardwired two: }
notify { variable $environment: }
file { /tmp/environment_test:
source = puppet:///base/tester,
}
}
/pre
*/etc/puppet/environments/three/modules/base/manifests/init.pp*
pre
class base {
notify { hardwired three: }
notify { variable $environment: }
file { /tmp/environment_test:
source = puppet:///base/tester,
}
}
/pre
pre
$ cat /etc/puppet/environments/{one,two,three}/modules/base/files/tester
one
two
three
/pre
Right? So we have two notify resources and a file resource.
- The hardwired notify is to illustrate which class is being loaded.
- The variable notify is to illustrate what $environment evaluates to
in the manifests.
- The file source is to illustrate which file is being sourced.
I also have an external node classifier that always returns this:
pre
---
classes:
- base
environment: one
/pre
So our classifier always includes base, and always sets the environment.
I then invoke a puppet run on a client, specifying the environment to be
*different* to the classifier.
Between all of these runs I delete cached client yaml info on the server.
(find /var/puppet/yaml -type f -delete)
pre
# puppetd -t --environment two
notice: hardwired one
notice: //base/Notify[hardwired one]/message: defined 'message' as
'hardwired one'
notice: variable two
notice: //base/Notify[variable two]/message: defined 'message' as 'variable
two'
notice: Finished catalog run in 0.18 seconds
# cat /tmp/environment_test
two
/pre
*So we have the class being evaluated in environment one, but the file
being sourced coming from environment two ! *And less importantly,
$environment evaluates to two.
*
*
Now, to throw the big spanner in the works we try not specifying an
environment at all.
pre
# puppetd -t
notice: hardwired one
notice: //base/Notify[hardwired one]/message: defined 'message' as
'hardwired one'
notice: variable production
notice: //base/Notify[variable production]/message: defined 'message' as
'variable production'
err: //base/File[/tmp/environment_test]: Failed to retrieve current state of
resource: Error 400 on SERVER: Not authorized to call find on
/file_metadata/base/tester Could not retrieve file metadata for
puppet:///base/tester: Error 400 on SERVER: Not authorized to call find on
/file_metadata/base/tester at
/etc/puppet/environments/one/modules/base/manifests/init.pp:6
notice: Finished catalog run in 0.08 seconds
/pre
As we don't have an environment production defined at all, the server
tries to read the metadata from a non-existent environment and fails.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #3806] Atomic Puppet
Issue #3806 has been updated by Daniel Pittman. Luke Kanies wrote: We would basically have to record the entire set of event queues, and only empty them when the service is restarted or whatever. This does play nicely into our goal of supporting more asynchrony, with direct integration into something like AMQP, but it's still a ways away, I think. On review, we concur with this: this is a highly desirable outcome, and Puppet should be able to work nicely even if interrupted. We don't really want to invent the wheel of keeping this persistent state ourselves, though, and given we have a strategy that would attach Puppet to an existing, persistent queue (eg: AMQP asynchronous Puppet, or whatever), better to hold off action until then. Feature #3806: Atomic Puppet https://projects.puppetlabs.com/issues/3806 Author: Trevor Vaughan Status: Accepted Priority: Normal Assignee: Category: transactions Target version: Affected Puppet version: Keywords: atomic transactions Branch: Per the mailing list: I thought I'd toss this idea out here to get pointed and laughed at before I Redmine'd it. I ran into the fun situation recently where I needed puppet to be more atomic. Basically: (A) Update file - (B) Restart Service But...for some reason puppet got interrupted precisely between A and B! So, the next time puppet ran, my system wasn't in the state that I had described, instead the file had been updated but the service had not been triggered. This got me thinking about the concept of atomic puppet updates. It shouldn't be too difficult to write to disk/register the state of the operations as they happen and to be able to pick back up by default if a run is interrupted. I say this, of course, completely tongue-in-cheek as the last graph discussion I jumped into went on for tons of messages! -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #4067] Automatic dependency resolution for package managers.
Issue #4067 has been updated by Daniel Pittman.
The actual problem applies to a broader field than just packages, though they
are fairly commonly the cause of this, in that the content of recursive file
operations, tidy operations, and some other types and providers that have
internal dependency information do the same thing. Finally, this is already
done for arbitrary types using the autorequire mechanism, on the client side.
In view of that, just integrating the data is pretty fine, although it SHOULD
be done together with getting the final graph back up to the master in the
report, so that users have some visibility of the whole process.
All in all, still valuable, and absolutely to be done, but not presently
scheduled.
Feature #4067: Automatic dependency resolution for package managers.
https://projects.puppetlabs.com/issues/4067
Author: Trevor Vaughan
Status: Accepted
Priority: Normal
Assignee:
Category: package
Target version: Telly
Affected Puppet version: development
Keywords: package, auto-generation, graph
Branch:
Various parties have indicated that they would like Puppet to seamlessly
integrate with the relevant package manager's dependency resolution ability if
possible.
Situation: If you have RPMs A and B, where B depends on A and Puppet objects
that depend on one, or more, of the RPMs, then Puppet should automatically add
relevant ordering objects to properly order the RPM dependencies.
Example:
RPM A
RPM B
B - A
package { B:
ensure = 'latest'
}
file { foo:
require = Package['B']
}
Should this manifest be activated, Puppet should automatically, generate an
internal dependency from B to A and insert it into the dependency graph.
This is an obviously contrived example, but there are situations where you
would want this type of thing to happen for more complex scenarios.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #4067] Automatic dependency resolution for package managers.
Issue #4067 has been updated by Nigel Kersten.
Target version deleted (Telly)
In light of the above comments and lack of a concrete proposal, this won't make
it for Telly.
Feature #4067: Automatic dependency resolution for package managers.
https://projects.puppetlabs.com/issues/4067
Author: Trevor Vaughan
Status: Accepted
Priority: Normal
Assignee:
Category: package
Target version:
Affected Puppet version: development
Keywords: package, auto-generation, graph
Branch:
Various parties have indicated that they would like Puppet to seamlessly
integrate with the relevant package manager's dependency resolution ability if
possible.
Situation: If you have RPMs A and B, where B depends on A and Puppet objects
that depend on one, or more, of the RPMs, then Puppet should automatically add
relevant ordering objects to properly order the RPM dependencies.
Example:
RPM A
RPM B
B - A
package { B:
ensure = 'latest'
}
file { foo:
require = Package['B']
}
Should this manifest be activated, Puppet should automatically, generate an
internal dependency from B to A and insert it into the dependency graph.
This is an obviously contrived example, but there are situations where you
would want this type of thing to happen for more complex scenarios.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #5789] launchd provider parses all plists twice, and uses too much CPU
Issue #5789 has been updated by Daniel Pittman. We should investigate this now that the plist binary format is documented and public, to see if the performance issues can be resolved by directly reading the content and all. Bug #5789: launchd provider parses all plists twice, and uses too much CPU https://projects.puppetlabs.com/issues/5789 Author: Nigel Kersten Status: Accepted Priority: Normal Assignee: Category: provider Target version: Affected Puppet version: Keywords: mac launchd service provider Branch: We shouldn't be parsing everything twice, and it appears that piping to /dev/stdout is particularly slow on OS X. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #9410] (Unreviewed) yumrepo type does notice changes
Issue #9410 has been reported by Jascha Lee.
Bug #9410: yumrepo type does notice changes
https://projects.puppetlabs.com/issues/9410
Author: Jascha Lee
Status: Unreviewed
Priority: Normal
Assignee: James Turnbull
Category: yumrepo
Target version:
Affected Puppet version: 2.6.6
Keywords:
Branch:
If the yum repo config file changes or disappears after the initial puppet run
in which it was created or modified, subsequent puppet runs will not notice.
The local change will remain (inconsistent with the catalog) and/or the removed
file will not be reconstructed.
It was suggested that indentation of multiple gpgkey values might be at play,
but this happens even with a single gpgkey value.
class yum {
yumrepo {
tivo-coxrtltivoqa2sp01.tivo.com:
descr= TiVo repo coxrtltivoqa2sp01.tivo.com,
baseurl = http://$yumvar_reponame/yum/rpms;,
gpgkey = http://$yumvar_reponame/yum/GPG/RPM-GPG-KEY-MySQL;,
gpgcheck = 1,
enabled = 1;
}
}
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #5981] Puppet shouldn't overwrite symlinks when specifying content and follow is on.
Issue #5981 has been updated by Daniel Pittman.
Nigel, is this still a legitimate issue? Your last update changed the target
version, so I assume you have some unrecorded knowledge about it?
Bug #5981: Puppet shouldn't overwrite symlinks when specifying content and
follow is on.
https://projects.puppetlabs.com/issues/5981
Author: Nigel Kersten
Status: Needs More Information
Priority: Normal
Assignee: Nigel Kersten
Category:
Target version: 2.7.x
Affected Puppet version:
Keywords:
Branch:
Illustration of the issue:
pre
kripke:~ nbk$ echo target /tmp/target
kripke:~ nbk$ ln -s /tmp/target /tmp/symlink
kripke:~ nbk$ ls -l /tmp/target /tmp/symlink
lrwxr-xr-x 1 nbk wheel 11 Jan 23 14:43 /tmp/symlink - /tmp/target
-rw-r--r-- 1 nbk wheel 7 Jan 23 14:43 /tmp/target
/pre
pre
kripke:~ nbk$ puppet --version
2.6.4
kripke:~ nbk$ cat /tmp/test.pp
file { /tmp/symlink:
ensure = present,
backup = false,
links = follow,
content = content,
}
kripke:~ nbk$ puppet apply -v /tmp/test.pp
info: Applying configuration version '1295823089'
notice: /Stage[main]//File[/tmp/symlink]/content: content changed
'{md5}80fb1dd0b20823f1d83e10d25840e2e4' to
'{md5}9a0364b9e99bb480dd25e1f0284c8555'
kripke:~ nbk$ ls -la /tmp/target /tmp/symlink
-rw-r--r-- 1 nbk wheel 7 Jan 23 14:51 /tmp/symlink
-rw-r--r-- 1 nbk wheel 7 Jan 23 14:47 /tmp/target
/pre
So even though we're not managing the symlink, and we've only got ensure set to
present, and we have links set to follow, Puppet overwrites the symlink with
the contents, rather than the target.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Cloud-Provisioner - Bug #9408] (Merged - Pending Release) jenkins test failure - file path expansion issue
Issue #9408 has been updated by Dan Bode.
Status changed from Accepted to Merged - Pending Release
merged in commit: c4395ce
Bug #9408: jenkins test failure - file path expansion issue
https://projects.puppetlabs.com/issues/9408
Author: Dan Bode
Status: Merged - Pending Release
Priority: Immediate
Assignee: Dan Bode
Category:
Target version:
Keywords:
Branch:
The jenkins build failed with the following error:
pre
1) Puppet::CloudPack::Installer when searching for file location should be
able to use a lib version
Failure/Error: installer_klass.find_template('puppet-enterprise').should
== File.join(scripts_dir, 'puppet-enterprise.erb')
expected: /home/jenkins/workspace/Cloud Provisioner
Unit/lib/puppet/cloudpack/scripts/puppet-enterprise.erb
got: /home/jenkins/workspace/Cloud Provisioner
Unit/spec/../lib/puppet/cloudpack/scripts/puppet-enterprise.erb (using ==)
# ./spec/unit/puppet/cloudpack/installer_spec.rb:32
pre
The problem is that the spec_helper is messing with the load path which causes
__FILE__ to return a relative path.
The best fix is just to update the test to expand_path.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #8492] (Needs Decision) Template function does not accept array variables
Issue #8492 has been updated by Daniel Pittman.
Status changed from Accepted to Needs Decision
Assignee changed from Matt Robinson to Nigel Kersten
Nigel Kersten wrote:
template currently takes a comma separated list instead of an array.
Rather than digging our hole any deeper here with the differences between
file/content/source, we need to be making these things consistent as per #5158
Nigel, we would like to consider this, but it isn't clear from either this
ticket, or #5158, what the expected unification is. Can we get that clarified
in both tickets, so that we can consider scheduling this? Otherwise it will
just remain stuck here. :(
Feature #8492: Template function does not accept array variables
https://projects.puppetlabs.com/issues/8492
Author: James Turnbull
Status: Needs Decision
Priority: Normal
Assignee: Nigel Kersten
Category: functions
Target version:
Affected Puppet version: 2.6.8
Keywords:
Branch:
pre
class foo {
$b = [/path/to/erbfile1,/path/to/erbfile2,/path/to/erbfile3]
file { /foo.txt:
owner = 'root',
group = 'root',
mode = 644,
content = template($b),
}
/pre
Results in:
pre
# puppet apply -d -v foo.pp
debug: Scope(Class[Foo]): Retrieving template abc
can't convert Array into String at /root/test/foo.pp:8 on node
hostname.example.com
/pre
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet Dashboard - Feature #3534] Dashboard should support ability to set variables as arrays in the ENC
Issue #3534 has been updated by Daniel Pittman. The ENC probably also needs maps added at the same time. The UI and communication paths should be approximately the same for handling both, I expect, at least at the YAML level. Feature #3534: Dashboard should support ability to set variables as arrays in the ENC https://projects.puppetlabs.com/issues/3534 Author: Stefan Goethals Status: Accepted Priority: Normal Assignee: Category: Target version: Keywords: Branch: Affected URL: Affected Dashboard version: **New description:** When editing a node, you can add arbitrary key/value pairs as parameters. Currently the value is treated as a string. We need: * syntax for array values, * correct reading/writing of array values. **Original description:** When assigning a parameter on a node as an array, the external node tool returns it, escaped, as a string, pre # /usr/local/puppet-dashboard/bin/external_node node --- name: node parameters: arraytest: [ \one\, \two\ ] classes: - puppet::server ... /pre -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #9337] (Investigating) OS X Lion group membership not updated
Issue #9337 has been updated by Nigel Kersten. Status changed from Closed to Investigating Priority changed from Normal to High Keywords deleted (lion) Argh. This is why you're having that problem... https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type/user.rb#L17 **Autorequires:** If Puppet is managing the user's primary group (as provided in the `gid` attribute), the user resource will autorequire that group. If Puppet is managing any role accounts corresponding to the user's roles, the user resource will autorequire those role accounts. This clearly isn't ideal for a world where group membership is defined by the group... Bug #9337: OS X Lion group membership not updated https://projects.puppetlabs.com/issues/9337 Author: David Thompson Status: Investigating Priority: High Assignee: Nigel Kersten Category: OSX Target version: Affected Puppet version: 2.7.3 Keywords: Branch: Switching to puppet (2.7.3) for managing my OS X Lion systems, I'm finding group membership not being updated. Couldn't find a dup for this, hope the information helps... Starting out, user dt is not a member of group dt-grp: pre # dscl . read /groups/dt-grp | grep GroupMembership GroupMembership: /pre ...Run puppet, says it adds to the group: pre # puppet agent --test --environment production info: Caching catalog for cypress.keck.waisman.wisc.edu info: Applying configuration version '1315332406' notice: /Stage[main]/Users_test/User[dt]/groups: groups changed '' to 'dt-grp' notice: Finished catalog run in 0.89 seconds /pre ...but the user still isn't part of the group: pre # dscl . read /groups/dt-grp | grep GroupMembership GroupMembership: /pre ...Hrm, let's add the user manually...just like the puppet code does... pre # dseditgroup -o edit -n . -a dt dt-grp # dscl . read /groups/dt-grp | grep GroupMembership GroupMembership: dt /pre ...But puppet still tries to add the user to the group... pre # puppet agent --test --environment production info: Caching catalog for cypress.keck.waisman.wisc.edu info: Applying configuration version '1315332406' notice: /Stage[main]/Users_test/User[dt]/groups: groups changed '' to 'dt-grp' notice: Finished catalog run in 0.83 seconds /pre -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #6808] (Needs Decision) Provide informative message when ensure = present, *and* managing content/source, and target is a symlink
Issue #6808 has been updated by Daniel Pittman.
Status changed from Accepted to Needs Decision
Assignee set to Nigel Kersten
Nigel, can you classify the severity of this:
A debug message, useful when someone investigates to figure it out?
A notice, which will show up normally, but be strange.
A warning on the client side, but carry on?
An error on the client side (or, correctly, during compilation) if both of
those are specified?
I lean heavily to the last; in the huge matrix of things you can tell `file` to
do, this one is invalid, and can be detected, so let us just fail the thing
honestly and make the user fix it.
Finally, if we do that, where should we target this? 2.6, 2.7, trunk? It
would break otherwise working manifests, in that they presently do something,
just not something that the user probably expects...
Bug #6808: Provide informative message when ensure = present, *and* managing
content/source, and target is a symlink
https://projects.puppetlabs.com/issues/6808
Author: Nigel Kersten
Status: Needs Decision
Priority: Low
Assignee: Nigel Kersten
Category:
Target version: 2.6.x
Affected Puppet version:
Keywords:
Branch:
pre
/tmp/foo - /tmp/bar
/pre
pre
file { /tmp/foo:
ensure = present,
content = foo,
}
/pre
When you run this, you get no indication that the content will not be written.
This is because the existence of the symlink suffices for ensure = present,
and the content isn't evaluated.
This is almost certainly another indicator that we should be breaking the
symlink type out into it's own type, separate from File, but in the meantime we
should try to log *something* here if feasible.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet] 'Downloading Puppet' wiki page has been updated
The 'Downloading Puppet' wiki page has been updated by Matthaus Litteken. Downloading Puppet: https://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet View differences: https://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet/diff/89 -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet] 'Downloading Puppet' wiki page has been updated
The 'Downloading Puppet' wiki page has been updated by Matthaus Litteken. Downloading Puppet: https://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet View differences: https://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet/diff/90 -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Cloud-Provisioner - Feature #8351] should document how to write custom template
Issue #8351 has been updated by Dan Bode. There have been a few internal requests for this information to be posted: here is a blurb that I sent out recently in an email: pre The ability to drop in arbitrary scripts to execute via ssh with the cloud provisioner is easy. Scripts are loaded out of the following directory: Puppet[:confdir]/scripts/SCRIPT_NAME.erb the script to use can be specified with the --install-script option to the install action of the cloud provisioner puppet node install --install-script SCRIPT_NAME The script will be compiled as an erb template before it is copied to the remote node to be executed. The script has access to all of the options passed to the cloud provisioner via the options hash, it also has access to these additional values: # hostname of puppetmaster options[:server] # environment to be used options[:environment] /pre Feature #8351: should document how to write custom template https://projects.puppetlabs.com/issues/8351 Author: Dan Bode Status: Accepted Priority: Normal Assignee: Category: cloudpack Target version: Keywords: Branch: Roadmapped: No The install-script option actually can take any arbitrary template from the users Puppet[:confdir/scripts/your_script.erb This needs to be documented as well as what options it can access via options[:opt] -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Cloud-Provisioner - Bug #8184] CloudPack spec tests should pass with Fog 0.9.0
Issue #8184 has been updated by Dan Bode. Assignee changed from Jeff McCune to Dan Bode Bug #8184: CloudPack spec tests should pass with Fog 0.9.0 https://projects.puppetlabs.com/issues/8184 Author: Jeff McCune Status: Accepted Priority: Low Assignee: Dan Bode Category: cloudpack Target version: Keywords: Branch: # Overview # The current version of Fog is 0.9.0 and our rspec tests are failing on this version: pre FF. Failures: 1) Puppet::Face[:node, 0.0.1] option validation (platform) should require a platform Failure/Error: data = Fog::AWS::Compute::Mock.data['us-east-1'][Fog.credentials[:aws_access_key_id]] NameError: uninitialized constant Fog::AWS::Compute # ./spec/unit/puppet/face/node/create_spec.rb:6 2) Puppet::Face[:node, 0.0.1] option validation (platform) should validate the platform Failure/Error: data = Fog::AWS::Compute::Mock.data['us-east-1'][Fog.credentials[:aws_access_key_id]] NameError: uninitialized constant Fog::AWS::Compute # ./spec/unit/puppet/face/node/create_spec.rb:6 3) Puppet::Face[:node, 0.0.1] option validation (type) should require a type Failure/Error: data = Fog::AWS::Compute::Mock.data['us-east-1'][Fog.credentials[:aws_access_key_id]] NameError: uninitialized constant Fog::AWS::Compute # ./spec/unit/puppet/face/node/create_spec.rb:6 4) Puppet::Face[:node, 0.0.1] option validation (type) should validate the tyoe Failure/Error: data = Fog::AWS::Compute::Mock.data['us-east-1'][Fog.credentials[:aws_access_key_id]] NameError: uninitialized constant Fog::AWS::Compute # ./spec/unit/puppet/face/node/create_spec.rb:6 5) Puppet::Face[:node, 0.0.1] option validation (image) should require an image Failure/Error: data = Fog::AWS::Compute::Mock.data['us-east-1'][Fog.credentials[:aws_access_key_id]] NameError: uninitialized constant Fog::AWS::Compute # ./spec/unit/puppet/face/node/create_spec.rb:6 6) Puppet::Face[:node, 0.0.1] option validation (image) should validate the image name Failure/Error: data = Fog::AWS::Compute::Mock.data['us-east-1'][Fog.credentials[:aws_access_key_id]] NameError: uninitialized constant Fog::AWS::Compute # ./spec/unit/puppet/face/node/create_spec.rb:6 7) Puppet::Face[:node, 0.0.1] option validation (keypair) should require a keypair name Failure/Error: data = Fog::AWS::Compute::Mock.data['us-east-1'][Fog.credentials[:aws_access_key_id]] NameError: uninitialized constant Fog::AWS::Compute # ./spec/unit/puppet/face/node/create_spec.rb:6 8) Puppet::Face[:node, 0.0.1] option validation (keypair) should validate the image name Failure/Error: data = Fog::AWS::Compute::Mock.data['us-east-1'][Fog.credentials[:aws_access_key_id]] NameError: uninitialized constant Fog::AWS::Compute # ./spec/unit/puppet/face/node/create_spec.rb:6 9) Puppet::Face[:node, 0.0.1] option validation (security-group) should split group names into an array Failure/Error: data = Fog::AWS::Compute::Mock.data['us-east-1'][Fog.credentials[:aws_access_key_id]] NameError: uninitialized constant Fog::AWS::Compute # ./spec/unit/puppet/face/node/create_spec.rb:6 10) Puppet::Face[:node, 0.0.1] option validation (security-group) should validate all group names Failure/Error: data = Fog::AWS::Compute::Mock.data['us-east-1'][Fog.credentials[:aws_access_key_id]] NameError: uninitialized constant Fog::AWS::Compute # ./spec/unit/puppet/face/node/create_spec.rb:6 Finished in 10.91 seconds 51 examples, 10 failures /pre # Expected Behaivor # With Fog 0.7.2 the tests succeed: pre ... Finished in 16.05 seconds 51 examples, 0 failures /pre -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #9410] (Needs More Information) yumrepo type does notice changes
Issue #9410 has been updated by James Turnbull.
Status changed from Unreviewed to Needs More Information
Assignee changed from James Turnbull to Jascha Lee
Can you show me some log output for this? I've never seen this happening. Can
you replicate this with the simplest possible yumrepo resource and we'll work
up from there. Thanks!
Bug #9410: yumrepo type does notice changes
https://projects.puppetlabs.com/issues/9410
Author: Jascha Lee
Status: Needs More Information
Priority: Normal
Assignee: Jascha Lee
Category: yumrepo
Target version:
Affected Puppet version: 2.6.6
Keywords:
Branch:
If the yum repo config file changes or disappears after the initial puppet run
in which it was created or modified, subsequent puppet runs will not notice.
The local change will remain (inconsistent with the catalog) and/or the removed
file will not be reconstructed.
It was suggested that indentation of multiple gpgkey values might be at play,
but this happens even with a single gpgkey value.
class yum {
yumrepo {
tivo-coxrtltivoqa2sp01.tivo.com:
descr= TiVo repo coxrtltivoqa2sp01.tivo.com,
baseurl = http://$yumvar_reponame/yum/rpms;,
gpgkey = http://$yumvar_reponame/yum/GPG/RPM-GPG-KEY-MySQL;,
gpgcheck = 1,
enabled = 1;
}
}
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #9391] (Needs More Information) Providers stop puppet working if binaries can't be found even if they are in the catalog to be installed.
Issue #9391 has been updated by James Turnbull.
Category set to provider
Status changed from Unreviewed to Needs More Information
Assignee set to Ashley Penney
Ashley
I feel your pain. I think this ticket is a duplicate though - I will try to
find the relevant ticket and close this one in favor of it.
Bug #9391: Providers stop puppet working if binaries can't be found even if
they are in the catalog to be installed.
https://projects.puppetlabs.com/issues/9391
Author: Ashley Penney
Status: Needs More Information
Priority: Normal
Assignee: Ashley Penney
Category: provider
Target version:
Affected Puppet version: 2.6.9
Keywords:
Branch:
I just decided to check out the vcsrepo module and ran into a reoccurring and
annoying bug within providers that keeps biting me. The vcsrepo{} I added in
my module has provider = svn. I also include a package { subversion } in
the same module. However, because the provider checks BEFORE the catalog is
run it immediately fails with no possibility for puppet to fix it. I would
like for puppet to either run the rest of the resources then attempt to rerun
the ones requiring a specific provider or check the catalog to see if the
provider requirement would be filled by a resource and then delay execution
until that is met. (I guess these goals are the same but the second is more
elegant in that it actually checks for a solution rather than just delaying and
trying again hopefully).
My mysql module does this too on new boxes - it won't do the package{mysql}
because it tries to parse the mysql lib/ stuff up front.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #9391] (Duplicate) Providers stop puppet working if binaries can't be found even if they are in the catalog to be installed.
Issue #9391 has been updated by James Turnbull.
Status changed from Needs More Information to Duplicate
Duplicate of #6907.
Bug #9391: Providers stop puppet working if binaries can't be found even if
they are in the catalog to be installed.
https://projects.puppetlabs.com/issues/9391
Author: Ashley Penney
Status: Duplicate
Priority: Normal
Assignee: Ashley Penney
Category: provider
Target version:
Affected Puppet version: 2.6.9
Keywords:
Branch:
I just decided to check out the vcsrepo module and ran into a reoccurring and
annoying bug within providers that keeps biting me. The vcsrepo{} I added in
my module has provider = svn. I also include a package { subversion } in
the same module. However, because the provider checks BEFORE the catalog is
run it immediately fails with no possibility for puppet to fix it. I would
like for puppet to either run the rest of the resources then attempt to rerun
the ones requiring a specific provider or check the catalog to see if the
provider requirement would be filled by a resource and then delay execution
until that is met. (I guess these goals are the same but the second is more
elegant in that it actually checks for a solution rather than just delaying and
trying again hopefully).
My mysql module does this too on new boxes - it won't do the package{mysql}
because it tries to parse the mysql lib/ stuff up front.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #7999] (Merged - Pending Release) Add a service provider that manages systemd services
Issue #7999 has been updated by James Turnbull. Status changed from In Topic Branch Pending Merge to Merged - Pending Release Target version changed from 2.7.x to 2.7.4 Awesome that this is merged - thanks again to Jeff for the code. Feature #7999: Add a service provider that manages systemd services https://projects.puppetlabs.com/issues/7999 Author: Jeff Ollie Status: Merged - Pending Release Priority: High Assignee: Nigel Kersten Category: service Target version: 2.7.4 Affected Puppet version: Keywords: Branch: https://github.com/jcollie/puppet/tree/feature%2Fmaster%2F7999-systemd-services systemd is the default system/service manager in Fedora 15 and will likely become the default on other Linux distributions in the future. While systemd provides a compatibility layer that allows the standard redhat Puppet service provider to manage some services on a systemd system, as more services are converted to native systemd services the compatibility layer will become less and less useful. For more information on systemd see: http://www.freedesktop.org/wiki/Software/systemd -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet] 'Release Notes' wiki page has been updated
The 'Release Notes' wiki page has been updated by Matthaus Litteken. Adding puppet 2.7.4rc1 changes Release Notes: https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes View differences: https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes/diff/123 -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet] 'Release Notes' wiki page has been updated
The 'Release Notes' wiki page has been updated by Matthaus Litteken. Release Notes: https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes View differences: https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes/diff/124 -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #6808] Provide informative message when ensure = present, *and* managing content/source, and target is a symlink
Issue #6808 has been updated by Nigel Kersten.
Is it feasible to do:
A warning on the client side, but carry on? - 2.7.x
An error on the client side (or, correctly, during compilation) if both of
those are specified? - Telly
?
That feels like the right thing to do.
Bug #6808: Provide informative message when ensure = present, *and* managing
content/source, and target is a symlink
https://projects.puppetlabs.com/issues/6808
Author: Nigel Kersten
Status: Needs Decision
Priority: Low
Assignee: Nigel Kersten
Category:
Target version: 2.6.x
Affected Puppet version:
Keywords:
Branch:
pre
/tmp/foo - /tmp/bar
/pre
pre
file { /tmp/foo:
ensure = present,
content = foo,
}
/pre
When you run this, you get no indication that the content will not be written.
This is because the existence of the symlink suffices for ensure = present,
and the content isn't evaluated.
This is almost certainly another indicator that we should be breaking the
symlink type out into it's own type, separate from File, but in the meantime we
should try to log *something* here if feasible.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #6808] Provide informative message when ensure = present, *and* managing content/source, and target is a symlink
Issue #6808 has been updated by Nigel Kersten.
Assignee changed from Nigel Kersten to Daniel Pittman
Bug #6808: Provide informative message when ensure = present, *and* managing
content/source, and target is a symlink
https://projects.puppetlabs.com/issues/6808
Author: Nigel Kersten
Status: Needs Decision
Priority: Low
Assignee: Daniel Pittman
Category:
Target version: 2.6.x
Affected Puppet version:
Keywords:
Branch:
pre
/tmp/foo - /tmp/bar
/pre
pre
file { /tmp/foo:
ensure = present,
content = foo,
}
/pre
When you run this, you get no indication that the content will not be written.
This is because the existence of the symlink suffices for ensure = present,
and the content isn't evaluated.
This is almost certainly another indicator that we should be breaking the
symlink type out into it's own type, separate from File, but in the meantime we
should try to log *something* here if feasible.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #5789] launchd provider parses all plists twice, and uses too much CPU
Issue #5789 has been updated by Nigel Kersten. Target version set to 2.7.x Bug #5789: launchd provider parses all plists twice, and uses too much CPU https://projects.puppetlabs.com/issues/5789 Author: Nigel Kersten Status: Accepted Priority: Normal Assignee: Gary Larizza Category: provider Target version: 2.7.x Affected Puppet version: Keywords: mac launchd service provider Branch: We shouldn't be parsing everything twice, and it appears that piping to /dev/stdout is particularly slow on OS X. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #5981] Puppet shouldn't overwrite symlinks when specifying content and follow is on.
Issue #5981 has been updated by Nigel Kersten.
No, it just didn't fall into the category of things we're targeting at 2.6.x,
which are egregious bugs and security issues.
Bug #5981: Puppet shouldn't overwrite symlinks when specifying content and
follow is on.
https://projects.puppetlabs.com/issues/5981
Author: Nigel Kersten
Status: Needs More Information
Priority: Normal
Assignee: Nigel Kersten
Category:
Target version: 2.7.x
Affected Puppet version:
Keywords:
Branch:
Illustration of the issue:
pre
kripke:~ nbk$ echo target /tmp/target
kripke:~ nbk$ ln -s /tmp/target /tmp/symlink
kripke:~ nbk$ ls -l /tmp/target /tmp/symlink
lrwxr-xr-x 1 nbk wheel 11 Jan 23 14:43 /tmp/symlink - /tmp/target
-rw-r--r-- 1 nbk wheel 7 Jan 23 14:43 /tmp/target
/pre
pre
kripke:~ nbk$ puppet --version
2.6.4
kripke:~ nbk$ cat /tmp/test.pp
file { /tmp/symlink:
ensure = present,
backup = false,
links = follow,
content = content,
}
kripke:~ nbk$ puppet apply -v /tmp/test.pp
info: Applying configuration version '1295823089'
notice: /Stage[main]//File[/tmp/symlink]/content: content changed
'{md5}80fb1dd0b20823f1d83e10d25840e2e4' to
'{md5}9a0364b9e99bb480dd25e1f0284c8555'
kripke:~ nbk$ ls -la /tmp/target /tmp/symlink
-rw-r--r-- 1 nbk wheel 7 Jan 23 14:51 /tmp/symlink
-rw-r--r-- 1 nbk wheel 7 Jan 23 14:47 /tmp/target
/pre
So even though we're not managing the symlink, and we've only got ensure set to
present, and we have links set to follow, Puppet overwrites the symlink with
the contents, rather than the target.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Cloud-Provisioner - Bug #8184] CloudPack spec tests should pass with Fog 0.11.0
Issue #8184 has been updated by Dan Bode. Subject changed from CloudPack spec tests should pass with Fog 0.9.0 to CloudPack spec tests should pass with Fog 0.11.0 updating to latest version v0.11.0 Bug #8184: CloudPack spec tests should pass with Fog 0.11.0 https://projects.puppetlabs.com/issues/8184 Author: Jeff McCune Status: Accepted Priority: Low Assignee: Dan Bode Category: cloudpack Target version: Keywords: Branch: # Overview # The current version of Fog is 0.9.0 and our rspec tests are failing on this version: pre FF. Failures: 1) Puppet::Face[:node, 0.0.1] option validation (platform) should require a platform Failure/Error: data = Fog::AWS::Compute::Mock.data['us-east-1'][Fog.credentials[:aws_access_key_id]] NameError: uninitialized constant Fog::AWS::Compute # ./spec/unit/puppet/face/node/create_spec.rb:6 2) Puppet::Face[:node, 0.0.1] option validation (platform) should validate the platform Failure/Error: data = Fog::AWS::Compute::Mock.data['us-east-1'][Fog.credentials[:aws_access_key_id]] NameError: uninitialized constant Fog::AWS::Compute # ./spec/unit/puppet/face/node/create_spec.rb:6 3) Puppet::Face[:node, 0.0.1] option validation (type) should require a type Failure/Error: data = Fog::AWS::Compute::Mock.data['us-east-1'][Fog.credentials[:aws_access_key_id]] NameError: uninitialized constant Fog::AWS::Compute # ./spec/unit/puppet/face/node/create_spec.rb:6 4) Puppet::Face[:node, 0.0.1] option validation (type) should validate the tyoe Failure/Error: data = Fog::AWS::Compute::Mock.data['us-east-1'][Fog.credentials[:aws_access_key_id]] NameError: uninitialized constant Fog::AWS::Compute # ./spec/unit/puppet/face/node/create_spec.rb:6 5) Puppet::Face[:node, 0.0.1] option validation (image) should require an image Failure/Error: data = Fog::AWS::Compute::Mock.data['us-east-1'][Fog.credentials[:aws_access_key_id]] NameError: uninitialized constant Fog::AWS::Compute # ./spec/unit/puppet/face/node/create_spec.rb:6 6) Puppet::Face[:node, 0.0.1] option validation (image) should validate the image name Failure/Error: data = Fog::AWS::Compute::Mock.data['us-east-1'][Fog.credentials[:aws_access_key_id]] NameError: uninitialized constant Fog::AWS::Compute # ./spec/unit/puppet/face/node/create_spec.rb:6 7) Puppet::Face[:node, 0.0.1] option validation (keypair) should require a keypair name Failure/Error: data = Fog::AWS::Compute::Mock.data['us-east-1'][Fog.credentials[:aws_access_key_id]] NameError: uninitialized constant Fog::AWS::Compute # ./spec/unit/puppet/face/node/create_spec.rb:6 8) Puppet::Face[:node, 0.0.1] option validation (keypair) should validate the image name Failure/Error: data = Fog::AWS::Compute::Mock.data['us-east-1'][Fog.credentials[:aws_access_key_id]] NameError: uninitialized constant Fog::AWS::Compute # ./spec/unit/puppet/face/node/create_spec.rb:6 9) Puppet::Face[:node, 0.0.1] option validation (security-group) should split group names into an array Failure/Error: data = Fog::AWS::Compute::Mock.data['us-east-1'][Fog.credentials[:aws_access_key_id]] NameError: uninitialized constant Fog::AWS::Compute # ./spec/unit/puppet/face/node/create_spec.rb:6 10) Puppet::Face[:node, 0.0.1] option validation (security-group) should validate all group names Failure/Error: data = Fog::AWS::Compute::Mock.data['us-east-1'][Fog.credentials[:aws_access_key_id]] NameError: uninitialized constant Fog::AWS::Compute # ./spec/unit/puppet/face/node/create_spec.rb:6 Finished in 10.91 seconds 51 examples, 10 failures /pre # Expected Behaivor # With Fog 0.7.2 the tests succeed: pre ... Finished in 16.05 seconds 51 examples, 0 failures /pre -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #3553] Cron resource with no time fields throws useless error message
Issue #3553 has been updated by Matthaus Litteken.
Docs updated in 2.7.4rc1. The behavior itself is still an outstanding issue.
Bug #3553: Cron resource with no time fields throws useless error message
https://projects.puppetlabs.com/issues/3553
Author: Darvin Denmian
Status: Needs Decision
Priority: Normal
Assignee:
Category:
Target version:
Affected Puppet version:
Keywords:
Branch:
Adding the following entry to a file :
cron { app:
command = nice -n -10
/usr/bin/php/var/www/public_html/rotinas/rotinas.php 21 /var/log/app.log,
environment = PATH=$PATH,
user= root,
}
I got the following as you can see in attached file.
(NF: snip!)
debug: Flushing cron provider target root
-:6: bad minute
errors in crontab file, can't install.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #5495] (Closed) Exec resource searches CWD when testing file attributes of executables
Issue #5495 has been updated by Matthaus Litteken.
Status changed from Merged - Pending Release to Closed
Released in 2.7.4rc1
Bug #5495: Exec resource searches CWD when testing file attributes of
executables
https://projects.puppetlabs.com/issues/5495
Author: Luke Bigum
Status: Closed
Priority: High
Assignee: Nick Lewis
Category: exec
Target version: 2.7.4
Affected Puppet version: 2.6.3
Keywords:
Branch:
I've noticed a problem with Exec resources that use an explicit or global
default path seem to search the current working directory when testing the
attributes on executable commands as part of 'unless', 'onlyif' or 'command'
parameters where the binary is an unqualified (eg: grep vs /bin/grep). If
the current working directory contains a file of the same name as what is to be
executed in the Puppet manifest, then it may cause the Ruby sanity tests in
type/exec.rb to fail.
See the following terminal log for a demonstration:
[root@host ~]# pwd
/root
[root@host ~]# cat test.pp
exec { test Exec:
path = /usr/sbin:/usr/bin:/sbin:/bin,
command = echo Woof,
onlyif = grep localhost /etc/hosts,
}
[root@host ~]# puppet apply test.pp
notice: /Stage[main]//Exec[test Exec]/returns: executed successfully
[root@host ~]# touch grep
[root@host ~]# puppet apply test.pp
err: /Stage[main]//Exec[test Exec]: Could not evaluate: 'grep' is not
executable
[root@host ~]# rm grep
rm: remove regular empty file `grep'? y
[root@host ~]# touch echo
[root@host ~]# puppet apply test.pp
err: /Stage[main]//Exec[test Exec]/returns: change from notrun to 0 failed:
'echo' is not executable
[root@host ~]# rm echo
rm: remove regular empty file `echo'? y
[root@host ~]# puppet apply test.pp
notice: /Stage[main]//Exec[test Exec]/returns: executed successfully
From what I can tell this is not a security issue though. I've tried embedding
a shell script of the same name as the binary in the CWD but it looks like
it's probably only the Ruby FileTest that has the problem, not the actual
execution of binaries:
[root@host ~]# pwd
/root
[root@host ~]# cat grep
#!/bin/bash
touch Done_bad_stuff
[root@host ~]# cat test.pp
exec { test Exec:
path = /usr/sbin:/usr/bin:/sbin:/bin,
command = echo Woof,
onlyif = grep localhost /etc/hosts,
}
[root@host ~]# puppet apply test.pp
notice: /Stage[main]//Exec[test Exec]/returns: executed successfully
[root@host ~]# ls -ld Done_bad_stuff
ls: Done_bad_stuff: No such file or directory
[root@host ~]#
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #7999] (Closed) Add a service provider that manages systemd services
Issue #7999 has been updated by Matthaus Litteken. Status changed from Merged - Pending Release to Closed Released in 2.7.4rc1 Feature #7999: Add a service provider that manages systemd services https://projects.puppetlabs.com/issues/7999 Author: Jeff Ollie Status: Closed Priority: High Assignee: Nigel Kersten Category: service Target version: 2.7.4 Affected Puppet version: Keywords: Branch: https://github.com/jcollie/puppet/tree/feature%2Fmaster%2F7999-systemd-services systemd is the default system/service manager in Fedora 15 and will likely become the default on other Linux distributions in the future. While systemd provides a compatibility layer that allows the standard redhat Puppet service provider to manage some services on a systemd system, as more services are converted to native systemd services the compatibility layer will become less and less useful. For more information on systemd see: http://www.freedesktop.org/wiki/Software/systemd -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #8272] (Closed) Windows Services Management
Issue #8272 has been updated by Matthaus Litteken. Status changed from Merged - Pending Release to Closed Target version changed from 2.7.x to 2.7.4 Released in 2.7.4rc1 Feature #8272: Windows Services Management https://projects.puppetlabs.com/issues/8272 Author: Cameron Thomas Status: Closed Priority: Normal Assignee: Category: windows Target version: 2.7.4 Affected Puppet version: Keywords: Branch: Create provider to manage Windows services via the registry. Should start,/stop, pause/restart enable/disable existing services. No requirement to install or remove. No DACLs, just ensure/enable as per other providers. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #8302] Improve documentation of shell provider for exec type
Issue #8302 has been updated by Matthaus Litteken. Released in 2.7.4rc1 Bug #8302: Improve documentation of shell provider for exec type https://projects.puppetlabs.com/issues/8302 Author: Nick Fagerlund Status: Closed Priority: Normal Assignee: Nick Fagerlund Category: documentation Target version: 2.7.4 Affected Puppet version: Keywords: Branch: The reason we added shell as a new provider instead of changing the default behavior of exec was because handing a string to a shell introduces additional security concerns. This should be outlined in the desc string for the provider. Post-facto edits to the 2.6.8 release notes may also be called for. Per [this comment](https://projects.puppetlabs.com/issues/4884#note-30) from issue #4884. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #8356] (Closed) Default value of :color should be false on Windows
Issue #8356 has been updated by Matthaus Litteken. Status changed from Merged - Pending Release to Closed Target version changed from 2.7.x to 2.7.4 Released in 2.7.4rc1 Bug #8356: Default value of :color should be false on Windows https://projects.puppetlabs.com/issues/8356 Author: Josh Cooper Status: Closed Priority: Normal Assignee: Josh Cooper Category: windows Target version: 2.7.4 Affected Puppet version: Keywords: windows Branch: Windows console windows do not support ansi escape sequences, so you get garbled output when running puppet: pre Z:\work\puppetpuppet config ←[1;35merr: 'config' has no default action. See `puppet help config`.←[0m /pre -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Refactor #8392] (Closed) Confine master tests to not run on Windows
Issue #8392 has been updated by Matthaus Litteken. Status changed from Merged - Pending Release to Closed Target version changed from 2.7.x to 2.7.4 Released in 2.7.4rc1 Refactor #8392: Confine master tests to not run on Windows https://projects.puppetlabs.com/issues/8392 Author: Jacob Helwig Status: Closed Priority: Normal Assignee: Jacob Helwig Category: windows Target version: 2.7.4 Affected Puppet version: Keywords: Branch: Since Windows is not a supported platform we don't need to make sure that the test purely related to master functionality pass on the platform. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #8408] (Closed) Local user provider for Windows
Issue #8408 has been updated by Matthaus Litteken. Status changed from Merged - Pending Release to Closed Target version changed from 2.7.x to 2.7.4 Released in 2.7.4rc1 Feature #8408: Local user provider for Windows https://projects.puppetlabs.com/issues/8408 Author: Jacob Helwig Status: Closed Priority: Normal Assignee: Category: windows Target version: 2.7.4 Affected Puppet version: Keywords: Branch: Basic user provider for Windows. Support for local users only. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #8409] (Closed) Local group provider for Windows
Issue #8409 has been updated by Matthaus Litteken. Status changed from Merged - Pending Release to Closed Target version changed from 2.7.x to 2.7.4 Released in 2.7.4rc1 Feature #8409: Local group provider for Windows https://projects.puppetlabs.com/issues/8409 Author: Jacob Helwig Status: Closed Priority: Normal Assignee: Category: windows Target version: 2.7.4 Affected Puppet version: Keywords: Branch: Basic group provider. Support only for local groups. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #8410] (Closed) Exec provider for Windows
Issue #8410 has been updated by Matthaus Litteken. Status changed from Merged - Pending Release to Closed Target version changed from 2.7.x to 2.7.4 Released in 2.7.4rc1 Feature #8410: Exec provider for Windows https://projects.puppetlabs.com/issues/8410 Author: Jacob Helwig Status: Closed Priority: Normal Assignee: Nick Lewis Category: windows Target version: 2.7.4 Affected Puppet version: development Keywords: Branch: Basic ability to run commands. Commands must either be present in PATH, or fully specified. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #8412] (Closed) MSI package provider for Windows
Issue #8412 has been updated by Matthaus Litteken. Status changed from Merged - Pending Release to Closed Target version changed from 2.7.x to 2.7.4 Released in 2.7.4rc1 Feature #8412: MSI package provider for Windows https://projects.puppetlabs.com/issues/8412 Author: Jacob Helwig Status: Closed Priority: Normal Assignee: Jacob Helwig Category: windows Target version: 2.7.4 Affected Puppet version: Keywords: Branch: https://github.com/jhelwig/puppet/commits/tickets/2.7.x/8412-install-msi-on-windows-via-package-type Ability to install manage packages installed via MSIs on Windows. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #8413] (Closed) Ability to run Puppet as an agent on Windows
Issue #8413 has been updated by Matthaus Litteken. Status changed from Merged - Pending Release to Closed Released in 2.7.4rc1 Feature #8413: Ability to run Puppet as an agent on Windows https://projects.puppetlabs.com/issues/8413 Author: Jacob Helwig Status: Closed Priority: Normal Assignee: Nick Lewis Category: windows Target version: 2.7.4 Affected Puppet version: development Keywords: Branch: Puppet agent should work on Windows, including the ability to run as a service. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #8489] (Closed) Puppet does not consistently use File::PATH_SEPARATOR
Issue #8489 has been updated by Matthaus Litteken. Status changed from Merged - Pending Release to Closed Target version changed from 2.7.x to 2.7.4 Released in 2.7.4rc1 Bug #8489: Puppet does not consistently use File::PATH_SEPARATOR https://projects.puppetlabs.com/issues/8489 Author: Josh Cooper Status: Closed Priority: Normal Assignee: Nick Lewis Category: windows Target version: 2.7.4 Affected Puppet version: development Keywords: Branch: The File::PATH_SEPARATOR on Unix is colon, but on Windows is semi-colon. And since colon is often present in Windows absolute paths (except for UNC), this means colon can't be used as the path separator character on Windows (unless the colon were to be escaped, but then backslash is a file separator, and that would be madness). Various places in puppet already split configuration options using the PATH_SEPARATOR, including modulepath, manifestdir, templatedir, factdir, etc. Some research will be required to find all of the places and make sure the code and tests are consistent, while not breaking Unix. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #8612] (Closed) exec creates param in doc example wrong
Issue #8612 has been updated by Matthaus Litteken.
Status changed from Merged - Pending Release to Closed
Released in 2.7.4rc1
Bug #8612: exec creates param in doc example wrong
https://projects.puppetlabs.com/issues/8612
Author: Jeff Blaine
Status: Closed
Priority: Normal
Assignee: Nick Fagerlund
Category: documentation
Target version: 2.7.4
Affected Puppet version:
Keywords:
Branch:
The 'creates' param in the code seems wrong, but I'm a newb, so...
http://docs.puppetlabs.com/references/stable/type.html#exec
...
***creates***
A file that this command creates. If this parameter is provided, then the
command will only be run if the specified file does not exist:
pre
exec { tar xf /my/tar/file.tar:
cwd = /var/tmp,
creates = /var/tmp/myfile,
path = [/usr/bin, /usr/sbin]
}
/pre
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #8644] (Closed) Host provider on Windows
Issue #8644 has been updated by Matthaus Litteken. Status changed from Merged - Pending Release to Closed Target version changed from 2.7.x to 2.7.4 Released in 2.7.4rc1 Feature #8644: Host provider on Windows https://projects.puppetlabs.com/issues/8644 Author: Josh Cooper Status: Closed Priority: Normal Assignee: Josh Cooper Category: windows Target version: 2.7.4 Affected Puppet version: Keywords: Branch: The host provider does not work on Windows because it does not know where to find the hosts file. From wikipedia, this should be pre %SystemRoot%\system32\drivers\etc\hosts /pre -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #8660] (Closed) Puppet and facter install should have reasonable defaults on Windows
Issue #8660 has been updated by Matthaus Litteken. Status changed from Merged - Pending Release to Closed Target version changed from 2.7.x to 2.7.4 Released in 2.7.4rc1 Bug #8660: Puppet and facter install should have reasonable defaults on Windows https://projects.puppetlabs.com/issues/8660 Author: Josh Cooper Status: Closed Priority: Normal Assignee: Josh Cooper Category: windows Target version: 2.7.4 Affected Puppet version: Keywords: Branch: The puppet and facter install.rb scripts default to directories such as /etc/puppet, which probably aren't the correct places on Windows. Also in Puppet::Util::RunMode, it defaults to File.join(Dir::WINDOWS, puppet, etc) for the conf dir, which doesn't match the installer. More research is needed to determine what the default values should be. Once decided, the install scripts need to be modified, and any puppet code, e.g. runmode, that makes assumptions about default locations should be updated. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #8662] (Closed) Puppet.features.root? always returns true on Windows
Issue #8662 has been updated by Matthaus Litteken. Status changed from Merged - Pending Release to Closed Target version changed from 2.7.x to 2.7.4 Released in 2.7.4rc1 Bug #8662: Puppet.features.root? always returns true on Windows https://projects.puppetlabs.com/issues/8662 Author: Josh Cooper Status: Closed Priority: Normal Assignee: Josh Cooper Category: windows Target version: 2.7.4 Affected Puppet version: development Keywords: Branch: On Windows, Puppet.features.root? always returns true, even when running as a non-admin user. It should only return true if we are running with elevated privileges. Part of the problem is that Puppet.features.root, invokes SUIDManager.root?, which calls Process.uid, without first requiring the win32/process gem. And without it, Process.uid always returns 0. We also need to investigate what code paths occur when root? is true or false, and make sure they make sense on Windows. For example, the file provider will attempt to set the owner and group of files that it manages when running as root, but the capability to obtain and set owner/group info is not implemented yet on Windows. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Cloud-Provisioner - Bug #8184] CloudPack spec tests should pass with Fog 0.11.0
Issue #8184 has been updated by Dan Bode. looks like there are two things to fix: Fog::Compute::AWS::Mock can now determine when a region is invalid region and raises its own exception. (this may require that the code is updated) Rename Namespace Fog::AWS::Compute to Fog::Compute::AWS Bug #8184: CloudPack spec tests should pass with Fog 0.11.0 https://projects.puppetlabs.com/issues/8184 Author: Jeff McCune Status: Accepted Priority: Low Assignee: Dan Bode Category: cloudpack Target version: Keywords: Branch: # Overview # The current version of Fog is 0.9.0 and our rspec tests are failing on this version: pre FF. Failures: 1) Puppet::Face[:node, 0.0.1] option validation (platform) should require a platform Failure/Error: data = Fog::AWS::Compute::Mock.data['us-east-1'][Fog.credentials[:aws_access_key_id]] NameError: uninitialized constant Fog::AWS::Compute # ./spec/unit/puppet/face/node/create_spec.rb:6 2) Puppet::Face[:node, 0.0.1] option validation (platform) should validate the platform Failure/Error: data = Fog::AWS::Compute::Mock.data['us-east-1'][Fog.credentials[:aws_access_key_id]] NameError: uninitialized constant Fog::AWS::Compute # ./spec/unit/puppet/face/node/create_spec.rb:6 3) Puppet::Face[:node, 0.0.1] option validation (type) should require a type Failure/Error: data = Fog::AWS::Compute::Mock.data['us-east-1'][Fog.credentials[:aws_access_key_id]] NameError: uninitialized constant Fog::AWS::Compute # ./spec/unit/puppet/face/node/create_spec.rb:6 4) Puppet::Face[:node, 0.0.1] option validation (type) should validate the tyoe Failure/Error: data = Fog::AWS::Compute::Mock.data['us-east-1'][Fog.credentials[:aws_access_key_id]] NameError: uninitialized constant Fog::AWS::Compute # ./spec/unit/puppet/face/node/create_spec.rb:6 5) Puppet::Face[:node, 0.0.1] option validation (image) should require an image Failure/Error: data = Fog::AWS::Compute::Mock.data['us-east-1'][Fog.credentials[:aws_access_key_id]] NameError: uninitialized constant Fog::AWS::Compute # ./spec/unit/puppet/face/node/create_spec.rb:6 6) Puppet::Face[:node, 0.0.1] option validation (image) should validate the image name Failure/Error: data = Fog::AWS::Compute::Mock.data['us-east-1'][Fog.credentials[:aws_access_key_id]] NameError: uninitialized constant Fog::AWS::Compute # ./spec/unit/puppet/face/node/create_spec.rb:6 7) Puppet::Face[:node, 0.0.1] option validation (keypair) should require a keypair name Failure/Error: data = Fog::AWS::Compute::Mock.data['us-east-1'][Fog.credentials[:aws_access_key_id]] NameError: uninitialized constant Fog::AWS::Compute # ./spec/unit/puppet/face/node/create_spec.rb:6 8) Puppet::Face[:node, 0.0.1] option validation (keypair) should validate the image name Failure/Error: data = Fog::AWS::Compute::Mock.data['us-east-1'][Fog.credentials[:aws_access_key_id]] NameError: uninitialized constant Fog::AWS::Compute # ./spec/unit/puppet/face/node/create_spec.rb:6 9) Puppet::Face[:node, 0.0.1] option validation (security-group) should split group names into an array Failure/Error: data = Fog::AWS::Compute::Mock.data['us-east-1'][Fog.credentials[:aws_access_key_id]] NameError: uninitialized constant Fog::AWS::Compute # ./spec/unit/puppet/face/node/create_spec.rb:6 10) Puppet::Face[:node, 0.0.1] option validation (security-group) should validate all group names Failure/Error: data = Fog::AWS::Compute::Mock.data['us-east-1'][Fog.credentials[:aws_access_key_id]] NameError: uninitialized constant Fog::AWS::Compute # ./spec/unit/puppet/face/node/create_spec.rb:6 Finished in 10.91 seconds 51 examples, 10 failures /pre # Expected Behaivor # With Fog 0.7.2 the tests succeed: pre ... Finished in 16.05 seconds 51 examples, 0 failures /pre -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #8663] (Closed) Get spec tests running on Windows
Issue #8663 has been updated by Matthaus Litteken. Status changed from Merged - Pending Release to Closed Target version changed from 2.7.x to 2.7.4 Released in 2.7.4rc1 Bug #8663: Get spec tests running on Windows https://projects.puppetlabs.com/issues/8663 Author: Josh Cooper Status: Closed Priority: Normal Assignee: Josh Cooper Category: windows Target version: 2.7.4 Affected Puppet version: Keywords: Branch: Over 2500 spec tests fail on Windows. Need to determine whether failing tests should be supported on Windows. For example, we are not supporting server functionality on Windows, in which case those tests should be disabled when running on Windows. Otherwise, figure out whether the test is broken, or if the code it is testing is broken. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #8808] (Merged - Pending Release) No error when an Augeas resource cannot be saved
Issue #8808 has been updated by Matthaus Litteken.
Status changed from In Topic Branch Pending Merge to Merged - Pending Release
Bug #8808: No error when an Augeas resource cannot be saved
https://projects.puppetlabs.com/issues/8808
Author: Dominic Cleal
Status: Merged - Pending Release
Priority: Normal
Assignee:
Category: augeas
Target version:
Affected Puppet version: 2.7.0
Keywords: augeas error
Branch: https://github.com/domcleal/puppet/tree/tickets/2.7.x/8808
The Augeas provider no longer fails with an error if saving fails and only
reports no need to run.
With the following manifest:
augeas { broken:
changes = set /files/etc/fstab/*[last()]/foo bar,
}
Prior to #2728 being applied:
err: /Stage[main]/Augeas/Augeas[broken]/returns: change from need_to_run to
0 failed: Save failed with return code false
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #8808] (Closed) No error when an Augeas resource cannot be saved
Issue #8808 has been updated by Matthaus Litteken.
Status changed from Merged - Pending Release to Closed
Target version set to 2.7.4
Merged in 1ce2973e8af2300aff2b042257d8181855cf887d
Released in 2.7.4rc1
Bug #8808: No error when an Augeas resource cannot be saved
https://projects.puppetlabs.com/issues/8808
Author: Dominic Cleal
Status: Closed
Priority: Normal
Assignee:
Category: augeas
Target version: 2.7.4
Affected Puppet version: 2.7.0
Keywords: augeas error
Branch: https://github.com/domcleal/puppet/tree/tickets/2.7.x/8808
The Augeas provider no longer fails with an error if saving fails and only
reports no need to run.
With the following manifest:
augeas { broken:
changes = set /files/etc/fstab/*[last()]/foo bar,
}
Prior to #2728 being applied:
err: /Stage[main]/Augeas/Augeas[broken]/returns: change from need_to_run to
0 failed: Save failed with return code false
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #9039] (Merged - Pending Release) Augeas commands documentation out of date
Issue #9039 has been updated by Matthaus Litteken. Status changed from In Topic Branch Pending Merge to Merged - Pending Release Merged in 020c47645c7d882b1eac5150fd47227806af8aed Bug #9039: Augeas commands documentation out of date https://projects.puppetlabs.com/issues/9039 Author: Dominic Cleal Status: Merged - Pending Release Priority: Normal Assignee: Dominic Cleal Category: documentation Target version: Affected Puppet version: Keywords: augeas Branch: https://github.com/domcleal/puppet/tree/tickets/2.7.x/9039 The list of supported commands in the Augeas type documentation is out of date. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #9039] (Closed) Augeas commands documentation out of date
Issue #9039 has been updated by Matthaus Litteken. Status changed from Merged - Pending Release to Closed Target version set to 2.7.4 Released in 2.7.4rc1 Bug #9039: Augeas commands documentation out of date https://projects.puppetlabs.com/issues/9039 Author: Dominic Cleal Status: Closed Priority: Normal Assignee: Dominic Cleal Category: documentation Target version: 2.7.4 Affected Puppet version: Keywords: augeas Branch: https://github.com/domcleal/puppet/tree/tickets/2.7.x/9039 The list of supported commands in the Augeas type documentation is out of date. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #8740] `puppet resource file` reports Cannot manage files of type socket
Issue #8740 has been updated by Matthaus Litteken. Released in 2.7.4rc1, 2.6.x release still outstanding. Bug #8740: `puppet resource file` reports Cannot manage files of type socket https://projects.puppetlabs.com/issues/8740 Author: Randall Hansen Status: Merged - Pending Release Priority: Urgent Assignee: Josh Cooper Category: Target version: 2.6.10 Affected Puppet version: Keywords: Branch: 12:38 milo | puppet --version 2.7.2 12:38 milo | puppet resource file /etc/hosts Could not run: Cannot manage files of type socket -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
