Puppet: Difference between revisions

From Bibliotheca Anonoma
No edit summary
 
Line 19: Line 19:
* Red Hat - SELinux policies can be applied.
* Red Hat - SELinux policies can be applied.
* OpenBSD - Now your configs can be consistent across machines with OpenBSD as well, and you can set up configurations similarly to other OSes.
* OpenBSD - Now your configs can be consistent across machines with OpenBSD as well, and you can set up configurations similarly to other OSes.
== Examples ==
* [https://github.com/kmonticolo/OpenBSD-owncloud-puppet Set up OwnCloud on OpenBSD]


== Sources ==
== Sources ==

Latest revision as of 05:03, 7 October 2017

At the Bibliotheca Anonoma and in various other large infrastructure organizations, there are multitudes of servers with various uses and operating systems that all need to be maintained. Configurations are often almost as important as the code themselves, and take a lot of time to replicate in new instances.

Although at early stages it took less time to just set up a config manually, this is no longer effective for backup and scale reasons. Thus, Puppet is used to check configuration into Git, and ensure that systems stick to the configuration specified: if it deviates, it will be rolled back. This also helps tremendously with security, as it deploys the same changes and updates to all systems, and makes it difficult for unauthorized configuration changes to remain intact.

Puppet and Ansible are the first things a sysadmin will need once they get ahold of a huge number of systems.

Use Cases[edit]

  • Deploy SSH keys to all servers - This is a killer app in itself. When you add a new user, it will create such a user with the correct group, sudo permissions, and SSH keys across systems. When you remove it, it will delete it from all affected servers. Groups can even be made to regulate which users have access to which servers.
  • Spin up multiple instances of the same configuration - If you have a growing amount of mail servers, why waste time configuring them over and over and risk doing something wrong? Just automate it.
  • Make use of and maintain existing recipes - Often times you don't even need to create a recipe, just get a good known one and deploy it.
  • Prevent configurations from diverging - If the configuration changes for whatever reason, Puppet will bring it back. You must make configuration changes through authorized means (Git) for them to stick. Note that for the interval while the configuration change is active, there could still be effects, so it doesn't prevent the changes from happening: Mandatory Access Control and chroots do that.

Compatible Systems[edit]

Various compatible operating systems can be managed solely through Puppet, and has a configuration language that is mostly common to all of them. Here are the most important ones.

  • Debian/Ubuntu - Apparmor policies can be applied.
  • Red Hat - SELinux policies can be applied.
  • OpenBSD - Now your configs can be consistent across machines with OpenBSD as well, and you can set up configurations similarly to other OSes.

Examples[edit]

Sources[edit]

Learning Puppet

https://www.safaribooksonline.com/library/view/learning-puppet-security/9781784397753/