RE: [Puppet Users] compare filebucket

[Jennings, Jared L CTR USAF AFMC 46 SK/CCI]

Judging from your log messages, the bucketed file is on the puppetmaster
("Filebucketed... to puppet"). You can use this command to get it:

puppet filebucket get 26e643361f26cdf766199a830417c8bf > /tmp/old-file

(Or at least, I can, with Puppet 2.7.6.) Then you can

diff -u /tmp/old-file /etc/nginx/nginx.conf
rm /tmp/old-file


> -Original Message-
> From: puppet-users@googlegroups.com [mailto:puppet-
> us...@googlegroups.com] On Behalf Of Peter Horvath
> Sent: Monday, May 14, 2012 11:10 AM
> To: Puppet Users
> Subject: [Puppet Users] compare filebucket
> 
> Hello,
> 
> Does anybody know how to compare a filebucketed file easily with the
> current file based on these infos?
> 
> info: /Stage[main]/Nginx/File[/etc/nginx/nginx.conf]: Filebucketed
> /etc/nginx/nginx.conf to puppet with sum
> 90dbcd7cf0accf5d372d077a6c90020c
> remote: notice:
/Stage[main]/Nginx/File[/etc/nginx/nginx.conf]/content:
> content changed '{md5}90dbcd7cf0accf5d372d077a6c90020c' to
> '{md5}26e643361f26cdf766199a830417c8bf'
> 
> Thank you
> Peter
> 
> --
> 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.

-- 
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] FIPS 140-2 compliance

[Jennings, Jared L CTR USAF AFMC 46 SK/CCI]

Pittman:
> Hey, thanks for filing away that request.  We had previous folks
> asking for similar things, but no one indicated that FIPS compliant
> OpenSSL would absolutely refuse to work with MD5, full stop.
> Am I right in imagining, given your title, that FIPS mode is an
> absolute requirement for y'all to use Puppet on your systems?

I believe I understand your question when I say: yes, we have to use FIPS mode 
on our systems; if Puppet does not work under FIPS mode, we can't use Puppet.

At my site, right now, it works ok, because I have locally-made RPM packages of 
Puppet and Ruby with the rough patches that I've indicated in the issue reports 
I've filed. For J. Random Federalgovernment Admin, it probably needs to work 
more smoothly. (What were her parents thinking, giving her two middle names...)

Further reading:

 (look for DCAS-1 
and DCCS-2)

Federal Information Security Management Act (FISMA)

-- 
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] FIPS 140-2 compliance

[Jennings, Jared L CTR USAF AFMC 46 SK/CCI]

I've just posted a feature request
 relating to FIPS 140-2
compliance. I'm pointing to it here on the mailing list because I listed
there five places where Puppet (nay, Ruby!) crashed while I was testing
a deployment using FIPS mode on all hosts. It crashed because it tried
to use MD5, and OpenSSL in FIPS mode doesn't let you do that. When I
replaced these five usages of Digest::MD5 with Digest::SHA256, things
ran well, but it's merely a stopgap.

-- 
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] puppet CA expired

[Jennings, Jared L CTR USAF AFMC 46 SK/CCI]

> [master]
> ca_ttl = 20y

Neat trick. By the time it expires you'll be gone! :P

-- 
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] logging output at err level, success as just a notice?

[Jennings, Jared L CTR USAF AFMC 46 SK/CCI]

Helwig:
> On Tue, 07 Jun 2011 10:29:12 -0500, Jennings, Jared L CTR USAF AFMC 46
> SK/CCI wrote:
> > pwck indeed behaves nicely with its exitcodes - the problem is I
want
> > the output to be an err, not a notice
> 
>   exec { 'pwck -r':
> path  => '/usr/bin:/bin:/usr/sbin:/sbin',
> logoutput => on_failure,
> loglevel  => err,
> unless=> 'pwck -r',
>   }
> 
> By doing the "unless => 'pwck -r'", the resource won't even show up as
> having been run if 'pwck -r' returns 0.  Having to run the command
> twice is a hack, but it's the best I can think of at the moment.

Ah, that's a good hack. No problem for me, pwck runs quickly enough.

> Seems reasonable that when "logoutput => on_failure" the actual output
> should be logged as an err, instead of a notice.  Would you mind
filing
> a feature request on the issue tracker[1]?

#7877.

Thanks for your help!

-- 
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] logging output at err level, success as just a notice?

[Jennings, Jared L CTR USAF AFMC 46 SK/CCI]

Helwig:
> Unfortunately, the documentation is just plain wrong.  loglevel is the
> only one that supports "any legal log level".  logoutput really does
> only support true, false, and on_failure.
> 
> Is pwck exiting non-zero when there is output?  That should be
> sufficient to trigger the behavior it seems like you're looking for if
> you have 'logoutput => on_failure' in the exec.

pwck indeed behaves nicely with its exitcodes - the problem is I want
the output to be an err, not a notice:

notice: /Stage[main]/User::Valid/Exec[pwck]/returns: user 'foo':
directory '/home/foo' does not exist
notice: /Stage[main]/User::Valid/Exec[pwck]/returns: pwck: no changes
err: /Stage[main]/User::Valid/Exec[pwck]/returns: change from notrun to
0 failed: /usr/sbin/pwck -r returned 2 instead of one of [0] at
/etc/puppet/modules/user/manifests/valid.pp:11

If I set loglevel => err, that makes the output purple, but if pwck is
happy, the loglevel setting also makes the "ran successfully" message an
err.

-- 
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] logging output at err level, success as just a notice?

[Jennings, Jared L CTR USAF AFMC 46 SK/CCI]

I'm trying to run pwck with Puppet 2.6.4. pwck checks the passwd file
and makes sure that, for example, each user's home directory exists.
(And other stuff.) When everything is OK, it doesn't say anything. So if
it says something, I want to know it, and I want it to stand out from
other exec output.

So I have

exec { "pwck":
command => "/usr/sbin/pwck -r",
logoutput => true,
loglevel => err,
}

If pwck gives any output, it shows up at the err loglevel. But if
everything is OK, I get:

err: /Stage[main]/User::Valid/Exec[pwck]/returns: executed successfully

(in purple, of course). I don't want an err message when everything is
fine.

The documentation for the exec resource type
() says, about
logoutput, "Values are true, false, on_failure, and any legal log level.
Valid values are true, false, on_failure." (Take a second and read that
again.) So I tried setting logoutput => err and no loglevel, and got:
'err: Could not run Puppet configuration client: Parameter logoutput
failed: Invalid value "err". Valid values are true, false, on_failure.'

How can I make "executed successfully" a notice, and any output from
pwck an err?

If logoutput can indeed be set to any legal log level, does anyone know
in what version of Puppet this works?

-- 
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] changing the default key length and hash

[Jennings, Jared L CTR USAF AFMC 46 SK/CCI]

> Ah.  I was thinking in the broader scope of getting us away from
> insecure hashes elsewhere in the product.  From a strictly certificate
> POV, indeed, it should be just fine.

I'm trying to configure FIPS-compliant servers, and I've run into segfaults 
thrown by the Ruby interpreter when Puppet tries to use MD5. I think this is a 
problem somewhere else in my system, not Puppet, but it highlights the issue 
that I need Puppet to be able to use other hashing algorithms in its system 
configuration work, not merely in its certificates.

I've got an internal patch that replaces Digest::MD5 with Digest::SHA2 in 
puppet/util/checksums.rb and in puppet/parser/functions/md5.rb, but this method 
lacks finesse. The DSL function is still called md5, and the string 
representation of a file still starts with '{md5}' even though the rest is an 
SHA256 sum.

It appears that puppet/util/checksums.rb was a start at adding hash algorithm 
flexibility, but the '{md5}' is added on elsewhere.

Has someone else already done things about this?

-- 
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] cannot create www-data user

[Jennings, Jared L CTR USAF AFMC 46 SK/CCI]

> It's rather confusing because I do have www-date defined in a file
> called group.pp
> 
> Which has the user defined like this:
> 
> group { 'www-data':
> ensure => 'present',
> gid => '33'
> }

I don't see that you have a user resource for the www-data user. What
you've defined above is a group resource. It's common to have a group
and a user by the same name, but they aren't the same thing: on most
unix OSes, groups are configured in /etc/group, and users in
/etc/passwd.

When you run useradd manually, you are creating the user. If you write a
user resource in your manifest, like

user { 'www-data': ensure => present, uid => 48, gid => 'www-data' }

that would also create the user. You'd also want your service resource
to require User['www-data'] as well as Group['www-data'].

Charles Johnson sez:
> We use CentOS 5.x and by default httpd runs as the apache user and not
> www-data.

I believe the www-data user is common in Debian and derivatives (eg
Ubuntu). - Ah, I see the references to CentOS in the manifest. *shrug* 

-- 
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] augeas slooow

[Jennings, Jared L CTR USAF AFMC 46 SK/CCI]

Hi, Aaron.

Aaron (quoting letter@):
> To avoid that, I added 'lens' and 'incl' parameters to the puppet type
> a while ago. If you set these, Augeas will only read a specific file,
> avoiding most of the unnecessary overhead.
> ... everything will be lightning fast, even without
> connection caching."

Me:
> I know I can avoid [Augeas populating its whole tree] by specifying 
> the lens and incl parameters in my augeas resources, but I like the
> clarity I get by not doing that, and want to preserve it.

The reason I brought the issue up is that I wanted to know why Augeas
connections are not cached. I think they should be, but someone on this
list may have tried to make that change, failed, and gained wisdom.

> lens => "Hosts.lns",

It's nice to find that I may not have to give the full path of the lens.

-- 
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] Puppet on Redhat 6

[Jennings, Jared L CTR USAF AFMC 46 SK/CCI]

> > > > "/bin/echo OS: $operatingsystem"

You are right, Stefan! I didn't pay attention at all to the command
being executed.

-- 
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] Puppet on Redhat 6

[Jennings, Jared L CTR USAF AFMC 46 SK/CCI]

> > my motd module is like this:
> >
> > class motd {
> >
> > $ascii = generate('/bin/sh', '-c', "/bin/echo OS:
> > $operatingsystem )
> >
> 
> Not an answer to your problem, but isnt this the same as
> 
> $ascii = "OS: ${operatingsystem}"
> 
> -Stefan

I believe the function is evaluated on the server, whereas the fact is
evaluated on the client

-- 
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: RFC: Splitting up the file{} type functionality.

[Jennings, Jared L CTR USAF AFMC 46 SK/CCI]

jcbollinger:
> On the other hand, perhaps the new thing needed is something
> different: what about resource sub-types? [...]
> plainfile { "/etc/profile.d/foo.sh": source => "..." }
> filelink { "/etc/profile.d/foo.sh": target => "/opt/foo/foo_env.sh" }
> service { "foo": require => File["/etc/profile.d/foo.sh"] }
...
> it models the problem domain better

This is an excellent idea. It breaks the exact correspondence between
file/File, service/Service, etc., but that's easier to explain than
symlinks and recursion (if not easier to implement).

-- 
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] augeas slooow

[Jennings, Jared L CTR USAF AFMC 46 SK/CCI]

Oho, this --evaltrace is what I was looking for. Thanks!

> -Original Message-
> From: puppet-users@googlegroups.com [mailto:puppet-
> us...@googlegroups.com] On Behalf Of Nigel Kersten
> Sent: Tuesday, March 22, 2011 4:40 PM
> To: puppet-users@googlegroups.com
> Cc: saurabh verma
> Subject: Re: [Puppet Users] augeas slooow
> 
> On Tue, Mar 22, 2011 at 1:24 PM, saurabh verma

> wrote:
> >>
> >>
> >> How can I profile my Puppet catalog, to see what resources take the
> >> longest to set straight? (I've only got puppet apply for now - no
> master
> >> yet)
> >>
> >> --
> >
> > +1 for profiling feature
> 
> More than --evaltrace ?
> 
> 
> 
> 
> >
> > --
> > 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.
> >
> >
> 
> 
> 
> --
> Nigel Kersten
> Product, Puppet Labs
> @nigelkersten
> 
> --
> 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.

-- 
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] augeas slooow

[Jennings, Jared L CTR USAF AFMC 46 SK/CCI]

I've got somewhere around 130 Augeas resources in my policy (catalog,
entire set of manifests, what-have-you) and 11 custom lenses, each for
only one or two files, and it takes like 2 1/2 minutes to apply the
whole thing. Looking at the --debug output, there are a whole lot of
pauses right after "opening Augeas" sorts of lines. (That happens 79
times.) I think that's because Augeas is populating its whole tree, each
time.

I know I can avoid that behavior by specifying the lens and incl
parameters in my augeas resources, but I like the clarity I get by not
doing that, and want to preserve it.
 
Has anyone ever tried to make it so that only one Augeas connection is
opened per Puppet run?

How can I profile my Puppet catalog, to see what resources take the
longest to set straight? (I've only got puppet apply for now - no master
yet)

-- 
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] provisioning bare metal (best practices)

[Jennings, Jared L CTR USAF AFMC 46 SK/CCI]

> Jared,
> Are you suggesting separate physical subnet, or simply a logical
subnet
> on the same physical network (using netmask)?

Mine's physically separate. I think it's what is required (google UNIX
STIG; see section 12.6), and it simplifies configuration and usage (this
network does this thing; the other doesn't).

Also once kickstarting is over, I'm going to trust the new host and
allow it access to a bunch of things, calm in knowing that I caused
every formative change to its configuration. I don't want to be wrong
about that.

And there's no effort wasted on this in our office: the IT team receives
all the new systems, and we have to configure the BIOS anyway before
letting one out on the floor, so just drop it in the inner sanctum for
an hour or two to kickstart.


-- 
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] RHEL5 and RHEL6 wiith Puppet

[Jennings, Jared L CTR USAF AFMC 46 SK/CCI]

> > Has anyone else spotted any other changes requiring alteration to
the
> Puppet
> > manifests and modules?

If you have anything that changes the inittab, it may not work: they
switched to Upstart for RHEL6.

-- 
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] provisioning bare metal (best practices)

[Jennings, Jared L CTR USAF AFMC 46 SK/CCI]

+1 for Cobbler.
 
At my site, we don't kickstart on the production network, in order to
avoid the case where a not-fully-secured machine is exposed to network
attacks. My kickstart network is all in one room, and so is easier to
secure, logically and physically. On such a network, automatic
certificate signing would likely be suitably secure, and assigning roles
by MAC is easy using Cobbler.

While you may not be subject to the same regulatory restraints, David, I
suggest a separate kickstart network as a best practice.

-- 
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] custom type with cool source parameter

[Jennings, Jared L CTR USAF AFMC 46 SK/CCI]

> http://docs.puppetlabs.com/guides/modules.html <-- I guess you want to
> define your own module.

Yup, did that already.

The answer I was looking for is this.

Given: we want a custom type my_cool_type such that we can write

my_cool_type { "bla":
justsometext => "hi mom",
source => "puppet:///modules/six/file.txt",
}

To make a source parameter in this custom type which will fetch the
given content, do something like so:

Puppet::Type.newtype(:my_cool_type) do
ensurable do
defaultvalues
defaultto :present
end

newparam(:justsometext) do
desc "A string of your choosing."
end

newparam(:source) do

[Now copy the validate, munge, cached_attr(:content), and
cached_attr(:metadata) from puppet/type/file/source.rb in here.]

end
end

In the provider, it's usual to get at the parameter values like
@resource[:paramname]. This will get us the value of the justsometext
parameter:

Puppet::Type.type(:my_cool_type).provide :strange_magic do
def create
self.debug "The string of the admin's choosing was
#{@resource[:justsometext]}."

end
end

But @resource[:source] is just the puppet:/// url. It's supposed to have
this content method; how do we call that? Answer: @resource[:source] is
a shortcut for @resource.parameter(:source).value.
@resource.parameter(:source) gets the parameter object, upon which we
can call the content method.

def create
self.debug "The contents of file.txt are
#{@resource.parameter(:source).content}"
end

-- 
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] custom type with cool source parameter

[Jennings, Jared L CTR USAF AFMC 46 SK/CCI]

> Felix, thanks for your quick reply, but I'm trying to write a new
type,
> not use the file type.

Oops, I misread your email, Felix. But I think the file function still
isn't what I'm after: I think I want the contents to be loaded from a
puppet:/// url, not an absolute path, because I want the same behavior
as the file type's source parameter where if I use puppet apply, it
looks in the module path, and if I use puppet agent, it gets it whence
it got the manifest.

(And: sorry for topquoting... magic 8 ball says, "outlook not so good")

-- 
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] custom type with cool source parameter

[Jennings, Jared L CTR USAF AFMC 46 SK/CCI]

Felix, thanks for your quick reply, but I'm trying to write a new type,
not use the file type. I've done stuff like

file { "/etc/pam_pkcs11/cacerts/myca.crt":
source => "puppet:///modules/pki/cacerts/myca.crt"
}

But what I want to do now is

nss_ca_cert { "myca":
source => "puppet:///modules/pki/cacerts/myca.crt"
}

where I've defined the nss_ca_cert type by writing some Ruby code. The
Ruby that creates the 'source' parameter for the 'file' type is right in
front of me, at /usr/lib/ruby/site_ruby/1.8/puppet/type/file/source.rb,
but I don't understand it well enough to know what I need to take from
it.

> -Original Message-
> From: puppet-users@googlegroups.com [mailto:puppet-
> us...@googlegroups.com] On Behalf Of Felix Frank
> Sent: Friday, February 18, 2011 8:52 AM
> To: puppet-users@googlegroups.com
> Subject: Re: [Puppet Users] custom type with cool source parameter
> 
> Hi,
> 
> you're not required to add all content to the manifest proper.
> Take note of the file() function.
> 
> http://docs.puppetlabs.com/references/stable/function.html#file
> 
> HTH,
> Felix
> 
> On 02/18/2011 03:41 PM, Jennings, Jared L CTR USAF AFMC 46 SK/CCI
> wrote:
> > I'm making a custom type under Puppet 2.6.4 to manage CA
certificates
> in
> > an NSS certificate database by running certutil. I've got it where
> when
> > I pass a content parameter with the whole -BEGIN
CERTIFICATE-
> > ewofifewoiihefwo wfoiefwjowejwfoifj oiejfw oefwij eoijfew ofewij weo
> > -END CERTIFICATE- stuff, it will add the CA certificate. But
> I
> > don't want to paste the certificate into the policy, I want to keep
> it
> > in a separate file, and use source =>
> > 'puppet:///modules/pki/ca-certs/my-ca.crt' - like the file type
does.
> > Try as I might, I haven't yet been able to duplicate the magic of
> that
> > parameter in my own type.
> >
> > What do I really need in order to get from
> > 'puppet:///modules/pki/ca-certs/my-ca.crt' to '-BEGIN
> > CERTIFICATE-...'? Do I need cached attributes? Do I need to
fetch
> > metadata? What's about all these checksums?
> >
> 
> --
> 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.

-- 
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] custom type with cool source parameter

[Jennings, Jared L CTR USAF AFMC 46 SK/CCI]

I'm making a custom type under Puppet 2.6.4 to manage CA certificates in
an NSS certificate database by running certutil. I've got it where when
I pass a content parameter with the whole -BEGIN CERTIFICATE-
ewofifewoiihefwo wfoiefwjowejwfoifj oiejfw oefwij eoijfew ofewij weo
-END CERTIFICATE- stuff, it will add the CA certificate. But I
don't want to paste the certificate into the policy, I want to keep it
in a separate file, and use source =>
'puppet:///modules/pki/ca-certs/my-ca.crt' - like the file type does.
Try as I might, I haven't yet been able to duplicate the magic of that
parameter in my own type.

What do I really need in order to get from
'puppet:///modules/pki/ca-certs/my-ca.crt' to '-BEGIN
CERTIFICATE-...'? Do I need cached attributes? Do I need to fetch
metadata? What's about all these checksums?

-- 
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] [puppet-users] run without puppet master

[Jennings, Jared L CTR USAF AFMC 46 SK/CCI]

> i want to use red hat satellite server to deliver to the clients of
> puppet an rpm containing puppet content a a few different packages.
> 
> 1 for base lockdown, in this case STIG
> 1 for project customization
> 1 for applications
> 
> or something along those lines.

Aaron, you should check out CLIP, the Certifiable Linux Integration
Platform, from Tresys.  It uses
puppet without a puppetmaster, to lock down a RHEL system. I believe the
lockdown they do is a superset of what the STIG requires.

-- 
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.