Add references to CLA and Redmine. fixes #299
added an additional line to the help output for the model slice that shows the syntax for
getting the list of model templates (for some reason, this usage line was missed when we
refactored the slice API last August/September)
fixed copy-and-paste error in the line just added to the model help syntax
(#299) Add reference to trivial patch exemption.
Merge pull request #313 from khussey/documentation/master/299

Add trivial patch exemption, CLA, and Redmine references to contribution guide. fixes #299
Merge pull request #312 from tjmcs/tb/fix-model-help

Adds missing line to the model slice's help output
Adds protection against injection attacks to the nodejs layer

The nodejs layer of the Razor back-end was wide open to injection attacks. Not
only did all commands perform shell expansion of the command line, some paths
where also directly mapped to the file system without first checking if they
contained '..' segments. I had no problems letting Razor server up my private
ssh key for instance. This commits adds some code to prevent injection attacks
from happening. It consist of the following:
1. All calls to exec() has been replaced by calls to execFile() to avoid shell
   expansion.
2. When the execFile results in errors, those errors are now handled. They
   were previously ignored.
3. Splitting, decoding, and validation of request path was refactored into one
   function.
4. A new exception type InvalidURIPathError was introduced.
5. All path segments are checked for length (<200 characters) and validated
   with a regexp that ensures that they don't contain any control characters.
6. Several tests were added to verify that some known types of injection
   attacks are trapped.
Changed all instances of "invert" in tag.rb to "inverse" to work properly with the tag matching capability of both Razor and puppetlabs-razor
Prevents web access to the Razor config

One of the points in the security assessment of Razor was
"Unauthenticated access to Razor configuration file".

This commit ensures that this file cannot be accessed using
the web interface by letting the Ruby CLI preventing access
to the 'config' slice for all calls using the -w flag.

A new flag, '-j' was introduced to enable the nodejs layer
to obtain the config in json format. The Ruby CLI will block
all attemts to combine the -w and -j flags.

The prevention check was added to the Ruby layer rather than
in the nodejs layer for two reasons:
1. There are ongoing discussions about replacing nodejs.
2. The check would have been added for all http methods. In
   the Ruby CLI, it was enough to add it in one place.

A more elaborate solution where the check was moved into the
'config' slice was considered but rejected because I wanted
to keep the alteration as limited (and thus easy to review)
as possible.

The commit also contains some tests to verify that the config
is impossible to obtain using the web.
Fixes issue #360; modified puppet broker plugin so that it uses a more widely accepted Bourne-style shell syntax to redirect both stdout and stderr when invoking the '/tmp/puppet_init.sh' script during the broker handoff process.  Previously, this script was invoked using the syntax '|&' to redirect both stdout and stderr to a 'tee' command, now the syntax '2>&1 |' is used instead (which works better with older versions of 'bash' and older versions of other Bourne-style shells)
(#366) Broken dependency on `which` in Debian packaging

The Debian packaging indicates a dependency on the package which, which does
not exist. The correct dependency is on the package debianutils which includes
the which(1) command - except that is an "essential" package, so we shouldn't
depend on it, we should just assume it is present.

This drops the dependency in the obvious way, fixing the problem, and
closing #366 along the way.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Merge pull request #367 from daniel-pittman/bug/master/366-incorrect-dependency-for-which-in-debian-packaging

(#366) Broken dependency on `which` in Debian packaging
Support the `mongodb-10gen` database as well as `mongodb`

We generally installed using the upstream 10gen packages of MongoDB, even when
there were distribution packages, with the git modules.  As part of smoothing
the migration between the two we should make the `mongodb-10gen` package
satisfy the dependencies of the Razor package.

That should allow both modes - distribution packaged mongodb, or upstream, to
work correctly as the developer wishes.

This is not an issue on the RPM side of the fence, since their policies forbid
any direct dependency between our package and the storage engine.

This closes #368.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Merge pull request #369 from daniel-pittman/bug/master/368-support-mongodb-10gen-package

Support the `mongodb-10gen` database as well as `mongodb`
Merge pull request #364 from tjmcs/tb/fixes-issue-360

Fixes issue #360; redirect of stdout and stderr to 'tee' changed from `|&` to `2>&1 |`
Add a brief document on how to run tests

There was no guidance in the repository about the steps required to run tests,
and those are not completely obvious.  We should improve the tests themselves
to work better, but for now we can get good millage out of documenting
everything at a lower cost.

This closes #370.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Support multiple razor install types in acceptance suite

In order to transition smoothly from git to packaged versions of Razor, there
needs to be a period when we support both, so that we don't leave users high
and dry with a broken system.  Even an alpha product like this should care
about user experience at this level.

This enhances the acceptance test installer for Razor to support "package"
install mode, if we ask for `internal-packages` install mode.  The default
remains git, and we can explicitly request that also.

It also configured, in `internal-packages` mode, the internal apt package
repository that contains the artifacts of the last successful internal
package build.

Neither of those is expected to be useful from outside the walls of
Puppet Labs, but the general infrastructure will: when we establish public
package repositories, we will be able to integrate a test mode that uses
those, and ensure that we continue to pass acceptance tests with our packaged
product in the face of external change.

This is part of #307, but not sufficient to complete it.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Install the "spec" acceptance test suite to test servers

When we are running our acceptance test suite using packages, we end up
without the "spec" directory - which contains acceptance tests - installed.

That is sensible and correct, but means we need to transfer that from the git
checkout manually in order to actually test the product.

This closes #307.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Merge pull request #371 from daniel-pittman/feature/master/307-run-acceptance-test-using-packaged-artifacts

Feature #307 - run acceptance test using packaged artifacts
Puppet dislikes top level brace surrounded variables...

Apparently some versions of Puppet dislike `${foo}` at the top level, leading
to test failures with the message "Could not match ${foo}", which is awesome.

This corrects that - the unquoted variable is portable through all the
variants of the DSL, so solves the problem smoothly.

This is part of #372, but does not resolve it.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>