Hi, I''m absolutely new to centralized server management, sorry sorry in advance for any stupid remarks. Looking on the puppet documentation, I mainly find a lot of info about how to manage the config files, but nothing about centralized control. So I''m wandering if I''m looking a the right software package for my needs. I want to be able to do the following from a centralized spot (by example): - Tell all ''web servers'' to install package libapache2-mod-xslt, enable it and restart apache - Tell all ''web servers'' expect server ''adam'' and ''eva'' to stop service vsftpd - Tell all servers which are not ''dedicated servers'', to run `apt-get upgrade`, run a check script and run `apt-savepoint restore` if the script fails - Tell server ''tiny'' to reboot - Tell all ''web servers'' to change /etc/my.cnf and restart mysql I do not want: - That a config file is automatically overwritten when manually alter it on the local server (I do want to be able to force this though) Is puppet suitable for my needs? If not, is cfengine or some other tool? Thanks for any reply, Arnold
On 5/22/2007 7:58 AM, Arnold Daniels wrote:> Looking on the puppet documentation, I mainly find a lot of info about > how to manage the config files, but nothing about centralized control. > So I''m wandering if I''m looking a the right software package for my needs.I think it''ll handle what you''re asking. Since the puppetmaster parses through all the manifests before presenting anything to the puppet clients, that''s one aspect of centralization. Lots of untested code follows. Lots of it copied from the wiki, but there''s always a chance I botched something in the adaptation.> I want to be able to do the following from a centralized spot (by example): > - Tell all ''web servers'' to install package libapache2-mod-xslt, enable > it and restart apachehttp://www.reductivelabs.com/trac/puppet/wiki/Recipes/DebianApache2Recipe may be more complicated than what you''re looking for, but it meets the requirements you list. And the package name sounds like you''re a Debian user already, so I''d start there. Once the included apache2 Puppet module is available, I think the second block of code on that page would be split into something like: class web-host inherits generic-host { $wantedpackages = ["apache2", "libapache2-mod-xslt", "vsftpd" ] package { $wantedpackages: ensure => installed, } service { "vsftpd": ensure => stopped, enable => false, } } node www01 { include web-host $enabledsites = ["www.example.com", "blog.example.com"] $disabledsites = ["nudes.example.com"] apache2::site { $enabledsites: ensure => ''present''; $disabledsites: ensure => ''absent''; } # Tomcat-enabled site apache2::module { "jk": require => "libapache2-mod-jk" } apache2::site { "java.example.com": require => "libapache2-mod-jk" } }> - Tell all ''web servers'' expect server ''adam'' and ''eva'' to stop service > vsftpdnode adam, eva { include web-host $enabledsites = ["www2.example.com",] apache2::site { $enabledsites: ensure => ''present''; } service { "vsftpd": ensure => running, enable => true, } }> - Tell all servers which are not ''dedicated servers'', to run `apt-get > upgrade`, run a check script and run `apt-savepoint restore` if the > script failsRunning the script on a class of servers is no problem (see the last part of http://www.reductivelabs.com/trac/puppet/wiki/DebianRecipies). I think I''d put all the pass/fail logic and conditional commands into the script itself, though.> - Tell server ''tiny'' to reboothttp://www.reductivelabs.com/trac/puppet/wiki/DebianRecipies mentioned above could handle that (subscribe the reboot exec to a file named for a particular host), but I''d just as soon keep reboots as an ''ssh into the server'' process.> - Tell all ''web servers'' to change /etc/my.cnf and restart mysqlhttp://www.reductivelabs.com/trac/puppet/wiki/FrequentlyAskedQuestions#id36 has an example for restarting/reloading via command. I''d guess something like: file { "mycnf": path => "/etc/my.cnf", owner => root, group => root, mode => 600, source => "puppet://puppetmaster/files/apps/mysql/my.cnf", require => Package["mysql-server-5.0"] } service { "mysql": subscribe => file["mycnf"] } would be the more abstracted version. That example is adapted from http://www.reductivelabs.com/trac/puppet/wiki/TypeReference#id82> I do not want: > - That a config file is automatically overwritten when manually alter > it on the local server (I do want to be able to force this though)http://www.reductivelabs.com/trac/puppet/wiki/TypeReference#file (see the "replace" parameter) should handle the first part. Forcing it whenever you wanted without just editing the appropriate manifest to change "replace => false" to "replace => true" would require a bit more logic-handling than I can manage at this hour. -- Mike Renfro / R&D Engineer, Center for Manufacturing Research, 931 372-3601 / Tennessee Technological University -- renfro@tntech.edu
Hi, Thanks for you answer. Most points have been cleared up, but unfortunately not all. How can I tell all web servers, except server ''adam'' and ''eva'' to stop service vsftpd? Can I do something like $stopped_hosts =`cat $ctldir/vsftpd.stopped`; case $hostname in $stopped_hosts: ensure => stopped. And can I subscribe this to the ''$ctldir/vsftpd.stopped'' file, so puppet won''t stop vsftpd again when I ssh to server ''tiny'' an start it by hand. I didn''t find an example which acts like this. Can I do something with ''onlyif'' to prevent changed config files from being replaced. I would like to say: Replace $file with a new one and run run `md5sum $file > $sumdir/$file`, but only if the return code of `md5sum -r --status $sumdir/$file` > 0. I hope I''m not a bother (yet). Most examples are placing puppet as monitoring tool, which fully controls each part of the server. I absolutely don''t want this, instead I mainly want to execute commands on multiple servers and sync config files. Therefor I am a bit reluctant before starting to use puppet. Thanks for your help. Arnold Mike Renfro wrote:> On 5/22/2007 7:58 AM, Arnold Daniels wrote: > > >> Looking on the puppet documentation, I mainly find a lot of info about >> how to manage the config files, but nothing about centralized control. >> So I''m wandering if I''m looking a the right software package for my needs. >> > > I think it''ll handle what you''re asking. Since the puppetmaster parses > through all the manifests before presenting anything to the puppet > clients, that''s one aspect of centralization. > > Lots of untested code follows. Lots of it copied from the wiki, but > there''s always a chance I botched something in the adaptation. > > >> I want to be able to do the following from a centralized spot (by example): >> - Tell all ''web servers'' to install package libapache2-mod-xslt, enable >> it and restart apache >> > > http://www.reductivelabs.com/trac/puppet/wiki/Recipes/DebianApache2Recipe > may be more complicated than what you''re looking for, but it meets the > requirements you list. And the package name sounds like you''re a Debian > user already, so I''d start there. Once the included apache2 Puppet > module is available, I think the second block of code on that page would > be split into something like: > > class web-host inherits generic-host { > $wantedpackages = ["apache2", "libapache2-mod-xslt", "vsftpd" ] > package { $wantedpackages: ensure => installed, } > service { "vsftpd": > ensure => stopped, > enable => false, > } > } > > node www01 { > include web-host > $enabledsites = ["www.example.com", "blog.example.com"] > $disabledsites = ["nudes.example.com"] > apache2::site { > $enabledsites: ensure => ''present''; > $disabledsites: ensure => ''absent''; > } > > # Tomcat-enabled site > apache2::module { "jk": require => "libapache2-mod-jk" } > apache2::site { "java.example.com": require => "libapache2-mod-jk" } > } > > >> - Tell all ''web servers'' expect server ''adam'' and ''eva'' to stop service >> vsftpd >> > > node adam, eva { > include web-host > $enabledsites = ["www2.example.com",] > apache2::site { > $enabledsites: ensure => ''present''; > } > service { "vsftpd": > ensure => running, > enable => true, > } > } > > >> - Tell all servers which are not ''dedicated servers'', to run `apt-get >> upgrade`, run a check script and run `apt-savepoint restore` if the >> script fails >> > > Running the script on a class of servers is no problem (see the last > part of http://www.reductivelabs.com/trac/puppet/wiki/DebianRecipies). I > think I''d put all the pass/fail logic and conditional commands into the > script itself, though. > > >> - Tell server ''tiny'' to reboot >> > > http://www.reductivelabs.com/trac/puppet/wiki/DebianRecipies mentioned > above could handle that (subscribe the reboot exec to a file named for a > particular host), but I''d just as soon keep reboots as an ''ssh into the > server'' process. > > >> - Tell all ''web servers'' to change /etc/my.cnf and restart mysql >> > > http://www.reductivelabs.com/trac/puppet/wiki/FrequentlyAskedQuestions#id36 > has an example for restarting/reloading via command. I''d guess something > like: > > file { "mycnf": > path => "/etc/my.cnf", > owner => root, group => root, mode => 600, > source => "puppet://puppetmaster/files/apps/mysql/my.cnf", > require => Package["mysql-server-5.0"] > } > > service { "mysql": > subscribe => file["mycnf"] > } > > would be the more abstracted version. That example is adapted from > http://www.reductivelabs.com/trac/puppet/wiki/TypeReference#id82 > > >> I do not want: >> - That a config file is automatically overwritten when manually alter >> it on the local server (I do want to be able to force this though) >> > > http://www.reductivelabs.com/trac/puppet/wiki/TypeReference#file (see > the "replace" parameter) should handle the first part. Forcing it > whenever you wanted without just editing the appropriate manifest to > change "replace => false" to "replace => true" would require a bit more > logic-handling than I can manage at this hour. > >_______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 23 May 2007, Arnold Daniels wrote:> How can I tell all web servers, except server 'adam' and 'eva' to stop > service vsftpd? Can I do something like $stopped_hosts =`cat > $ctldir/vsftpd.stopped`; case $hostname in $stopped_hosts: ensure => > stopped.Puppet manifests are very declarative. Therefore you don't need loops. For this functionality, you would code your webserver class, that the service vsftpd has a "enabled => $vsftp_enabled". Then you can decide in one of the enclosing scopes (typically on node scope) whether you want the vsftpd enabled or not. Of course you can define a default within your webserver class. For an example look at the $apache2_port usage in my manifests at http://club.black.co.at:82/svn/manifests/trunk/manifests/classes/apache2.pp> And can I subscribe this to the '$ctldir/vsftpd.stopped' file, > so puppet won't stop vsftpd again when I ssh to server 'tiny' an start > it by hand. I didn't find an example which acts like this.Yes, you can, but I wouldn't recommend that. If you ever change the .stopped file for any reason, it would stop the vsftpd on 'tiny'. Basically resources managed by puppet should be handled exclusively by puppet. Note though, that puppet has a very wide definition of "resource". This can be a single line in a config file up to a whole computing cluster.> Can I do something with 'onlyif' to prevent changed config files from > being replaced. I would like to say: Replace $file with a new one and > run run `md5sum $file > $sumdir/$file`, but only if the return code of > `md5sum -r --status $sumdir/$file` > 0.Yes, you can, but again I wouldn't recommend that. For a overwhelming majority of cases where someone or something really has to modify a managed file it is possible to have a directory of snippets somewhere and just include it or "cat *" it all together to create the file on the fly.> I hope I'm not a bother (yet). Most examples are placing puppet as > monitoring tool, which fully controls each part of the server. I > absolutely don't want this, instead I mainly want to execute commands on > multiple servers and sync config files. Therefor I am a bit reluctant > before starting to use puppet.Puppet does what it is told. Some might argue that installing ruby everywhere to sync a few config files is overkill, but a) that is your call and b) you might find that there is more to puppet than meets the eye yfter your first glance. Regards, David - -- - - hallo... wie gehts heute? - - *hust* gut *rotz* *keuch* - - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGU/Km/Pp1N6Uzh0URApweAKCF+PrfTBPn09lEXEm5+LrN4KDXxQCeI54B w5bOG1DnI5uHt2IbZhQ59RE=gAaG -----END PGP SIGNATURE----- _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On 5/22/2007 5:45 PM, Arnold Daniels wrote:> How can I tell all web servers, except server ''adam'' and ''eva'' to > stop service vsftpd?I thought I answered that part, but maybe I didn''t call it out as such. Here it is again, but tell me if I''m dense and forgot to address something. The first block defines how a standard web server should behave (i.e., install apache2, the xslt module, and vsftpd, but make sure vsftpd is turned off): class web-host inherits generic-host { $wantedpackages = ["apache2", "libapache2-mod-xslt", "vsftpd" ] package { $wantedpackages: ensure => installed, } service { "vsftpd": ensure => stopped, enable => false, } } The second block defines how adam and eva differ from the standard web server (i.e., they both handle www2.example.com, and they should have vsftpd running): node adam, eva { include web-host $enabledsites = ["www2.example.com",] apache2::site { $enabledsites: ensure => ''present''; } service { "vsftpd": ensure => running, enable => true, } } That''s not the only way to do it, of course. You could take every reference to vsftpd out of the web-host class entirely and put it in adam''s and eva''s node-level definition, for example.> Most examples are placing puppet as monitoring tool, which fully > controls each part of the server. I absolutely don''t want this, > instead I mainly want to execute commands on multiple servers and > sync config files.I''d call nagios and similar packages monitoring tools, and call puppet, cfengine, etc. configuration management tools, but since what I call a configuration management tool often monitors local processes for restarts, I understand your usage of the term. But to the specific points there: Puppet only manages what you tell it to manage. If you just want it to distribute config files, it''ll do that via the file builtin type. The simplest sudoers recipe (http://www.reductivelabs.com/trac/puppet/wiki/SimplestPuppetInstallRecipe) really does nothing more than that; it doesn''t even check if sudo is installed before running. By making classes (and probably subclasses) of servers, you can make sure that a consistent core apache2 configuration ends up on all your web servers, and that each individual server gets its own configuration files that differ from the baseline. For executing commands on multiple servers (part of what the infrastructures.org guys call "ad-hoc change tools"), I now use dsh and pre-arranged ssh key exchange (part of my Debian preseeded installations). Previously, I used a bash wrapper around ssh and pre-arranged ssh key exchange (part of my Debian systemimager images). For syncing config files, I''m moving to puppet. Previously, I''d use ad-hoc rsyncs on servers, and some "inventive" (read: hackish) systemimager calls during bootup on dual-boot systems that were only available late night and on weekends. Puppet''s starting to give me the same less-stressed feeling I''ve gotten as I''ve migrated other tools and practices from "this was the first thing I found an example of, or thought of" to something that scales up much better. I''m writing up my migration from an ad-hoc bunch of systems to a more managed infrastructure at http://blogs.cae.tntech.edu/mwr/infrastructure-management/ -- it''s a work in progress, and a few things have changed since I wrote them up originally (particularly, I''ve abolished pkgsync and autostow in favor of puppet''s native package management and making .deb packages of the few things I''d normally stow). But as I refine and edit my setup, puppet will be an increasingly important part of everything past the initial minimal system installation. -- Mike Renfro / R&D Engineer, Center for Manufacturing Research, 931 372-3601 / Tennessee Technological University -- renfro@tntech.edu