[Puppet Users] Tips for a new puppet setup
Ok folks, I've read BestPractices and probably most of the wiki docs but I
am still banging my head about how to layout a new puppet deployment.
Everything is fresh, fresh repo, fresh puppet install.
We will use SVN for version control.
Here are some of my challenges. I go back and forth on how I feel best to
solve them so I would appreciate any input.
My company manages about 200 Linux boxes mostly RHEL4 and RHEL5. We have
four datacenters which each requires a different resolvers, ldap settings,
proxy server etc etc etc. Additionally we have customers who sometimes have
settings that differ from that of the rest of the datacenter and further
still, host 'classes' or services, webserver, database server etc.
1. What are some good ways to organize all of this both from a file
perspective?
Does it make sense to define defaults in classes and then override them in
datacenter classes?
i.e. resolver class has resolver::list [ '1.2.3.4' ] then a datacenter
class overrides it with Resolver::list [ '4.4.4.4' ] or maybe just append to
it.
2. What is a class and what is a module?
classes:
datacenter
datacenter::a
customer
customer::one
service
service::s_www
service::s_sldap
modules:
resolver
authconfig (ldap, nss_ldap)
logrotate
(basically matching the name of the package it configures)
Then a node gets a datacenter, customer and service class which rely on the
modules to make config changes.
I would like to have the option of doing things additively and not just
strictly replace values. For example in datacenter a the resolvers might
be 1.1.1.1 and 2.2.2.2 but customer one wants to add their primary dc as the
first resolver making their resolvers 3.3.3.3, 1.1.1.1, 2.2.2.2. But if we
update the datacenter a resolvers to 2.2.2.2, 4.4.4.4 customer one's server
in datacenter a ends up with resolvers 3.3.3.3, 2.2.2.2, 4.4.4.4.
3. How to organize subversion repo, I want to have testing and development.
puppet/trunk - development {modules,manifests,plugins,puppet.conf,etc.}
puppet/tags/production/{modules,manifests,plugins,puppet.conf,etc.}
puppet/tags/testing/{modules,manifests,plugins,etc.} (no need for
puppet.conf and a few other things)
So pretend you are starting anew, what would you do differently?
Regards,
-Alan
--~--~-~--~~~---~--~~
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] Puppet Reporting - ignoring reports config option?
Hi all, I've gotten a fair way into implementing a pilot puppet implementation. I have a reasonable amount of the configuration done, and have been working on reporting. At present, on the puppetmaster I have: report = true -- puppetmaster is also a puppet... reportserver = puppet reportdir = /var/opt/csw/puppet/reports -- Files definately being uploaded from 2 clients. reportfrom = i...@somewhere.com reports = tagmail,store,log tagmap = /etc/opt/csw/puppet/tagmail.conf (I've chopped out the seemingly less relevant options... They are all pretty much standard as per puppetd --genconfig, though I have commented out the CA options to leave them as defaults) in tagmail.conf I only have one line: all: sysad...@somewhere.com Running puppetmasterd --debug it appears to only run the 'store' report, which of course shoves the yaml file into /var/opt/csw/puppet/ reports as its supposed to do... Logs from puppetmasterd: May 6 15:40:19 pmaster puppetmasterd[1802]: [ID 702911 daemon.info] Expiring the node cache of test1 May 6 15:40:19 pmaster puppetmasterd[1802]: [ID 702911 daemon.info] Not using expired node for test1 from cache; expired at Wed May 06 15:39:19 +1000 2009 May 6 15:40:19 pmaster puppetmasterd[1802]: [ID 702911 daemon.info] Caching node for test1 May 6 15:40:20 pmaster puppetmasterd[1802]: [ID 702911 daemon.notice] Compiled catalog for test1 in 1.02 seconds May 6 15:40:54 pmaster puppetmasterd[1802]: [ID 702911 daemon.info] Processing reports store for test1 I am guessing that Processing reports store for server indicates which report (store) is being run, and that since I have only one log entry that it is the only report being attempted. I've reviewed as much of the reporting code as I can follow, but am drawing a blank at exactly where it reads the config option - the only Ruby I have done is relating to understanding Puppet... This is all running off 0.24.7 on Solaris 10 using the latest Blastwave packages... Any thoughts on what I'm missing would be appreciated. --~--~-~--~~~---~--~~ 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] Re: Puppet Reporting - ignoring reports config option?
Gah... Figured out the problem literally 5 minutes after I posted... Problem was that I had generated a puppet.conf using --genconfig and forgotten to remove genconfig = true... Logs reported that the config file had been re-read, but obviously not true if this setting has been left enabled - after all --genconfig prints a config file and exits... Obviously had I actually restarted puppetmasted I would have seen this... kicking self for a wasted day Greg --~--~-~--~~~---~--~~ 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] Re: Tips for a new puppet setup
Alan,
One thing I found handy was to build up 2 custom facts to add into
facter: defaultroute and site.
defaultroute is used to determine which site a host is in...
Personally I found the class heirarchy
too limited since you can't inherit from multiple places... So you
would need classes like site1-webserver,
site2-webserver, site1-database, site2-database and so on... Too
annoying.
Adding in these custom facts allows you to add in config files based
on which site the node lives.
For example:
file { /etc/resolv.conf:
source = puppet:///network/resolv.conf-$site
owner = root, group = root, mode = 644
}
Heres the custom facts I added.
(Note: the default route is Solaris specific as I don't need to manage
any Linux boxes at my site)
(Also note: My knowledge of Ruby is *really* basic at this stage,
apologies if this code is bad)
defaultroute.rb:
Facter.add(defaultroute) do
setcode do
defroutefh = File.open(/etc/defaultrouter)
defroutefh.readline.chomp
end
end
site.rb:
Facter.add(site) do
setcode do
case Facter.value('defaultroute')
when 10.0.0.1
site1
when 10.0.0.2, 10.0.0.3
site2
else
unknown
end
end
end
Now, this makes the answer to q1 a bit easier... I have mine
modularised into groups based on what the config is about. Networking
config is in one module, sudo management in another and so on. That
way its (hopefully) more sane when you come to make changes. I guess
the granularity that you put this on is up to you.
2. I will leave this one to someone more experienced with Puppet than
me, but I use modules to group similar classes
together - kind of like a library. Its probably a very simplistic view
of things, but so far it has worked well for me...
3. My svn repository is set up as follows:
- baseline/
Main trunk - This is where most of the work gets done... Keep
your live Puppet Master config tree here...
- tags/
Contains discrete release views.
- branches/
Haven't used this yet, but I'm planning on using this for
larger changes, development work and so forth...
I'm sure I have missed out something that I'm going to need later on,
but figure its a reasonable starting point...
--~--~-~--~~~---~--~~
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] set password of root
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: set password of root
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 ro...@kallisti.net.nz JabberID: eyth...@jabber.kallisti.net.nz
Hostes alienigeni me abduxerunt. Qui annus est?
PGP Key 0xA99CEB6D = 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D
signature.asc
Description: This is a digitally signed message part.
[Puppet Users] Re: set password of root
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: set password of root
2009/5/6 Chad Huneycutt chad.huneyc...@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: set password of root
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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: set password of root
On Wed, May 6, 2009 at 2:51 AM, 骡骡 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
}
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Pitching puppet - how does it work question
I'm trying to pitch puppet to my group. I have a test server 2 clients, things are going pretty well. The question relates to user password management as outlined in the recipies. My question, if only the hash value changes, will puppet apply that change? Who notices the change, the client or the server? I need to explain how it works. Thanks, just trying to be the salesman --~--~-~--~~~---~--~~ 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] Re: Pitching puppet - how does it work question
Hi, Am 06.05.2009 um 16:40 schrieb LenR: I'm trying to pitch puppet to my group. I have a test server 2 clients, things are going pretty well. The question relates to user password management as outlined in the recipies. My question, if only the hash value changes, will puppet apply that change? Who notices the change, the client or the server? I need to explain how it works. The way I understand it, the server looks at the file when compiling the recipe for the client and calculates a hash value for the file. This hash value is the integrated in the recipe, which in turn is sent to the client. The client then looks at the files described in the recipe and checks if the hash values of the local files match the hash values sent by the server for those files. If they match, nothing happens, as the file is in the right state, if not, the client downloads the file from the server. That's a least the principle. You also have some layers of caching and checking timestamps to see if it's even necessary to recompute a hash, or if you can take the hash value from a previous run, and so on. BR, Felix --~--~-~--~~~---~--~~ 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] FreeBSD pw user provider password management
Hi all,
Can someone tell me what is the reason for the pw user provider not
supporting the password parameter? As far as I know one can pipe an
encrypted password string to pw and it will set it as expected.
As a workaround I'm using an exec to achieve this functionality:
define users::freebsd_user($gid, $uid, $comment, $password, $shell) {
user { $name:
ensure = present,
comment = $comment,
gid= $gid,
uid= $uid,
password = $password,
shell = $shell,
notify = Exec[passwd_$name];
}
exec { passwd_$name:
path = /bin:/sbin:/usr/bin:/usr/sbin,
command = echo '$password' | /usr/sbin/pw usermod $name -H 0,
refreshonly = true;
}
}
However it would be cleaner if the built-in type supported this. Is
there a technical reason why this wasn't done?
Cheers,
Andrew.
--
. __/_/_ w: http://darq.com/
. __/_/_ t: 020 7100 1447
. / / e: supp...@darq.com
--~--~-~--~~~---~--~~
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] Re: FreeBSD pw user provider password management
Is it this issue?
http://projects.reductivelabs.com/issues/1511
You need to have ruby-shadow library and restart puppetd.
-Peter
On May 6, 2009, at 11:07 AM, Andrew Wasilczuk wrote:
Hi all,
Can someone tell me what is the reason for the pw user provider not
supporting the password parameter? As far as I know one can pipe an
encrypted password string to pw and it will set it as expected.
As a workaround I'm using an exec to achieve this functionality:
define users::freebsd_user($gid, $uid, $comment, $password, $shell) {
user { $name:
ensure = present,
comment = $comment,
gid= $gid,
uid= $uid,
password = $password,
shell = $shell,
notify = Exec[passwd_$name];
}
exec { passwd_$name:
path = /bin:/sbin:/usr/bin:/usr/sbin,
command = echo '$password' | /usr/sbin/pw usermod
$name -H 0,
refreshonly = true;
}
}
However it would be cleaner if the built-in type supported this. Is
there a technical reason why this wasn't done?
Cheers,
Andrew.
--
. __/_/_ w: http://darq.com/
. __/_/_ t: 020 7100 1447
. / / e: supp...@darq.com
--
Peter Burkholder
AARP | Web Strategy Operations | 601 E Street, NW | Washington, DC
20049
pburkhol...@aarp.org | aim: peterbtech | ph: 202-434-3530 | cell:
202-344-7129 |
--~--~-~--~~~---~--~~
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] Re: set password of root
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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Automatically update host
I do this using storedconfigs and virtual resources for hosts. For example:
@@host { $hostname.private:
ip = $ipaddress_eth1,
ensure = present,
alias = $hostname
}
Host | |
What this does is when the machine first connects, it creates a virtual
resource for itself, then when another machine connects, it will realize it and
get added to the machine's /etc/hosts
Hope this helps.
Cheers,
Eric
On Thu, Apr 30, 2009 at 10:59:39AM -0700, haribole wrote:
Hello Group
I am trying to setup puppet so that when a new client connects to the
server, the puppetd from the client can update a resource on the
puppetmasted server with its IP address, fqdn and alias, so that this
info can be distributed to all the known clients of the network.
From what I understand the puppet master server would have these
details from facter, and wonder if the above can be scripted.
Thanks for any inputs.
Hari
--
Eric Gerlach, Network Administrator
Federation of Students
University of Waterloo
p: (519) 888-4567 x36329
e: egerl...@feds.uwaterloo.ca
--~--~-~--~~~---~--~~
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] Re: Pitching Puppet - How does it work question
Hi Len, Let me take a shot at this. I'm sure I'll be corrected if I'm wrong. It roughly works like this: 1) Client connects to server and asks what should my configuration be? 2) Server responds with the desired configuration 3) Client then checks that configuration against what exists 4) Client fixes anything that doesn't match what the server gave it tl;dr: If only the hash value changes, will puppet apply that change? Yes. Who notices the change, the client or the server? Mu. (It's kinda both) Cheers, Eric On Tue, May 05, 2009 at 08:48:34PM -0500, Len Rugen wrote: I'm trying to pitch puppet to my group. I have a test server 2 clients, things are going pretty well. The question relates to user password management as outlined in the recipies. My question, if only the hash value changes, will puppet apply that change? Who notices the change, the client or the server? Thanks, just trying to be the salesman -- Eric Gerlach, Network Administrator Federation of Students University of Waterloo p: (519) 888-4567 x36329 e: egerl...@feds.uwaterloo.ca --~--~-~--~~~---~--~~ 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] Re: set password of root
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 mar...@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: set password of root
On Wed, May 06, 2009 at 04:02:54PM +0200, Bjørn Dyre Dyresen wrote: 2009/5/6 Chad Huneycutt chad.huneyc...@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 mar...@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: set password of root
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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: set password of root
On Wed, May 6, 2009 at 2:25 PM, Bruce Richardson itsbr...@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. -- Bruce I 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: set password of root
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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Starting a (SMF) service on Solaris with Puppet
I believe you do not need
start = true
you may need to set the name though:
name = 'svc:/network/postfix:default'
unless 'svcadm enable postfix' works as is (I do not have postfix on
my servers, but I can do 'svcadm enable smtp'
The enable = true means to execute the 'svcadm enable $name'
- JimP
On May 6, 2009, at 9:36 PM, Don Jackson wrote:
Hello,
I am a puppet newbie, I got a puppetmaster running on my network, and
puppetd is installed and run on new servers.
I am trying to get puppet to start postfix on a Solaris server.
The postfix package was previously installed (via jumpstart).
When the system first comes up, if I type
svcadm enable svc:/network/postfix:default
then postfix starts and runs fine. But I want puppet to do that for
me automatically.
Here is what I put in my manifest file:
file { password:
name = /etc/passwd,
owner = root,
group = $operatingsystem ? {
OpenBSD = wheel,
Solaris = sys,
},
mode = 644,
}
node 'solaristest.clark-communications.com' {
service { postfix:
enable = true,
start = true,
ensure = running,
}
}
But that doesn't seem to work, here is what puppetd says:
/opt/csw/bin/puppetd --no-daemonize --debug
debug: Creating default schedules
debug: Failed to load library 'shadow' for feature 'libshadow'
debug: Failed to load library 'ldap' for feature 'ldap'
debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[ssl]/
File[/
etc/opt/csw/puppet/ssl/public_keys]: Autorequiring File[/etc/opt/csw/
puppet/ssl]
debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[main]/
File[/var/opt/csw/puppet/lib]: Autorequiring File[/var/opt/csw/puppet]
debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[main]/
File[/etc/opt/csw/puppet/ssl]: Autorequiring File[/etc/opt/csw/puppet]
debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[ssl]/
File[/
etc/opt/csw/puppet/ssl/private_keys/solaristest.clark-
communications.com.pem]: Autorequiring File[/etc/opt/csw/puppet/ssl/
private_keys]
debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[ssl]/
File[/
etc/opt/csw/puppet/ssl/certs]: Autorequiring File[/etc/opt/csw/puppet/
ssl]
debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[puppetd]/
File[/var/opt/csw/puppet/state/classes.txt]: Autorequiring File[/var/
opt/csw/puppet/state]
debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[ssl]/
File[/
etc/opt/csw/puppet/ssl/private]: Autorequiring File[/etc/opt/csw/
puppet/ssl]
debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[ssl]/
File[/
etc/opt/csw/puppet/ssl/private_keys]: Autorequiring File[/etc/opt/csw/
puppet/ssl]
debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[puppetd]/
File[/var/opt/csw/puppet/state/state.yaml]: Autorequiring File[/var/
opt/csw/puppet/state]
debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[main]/
File[/var/opt/csw/puppet/state]: Autorequiring File[/var/opt/csw/
puppet]
debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[main]/
File[/var/opt/csw/puppet/log]: Autorequiring File[/var/opt/csw/puppet]
debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[ssl]/
File[/
etc/opt/csw/puppet/ssl/certs/solaristest.clark-
communications.com.pem]: Autorequiring File[/etc/opt/csw/puppet/ssl/
certs]
debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[main]/
File[/var/opt/csw/puppet/run]: Autorequiring File[/var/opt/csw/puppet]
debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[ssl]/
File[/
etc/opt/csw/puppet/ssl/certs/ca.pem]: Autorequiring File[/etc/opt/csw/
puppet/ssl/certs]
debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[puppetd]/
File[/etc/opt/csw/puppet/puppet.conf]: Autorequiring File[/etc/opt/
csw/
puppet]
debug: Finishing transaction 69170270 with 0 changes
notice: Starting Puppet client version 0.24.8
debug: Loaded state in 0.00 seconds
debug: Retrieved facts in 3.09 seconds
debug: Retrieving catalog
debug: Calling puppetmaster.getconfig
debug: Retrieved catalog in 0.35 seconds
debug: Puppet::Type::Service::ProviderGentoo: file /sbin/rc-update
does not exist
debug: Puppet::Type::Service::ProviderDebian: file /usr/sbin/update-
rc.d does not exist
debug: Puppet::Type::Service::ProviderRunit: file /usr/bin/sv does not
exist
debug: Puppet::Type::Service::ProviderDaemontools: file /usr/bin/svc
does not exist
debug: Puppet::Type::Service::ProviderRedhat: file /sbin/service does
not exist
debug: Puppet::Type::Service::ProviderLaunchd: file /bin/launchctl
does not exist
debug: Creating default schedules
debug: Finishing transaction 74131070 with 0 changes
info: Caching catalog at /var//opt/csw/puppet/state/localconfig.yaml
notice: Starting catalog run
debug: Loaded state in 0.00 seconds
debug: Puppet::Type::Service::ProviderSmf: Executing '/usr/bin/svcs -l
postfix'
debug: Puppet::Type::Service::ProviderSmf: Executing '/usr/bin/svcs -l
[Puppet Users] Re: set password of root
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: Has anyone tried Puppet under Ruby 1.9?
josb has provided a 1.9 compatibility patch, but we stupidly have not merged it in yet. It'll be in 0.25, though. Where can we find this patch? Or alternatively is 0.25 coming out fairly soon? --~--~-~--~~~---~--~~ 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] Re: Pitching Puppet - How does it work question
When you say the hash value changed, do you mean on the puppetmaster? In the most used Puppet setup, the master compiles the config for each client, and the client synchronizes the resources. 'Noticed' is a little ambiguous, and I might be misinterpreting, but the client is what is going to compare the current state of the system with the compiled config. Does that answer the question? On Tue, May 5, 2009 at 7:48 PM, Len Rugen lenru...@gmail.com wrote: I'm trying to pitch puppet to my group. I have a test server 2 clients, things are going pretty well. The question relates to user password management as outlined in the recipies. My question, if only the hash value changes, will puppet apply that change? Who notices the change, the client or the server? Thanks, just trying to be the salesman --~--~-~--~~~---~--~~ 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] Re: set password of root
2009/5/6 Ryan Dooley ryan.doo...@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Starting a (SMF) service on Solaris with Puppet
On May 6, 2009, at 6:47 PM, Jim Pirzyk wrote:
I believe you do not need
start = true
you may need to set the name though:
name = 'svc:/network/postfix:default'
unless 'svcadm enable postfix' works as is (I do not have postfix on
my servers, but I can do 'svcadm enable smtp'
The enable = true means to execute the 'svcadm enable $name'
I implemented both your suggestions, and it worked!
Thank you!
Don
Hello,
I am a puppet newbie, I got a puppetmaster running on my network, and
puppetd is installed and run on new servers.
I am trying to get puppet to start postfix on a Solaris server.
The postfix package was previously installed (via jumpstart).
When the system first comes up, if I type
svcadm enable svc:/network/postfix:default
then postfix starts and runs fine. But I want puppet to do that for
me automatically.
Here is what I put in my manifest file:
file { password:
name = /etc/passwd,
owner = root,
group = $operatingsystem ? {
OpenBSD = wheel,
Solaris = sys,
},
mode = 644,
}
node 'solaristest.clark-communications.com' {
service { postfix:
enable = true,
start = true,
ensure = running,
}
}
But that doesn't seem to work, here is what puppetd says:
/opt/csw/bin/puppetd --no-daemonize --debug
debug: Creating default schedules
debug: Failed to load library 'shadow' for feature 'libshadow'
debug: Failed to load library 'ldap' for feature 'ldap'
debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[ssl]/
File[/
etc/opt/csw/puppet/ssl/public_keys]: Autorequiring File[/etc/opt/csw/
puppet/ssl]
debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[main]/
File[/var/opt/csw/puppet/lib]: Autorequiring File[/var/opt/csw/
puppet]
debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[main]/
File[/etc/opt/csw/puppet/ssl]: Autorequiring File[/etc/opt/csw/
puppet]
debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[ssl]/
File[/
etc/opt/csw/puppet/ssl/private_keys/solaristest.clark-
communications.com.pem]: Autorequiring File[/etc/opt/csw/puppet/ssl/
private_keys]
debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[ssl]/
File[/
etc/opt/csw/puppet/ssl/certs]: Autorequiring File[/etc/opt/csw/
puppet/
ssl]
debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[puppetd]/
File[/var/opt/csw/puppet/state/classes.txt]: Autorequiring File[/var/
opt/csw/puppet/state]
debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[ssl]/
File[/
etc/opt/csw/puppet/ssl/private]: Autorequiring File[/etc/opt/csw/
puppet/ssl]
debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[ssl]/
File[/
etc/opt/csw/puppet/ssl/private_keys]: Autorequiring File[/etc/opt/
csw/
puppet/ssl]
debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[puppetd]/
File[/var/opt/csw/puppet/state/state.yaml]: Autorequiring File[/var/
opt/csw/puppet/state]
debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[main]/
File[/var/opt/csw/puppet/state]: Autorequiring File[/var/opt/csw/
puppet]
debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[main]/
File[/var/opt/csw/puppet/log]: Autorequiring File[/var/opt/csw/
puppet]
debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[ssl]/
File[/
etc/opt/csw/puppet/ssl/certs/solaristest.clark-
communications.com.pem]: Autorequiring File[/etc/opt/csw/puppet/ssl/
certs]
debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[main]/
File[/var/opt/csw/puppet/run]: Autorequiring File[/var/opt/csw/
puppet]
debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[ssl]/
File[/
etc/opt/csw/puppet/ssl/certs/ca.pem]: Autorequiring File[/etc/opt/
csw/
puppet/ssl/certs]
debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[puppetd]/
File[/etc/opt/csw/puppet/puppet.conf]: Autorequiring File[/etc/opt/
csw/
puppet]
debug: Finishing transaction 69170270 with 0 changes
notice: Starting Puppet client version 0.24.8
debug: Loaded state in 0.00 seconds
debug: Retrieved facts in 3.09 seconds
debug: Retrieving catalog
debug: Calling puppetmaster.getconfig
debug: Retrieved catalog in 0.35 seconds
debug: Puppet::Type::Service::ProviderGentoo: file /sbin/rc-update
does not exist
debug: Puppet::Type::Service::ProviderDebian: file /usr/sbin/update-
rc.d does not exist
debug: Puppet::Type::Service::ProviderRunit: file /usr/bin/sv does
not
exist
debug: Puppet::Type::Service::ProviderDaemontools: file /usr/bin/svc
does not exist
debug: Puppet::Type::Service::ProviderRedhat: file /sbin/service does
not exist
debug: Puppet::Type::Service::ProviderLaunchd: file /bin/launchctl
does not exist
debug: Creating default schedules
debug: Finishing transaction 74131070 with 0 changes
info: Caching catalog at /var//opt/csw/puppet/state/localconfig.yaml
notice: Starting catalog run
debug: Loaded state in 0.00 seconds
