1. login
Puppetmanaged.org
How to use it in
your
environment

2. id
uid=500(Yaakov M. Nemoy) gid=500(Human)
groups=10(wheel),501(Fedora Project
Ambassador),502(Puppetmanaged.org
Developer),503(RHCE),666(UMC Utrecht BOFH)

3. elinks
● Puppetmanaged.org is a collection of (mostly)
standalone common puppet modules for per
service deployment of your infrastructure
● It's designed around principles of good
configuration management

4. elinks
● Puppet ● Zarafa
● Mysql ● Openldap
● Apache ● Openvpn
● Bind ● Postfix
● Cobbler ● Monit
● Yum ● Munin
● Samba ● Nagios

5. elinks
● Authconfig ● Selinux
● Autofs ● Ssh
● Func ● Sudo
● Iptables ● Trac
● NFS ● Virt
● NTP ● Xen
● Rsync ● Pam

6. elinks
● Each module contains
● A bunch of file declarations
● Gets your service up and running
● RHEL default configurations
● Well defined classes with logical meaning
● Every class has a disabled subclass for cleanup
● A pony – development, testing, and production
branches

7. elinks
● pm.org is file based – just deliver the files and
get out of the way
● There are five options for file locations
● Environment + Host
● Environment
● System Wide + Host
● System Wide
● PM.org default

8. elinks
● puppet://$server/private/$environment/webserver/httpd.conf.
$hostname
● puppet://$server/private/$environment/webserver/httpd.conf
● puppet://$server/files/webserver/httpd.conf.$hostname
● puppet://$server/files/webserver/httpd.conf
● puppet://$server/webserver/httpd.conf

9. elinks
node 'node1.example.org' {
include webserver
webserver::virtualhost { "www.example.org":
enable => true
}
webserver::module::enable { "php":
enable => true
}
}

10. elinks
● Uses definitions to create pseudo resources
● Makes these modules very easy to adopt
● Easy to deploy in your current infrastructure,
one module at a time
● Easy to collaborate with upstream on

11. git clone
All modules in a git repository

12. make
● All you need is a git repo with a directory per
module
● Each branch is a seperate environment
● The master branch is the site-wide
configuration
● The pm.org puppet module handles the rest

13. make
● Some services require OS version specific files,
then you get twenty options
● OS + minor version
● OS + major version
● OS
● Default
● For example:
● pam

14. make install
● ah... um.....

15. make install
● Actually this slide should be
febootstrap/debootstrap

16. git svn
I can't talk about how to fix this in your
environment...

17. git svn
Or can i?
[Insert Shamless Hire Me Plug]

18. git svn
The UMC Utrecht DBG née Genomics Center is
a public institution, so we can talk about how we
solved the problem there

19. git foo
● There are good gateways for git and other
source control

20. git svn
● We started with an old experimental version of
pm.org
● conf/manifests – this is our site manifest
● distr/modules – one git repo per module
● distr/files – legacy files
● distr/files/private – file domain structure
● We only have one environment currently

21. git branch
● Each repo is cloned into the svn, then branched
to a umc specific branch
● Since we're using svn, i freely use git rebase,
so it's obvious which patches are not yet
upstream
● The diff between development and umc is
meant to be as short as possible

22. emacs
● Our umc branches normally just edit file
locations and comment out code defined in
legacy
● UMC specific classes are in
conf/manifests/classes/*pp

23. git rebase
● Every time i commit to git, i can also commit it
to our SVN
● Everytime someone else commits to svn, i can
rebase the git on top

24. git push
● Commiting is then very easy, just switch to the
right branch and push
● git format patch is great
● There is a devel mailing list open for patches
● Frequent patchers can probably get commit
access

25. publican
● Documentation is yet another git repo
● We store it at documentation/
● We branch and merge like usual

26. make install
● Move all code into modules or classes
● Migrate to pm.org's puppet module managing
site.pp
● Sort all files into distr/files/private
● Ensure every module we have is pm.org quality

27. make install
● Move each git repo to its own toplevel in svn
(except maybe distr/modules)
● git-svn handles mapping svn branches
● Fix the puppet module to do svn too

28. cat /dev/future
● Environments per working group
● Each group has write access to their own branch
● Porcelain – extensions on top of pm.org
standard
● More modules
● Better integration with external nodes

29. who
● ogd.nl ● rpmfusion.org
● kolabsys.com ● kanarip.com
● genomicscenter.nl
● op.umcutrecht.nl
● berica.nl
● fedoraunity.org
● puppetmanaged.org

30. wget puppetmanaged.org
● http://www.puppetmanaged.org/
● http://git.puppetmanaged.org/
● http://www.puppetmanaged.org/mailman/listinfo
● Commits
● Devel
● Users

31. questions?
● loupgaroublond@gmail.com
● loupgaroublond on practically every social
network, especially freenode
● #ergo@freenode.net
● Or just annoy kanarip
● the one with the ugly haircut