| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The intention in these specs is for the default_manifest setting
to be absolute for the platform under test. Without an expand_path,
the POSIX style setting we're using will still seem relative on
windows, causing these two tests to fail. Really these settings
should only be used on a master instance, which would be POSIX,
but for completeness sake, this commit expands the initial
default_manifest paths.
|
|
After discussion with Nick Fagerlund and Henrik Lindberg, changing
restrict_environment_manifest setting to
disable_per_environment_manifest to more clearly reflect what the
setting does.
|
|
Henrik brought up that with the new restrict_environment_manifest
setting set true, authors of modules in a particular environment
may be surprised by a manifest they have specified in their
environment.conf not being pulled in, leading to bad behavior when a
catalog is executed. Although this is logged on the master, compilation
delivery and catalog execution is not prevented.
This commit will raise an exception on the master prior to catalog
compilation if it detect's a conflict between manifest settings in the
requested environment.
|
|
Added tests for checking that default_manifest behaves properly when
given $environment. Also when restrict_environment_manifest is true with
a non-relative default_manifest.
This commit also fixed the hook on the :default_manifest setting to
validate that $environment was not present when setting the value.
|
|
Some Puppet installations do not use environment specific manifests
(particularly when an ENC is in use), however may still have global
setup required for all environments. For these installations it is
convenient to have a :default_manifest setting specified rather than
copying them manifest into every environment.
There are also installations which have a separation of roles between
users mainting the puppet master, puppet.conf and enc, and users making
per environment module changes. In these cases some Puppet installations
prefer to restrict the use of per environment manifests.
These two use cases were handled by setting the global manifest to a
non-interpolated path while setting the global modulepath to a path
interpolated with $environment.
With these settings being deprecated, directory environment
installations did not provide a means of preserving this functionality.
This patch addresses this by providing two new settings:
* default_manifest - is now the fallback manifest path if non is
specified in a given environment's environment.conf. It defaults to the
environment root relative path './manifests' which is the same default
that was previously hardset in early version of directory environments.
* restrict_environment_manifest - if set to true, enforces that
environments cannot define their own manifest setting, and validates
that default_manifest is set to an absolute path.
It is an initialization error if default_manifest is set to a string
that has an '$environment' to be interpolated within it.
We also log an error if restrict_environment_manifest is true and the
loaded environment's environment.conf has a manifest setting that
differs from the default_manifest setting.
|
|
- Previously, Process constants were used in a few locations throughout
the code. Capture the needed PRIORITY_CLASS constants in our local
Windows Process class, and also define CREATE_NEW_CONSOLE. These
constants have moved in new versions of the win32-process gem.
- Note that ext/windows/service/daemon.rb doesn't load Puppet code.
The daemon only loads what it explicitly needs, so ensure the
CREATE_NEW_CONSOLE constant is defined there.
|
|
Conflicts:
lib/puppet/defaults.rb
|
|
|
|
A new call to self.resource_type in Puppet::Resource#initialize can cause
the loading of type code as a side effect. This interfered with the mocking
for the test
Puppet::Settings::FileSetting when being converted to a resource
should manage existent files even if 'create_files' is not enabled
Add a stubs call to one of the uncritical expectations so that
additional calls are not considered as spurious.
|
|
Environments specified in puppet.conf are deprecated ahead of removing
legacy puppet.conf environments in 4.0. Now we issue a single
deprecation warning if a section other than main, master, agent or user
is present in puppet.conf. Because the deprecation warnings are all
coming from the same line, Puppet::Util::Logging handles ensuring that
only one is issued.
|
|
|
|
When reading EnvironmentConf settings, relative paths were prepended
with the directory environment path. This commit ensures that we also
expand the paths properly so that they are absolute on both Windows and
Posix platforms.
|
|
The initial implementation of environment.conf handling for directory
environments did not take into account the interpolation of settings
within environment.conf settings. The issue was further complicated by
the fact that environment.conf settings are post-processed to make
relative paths absolute from the context of the environment directory.
For instance, given a directory environment
'/some/environments/interpolated' with an environment.conf where
'modulepath=$basemodulepath:relative/modules', lookup of the setting via
Puppet.setting.value(:modulepath, 'interpolated') would previously
create a directory environment via the loader, which would read the
environment.conf and create an EnvironmentConf object, and return a
modulepath looking like
"/some/environments/interpolated/$basemodulepath:/some/environments/interpolated/relative/modules"
This would then be interpolated by the Settings system, inserting the
value of $basemodulepath.
A direct call to the instatiated
Puppet::Node::Environment#full_modulepath, by contrast would return just
the pre-interpolated path. Neither was correct.
The problem was that the environment.conf values were being obtained
and post-processed for absolute paths, then passed to the instantiated
environment before settings ever had a chance to be involved.
Historically, this was because settings for directory environments were
based on the values obtained from an instantiated env instance, since
the settings were all hard defaults based solely on the environment
directory.
To fix this, the action of obtaining an environment's configuration has
been separated from the process of obtaining an environment, and a
get_conf() method has been added to the Environments loaders. For a
Directories loader, it returns the EnvironmentConf for the requested
directory environment. This is now used by Settings to obtain setting
information for a given directory environment. And Settings values for
an environment are considered canonical and used by the loader to
instantiate new directory environments.
The other half of the fix is a bit of logic in
EnvironmentConf#absolute() which does not prepend the environment
directory to a path section that begins with a '$' since this indicates
a configuration setting to be interpolated by the Settings system. This
allows the timing between standing up an EnvironmentConf instance, and
interpolating it within Settings to be separated.
|
|
Prior to this commit, the new directory environments would always have a
set manifest and modules directory relative to their environment
directory. This is too restrictive compared with the arbitrary
modulepath and manifest settings available to legacy puppet.conf
environments, so we are adding a per directory environment.conf which
allows arbitrary settings for manifest, modulepath and config_version
per directory environment.
The path to the environment.conf is unique per directory environment and
is not configurable. For a given $environment found through the
$environmentpath, it is always
"<path-in-environmentpath>/$environment/environment.conf"
Sections other than 'main' are ignored in this file, as are any settings
other than manifest, modulepath and config_version. Adding a section or
other setting will log a warning but otherwise parse. A relative path
is always taken to be relative to the environment directory itself.
|
|
This reverts commit cf4501c7a97c106994c2ef81756c2081f56feeef, reversing
changes made to fcf482aa85708fe20f38cd96d6d92fc58ee78cf6.
|
|
- Previously, Puppet would ignore the configuration in defaults.rb for
setting a group / owner on a given file or directory -- even when
the Windows machine was running with administrative permissions
- Since Windows now has the capability of properly setting a group
and owner, allow Windows to manage these permissions when
appropriate
- The existing Puppet::Settings::FileSettings::Service class
depends on looking up the appropriate default service accounts
for use in a number of locations. To fall in line with this usage
pattern, "Administrators" is set as the default owner and
the "Service" group S-1-5-6 is set as the default group. This
special OS managed group includes all accounts with the logon
as a service token privilege.
|
|
|
|
|
|
When inserting settings into [main], there isn't any need to add a
section header.
|
|
Previously the setting manipulation code would always create a section
header if the setting was not already present in the file. This changes
it to reuse and existing header if the section is present but the
setting is not.
|
|
The FileSetting#to_resource method will call File.expand_path, which on
Windows, will convert a relative path like /foo/bar to an absolute path based
on the current drive.
This commit changes to the test so that the autoconf setting returns an
absolute path.
|
|
Puppet settings of type :file can specify the owner, group, and mode of
the file specified by the setting, like so:
[master]
autosign = $confdir/autosign.conf { mode = 664, owner = service, group = service}
Commit bca628dc extracted the autosign setting validation to a setting
class but dropped the ability for file settings to be specified. This
commit resolves the issue by making the autosign setting inherit from
the file setting.
|
|
The previous parsing of the config file was a hierarchy of hashes, which
made it hard to discover what the parts were. This changes it to use a
more structured system and lays the groundwork for moving lookup
behavior elsewhere.
|
|
The --section option to the subcommand now allows a specific section of
the configuration file to be manipulated.
|
|
|
|
Not all operating systems start reading from the same position with 'a+'
when opening the file. This ensures that we create the file with
default permissions, and begin reading from the first line.
We also make some acceptance changes for testing puppet config set, and
remove an acceptance test which was of dubious value.
|
|
Ensure we incremenet line count when parsing an ini_file, and tests that
we are correctly tracking line count in multi line config errors.
|
|
The ConfigFile was getting muddled and large. This pulls out the new
file manipulation code into IniFile and has ConfigFile use that.
|
|
This merges together the two concrete parsers for the puppet config
file. The transformation into the section groups is now done as a second
pass that works on the individual line objects. In doing so it became
clear that the error reporting was supposed to be issuing line numbers,
but was instead outputing the entire line that was wrong. This also
fixes up that mistake.
|
|
This provides a new action on the puppet config subcommand to allow
setting configuration values in the puppet.conf file. This implemenation
does not understand sections and so will simply change the first
instance of the configuration parameter that it is trying to change.
|
|
The path /path/to/file is not absolute on windows, causing the specs to fail.
|
|
This commit adds adds a new 'autosign' setting for the autosign command.
There are two reasons we're doing this: first, setting validation is
best done with a new setting class, and second, defining a hook for a
setting that might interpolate an application setting can cause the
interpolation to fail. By moving validation to a setting class, we can
sidestep this issue for now.
Jira issue: PUP-932
|
|
When using a UNC style file path, the windows file provider invokes
File.expand_path('//server/...'), which results in a failed Windows
network lookup. Executing these two tests was previously taking 15.4
seconds.
This commit instead provides a `localhost` server to short-circuit the
lookup. The tests now only take 1.7 seconds.
|
|
- All previous File and FileTest calls to exist? or exists? go through
the new FileSystem::File abstraction so that the implementation can
later be swapped for a Windows specific one to support symlinks
|
|
Needs to be BELOW_NORMAL_PRIORITY_CLASS.
|
|
(#21241) Allow process priority to be specified
|
|
This commit adds a Puppet::Util::Limits module for specifying process
priority, and mixes the module into Puppet::Util::CommandLine. Since
the CommandLine is the application entry point for puppet it seemed
sensible to have it set the process priority there, and to have it done
as early as possible.
Another option would have been to set the priority in the base
Application, after the application-specific settings have been
initialized. But this would mean you couldn't set the process priority
when puppet executes an ExternalSubcommand-based application.
As it stands now, it's not possible to have different priorities for
different sections, e.g. agent vs master, in puppet's configuration
file.
|
|
This commit add a `:priority` type of setting that maps generic priority
labels to operating system specific priorities, e.g. normal priority is
0 on posix, but 32 on Windows.
If the value is specified as an integer, then it is passed as is, so
that specific priority levels can be specified.
This commit also adds the `priority` setting to the main section of
puppet's configuration.
|
|
- The usage of Dir.getwd in tests has been simplified to
File.expand_path to properly handle mixed case CWD
- util_spec.rb ensures 'FOO' Env var cleared before test starts
- Windows SID checks should be performed as a regex match to
properly handle all accounts starting with S-1-5-*, which denotes
accounts with an identifier authority of SECURITY_NT_AUTHORITY
instead of hardcoding S-1-5-32-544, the Administrators group
|
|
It is often useful to be able to restrict the valid values for a setting
to a known set. This adds an :enum setting type that can take a :values
array, which defines the allowed values. If the value given for the
setting is now found in the list of allowed values, then it will throw
an error.
|
|
The previous attempt to enable in-memory sqlite3 database testing for
the spec tests in 58e1c23 is insufficient because the
Puppet[:dblocation] setting is a type of FileSetting which munges values
using File.expand_path. This is a problem because the path expansion
caused the database to be written to the filesystem rather than memory,
as intended.
This patch addresses the problem by adding a special case for all file
settings. The munge operation is a no-op if the special value of
':memory:' is passed.
|
|
The previous tests were not very careful about making sure that they
were going to be going down the right branches to test the path that
they wanted. This makes some of the branch selection more explicit so
make the tests a bit more robust to change.
|
|
The previous behavior for managing the group of a file meant that if the
group didn't exist puppet errored when trying to set permissions. This
changes the behavior to check for the existance of the group and in the
case of the group not existing (and we don't expect it to be created
because `:mkusers` is false) then the group is not managed.
There were several alternatives that were possible:
* use the primary group of the "root" user
* use the primary group of the `:owner` for the file
Neither of these were compellingly better alternatives, since this
should only be happening when puppet hasn't been fully configured on the
system.
|
|
The previous behavior allowed the group parameter to be set to root, but
it still selected the configured "service" group. This is contrary to
what is done for the owner parameter and seems to have been an
accidental behavior.
This commit brings this portion of the group handling in line with user.
|
|
The error message for the group parameter had gotten out of sync with
what the allowed values actually were. This updates the message to
include all of the allowed values.
|
|
The previous error message for an invalid owner looked like:
Error: Could not intialize global default settings: Internal error: The :owner setting for Where Puppet stores dynamic and growing data. The default for this setting is calculated specially, like `confdir`_.: vardir must be either 'root' or 'service', not 'gnats'
That message was not very clear as to what had just gone wrong because
it is providing far too much information. This commit changes the
message too:
Error: Could not intialize global default settings: The :owner parameter for the setting 'vardir' must be either 'root' or 'service', not 'gnats'
This applies to both the owner and group parameters.
|
|
Now that the behavior around selecting the right owner and group is
explicitly tested there is no need for the tests around the internal
method to determine whether to use a service user or not. This removes
those tests and fixes up the names of some of the replacement tests.
|
|
|
|
The previous tests for group behaviour of the file setting was not very
clear as to the logic it tried to implement. This changes the tests and
makes clear that the group behavior is a little odd in that if 'root' is
specified it still uses the service group.
|
|
The previous tests around the owner behavior for a file setting did very
little to test the logic around what actual owner will be used when.
This commit changes the tests to make them more clearly define the
behavior of the owner selection.
|
