in 1st day of each month , change passwd of root.
# vi /etc/puppet/modules/user/manifests/init.pp
class user {
exec { "rootpw":
command => "/usr/sbin/usermod -p $rootpw root",
onlyif => "/usr/bin/test `/bin/date -d now +%d` =
''01''",
}
}
# vi /etc/puppet/manifests/templates.pp
import user
node basenode {
$rootpw = "Vale.com-init"
include user
}
--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
On Wed, 06 May 2009, 骡骡 wrote:> in 1st day of each month , change passwd of root.> exec { "rootpw": > command => "/usr/sbin/usermod -p $rootpw root", > onlyif => "/usr/bin/test `/bin/date -d now +%d` = ''01''",Assuming you run puppet every 30 minutes, won''t that happen ~48 times on the first of the month? Perhaps not too bad, but not too nice either. -- Robin <robin@kallisti.net.nz> JabberID: <eythian@jabber.kallisti.net.nz> Hostes alienigeni me abduxerunt. Qui annus est? PGP Key 0xA99CEB6D = 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D
I have a couple of concerns about this (at least in my environment). First, the root password would be clearly visible (not even crypted!) In the process listing during execution of the usermod. Second, similarly, the root password is stored in plaintext on the puppetmaster. Actually, would that variable be stored in each hosts yaml cache? Puppet has a user type that I think would be much better. I haven''t done this yet, but assuming you have installed ruby-shadow package, you just need to specify the crypted string. On 5/6/09, 骡骡 <ken.gogo@gmail.com> wrote:> > in 1st day of each month , change passwd of root. > > # vi /etc/puppet/modules/user/manifests/init.pp > > class user { > exec { "rootpw": > command => "/usr/sbin/usermod -p $rootpw root", > onlyif => "/usr/bin/test `/bin/date -d now +%d` = ''01''", > } > } > > # vi /etc/puppet/manifests/templates.pp > import user > node basenode { > $rootpw = "Vale.com-init" > include user > } > > > > > >-- Sent from my mobile device Chad M. Huneycutt --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
I have a couple of concerns about this (at least in my environment). First, the root password would be clearly visible (not even crypted!) In the process listing during execution of the usermod. Second, similarly, the root password is stored in plaintext on the puppetmaster. Actually, would that variable be stored in each hosts yaml cache? Puppet has a user type that I think would be much better. I haven''t done this yet, but assuming you have installed ruby-shadow package, you just need to specify the crypted string. On 5/6/09, 骡骡 <ken.gogo@gmail.com> wrote:> > in 1st day of each month , change passwd of root. > > # vi /etc/puppet/modules/user/manifests/init.pp > > class user { > exec { "rootpw": > command => "/usr/sbin/usermod -p $rootpw root", > onlyif => "/usr/bin/test `/bin/date -d now +%d` = ''01''", > } > } > > # vi /etc/puppet/manifests/templates.pp > import user > node basenode { > $rootpw = "Vale.com-init" > include user > } > > > > > >-- Sent from my mobile device Chad M. Huneycutt --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
2009/5/6 Chad Huneycutt <chad.huneycutt@gmail.com>> > I have a couple of concerns about this (at least in my environment). > First, the root password would be clearly visible (not even crypted!) > In the process listing during execution of the usermod. Second, > similarly, the root password is stored in plaintext on the > puppetmaster. Actually, would that variable be stored in each hosts > yaml cache? > > Puppet has a user type that I think would be much better. I haven''t > done this yet, but assuming you have installed ruby-shadow package, > you just need to specify the crypted string. > >It''s easy enough to just use sed in a exec to updatet the hash in shadow. I agree that having a clear text root passord floating around is a bad idea. That would lead it to be in the manifests, in subversion, in syslog and probably in the yaml cache like Chad said. Regards --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Hi> It''s easy enough to just use sed in a exec to updatet the hash in shadow. I > agree that having a clear text root passord floating around is a bad idea. > That would lead it to be in the manifests, in subversion, in syslog and > probably in the yaml cache like Chad said.it''s even easier to just use the password parameter of the user type and supply an already encrypted password. cheers pete --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Wed, May 6, 2009 at 2:51 AM, 骡骡 <ken.gogo@gmail.com> wrote:> > in 1st day of each month , change passwd of root. > > # vi /etc/puppet/modules/user/manifests/init.pp > > class user { > exec { "rootpw": > command => "/usr/sbin/usermod -p $rootpw root", > onlyif => "/usr/bin/test `/bin/date -d now +%d` = ''01''", > } > } > > # vi /etc/puppet/manifests/templates.pp > import user > node basenode { > $rootpw = "Vale.com-init" > include user > } > > >This just looks like a bad way to handle things. Given that you are going to manually set the password for puppet to use any way why not use something like this: <Warning this has not been tested> class update_pw{ user{"root": ensure => present, password => generate("/opt/new_passwd.sh"), } On the server /opt/new_passwd.sh would look like this: #!/bin/bash passwd=foobar openssl passwd -crypt $passwd This method should provide solutions to several problems with the initial approach. You know have the password out of the manifests and only have to secure one file. It will be handled by puppet as an encrypted password so it will go over the wire encrypted. It will now only change the password if the password parsed by the generate command changes. Evan --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Wed, May 06, 2009 at 04:02:54PM +0200, Bj?rn Dyre Dyresen wrote:> It''s easy enough to just use sed in a exec to updatet the hash in shadow. I > agree that having a clear text root passord floating around is a bad idea. > That would lead it to be in the manifests, in subversion, in syslog and > probably in the yaml cache like Chad said.Most Linux distributions include a utility called chpasswd, which can read username/password pairs (with the password encrypted) from stdin. It''s reasonably secure (you could, for example, push out a file with 400 permissions and then feed it to chpasswd locall6), respects login.defs and is safer than simply running sed against the shadow file. -- Bruce Bitterly it mathinketh me, that I spent mine wholle lyf in the lists against the ignorant. -- Roger Bacon, "Doctor Mirabilis" --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Wed, May 06, 2009 at 04:02:54PM +0200, Bjørn Dyre Dyresen wrote:> 2009/5/6 Chad Huneycutt <chad.huneycutt@gmail.com> > > > > > I have a couple of concerns about this (at least in my environment). > > First, the root password would be clearly visible (not even crypted!) > > In the process listing during execution of the usermod. Second, > > similarly, the root password is stored in plaintext on the > > puppetmaster. Actually, would that variable be stored in each hosts > > yaml cache? > > > > Puppet has a user type that I think would be much better. I haven''t > > done this yet, but assuming you have installed ruby-shadow package, > > you just need to specify the crypted string. > > > > > It''s easy enough to just use sed in a exec to updatet the hash in shadow.Sounds like a recipe for a race condition :-/ -- Marcin Owsiany <marcin@owsiany.pl> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 "Every program in development at MIT expands until it can read mail." -- Unknown --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Wed, May 06, 2009 at 09:24:41AM -0500, Evan Hisey wrote:> openssl passwd -crypt $passwd[...]> encrypted password so it will go over the wire encrypted. It will nowBut it will still show up unencrypted in processlist. -- Marcin Owsiany <marcin@owsiany.pl> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 "Every program in development at MIT expands until it can read mail." -- Unknown --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Wed, May 6, 2009 at 1:40 PM, Marcin Owsiany <marcin@owsiany.pl> wrote:> > On Wed, May 06, 2009 at 09:24:41AM -0500, Evan Hisey wrote: >> openssl passwd -crypt $passwd > [...] >> encrypted password so it will go over the wire encrypted. It will now > > But it will still show up unencrypted in processlist. > > -- > Marcin Owsiany <marcin@owsiany.pl> http://marcin.owsiany.pl/ > GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 > > "Every program in development at MIT expands until it can read mail." > -- Unknown >Only on the puppetmaster server, and this would happen no matter how you generate the password encryption. If somebody is that far inside your network already you have bigger problems. but if this is a concern just manually generate the encrypted password and change the command to "echo $passwd". evan --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Wed, May 06, 2009 at 02:02:42PM -0500, Evan Hisey wrote:> > > > But it will still show up unencrypted in processlist. > > > Only on the puppetmaster server, and this would happen no matter how > you generate the password encryption.Not true. There are several utilities that can read from stdin or a file to generate an encrypted passwrd, like mkpasswd. -- Bruce Remember you''re a Womble. --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Wed, May 6, 2009 at 2:25 PM, Bruce Richardson <itsbruce@workshy.org> wrote:> > On Wed, May 06, 2009 at 02:02:42PM -0500, Evan Hisey wrote: >> > >> > But it will still show up unencrypted in processlist. >> > >> Only on the puppetmaster server, and this would happen no matter how >> you generate the password encryption. > > Not true. There are several utilities that can read from stdin or a > file to generate an encrypted passwrd, like mkpasswd. > > -- > BruceI was thinking about scripted creation of passwords. If you used mkpasswd in place of oppenssl in the script it would still show up in the list. Openssl also takes sdtin as an option. You could probably put a lot of extra work in place and get a completely encrypted automate path of creation. But if you need that level of protection on a puppetmaster server then you would be best served by manual creation anyway. That may be best practice, on further though. Using generate and an external file to hold the encrypted password, saves the headache of version controlling old passwords. That way if you have to roll back for some reason you do not accidentally rollback the password. Evan --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
We sort of do this we set a global $password in our site.pp. That
$password is an MD5 string. My environment is currently all Linux.
Then, in our base module we have:
exec {
"set-root-password":
path => "/usr/sbin:/sbin"
command => "/bin/echo root:$password | /usr/sbin/chpasswd -e"
}
It''s obviously not very portable but eh.
Cheers,
Ryan
On Wed, 2009-05-06 at 09:24 -0500, Evan Hisey wrote:> On Wed, May 6, 2009 at 2:51 AM, 骡骡 <ken.gogo@gmail.com> wrote:
> >
> > in 1st day of each month , change passwd of root.
> >
> > # vi /etc/puppet/modules/user/manifests/init.pp
> >
> > class user {
> > exec { "rootpw":
> > command => "/usr/sbin/usermod -p $rootpw
root",
> > onlyif => "/usr/bin/test `/bin/date -d now +%d`
= ''01''",
> > }
> > }
> >
> > # vi /etc/puppet/manifests/templates.pp
> > import user
> > node basenode {
> > $rootpw = "Vale.com-init"
> > include user
> > }
> >
> >
> >
> This just looks like a bad way to handle things. Given that you are
> going to manually set the password for puppet to use any way why not
> use something like this: <Warning this has not been tested>
>
> class update_pw{
> user{"root":
> ensure => present,
> password => generate("/opt/new_passwd.sh"),
> }
>
> On the server /opt/new_passwd.sh would look like this:
> #!/bin/bash
> passwd=foobar
> openssl passwd -crypt $passwd
>
>
> This method should provide solutions to several problems with the
> initial approach. You know have the password out of the manifests and
> only have to secure one file. It will be handled by puppet as an
> encrypted password so it will go over the wire encrypted. It will now
> only change the password if the password parsed by the generate
> command changes.
>
> Evan
>
> >
--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
I am not sure everyone is on the same page: 1. you don''t want to have the root password (encrypted or not) showing up in the process listing of your clients. 2. even if you are generating the password on the master, it is going to show up in the yaml on the client, and if that is the case, it would seem to me that puppet''s "user" type would be a much more logical and explicit place to set it. If you want puppet to manage the password, I don''t think it gets any more secure than the user type. I guess if you had multiple admins writing manifests, and you were trying to prevent them from seeing the encrypted string, you could store it in a file that the puppetmaster could read (and they could not), distribute that file via the file type, and then use something like chpasswd to read the file, but that''s really only more obscure rather than secure (the manifest writer could just pull down the file and chown it to themselves...). - Chad On Wed, May 6, 2009 at 5:47 PM, Ryan Dooley <ryan.dooley@gmail.com> wrote:> > We sort of do this we set a global $password in our site.pp. That > $password is an MD5 string. My environment is currently all Linux. > > Then, in our base module we have: > > exec { > "set-root-password": > path => "/usr/sbin:/sbin" > command => "/bin/echo root:$password | /usr/sbin/chpasswd -e" > } > > It''s obviously not very portable but eh. > > Cheers, > Ryan > > On Wed, 2009-05-06 at 09:24 -0500, Evan Hisey wrote: >> On Wed, May 6, 2009 at 2:51 AM, 骡骡 <ken.gogo@gmail.com> wrote: >> > >> > in 1st day of each month , change passwd of root. >> > >> > # vi /etc/puppet/modules/user/manifests/init.pp >> > >> > class user { >> > exec { "rootpw": >> > command => "/usr/sbin/usermod -p $rootpw root", >> > onlyif => "/usr/bin/test `/bin/date -d now +%d` = ''01''", >> > } >> > } >> > >> > # vi /etc/puppet/manifests/templates.pp >> > import user >> > node basenode { >> > $rootpw = "Vale.com-init" >> > include user >> > } >> > >> > >> > >> This just looks like a bad way to handle things. Given that you are >> going to manually set the password for puppet to use any way why not >> use something like this: <Warning this has not been tested> >> >> class update_pw{ >> user{"root": >> ensure => present, >> password => generate("/opt/new_passwd.sh"), >> } >> >> On the server /opt/new_passwd.sh would look like this: >> #!/bin/bash >> passwd=foobar >> openssl passwd -crypt $passwd >> >> >> This method should provide solutions to several problems with the >> initial approach. You know have the password out of the manifests and >> only have to secure one file. It will be handled by puppet as an >> encrypted password so it will go over the wire encrypted. It will now >> only change the password if the password parsed by the generate >> command changes. >> >> Evan >> >> > > > > > >-- Chad M. Huneycutt --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Chad Huneycutt wrote:> I am not sure everyone is on the same page: > > 1. you don''t want to have the root password (encrypted or not) showing > up in the process listing of your clients.Well, this is a policy/philosophy issue. The question is "what is an acceptable risk for your environment?" Is it okay to have the root password managed by puppet? Should puppet manage any users password? If the answer to that question is "puppet should in no way manage a password" because that password is stored on disk and potentially displayed in the process list or in a yaml file, then really you''ve deleted this thread and moved on :) I absolutely agree there are other and better ways to manage the root password. Heck disable the root account in its entirety and create a proper process and policy to grant access if an SA or data center support individual who might need access. Or build your environment with enough redundancy so that if a machine begins to fail it is easier to just completely reinstall instead of diagnosing a dead machine and never login as root.> 2. even if you are generating the password on the master, it is going > to show up in the yaml on the client, and if that is the case, it > would seem to me that puppet''s "user" type would be a much more > logical and explicit place to set it.Doesn''t the users password still exist under the user type params in localconfig.yaml? Not really that more secure.> If you want puppet to manage the password, I don''t think it gets any > more secure than the user type. I guess if you had multiple admins > writing manifests, and you were trying to prevent them from seeing the > encrypted string, you could store it in a file that the puppetmaster > could read (and they could not), distribute that file via the file > type, and then use something like chpasswd to read the file, but > that''s really only more obscure rather than secure (the manifest > writer could just pull down the file and chown it to themselves...).Again, this is a matter of policy, process or philosophy and what is best for your environment. Cheers, Ryan --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On May 6, 3:51 pm, 骡骡 <ken.g...@gmail.com> wrote:> in 1st day of each month , change passwd of root. > > # vi /etc/puppet/modules/user/manifests/init.pp > > class user { > exec { "rootpw": > command => "/usr/sbin/usermod -p $rootpw root", > onlyif => "/usr/bin/test `/bin/date -d now +%d` = ''01''", > } > > } > > # vi /etc/puppet/manifests/templates.pp > import user > node basenode { > $rootpw = "Vale.com-init" > include user > > }change : Use MD5 encryption command => "/bin/echo ''root:$rootpw'' | /usr/sbin/chpasswd -m", --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Thank you ! I find my problem ! I will modify the module with user type. On May 6, 9:54 pm, Chad Huneycutt <chad.huneyc...@gmail.com> wrote:> I have a couple of concerns about this (at least in my environment). > First, the root password would be clearly visible (not even crypted!) > In the process listing during execution of the usermod. Second, > similarly, the root password is stored in plaintext on the > puppetmaster. Actually, would that variable be stored in each hosts > yaml cache? > > Puppet has a user type that I think would be much better. I haven''t > done this yet, but assuming you have installed ruby-shadow package, > you just need to specify the crypted string. > > On 5/6/09, 骡骡 <ken.g...@gmail.com> wrote: > > > > > > > in 1st day of each month , change passwd of root. > > > # vi /etc/puppet/modules/user/manifests/init.pp > > > class user { > > exec { "rootpw": > > command => "/usr/sbin/usermod -p $rootpw root", > > onlyif => "/usr/bin/test `/bin/date -d now +%d` = ''01''", > > } > > } > > > # vi /etc/puppet/manifests/templates.pp > > import user > > node basenode { > > $rootpw = "Vale.com-init" > > include user > > } > > -- > Sent from my mobile device > > Chad M. Huneycutt--~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
2009/5/6 Ryan Dooley <ryan.dooley@gmail.com>:> > Chad Huneycutt wrote: >> I am not sure everyone is on the same page: >> >> 1. you don''t want to have the root password (encrypted or not) showing >> up in the process listing of your clients. > > Well, this is a policy/philosophy issue. The question is "what is an > acceptable risk for your environment?" Is it okay to have the root > password managed by puppet? Should puppet manage any users password? > > If the answer to that question is "puppet should in no way manage a > password" because that password is stored on disk and potentially > displayed in the process list or in a yaml file, then really you''ve > deleted this thread and moved on :)I would argue that displaying the password in the process list is in a separate class from having it stored locally on the disk, since even unprivileged users could trivially capture it, which was really my only point. Just good practice to avoid that as there are lots of possible alternatives.> > I absolutely agree there are other and better ways to manage the root > password. Heck disable the root account in its entirety and create a > proper process and policy to grant access if an SA or data center > support individual who might need access. Or build your environment > with enough redundancy so that if a machine begins to fail it is easier > to just completely reinstall instead of diagnosing a dead machine and > never login as root.I really considered this. Why even have a root password? We can reboot into a rescue environment in the worst case. In the end, the most compelling argument for keeping the root password was to be able to do forensics on a live, compromised box without having to reboot (open, academic environment here, so it happens). Convenience (for problems during boot, etc.) came in a close second, though :)>> 2. even if you are generating the password on the master, it is going >> to show up in the yaml on the client, and if that is the case, it >> would seem to me that puppet''s "user" type would be a much more >> logical and explicit place to set it. > > Doesn''t the users password still exist under the user type params in > localconfig.yaml? Not really that more secure.Indeed. My point was not that it was more secure, just that it was more "logical and explicit". As long as the string is going to be in the yaml anyway, might as well do it the "puppet way". -- Chad M. Huneycutt --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---