How can we find out the directory presence?

[Satish Katuru]

Hi ,

I wanted to find out whether the directory exists or not in the machine.How can I do it?

if I do it as below it will create a directory:

File { " /etc/puppet/test":
ensure => "directory",

}

[Christopher Wood]

This is generally the reason that you need something like puppet, that you want to enforce a configuration.

If you need to detect things about a server, there are a number of things you can do:

a) monitoring (snmp?) check invoking a custom script, script detects the dir
b) use something like mcollective to check in real time whether the dir exists
c) ssh in and use ls

The usual point also, that you should stop asking your servers how they are and tell them how they should be. Declare, don't inquire.

> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [1]puppet-users...@googlegroups.com.
> To view this discussion on the web visit
> [2]https://groups.google.com/d/msgid/puppet-users/6f8d03fb-8d97-4832-a3b7-70868132c451%40googlegroups.com.
> For more options, visit [3]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. mailto:puppet-users...@googlegroups.com
> 2. https://groups.google.com/d/msgid/puppet-users/6f8d03fb-8d97-4832-a3b7-70868132c451%40googlegroups.com?utm_medium=email&utm_source=footer
> 3. https://groups.google.com/d/optout

[Wil Cooley]

On Mon, Aug 18, 2014 at 10:01 AM, Christopher Wood <christop...@pobox.com> wrote:

This is generally the reason that you need something like puppet, that you want to enforce a configuration.

If you need to detect things about a server, there are a number of things you can do:

a) monitoring (snmp?) check invoking a custom script, script detects the dir
b) use something like mcollective to check in real time whether the dir exists
c) ssh in and use ls

d) Write a custom fact; external facts make it as easy as writing a small shell script:

/etc/facter/facts.d/mydir.sh:

#!/bin/sh

test -d /foo/bar && echo "dir_foo_bar_exists=true"

 

The usual point also, that you should stop asking your servers how they are and tell them how they should be. Declare, don't inquire.

That's great advice and a worthwhile long-term goal. But when you're just starting out or are increasing management coverage incrementally, you need to do these kinds of things.

Wil

[Flamarion Jorge]

File { " /etc/puppet/test":
ensure => "directory",

unless => 'test -d /etc/puppet/test'
}

Flamarion Jorge
Sent from my mobile

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/6f8d03fb-8d97-4832-a3b7-70868132c451%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Christopher Wood]

On Mon, Aug 18, 2014 at 01:48:55PM -0700, Wil Cooley wrote:
> On Mon, Aug 18, 2014 at 10:01 AM, Christopher Wood
> <[1]christop...@pobox.com> wrote:
>
> This is generally the reason that you need something like puppet, that
> you want to enforce a configuration.
>
> If you need to detect things about a server, there are a number of
> things you can do:
>
> a) monitoring (snmp?) check invoking a custom script, script detects the
> dir
> b) use something like mcollective to check in real time whether the dir
> exists
> c) ssh in and use ls
>

> d) Write a custom fact; [2]external facts make it as easy as writing a

> small shell script:
> /etc/facter/facts.d/mydir.sh:
> #!/bin/sh
> test -d /foo/bar && echo "dir_foo_bar_exists=true"

If you're using this in manifests and you really can't manage the directory, this is better. Of course, I'd say go for a custom fact rather than an external fact. That way you get pluginsync for free.

https://docs.puppetlabs.com/facter/2.0/fact_overview.html

That said, if you need your monitoring-of-this-directory to eventually alert a human if something goes wrong, you'll need to set up monitoring/ticketing/alerting. Dig around on forge.puppetlabs.com for strings like:

nagios
snmp
monit

>
> The usual point also, that you should stop asking your servers how they
> are and tell them how they should be. Declare, don't inquire.
>
> That's great advice and a worthwhile long-term goal. But when you're just
> starting out or are increasing management coverage incrementally, you need
> to do these kinds of things.
> Wil

That rather depends on your goals, albeit that I'm on my second set of production puppetized services. In short, based on prior horrible experiences, I'm going for "know what you're doing".

For the current set of puppetized hosts I went with:

a) be able to bootstrap all puppet infrastructure from a CentOS minimal install and the puppet git tree (some chicken/egg here requiring manual intervention, I admit)
b) any node should be automagically configurable from a CentOS minimal install to full production readiness with no manual intervention

(The basics.)

This makes knowing what components constitute the puppetized services a direct requirement of running their backend nodes. It took longer to get going, but now there's no puppet-vs-nonpuppet-bits tracking, no "who made that change when", and no "make sure all servers have this" for the puppetized hosts. (Still the basics.)

It has, of course, shown up a number of interesting cultural practices around configuration changes that are still sorting themselves out.

If I had to sum up, I'd say that puppet's main value so far is to throw all this stuff into sharp relief. The automation is good, but knowing what it takes to run things is the real advantage.

> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to [3]puppet-users...@googlegroups.com.

> To view this discussion on the web visit

> [4]https://groups.google.com/d/msgid/puppet-users/CAMmm3r7XFyhLHy2ocT1JSydYuY1GvJW9H_4XgJVQCKwptWeWEw%40mail.gmail.com.
> For more options, visit [5]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. mailto:christop...@pobox.com
> 2. https://docs.puppetlabs.com/facter/latest/custom_facts.html#external-facts
> 3. mailto:puppet-users...@googlegroups.com
> 4. https://groups.google.com/d/msgid/puppet-users/CAMmm3r7XFyhLHy2ocT1JSydYuY1GvJW9H_4XgJVQCKwptWeWEw%40mail.gmail.com?utm_medium=email&utm_source=footer
> 5. https://groups.google.com/d/optout

[Yanis Guenane]

Jorge,

This is wrong. unless is not a parameter of the file resource

https://docs.puppetlabs.com/references/latest/type.html#file

unless applies only to the exec resource.

--
Yanis Guenane

> <https://groups.google.com/d/msgid/puppet-users/6f8d03fb-8d97-4832-a3b7-70868132c451%40googlegroups.com?utm_medium=email&utm_source=footer>
> .

[Flamarion Jorge]

Ok. I'm sorry.  Here other way.

exec { "create dir":
....
command => 'mkdir -p /etc/puppet/test'

unless => 'test -d /etc/puppet/test'

......
}

Now your directory will be created if it doesn't exist.

Flamarion Jorge
Sent from my mobile

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/53F3912C.50504%40gmail.com.

[Sneha More]

Jorge, :

the other way you specified does the same as:

File { " /etc/puppet/test":
ensure => "directory",
}

This will also create a directory if it does not exist.

Satish:

There must be some reason for which you are checking presence of directory.

So you can add unless condition with exec resource as specified by Jorge to execute something if the the directory is present or not

Thanks and Regards,

Sneha More

[Martin Alfke]

Hi,

you want to find out whether a directory exists on a node.
This has to be done on the node by using custom facts.

When the master compiles the catalog you want to switch processing of Puppet code depending on the fact result.

This means:

you have to write a custom fact which best distributed to the nodes.
(https://docs.puppetlabs.com/facter/2.1/custom_facts.html)
This fact will be available as variable on the master during catalog compile.

You then want to check for the fact and split stuff.



Besides this: you want to tell your node how it should look like. You do not want your node to make decisions what he wants.

hth,

Martin

> To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/fe796814-04d6-496f-adb4-d6bc66691317%40googlegroups.com.

[Jason_s]

you could drop down into pure ruby and evaluate that inside an inline_template…

[Christopher Wood]

That might work if you were compiling the catalog on the server where the catalog will be applied. Functions/templates are run during catalog compilation so this will not find a directory on a pure-agent node.

https://docs.puppetlabs.com/learning/templates.html
https://docs.puppetlabs.com/guides/templating.html

> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to [1]puppet-users...@googlegroups.com.

> To view this discussion on the web visit

> [2]https://groups.google.com/d/msgid/puppet-users/dc11f203-f961-4fb0-8004-be7ed51b02a6%40googlegroups.com.
> For more options, visit [3]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. mailto:puppet-users...@googlegroups.com
> 2. https://groups.google.com/d/msgid/puppet-users/dc11f203-f961-4fb0-8004-be7ed51b02a6%40googlegroups.com?utm_medium=email&utm_source=footer
> 3. https://groups.google.com/d/optout