[Puppet Users] Re: file, recurse and managing subdirectories
Hi >> Is this the expected behavior, is there a workaround or is it simply >> a bug? > > I don't think I completely understood your examples, but it's expected > behaviour that Puppet will not manage through recursion any files > you're explicitly managing. I think you got it. :) > To Puppet, there are implicit and explicit resources; anything that > shows up directly in your catalog is an explicit resource, anything > managed through recursion is implicit. Implicit resources that > conflict with explicit resources always just get ignored. Crucially > for you, when doing recusion, explicit resources cause the recursion > to stop at the explicit point. > > Imagine if you wanted to do recursive management on that second file > statement - what behaviour woould you expect to see, if the top-level > recursion still managed the other directory, especially if purging > were enabled? You'd have the two file statements fighting, it seems. I was also thinking that, but wasn't sure if it really might be the problem. > So yeah, this is expected behaviour, and I don't think it's a bug, but > maybe others disagree. So expected behavior. And I now also see the solution for my use case. I just have to readd, the subsource part. :/ thanks for looking at it and cheers pete. --~--~-~--~~~---~--~~ 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: exec issue
On Fri, 20 Mar 2009 17:32:12 +0500, Mike Renfro wrote:
YUPI! SOLVED
That variant is ok!
exec { "/usr/bin/chpass -p '\$1\$HvjTWzzz\$jF.G/mEbh7IOtpCdUPUTO1' pt_":}
Thank everybody who helps me.
>
> nick.maystre...@gmail.com wrote:
>> On Fri, 20 Mar 2009 06:18:42 +0500, jrojas
>> wrote:
>> Am I understand you right? I must exec this string "/usr/bin/chpass -p
>> \$1\$HvjTWzzz\$jF.G/mEbh7IOtpCdUPUTO1 pt_"
>> If yes, so it is not work((
>> PS This is my "new" config string which NOT working as I want: exec {
>> "/usr/bin/chpass -p \$1\$HvjTWzzz\$jF.G/mEbh7IOtpCdUPUTO1 pt_":}
>>
>>> You have to escape the dollar signs or quote the text specifically.
>
> or quote it: command => "/usr/bin/chpass -p '$1$foo$bar' pt_";
>
> worst case, put the command in a shell script, pull the script to the
> client with a file entry, and exec it. Might be a grep typo in the
> onlyif statement below -- it's intended to run the chpass script if and
> only if the password is set incorrectly. Otherwise, you could write
> whatever logic you want in the script to ensure that the password isn't
> already set properly before it runs chpass.
>
> file { "/path/to/script":
>source => "puppet://server/other/path/to/script",
>mode => 0700;
> }
>
> exec { "chpass_pt_":
>command => "/path/to/script",
>onlyif => "egrep -q '^pt_:.*UPUTO1:' /path/to/passwd",
>require => File["/path/to/script"];
> }
>
--~--~-~--~~~---~--~~
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: exec issue
nick.maystre...@gmail.com wrote:
> On Fri, 20 Mar 2009 06:18:42 +0500, jrojas wrote:
> Am I understand you right? I must exec this string "/usr/bin/chpass -p
> \$1\$HvjTWzzz\$jF.G/mEbh7IOtpCdUPUTO1 pt_"
> If yes, so it is not work((
> PS This is my "new" config string which NOT working as I want: exec {
> "/usr/bin/chpass -p \$1\$HvjTWzzz\$jF.G/mEbh7IOtpCdUPUTO1 pt_":}
>
>> You have to escape the dollar signs or quote the text specifically.
or quote it: command => "/usr/bin/chpass -p '$1$foo$bar' pt_";
worst case, put the command in a shell script, pull the script to the
client with a file entry, and exec it. Might be a grep typo in the
onlyif statement below -- it's intended to run the chpass script if and
only if the password is set incorrectly. Otherwise, you could write
whatever logic you want in the script to ensure that the password isn't
already set properly before it runs chpass.
file { "/path/to/script":
source => "puppet://server/other/path/to/script",
mode => 0700;
}
exec { "chpass_pt_":
command => "/path/to/script",
onlyif => "egrep -q '^pt_:.*UPUTO1:' /path/to/passwd",
require => File["/path/to/script"];
}
--
Mike Renfro / R&D Engineer, Center for Manufacturing Research,
931 372-3601 / Tennessee Technological University -- ren...@tntech.edu
--~--~-~--~~~---~--~~
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: exec issue
On 2009-Mar-20, at 2:07 AM, nick.maystre...@gmail.com wrote:
> PS This is my "new" config string which NOT working as I want: exec {
> "/usr/bin/chpass -p \$1\$HvjTWzzz\$jF.G/mEbh7IOtpCdUPUTO1 pt_":}
Have you tried single quotes? (I'm not sure if you even need to keep
the backslashes with single quotes.)
--
Rob McBroom
[Puppet Users] Re: Custom Types and autonotify?
On Mar 19, 2009, at 6:23 PM, Luke Kanies wrote:
On Mar 18, 2009, at 1:23 PM, Jim Pirzyk wrote:
I have been working on full feature syslog type and providers. I
have a few questions about how to do things.
1) How do I have a type 'implement' functionality from another type.
For example, I have these 2 types:
file {"/var/log/ipfw.log":
ensure => present,
mode => 600,
owner => root,
group => wheel,
}
syslog { "/var/log/ipfw.log":
selector => 'security.info'',
ensure => present,
notify => [ Service[syslog] ]
mode => 600,
owner => root,
group => wheel,
}
I'd like not to have the first file{} type and have the provider
'touch' the file if it does not exist.
You could have the syslog type generate the file resource:
def generate
Puppet::Type.type(:file).create(:path => self[:name], :mode
=> ) unless catalog.resource(:file, self[:name])
end
Something like that, anyway.
2) Is there an 'autonotify' feature like there is autorequire? Seems
like I should be able to have it notify the syslog service every time
I update the syslog.conf file.
There is not; I've never had anyone ask for it. I'd accept a patch
for it, but you can hack it in the initialize method in the meantime.
I'll take a crack at it.
I just though of another case where this would be useful, running
'newaliases' after /etc/mail/aliases has been updated. What do other
people do? I have
mailalias { foo:
...
notify => [ Exec[newaliases] ]
}
on each mailalias type. I thought last night that:
Mailalias {
notify => [ Exec[newaliases] ]
}
would work, but it does not seem to.
Just do something like:
def initialize(*args)
super
self[:notify] = [:service, "syslog"]
end
Yes, hackish, but that's what you get for being special. :)
OTOH, if you're generating the file as above, then include the
'notify' value in the arguments to it.
Adding the notify to the file creation is not the same. Usually the
file only get created once, but I need syslog HUP'ed everytime that /
etc/[r]syslog.conf is updated, regardless of the destination log file
existing or not.
- JimP
--- @(#) $Id: dot.signature,v 1.15 2007/12/27 15:06:13 pirzyk Exp $
__o j...@pirzyk.org ---
_'\<,_
(*)/ (*) I'd rather be out biking.
PGP.sig
Description: This is a digitally signed message part
[Puppet Users] Re: Custom Types and autonotify?
Hi
> I just though of another case where this would be useful, running
> 'newaliases' after /etc/mail/aliases has been updated. What do
> other people do? I have
>
> mailalias { foo:
> ...
> notify => [ Exec[newaliases] ]
> }
>
> on each mailalias type. I thought last night that:
>
> Mailalias {
> notify => [ Exec[newaliases] ]
> }
>
> would work, but it does not seem to.
this should do it. but this definition should be included as first,
before any the other Mailalias definitions. I have plenty of such
statements, and they work fine.
Another thing is to add a wrapper define, which will set the
appropriate defaults on your exec. Actually for the alias type I do it
that way.
cheers pete
--~--~-~--~~~---~--~~
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: Custom Types and autonotify?
On Mar 20, 2009, at 10:00 AM, Peter Meier wrote:
Hi
I just though of another case where this would be useful, running
'newaliases' after /etc/mail/aliases has been updated. What do
other people do? I have
mailalias { foo:
...
notify => [ Exec[newaliases] ]
}
on each mailalias type. I thought last night that:
Mailalias {
notify => [ Exec[newaliases] ]
}
would work, but it does not seem to.
this should do it. but this definition should be included as first,
before any the other Mailalias definitions. I have plenty of such
statements, and they work fine.
Another thing is to add a wrapper define, which will set the
appropriate defaults on your exec. Actually for the alias type I do it
that way.
What version? I'm running 0.24.7. I have other resource defaults,
and they did work. I have not tested it lately. I have defined the
Mailalias within the 'mail' class and I'm testing in my 'ssh::client'
class. The mail is imported before ssh and the mail class is
included before the ssh::client class.
- JimP
--- @(#) $Id: dot.signature,v 1.15 2007/12/27 15:06:13 pirzyk Exp $
__o j...@pirzyk.org ---
_'\<,_
(*)/ (*) I'd rather be out biking.
PGP.sig
Description: This is a digitally signed message part
[Puppet Users] ensuring puppet version - Ubuntu problem
Hi,
I've setup puppet to install apache2 version 2.2.9-7 (which isn't
available to the client).
Puppet installs apache-2.2.8-1ubuntu0.3.
Isn't it suppose to fail instead, when I've defined a version it can't
install?
This is my apache2 class:
class apache2 {
$packagelist = ["apache2"]
package { $packagelist:
ensure => "2.2.9-7",
ensure => "installed",
}
file { "/etc/apache2/apache2.conf":
ensure => present,
owner => "root",
group => "root",
mode => 644,
source => "puppet://puppetmaster.u.net/files/apache2/apache2.conf",
}
service { apache2:
hasrestart => "true",
hasstatus => "true",
enable => "true",
ensure => "running",
require => Package["apache2"]
}
}
/klavs
--~--~-~--~~~---~--~~
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] puppetrun could not call puppetrunner.run
Hi folks, I've searched around the group and couldn't find something that would specifically answer my problem. I was trying to use puppetrun to force an update on a specific host machine but ended up with the following error: # puppetrun --host client1.int Triggering client1.int err: Could not call puppetrunner.run: # Host client1.int failed: HTTP-Error: 500 Internal Server Error client1.int finished with exit code 2 Failed: client1.int I turned on verbose logging on the receiving side, and all I saw was: # puppetd --no-daemonize --listen --verbose --no-client info: Starting handler for Runner info: Starting server for Puppet version 0.24.7 info: Listening on port 8139 info: access[puppetrunner]: allowing puppet access Appreciate if you guys can point me in the right direction. 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 -~--~~~~--~~--~--~---
[Puppet Users] automating portinstall via puppet on freebsd
Hi there, this is not really a puppet reltated question but maybe someone who uses puppet on freebsd machines has bumped into the same problem. I want puppet to take care that certain ports are installed or updated which works fine ... ... as long as there is no user input during the installation process. But there are ports like "nagios-plugins" or "munin-node" who ask the user for confirmation whether to install users and stuff. Despite a "BATCH=yes" entry in /etc/make.conf these confirmations don't vanish and the installation process stops. So the puppetd hangs awaiting a user input. What makes things worse: I have no clue how to connect to a running puppet process which doesn't have a terminal (it's just a cron job without a terminal). Anybody out there who can help me out? best regards, Bernd Kuhlen --~--~-~--~~~---~--~~ 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: ensuring puppet version - Ubuntu problem
I found that according to a comment in the apt provider, it does not
yet support enforcing versions :(
I guess I'll have to implement it, if I really need it :)
On 20 Mar., 15:32, "Klavs Klavsen" wrote:
> Hi,
>
> I've setup puppet to install apache2 version 2.2.9-7 (which isn't
> available to the client).
>
> Puppet installs apache-2.2.8-1ubuntu0.3.
>
> Isn't it suppose to fail instead, when I've defined a version it can't
> install?
>
> This is my apache2 class:
> class apache2 {
> $packagelist = ["apache2"]
> package { $packagelist:
> ensure => "2.2.9-7",
> ensure => "installed",
> }
>
> file { "/etc/apache2/apache2.conf":
> ensure => present,
> owner => "root",
> group => "root",
> mode => 644,
> source => "puppet://puppetmaster.u.net/files/apache2/apache2.conf",
>
> }
>
> service { apache2:
> hasrestart => "true",
> hasstatus => "true",
> enable => "true",
> ensure => "running",
> require => Package["apache2"]
>
> }
> }
>
> /klavs
--~--~-~--~~~---~--~~
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] scoping of variables in modules for reuse
Hi All,
I wanted to make a module of mine to be more re-usable by declaring a
variable somewhere in it. I wanted users to be able to override the
variable, but I also wanted the module to work if they instantiated the
class directly. I'm using puppet 0.24.5 (and the -3 debian subversion)
and I found that if I do something like the following:
class reprepro-test1 inherits reprepro {
$reprepro_dir = "/tmp/reprepro_archive1"
}
class reprepro-test2 {
$reprepro_dir = "/tmp/reprepro_archive2"
include reprepro
}
node default {
include reprepro-test1
include reprepro-test2
include reprepro
}
With the following file (reprepro/manifests/init.pp) on the module
search path:
class reprepro {
$reprepro_dir = "/tmp/reprepro_archive_module"
file { $reprepro_dir:
ensure => directory,
}
}
Then /tmp/reprepro_archive_module gets created with no warnings or
errors (due to the node including reprepro), but /tmp/reprepro-test2
does not get created. My variable does not get overloaded.
If I change the module to:
$reprepro_dir = "/tmp/reprepro_archive_module"
class reprepro {
file { $reprepro_dir:
ensure => directory,
}
}
And I stop using class reprepro-test1 in the node (*):
node default {
#include reprepro-test1
include reprepro-test2
inclure reprepro
}
Then I only get "/tmp/reprepro_archive2" created, and no warnings.
So I think the following statements are true:
* variables in a module have scope of only that module.
* The scope of variables inside classes bind tighter than those of
module variables.
* Class inheritance is limited (as the documentation says), you can't
override parent variables.
* class includeness binds tighter than module variables, regardless of
where in the module you declare the variable.
I can't think of how I can achieve what I want, where both "include
reprepro-test2" and "include reprepro" do what I expect them to do.
I also tried in a separate file:
$reprepro_dir = "/tmp/reprepro_archive3"
class reprepro-test3 inherits reprepro {
}
class reprepro-test4 {
include reprepro
}
But it looks like class reprepro-test3 behaves exactly like
reprepro-test1, and reprepro-test4 behaves exactly like class reprepro.
The $reprepro_dir in that file gets global scope, and gets overridden by
the definition of $reprepro_dir in the module, regardless of where in
the module you declare it.
So I think that the documentation here:
http://reductivelabs.com/trac/puppet/wiki/LanguageTutorial#importing-manifests
says:
Puppet has an import keyword for importing other manifests. Code in
those external manifests should always be stored in a class or
definition or it will be imported into the main scope and applied to
all nodes.
Should be extended to describe how the scope of variables in modules
works. But I've already spent an hour writing this email, so I'm not
going to suggest a patch just now.
(*) If you keep reprepro-test1 included, then when reprepro-test1 is
evaluated the $reprepro_dir is not defined at all, and you see the
following errors:
err: Could not create : Parameter path failed: File paths must be fully
qualified
warning: Not using cache on failed catalog
warning: Configuration could not be instantiated: Parameter path failed:
File paths must be fully qualified
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
