| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| | |
Removed spurious "exec" from a debug string
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
lib/puppet/feature/base.rb
lib/puppet/file_serving/configuration.rb
spec/unit/indirector/ssl_file_spec.rb
spec/unit/parser/functions/extlookup_spec.rb
spec/unit/resource/catalog_spec.rb
test/language/ast/variable.rb
|
| | |\
| | |
| | | |
Ticket/2.7.x/8662 root on windows
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When running as root, puppet will by default manage internal file
permissions for file-related settings. However, ruby does not support
chown/chgrp functionality on Windows, so puppet will fail to run
(puppet apply generates an exception while trying to set the owner,
etc).
This commit disables internal file permissions handling on Windows
until we add support for chown (at least) as part of the larger file
type effort on Windows.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When running as root, puppet will generate a catalog from its settings
to create the various directories, e.g. var, ssl. If mkusers is true
and a setting implements owner and/or group methods, then puppet will
automatically add user and group resources to the catalog (provided
the user name is not root and the group names are not root or
wheel). This functionality will not be supported on Windows, and so
this step is skipped.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This commit changes Puppet::Util::SUIDManager.root? (and
Puppet.features.root?) to only return true if the user is running with
elevated privileges (granted via UAC). If this check fails because
elevated privileges are not supported, e.g. pre-Vista, then we fall
back to checking if the user is a member of the builtin Administrators
group.
This means if you are logged in as Administrator on 2008,
Puppet.features.root? will return false, unless you are explicitly
running puppet as an administrator, e.g.
runas /user:Administrator "puppet apply manifest.pp"
This commit also adds tests to ensure SUIDManager.asuser is a no-op on
Windows, since Windows does not (easily) support switching user
contexts without providing a password.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The root feature was being evaluated prior to the microsoft_windows
feature being defined. On Windows, this had the side-effect of calling
Process.uid prior to the win32 sys/admin gem being loaded. And the
default ruby implementation of Process.uid always returns 0, which
caused Puppet.features.root? to always return true.
This commit reorders the syslog, posix, microsoft_windows, and root
features due to dependencies among them. This ensures the
microsoft_windows feature is defined prior to evaluating the root
feature.
As a result of this commit, the SUIDManager now calls the win32
sys/admin version of the Process.uid method, which returns the RID
component of the user's SID. As this is not 0, Puppet.features.root?
will now always return false on Windows. A future commit will fix
this, so that Puppet.feature.root? only returns true when running as
the Windows-equivalent of root.
|
| | |\ \
| | | |
| | | | |
Maint/2.7.x/ssl file spec test failure
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
One of the spec tests required that the parent directory (in this case
/tmp) already exist and that /tmp/my_directory could be created. This
fails on Windows as /tmp likely doesn't exist, and also the test
doesn't actually need to create the directory.
This commit forces the call to exists? with the parent directory to
return true, and stubs the mkdir call so that the directory is not
actually created.
It also makes the raise_error expectation look for the specific error
message, instead of a generic DevError.
|
| | |\ \
| | |/
| |/|
| | |
| | |
| | |
| | | |
'jhelwig/add-missing-commit-for-ruby-1.8.5-compatibility-to-2.7.x' into 2.7.x
* jhelwig/add-missing-commit-for-ruby-1.8.5-compatibility-to-2.7.x:
Don't use non-1.8.5-compatible methods 'Object#tap' and 'Dir.mktmpdir'
|
| | |/
| |
| |
| |
| |
| |
| |
| | |
These methods aren't available until Ruby 1.8.6 (Dir.mktmpdir) and Ruby 1.8.7
(Object#tap).
Reviewed-By: Jacob Helwig <jacob@puppetlabs.com>
(cherry picked from commit 61df3f7c39d74b82e37f48c3519293406036e1e9)
|
| | |\
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* backport-windows-work-to-2.7: (60 commits)
maint: Fix build break due to recent merge from 2.7.x to master
Fix posix exec provider spec failures on Windows
(#5495) Remove dead Windows-specific code from posix exec provider
Stop trying to make config directories in Windows specs
(#8272) Add missing tests for Windows service provider methods.
(#8409) Add a default group provider for Windows
(#8408) Add a default user provider for Windows
(#8408/8409) Add a Windows ADSI helper module
(#8663) Exclude exec timeout test on Windows
(#8663) Exclude git rev-parse HEAD spec test on Windows
Check for the appropriate permissions in File type tests on Windows
Remove :fails_on_windows from file type tests that no longer fail on Windows
Disable file bucket diffing tests on Windows
Always put a slash between the checksum and path in filebucket URLs
Treat Windows absolute paths as absolute paths
Consolidate test logic determining if a registered file is in the temp directory
Clarify logic and error messages when initializing Puppet::FileBucket::File
Disable symlink related file tests on Windows
(#8644) Host provider on Windows
(#8660) Fix destdir option on Windows
...
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The resource_spec was failing because /etc is not considered a
fully-qualified path on Windows. Using File.expand_path fixes that.
The suidmanager_spec was failing because we weren't stubbing the
microsoft_windows feature, so SUIDManager.asuser was a no-op when
running as root, and our expectations weren't being met.
(cherry picked from commit af87f32a016a5ed48353f516f9558f95c54c50b4)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
These specs were assuming that paths such as /foo were always absolute, which
is not the case on Windows. Thus, when run on Windows, the provider was
complaining about receiving relative paths when it expected absolute, rather
than succeeding or failing in the intended way. Now we expand all paths we want
to be absolute, to guarantee they will be absolute everywhere.
Also, some specs were failing because they were trying to test the case where a
file isn't executable. That's not something we can reliably check on Windows,
so instead just stub the appropriate executable? methods.
Reviewed-By: Matt Robinson <matt@puppetlabs.com>
(cherry picked from commit e9b558dd35eec6e221aef9de3f300a5843347454)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Because this provider only applies when the posix feature is present (and thus
not the windows feature), it can never be used on Windows. Thus, the
Windows-specific command handling is unnecessary and unused.
Also added more specific error messages for the cases where a command doesn't
exist, isn't a file, and isn't executable. These only apply when the command
path is absolute (otherwise the message is simply command not found).
Reviewed-By: Matt Robinson <matt@puppetlabs.com>
(cherry picked from commit b28bcb031346cfd2026361ec5ffb420c1dcf60d7)
Conflicts:
spec/unit/provider/exec/posix_spec.rb
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
FileSetting#to_resource had a provision to not attempt to manage files in /dev,
which effectively stopped spec from trying to make their configuration
directories in /dev/null. However, on Windows, the path turns into something
like C:/dev/null, so the specs were still trying to manage their configuration
directories when this wasn't desired or handled by the spec.
Now, we also exclude management of C:/dev (or similar), to mimic the behavior
on Windows. Because this isn't a standard path (and thus will not be used for
anything else), there seems to be no harm in treating it as though it were
really /dev.
Reviewed-By: Josh Cooper <josh@puppetlabs.com>
(cherry picked from commit 44719fcf9f9053a7be1bea59d516f24d2234ede4)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Added missing spec tests for Windows service provider methods:
:stop, :enable, :disable, and :manual_start
Refactored to match Nick's previous work.
Reviewed By: Nick Lewis [nick@puppetlabs.com]
(cherry picked from commit d08ae7fd2180c95d1fcafa149128d25cc4680c6c)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This provider, windows_adsi, uses the Puppet::Util::ADSI module to manage
groups. It can only manage group existence and memberships, but is fully
functional in those regards.
Based on work by: Joel Rosario <joel.r@.internal.directi.com>
Based on work by: Cameron Thomas <cameron@puppetlabs.com>
Reviewed-By: Matt Robinson <matt@puppetlabs.com>
(cherry picked from commit 01f09f5f395bab66b90a4e81e958aa89025977b4)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This provider, windows_adsi, uses the Puppet::Util::ADSI module to manage
users. It can currently only manage group memberships, comments, and home
directories, which are the only fields that can be managed via ADSI.
Based on work by: Joel Rosario <joel.r@.internal.directi.com>
Based on work by: Cameron Thomas <cameron@puppetlabs.com>
Reviewed-By: Matt Robinson <matt@puppetlabs.com>
(cherry picked from commit ac00e9e289f8fdc81f060e7dd289e1a8e0f133c0)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This module (Puppet::Util::ADSI) provides access to Active Directory Services
Interfaces, using win32ole. The base module has methods for generating resource
URIs and connecting to ADSI.
It also provides classes Puppet::Util::ADSI::User and Puppet::Util::ADSI::Group
for managing Active Directory users and groups, along with their properties and
group memberships. This will be used to implement the Windows ADSI user and
group providers.
Based on work by: Joel Rosario <joel.r@.internal.directi.com>
Based on work by: Cameron Thomas <cameron@puppetlabs.com>
Reviewed-By: Matt Robinson <matt@puppetlabs.com>
(cherry picked from commit b5fd95336e71ad428109cddf6cd2f33bdd31e025)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The exec provider is not yet supported for Windows and this test relies
on /bin/sleep. And due to #8410 it attempts to execute the program named
"sleep 1", with variations of "sleep 1".bat, etc. This test needs to be
reworked for Windows when the exec provider is implemented.
Reviewed-by: Nick Lewis <nick@puppetlabs.com>
(cherry picked from commit 0efe900902f0a6528c78c966b73f3eb6c720353b)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When running spec/integration/parser/compiler_spec.rb, the git command
passed to Puppet::Util.execute is an array containing a single string
["git rev-parse HEAD"]. On Unix, it calls Kernel.exec(*command), but on
Windows it calls Process.create(:command_line =>command), which attempts
to execute the program called "git rev-parse HEAD" and fails:
CreateProcess() failed: The system cannot find the file specified.
This commit marks the test as fails_on_windows, and will be re-enabled
when #8410 is fixed.
Reviewed-by: Nick Lewis <nick@puppetlabs.com>
(cherry picked from commit 7ca187509ce954e5b2707212a5615dbb9eb20378)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Ruby's interface to the permissions on Windows does not map well to
the *nix concept of User, Group, and Other. On Windows directories
don't get the execute bit, and Ruby cannot manage group, and other via
the standard chmod interfaces.
Because of this, we no longer check that the execute bit is set on
Windows, and use a permission set that will show differences if we
fail to set the permissions on Windows.
Reviewed-by: Nick Lewis <nick@puppetlabs.com>
(cherry picked from commit 447c1171845d8d17e4e684c9508fddecc003d15e)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
With the previous changes to the file bucket and the handling of what
is considered an absolute path, enough pieces have slid into place
that the file type is now mostly working on Windows.
Reviewed-by: Nick Lewis <nick@puppetlabs.com>
(cherry picked from commit 6385e08004ff06b709cc874870de38c078adb791)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The diffing ability of the file bucket is purely master functionality,
and not supported on Windows.
Reviewed-by: Nick Lewis <nick@puppetlabs.com>
(cherry picked from commit 660ea963ddc5c74a758f6d52384ea40a8d335c58)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Since absolute paths on Windows do not always start with /, we need to
make sure that there is always a slash between the checksum and the
path, or the drive letter will end up being considered as part of the
checksum.
On systems where absolute paths always start with /, the extra slash
is removed by the parsing done to the constructed URL.
Reviewed-by: Nick Lewis <nick@puppetlabs.com>
(cherry picked from commit 5314376d4378c4b4f990a7d61a9677594e12a2a5)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously, we only considered files that matched the *nix concept of
'absolute' as being absolute paths. Since absolute paths on Windows
look more like URLs with this world-view, we need to specifically look
for the Windows absolute paths, and treat them as such.
We will still treat *nix absolute paths as absolute on Windows, even
though they are actually relative to the "current" drive. We do not
currently limit which "style" of absolute path is allowed based on
what the agent is.
Reviewed-by: Nick Lewis <nick@puppetlabs.com>
(cherry picked from commit 568d25ee10effd5e87c57cdc8c24280eabf9cd93)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously, we were always using string comparisons, and hard-coded
paths to temp locations on non-Windows platforms. This was
problematic for a few reasons. We had to maintain a list of temp
locations for the various platforms, and the string comparisons were
unreliable on Windows, since paths have two string representations
(the "short" name containing a ~ followed by a number, and the "full"
name).
By getting the current temp location using Dir.tempdir (the same
mechanism our temp creation code uses), we no longer need to maintain
the list of temp locations. Also, rather than doing string
comparisons on file paths, we can use a combination of
Pathname#ascend, and File.identical? to determine if the path
registered as a temp file for deletion was actually created in the
temp location.
With this refactoring, the same code now works for both Windows, and
non-Windows platforms.
Reviewed-by: Nick Lewis <nick@puppetlabs.com>
(cherry picked from commit 3aec02ba0e4bda8ba4e9fffbc6defaae4e4e2ba1)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Rather than stating the logic as 'if !thing', the two checks done when
initializing a new Puppet::FileBucket::File are now phrased as 'unless
thing', which should lessen the likelihood of overlooking the '!'.
We also now provide a reason for the ArgumentError being raised, which
should help users of Puppet::FileBucket::File quickly figure out what
is the problem when these exceptions are raised.
In addition to updating the tests to look for these new error
messages, we update the existing tests to specify which type of
exception, and what message it should have, when something is raised.
Reviewed-by: Nick Lewis <nick@puppetlabs.com>
(cherry picked from commit b4cacfd8f95577c514999b4dd6bcb7ad57e37207)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
While Windows filesystems typically have support for symlinks (NTFS),
there are no immediate plans to support symlinks on Windows.
Reviewed-by: Nick Lewis <nick@puppetlabs.com>
(cherry picked from commit 207d41f798356d7001f5de971e118e3c33d5f6d1)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The host provider did not work on Windows because it didn't know where
to find its hosts file. The provider now uses Win32::Resolv, which is
part of the standard ruby library, to find it.
Several host type/provider spec tests were marked as fails_on_windows,
but now that the provider is working, I removed the tag from those
tests, and verified that the tests now pass. There are two tests in
resources_spec that fail because the user and exec providers are not
supported on Windows yet, so those tests are marked as fails_on_windows.
Reviewed-by: Pieter van de Bruggen <pieter@puppetlabs.com>
(cherry picked from commit 82c6b3cb41397c989c011cf767066bcf1e403db2)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Specifying the --destdir option failed on windows because the install
script attempted to concatenate two absolute paths together. On Unix,
this is fine, but on Windows, it fails because the colon (part of the
drive specifier) is not a valid filename character. This commit adds a
method to join two paths, stripping off the drive specifier, if
present.
Also fixed a minor bug, which caused a deprecation warning to always
be printed when the --destdir option is omitted, which is the default
case.
Reviewed-by: Cameron Thomas <cameron@puppetlabs.com>
(cherry picked from commit f6006177a85766cfb3387db6c3d337bf97b52f17)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The puppet install.rb script now defaults the config directory to
%PROGRAMDATA%\PuppetLabs\puppet\etc on Windows. This is more inline
with Windows best-practices, as this directory is used to store
application data across all users. The PROGRAMDATA environment
variable also takes into account alternate system drives, by using the
SYSTEMDRIVE environment variable.
Note that the Dir::COMMON_APPDATA constant is so named because it
corresponds to the CSIDL_COMMON_APPDATA constant, which on 2000, XP,
and 2003 is %ALLUSERSPROFILE%\Application Data, and on Vista, Win7 and
2008 is %SYSTEMDRIVE%\ProgramData.
This commit also updates puppet's default run_mode var and conf
directories when running as "root" to match the install script, and
fixes the spec test, which was looking in the Dir::WINDOWS directory.
Reviewed-by: Cameron Thomas <cameron@puppetlabs.com>
(cherry picked from commit 95b21dfde7d77a61633555f20f2e3b9675d48415)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The mount, shell, and ssh_authorized_key types are not supported on
Windows, so these spec tests have been disabled when running on
Windows.
One of the compiler spec tests fails on Windows because
Puppet::Util.execute attempts to execute a program named "git rev-parse
HEAD". This has different semantics than Unix, where the command is
splatted, Kernel.exec(*command). Since this truly is a Windows bug, I
removed the fails_on_windows tag and updated ticket #8410.
Reviewed-by: Jacob Helwig <jacob@puppetlabs.com>
(cherry picked from commit d9ce88d10707268fe41c8f3ad1166137fe8e202f)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
One of the file spec tests was attempting to use X: as a fully
qualified file path, and the file type was correctly rejecting it,
since it is a relative path. This commit changes the spec test to
expect the file type to raise an exception.
Reviewed-by: Jacob Helwig <jacob@puppetlabs.com>
(cherry picked from commit e0d3f11fc7b580aedec5350dc41a01417d6acd8d)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When running as root, the default conf and var directories on Windows
are currently puppet/etc and puppet/var within the windows
directory. Updated the spec tests to match what the code does on
Windows.
Whether or not this is the correct behavior is something that will be
addressed in the future. See #8660.
Reviewed-by: Jacob Helwig <jacob@puppetlabs.com>
(cherry picked from commit f883648d2f6e4c357263c0cf3aa39afd63d852d7)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We are not supporting the ssh_authorized_key type on Windows at this
time, since Windows does not ship with an ssh server (though there are
third-party versions available). As a result these spec tests have
been disabled.
Reviewed-by: Jacob Helwig <jacob@puppetlabs.com>
(cherry picked from commit 6bd8aaa8a8307913eb20afc4e57551e2dfd4822e)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The cacher was causing spec tests to fail due to Time.now not having
millisecond resolution on Windows. Now that usage of the cacher has
been removed from many places, these tests now pass.
Reviewed-by: Jacob Helwig <jacob@puppetlabs.com>
(cherry picked from commit 9e502ed121847fe4fcca90453c0520b53103d17d)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The master, and queue applications are not used for agent
functionality and since only agent functionality is supported on
Windows, these tests do not need to run.
Reviewed-by: Josh Cooper <josh@puppetlabs.com>
(cherry picked from commit a521b99b2267e4c2588ceb6b90d36cab5af83aa6)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Because Windows allows a service to be both running and disabled, we now
support that capability. If a service is explicitly requested to be running and
disabled, we will set it to manual start if necessary, start it, and then
disable it. If the service is requested to be running and enabled, we will now
enable it before attempting to start it (previously, this would simply try to
start it and fail).
The exception to this rule is a service which is disabled, and for which we are
not managing the enable property. In that case, we assume that some other
authority has disabled the service, and respect that, failing to start. Thus,
if the user actually wants a service to be running and disabled, they must
explicitly declare that intent.
Reviewed-By: Jacob Helwig <jacob@puppetlabs.com>
(cherry picked from commit 12d0018f93e5a72a728c6decffb351a693a86344)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
These were using fake objects when that's not really necessary, so replace them
with real ones. Additionally, many of these specs were doing the same thing
(like creating a resource), so that has been extracted to the before block.
Reviewed-By: Jacob Helwig <jacob@puppetlabs.com>
(cherry picked from commit f5e8dbef9e16bf05e4c05a43407e94027faa2410)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Because the enable property of the service type uses :true and :false as its
valid values, rather than true and false, we need to return :true and :false
from our enabled? method. Otherwise, the property was being synced every time
it was enabled or disabled, regardless of whether it was actually in sync or
not.
Reviewed-By: Jacob Helwig <jacob@puppetlabs.com>
(cherry picked from commit 44e2d494f499e2005c1b31b92b97834189d4224d)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We want to use self.debug for logging in the provider, so that log messages are
properly associated with the resource, rather than generically coming from
Puppet.
Also fix the self.instances method to not use an unnecessary extra variable
when collecting.
Reviewed-By: Jacob Helwig <jacob@puppetlabs.com>
(cherry picked from commit 38c181d00e87ecc699c6a3e23dd2155f716a6602)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The environment validates its modulepath and manifestdir settings, but
it uses Dir.getwd to convert a relative path into an absolute path. The
problem is that on Windows, Dir.getwd returns a path with backslashes.
(Interestingly this only happens when puppet is loaded, not in irb for
example.) And since we do not yet support backslashes in Windows paths
or UNC paths, the directory is not included in the environment.
For the time being, I am using File.expand_path to normalize the path.
It has the side-effect of converting backslashes to forward slashes.
This is sufficient to work around backslashes in Dir.getwd. In the near
future, I will be refactoring how paths are split, validated, tested,
etc, and I have a REMIND in place to fix the environment.
But as a result of this change it exposed a bug in our rdoc parser
dealing with the finding the root of a path. The parser assumed that the
root was '/', but caused an infinite loop when passed a Windows path.
I added a test for this case, which is only run on Windows, because on
Unix File.dirname("C:/") == '.'.
After all of that, I had to disable one of the rdoc spec tests, because
it attempted to reproduce a specific bug, which caused rdoc to try to
create a directory of the form: C:/.../files/C:/.... Of course, this
fails because ':' is not a valid filename character on Windows.
Paired-with: Nick Lewis <nick@puppetlabs.com>
Reviewed-by: Jacob Helwig <jacob@puppetlabs.com>
(cherry picked from commit 9279d0954eb20d75e18a666fd572b5492e157608)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Ruby does not support creating symlinks on Windows (though Windows does
support them), and since the tidy spec test is designed to reproduce a
specific bug (as opposed to testing symlink functionality on Windows) it
has been disabled.
Ruby on Windows also does not support File.chmod, so the inspect spec
test has been disabled. The general issue of File.chmod on Windows is
something I know needs to be investigated.
Also disabled the cron spec test as this functionality will not be
supported on Windows (instead there will be task manager support).
Re-enable the autoload spec tests as those now pass on Windows (this is
probably due to the cacher changes recently made).
The inventory ssl spec is not supported on Windows and so is disabled.
However, while researching the failure, it was due to
Time.now.strftime("%Z") returning "Pacific Daylight Time" on Windows,
instead of "PDT" like it does on other platforms. As a result, the split
method was sometimes splitting in the wrong place.
As far as I can tell, the inventory code is only called from the CA (to
keep track of serial numbers for certs that it has issued). But it's
something to watch out for on Windows when calling strftime.
Webrick, fileserver and CA functionality are not supported on Windows so
these spec tests are disabled.
Also fix path issue with catalog spec.
Also several spec tests were creating tempfiles manually and calling
system("rm -rf ..."), these have been replaced with
PuppetSpec::Files.tmpdir.
Reviewed-by: Jacob Helwig <jacob@puppetlabs.com>
(cherry picked from commit 75d2e62cab1de7677463c274892f8920cb7e0cbf)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Disable CA related spec tests on Windows, since that functionality is not supported.
Some cert spec tests are still marked as fails_on_windows because
settings attempts to create and apply a catalog corresponding to
ssl/cert related directories. This fails because on Windows
Puppet.features.root? always returns true (which is a separate bug),
and as a result attempts to set the owner and group, which fails because
the provider is not implemented yet on Windows.
Also many of these tests were using Tempfile.new and trying to
system("rm -rf ...") later. I changed these to use
PuppetSpec::Files.tmpdir instead, which automatically cleans up
temporary directories after the tests have run.
Reviewed-by: Jacob Helwig <jacob@puppetlabs.com>
(cherry picked from commit 95837e6d3e74648617c308aedc52192bb13fde5a)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This provider allows us to query the system state through "puppet
resource", and manage the ensure, and enabled properties of services on
Windows.
This also adds support for a new enabled value of 'manual' on Windows
only. With this we support the three major start types for services on
Windows, with the following mapping of enabled to start type:
true => Automatic
false => Disabled
manual => Manual (Demand)
We use the win32-service gem to provide access to the Windows APIs for
our operations. This does add a new gem requirement for running Puppet
on Windows, but we were already requiring some gems from the same suite
that win32-service is a part of.
When referring to a service, the simple service name must be used,
instead of the display name. For example, "snmptrap", instead of
"SNMP Trap".
All system services are reported in 'puppet resource service',
including those started prior to run level 3 (system, device drivers,
etc.). These services should probably not be managed, without careful
thought and planning.
This currently does not support being able to move a service from
{enabled => false, ensure => stopped} to {enabled => true, ensure =>
running} (or enabled => manual) in a single Puppet run, since Puppet
currently always tries to sync ensure before any other property.
Because of this, the puppet run will fail every time, and the service
must first be managed as {ensure => stopped, enabled => true} (or
enabled => manual), before it can be managed as running and automatic
start or manual start.
Reviewed by: Jacob Helwig <jacob@puppetlabs.com>
(cherry picked from commit 82476e8be41b62ce1767ab6854a72b481b917380)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Because Windows file paths can (and do) contain '\', they can end up
being interpreted as back-references on the substitution side of gsub.
Since this is not at all what is intended, we use Regexp.escape to quote
them.
Reviewed-by: Jacob Helwig <jacob@puppetlabs.com>
(cherry picked from commit ca2f159caed691936bd9e87b59ccddc764066aa2)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We have removed every usage of cached_attr in which the attribute needs to be
manually expired. Thus, the only meaningful behavior provided by
Puppet::Util::Cacher is expiration based on TTLs. This commit reworks the
cacher to only support that behavior.
Rather than accepting an options hash, of which :ttl is the only available
option, cached_attr now requires a second argument, which is the TTL.
TTLs are now used to compute expirations, which are stored and used for
expiring values. Previously, we stored a timestamp and used it and the TTL to
determine whether the attribute was expired. This had the potentially
undesirable side effect that the lifetime of a cached attribute could be
extended after its insertion by modifying the TTL setting for the cache. Now,
the lifetime of an attribute is determined when it is set, and is thereafter
immutable, aside from deliberately re-setting the expiration for that
particular attribute.
Reviewed-By: Jacob Helwig <jacob@puppetlabs.com>
(cherry picked from commit d198fedf65e472b384666fc9ae3bef487852068a)
Conflicts:
spec/integration/node/facts_spec.rb
spec/unit/node_spec.rb
|
