Re: [Puppet Users] duplicate definition error
On 19/12/11 16:36, Chris Blumentritt wrote:
> I have an error that I do not understand. I get a duplicate
> definition and I am not sure why: http://pastie.org/3041278
>
> if I change line 27 in that paste from class { 'passenger': } to
> include passenger, there is not an error but the passenger class (it
> is a module) is not evaluated.
>
> Does having module foo that contains a class, foo:bar::baz and then
> including another module named, baz cause this?
>
> I tested with puppet 2.7.9, 2.7.8 and 2.7.3
>
Basically, yes. It's all to do with how unqualified variables are resolved.
Try "class { '::passenger': }" instead to qualify the class as being in
the root scope.
HTH
Dan
--
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] mount type is constantly remounting
On 15/09/11 07:59, slune wrote:
> Hi,
>
> I have defined mount resource like this:
>
> mount { "/mnt/test/":
> device => "//test/test",
> fstype => cifs,
> ensure => mounted,
> options=> "defaults,acl,soft,uid=test,gid=test=x","
> remounts => true,
> }
>
> For the first time (mount point is not mounted) it mounts perfectly,
> but after that it keeps mounting to that mount point with every puppet
> client run and piling up mounts. After while I have many the same
> mounts on this mount point. For now I've changed ensure => present,
> but this is not ideal. Is there any way how prevent this behaviour.
Remove the / at the end of the "/mnt/test/". Basically a mismatch on
what the list of mounted devices returns and what puppet is looking for.
See Stefan Schulte's reply in this thread for more verbose details:
http://groups.google.com/group/puppet-users/browse_thread/thread/c6cb361ba7da32f2/5e305ca7ddbbabb8
Dan
--
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] list of puppet-agents
On 10/08/11 11:16, Sans wrote: > Dear all, > > Is there any why to get the list of the nodes are currently being > managed by puppet? I know that I can do that looking in the "$vardir/ > ssl/ca/signed" directory but i was wondering if puppet master itself > provides some mechanism. I'm running v2.6.6. Cheers!! You'll want to set up reporting. This will also tell you when a node has stopped reporting or is otherwise struggling. Have a read through http://docs.puppetlabs.com/guides/reporting.html . You'll also probably want a pretty web frontend like Puppet Dashboard (http://www.puppetlabs.com/puppet/related-projects/dashboard/) or The Foreman (http://theforeman.org/) Dan -- 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] Facter 1.6.0 and CentOS 6.0
On 30/07/11 05:26, Derek J. Balling wrote: > We just started testing CentOS 6.0 here, and I'm using Facter 1.6.0 > > If I run this command from my CentOS 5.x test machine: > > [root@puppetclient.nj1:~]# facter --version > 1.6.0 > [root@puppetclient.nj1:~]# facter | grep lsb > lsbdistcodename => Final > lsbdistdescription => CentOS release 5.3 (Final) > lsbdistid => CentOS > lsbdistrelease => 5.3 > lsbmajdistrelease => 5 > lsbrelease => > :core-3.1-amd64:core-3.1-ia32:core-3.1-noarch:graphics-3.1-amd64:graphics-3.1-ia32:graphics-3.1-noarch > > I get reasonable results. But if I do that from my CentOS 6.0 test machine: > > [root@cos6test.nj1:~]# facter --version > 1.6.0 > [root@cos6test.nj1:~]# facter | grep lsb > [root@cos6test.nj1:~]# > > I get remarkably less kosher results. > > Is this a known issue? Is there any work-around? It's really breaking my > CentOS 6 servers' ability to find their REPOs. :-) You need to have the lsb_release command installed for the lsb* results to appear. Fedora/Redhat have it in the redhat-lsb package, so it possibly has a similar name under CentOS. HTH, Dan -- 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] Deployed but unmanaged file
On 29/06/11 16:34, Craig White wrote:
> This seems to work but it does seem perilous and ugly. A meta description of
> what I am trying to do is:
> - install firebird sql server
> - replace the 'security' file with a known file
> - restart the firebird service
>
> I'm not going to include firebird::install class because the part that
> worries me is that I can't work on /var/lib/firebird/2.1/system/security.fdb
> directly because we will want to maintain it locally after installation. I
> only want a single shot deploy. So I am linking to /root/security.fdb and
> then copying it from there to it's home. I suppose there is a much better way
> to do this but I haven't found it.
>
> My worry is that I never actually overwrite
> /var/lib/firebird/2.1/system/security.fdb after the initial install/configure
> phase is completed.
>
> class firebird::configure {
> file {"/root/security.fdb":
> source => "puppet:///modules/firebird/security.fdb",
> owner=> root,
> group=> root,
> mode => 640,
> replace => false,
> }
> exec { "Copy KNOWN security.fdb into position":
> path=> "/usr/local/bin:/usr/local/sbin:/bin:/usr/bin",
> environment => "HOME=/root",
> command => "/bin/cp /root/security.fdb /var/lib/firebird/2.1/system",
> user=> "root",
> group => "root",
> logoutput => on_failure,
> require => Class["firebird::install"],
> }
> }
>
> Is there a better way?
Looking at this you'll be overwriting the security file every puppet
run, rather than never at all. The first run *may* fail as the copy has
no dependency on File['/root/security.fdb'].
Maintaining local configs on the servers is fighting the Puppet
mentality. You'd be better off using an array of source files so that
puppet will fall through the list until hitting a positive. Have a read
through the Source part of
http://docs.puppetlabs.com/references/stable/type.html#file
This class doesn't restart the sql server. Is that handled elsewhere?
An example:
class firebird::configure {
file { '/var/lib/firebird/2.1/system/security.fdb':
source => [ "puppet:///modules/firebird/custom/security.$host",
'puppet:///modules/firebird/security.fdb'],
owner => root,
group => root,
mode => 640,
require => Class['firebird::install'],
# notify => Service['firebird'],
}
}
HTH,
Dan
--
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] confused about file ensure/require
On 21/06/11 17:03, Craig White wrote:
> On Jun 20, 2011, at 3:54 PM, Ken Barber wrote:
>
>> It does seem like its not being included :-) ...
>>
>> What does:
>>
>> echo "# foo" >> /etc/ntp.conf
>> puppet apply -d -e 'include ntp'
>>
>> Do?
>
> seems so basic - output at bottom
>
> I have gone over and over the Pro Puppet book and the
> http://docs.puppetlabs.com/guides/file_serving.html page and they both are
> the same and this should absolutely work.
>
> # cat modules/ntp/manifests/ntp.pp
> # ntp.pp
>
> class ntp {
> case $operatingsystem {
> centos, redhat: {
> $service_name = 'ntpd'
> $conf_file = 'ntp.conf.el'
> }
> debian, ubuntu: {
> $service_name = 'ntp'
> $conf_file = 'ntp.conf.debian'
> }
> }
>
> package { 'ntp':
> ensure => installed,
> }
>
> service { 'ntp':
> name => $service_name,
> ensure => running,
> enable => true,
> subscribe => File['ntp.conf'],
> }
>
> file { 'ntp.conf':
> path => '/etc/ntp.conf',
> ensure => file,
> require => Package['ntp'],
> source => "puppet:///modules/ntp/files/${conf_file}",
> }
> }
>
> # class {'ntp': }
>
> but no matter what I do, it always errors and says it can't find
> /etc/puppet/modules/ntp/files/ntp.conf.debian but yet it is there and
> readable all the way...
You don't want the /files/ bit. Puppet automatically looks for module
files in the /files/ subfolder. Currently puppet is trying to access
/etc/puppet/modules/ntp/files/files/ntp.conf.debian which doesn't exist :)
All you need is:
source => "puppet:///modules/ntp/${conf_file}"
HTH
Dan
> # ls -l /etc/puppet/modules/ntp/files/ntp.conf.debian
> -rw-r--r-- 1 root root 535 2011-06-13 12:55
> /etc/puppet/modules/ntp/files/ntp.conf.debian
>
> anyway, the output as requested...
>
> Thanks
>
> Craig
--
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] postfix module problems
On 03/03/11 21:14, Tim Dunphy wrote: > hello list!! > > I am having some trouble with a postfix module I am attempting to > implement. as always, your input is extremely valuable and would be > appreciated > > > here's what's going on: > > ## errors > > err: //postfix/Package[postfix-pflogsum.x86_64]/ensure: change from > absent to present failed: Could not find package > postfix-pflogsum.x86_64 > notice: //postfix/Cron[pflogsum]: Dependency > package[postfix-pflogsum.x86_64] has 1 failures > warning: //postfix/Cron[pflogsum]: Skipping because of failed dependencies > err: //postfix/Service[postfix]/ensure: change from stopped to running > failed: Could not start Service[postfix]: Execution of '/sbin/service > postfix start' returned 1: at > /etc/puppet/modules/postfix/manifests/init.pp:35 > err: //postfix/File[/etc/aliases.db]: Failed to retrieve current state > of resource: Error 400 on SERVER: Permission denied - > /etc/puppet/modules/postfix/files/aliases.db Could not retrieve file > metadata for puppet:///postfix/aliases.db: Error 400 on SERVER: > Permission denied - /etc/puppet/modules/postfix/files/aliases.db at > /etc/puppet/modules/postfix/manifests/init.pp:17 > > > > As you can see pflogsum is not being installed and the postfix service > is not starting. also the aliases.db file that I am attempting to > share doesn't get transferred. although > > ## ls of files > > [root@puppet ~]# ls -l /etc/puppet/modules/postfix/files/aliases.db > -rw-r- 1 root root 12288 Mar 2 16:18 > /etc/puppet/modules/postfix/files/aliases.db Is your puppetmaster running as root? It's unlikely. You either want to change the owner or chmod o+r. HTH, Dan -- 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] lsbdistcodename and Debian Squeeze
On 03/03/11 11:55, FRLinux wrote: > Hello all, > > I use puppetmaster on a Debian Squeeze server (packaged from Debian 2.6.2-4) > > I am using a template for Debian Servers which works great for Lenny > in order to update my sources.list automagically, here goes: > > deb http://ftp.ie.debian.org/debian <%= lsbdistcodename %> main contrib > non-free > deb http://security.debian.org/ <%= lsbdistcodename %>/updates main > > Now the problem is that for squeeze, it does not work as > lsbdistcodename gets n/a instead, is there any way to fix this? Update your lsb-release package to at least version 3.2-23.2squeeze1. Debian managed to almost release Squeeze with an lsb-release without code for converting the version number 6.0 to the codename. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609325 HTH Dan -- 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] overriding packages in subclasses
On 02/03/11 04:31, russell.fulton wrote:
> I am having a fight with a postgressql nodule:
>
> It defines:
>
> class postgresql::base {
>
>
> package {"postgresql":
> ensure => present,
> notify => undef,
> }
> ...
>
> and later we have a class that inherits the base class:
>
> class postgresql::rhe::v8-4 inherits postgresql::base {
>
> $data_dir = $postgresql_data_dir ? {
> "" => "/var/lib/postgresql",
> default => $postgresql_data_dir,
> }
>
> package {[
> "postgresql84",
> "postgresql84-server",
> ]:
> ensure => present,
> }
>
> How can I get puppet to ignore the package definition in the 'base'
> class?
A slightly different tactic is to change the name of previously declared
package:
class postgresql::rhe::v8-4 inherits postgresql::base {
Package['postgresql'] {
name => 'postgresql84',
}
package { 'postgresql84-server':
ensure => present,
}
}
This way if you have any external classes putting a dependency on
Package['postgresql'] they don't get 'broken'.
Dan
> This is on redhat -- postgresql installs 8.1.xxx and I want 8.4 --
> puppet installs the two 84 packages and then bitches that it can not
> install the straight postgresql because of conflicts (quite rightly).
>
> Russell
>
--
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: fileserver and distributing many files
On 28/02/11 12:23, Thomas Rasmussen wrote:
> hey
>
> OK, now I have tried to do it via rsync and it seems to be working...
> but the recurse bug is apparently very serious... I now have a
> manifest that does:
>
> file { "/pack/mysql-5.5.9":
> ensure => directory,
> recurse => true,
> force => true,
> owner => "root",
> group => "root",
> require => Exec[rsync_mysql_install],
> }
>
> This takes about the same time as if I was copying (I need to be sure
> of permissions of rsync'ed files). Is the recurse feature really that
> bad?
It'll still be reading and md5summing all those files multiple times
even though there's nothing to compare against. Try setting "checksum =>
none" to disable it.
If it's still really slow, run "puppet agent --test" or "puppet apply"
in strace to see what's taking so long. Search for known file names.
Dan
> Thomas
>
> On Feb 28, 11:28 am, Daniel Piddock wrote:
>> On 28/02/11 10:19, Thomas Rasmussen wrote:
>>
>>> Hi
>>> My network is 100Mbit (approximately, but through a VPN so not that
>>> fast) with latency around 2ms (right now our test-setup is running on
>>> servers right beside each other :-))
>>> I have tried to switch to passenger and this does not seem that much
>>> faster, still uses very very long time to run. I now have tried to
>>> copy the tar-ball and unpackaged this to the target directory and run
>>> puppet again, now it just wants to correct permissions (which is OK
>>> because they are wrong in the tar-ball) and this takes 2-5 seconds per
>>> file!) which is pretty much unusable (I still have the manifest to
>>> copy from the master to clients)
>> Directory recursion is horribly inefficient and quite broken. It's
>> md5summing every source and target file twice. It then md5sums the
>> target again at the end to ensure it did it right.
>>
>> Seehttps://projects.puppetlabs.com/issues/5650, 6003 and 6004.
>>
>>> I'm not that happy about making a solution like yours, it might be the
>>> solution we choose but I really don't see this as the best one. I'd
>>> rather have puppet serve the files on its own, but it seems as though
>>> it is not feasible?
>> If you *really* want puppet to manage the files you have two solutions:
>> * Put up with the horrible delay and brokenness until it's eventually fixed.
>> * List each file and subdirectory in your manifest.
>>
>> Personally, I went with rsync run from a script with a schedule of
>> daily, similar to Patrick.
>> exec { '/usr/local/scripts/installMaps.sh':
>> schedule => daily,
>>
>>
>>
>> }
--
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: fileserver and distributing many files
On 28/02/11 10:19, Thomas Rasmussen wrote:
> Hi
>
> My network is 100Mbit (approximately, but through a VPN so not that
> fast) with latency around 2ms (right now our test-setup is running on
> servers right beside each other :-))
>
> I have tried to switch to passenger and this does not seem that much
> faster, still uses very very long time to run. I now have tried to
> copy the tar-ball and unpackaged this to the target directory and run
> puppet again, now it just wants to correct permissions (which is OK
> because they are wrong in the tar-ball) and this takes 2-5 seconds per
> file!) which is pretty much unusable (I still have the manifest to
> copy from the master to clients)
Directory recursion is horribly inefficient and quite broken. It's
md5summing every source and target file twice. It then md5sums the
target again at the end to ensure it did it right.
See https://projects.puppetlabs.com/issues/5650 , 6003 and 6004.
> I'm not that happy about making a solution like yours, it might be the
> solution we choose but I really don't see this as the best one. I'd
> rather have puppet serve the files on its own, but it seems as though
> it is not feasible?
If you *really* want puppet to manage the files you have two solutions:
* Put up with the horrible delay and brokenness until it's eventually fixed.
* List each file and subdirectory in your manifest.
Personally, I went with rsync run from a script with a schedule of
daily, similar to Patrick.
exec { '/usr/local/scripts/installMaps.sh':
schedule => daily,
}
> Still hopes for solutions :-)
>
> Thomas
>
> On Feb 28, 9:53 am, Patrick wrote:
>
>> Assuming your definition of small matches mine (less that 50Kb), in my
>> experience Puppet will only do this if the server is loaded (not applicable
>> to you) or if you have high latency. (more than 100ms ping) Switching away
>> from Webrick is strongly advised because 2 clients running at the same time
>> can heavily load it down when serving files, but I know that doesn't apply
>> to you.
>>
>> In my case, I use an exec managed by puppet that uses rsync to sync the
>> files at 2am. Here it is although it doesn't sound like it's very useful to
>> you. There's also a bit more code to force it to run on the first run using
>> a creates.
>>
>> exec { "/usr/bin/rsync -avz simba.outer::www/ /var/www/":
>> schedule => long_maintenance,
>> require => [Package["apache2"], Package["rsync"]],
>> }
>>
>> schedule { long_maintenance:
>> period => daily,
>> repeat => 1,
>> range => "1:30 - 2:30",
>> }
>>
>>> Any ideas on what the best solution is? It is NOT a solution to simply
>>> setup a manifests that installs the app from the ubuntu repository. Is
>>> there any way of using ie. rsync to deploy the files instead of
>>> puppet?
>> Again, I'm giving you what you asked for, but this is rather simple.
--
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] Fresh node fails puppet run - init script not found before installing package
On 17/02/11 14:05, Daniel Piddock wrote: > On 17/02/11 12:09, Daniel Piddock wrote: >> I managed to solve the problem by installing the openssh-server package >> manually so the init script was present. I have other modules with a >> very similar structure and they weren't throwing up these errors. Odd >> glitch. Frustrating. > I tried a few more things and it's still failing: > * Upgrading the server and client to 2.6.4. > * Flattened the ssh module to remove the class level requires. > * Added a node definition so that only the ssh class was included. > * Put a direct require from Service[ssh] to Package[openssh-server] > * Syntax errors in init.pp to ensure it's actually reading the right file ;) > > Attaching init.pp from ssh module and the client's cached yaml if anyone > fancies looking. > > Dan Puppet bug. It's setting the name parameter to not match the title that causes this example to explode and why the other services weren't. Issue 5610. Still hasn't been fixed in 2.6.5rc4. Ah well, something else to work around. Cheers, Dan -- 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] Fresh node fails puppet run - init script not found before installing package
On 17/02/11 12:09, Daniel Piddock wrote:
> I managed to solve the problem by installing the openssh-server package
> manually so the init script was present. I have other modules with a
> very similar structure and they weren't throwing up these errors. Odd
> glitch. Frustrating.
I tried a few more things and it's still failing:
* Upgrading the server and client to 2.6.4.
* Flattened the ssh module to remove the class level requires.
* Added a node definition so that only the ssh class was included.
* Put a direct require from Service[ssh] to Package[openssh-server]
* Syntax errors in init.pp to ensure it's actually reading the right file ;)
Attaching init.pp from ssh module and the client's cached yaml if anyone
fancies looking.
Dan
--
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.
--- &id001 !ruby/object:Puppet::Resource::Catalog
aliases: {}
applying: false
classes:
- settings
- dhcp75.int.corefiling.com
- ssh
edges:
- &id044 !ruby/object:Puppet::Relationship
source: &id009 !ruby/object:Puppet::Resource
catalog: *id001
exported: false
parameters:
!ruby/sym name: main
reference: !ruby/object:Puppet::Resource::Reference
title: &id002 main
type: &id003 Stage
tags:
- stage
- main
title: *id002
type: *id003
target: &id006 !ruby/object:Puppet::Resource
catalog: *id001
exported: false
parameters:
!ruby/sym name: main
reference: !ruby/object:Puppet::Resource::Reference
title: &id004 Main
type: &id005 Class
tags:
- class
- main
title: *id004
type: *id005
- &id043 !ruby/object:Puppet::Relationship
source: *id006
target: &id033 !ruby/object:Puppet::Resource
catalog: *id001
exported: false
parameters: {}
reference: !ruby/object:Puppet::Resource::Reference
title: &id007 dhcp75.int.corefiling.com
type: &id008 Node
tags:
- node
- dhcp75.int.corefiling.com
- class
title: *id007
type: *id008
- &id042 !ruby/object:Puppet::Relationship
source: *id009
target: &id012 !ruby/object:Puppet::Resource
catalog: *id001
exported: false
parameters: {}
reference: !ruby/object:Puppet::Resource::Reference
title: &id010 Ssh
type: &id011 Class
tags:
- class
- ssh
- node
- dhcp75.int.corefiling.com
title: *id010
type: *id011
- &id036 !ruby/object:Puppet::Relationship
source: *id012
target: &id027 !ruby/object:Puppet::Resource
catalog: *id001
exported: false
file: /etc/puppet/modules/ssh/manifests/init.pp
line: 9
parameters:
!ruby/sym ensure: latest
reference: !ruby/object:Puppet::Resource::Reference
title: &id013 openssh-server
type: &id014 Package
tags:
- package
- openssh-server
- class
- ssh
- node
- dhcp75.int.corefiling.com
title: *id013
type: *id014
- &id037 !ruby/object:Puppet::Relationship
source: *id012
target: &id030 !ruby/object:Puppet::Resource
catalog: *id001
exported: false
file: /etc/puppet/modules/ssh/manifests/init.pp
line: 9
parameters:
!ruby/sym ensure: latest
!ruby/sym name: openssh-client
reference: !ruby/object:Puppet::Resource::Reference
title: &id015 openssh-clients
type: &id016 Package
tags:
- package
- openssh-clients
- class
- ssh
- node
- dhcp75.int.corefiling.com
title: *id015
type: *id016
- &id041 !ruby/object:Puppet::Relationship
source: *id012
target: &id025 !ruby/object:Puppet::Resource
catalog: *id001
exported: false
file: /etc/puppet/modules/ssh/manifests/init.pp
line: 25
parameters:
!ruby/sym source:
- puppet:///files/dhcp75.int.corefiling.com/ssh/sshd_config
- puppet:///modules/ssh/sshd_config-int.corefiling.com.Debian
- puppet:///modules/ssh/sshd_config.Debian
!ruby/sym group: root
!ruby/sym owner: root
!ruby/sym mode: "644"
!ruby/sym require: &q
Re: [Puppet Users] Fresh node fails puppet run - init script not found before installing package
On 17/02/11 11:45, Felix Frank wrote:
>> e.g.: file { 'something': require => Class['ssh'] }
>> class ssh gets processed but ssh::install and ssh::config might not be,
>> unless I put a depend on something deeper within it. Which defeats the
>> idea of organising into classes a bit.
> Where have you gotten that idea from? Is this documented?
>
> AFAIK, requiring Class[ssh] will require all resources declared by class
> ssh, and it doesn't matter whether those resources are declared through
> include or directly in the class.
>
> Correct me if I'm wrong, please.
My first mail to the group was about this very issue with the conclusion
of using require instead of include:
http://groups.google.com/group/puppet-users/browse_thread/thread/64e4dde981c79ffb/bbb8bdc4ab78c328?lnk=gst
A require does require everything defined within the class but it does
not put a dependency on other classes pulled in by an include.
> If I *am* wrong on this one, here's what should be safer:
> class ssh {
> include ssh::install
> require ssh::config
> }
>
> and have all resources in ssh::config require Class[ssh::install], but
> that would be ugly and a bit evil (although not as evil as requiring two
> interrelated classes).
>
> All this aside, I looked at your error again and begin to doubt that
> this is the root cause of your problems. Your catalog should either
> apply or be rejected because of cyclic dependencies. Something else must
> be fishy. Does the catalog work if your node doesn't include ssh at all?
I managed to solve the problem by installing the openssh-server package
manually so the init script was present. I have other modules with a
very similar structure and they weren't throwing up these errors. Odd
glitch. Frustrating.
Cheers,
Dan
--
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] Fresh node fails puppet run - init script not found before installing package
On 17/02/11 08:52, Felix Frank wrote:
> Hi,
>
> On 02/16/2011 05:35 PM, Daniel Piddock wrote:
>> Hey all,
>>
>> I was installing puppet on a freshly installed node and the catalog
>> fails to apply. It immediately bails out with:
>> err: Could not run Puppet configuration client: Could not find init
>> script for 'ssh'
>>
>> This is annoying and odd. ssh service is run by a module in main stage,
>> there is a stage before that which isn't being applied. The service
>> subscribes to a file which in turn requires the package.
>>
>> Can anyone shed light/guess at why puppet is bailing on an init script
>> for a service it hasn't installed yet and shouldn't be worrying about at
>> this stage?
>>
>> Running puppet 2.6.2 on Debian Squeeze. Master is also 2.6.2 on Squeeze.
>>
>> Cheers,
>> Dan
>>
>>
>> modules/ssh/manifests/init.pp
>> class ssh {
>> require ssh::install, ssh::config
>> }
> Why do you use the require function? I think it's dangerous in this
> case, because it probably tries to enforce an ordering. I.e.,
> ssh::config is to be done before the "class ssh" proper. However,
> service "sshd" should require the ssh::install class.
>
> Use include instead of require, and make sure the service requires the
> install class as well. That may just solve your problem.
include doesn't provide a tight enough binding. It simply says "this
would be useful, please process it at some point". With your suggested
change, if another package puts a dependency on ssh module there's no
guarantee that the whole module will be processed in a usable state.
e.g.: file { 'something': require => Class['ssh'] }
class ssh gets processed but ssh::install and ssh::config might not be,
unless I put a depend on something deeper within it. Which defeats the
idea of organising into classes a bit.
I should probably just rewrite all my modules to be single classes
unless there's a clear use for a proper subclass. Puppet's classing
seems broken and my design with requires isn't helping.
I also think this is a tangent to the issue of failing a catalog due to
an init script not being present on a service that has dependencies to
process.
Dan
--
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] Fresh node fails puppet run - init script not found before installing package
Hey all,
I was installing puppet on a freshly installed node and the catalog
fails to apply. It immediately bails out with:
err: Could not run Puppet configuration client: Could not find init
script for 'ssh'
This is annoying and odd. ssh service is run by a module in main stage,
there is a stage before that which isn't being applied. The service
subscribes to a file which in turn requires the package.
Can anyone shed light/guess at why puppet is bailing on an init script
for a service it hasn't installed yet and shouldn't be worrying about at
this stage?
Running puppet 2.6.2 on Debian Squeeze. Master is also 2.6.2 on Squeeze.
Cheers,
Dan
modules/ssh/manifests/init.pp
class ssh {
require ssh::install, ssh::config
}
modules/ssh/manifests/install.pp
class ssh::install {
package {
'openssh-server': ;
'openssh-clients':
name => $operatingsystem ? {
debian => 'openssh-client',
default => 'openssh-clients',
};
}
}
modules/ssh/manifests/config.pp
class ssh::config {
File {
require => Class['ssh::install'],
}
file {
'/etc/ssh/sshd_config':
source => [
"puppet:///files/$fqdn/ssh/sshd_config",
"puppet:///modules/ssh/sshd_config-${domain}.$operatingsystem",
"puppet:///modules/ssh/sshd_config.$operatingsystem",
];
'/etc/ssh/ssh_config':
source => 'puppet:///modules/ssh/ssh_config';
'/etc/ssh/ssh_known_hosts':
source => 'puppet:///files/ssh/ssh_known_hosts';
}
service { 'sshd':
name => $operatingsystem ? {
debian => 'ssh',
default => 'sshd',
},
subscribe => File['/etc/ssh/sshd_config'],
hasstatus => true,
}
}
manifests/site.pp (minus other includes and some hierarchy):
node default {
include ssh
class { "repositories": stage => repositories; }
}
Defaults:
stage { 'repositories': before => Stage[main] }
File {
owner => root,
group => root,
mode => 644,
}
Package {
ensure => latest,
}
Service {
enable => true,
ensure => running,
hasrestart => true,
}
--
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] Wierd debian package issue...
On 28/01/11 16:52, Peter Berghold wrote:
> This one has me scratching my head. Simply enough I have the
> following in one of my manifests:
>
> package { postgresq1: ensure => latest }
I'm not sure if this is a special typo for the mailing list but that
looks like a One at the end of postgresql. Given it's consistent in the
error message, I guess not.
> I checked with the Debian site to ensure that I had the correct
> package name, puppetd did its thing and lo and behold I get the
> following error message:
>
> err: /Stage[main]/Groupware-server/Package[postgresq1]/ensure: change
> from purged to latest failed: Could not update: Execution of
> '/usr/bin/apt-get -q -y -o DPkg::Options::=--force-confold install
> postgresq1' returned 100: Reading package lists...
> Building dependency tree...
> Reading state information...
> E: Couldn't find package postgresq1
> at /etc/puppet/manifests/templates.pp:58
> notice: Finished catalog run in 3.05 seconds
Dan
--
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] Mirror folder with large files
On 25/01/11 12:45, Brice Figureau wrote:
> On Mon, 2011-01-24 at 17:14 +0000, Daniel Piddock wrote:
>> Dear list,
>>
>> I'm attempting to mirror a folder containing a few large files from an
>> NFS location to the local drive. Subsequent runs take a lot longer than
>> I'd have expected, after the first run.
>>
>> Using the following block a puppet apply run is currently taking 30 seconds:
>> file { '/usr/share/target':
>> source => 'file:///home/archive/source/',
>> recurse => true,
>> backup => false,
>> checksum => mtime,
>> }
>>
>> There are 42 files taking up 870MB. I'd have thought stating the files
>> in the source and target, comparing to each other (or a cache internal
>> to puppet as it doesn't set the mtime on files) would be a lot faster
>> than it is.
> This is a naive view of the problem :)
> The puppet file type is certainly the most complex resource abstraction
> puppet embeds (just think about the fact that it handles dir, files,
> link, remote recursion, local recursion, etc...).
Yes, it's a shame that the implication of "checksum => mtime" doesn't do
what it says on the tin, or the documentation doesn't really mention
anything about how the checksums differ or function. However md5summing
every file twice when recursing seems a bit broken.
>> I was curious about what puppet was up to, so ran it in strace. It's
>> reading every file every run, multiple times! Reads the target twice,
>> then the source twice before reading the target again. Considering I
>> wasn't expecting it to open any of the files at all this is total over kill.
>>
>> Is this horribly bugged or have I got a magic incantation that's causing
>> this behaviour? strace is rather verbose and I haven't exactly read all
>> 80MB of the dump line by line.
>>
>> Is there a neater way of just mirroring a folder based on modification
>> time? I suppose the easiest route would be an exec of rsync, at least I
>> have control over that.
> Yes, I think rsync is the sanest way to do this.
>
> Recursive file resources (and especially sourced ones) are really tough
> for puppet to handle in the current way the code is working.
>
> Puppet manages individual file resources, and for every resource it
> manages it as an instance of this resource in memory.
>
> For deep/large file hierarchies, Puppet has to create/manage an
> individual resource per file/directory present in this hierarchy, which
> consumes both cpu and ram (due to the way the ruby GC is poorly
> implemented and the time it takes to create a ruby object).
> And I don't even talk about the scalability issues of the generation and
> handling of billions of "change" event coming up each time a file is
> changed (which happens for instance the first time puppet runs).
>
> I think I remember mtime is a checksum valid only for directory, and
> puppet automatically switches to md5 for files (I don't really know the
> reason, but I'm sure redmine knows it).
>
> (One of) The problem is that puppet reads the file once to compute the
> md5 sum, then it also reads it again to perform the copy when it detects
> a change. I don't exactly know why it would write multiple times, but
> I'm sure you can debug this by adding debug statements in
> puppet/type/file/content.rb where all the write happens.
In recursion, the source file is read twice, target is tested and if it
doesn't exist the source is read again for the copy. If the target did
exist, it's read twice as well. It does not matter if the checksum was
specified as md5 or mtime. I put more detail on issue 6003
http://projects.puppetlabs.com/issues/6003 .
Writing only happens once per changed file.
>> I'm using Puppet 2.6.4.
>>
>> Dan
>> I especially like the way Ruby searches for and loads the md5 library
>> every time it's used. What a performant language.
> This certainly comes from this code in Puppet::Util::Checksums:
> # Calculate a checksum of a file's content using Digest::MD5.
> def md5_file(filename, lite = false)
> require 'digest/md5'
>
> digest = Digest::MD5.new
> checksum_file(digest, filename, lite)
> end
>
> Notice how the "require" is in the function instead of being outside.
> I'd think that ruby would be smart enough to understand the file has
> already been "required" and not bother, but apparently it doesn't do
> that for you. Can you give us what ruby version and what platform you're
> using?
The client I'm using for testing is Fedora 14, ruby-1.8.7.330-1.fc14.x86_64
Dan
--
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] Mirror folder with large files
On 24/01/11 20:57, Patrick wrote:
> On Jan 24, 2011, at 9:14 AM, Daniel Piddock wrote:
>
>> Dear list,
>>
>> I'm attempting to mirror a folder containing a few large files from an
>> NFS location to the local drive. Subsequent runs take a lot longer than
>> I'd have expected, after the first run.
>>
>> Using the following block a puppet apply run is currently taking 30 seconds:
>> file { '/usr/share/target':
>>source => 'file:///home/archive/source/',
>>recurse => true,
>>backup => false,
>>checksum => mtime,
>> }
>>
>> There are 42 files taking up 870MB. I'd have thought stating the files
>> in the source and target, comparing to each other (or a cache internal
>> to puppet as it doesn't set the mtime on files) would be a lot faster
>> than it is.
>>
>> I was curious about what puppet was up to, so ran it in strace. It's
>> reading every file every run, multiple times! Reads the target twice,
>> then the source twice before reading the target again. Considering I
>> wasn't expecting it to open any of the files at all this is total over kill.
>>
>> Is this horribly bugged or have I got a magic incantation that's causing
>> this behaviour? strace is rather verbose and I haven't exactly read all
>> 80MB of the dump line by line.
>>
>> Is there a neater way of just mirroring a folder based on modification
>> time? I suppose the easiest route would be an exec of rsync, at least I
>> have control over that.
>>
>> I'm using Puppet 2.6.4.
>>
>> Dan
>> I especially like the way Ruby searches for and loads the md5 library
>> every time it's used. What a performant language.
> This sounds like a bug to me. I do know that I never use recurse=true except
> when neccisary myself because it's too slow. In your position, I would
> replace it with an rsync and file a bug.
>
> Also, does it behave this badly when no changes are made or just when making
> changes
This happens every single run, source and target have not changed state.
I tried stracing when just a single file is copied. Puppet is still
reading both source and target when checksum => mtime is used, although
just the once.
I think there might be two bugs here - checksum does not work with
timestamps and recurse is horribly broken.
Puppet issues 6003 and 6004 raised.
Dan
--
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] Mirror folder with large files
Dear list,
I'm attempting to mirror a folder containing a few large files from an
NFS location to the local drive. Subsequent runs take a lot longer than
I'd have expected, after the first run.
Using the following block a puppet apply run is currently taking 30 seconds:
file { '/usr/share/target':
source => 'file:///home/archive/source/',
recurse => true,
backup => false,
checksum => mtime,
}
There are 42 files taking up 870MB. I'd have thought stating the files
in the source and target, comparing to each other (or a cache internal
to puppet as it doesn't set the mtime on files) would be a lot faster
than it is.
I was curious about what puppet was up to, so ran it in strace. It's
reading every file every run, multiple times! Reads the target twice,
then the source twice before reading the target again. Considering I
wasn't expecting it to open any of the files at all this is total over kill.
Is this horribly bugged or have I got a magic incantation that's causing
this behaviour? strace is rather verbose and I haven't exactly read all
80MB of the dump line by line.
Is there a neater way of just mirroring a folder based on modification
time? I suppose the easiest route would be an exec of rsync, at least I
have control over that.
I'm using Puppet 2.6.4.
Dan
I especially like the way Ruby searches for and loads the md5 library
every time it's used. What a performant language.
--
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] Namespacing, includes and module lookup. Bug?
On 24/12/10 12:10, Dan Carley wrote:
> On 24 December 2010 11:11, Daniel Piddock <mailto:dgp-g...@corefiling.co.uk>> wrote:
>
> Hey all,
>
> I'm not sure if I've made a fundamental misunderstanding of Puppet
> namespacing and include resolution or whether there's a bug.
>
> Background:
> I have a modules, called kerberos, that configures a client for
> working
> on my kerberos domain. I then have a module called ssh that sets up a
> basic sshd. I wanted to create a ssh::kerberos class in the ssh module
> that extends my ssh setup with kerberos support. I wanted to put a
> dependency on the kerberos module. However things fell apart and there
> was lots of hair tearing thinking I'd done something stupid (e.g. a
> typo.) I now believe it's not that simple...
>
> ..
>
> Is this by design? If so, how do I specify module, not subclass,
> in the
> include/require?
> Is there a bug?
>
>
> It's a bug, IMO. One which seems to be cropping up more frequently.
>
> I think it's quite a common use case to have sub-classes of the same
> name as top-level classes. For instance, I have a number of classes
> like 'php::mysql', 'python::mysql' and 'exim::mysql' which all
> 'include mysql' in order to pull in common MySQL client functionality.
>
> The trouble is that the resolution of a class name always begins
> relative to the current class. If it's able to satisfy the include
> from within the current class namespace, including the current class
> itself, then it won't check the top-level. It can be demonstrated with
> a simplified example:
>
> """
> d...@dan-macpro:~$ puppet apply
> class bar {
> notify { "bar": }
> }
>
> class foo::bar {
> include bar
> notify { "foo": }
> }
>
> include foo::bar
> ^D
> notice: foo
> notice: /Stage[main]/Foo::Bar/Notify[foo]/message: defined 'message'
> as 'foo'
> """
>
> You can see that Class["bar"] and Notify["bar"] have both been
> ignored. I suspect that in a lot of cases this behaviour will go
> unnoticed by people. It's not until you add a require to the resource
> that the loop is then exposed with a failure:
>
> """
> d...@dan-macpro:~$ puppet apply
> class bar {
> notify { "bar": }
> }
>
> class foo::bar {
> include bar
> notify { "foo":
> require => Class["bar"],
> }
> }
>
> include foo::bar
> ^D
> err: Could not apply complete catalog: Found dependency cycles in the
> following relationships: Notify[foo] => Notify[foo]
> """
>
> There are some hack-ish ways to work around it. You can specify that
> all of your includes come from the top scope by prefixing them with
> ::, such as 'include ::mysql'. But this makes for some pretty long
> winded manifest writing if you want to be sure 100% of the time. There
> isn't an equivalent syntax for require meta-parameters. You can
> achieve something vaguely similar with 'require ::mysql' which will
> create dependencies from all resources in the current class. It's
> certainly not the same effect though.
>
> I spoke to James Turnbull and some others on IRC about this a couple
> of weeks ago. I believe he was going to see whether it fitted in with
> an existing ticket. If there isn't one, then something new needs to be
> raised. What I'd really like to see is that all class naming becomes
> absolute. That would leave much less scope for this kind of confusion
> and erratic behaviour.
That's a tidier example, thanks.
I've done a bit of poking around the issue tracker. Issue 4473
http://projects.puppetlabs.com/issues/4473 appears to be the ticket
related to this. Unfortunately it looks like puppeteers expect this
unusual name resolution order, if they ever knowingly stumble upon it
(e.g. 4483, 4472). Either I need to hack around this problem carefully
or wait a long time for the next major release, if puppetlabs decide to
follow the OO programming crowd.
The use of top scope prefixing seems to work around my current selection
of problems, if I'm consistent in its use.
Thank you,
Dan
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Namespacing, includes and module lookup. Bug?
On 24/12/10 11:11, Daniel Piddock wrote:
> Hey all,
>
> I'm not sure if I've made a fundamental misunderstanding of Puppet
> namespacing and include resolution or whether there's a bug.
>
> Background:
> I have a modules, called kerberos, that configures a client for working
> on my kerberos domain. I then have a module called ssh that sets up a
> basic sshd. I wanted to create a ssh::kerberos class in the ssh module
> that extends my ssh setup with kerberos support. I wanted to put a
> dependency on the kerberos module. However things fell apart and there
> was lots of hair tearing thinking I'd done something stupid (e.g. a
> typo.) I now believe it's not that simple...
>
> [Contrived, simplistic example]
> Take a module called "t" that creates a folder:
> /etc/puppet/modules/t/manifests/init.pp:
> class t {
> file { '/tmp/t': ensure => directory }
> }
>
> Create another module called test, that creates a file in that directory:
> /etc/puppet/modules/test/manifests/init.pp
> class test {
> include t
> file { '/tmp/t/foo':
> ensure => file,
> require => File['/tmp/t'],
> }
>
> Everything's super happy and fine. I have /tmp/t/foo. puppet agent
> --test --debug:
> info: Caching catalog for debian.localdomain
> debug: Creating default schedules
> debug: Loaded state in 0.00 seconds
> debug: /Stage[main]/Test/File[/tmp/t/foo]/require: requires File[/tmp/t]
> info: Applying configuration version '1293188258'
> notice: /Stage[main]/T/File[/tmp/t]/ensure: created
> notice: /Stage[main]/Test/File[/tmp/t/foo]/ensure: created
> debug: Finishing transaction -615069188
> debug: Storing state
> debug: Stored state in 0.01 seconds
> notice: Finished catalog run in 0.03 seconds
>
> Now, create a test::t class.
> /etc/puppet/modules/test/manifests/t.pp:
> class test::t {
> }
>
> It falls apart. Puppet resolves the "include t" as being the subclass of
> test, rather than the module:
> info: Caching catalog for debian.localdomain
> debug: Creating default schedules
> err: Could not run Puppet configuration client: Could not find
> dependency File[/tmp/t] for File[/tmp/t/foo] at
> /etc/puppet/modules/test/manifests/init.pp:6
>
> Replacing the require with Class['t'] is rather more telling in the debug:
> info: Caching catalog for debian.localdomain
> debug: Creating default schedules
> debug: Loaded state in 0.00 seconds
> debug: /Stage[main]/Test/File[/tmp/t/foo]/require: requires Class[Test::T]
> info: Applying configuration version '1293188643'
> err: /Stage[main]/Test/File[/tmp/t/foo]/ensure: change from absent to
> file failed: Could not set 'file on ensure: No such file or directory -
> /tmp/t/foo at /etc/puppet/modules/test/manifests/init.pp:6
> debug: Finishing transaction -614790778
> debug: Storing state
> debug: Stored state in 0.01 seconds
> notice: Finished catalog run in 0.03 seconds
>
> Is this by design? If so, how do I specify module, not subclass, in the
> include/require?
> Is there a bug?
I should have mentioned that I first got the issue under 2.6.2 but have
also tested under 2.6.4
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Namespacing, includes and module lookup. Bug?
Hey all,
I'm not sure if I've made a fundamental misunderstanding of Puppet
namespacing and include resolution or whether there's a bug.
Background:
I have a modules, called kerberos, that configures a client for working
on my kerberos domain. I then have a module called ssh that sets up a
basic sshd. I wanted to create a ssh::kerberos class in the ssh module
that extends my ssh setup with kerberos support. I wanted to put a
dependency on the kerberos module. However things fell apart and there
was lots of hair tearing thinking I'd done something stupid (e.g. a
typo.) I now believe it's not that simple...
[Contrived, simplistic example]
Take a module called "t" that creates a folder:
/etc/puppet/modules/t/manifests/init.pp:
class t {
file { '/tmp/t': ensure => directory }
}
Create another module called test, that creates a file in that directory:
/etc/puppet/modules/test/manifests/init.pp
class test {
include t
file { '/tmp/t/foo':
ensure => file,
require => File['/tmp/t'],
}
Everything's super happy and fine. I have /tmp/t/foo. puppet agent
--test --debug:
info: Caching catalog for debian.localdomain
debug: Creating default schedules
debug: Loaded state in 0.00 seconds
debug: /Stage[main]/Test/File[/tmp/t/foo]/require: requires File[/tmp/t]
info: Applying configuration version '1293188258'
notice: /Stage[main]/T/File[/tmp/t]/ensure: created
notice: /Stage[main]/Test/File[/tmp/t/foo]/ensure: created
debug: Finishing transaction -615069188
debug: Storing state
debug: Stored state in 0.01 seconds
notice: Finished catalog run in 0.03 seconds
Now, create a test::t class.
/etc/puppet/modules/test/manifests/t.pp:
class test::t {
}
It falls apart. Puppet resolves the "include t" as being the subclass of
test, rather than the module:
info: Caching catalog for debian.localdomain
debug: Creating default schedules
err: Could not run Puppet configuration client: Could not find
dependency File[/tmp/t] for File[/tmp/t/foo] at
/etc/puppet/modules/test/manifests/init.pp:6
Replacing the require with Class['t'] is rather more telling in the debug:
info: Caching catalog for debian.localdomain
debug: Creating default schedules
debug: Loaded state in 0.00 seconds
debug: /Stage[main]/Test/File[/tmp/t/foo]/require: requires Class[Test::T]
info: Applying configuration version '1293188643'
err: /Stage[main]/Test/File[/tmp/t/foo]/ensure: change from absent to
file failed: Could not set 'file on ensure: No such file or directory -
/tmp/t/foo at /etc/puppet/modules/test/manifests/init.pp:6
debug: Finishing transaction -614790778
debug: Storing state
debug: Stored state in 0.01 seconds
notice: Finished catalog run in 0.03 seconds
Is this by design? If so, how do I specify module, not subclass, in the
include/require?
Is there a bug?
Cheers,
Dan
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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: lsbmajdistrelease fact
On 21/12/10 17:48, Arnau Bria wrote: > On Tue, 21 Dec 2010 17:02:20 +0100 > Arnau Bria wrote: > >> Hi all, >> >> I've noticed that facter version superior from epel do not >> display lsbmajdistrelease fact: > Sorry for the noise, that's not true. > > it works in some systems and it doesn't in others. I'm sure I have some > diff between systems, so, I have to change my question: anyone could > tell me what package could be causing this diff behaivour between hosts? On Debian systems you need to specifically install the lsb-release package, which provides the lsb_release command. lsb_release is provided by redhat-lsb under Fedora (which is installed by default.) HTH Dan -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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] Could not find class
On 16/12/10 01:48, Dmytro Bablinyuk wrote:
> Hi Everybody,
>
> I am sure that I am missing something very obvious,
>
> I have installed rsync package
>
> git clone https://github.com/camptocamp/puppet-rsyncd.git rsync
>
> The path
>
> r...@puppet-master:/etc/puppet/modules/rsync/manifests/classes# ls -l
> total 4
> -rw-r--r-- 1 root root 1078 2010-12-16 09:54 rsyncd.pp
>
> The manifest file
>
> package { ["rsync", "xinetd"]: ensure => present }
> service { "xinetd": ensure => running }
>
> include rsyncd
>
> rsyncd::export { "etc":
> path => "/etc",
> chroot => true,
> gid => "staff",
> allow => ["172.16.50.4", "172.16.41.10"],
> }
>
> I have error on the client
>
> r...@puppet-client-ubuntu:~# puppetd --test
> info: Retrieving plugin
> err: Could not retrieve catalog from remote server: Error 400 on
> SERVER: Could not find class rsyncd at /etc/puppet/manifests/site.pp:
> 33 on node puppet-client-ubuntu.harbour
> warning: Not using cache on failed catalog
> err: Could not retrieve catalog; skipping run
>
> How do I specify path to the rsyncd class?
The "include rsyncd" line causes Puppet to look for
/etc/puppet/modules/rsyncd/manifests/init.pp which you don't have. Try
renaming the rsync checkout folder to rsyncd.
Dan
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Best practices for different hosts with different configs
On 13/12/10 04:00, Josh wrote: > Greetings, > I'm just getting started with setting up Puppet in an environment of > about ~15 servers, a mixture of Mac OS X servers and Ubuntu servers - > each with different roles and obviously different versions of configs. > > Before I get too carried away, I was hoping to get advice on the "rule > of thumb" about different versions of configs. Most of the > documentation and examples I've seen seem to be geared more towards > "roles" of a set of nodes, such as "http nodes, dns nodes" etc. What > hasn't been too clear to me is a smaller scale environment where there > aren't multiple nodes sharing the same job. > > Say I have an application installed on two of my servers and > obviously, each server has its own version of the config files for > that. What is the "best practice" to manage that? Do I define a > class for "server1" with each thing I want to manage, and point to a > specific file (e.g. puppet://puppet/files/server1/config.cfg .../ > server2/config.cfg ...etc)? > > Any nudge in the right direction is greatly appreciated! Thanks. You can use a variable in the source path definition. e.g. puppet:///files/$host/config.cfg. The source parameter can also take an array and will search each path in order until it gets a positive hit: source => [ "puppet:///files/$host/config.cfg", "puppet:///modules/mymodule/config.cfg", ] See source section of http://docs.puppetlabs.com/references/latest/type.html#file for more details. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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] apt-get -t lenny-backports
On 08/12/10 10:54, Adrian wrote:
> Hello everybody,
>
>
> Is there a way when installing a package like this :
>
> package { "rubygems":
> ensure => installed,
> }
>
> to pass -t parameter to apt-get in order to use a specific apt
> source ? EG : apt-get install -t lenny-backports rubygems
>
> Ideally I would not use exec ...
>
> I am on a Debian and I want to find a clean way to upgrade
> rubygems ...
I went with the slightly messy solution of adding the requested repo to
the package name:
package { rubygems:
name => $operatingsystemrelease ? {
/^5\.0\./ => 'rubygems/lenny-backports',
default => 'rubygems',
},
ensure => latest,
}
This causes puppet to 'spam' an "ensure created" line each run and a
wasted call to apt-get.
A temporary solution until squeeze appears and preferences.d is supported.
There is an old puppet issue for this feature request but no solution
was produced: http://projects.puppetlabs.com/issues/2406
Dan
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Depending on a class from a class?
On 01/12/10 15:03, Nigel Kersten wrote:
> On Wed, Dec 1, 2010 at 4:18 AM, Daniel Piddock
> wrote:
>> On 01/12/10 09:57, Daniel Piddock wrote:
>>> On 30/11/10 18:07, Eric Sorenson wrote:
>>>> Minimally in your current code change 'include repositories::debian' to
>>>> 'require("repositories::debian")' - this is a built-in function that does
>>>> an include-plus-require and will produce the ordering you want (Thanks to
>>>> Jeff Mccune for pointing me at this)
>>>> http://docs.puppetlabs.com/references/latest/function.html#require
>>> require was the function I was looking for. So obvious and documented.
>> It appears that I was a little too early in my celebration.
>>
>> "require $class" causes you to import the class, however no dependency
>> is then placed on the *contents* of said class. I'm in exactly the same
>> position. If I have "require => Class[repository::fedora]" instead of
>> just "require => Class[repository]" in the Package definition I get the
>> results desired. This strikes me as a design flaw.
> It sounds like you don't have a relationship defined between
> Class[repository] and Class[repository::fedora] ?
class repository contains a "require repository::fedora" line (context
has been lost from the first mail)
> Setting up a relationship with the former does not imply a
> relationship with the latter.
I've tracked it down to being a problem with 0.25.5. Using 2.6.3 the
require gets expanded correctly. Either solution I need to upgrade to 2.6.3.
I was previously calling puppetd which is not maintained by the 2.6.3
gem, so I was not actually testing 2.6.3. "puppet agent --test --noop"
works.
I now have large expanded_relationships graph with yum repos at the top
and a long line of Packages below.
Dan
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Depending on a class from a class?
On 01/12/10 09:57, Daniel Piddock wrote:
> On 30/11/10 18:07, Eric Sorenson wrote:
>> Minimally in your current code change 'include repositories::debian' to
>> 'require("repositories::debian")' - this is a built-in function that does an
>> include-plus-require and will produce the ordering you want (Thanks to Jeff
>> Mccune for pointing me at this)
>> http://docs.puppetlabs.com/references/latest/function.html#require
> require was the function I was looking for. So obvious and documented.
It appears that I was a little too early in my celebration.
"require $class" causes you to import the class, however no dependency
is then placed on the *contents* of said class. I'm in exactly the same
position. If I have "require => Class[repository::fedora]" instead of
just "require => Class[repository]" in the Package definition I get the
results desired. This strikes me as a design flaw.
I tried the puppet 2.6.3 gem but it still performs in the same fashion.
I'll try generating some simplified configs in a test environment and
file a bug report. Then I'll redesign everything else.
Dan
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Depending on a class from a class?
On 30/11/10 18:07, Eric Sorenson wrote:
> On Nov 30, 2010, at 7:03 AM, Daniel Piddock wrote:
>
>> Is there any way for a class to depend on another class or for the
>> include statement to act more like a require?
>
> Two things here:
>
> If you're on 2.6.3 put your repositories class in a 'pre' stage, that way you
> eliminate putting an individual dependency on every package resource as
> you're currently doing.
Unfortunately I'm still stuck in 0.25 land. Staging looks like a nicer
solution to some of my problems.
> Minimally in your current code change 'include repositories::debian' to
> 'require("repositories::debian")' - this is a built-in function that does an
> include-plus-require and will produce the ordering you want (Thanks to Jeff
> Mccune for pointing me at this)
> http://docs.puppetlabs.com/references/latest/function.html#require
require was the function I was looking for. So obvious and documented.
Thank you,
Dan
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Depending on a class from a class?
Hello,
I fear that I have done something stupid in my manifests that requires
a redesign. To take an example:
I have the global statement:
Package {
ensure => latest,
require => Class['repositories'],
}
I then have a repositories module with init.pp containing:
class repositories {
case $operatingsystem {
debian: {
include repositories::debian
}
fedora: {
include repositories::fedora
}
default: {
fail "Unsupported OS $operatingsystem'"
}
}
}
Unfortunately I was hoping that an include here would act like a
requirement, however it does not. The contents of debian.pp/fedora.pp
get evaluated at an arbitrary later point causing interesting issues
when first installing a system. Puppet attempts to install some
packages before the repositories have been configured.
Is there any way for a class to depend on another class or for the
include statement to act more like a require?
In this example it would be trivial to change the global statement to
directly require the operating system's repositories subclass.
Unfortunately I have used this paradigm in multiple locations, some
where the alternative may not be as obvious or would increase the
verbosity of the including classes.
Thank you for any pointers,
Dan
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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.
