This book is a standard for something.
Having a common starting point for operating systems ensures that when systems administrators, users and developers move from one host to another they will know what they can expect. Keeping a base install simple and only adding the bits needed for the task of that host also helps keep costs and risk low. It makes updates easier as well as testing those updates. It also helps ensure that some resource eating bits that might normally be installed by an operating system but aren't often used, don't get installed at all helping improve efficiency.
In all sized environments simplification helps reduce costs. Simple Operating Systems are easier to troubleshoot when there are issues, they are easier to update since there is less to update, they take less time to provision and they help keep training simple. The CSI standard focuses on this simplicity with regards to how the systems administrators, engineers and architects view the environment. At an operational level the nuances of day to day administration and use, as well as emergency and outage situations have been kept in mind when designing this standard.
Since this is standard includes a base install which can be further built upon it is suitable for all environments. Those in small environments will appreciate the quick turnaround time for rebuilding a couple of machines. Those in larger environments will appreciate being able to predict how long provisioning of newly installed hardware will take.
The ideas used in building what should and should not be on a base operating system focus around a few basic ideas:
Does an application need to be run on this server or, for example like whois, does it produce the same result everywhere?
Is the application just installed by default or is it actually needed?
Any application installed must not conflict with an already existing CSI standard.
This book is a standard for the base infrastructure of your networked environment.
A stable, secure and consistent infrastructure prevents you from having to put down fires all over the place, hunting down problems until you've seen every little corner of the office.
This book is a standard for something.
This book is a standard for configuration management amongst diverse systems, to avoid ambiguity, describing the best practice to configuration management.
Between any larger number of systems, managing the configuration of these systems requires a management utility that offers enough features so that you can classify systems, distinct different services and distribute arbitrary files or directory trees amongst them. This ensures all your systems comply to a standard you distribute from one or more locations, including source control management for your administrators to keep track of changes.
Management utilities include CFEngine, and puppet. In this book, we use puppet for it's security, reliability, the flexibility of it's manifests and modularity.
See also: CFEngine vs. Puppet
The definition of terms used in this document can be found at:
The Community Services Infrastructure Standard this document is a part of.
A short review of the terms defined in aforementioned documents and how they apply to puppet.
An operating system instance managed by Puppet. Note that this can be the same OS instance as the puppet master. Either an OS on it's own hardware or virtualized. In puppet manifests, this is often refered to as a 'node'.
Facts are details or properties returned by Facter. Facter has many builtin details about the node it runs on, such as the hostname. Creating your own custom facts is relatively easy.
A puppet is a managed node or client. Note that this can be the same node the puppetmaster is running on.
The puppetmaster is the puppet server, from which nodes get their configuration and required actions.
This refers to the puppet server, or puppetmaster. While this usually applies to nodes offering services to other nodes, this document does only use the term *server* to indicate the puppetmaster.
The following packages need to be available on the systems you plan to manage with puppet:
| Package Name | Description |
|---|---|
| puppet | The puppet client |
The following packages need to be available on the system(s) you use to manage the rest (puppetmaster):
| Package Name | Description |
|---|---|
| puppet-server | The puppet master (server) |
| rubygem-mongrel | A small fast HTTP library and server |
This chapter describes the standard of configuration management applied with puppet.
The "default" node applies to all nodes that have do not have a node configuration (yet). The default node should always have a minimal configuration, and a notice to indicate this node is using the default configuration.
Assigning variables from facts is helpful; overriding the system's Operating System version allows you to instantly upgrade the OS via puppet.
See Also: Section 3.2, “Facts and Variables”, Section 4.3, “Creating Custom Facts”, Section 4.4, “Using Facts and Variables”
Make sure you manage puppet via puppet.
Nothing in a puppet managed environment is as critical as the puppetmaster. You should manage the puppetmaster with puppet to ensure consistency and to not allow sudden (unwanted) changes to it's configuration. Managing the puppetmaster also enables you to pull the manifests, files and modules from a source control management system regularly. In addition, in environments where the puppetmaster is load-balanced or in a geographically distributed environment, managing the puppetmasters ensures consistency between all of these.
Modules make up a large part of your manifests, allowing you to include modules and submodules for each node and/or group
Use a Source Control Management System for your manifests, files and modules to enable revision control and branching (stable, production, development and testing).
Configuration Management is mandatory for administrators seeking version control for the configuration they push, secure sharing of configuration files and arbitrary scripts, and/or consistency amongst disparate systems.
Facts are a great way of identifying properties of a system, and can be used in puppet manifests as conditions or parameters. Facts however cannot be overriden from within the manifest -they are protected, static variables. By assigning the value of a Fact to a custom variable however that protection is gone and you can use the new variable to override, for example, the operating system version, or whether the system is virtualized.
See also: Section 4.4, “Using Facts and Variables”
Set up the following directories to hold your manifests:
/etc/puppet/
Main configuration directory. Holds client configuration (puppet.conf), as well as master configuration (puppet.conf, fileserver.conf, tagmail.conf), and directories and files relevant for the puppet master (manifests/).
/etc/puppet/manifests/
Holds the manifests the puppet master uses to determine the configuration to push to the client. At the very least, this directory should have a file named site.pp. This directory also contains nodes/, classes/, utils/, and groups/.
/etc/puppet/manifests/nodes/
Holds the declaration of nodes (clients) being managed, and what configuration should be included for these clients. An example node declaration looks like this:
node 'dummy.example.org' {
include some-class
}
which causes client dummy.example.org to include configuration held by the class some-class.
/etc/puppet/manifests/classes/
Holds the classes that are not modular. Using non-modular classes is a bad idea, and you should avoid it whenever possible. Although perfectly valid, it obfuscates the configuration applied to the clients and does not scale very well. In addition, it doesn't allow for a naming standard for the files such as the service or configuration item it is managing.
/etc/puppet/manifests/utils/
Particularly useful if the managed systems are somewhat homogeneous (they are all Linux?), so you can set defaults. Imagine you have to set the PATH for each Exec. Instead, defining in utils/exec.pp:
Exec {
path => [
"/bin/",
"/usr/bin/",
"/usr/local/bin/",
"/sbin/",
"/usr/sbin/",
"/usr/local/sbin/",
]
}
and importing it once (in site.pp) will save you from having to define the PATH over and over again.
/etc/puppet/manifests/groups/
Manifests for groups of systems. This defines the defaults for groups, such as a group "webserver", which should have the httpd package installed, and the service httpd running.
/var/lib/puppet/clientbucket/
The main server backup location (if configured). If you harvest replaced configuration files from your clients, this directory must also be backed up regularly.
/var/lib/puppet/facts/
Custom facts to distribute amongst your clients.
/var/lib/puppet/files/
Holds files distributed by the puppet master to the clients. Like with the classes in /etc/puppet/manifests/classes/, putting files in here is generally a bad idea and should be avoided.
/var/lib/puppet/modules/
Holds modules.
/var/lib/puppet/ssl/
Holds the puppet master and client certificate chain. VERY important to backup regularly.
| Directory | Description of Contents |
|---|---|
/etc/puppet/
|
Holds the puppetmaster configuration files |
/etc/puppet/manifests/
|
The initial manifest to start out with should at least define the following:
Set the server to use throughout the manifest:
$server = "puppet.puppetmanaged.org"
In site.pp, you should import classes/modules.pp:
import "classes/modules.pp"
What is in classes/modules.pp exactly is up to you. Note that importing too many modules doesn't hurt, but you should import the least amount of modules and thus only those that you use.
In site.pp, you should import utils/*.pp:
import "utils/*.pp"
What files are in utils/ and what they define is up to you. See also: ???
In site.pp, you should import classes/modules.pp:
import "classes/modules.pp"
What is in classes/modules.pp exactly is up to you. Note that importing too many modules doesn't hurt, but you should import the least amount of modules and thus only those that you use.
The "default" node applies to all nodes that have do not have a node configuration (yet). The default node should always have a minimal configuration, and a notice to indicate this node is using the default configuration. A default node declaration could look like this:
node default {
notice("Node $fqdn is using the default configuration!")
}
By including the client class from the puppet module, you can start managing puppet via puppet:
include puppet::client
By including the master class from the puppet module, you can start managing the puppetmaster via puppet:
include puppet::master
Given the above, a default site.pp could look similar to:
$server = "master.puppetmanaged.org"
import "classes/modules.pp"
# Always include the puppet::client class
include puppet::client
# The default node
node default {
notice("Node $fqdn uses a default configuration")
}
# The puppetmaster should include the puppet::master class
node 'master.puppetmanaged.org' {
include puppet::master
}
In order for your environment to be able to scale properly, you will need to go with the mongrel server type. The default webrick server type does not scale beyond ~30 managed clients, because it is a single threaded webserver whereas the mongrel server type is multithreaded. Having a multi-threaded server type is a MUST.
Enable the mongrel server type by adding to /etc/sysconfig/puppetmaster's PUPPETMASTER_EXTRA_OPTS setting:
--servertype=mongrel --masterport=8141
Make sure the PUPPETMASTER_MANIFEST in /etc/sysconfig/puppetmaster is set to /etc/puppet/manifests/site.pp
SSH is a method for secure communications without access to a local console. OpenSSH is feature rich supporting many different authentication mechanisms. It can also allow users to completely bypass firewall configurations via tunneling.
This document is designed specifically with remote management of hosts in mind. While it may scale to allow shell accounts to end users, it has not been tested in that configuration. Each host should have an OpenSSH install, each deployed identically with the configurations noted below.
| Service | Software package |
|---|---|
| OpenSSH Server | openssh-server |
| OpenSSH Client | openssh-clients |
| denyhosts | denyhosts |
| Complete | Requirement | Action | Config | Comment |
|---|---|---|---|---|
| Must | Define |
Protocol 2
|
||
| Must | Define |
PermitRootLogon no
|
||
| Must | Define |
TCPKeepAlive yes
|
||
| Must | Not Define |
Protocol 1
|
||
| Should | Define |
X11Forwarding no
|
||
| Should | Define |
AllowTcpForwarding no
|
||
| Should | Define |
GatewayPorts no
|
||
| Should | Define |
PermitTunnel no
|
Remote Access is an important tool which allows administrators to monitor and control remote machines without physical access to the machine. While not everything can be done with a remote shell, often times 99% of what needs to be done during the livespan of a host, can be done via a remote shell. OpenSSH is an industry standard and its implementation can be quite secure.
OpenSSH is ideal for remote administration in any sized organization. It requires trivial resources in terms of disk space, CPU, memory, etc for any modern machine. It is released under a Open Source license and by most standards is very stable.
OpenSSH is a standard part of most distibutions. By providing a command line shell into the host it provides the same level of access to a normally booted host that physically being at the machine would. The server portion runs on each host and requires a firewall be opened to allow remote users to contact. The default for most modern distributions is to install and run this ssh server portion on each host. The ssh client, run by the user then connects and does authentication. All of this happens via an encrypted link. This allows for secure communcation between two remote sources over untrusted networks.
Proper standards regarding config file format and indentation help ensure more readable configuration files. This document describes such things as what a tab should be and how to properly comment.
This policy should be followed by all admins, developers or anyone who alters configuration files.
This standard should not be used when using it causes syntax errors or other failurs in the application. There are some configuration files and applicatons for which this standard is not compatable. Not using this standard on those files does not mean that you are not compliant with the standard. This exception has been granted in that case
Only one of the following packages is required
| Application | Software package |
|---|---|
| Vi IMproved | vim |
| Complete | Topic | Requirement | Comment | |
|---|---|---|---|---|
| Must | Tab | A tab's are equal to 4 spaces | ||
| Must | width | 80 | Unless there is a single word/directive with no spaces that is larger then 80 characters, for example a full path. | |
| Should | License | Include any licnse or copyright information at the top of the config file in a comment. |
Maintaining a common standard for configuration files is an important concept that often gets overlooked in large environments. Following the CSI standards for configuration files will help ensure that config files are more readable, reusable, parsable by scripts and sane.
Properly packaging of software is part science and part art. In the Red Hat family, everything is distributed via RPM's. While RPM's are distributed via yum. As an ISV there is no reason not to distribute a package and its updates in the exact same way that all other packages are distributed.
Fedora is an operating system and The Fedora Project is an open source organization. The Fedora Project has a special interest group (SIG) where ISV's go to ask questions and discuss various issues they have, etc. This SIG is at the very core of openness that The Fedora Project holds to.
Ensure that at least one representative of the software in question has joined this mailing listhttps://www.redhat.com/archives/fedora-isv-sig-list/
Send an email to that list with the following information:
An Independant Software Vendors or ISV's create software that can be used with operating systems like Red Hat Enterprise Linux or Fedora. Different ISV's have different business models and this standard focuses on the right way to go about getting your software included in Fedora, Red Hat Enterprise Linux or Extra Packages for Enterprise Linux.
Companies who have a software product line they would like to have be available and updated to users by simple use of yum should follow these standards. Those who are just looking to get a smaller package of theirs or just a package that they use and do wish to maintain alone should look at the packaging guidelines as the ISV standard includes packaging but goes a step further.
In an industry that moves quickly getting a software product to users isn't always a simple matter of distribution. Including a download link on some random website is only one option. Having users be able to type a simple command like yum install thisApplication is entirely different.
By following these standards, ISV's will not only be able to distribute their product via the channels that admins are now familiar with but they will also be able to issue updates via the same way they currently update everything else on their system. Additionally, by joining various mailing lists ISV's can get in touch with other ISV's to discuss technical and other issues that arise.