summaryrefslogtreecommitdiff
path: root/spec/unit/settings
AgeCommit message (Collapse)AuthorFilesLines
2014-09-02(PUP-3069) Fix path expansion for environment.conf test on WinJosh Partlow1-2/+2
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.
2014-08-29(PUP-3069) Change restrict_environment_manifest nameJosh Partlow1-4/+4
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.
2014-08-29(PUP-3069) Halt compile if environment has manifest conflictJosh Partlow1-0/+10
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.
2014-08-29(PUP-3069) Add spec test for new default optionsBritt Gresham2-6/+6
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.
2014-08-29(PUP-3069) Add default manifest settingsJosh Partlow1-10/+67
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.
2014-06-26(PUP-2521) Define Process constants locallyEthan J. Brown1-4/+4
- 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.
2014-06-04Merge branch 'stable'Adrien Thebo1-0/+39
Conflicts: lib/puppet/defaults.rb
2014-06-04(PUP-2650) Add :array setting typeAdrien Thebo1-0/+39
2014-04-26(PUP-1381) make file_setting spec test more robustFelix Frank1-0/+1
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.
2014-04-16(PUP-1114) Deprecate environment sections in puppet.confJosh Partlow1-0/+29
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.
2014-04-16(maint) Remove unused helper methodJosh Partlow1-6/+0
2014-03-21(PUP-1596) Expand all paths when creating directory environmentsJosh Partlow1-5/+8
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.
2014-03-18(PUP-1596) Interpolate settings inside an environment.confJosh Partlow1-2/+2
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.
2014-03-18(PUP-1596) Read environment.conf for new directory environmentsJosh Partlow1-0/+48
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.
2014-01-17Revert "Merge branch 'ticket/master/18342-windows-file-setting-owner-group'"Iristyle1-9/+27
This reverts commit cf4501c7a97c106994c2ef81756c2081f56feeef, reversing changes made to fcf482aa85708fe20f38cd96d6d92fc58ee78cf6.
2014-01-14(PUP-266) Puppet manages group and owner on configEthan J. Brown1-27/+9
- 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.
2014-01-06(PUP-761) Make most FileSystem API change related test passHenrik Lindberg2-3/+3
2013-12-17Merge branch 'stable'Adrien Thebo1-3/+60
2013-12-13(#23373) Check for minimal use of [main]Andrew Parker1-0/+18
When inserting settings into [main], there isn't any need to add a section header.
2013-12-12(#23373) Reuse existing section headersAndrew Parker1-2/+46
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.
2013-12-12(#23403) Do File.expand_path on the expected pathJosh Cooper1-3/+4
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.
2013-12-12(#23403) 'autosign' setting should manage file parametersAdrien Thebo1-3/+59
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.
2013-12-12(#23373) Provide a more structure config file parseAndrew Parker1-15/+49
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.
2013-12-11(#23373) Support selecting the sectionAndrew Parker1-5/+64
The --section option to the subcommand now allows a specific section of the configuration file to be manipulated.
2013-12-09Merge branch 'feature/master/23373-manipulate-puppet-conf-ignore-sections'Rob Reynolds2-1/+83
2013-12-09(#23373) Always open config so we are reading from the beginningJosh Partlow2-14/+13
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.
2013-12-06(#23373) Fix line number tracking for settings configJosh Partlow1-0/+20
Ensure we incremenet line count when parsing an ini_file, and tests that we are correctly tracking line count in multi line config errors.
2013-12-06(#23373) Pull apart ConfigFile and IniFileAndrew Parker2-59/+63
The ConfigFile was getting muddled and large. This pulls out the new file manipulation code into IniFile and has ConfigFile use that.
2013-12-06(#23373) Remove duplicate config file parsersAndrew Parker1-1/+3
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.
2013-12-06(#23373) Allow basic control of puppet.confAndrew Parker1-0/+57
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.
2013-12-06(Maint) Expand paths for windowsJosh Cooper1-1/+2
The path /path/to/file is not absolute on windows, causing the specs to fail.
2013-12-05(#23349) Create autosign setting for input validationAdrien Thebo1-0/+45
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
2013-11-26(Maint) Eliminate Windows network lookupsJosh Cooper1-2/+2
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.
2013-11-08(#19447) Puppet::FileSystem::File.exist?Ethan J. Brown1-2/+2
- 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
2013-11-01(#21241) Use correct constant for low priorityJosh Cooper1-1/+1
Needs to be BELOW_NORMAL_PRIORITY_CLASS.
2013-10-31Merge pull request #1922 from joshcooper/ticket/master/21241-priorityJosh Partlow1-0/+66
(#21241) Allow process priority to be specified
2013-09-20(#21241) Set process priority if one is specifiedJosh Cooper1-1/+1
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.
2013-09-20(#21241) Add a priority settingJosh Cooper1-0/+66
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.
2013-09-06(maint) Windows failing spec fixesIristyle1-3/+1
- 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
2013-08-15(#22205) Add enum setting typeAndrew Parker1-0/+27
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.
2013-04-25(maint) Make sqlite3 use an in-memory DB (try 2)Jeff McCune1-1/+7
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.
2013-01-02(Maint) Ensure tests are hitting the right ascpectAndrew Parker1-2/+4
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.
2012-12-18(#9862) Do not manage the group if it doesn't existAndrew Parker1-4/+22
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.
2012-12-18(#9862) Allow group to be rootAndrew Parker1-2/+2
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.
2012-12-18(Maint) Show the actual allowed values for groupAndrew Parker1-1/+1
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.
2012-12-18(Maint) Clarify error message for invalid group and ownerAndrew Parker1-4/+4
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.
2012-12-18(Maint) Remove duplicate testsAndrew Parker1-28/+11
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.
2012-12-18(Maint) Move variable closer to point of useAndrew Parker1-4/+1
2012-12-17(Maint) Cleanup tests for group to actually test the logicAndrew Parker1-48/+45
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.
2012-12-17(Maint) Cleanup tests for owner to actually test the logicAndrew Parker1-30/+36
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.