| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |\ \ \
| | |/
| |/| |
|
| | |\ \
| | | |
| | | |
| | | |
| | | | |
daniel-pittman/bug/2.7.x/4762-ensure-that-clients-on-the-moon-can-successfully-connect
Bug/2.7.x/4762 ensure that clients on the moon can successfully connect
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously, we only allowed Puppet Clients at a maximum distance of somewhere
between 7,494 and 14,988 kilometers from the master, depending on the variance
in local conditions.
While this gave us good data security against hostile clients connecting from
the dark side of the moon, real world testing shows the moon folks are likely
to just take over a local staging host and attack that way.
So, instead, allow clients sufficient time they should be comfortable able to
connect to a master from the moon. We still refuse clients further out, like
Mars, since it seems unlikely that Puppet management over that distance should
work.
We advise the manned Mars expedition to deploy a local Puppet Master to manage
infrastructure in their base, and to watch out for the martians.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We have historically had the preferred contribution process on the
Redmine wiki, however this is not obvious to people that don't already
know it is there. By adding this document to the repository itself,
it becomes much easier for new contributors to find what the preferred
contribution methods are.
By having the preferred contribution method in the repository also
means that it becomes a "curated" document, which must go through the
same submission/review process that other changes to the repositories
go through.
Reviewed-by: Nick Fagerlund <nick.fagerlund@puppetlabs.com>
Reviewed-by: Nick Lewis <nick@puppetlabs.com>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
vcsrepo is available in a module of its own, is missing tests, and
goes against the long-term goal of moving "extra" types out of core
puppet into modules (an example of this is the nagios types).
This reverts commit 25b967559dfa39eb094008c7a3952c4ee885530b, reversing
changes made to b87a1dea704ed981f2f0af728afac2c63e87b5a8.
Reviewed-by: Michael Stahnke <mike@puppetlabs.com>
|
| | |\ \ |
|
| | |\ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
* ticket/2.7.x/8704-fileserverconf_parse_errors:
(#8704) Give better errors for invalid fileserver.conf
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
If you tried to just put an allow or deny line in the fileserver.conf
without a mount point, you got a really confusing error message:
lib/puppet/network/handler/fileserver.rb:285:in `readconfig': undefined method `info' for nil:NilClass (NoMethodError)
Now instead we give an error saying no mount point was specified.
Reviewed-by: Josh Cooper <josh@puppetlabs.com>
|
| | |\ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
* tickets/2.7.x/1886:
(Maint.) Disable cleaning of storeconfigs.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This feature (and the corresponding tests) were causing intermittent
failures which we were unable to trace. We will reintroduce this
behavior when we can do so without test fragility.
Reviewed-By: Matt Robinson
|
| | |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
When we introduced verification of options, we forgot to handle the case that
global options from the Puppet settings system could be passed to the face.
This, in turn, means that the system would fail if you used any of those.
This remediates that, and now these work as expected.
Reviewed-By: Pieter van de Bruggen <pieter@puppetlabs.com>
|
| | |\ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
* tickets/2.7.x/1886:
(Maint.) Fix spec failures related to leaking state.
|
| | |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The `node clean` code has introduced a systematic change in
state which is not uniformly protected against by the tests.
As these order dependent failures arise, we should refactor
the tests to be more robust.
Reviewed-By: Matt Robinson
|
| | |\ \ \ \
| | |/ / /
| |/| | |
| | | | |
| | | | |
| | | | | |
* feature/2.7.x/1886:
(#1886) Clean up `node clean` for merge.
Fix #1886 - Add node cleanup capability
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This includes various style changes, and assorted fixes to testing.
Paired-With: Matt Robinson
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Here is a changeset that adds a new action to the puppet node face.
This application removes all traces of a node on the puppetmaster
(including certs, cached facts and nodes, reports, and storedconfig
entries).
Furthermore it is capable of unexporting exported resources of a
host so that consumers of these resources can remove the exported
resources and we will safely remove the node from our
infrastructure.
Usage:
puppet node clean [--unexport] <host> [<host2> ...]
To achieve this we add different destroy methods to the different
parts of the indirector. So for example for yaml indirections we
already offer read access for the yaml, this changeset adds
the destroy handler which only removes the yaml file for
a request. This can be used to remove cached entries.
This work is based on the initial work of Brice Figureau
<brice-puppet@daysofwonder.com>
|
| | |\ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
* tickets/2.7.x/5777:
Deprecate RestAuthConfig#allowed? in favor of #check_authorization
Fix #6026 - security file should support inline comments
Fix #5010 - Allow leading whitespace in auth.conf
Fix #5777 - rule interpolation broke auth.conf CIDR rules
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
#allowed? was a poorly named method since it isn't actually a predicate
method. Instead of returning a boolean, this methods throws an
exception when the access is denied (in order to keep the full context
of what ACE triggered the deny).
Given that #allowed? was overriding the behavior from AuthConfig, we
leave a version of #allowed? in place that will issue a deprecation
warning before delegating to #check_authorization. Once support for
XML-RPC agents is removed from the master, we will be able to remove
this delegation, since there should no longer be a reason for a
distinction between AuthConfig and RestAuthConfig.
Signed-off-by: Brice Figureau <brice-puppet@daysofwonder.com>
Signed-off-by: Jacob Helwig <jacob@puppetlabs.com>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Auth.conf, namespaceauth.conf and fileserver.conf were not supporting
trailing inlined comments.
Also this commit fixes some indentation and error management.
Signed-off-by: Brice Figureau <brice-puppet@daysofwonder.com>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The regex used to detect ACE is too lax and would allow trailing
spaces to sneak in, which in turn would confuse the ACE parser.
Signed-off-by: Brice Figureau <brice-puppet@daysofwonder.com>
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Due to the interpolation performed to support regex back-references,
various type of rules (mainly IP CIDR notations and wildcard hosts)
were not working anymore.
This patch adds an auth.conf integration test that covers most
of the various rules types.
Signed-off-by: Brice Figureau <brice-puppet@daysofwonder.com>
|
| | |\ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
2.7.x
* ticket/2.7.x/maint-show_help_for_cert_without_subcommand:
maint: Fix cert app to print help and exit if no subcommand
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
In 2.6.x this was the behavior, but the changes to the way options
parsing worked in 2.7.x to support faces changed the behavior of how
help was called.
This resulted in the follow unhelpful error message when you just called
`puppet cert`:
/Users/matthewrobinson/work/puppet/lib/puppet/ssl/certificate_authority/interface.rb:85:in `method='
Invalid method to apply
Reviewed-by: Pieter van de Bruggen <pieter@puppetlabs.com>
|
| | |\ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
* ticket/2.7.x/maint-improve_ssl_error:
maint: Suggest where to start troubleshooting SSL error message
|
| | |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Much like the infamous "hostname was not match" error message, there's
another SSL error that people run into that isn't clear how to
troubleshoot.
err: Could not send report: SSL_connect returned=1 errno=0
state=SSLv3 read server certificate B: certificate verify failed.
As far as I can tell this only ever happens when the clock is off on the
master or client. People seem to think it will happen other times, but
I haven't been able to reproduce it other ways - missing private key,
revoked cert, offline CA all have their own errors. I googled around
and the only thing I've seen for this error in relation to puppet is the
time sync problem.
So the error message text just has some additional info to suggest you
check your clocks.
Reviewed-by: Nick Lewis <nick@puppetlabs.com>
|
| | |\ \ \ \
| | |/ / /
| |/| | /
| | | |/
| | |/| |
|
| | | |\ \ |
|
| | | |/ /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The introduction of composite namevars caused the resource title used in
resource aliases to be set as an array, even when the resource only had one
namevar. This would fail to conflict with non-alias entries in the resource
table, which used a string for the title, even though the single element array
contained the same string.
Now, we flatten the key used in the resource table, so that single element
arrays are represented as strings, and will properly conflict with resource
titles.
Paired-With: Jacob Helwig <jacob@puppetlabs.com>
|
| | | |\ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
* ticket/2.6.x/8418-inspect_respect_run_mode:
(#8418) Fix inspect app to have the correct run_mode
maint: Adding logging to include environment when source fails
maint: Add debug logging when the master receives a report
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Requiring puppet before the run_mode has been set by the application
causes the default run_mode of 'user' to be set instead of what the
application wants. This leads to the incorrect default settings to be
used, which lead to inspect not being able to properly retrieve file
metadata from a fileserver.
Reviewed-by: Max Martin <max@puppetlabs.com>
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Reviewed-by: Max Martin <max@puppetlabs.com>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
It's always bothered me that when running puppet inspect (or any
application that produces a report really) the master gives no
indication that anything happened when it processes the report.
Reviewed-by: Max Martin <max@puppetlabs.com>
|
| | |\ \ \ \ |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
By default, the SSL-related faces should all render a strings,
not with `Object#inspect`.
Reviewed-By: Daniel Pittman
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The additional quotation marks frustrate certain syntax highlighters,
and are completely unnecessary for their use.
Reviewed-By: Daniel Pittman
|
| | |\ \ \ \ \
| | |/ / / /
| |/| | | | |
|
| | |\ \ \ \ \ |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The validation for the ca_location option on the certificate
application continued to hang around on the application long
after the face realized its potential to take responsibility
for itself. This change moves (and adds) validation code as
appropriate into the Face.
Reviewed-By: Matt Robinson
|
| | |/ / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Ruby 1.8.7 is fairly lax about various bits of introspection, including that
we can't tell much about what arguments a block takes. Ruby 1.9.2 makes it
possible to do this, though.
Meanwhile, the Faces system uses this to make sure that scripts and actions
take the right set of arguments, to avoid surprises: failing early and
explicitly is better than failing at runtime.
Which, in final turn, exposes that I forgot to accept the right arguments in a
couple of my testing actions for Faces, but didn't notice because 1.8.7
doesn't check that, and I didn't test on 1.9.2.
|
| | |\ \ \ \ \ |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Now that we enforce that options must be declared, the model we exposed in the
Ruby API (but not the CLI facade) was that you could pass additional arguments
to the indirection method by passing them as unknown options doesn't work.
Instead, explicitly declare an option, `extra`, that accepts the final
argument to be passed direct to the indirection. This makes things work
smoothly, as well as making it possible (once you can input a hash on the
command line) to invoke extra arguments from the facade too...
Reviewed-By: Pieter van de Bruggen <pieter@puppetlabs.com>
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Rather than printing directly, we should return the data from the Action and
allow the facade to route that to the user directly.
Reviewed-By: Pieter van de Bruggen <pieter@puppetlabs.com>
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Rewrite the process of validating and updating the options to fully reflect
the contract - we fail if there are unknown options passed, report nicely
errors of duplicate names, pass only the canonical names to the action code,
and generally enforce nicely.
Reviewed-By: Pieter van de Bruggen <pieter@puppetlabs.com>
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Rather than having multiple, separate operations that modify and validate the
arguments to an action, a single pass makes sense. This also means less walks
across the set of data, and a few less expensive method calls in Ruby.
Additionally, we work on a duplicate of the arguments hash rather than
directly modifying the original. Because everything we do is at the top level
key/value mapping, this is sufficient to isolate the original.
While mostly theoretical, we now don't mutilate the hash passed in, so the
user won't get nastily surprised by the fact that we could have done so.
Reviewed-By: Pieter van de Bruggen <pieter@puppetlabs.com>
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Part of the "social contract" of Faces, Actions and Options is that the
metadata we collect is authoritative: it covers everything that is possible.
In the initial release we didn't enforce that around options. If you passed
an unknown option in the hash, we just silently ignored it in validation and
made it available down in the action.
Now, instead, we enforce that rule. If you pass an unknown option we raise an
error and complain; anything that gets to the action will be listed in the set
of inspectable options.
Cases that depended on this behaviour to pass arbitrary content in the hash
should be rewritten to move that content down a level: take a hash value for
one option, and use that for your free content.
Reviewed-By: Pieter van de Bruggen <pieter@puppetlabs.com>
|
| | |/ / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
When we invoke an action, we parse a set of options. These have a canonical
name, and optionally a set of aliases. For example, :bar might have :b as an
alias to allow a short name to be given.
Previously we would just pass this on as received; if you passed :bar you got
:bar, and if you passed :b you got :b. This works, but means that every
action has to write the same code to extract the appropriate version of an
option from whatever set of aliases might be passed.
Now, instead, we centralize that and always pass options as their canonical
name to the action code. This makes it simpler to work with. (This happens
before any validation, or other user-supplied, code to simplify everything
that handles options.)
Reviewed-By: Pieter van de Bruggen <pieter@puppetlabs.com>
|
| | |\ \ \ \ \ |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
When we define an action on an older version of a Face, we must be sure to
directly load the core of that version, not just define it with the external
Action(s) that it had.
Otherwise we break our contract, which is that any core Actions for a specific
version will be available to your external Action for as long as we support
that core version.
Reviewed-By: Pieter van de Bruggen <pieter@puppetlabs.com>
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
When we first touch a Face, we load all the available Actions from disk.
Given they define themselves against a specific version of a Face, they are
automatically available tied to the correct version; this makes it trivially
possible to locate those on demand and return them.
Now, we have the ability to find and, consequently, invoke Actions on older
versions of Faces. We don't load enough context, though: the older face will
only have external Actions defined, not anything core.
Reviewed-By: Pieter van de Bruggen <pieter@puppetlabs.com>
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
As part of moving to load actions first, and their associated face, when
invoked from the command line, it makes sense to push the logic for finding
the action and face down into the Puppet::Face implementation.
This means that we can change the logic there without needing to update the
public part of the CLI implementation, and that any further facades can use
the same, correct, logic to locate the action for the face.
Reviewed-By: Pieter van de Bruggen <pieter@puppetlabs.com>
|
