Known issues
facts
task fails on Windows targets with Facter 3 installed
When running the facts
task on a Windows target that has Facter 3 installed,
the task will fail but still return facts for the target. Output might look
similar to the following:
$ bolt task run facts --targets windows_target
Started on windows_target...
Failed on windows_target:
{
...
}
Failed on 1 target: windows_target
Ran on 1 target in 4.97 sec
This failure is caused by a bug in Facter 3 on Windows that causes Facter to terminate with a segmentation violation signal when attempting to resolve Puppet facts.
📖 Related issues
Tasks executed with PowerShell version 2.x or earlier cannot use parameters named type
When executing PowerShell tasks on targets using PowerShell version 2.x or
earlier, you cannot use a task parameter with the name type
. Because
PowerShell version 2.x and earlier do not support type
as a named argument,
and PowerShell tasks convert parameters to named arguments, Bolt will filter out
a type
parameter before running the task.
When running PowerShell tasks on targets using PowerShell version 3.0 or later, any parameter name is permissible.
📖 Related issues
JSON strings as command arguments might require additional escaping in PowerShell
When passing complex arguments to tasks with --params
, JSON strings (typically
created with the ConvertTo-Json
cmdlet) might require additional escaping. In
some cases, you can use the PowerShell stop parsing symbol --%
as a
workaround.
📖 Related issues
Commands fail in remote Windows sessions
Interactive tools fail when run in a remote PowerShell session. For example,
using --password-prompt
to prompt for a password when running Bolt triggers an
error.
As a workaround, consider putting the password in a configuration file
such as bolt-defaults.yaml
or
bolt-project.yaml
, in an
inventory file, or passing the password on the
command line with the --password
option.
📖 Related issues
Unable to authenticate with ed25519 keys over SSH transport on Windows
By default, Bolt uses the net-ssh
Ruby libary to connect to targets over SSH.
The net-ssh
library requires the ed25519
and bcrypt_pbkdf
gems as
dependencies, which are not supported in Bolt's packaging process due to issues
with compiling native extensions.
Attempting to authenticate with ed25519 keys over SSH on Windows will result in an error message similar to this:
unsupported key type `ssh-ed25519'
net-ssh requires the following gems for ed25519 support:
* ed25519 (>= 1.2, < 2.0)
* bcrypt_pbkdf (>= 1.0, < 2.0)
A workaround is to use native SSH when you need to authenticate with ed25519
keys. When native SSH is enabled, Bolt will use a specified SSH client to
connect to targets instead of the net-ssh
Ruby library. To learn more about
native SSH, see native SSH
transport.
🧪 Native SSH is experimental and might change in future minor (y) releases.
📖 Related issues
🧪 Limited Kerberos support over WinRM
🧪 Authenticating with Kerberos over WinRM is considered experimental and is only supported when running Bolt from a Linux host. You must install the the MIT Kerberos library to authenticate with Kerberos over WinRM.
📖 Related issues
Errno::EMFILE Too many open files
This error is raised when there are too many files open in Bolt's Ruby process. To see what your current limit is, run:
ulimit -n
To raise the limit, set the following in your shell configuration file (For
example, ~/.bash_profile
):
ulimit -n 1024
You can also set Bolt's concurrency lower to have fewer file descriptors opened
at once. The default concurrency is 100. You can use --concurrency
on the CLI,
or set concurrency: <CONCURRENCY>
in Bolt config.
📖 Related issues