Ask Your Question

Revision history [back]

Puppet doesn't work that way. :) When you write a manifest, you are defining the desired end state of your node. If the user doesn't exist and you have declared that you want that user to exist, Puppet will create it for you.

The 2nd code snippet you included works a little differently than what you're trying to do, too. The !defined(...) test is checking to see if there is a user resource already present in the catalog, not whether the user exists on the system or not.

Can you describe a little more about what you are trying to achieve? Maybe there's a way to do it within the Puppet "way" once we get some additional details. Theoretically, you could create an exec resource to do what you are asking, but I'd like to know more about your use case.

Puppet doesn't work that way. :) When you write a manifest, you are defining the desired end state of your node. If the user doesn't exist and you have declared that you want that user to exist, Puppet will create it for you.

The 2nd code snippet you included works a little differently than what you're trying to do, too. The !defined(...) test is checking to see if there is a user resource already present in the catalog, not whether the user exists on the system or not.

Can you describe a little more about what you are trying to achieve? Maybe there's a way to do it within the Puppet "way" once we get some additional details. Theoretically, you could create an exec resource to do what you are asking, but I'd like to know more about your use case.

* UPDATE AFTER ADDITIONAL INFO PROVIDED *

Ok, thank you for the clarification on how your systems are set up. While Puppet doesn't generally support a workflow like "if resource X doesn't exist or isn't configured correctly, abort further processing", you could write a custom fact to check for required users and/or filesystems and wrap the rest of your code in an if ${::good_to_go} { ...do stuff... } type check.

Alternately, maybe you should investigate the use of the noop and/or audit metaparameters. Create the user resources and filesystem resources as if Puppet is responsible for managing them. But turn on the appropriate metaparameter so they are not enforced by Puppet or are only monitored for changes.

If you enable noop on the user resource(s) managed by AutoAudit, then make the rest of your manifest dependent on that resource, Puppet will not enforce the rest of the catalog if that user is not present. It's not as though the catalog enforcement aborts immediately, but Puppet will fail to apply the rest of the catalog, which is effectively the same thing.

Here are some links that might help:

  • https://docs.puppetlabs.com/pe/latest/compliance_alt.html
  • https://docs.puppetlabs.com/references/latest/metaparameter.html#noop
  • https://docs.puppetlabs.com/references/latest/metaparameter.html#audit

Puppet doesn't work that way. :) When you write a manifest, you are defining the desired end state of your node. If the user doesn't exist and you have declared that you want that user to exist, Puppet will create it for you.

The 2nd code snippet you included works a little differently than what you're trying to do, too. The !defined(...) test is checking to see if there is a user resource already present in the catalog, not whether the user exists on the system or not.

Can you describe a little more about what you are trying to achieve? Maybe there's a way to do it within the Puppet "way" once we get some additional details. Theoretically, you could create an exec resource to do what you are asking, but I'd like to know more about your use case.

* UPDATE AFTER ADDITIONAL INFO PROVIDED *

Ok, thank you for the clarification on how your systems are set up. While Puppet doesn't generally support a workflow like "if resource X doesn't exist or isn't configured correctly, abort further processing", you could write a custom fact to check for required users and/or filesystems and wrap the rest of your code in an if ${::good_to_go} { ...do stuff... } type check.

Alternately, maybe you should investigate the use of the noop and/or audit metaparameters. Create the user resources and filesystem resources as if Puppet is responsible for managing them. But turn on the appropriate metaparameter so they are not enforced by Puppet or are only monitored for changes.

If you enable noop on the user resource(s) managed by AutoAudit, then make the rest of your manifest dependent on that resource, Puppet will not enforce the rest of the catalog if that user is not present. It's not as though the catalog enforcement aborts immediately, but Puppet will fail to apply the rest of the catalog, which is effectively the same thing.

Here are some links that might help: