[Puppet Users] Re: Puppet EC2: Attach an EBS volume at boot?
So, am I correct in thinking then that the following workflow *can't* be done with puppet? 1) The EC2 instance starts up, and the puppet client on the instance connects to the puppet master. 2) The puppet client receives the EC2 authentication credentials (env vars, certs, etc) from the master. 3) The master tells the client which EBS volums to attach at which mount points. 4) The client uses the authentication credentials to execute the EC2 commands to attach the volumes. 5) The client then removes the EC2 creds (unset env vars, rm certs, etc) for security. -- 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.
Re: [Puppet Users] Re: Puppet EC2: Attach an EBS volume at boot?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/23/2010 10:07 AM, Phillip B Oldham wrote: So, am I correct in thinking then that the following workflow *can't* be done with puppet? 1) The EC2 instance starts up, and the puppet client on the instance connects to the puppet master. 2) The puppet client receives the EC2 authentication credentials (env vars, certs, etc) from the master. 3) The master tells the client which EBS volums to attach at which mount points. 4) The client uses the authentication credentials to execute the EC2 commands to attach the volumes. 5) The client then removes the EC2 creds (unset env vars, rm certs, etc) for security. I didn't closely follow the thread, but I see no reason why not: 1) 1.1) you upload an image with the infos to connect your instances to your master 1.2) master gets an autosigned entry for every instance you fire up 2) 2.1) your modules contain a fact to decide whether your volume is setup correctly or not 2.2) if it is not setup correctly it includes a class to setup the volume 2.3) the master provides within that class the credentials (ie. via extlookup) 3) 3.1) the master provides that info within the previously outlined class 4) 4.1) the client applies the included class which does that. 5) 5.1) additionally you would include a class which cleans up everything _after_ the setup, this means that: 5.2) if the fact tells you to apply the settingup-class this cleanup class would require the settingup-class 5.3) for security reasons if the fact says that everything is setup you include only the cleanup class, so that you are sure that you won't have any leftovers around. it's quite straight forward. What are the tricks? * write a custom fact to signal whether the volume is correctly setup or not * write 2 classes, where one setup things and the other one does the cleanup * depend the cleanup stuff on the setup class _if_ the fact is set to setup sounds feasible, not? cheers pete PS: I assume there are also other ways, would be interesting to hear how other people solve that problem. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvRb5UACgkQbwltcAfKi3/lVQCdFOcORgnSmqr2B9Z1oR+bIdJf BDkAn0jYyceWLQuh3FLzbqWmdzARflfg =Vy/N -END PGP SIGNATURE- -- 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.
[Puppet Users] /etc/passwd, shadow, group, hosts
Hello All,
I'm new to puppet, and I'd like to know: Is there a formal best
practices guide for syncing { /etc/passwd, shadow, group, hosts}
across clients from the master? For instance; is it a better practice
to make a hard link to these files and share the link, as opposed to
just sharing the files directly via a target in fileserver.conf?
Inquiring minds want to know...
Cheers,
--
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.
Re: [Puppet Users] /etc/passwd, shadow, group, hosts
On 4/23/2010 12:52 PM, CraftyTech wrote:
Hello All,
I'm new to puppet, and I'd like to know: Is there a formal best
practices guide for syncing { /etc/passwd, shadow, group, hosts}
across clients from the master? For instance; is it a better practice
to make a hard link to these files and share the link, as opposed to
just sharing the files directly via a target in fileserver.conf?
Inquiring minds want to know...
It is recommended to use the built-in host, user and group resources to
manage hosts, users and groups. That way you have fine-grained control
over the users without having to manage the complete files.
If you REALLY want to distribute the complete files, you must copy them
to your file serving area (as defined in fileserver.conf). This is for
two reaasons. 1) you don't want to create every user you need in your
cluster on the puppetmaster and 2) the puppetmaster runs with lowered
privileges and must not access the shadow file.
Best Regards, David
--
dasz.at OG Tel: +43 (0)664 2602670 Web: http://dasz.at
Klosterneuburg UID: ATU64260999
FB-Nr.: FN 309285 g FB-Gericht: LG Korneuburg
--
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.
Re: [Puppet Users] /etc/passwd, shadow, group, hosts
CraftyTech hmmed...@gmail.com writes:
I'm new to puppet, and I'd like to know: Is there a formal best practices
guide for syncing { /etc/passwd, shadow, group, hosts} across clients from
the master?
You will probably find the most common best practice answer to this is
don't do it that way: the risks probably outweigh the cost, and using a
proper system like LDAP, NIS, or puppet user bits is probably less painful.
For instance; is it a better practice to make a hard link to these files and
share the link, as opposed to just sharing the files directly via a target
in fileserver.conf?
I would, simply because you reduce the list of exposed files that way.
Daniel
By would I mean would deploy LDAP, but if you insist, of course.
--
✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons
--
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.
[Puppet Users] Re: puppetd stops
Are we missing the top of that stack trace Kim? FYI If you use Ctrl-A + [ you can scrollback in screen. ken. On Apr 23, 8:54 am, Kim Gert Nielsen k...@netgroup.dk wrote: On Apr 21, 2010, at 2:51 PM, Ken wrote: More data is needed I think. Can you run puppetd --no-daemonize --debug in 'screen' or by piping the output somewhere? It may give you a better clue. All I get is this: /usr/lib/ruby/1.8/net/protocol.rb:135:in `sysread' /usr/lib/ruby/1.8/net/protocol.rb:135:in `rbuf_fill' /usr/lib/ruby/1.8/timeout.rb:62:in `timeout' /usr/lib/ruby/1.8/timeout.rb:93:in `timeout' /usr/lib/ruby/1.8/net/protocol.rb:134:in `rbuf_fill' /usr/lib/ruby/1.8/net/protocol.rb:116:in `readuntil' /usr/lib/ruby/1.8/net/protocol.rb:126:in `readline' /usr/lib/ruby/1.8/net/http.rb:2020:in `read_status_line' /usr/lib/ruby/1.8/net/http.rb:2009:in `read_new' /usr/lib/ruby/1.8/net/http.rb:1050:in `request' /usr/lib/ruby/1.8/net/http.rb:1037:in `request' /usr/lib/ruby/1.8/net/http.rb:543:in `start' /usr/lib/ruby/1.8/net/http.rb:1035:in `request' /usr/lib/ruby/1.8/net/http.rb:772:in `get' /usr/lib/ruby/1.8/puppet/indirector/rest.rb:69:in `find' /usr/lib/ruby/1.8/puppet/indirector/indirection.rb:198:in `find' /usr/lib/ruby/1.8/puppet/indirector.rb:51:in `find' /usr/lib/ruby/1.8/puppet/configurer.rb:94:in `retrieve_catalog' /usr/lib/ruby/1.8/puppet/util.rb:418:in `thinmark' /usr/lib/ruby/1.8/benchmark.rb:308:in `realtime' /usr/lib/ruby/1.8/puppet/util.rb:417:in `thinmark' /usr/lib/ruby/1.8/puppet/configurer.rb:93:in `retrieve_catalog' /usr/lib/ruby/1.8/puppet/configurer.rb:145:in `run' /usr/lib/ruby/1.8/puppet/agent.rb:53:in `run' /usr/lib/ruby/1.8/puppet/agent/locker.rb:21:in `lock' /usr/lib/ruby/1.8/puppet/agent.rb:53:in `run' /usr/lib/ruby/1.8/sync.rb:230:in `synchronize' /usr/lib/ruby/1.8/puppet/agent.rb:53:in `run' /usr/lib/ruby/1.8/puppet/agent.rb:130:in `with_client' /usr/lib/ruby/1.8/puppet/agent.rb:51:in `run' /usr/lib/ruby/1.8/puppet/application/puppetd.rb:103:in `onetime' /usr/lib/ruby/1.8/puppet/application.rb:226:in `send' /usr/lib/ruby/1.8/puppet/application.rb:226:in `run_command' /usr/lib/ruby/1.8/puppet/application.rb:217:in `run' /usr/lib/ruby/1.8/puppet/application.rb:306:in `exit_on_fail' /usr/lib/ruby/1.8/puppet/application.rb:217:in `run' /usr/sbin/puppetd:159 -- 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 athttp://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-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.
[Puppet Users] regsubst questions
I am attempting to set some variables in my manifest and I amd seeing
a result I don't quite understand. Here is a section of code from my
manifest:
$boot_time = generate('/usr/bin/env', '/bin/date', '+%H:%m')
notice(boot_time = $boot_time)
$boot_hour = regsubst($boot_time,'^([0-9]+)[:]([0-9]+)\n','\1')
notice(w newline - boot_hour = |$boot_hour|)
$boot_hour_1 = regsubst($boot_time,'^([0-9]+)[:]([0-9]+)','\1')
notice(w/o newline - boot_hour_1 = |$boot_hour_1|)
And the lines from the messages file:
(Scope(Class[main])) boot_time = 09:04
(Scope(Class[main])) w newline - boot_hour = |09|
(Scope(Class[main])) w/o newline - boot_hour_1 = |09 |
What I don't understand is that in the first setting of the variable
the trailing new line is specified in the regsubst pattern but is not
included in the resulting variable. In the second case, the new line
is not specified but is part of the resulting variable. In neither
case is the new line in the capture group. I would think that the
capture would include only the characters specified in the group, i.e.
one or more digits before a colon.
Can anyone explain this behavior.
Thanks,
Ed
--
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.
Re: [Puppet Users] regsubst questions
On 04/23/10 15:55, ed-rfmd wrote:
$boot_time = generate('/usr/bin/env', '/bin/date', '+%H:%m')
notice(boot_time = $boot_time)
$boot_hour = regsubst($boot_time,'^([0-9]+)[:]([0-9]+)\n','\1')
notice(w newline - boot_hour = |$boot_hour|)
$boot_hour_1 = regsubst($boot_time,'^([0-9]+)[:]([0-9]+)','\1')
notice(w/o newline - boot_hour_1 = |$boot_hour_1|)
And the lines from the messages file:
(Scope(Class[main])) boot_time = 09:04
(Scope(Class[main])) w newline - boot_hour = |09|
(Scope(Class[main])) w/o newline - boot_hour_1 = |09 |
What I don't understand is that in the first setting of the variable
the trailing new line is specified in the regsubst pattern but is not
included in the resulting variable. In the second case, the new line
is not specified but is part of the resulting variable. In neither
case is the new line in the capture group. I would think that the
capture would include only the characters specified in the group, i.e.
one or more digits before a colon.
The return value from regsubst() is not just the matching part of the
original string, but the *entire* original string with the substition
performed. For example, regsubst(bananas, (n), !, G) will
return ba!a!as, even though neither ba nor as matches (n).
*Since* the newline in your example isn't matched by the second
regexp, it will not be replaced, and thus be left alone and be part
of the return value.
/Bellman
--
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.
[Puppet Users] Re: /etc/passwd, shadow, group, hosts
On Apr 23, 7:24 am, Daniel Pittman dan...@rimspace.net wrote:
CraftyTech hmmed...@gmail.com writes:
I'm new to puppet, and I'd like to know: Is there a formal best practices
guide for syncing { /etc/passwd, shadow, group, hosts} across clients from
the master?
You will probably find the most common best practice answer to this is
don't do it that way: the risks probably outweigh the cost, and using a
proper system like LDAP, NIS, or puppet user bits is probably less painful.
For instance; is it a better practice to make a hard link to these files and
share the link, as opposed to just sharing the files directly via a target
in fileserver.conf?
I would, simply because you reduce the list of exposed files that way.
Daniel
By would I mean would deploy LDAP, but if you insist, of course.
--
✣ Daniel Pittman ✉ dan...@rimspace.net ☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons
Thanks for the quick reply. I should have been more specific in my
question: We do use ldap/DNS in our environment; I wanted to use
puppet for syncing the { /etc/passwd, shadow, group, hosts} for the
purposes of service accounts only, and not users in general. Also the
host file would be helpful in case there are hosts names that need to
be hard coded. I suppose I can create a class that creates the users
for the service accounts and propagate it that way... My thought
process was that if I have a hand-full of service accounts that need
to be present in all hosts, and certain hosts that need to be hard-
coded in the hosts file, that I would just share the previously
mentioned files via hard link on fileserver.conf. There appear to be
some security holes with this approach, so I have to re-think my
deployment strategy.. All suggestions are welcome :-))
--
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.
Re: [Puppet Users] Re: /etc/passwd, shadow, group, hosts
On Apr 23, 2010, at 7:15 AM, CraftyTech wrote:
On Apr 23, 7:24 am, Daniel Pittman dan...@rimspace.net wrote:
CraftyTech hmmed...@gmail.com writes:
I'm new to puppet, and I'd like to know: Is there a formal best practices
guide for syncing { /etc/passwd, shadow, group, hosts} across clients from
the master?
You will probably find the most common best practice answer to this is
don't do it that way: the risks probably outweigh the cost, and using a
proper system like LDAP, NIS, or puppet user bits is probably less painful.
For instance; is it a better practice to make a hard link to these files and
share the link, as opposed to just sharing the files directly via a target
in fileserver.conf?
I would, simply because you reduce the list of exposed files that way.
Daniel
By would I mean would deploy LDAP, but if you insist, of course.
--
✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155
707
♽ made with 100 percent post-consumer electrons
Thanks for the quick reply. I should have been more specific in my
question: We do use ldap/DNS in our environment; I wanted to use
puppet for syncing the { /etc/passwd, shadow, group, hosts} for the
purposes of service accounts only, and not users in general. Also the
host file would be helpful in case there are hosts names that need to
be hard coded. I suppose I can create a class that creates the users
for the service accounts and propagate it that way... My thought
process was that if I have a hand-full of service accounts that need
to be present in all hosts, and certain hosts that need to be hard-
coded in the hosts file, that I would just share the previously
mentioned files via hard link on fileserver.conf. There appear to be
some security holes with this approach, so I have to re-think my
deployment strategy.. All suggestions are welcome :-))
If you only have a few service accounts, it's probably easiest to just manage
them using the user resource.
--
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.
[Puppet Users] read-only 'ensure' for File resource?
rlpowell mentioned this earlier on irc and i find myself in a similar boat - I
need to express a condition that doesn't fit neatly into the class/parameter
model and I'm not quite sure how to do it. i'd like to add a cron entry IFF a
particular file (not managed through puppet) exists. Seems like the natural
thing would be to do:
cron { myjob:
command = /run/this/script.sh,
user = roleacct,
minute = [0,30],
require = File[/run/this/script.sh]
}
file { /run/this/script.sh:
ensure = XXX
}
where XXX is some value that would not cause any changes to the file but merely
mark the resource as passing or failing depending on the stat(). Exec'ing
/bin/test is possible but I kind of hate execs. I'm not super happy about
having a resource intentionally fail but I'm not sure what else to do about it.
Any thoughts from others on how to accomplish this?
-=Eric
--
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.
[Puppet Users] Logging Exec
Is there a way to stop puppetd from logging the command line arguments passed to an Exec() ? I need to pass sensitive options, ie passwords, on the command line, and don't want them to appear in log files. Doug. -- 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.
Re: [Puppet Users] Logging Exec
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/24/2010 01:02 AM, Douglas Garstang wrote: Is there a way to stop puppetd from logging the command line arguments passed to an Exec() ? I need to pass sensitive options, ie passwords, on the command line, and don't want them to appear in log files. imho not yet*. cheers pete * i think it's reasonable to file a bug for this. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvSKtgACgkQbwltcAfKi3+FygCeL0WbzqaQP1LMohk3DdVNuFcG 9YgAoLWRxiVMMzq6QmpNgys6f5MxfI9b =0VsX -END PGP SIGNATURE- -- 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.
Re: [Puppet Users] Logging Exec
On Fri, Apr 23, 2010 at 4:02 PM, Douglas Garstang doug.garst...@gmail.comwrote: Is there a way to stop puppetd from logging the command line arguments passed to an Exec() ? I need to pass sensitive options, ie passwords, on the command line, and don't want them to appear in log files. You know they'll still appear in the catalog ? Doug. -- 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.compuppet-users%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- nigel -- 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.
Re: [Puppet Users] Logging Exec
Hey Douglas,
Douglas Garstang wrote:
I need to pass sensitive options, ie passwords, on the command line,
and don't want them to appear in log files.
I work around this by storing passwords in scripts distributed by File{}
resources that are mode 400 to root and then Exec'ing the script. That
way, all the log/catalog sees is the script being run, but not the
actual password itself.
Though, if someone has permission to read /var/log/messages, then they
can probably also read root scripts, so YMMV.
cYa,
Avi
--
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.
Re: [Puppet Users] Re: /etc/passwd, shadow, group, hosts
CraftyTech hmmed...@gmail.com writes:
On Apr 23, 7:24 am, Daniel Pittman dan...@rimspace.net wrote:
CraftyTech hmmed...@gmail.com writes:
I'm new to puppet, and I'd like to know: Is there a formal best practices
guide for syncing { /etc/passwd, shadow, group, hosts} across clients from
the master?
You will probably find the most common best practice answer to this is
don't do it that way: the risks probably outweigh the cost, and using a
proper system like LDAP, NIS, or puppet user bits is probably less painful.
For instance; is it a better practice to make a hard link to these files
and
share the link, as opposed to just sharing the files directly via a target
in fileserver.conf?
I would, simply because you reduce the list of exposed files that way.
By would I mean would deploy LDAP, but if you insist, of course.
Thanks for the quick reply. I should have been more specific in my
question: We do use ldap/DNS in our environment; I wanted to use puppet for
syncing the { /etc/passwd, shadow, group, hosts} for the purposes of service
accounts only, and not users in general.
As Patrick suggests, use the built-in user and group type instead. It will
take care of this more effectively than trying to sync those static files, and
with much lower overall risk to you.
Also the host file would be helpful in case there are hosts names that need
to be hard coded.
For that, I would probably just distribute the file, because I like the
determinism that gives me.[1] There is also a built-in type for managing
those records, however, which you could just as well use.
Daniel
Footnotes:
[1] Specifically: this way I know that the content of the file is exactly
as I specify, and entirely predictable and controlled. Using the host
alias type means that, for example, some effort is made to preserve
hand-edits, which I usually don't want for this network layer.
--
✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons
--
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.
Re: [Puppet Users] Logging Exec
Avi Miller avi.mil...@gmail.com writes:
Douglas Garstang wrote:
I need to pass sensitive options, ie passwords, on the command line,
and don't want them to appear in log files.
I work around this by storing passwords in scripts distributed by File{}
resources that are mode 400 to root and then Exec'ing the script. That way,
all the log/catalog sees is the script being run, but not the actual
password itself.
That still exposes it to anyone on the machine at all[1], since they can read
it from the command line of the running process; the same is true of putting
it in the environment.
You really want the process to read it from a secure file, or to wrap it in
expect or something, if you don't trust local users.[2]
Though, if someone has permission to read /var/log/messages, then they can
probably also read root scripts, so YMMV.
I was going to say the same thing, then I thought about the number of places
that ship logs to something: a puppet dashboard, a central logging server, or
somewhere similar, from which you have less control over this data.
Daniel
Footnotes:
[1] ...by default; appropriate SELinux rules might be able to restrict
this, I guess, but I don't know for sure.
[2] ...which, of course, you shouldn't, because doing that turns a remote
any-user-account exploit into ownership of a second account, perhaps
root, and so on.
--
✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons
--
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.
