speling
This commit is contained in:
parent
c3c6171f96
commit
906e483c53
|
|
@ -5,9 +5,9 @@
|
|||
Introduction
|
||||
============
|
||||
|
||||
This document describes how to setup and run systems and service operations for a small to midsized
|
||||
This document describes how to setup and run systems and service operations for a small to mid-sized
|
||||
systems collection while maintaining scalability, security and auditability for changes.
|
||||
The process described below is based on opensource components and assumes a Linux-based hosting
|
||||
The process described below is based on open source components and assumes a Linux-based hosting
|
||||
infrastructure. These limitations could easily be removed though. This document describes the
|
||||
multiverse template for combining cosmos and puppet.
|
||||
|
||||
|
|
@ -18,7 +18,7 @@ Design Requirements
|
|||
The cosmos system has been used to operate security-critical infrastructure for a few years before
|
||||
it was combined with puppet into the multiverse template.
|
||||
|
||||
Several of the design requirements below are fulfilled by comos alone, while some (eg consistency)
|
||||
Several of the design requirements below are fulfilled by cosmos alone, while some (eg consistency)
|
||||
are easier to achieve using puppet than with cosmos alone.
|
||||
|
||||
Consistency
|
||||
|
|
@ -27,7 +27,7 @@ Consistency
|
|||
Changes should be applied atomically (locally on each host) across multiple system components on multiple
|
||||
physical and logical hosts (aka system state). The change mechanism should permit verification of state
|
||||
consistency and all modifications should be idempotents, i.e the same operation
|
||||
performend twice on the same system state should not in itself cause a problem.
|
||||
performed twice on the same system state should not in itself cause a problem.
|
||||
|
||||
Auditability
|
||||
------------
|
||||
|
|
@ -40,7 +40,7 @@ Authenticity
|
|||
------------
|
||||
|
||||
All changes must be authenticated by private keys in the personal possession of privileged
|
||||
system operators before applied to system state aswell as at any point in the future.
|
||||
system operators before applied to system state as well as at any point in the future.
|
||||
|
||||
Simplicity
|
||||
----------
|
||||
|
|
@ -62,7 +62,7 @@ Administrative Scope
|
|||
|
||||
The repository constitutes the administrative domain of a multiverse setup: each host is
|
||||
connected to (i.e runs cosmos off of) a single GIT repository and derives trust from signed
|
||||
tags on that repository. A host cannot belong to more than 1 administratve domain but each
|
||||
tags on that repository. A host cannot belong to more than 1 administrative domain but each
|
||||
administrative domains can host multiple DNS domains - all hosts in a single repository
|
||||
doesn't need to be in the same zone.
|
||||
|
||||
|
|
@ -122,9 +122,9 @@ Consistency
|
|||
-----------
|
||||
|
||||
As a master-less architecture, multiverse relies on _eventual consistency_: changes will eventually
|
||||
be applied to all hosts. In such a model it becomes very imporant that changes are idempotent, so
|
||||
be applied to all hosts. In such a model it becomes very important that changes are idempotent, so
|
||||
that applying a change multiple times (in an effort to get dependent changes through) won't cause
|
||||
an issue. Using native cosmos, such changes are achived using timestamp-files that control entry
|
||||
an issue. Using native cosmos, such changes are archived using timestamp-files that control entry
|
||||
into code-blocks:
|
||||
|
||||
```
|
||||
|
|
@ -136,7 +136,7 @@ fi
|
|||
```
|
||||
|
||||
This pattern is mostly replaced in multiverse by using puppet manifests and modules that
|
||||
are inherently indempotent but it can nevertheless be a useful addition to the toolchain.
|
||||
are inherently idempotent but it can nevertheless be a useful addition to the toolchain.
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
|
@ -184,7 +184,7 @@ multiverse. Fabric provides the 'fab' command which will be introduced later on.
|
|||
# apt-get install fabric
|
||||
```
|
||||
|
||||
These two tools (git & fabric) are only needed on mashines where system operators work.
|
||||
These two tools (git & fabric) are only needed on machines where system operators work.
|
||||
|
||||
Next clone git@github.com:SUNET/multiverse.git - this will form the basis of your cosmos+puppet
|
||||
repository:
|
||||
|
|
@ -226,7 +226,7 @@ Finally create a branch for the 'multiverse' upstream so you can merge changes t
|
|||
```
|
||||
|
||||
Note that you can maintain your repo on just about any git hosting platform, including
|
||||
github, gitorius or your own local setup as long as it supports read-only access to your
|
||||
github, gitorious or your own local setup as long as it supports read-only access to your
|
||||
repository. It is important that the remotes called 'origin' and 'ro' refer to your
|
||||
repository and not to anything else (like a private version of multiverse).
|
||||
|
||||
|
|
@ -266,7 +266,7 @@ ssh as root. This requires that root key trust be established in advance. The ad
|
|||
command creates and commits the necessary changes to the repository to add a host named
|
||||
$fqdn. Only fully qualified hostnames should ever be used in cosmos+puppet.
|
||||
|
||||
The boostrap process will create a cron-job on $fqdn that runs
|
||||
The bootstrap process will create a cron-job on $fqdn that runs
|
||||
|
||||
```
|
||||
# cosmos update && cosmos apply
|
||||
|
|
@ -285,7 +285,7 @@ Defining naming rules
|
|||
---------------------
|
||||
|
||||
A naming rule is a mapping from a name to a set of puppet classes. These are defined in
|
||||
the file 'global/overlay/etc/puppet/cosmos-rules.yaml' (linked to the toplevel directory
|
||||
the file 'global/overlay/etc/puppet/cosmos-rules.yaml' (linked to the top level directory
|
||||
in multiverse). This is a YAML format file whose keys are regular expressions and whose
|
||||
values are lists of puppet class definitions. Here is an example that assigns all hosts
|
||||
with names on the form ns\<number\>.example.com to the 'nameserver' class.
|
||||
|
|
@ -295,7 +295,7 @@ with names on the form ns\<number\>.example.com to the 'nameserver' class.
|
|||
nameserver:
|
||||
```
|
||||
|
||||
Note that the value is a hash with an empty value ('namserver:') and not just a string
|
||||
Note that the value is a hash with an empty value ('nameserver:') and not just a string
|
||||
value.
|
||||
|
||||
Since regular expressions can also match on whole strings so the following is also
|
||||
|
|
@ -323,11 +323,11 @@ Given the above example the following command would reload all nameservers:
|
|||
Creating a change-request
|
||||
-------------------------
|
||||
|
||||
After performing whatever changes you want to the reqpository, commit the changes as usual
|
||||
After performing whatever changes you want to the repository, commit the changes as usual
|
||||
and then sign an appropriately formatted tag. This last operation is wrapped in the 'bump-tag' command:
|
||||
|
||||
```
|
||||
# git commit -m "some changes" global/overlay/somethig or/other/files
|
||||
# git commit -m "some changes" global/overlay/something or/other/files
|
||||
# ./bump-tag
|
||||
```
|
||||
|
||||
|
|
@ -388,7 +388,7 @@ Add the ascii-armoured key in a file in `global/overlay/etc/cosmos/keys` with a
|
|||
Removing an operator
|
||||
--------------------
|
||||
|
||||
Identitfy the public key file in `global/overlay/etc/cosmos/keys`
|
||||
Identify the public key file in `global/overlay/etc/cosmos/keys`
|
||||
|
||||
```
|
||||
# git rm global/overlay/etc/cosmos/keys/X.pub
|
||||
|
|
@ -465,4 +465,3 @@ On all hosts:
|
|||
```
|
||||
# fab -- reboot # danger Will Robinsson!
|
||||
```
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue