Pattern Requests

Create a list here of patterns you’d like to see, and those Puppeteers who have time will try to come by and create them.

Puppet

  • An ‘editfile’ type. I don’t know why editing files isn’t built into Puppet, but it’s an obvious short-coming, and everyone seems to be asking for it. There’s some scattered modules on the net which attempt to solve this, but they’re poorly documented, have dependencies, and are not built-in. An ‘editfile’ “Type” could be very elegant and probably be put into a single *.rb file under $RUBY_LIB_DIR/site_ruby/1.8/puppet/type/editfile.rb. The ‘editfile’ type _should_ extend the ‘file’ type, so configs can remain compact. An example usage would be:
      editfile { "cron.allow":
                    path                   => "/etc/cron.d/cron.allow",
                    owner                  => root,
                    group                  => sys,
                    mode                   => 600,
                    append_if_no_such_line => ["john_smith", "root", "sys"],
                    remove_line_if_matches => "evil_user",
                    comment_out_if_matches => ".*daemon",
            }
    

Would this not be the most elegant solution!?

First, an uncomment would be nice too, but there’s a bigger problem. How are lines commented? Does it use ;, //, # or something else? There could be an attribute that’s a string called comment_prefix. We could default it or guess the default, but I think that both of those could easily cause the user problems. I think forcing the user to explicitly choose it is best. Also, right now people do this with augeas and sed defines. It still seems useful when you don’t need as much flexibility as sed gives, and for some reason augeas isn’t practical. -Patrick

  • some kind of ssh authorized_keys management

See Recipes/Authorized_keys for a working solution. – windowsrefund

  • bind zone files
  • /etc/group membership management (different groups have different users, in no particular order) (This is already possible — you use the groups attribute on individual users. —luke)
  • automate the provisioning of Solaris Zones including the installation/configuration of puppet so that additional software can be automatically installed within that zone.
  • automate the installation of firefox extensions – unfortunately, most distributions don’t package them.

    • looks like xpi files are just zipped archives that can be extracted into either a user’s local directory or a system-wide directory. In Ubuntu 7.10, that appears to be /usr/lib/firefox/extensions. Candidate for facter?
      • I don’t think it is that easy. Firefox extensions have also to be registered into extensions.ini and extensions.rdf files with their appropriate manifests, so that Firefox knows where to look for what.
        • Debian has created some infrastructure for registering globally installed extensions. Rather, probably worth another package provider.
  • Management for quota.

    • Initially enabling quota for partitions
  • Management of local NIS users. People who need this seem largely to be rolling their own alternatives to the User type, but the Right Way is probably a custom provider for the User type.

Facter

  • firewall facts, e.g. network interfaces, ipaddresses, netmasks, default gateway, routes,
  • better freebsd facts. by default only the following are available on freebsd:

    domain facterversion fqdn hardwaremodel hostname ipaddress kernel kernelrelease operatingsystem operatingsystemrelease ps puppetversion rubysitedir rubyversion sshdsakey sshrsakey

Simple Complete Configuration

The Current Complete Configuration is very complete, but very complex. And as far as I can tell, very Debian dependent. It would be great if there was a somewhat more simple complete configuration example to see how things fit together for beginners like me.

Ideally there would be a very simple complete configuration that does more than the current tutorials show (ie do something useful like set up users or some service and not just show how to create a file). Then a slightly more complex example that shows how to set up mysql or apache.

By Complete Configuration, I would be interested in seeing best practices of how to organize the /etc/puppet tree with modules and classes but not so complex that I can’t get it to work without understanding everything in puppet (like the current [[Complete Configuration]] uses plugins which is very advanced and doesn’t seem to work out of the box on my Fedora environment)