[Puppet Users] Re: /etc/passwd, shadow, group, hosts
Thanks for the useful feedback. I know where to start now. Cheers, Henry -- 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.
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.
