Browse Source

Fix typos.

fix-j
mhameed 5 years ago
parent
commit
adfec76bce
  1. 8
      docs/src/cdist-best-practice.rst
  2. 4
      docs/src/cdist-explorer.rst
  3. 6
      docs/src/cdist-features.rst
  4. 14
      docs/src/cdist-hacker.rst
  5. 2
      docs/src/cdist-install.rst
  6. 4
      docs/src/cdist-manifest.rst
  7. 5
      docs/src/cdist-stages.rst
  8. 2
      docs/src/cdist-why.rst
  9. 4
      docs/src/man1/cdist.rst

8
docs/src/cdist-best-practice.rst

@ -97,7 +97,7 @@ Including a possible common base that is reused across the different sites::
git merge common
The following **.git/config** is taken from a a real world scenario::
The following **.git/config** is taken from a real world scenario:
# Track upstream, merge from time to time
[remote "upstream"]
@ -142,7 +142,7 @@ implement this scenario with a gateway host and sudo:
- Setup the ssh-pubkey for this user that has the right to configure all hosts
- Create a wrapper to update the cdist configuration in ~cdist/cdist
- Allow every developer to execute this script via sudo as the user cdist
- Allow run of cdist as user cdist on specific hosts on a per user/group base
- Allow run of cdist as user cdist on specific hosts on a per user/group basis.
- f.i. nico ALL=(ALL) NOPASSWD: /home/cdist/bin/cdist config hostabc
@ -213,11 +213,11 @@ Other content in cdist repository
Usually the cdist repository contains all configuration
items. Sometimes you may have additional resources that
you would like to store in your central configuration
repositiory (like password files from KeepassX,
repository (like password files from KeepassX,
Libreoffice diagrams, etc.).
It is recommended to use a subfolder named "non-cdist"
in the repository for such content: It allows you to
easily distinguish what is used by cdist and what not
easily distinguish what is used by cdist and what is not
and also to store all important files in one
repository.

4
docs/src/cdist-explorer.rst

@ -3,8 +3,8 @@ Explorer
Description
-----------
Explorer are small shell scripts, which will be executed on the target
host. The aim of the explorer is to give hints to types on how to act on the
Explorers are small shell scripts, which will be executed on the target
host. The aim of each explorer is to give hints to types on how to act on the
target system. An explorer outputs the result to stdout, which is usually
a one liner, but may be empty or multi line especially in the case of
type explorers.

6
docs/src/cdist-features.rst

@ -8,7 +8,7 @@ Simplicity
Design
+ Type and core cleanly separated
+ Sticks completly to the KISS (keep it simple and stupid) paradigma
+ Sticks completely to the KISS (keep it simple and stupid) paradigm
+ Meaningful error messages - do not lose time debugging error messages
+ Consistency in behaviour, naming and documentation
+ No surprise factor: Only do what is obviously clear, no magic
@ -40,9 +40,9 @@ Requirements, Simplicity
UNIX
Reuse of existing tools like cat, find, mv, ...
UNIX, familar environment, documentation
UNIX, familiar environment, documentation
Is available as manpages and HTML
UNIX, simplicity, familar environment
UNIX, simplicity, familiar environment
cdist is configured in POSIX shell

14
docs/src/cdist-hacker.rst

@ -4,7 +4,7 @@ Hacking
Welcome
-------
Welcome dear hacker! I invite you to a tour of pointers to
get into the usable configuration mangament system, cdist.
get into the usable configuration management system, cdist.
The first thing to know is probably that cdist is brought to
you by people who care about how code looks like and who think
@ -21,18 +21,18 @@ subject prefixed with "[BUG] " or create an issue on github.
Coding conventions (everywhere)
-------------------------------
If something should be better done or needs to fixed, add the word FIXME
If something should be improved or needs to be fixed, add the word FIXME
nearby, so grepping for FIXME gives all positions that need to be fixed.
Indention is 4 spaces (welcome to the python world).
Indentation is 4 spaces (welcome to the python world).
How to submit stuff for inclusion into upstream cdist
-----------------------------------------------------
If you did some cool changes to cdist, which you value as a benefit for
everybody using cdist, you're welcome to propose inclusion into upstream.
If you did some cool changes to cdist, which you think might be of benefit to other
cdist users, you're welcome to propose inclusion into upstream.
There are though some requirements to ensure your changes don't break others
There are some requirements to ensure your changes don't break other peoples
work nor kill the authors brain:
- All files should contain the usual header (Author, Copying, etc.)
@ -130,7 +130,7 @@ use **git stash** to stash your changes away::
git fetch -v origin
git merge origin/master
Similar when you want to develop another new feature, you go back
Similarly when you want to develop another new feature, you go back
to the master branch and create another branch based on it::
.. code-block:: sh

2
docs/src/cdist-install.rst

@ -7,7 +7,7 @@ Requirements
Source Host
~~~~~~~~~~~
This is the machine you use to configure the target hosts.
This is the machine from which you will configure target hosts.
* /bin/sh: A posix like shell (for instance bash, dash, zsh)
* Python >= 3.2

4
docs/src/cdist-manifest.rst

@ -114,7 +114,7 @@ requirements can be added white space separated.
Above the "require" variable is only set for the command that is
immediately following it. Dependencies should always be declared that way.
On line 4 you can see that the instantion of a type "\__link" object needs
On line 4 you can see that the instantiation of a type "\__link" object needs
the object "__file/etc/cdist-configured" to be present, before it can proceed.
This also means that the "\__link" command must make sure, that either
@ -149,7 +149,7 @@ All objects that are created in a type manifest are automatically required
from the type that is calling them. This is called "autorequirement" in
cdist jargon.
You can find an more in depth description of the flow execution of manifests
You can find a more in depth description of the flow execution of manifests
in `cdist execution stages <cdist-stages.html>`_ and of how types work in `cdist type <cdist-type.html>`_.

5
docs/src/cdist-stages.rst

@ -3,8 +3,7 @@ Execution stages
Description
-----------
Starting the execution of deployment with cdist, cdist passes
through different stages.
When cdist is started, it passes through different stages.
Stage 1: target information retrieval
@ -67,5 +66,5 @@ The cache stores the information from the current run for later use.
Summary
-------
If, and only if, all the stages complete without an errors, the configuration
If, and only if, all the stages complete without errors, the configuration
will be applied to the target.

2
docs/src/cdist-why.rst

@ -40,7 +40,7 @@ call cdist types, the result is always the same.
Zero dependency configuration management
----------------------------------------
Cdist requires very litte on a target system. Even better,
Cdist requires very little on a target system. Even better,
in almost all cases all dependencies are usually fulfilled.
Cdist does not require an agent or a high level programming
languages on the target host: it will run on any host that

4
docs/src/man1/cdist.rst

@ -72,7 +72,7 @@ Configure/install one or more hosts.
.. option:: -b, --beta
Enable beta functionalities.
Enable beta functionality.
Can also be enabled using CDIST_BETA env var.
@ -244,7 +244,7 @@ CDIST_REMOTE_COPY
Use this command for remote copy (should behave like scp).
CDIST_BETA
Enable beta functionalities.
Enable beta functionality.
EXIT STATUS
-----------

Loading…
Cancel
Save