[Puppet Users] Re: Official puppetlabs position on cron vs puppet as a service?
Mostly stlll run as cron. Though for some instances we run as a daemon. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/itTFPtfZLocJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] how to use optional parameters
On 10/08/2011 12:28 AM, maillis...@gmail.com wrote:
New to puppet and I just don't understand how to do this. Apologies in
advance if it's a dumb question.
Let's say I have a module called httpd and inside that is a class
called httpd::service, which accepts a couple of parameters:
class httpd::service (
$running = 'running',
$enabled = 'true',
) {
service { "httpd":
path => "/etc/init.d/httpd",
ensure=> $running,
enable=> $enabled,
require => [ Package[ "httpd" ], File[ "/etc/httpd/conf/httpd.conf" ] ],
subscribe => File[ "/etc/httpd/conf/httpd.conf" ],
}
}
But let's say that I want to allow the option of both requiring and
subscribing to a second file -- any file -- in addition to httpd.conf.
If I were doing this in a procedural language, I'd probably do
something naive and create a couple of empty parameters called
$also_subscribed and $myfile_path, use a conditional to see if it's
defined, then create the arguments to require and subscribe based on
that.
I cannot figure out how to get this done in puppet. Any help is
appreciated, even a link to an appropriate doc or example. Thanks!
I would use definition instead of class and it would look similar to this:
define httpd::service (
running = 'running',
enabled = 'true',
path = '/etc/init.d/httpd',
require = [ Package[ "httpd" ], File[
"/etc/httpd/conf/httpd.conf" ] ],
subscribe= File[ "/etc/httpd/conf/httpd.conf" ],
) {
service { "httpd":
path => $path,
ensure=> $running,
enable=> $enabled,
require => $require,
subscribe => $subscribe,
}
}
Now you're able to override default values in this way:
httpd::service { path => '/some/path', }
You can also use assign array here:
$array = [ '/some/path', '/another/path' ]
httpd::service { path => $array, }
--
Dominik Zyla
--
You received this message because you are subscribed to the Google Groups "Puppet
Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] how to use optional parameters
New to puppet and I just don't understand how to do this. Apologies in
advance if it's a dumb question.
Let's say I have a module called httpd and inside that is a class
called httpd::service, which accepts a couple of parameters:
class httpd::service (
$running = 'running',
$enabled = 'true',
) {
service { "httpd":
path => "/etc/init.d/httpd",
ensure=> $running,
enable=> $enabled,
require => [ Package[ "httpd" ], File[ "/etc/httpd/conf/httpd.conf" ] ],
subscribe => File[ "/etc/httpd/conf/httpd.conf" ],
}
}
But let's say that I want to allow the option of both requiring and
subscribing to a second file -- any file -- in addition to httpd.conf.
If I were doing this in a procedural language, I'd probably do
something naive and create a couple of empty parameters called
$also_subscribed and $myfile_path, use a conditional to see if it's
defined, then create the arguments to require and subscribe based on
that.
I cannot figure out how to get this done in puppet. Any help is
appreciated, even a link to an appropriate doc or example. Thanks!
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Hostname fact doesn't handle hostnames with periods
You can effectively override a fact by setting the weight, as follows Facter.add(:hostname) do has_weight 200 setcode do # your own hostname implementation end end On Fri, Oct 7, 2011 at 12:57 PM, Matthew Black wrote: > You are confusing Standards (RFC) and POSIX. They are typically mutually > exclusive in their roles. > RFC dictates the standards the information should be presented. POSIX > dictates the API that the information is obtained. The difference can be > plainly seen in message protocols, like > smtp. http://nemo.its.uiowa.edu/reference/sendmail-rfc.html > I would rather facter had a way to override fact definitions, so I could use > custom facts for things like hostname. > Instead of having Facter.add(:hostname) it would be > Facter.replace(:hostname), then the problem would be solved by creating a > custom hostname and domain facts for people who want to go against the > standards. In fact the idea of replacing facts with custom facts might be > handy in other situations and I vote to have that added instead of changing > how facter pulls information. > Although until sometime as that is in place you can always modify the > hostname.rb and domain.rb in facter lib to present the data the way you want > it for your environment. > > > On Fri, Oct 7, 2011 at 11:54 AM, easybeats wrote: >> >> Hi Tim, >> >> > IMO, you've got to be clear what the underlying information model that >> > puppet / facter supports is. In particular, if you simply say that the >> > facts are the data reported by the underlying tools, then you've got >> > zero abstraction of the model and it's 'an exercise for the user to >> > handle the differences between platforms. >> >> I agree with you there needs to be clarity as to what standard/ >> information model is to be supported. To me there are two standards in >> operation here and an assumption being made. >> >> At this time to me DNS is assumed to be the only valid overarching >> "directory service" and "naming standard". >> >> POSIX the underlying Unix standard makes no such assumptions as to >> which overarching directory service or naming standard will be in >> operation. Hypothetically should a site admin choose to support WINS >> (heaven forbid) or some other standard, POSIX which has portability in >> mind caters for that. I concede DNS is the most widely used directory >> standard, naming service around but it is still an assumption. >> >> If DNS is the only valid naming standard that can apply to the >> hostname is to the exclusion of IEEE Std 1003.1-2008 (POSIX:2008) >> which to my knowledge doesn't comment on the restriction of character >> sets for hostnames, so currently puppet at this point in time can not >> report on a POSIX compliant hostname from the Kernel if it contains a >> period (.). (NB if puppet were to support this I'm suggesting a >> different fact so as to not interfer with current operations) >> >> http://pubs.opengroup.org/onlinepubs/9699919799/functions/uname.html >> >> If to support multiplatform (IE Windows), one must allow for and >> consider other valid directory naming standards and directory services >> and or the underlying OS standard. >> >> > Alternatively, you can >> > define a canonical ontology and how the different tools map onto that >> > ontology. Even with such an ontology, you probably need to include >> > platform specific types in the data model. >> > fwiw, I'm also a big fan of encouraging best practice in the use of >> > the tools, so in this instance, the teaching/documentation would show >> > how to avoid naming pitfalls introduced by differences in standards >> > and how to remediate an environment that's fallen into such a trap. >> > Otherwise, the tools get bogged down in handling nasty >> > inconsistencies, which are impossible to cope with cleanly in code as >> > they depend on implicit or explicit customer organisational policies - >> > and the tool gets blamed for any shortfalls, while the organisation >> > keeps digging itself deeper into the trap. >> >> I agree with promoting best practice, however which standard(s) is/are >> to be supported on a given platform should be taken into account. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To post to this group, send email to puppet-users@googlegroups.com. >> To unsubscribe from this group, send email to >> puppet-users+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > -- You received this message because you are subscribed to the Google Groups "Pup
Re: [Puppet Users] Exec {rake db:mgirate } not working
One thing you might want to try, which could resolve the issue is use cwd
meta for exec. I would also split the actions up, like below, with
refreshonly meta set to true so it doesnt execute them on every puppet run.
You would need a resource that would trigger them, like package install or
something.
exec { "redmine-db-migrate":
command => "rake db:migrate",
refreshonly => true
}
exec { "redmine-install-gems":
command => "rake gems:install",
refreshonly => true,
notify => Exec[redmine-db-migrate]
}
On Fri, Oct 7, 2011 at 5:03 PM, damniamgood wrote:
> Hello,
>I have master and agent puppet server setup and i am running
> the manifest which includes the exec block
>
> exec{"install-gems":
> command => "cd /opt/redmine/current && rake gems:install && rake
> db:migrate",
> }
>
>
> When i run on the client side , the execution of the install-gems
> fails and returns non-zero.
>
> Can you possibly tell the reason ?
>
> Is there any other way to handle this.?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Problems with exported resources after upgrade to 2.7.5
This should be fixed in 2.7.6rc2. Please test. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Announce: Puppet 2.7.6rc2 available
Puppet 2.7.6rc2 is available. This release candidate fixes issues undercovered with using storedconfigs. Release Notes for 2.7.6 series -- https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes This release is available for download at: http://downloads.puppetlabs.com/puppet/ See the Verifying Puppet Download section at: http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet Please report feedback via the Puppet Labs Redmine site, using an affected version of 2.7.6rc2 http://projects.puppetlabs.com/projects/puppet Documentation is available at: http://docs.puppetlabs.com/index.html Changes since RC1. (#9832) General StoreConfigs regression. The previous fixes around PostgreSQL were not complete in addressing the regression: some StoreConfigs exported and imported resources would not be found. This removes the last bits that were causing regressions, and additional testing shows that the generated SQL is now identical between 2.7.3 and the current version. This should resolve all the remaining regressions. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Problem with custom function returning array
Hi,
I'm trying create a custom function that will return an array of file
paths for the file type source. Instead of defining the following
array for source for each file type:
file: { "some_file":
source => [ "puppet:///file/$hostname/path", "puppet:///file/$role/
$mode/path", "puppet:///file/$role/path", "puppet:///file/common/
path", ],
...
}
I've created a custom function to return the generated array similar
to the following:
file: { "some_file":
source => find_file(path),
...
}
I'm getting the following message on the client:
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Function 'find_file' does not return a value at /etc/puppet/
manifests/class/sudo.pp:12 on node tnfs01
The function is located at /var/lib/puppet/lib/puppet/parser/functions/
find_file.rb.
Function:
module Puppet::Parser::Functions
newfunction(:find_file, :type => :rvalue) do |args|
filename = args[0]
hostname = lookupvar('hostname')
role = lookupvar('role')
mode = lookupvar('mode')
sources = Array.new
sources << "puppet:///files/#{hostname}/#{filename}"
sources << "puppet:///files/#{role}/#{mode}/#{filename}"
sources << "puppet:///files/#{role}/#{filename}"
sources << "puppet:///files/common/#{filename}"
return sources
end
end
Not sure what I'm doing wrong here. Any help would be greatly
appreciated. Also, if there's already a built-in way to do this in
Puppet I'd gladly ditch the custom function, although I'd still like
to figure out the problem for future reference.
Thanks,
Nate
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Exec {rake db:mgirate } not working
Hello,
I have master and agent puppet server setup and i am running
the manifest which includes the exec block
exec{"install-gems":
command => "cd /opt/redmine/current && rake gems:install && rake
db:migrate",
}
When i run on the client side , the execution of the install-gems
fails and returns non-zero.
Can you possibly tell the reason ?
Is there any other way to handle this.?
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] More cloud provisioner stuff
I'm still having some issues with cloud provisioner. I have a fresh
install of provisioner, .60rc1, puppet 2.7.3, and dashboard 1.2.0.
Everything has a very default install as described in the
documentation. I was unable to get bootstrap to work, so I did things
in a linear fashion (create, install, classify). Classify is failing
and theres not really any good debug info, I just get this:
root@ip-10-36-11-244:/etc/puppet/manifests# puppet node install
ec2-50-19-149-210.compute-1.amazonaws.com --login root --keyfile /
root/.ssh/puppet.pem --install-script gems --puppet-version 2.7.5
notice: Waiting for SSH response ...
notice: Waiting for SSH response ... Done
notice: Installing Puppet ...
info: access[^/catalog/([^/]+)$]: allowing 'method' find
info: access[^/catalog/([^/]+)$]: allowing $1 access
info: access[^/node/([^/]+)$]: allowing 'method' find
info: access[^/node/([^/]+)$]: allowing $1 access
info: access[/certificate_revocation_list/ca]: allowing 'method' find
info: access[/certificate_revocation_list/ca]: allowing * access
info: access[/report]: allowing 'method' save
info: access[/report]: allowing * access
info: access[/file]: allowing * access
info: access[/certificate/ca]: adding authentication no
info: access[/certificate/ca]: allowing 'method' find
info: access[/certificate/ca]: allowing * access
info: access[/certificate/]: adding authentication no
info: access[/certificate/]: allowing 'method' find
info: access[/certificate/]: allowing * access
info: access[/certificate_request]: adding authentication no
info: access[/certificate_request]: allowing 'method' find
info: access[/certificate_request]: allowing 'method' save
info: access[/certificate_request]: allowing * access
info: access[/]: adding authentication any
info: access[/certificate_status]: allowing 'method' save
info: access[/certificate_status]: adding authentication yes
info: access[/certificate_status]: allowing * access
info: Inserting default '/status'(auth) ACL because none were found in
'/etc/puppet/auth.conf'
info: Inserting default '/resource'(auth) ACL because none were found
in '/etc/puppet/auth.conf'
info: Could not find certificate for '2c96865c-deb0-a646-2d94-
c4287f72650f'
info: Could not find certificate_request for '2c96865c-deb0-a646-2d94-
c4287f72650f'
notice: 2c96865c-deb0-a646-2d94-c4287f72650f has a waiting certificate
request
notice: Signed certificate request for 2c96865c-deb0-a646-2d94-
c4287f72650f
notice: Removing file Puppet::SSL::CertificateRequest 2c96865c-deb0-
a646-2d94-c4287f72650f at '/etc/puppet/ssl/ca/requests/2c96865c-deb0-
a646-2d94-c4287f72650f.pem'
2c96865c-deb0-a646-2d94-c4287f72650f
root@ip-10-36-11-244:/etc/puppet/manifests# puppet node classify
ec2-50-19-149-210.compute-1.amazonaws.com --mode agent --node-
group=puppet-agentsnotice: Registering node ...
err: Connection reset by peer
err: Try 'puppet help node classify' for usage
nothing shows up in dashboard, a check of the syslog on the client
reveals:
Oct 6 19:50:19 domU-12-31-39-0C-10-C7 puppet-agent[1279]: (/File[/var/
lib/puppet/lib/puppet/face/node/terminate.rb]/ensure) defined content
as '{md5}58a4dadeb4194a3cb285f1d2ec582bd2'
Oct 6 19:50:19 domU-12-31-39-0C-10-C7 puppet-agent[1279]: Loading
downloaded plugin /var/lib/puppet/lib/puppet/cloudpack.rb
Oct 6 19:50:19 domU-12-31-39-0C-10-C7 puppet-agent[1279]: Could not
load downloaded file /var/lib/puppet/lib/puppet/cloudpack.rb: no such
file to load -- guid
Oct 6 19:50:19 domU-12-31-39-0C-10-C7 puppet-agent[1279]: Loading
downloaded plugin /var/lib/puppet/lib/puppet/face/node/classify.rb
Oct 6 19:50:19 domU-12-31-39-0C-10-C7 puppet-agent[1279]: Could not
load downloaded file /var/lib/puppet/lib/puppet/face/node/classify.rb:
no such file to load -- guid
Oct 6 19:50:19 domU-12-31-39-0C-10-C7 puppet-agent[1279]: Loading
downloaded plugin /var/lib/puppet/lib/puppet/face/node/terminate.rb
Oct 6 19:50:19 domU-12-31-39-0C-10-C7 puppet-agent[1279]: Could not
load downloaded file /var/lib/puppet/lib/puppet/face/node/
terminate.rb: no such file to load -- guid
Oct 6 19:50:19 domU-12-31-39-0C-10-C7 puppet-agent[1279]: Loading
downloaded plugin /var/lib/puppet/lib/puppet/face/node/init.rb
Oct 6 19:50:19 domU-12-31-39-0C-10-C7 puppet-agent[1279]: Could not
load downloaded file /var/lib/puppet/lib/puppet/face/node/init.rb: no
such file to load -- guid
Oct 6 19:50:19 domU-12-31-39-0C-10-C7 puppet-agent[1279]: Loading
downloaded plugin /var/lib/puppet/lib/puppet/cloudpack/scripts/puppet-
enterprise.erb
Oct 6 19:50:19 domU-12-31-39-0C-10-C7 puppet-agent[1279]: Could not
load downloaded file /var/lib/puppet/lib/puppet/cloudpack/scripts/
puppet-enterprise.erb: /var/lib/puppet/lib/puppet/cloudpack/scripts/
puppet-enterprise.erb:6: unterminated string meets end of file
Oct 6 19:50:19 domU-12-31-39-0C-10-C7 puppet-agent[1279]: Loading
downloaded plugin /var/lib/puppet/lib/puppet/face/node/fingerprint.rb
Oct 6 19:50:19 domU-12-31-39-0C-10-C7 puppet-agent[1279]: Could not
load downloaded
[Puppet Users] Cloud Provisioner: What works and what doesn't work?
Hi all, I'm very excited about using puppet cloud provisioner to spin up new EC2 instances and have puppet auto-installed on them and then get them to play their part by getting them classified using either puppet master or puppet dashboard, so that each node will install all the appropriate packages according to their roles. However, I'm running into some troubles. Using puppet v2.7.3 with cloud provisioner, I get some unexpected errors from the various commands I try to run: # puppet node bootstrap --image ami- --keypair puppet --login root --keyfile /root/.ssh/puppet.pem --certname mypuppetmaster.mydomain.com --type t1.micro notice: Creating new instance ... notice: Creating new instance ... Done notice: Creating tags for instance ... notice: Creating tags for instance ... Done notice: Launching server i-12341234 ... ### notice: Server i-12341234 is now launched notice: Server i-12341234 public dns name: ec2-XX-XX-XXX- XXX.compute-1.amazonaws.com notice: Waiting for SSH response ... notice: Waiting for SSH response ... Done notice: Installing Puppet ... notice: Puppet is now installed on: ec2-XX-XX-XXX- XXX.compute-1.amazonaws.com notice: Signing certificate ... err: Unknown options passed: image, keyfile, keypair, login, type err: Try 'puppet help node bootstrap' for usage It complains that some required options are unknown: image, keyfile, login, type Clearly, I'm passing in those options, and it did spin up an instance, and apparently installed puppet on it. Should I ignore such errors, or is this an indication that something is wrong in my setup? Thanks! -Eivind -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Open Source Team iteration & planning summary 2011-10-07
Good news, everyone! The Windows work is (nearly) done. There are a
couple of topic branches that are left to review and merge but other
than these we're back to our regularly scheduled program/backlog.
Currently, the plan is to divide our effort roughly equally between
catching back up on reviewing the changes that have been submitted so
far (both from the list in Patchwork[1], and the pull requests opened in
the various repositories on GitHub) and the backlog listed at the end of
this email.
Changes since last time:
Ricky Zhou provided the security fix for CVE-2011-3870 (#9790).
Puppet will now drop privileges before creating and chmoding SSH
keys. This has been released in several versions of Puppet, with
further details available in the ticket.
Erik Hermansen discovered CVE-2011-3848 which consists of a
directory traversal attack. This has been fixed in released
versions, with further details available in the release
announcement[2].
A Ruby 1.9 compatibility fix was provided by Whyme Lyu (commit
8b6a775b). This addresses a behavior change in Array#join between
Ruby 1.8 and 1.9. This has been merged into the 2.7.x branch and is
available in 2.7.6rc1.
Puppet no longer raises an exception trying to retrieve the exit
status of a failed command on Windows (#8410). Previously Puppet
was trying to call #exitstatus on the raw Fixnum when on Windows.
This has been merged into the 2.7.x branch, and is available in
2.7.6rc1.
Puppet agent reports that it cannot daemonize on Windows (and
defaults to not daemonizing) rather than erroring (#9329). This has
been merged into the 2.7.x branch and is available in 2.7.6rc1.
Puppet file log destinations now properly recognize absolute Windows
paths (#9435). This has been merged into the 2.7.x branch and is
available in 2.7.6rc1.
Puppet no longer attempts to log to syslog on Windows (#9435). Log
destinations are now able to tell Puppet whether they are suitable
or not when attempting to register them. This has been merged into
the 2.7.x branch and is available in 2.7.6rc1.
Puppet now supports managing password in the Windows user provider
(#9326). Currently this requires that passwords be specified in
plain-text in the manifest. This has been merged into the 2.7.x
branch and is available in 2.7.6rc1.
There is a new internal (library) method for handling retrieval of
local user and group SIDs given a user or group name (#9328). This
has been merged into the 2.7.x branch and is available in 2.7.6rc1.
Puppet again handles running "puppet" without any arguments or
running "puppet ${unknown_subcommand}" properly (#9458). Previously
Puppet would raise an undefined method error due to
Puppet::Util.which attempting to use
Puppet.features.microsoft_windows?. This has been merged into 2.7.x
and is available in 2.7.6rc1.
There have been several improvements around the file type &
providers, as well as their behavior on Windows. These changes
include clean-up and increased coverage of the unit & integration
tests, improved handling of paths, improved handling of file and
directory modes, among others. The full changes can be viewed in
the commit range ec587b44^1..ec587b44^2. This has been merged into
2.7.x and is available in 2.7.6rc1.
The groupadd provider no longer needlessly warns about not being
able to manage the ia_load_module attribute (#9027). This is a
mirror of the fix for #7137 (same problem with the useradd
provider). This has been merged into the 2.7.x branch and is
available in 2.7.6rc1.
Puppet now supports managing Scheduled Tasks on Windows through the
new scheduled_task type (#8414). This has been merged into the
2.7.x branch and is scheduled to be available after the 2.7.6 RC
series.
[1] https://patchwork.puppetlabs.com
[2]
http://groups.google.com/group/puppet-users/browse_thread/thread/e57ce2740feb9406/66bfcbfb43533736
Completed items:
* #8410 - Exec provider for Windows
* #9329 - Puppet agent daemonize option doesn't work on Windows
* #9435 - Log destinations are broken on Windows
* #9326 - Password management on windows
* #9328 - Retrieve user and group SIDs on windows
* #9458 - Puppet fails to run when no subcommand specified
* #9027 - groupadd provider throws spurious warnings about AIX feature on
non-AIX platforms.
* #8414 - Task scheduler type/provider for Windows
* #9459 - (Review) Puppet fails to create user when groups are specified
* #8411 - File type working on Windows
* #9460 - Puppet agent fails if the PuppetLabs/puppet directory doesn't exist
on Windows
* #9461 - Puppet resource package fails on Windows
Current backlog:
* #7316 - puppet applications delivered via pluginsync don't work.
* #5517 - Overriding parameters on included & inherited classes
* #3741 - Custom facts loaded multiple times
* #4916 - Plugins should not be able to override core functionality.
* #778
[Puppet Users] Re: Trigger when on any package change
One option would be to create a define to use as a wrapper around
"package". Something like this:
define package::special($ensure) {
package { $name:
ensure => $ensure,
}
exec { "rkhunter-$name":
command => "rkhunter --propupd",
refreshonly => true
subscribe => Package[$name],
}
}
Then you'd just use package::special, instead of package by itself:
package::special { "openssh":
ensure => latest,
}
On Sep 29, 12:22 pm, GeekBiker wrote:
> I need to exec a program if ANY packages have been modified (added,
> removed, updated, etc). I tried subscribing to Package with a
> wildcard, but that isn't supported.
>
> Is there any way to trigger an exec if there were any packages changes
> were made or if yum was executed?
>
> Specifically, I need to execute "rkhunter --propupd" so we will stop
> getting false alarms whenever we update a bunch of systems.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Hostname fact doesn't handle hostnames with periods
You are confusing Standards (RFC) and POSIX. They are typically mutually exclusive in their roles. RFC dictates the standards the information should be presented. POSIX dictates the API that the information is obtained. The difference can be plainly seen in message protocols, like smtp. http://nemo.its.uiowa.edu/reference/sendmail-rfc.html I would rather facter had a way to override fact definitions, so I could use custom facts for things like hostname. Instead of having Facter.add(:hostname) it would be Facter.replace(:hostname), then the problem would be solved by creating a custom hostname and domain facts for people who want to go against the standards. In fact the idea of replacing facts with custom facts might be handy in other situations and I vote to have that added instead of changing how facter pulls information. Although until sometime as that is in place you can always modify the hostname.rb and domain.rb in facter lib to present the data the way you want it for your environment. On Fri, Oct 7, 2011 at 11:54 AM, easybeats wrote: > Hi Tim, > > > IMO, you've got to be clear what the underlying information model that > > puppet / facter supports is. In particular, if you simply say that the > > facts are the data reported by the underlying tools, then you've got > > zero abstraction of the model and it's 'an exercise for the user to > > handle the differences between platforms. > > I agree with you there needs to be clarity as to what standard/ > information model is to be supported. To me there are two standards in > operation here and an assumption being made. > > At this time to me DNS is assumed to be the only valid overarching > "directory service" and "naming standard". > > POSIX the underlying Unix standard makes no such assumptions as to > which overarching directory service or naming standard will be in > operation. Hypothetically should a site admin choose to support WINS > (heaven forbid) or some other standard, POSIX which has portability in > mind caters for that. I concede DNS is the most widely used directory > standard, naming service around but it is still an assumption. > > If DNS is the only valid naming standard that can apply to the > hostname is to the exclusion of IEEE Std 1003.1-2008 (POSIX:2008) > which to my knowledge doesn't comment on the restriction of character > sets for hostnames, so currently puppet at this point in time can not > report on a POSIX compliant hostname from the Kernel if it contains a > period (.). (NB if puppet were to support this I'm suggesting a > different fact so as to not interfer with current operations) > > http://pubs.opengroup.org/onlinepubs/9699919799/functions/uname.html > > If to support multiplatform (IE Windows), one must allow for and > consider other valid directory naming standards and directory services > and or the underlying OS standard. > > > Alternatively, you can > > define a canonical ontology and how the different tools map onto that > > ontology. Even with such an ontology, you probably need to include > > platform specific types in the data model. > > fwiw, I'm also a big fan of encouraging best practice in the use of > > the tools, so in this instance, the teaching/documentation would show > > how to avoid naming pitfalls introduced by differences in standards > > and how to remediate an environment that's fallen into such a trap. > > Otherwise, the tools get bogged down in handling nasty > > inconsistencies, which are impossible to cope with cleanly in code as > > they depend on implicit or explicit customer organisational policies - > > and the tool gets blamed for any shortfalls, while the organisation > > keeps digging itself deeper into the trap. > > I agree with promoting best practice, however which standard(s) is/are > to be supported on a given platform should be taken into account. > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Hostname fact doesn't handle hostnames with periods
Hi Tim, > IMO, you've got to be clear what the underlying information model that > puppet / facter supports is. In particular, if you simply say that the > facts are the data reported by the underlying tools, then you've got > zero abstraction of the model and it's 'an exercise for the user to > handle the differences between platforms. I agree with you there needs to be clarity as to what standard/ information model is to be supported. To me there are two standards in operation here and an assumption being made. At this time to me DNS is assumed to be the only valid overarching "directory service" and "naming standard". POSIX the underlying Unix standard makes no such assumptions as to which overarching directory service or naming standard will be in operation. Hypothetically should a site admin choose to support WINS (heaven forbid) or some other standard, POSIX which has portability in mind caters for that. I concede DNS is the most widely used directory standard, naming service around but it is still an assumption. If DNS is the only valid naming standard that can apply to the hostname is to the exclusion of IEEE Std 1003.1-2008 (POSIX:2008) which to my knowledge doesn't comment on the restriction of character sets for hostnames, so currently puppet at this point in time can not report on a POSIX compliant hostname from the Kernel if it contains a period (.). (NB if puppet were to support this I'm suggesting a different fact so as to not interfer with current operations) http://pubs.opengroup.org/onlinepubs/9699919799/functions/uname.html If to support multiplatform (IE Windows), one must allow for and consider other valid directory naming standards and directory services and or the underlying OS standard. > Alternatively, you can > define a canonical ontology and how the different tools map onto that > ontology. Even with such an ontology, you probably need to include > platform specific types in the data model. > fwiw, I'm also a big fan of encouraging best practice in the use of > the tools, so in this instance, the teaching/documentation would show > how to avoid naming pitfalls introduced by differences in standards > and how to remediate an environment that's fallen into such a trap. > Otherwise, the tools get bogged down in handling nasty > inconsistencies, which are impossible to cope with cleanly in code as > they depend on implicit or explicit customer organisational policies - > and the tool gets blamed for any shortfalls, while the organisation > keeps digging itself deeper into the trap. I agree with promoting best practice, however which standard(s) is/are to be supported on a given platform should be taken into account. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Concat::Fragment collection broken in 2.7.5
Hello, sorry for the delay, I did a few tests and found out that the puppet master does not even go as far a querying the database. Starting from a clean query log (mysql), there is no sign of Concat::Fragment (tried small case as well). I guess this info also applies to the post "Problems with exported resources after upgrade to 2.7.5". -- Bruno -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: how to modify a parameter inside a parametrized class
On Fri, 7 Oct 2011 06:34:00 -0700 (PDT)
jcbollinger jcbollinger wrote:
> On Oct 7, 8:11 am, Arnau Bria wrote:
> > On Fri, 7 Oct 2011 05:55:34 -0700 (PDT)
> >
> > jcbollinger jcbollinger wrote:
> > > While I'm on this topic, I'll throw in that I would find it
> > > terribly confusing if a class or definition failed to honor my
> > > specification for a parameter named 'ensure'.
> >
> > Sorry John, but I don't understand this point.
>
> Because of the consistent manner of "ensure" parameters' use in
> Puppet's built-in resources, and the associated conventions even for
> custom and defined types, I would be very surprised if I ever declared
> something with "ensure => 'absent'" but that specification was
> overridden to the opposite. Indeed, I would be at least somewhat
> surprised by that with *any* parameter. Don't give me the option if
> you don't intend to honor it.
Ok, now it's clear.
I should put that logic outside the class, in node/param definitions ..
something like:
if ($::kernel=='Linux') and ($::lsbmajdistrelease=='6') {
class { 'common::nrpe' :
ensure => absnet,
}else{
class { 'common::nrpe' :
ensure => present,
}
> Inasmuch as this is for testing purposes, however, that's a different
> story. I don't think I would test in the way you are doing, but then
> again, maybe I would.
>
> John
>
Many thanks for your reply,
Arnau
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: how to modify a parameter inside a parametrized class
On Oct 7, 8:11 am, Arnau Bria wrote: > On Fri, 7 Oct 2011 05:55:34 -0700 (PDT) > > jcbollinger jcbollinger wrote: > > While I'm on this topic, I'll throw in that I would find it terribly > > confusing if a class or definition failed to honor my specification > > for a parameter named 'ensure'. > > Sorry John, but I don't understand this point. Because of the consistent manner of "ensure" parameters' use in Puppet's built-in resources, and the associated conventions even for custom and defined types, I would be very surprised if I ever declared something with "ensure => 'absent'" but that specification was overridden to the opposite. Indeed, I would be at least somewhat surprised by that with *any* parameter. Don't give me the option if you don't intend to honor it. Inasmuch as this is for testing purposes, however, that's a different story. I don't think I would test in the way you are doing, but then again, maybe I would. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Feature 4815: Allow Mount to create a mount point and set the under lying permission?
On Thu, Oct 6, 2011 at 11:22 PM, Stefan Schulte
wrote:
>
> You could create the mountpoint with an exec resource. Like
>
> define mymount (.) {
> exec { "create_${name}":
> command => "/bin/mkdir -m 0755 ${name}",
> creates => $name,
> }
> mount { $name:
> ...
> require => Exec["create_${name}"],
> }
> }
>
> You can now use a file resource to set e.g. owner and group on the
> mounted path.
Ah, yes that would work well, at least in the short term.
--
Jeff Ollie
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: how to modify a parameter inside a parametrized class
On Fri, 7 Oct 2011 05:55:34 -0700 (PDT)
jcbollinger jcbollinger wrote:
Hi John,
> You are misunderstanding that Puppet variables' values can never be
> reassigned. Once a variable has a value, it never changes throughout
> the compilation of that catalog. This is an aspect of Puppet DSL's
> declarative nature.
>
> As to how to accomplish what you ask, the usual way would be to use
> the parameter and any other data you want to select the value of a
> *different* variable, and then use that second variable. The same
> thing is fairly common practice in defined types:
>
> class common::nrpe($ensure='absent') {
> [...]
>
> if ($::kernel=='Linux') and ($::lsbmajdistrelease=='6') {
> $really_ensure = 'present'
> } else {
> $really_ensure = $ensure
> }
>
> [...]
>
> }
Ok, I solved the issue with something like that but I thought it was
some kind of ugly workaround... but if it's common I feel better with my
code.
> While I'm on this topic, I'll throw in that I would find it terribly
> confusing if a class or definition failed to honor my specification
> for a parameter named 'ensure'.
Sorry John, but I don't understand this point.
> I'd also find it confusing, though
> less so, for the default value of an 'ensure' parameter to be
> 'absent'. I recommend that you tweak your design a bit so as to not
> leave little traps like those for yourself and others to stumble over
> later. Or at least document the wazoo out of that thing.
I'm playing with this class. First time I do something like above.
Our production services have a default present, but this one is still
in test and I'd like to test it only on Linux 6., so I was playing with
logic inside new class :-)
> John
Many thanks for your reply,
Arnau
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: I can't seem to create mountpoint and change permissions after mounting in 2.7.3
On Oct 5, 10:54 pm, Chris McDermott wrote: > I haven't used them yet, but isn't this what stages are meant to facilitate? > > http://docs.puppetlabs.com/references/stable/metaparameter.html#stage Run stages are syntactic sugar. There is nothing you can do with them that you cannot also do with explicit class and resource relationships. A little bit of candy is good for the psyche, and their sugary nature does not predispose me against run stages. They are nice as an organizational mechanism, and somewhat for self-documentation. On the other hand, I don't care for parameterized classes at all, and you cannot use run stages without them. In this case, run stages do nothing whatever to address the problem that you cannot manage properties of a mount point while a filesystem is mounted on it. You still cannot see the underlying directory. Moreover, Puppet's prohibition against duplicate resources extends across all run stages. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: how to modify a parameter inside a parametrized class
On Oct 7, 6:05 am, Arnau Bria wrote:
> Hi all,
>
> I think I'm not understanding something...
>
> fromhttp://docs.puppetlabs.com/guides/parameterized_classes.html:
>
> "The parameters you name can be used as normal local variables
> throughout the class definition"
>
> so, I have a class like:
>
> class common::nrpe($ensure='absent') {
> [...]
>
> if ($::kernel=='Linux') and ($::lsbmajdistrelease=='6') {
> $ensure='present'
>
> }
>
> so, by default the class is dissabled, but if it's a Linux release 6,
> the value must be present.
>
> so, I define the class in a Linux release 6 like:
>
> nodes 'test' {
> class { 'common::nrpe' : }
>
> }
>
> pupet fails with error:
>
> Cannot reassign variable ensure
>
> So, what am I missunderstanding? What is the correct way for doing what
> I'm trying?
You are misunderstanding that Puppet variables' values can never be
reassigned. Once a variable has a value, it never changes throughout
the compilation of that catalog. This is an aspect of Puppet DSL's
declarative nature.
As to how to accomplish what you ask, the usual way would be to use
the parameter and any other data you want to select the value of a
*different* variable, and then use that second variable. The same
thing is fairly common practice in defined types:
class common::nrpe($ensure='absent') {
[...]
if ($::kernel=='Linux') and ($::lsbmajdistrelease=='6') {
$really_ensure = 'present'
} else {
$really_ensure = $ensure
}
[...]
}
While I'm on this topic, I'll throw in that I would find it terribly
confusing if a class or definition failed to honor my specification
for a parameter named 'ensure'. I'd also find it confusing, though
less so, for the default value of an 'ensure' parameter to be
'absent'. I recommend that you tweak your design a bit so as to not
leave little traps like those for yourself and others to stumble over
later. Or at least document the wazoo out of that thing.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] how to modify a parameter inside a parametrized class
Hi all,
I think I'm not understanding something...
from http://docs.puppetlabs.com/guides/parameterized_classes.html :
"The parameters you name can be used as normal local variables
throughout the class definition"
so, I have a class like:
class common::nrpe($ensure='absent') {
[...]
if ($::kernel=='Linux') and ($::lsbmajdistrelease=='6') {
$ensure='present'
}
so, by default the class is dissabled, but if it's a Linux release 6,
the value must be present.
so, I define the class in a Linux release 6 like:
nodes 'test' {
class { 'common::nrpe' : }
}
pupet fails with error:
Cannot reassign variable ensure
So, what am I missunderstanding? What is the correct way for doing what
I'm trying?
TIA,
Arnau
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] puppet 2.7.5 and augeas break grub.conf on RHEL5
Hi,
I was running puppet (2.7.5) on a host which needed to have some
settings changed in it's /boot/grub/menu.lst file. This file is
however a link to /boot/grub/grub.conf
When I used augeas in puppet like shown below
augeas { "${dom0::params::module_label}_menu.lst_memory": incl => '/
boot/grub/menu.lst', lens => 'Grub.lns', changes => [ 'set title[1]/
kernel/dom0_mem 2G', 'set title[last()]/kernel/dom0_mem 2G', ], }
it updated the menu.lst, but menu.lst is now a file and not a link
anymore to grub.conf
After changing the puppet module to incl => '/boot/grub/grub.conf',
augeas handled it well
Was this a mistake my side that I included a link instead of a real
file, or is this someting that changed in augeas. I have used this
setup for a long time now and on older servers the link was not
broken.
I use the following software
# augeas-0.8.1-2.el5 # augeas-libs-0.8.1-2.el5 # ruby-
augeas-0.4.1-1.el5 # puppet-2.7.5-1.el5
Rene
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
