3 Answers

It appears you are trying to use Puppet as an auditing or monitoring system. It is decidedly a configuration management system. You can, however, use exported resources to set up nagios checks, so that the monitoring system receives data from the configuration management system. That lets each system do what it's really good at without trying to shoehorn a kludge on top of either one.

For the issue of users going poof, you may also wish to look at something like Tripwire, a host-based auditing and accounting system that will notify you when files change so that you can correlate the activity with your change management systems to determine if it's an authorized change or not.

I do not want the user created if it does not exist. And the manifest must stop immediately.
I have it in the pre stage. I don't want them realized and fail if not there. I need to ensure the home
and user exist and are symlinked correctly depending on the set of systems. I have no control
over the puppet server either, just a manifest to ensure rpm, files, users etc are right.

I also need to abort if there is less then 32TB in that mounted filesystem /x/$env/d01 is an app
directory mount point and then symlinked to /opt/application. I dont control the filesystem design
just need to abort if user is not in that environment rather than plow forward.

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.

Comments

In our environment, puppet is not all-encompassing for configuration management. User/group management is performed by the USPS Engineering-written AutoAudit process, and it should be the only process that modifies user/group configuration. Like puppet, the AutoAudit script will run regularly, and m