`decoded_name` was created twice, each from `rset.name`
So, the second call to `.replace(r'\100', '@')` overwrites decoded_name, discarding the result of the call to `.replace(r'\052', '*')`
I had a problem with wildcard domains that was fixed by this patch.
This is necessary for the scenario when you push a new, broken monit
config out, and then set a state=reloaded handler - the error was
previously swallowed so you could end up with successful play but missing
monitoring (!).
Signed-off-by: Chris Lamb <chris@chris-lamb.co.uk>
Upon a second run, the default egress rule will be removed when a
vpc is specified but no other egress rules were set. This patch
corrects that behavior by removing the default egress rule from the
list of unmatched outbound rules.
Fixes#7309
The content of the sha256sum attribute should be lowered before comparing it with the calculated sha256sum.
In the following example the used sha256sum uses ABC.. and not abc.. and the check failed. This should not happen.
```
TASK: [get_url url=http://ftp.fau.de/apache/hadoop/common/hadoop-2.4.0/hadoop-2.4.0.tar.gz dest=/home/vagrant/hadoop-2.4.0.tar.gz mode=0644 sha256sum=024326AC68A1A68B5566B10F95609EAAFD9F70CFEB37FCA0E97CBB1674E57C3A] ***
failed: [instance000] => {"failed": true}
msg: The SHA-256 checksum for /home/vagrant/hadoop-2.4.0.tar.gz did not match 024326AC68A1A68B5566B10F95609EAAFD9F70CFEB37FCA0E97CBB1674E57C3A; it was 024326ac68a1a68b5566b10f95609eaafd9f70cfeb37fca0e97cbb1674e57c3a.
FATAL: all hosts have already failed -- aborting
```
* the current state of the ELB was not reflected properly when checking
the status after a change was made.
* invalid zones caused a traceback when enabling/disabling zones
If we try to use the user module without being root, it fail on RHEL/Fedora
because usermod --help cannot be run. The root cause is lack of permission
due to EAL4+ certification, as seen in shadow-utils changelo.
So if we cannot run it, assume there is no append. It doesn't matter
much since we will not be able to run usermod at all with or without the
option.
The current 10-second default timeout for rsync seems to be behind issue #6809.
As a workaround for the underlying issue in rsync when different versions are
used on the source and destination sides, don't include the timeout option
unless the user specifies a timeout > 0.
