If this works, congratulations, you have made your first change across
the entire Puppet infrastructure! You might want to look at the rest
of the documentation to learn more about how to do different tasks and
how things are setup. A key Howto we recommend is the `Progressive
how things are setup. A key "Howto" we recommend is the `Progressive
deployment` section below, which will teach you how to make a change
like the above while making sure you don't break anything even if it
affects a lot of machines.
...
...
@@ -83,7 +83,7 @@ affects a lot of machines.
## Modifying an existing configuration
For new deployments, this is *NOT* the prefered method. For example,
For new deployments, this is *NOT* the preferred method. For example,
if you are deploying new software that is not already in use in our
infrastructure, do *not* follow this guide and instead follow the
`Adding a new module` guide below.
...
...
@@ -126,7 +126,7 @@ Next, the module was added to the Puppetfile (in
This fetched a lot of code from the Puppet forge: the stdlib, archive
and system modules were all installed or updated. All those modules
were audited manually, by reading each file and looking for obvious
security flaws or backdoors. Then the code was committed into git:
security flaws or backdoors. Then the code was committed into git:
git add 3rdparty
git commit -m'install prometheus module after audit'
...
...
@@ -178,7 +178,7 @@ code in `3rdparty/modules/prometheus`, and committed into git:
git commit -m'implement all the missing stuff' 3rdparty
git push
And the above puppet commandline was ran again, continuing that loop
And the above puppet command-line was ran again, continuing that loop
until things were good.
If you need to deploy the code to multiple hosts, see the `Progressive
...
...
@@ -188,7 +188,7 @@ you should do so), see the section right below.
## Contributing changes back upstream
For simple changes, the above workflow works well, but eventually it
is preferable to actually fork the upstream repo and operate on our
is preferable to actually fork the upstream repository and operate on our
fork until the changes are merged upstream.
First, the modified module is moved out of the way:
...
...
@@ -221,7 +221,7 @@ request was sent.
Since you now have a clone of the upstream repository, you can push
and pull normally with upstream. When you make a change, however, you
need to commit (and push) the change *both* in the sub-repo and the
need to commit (and push) the change *both* in the sub-repository and the
main repository:
cd 3rdparty/modules/prometheus
...
...
@@ -297,7 +297,7 @@ value:
ssh -t pauli.torproject.org "sudo -u postgres psql puppetdb -P pager=off -F',' -A -t -c \"SELECT c.certname, value_string FROM factsets fs INNER JOIN facts f ON f.factset_id = fs.id INNER JOIN fact_values fv ON fv.id = f.fact_value_id INNER JOIN fact_paths fp ON fp.id = f.fact_path_id INNER JOIN certnames c ON c.certname = fs.certname WHERE fp.name = 'virtual' AND c.deactivated IS NULL\"" | tee hosts.csv
The resulting file is a Comma-Seperated Value (CSV) file which can be
The resulting file is a Comma-Separated Value (CSV) file which can be
used for other purposes later.
Possible values of the `virtual` field can be obtain with a similar
...
...
@@ -307,7 +307,7 @@ query:
The currently known values are: `kvm`, `physical`, and `xenu`.
As a bonus, this query will show the number of hosts running each os release:
As a bonus, this query will show the number of hosts running each release:
SELECT COUNT(c.certname), value_string FROM factsets fs INNER JOIN facts f ON f.factset_id = fs.id INNER JOIN fact_values fv ON fv.id = f.fact_value_id INNER JOIN fact_paths fp ON fp.id = f.fact_path_id INNER JOIN certnames c ON c.certname = fs.certname WHERE fp.name = 'lsbdistcodename' AND c.deactivated IS NULL GROUP BY value_string;
...
...
@@ -343,7 +343,7 @@ As a bonus, this query will show the number of hosts running each os release:
