You've got some problems that are caused because the packages didn't do things you need done, and other problems that are unrelated.
On the clients, puppetd will automatically look for the server at puppet, and should use the search domain. You really want to change DNS so that the puppetmaster has a DNS name of puppet. If it's working, "ping puppet" should ping the puppet master. At this point the server flag should be needed anymore. On the master, you need to create a user and group called puppet. This user needs read-only access to everything in/etc/puppet and read-write access to everything in /var/lib/puppet. (These are standard locations for Debian, but they might be in a different place in your version of puppet. Some of the files in these directories should not be world-readable, so it's easier to just make both of them be not world-readable. I'm assuming that you are using puppet version 0.25.4 or above. If you aren't, you should upgrade now. For startup scripts, it's probably easier to get the scripts from the official packages or the examples than it is to write your own. Hints: puppetd is normally be run as root so it can administrate your (puppet) clients. puppetmaster is normally run as puppet because it doesn't need to make changes to the server. Summery: 1) Make sure that running "ping puppet" on the client pings the server. 2) Add a user called puppet 3) Add a group called puppet 4) chown -R root:puppet /etc/puppet 5) chown -R puppet:puppet /var/lib/puppet 6) Set permissions on /etc/puppet to 640 and 750 7) Set permissions on /var/lib/puppet to 660 and 770 PS if you aren't using version control yet, start using it now. Even if you don't use comments, tags, and branches, it will still allow you to: 1) Revert stupid mistakes 2) Do a binary search through your revisions to find out what change caused a bug. On Jun 20, 2010, at 2:38 AM, Christopher wrote: > Hi everyone, > > I’ve been working on getting puppet set up for our systems for the > past week, and all has gone well in learning about writing manifests, > but now that I’m ready to set it into production, I realize that it’s > still unclear to me exactly how that’s supposed to go. > > For instance, during testing it has always been that I manually > started and stopped puppetd and puppetmasterd on their respective > machines with the following commands > > node1 $ puppetd --server servercharlie.bestgroup --waitforcert 60 -- > test > > and on the master > > master $ puppetmasterd --debug --no-daemonize > > But now that it’s time for production, trying to start the puppetd > with my init script, yielded the following error: > > chown: invalid user: ‘puppet:puppet’ > > which made me realize that I haven’t done anything in terms of > configuration on the nodes; I simply always ran the above command. > > So, I have a few specific questions about this, but I’d also > appreciate any insight into things that I might fail to ask, but could > be relevant to this topic. > > 1. The init scripts supplied by the Debian package (which I’m actually > not using, I’m just using the init scripts, logrotate.d and /etc/ > default files, etc) only act on puppetd. So then how is the > puppetmasterd supposed to be started on the master node? I know the > init scripts can be written. I have no fear of that, but I do get the > feeling that I’m missing something. > > 2. I never really saw where in the documentation puppet.conf file is > addressed. I’ve seen that it’s pretty well documented, but again, did > I miss something, especially considering that I have gone through the > online manifest-writing/language documentation for the past week, and > through all of the testing, I never once did something to configure > the client nodes. As mentioned above, I simply ran the puppetd > command. > > Okay, for specific questions that covers it for now, but like I said, > if there is any other general advice in terms these aspects of puppet, > that would be appreciated too. > > As a final note, I should probably point out that I have a Debian > system, but that I haven’t used their package because their libraries > tend to be quite old, and we’ve had a couple of instances where the > web-apps that we develop have actually been derailed because of old > ruby libraries that come as dependencies for these older packages. > > Anyway, thanks in advance. > > Regards, > Chris > > -- > 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. > -- 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.
