On some switches, starting an SSH connection and immediately calling
recv() will result in a connection timeout. The switch requires some
input on the channel before it provides any prompt.
As such, this patch sends an empty command immediately upon connection,
triggering the switch to send a prompt which the shell can then
interpret.
Signed-off-by: Devananda van der Veen <devananda.vdv@gmail.com>
* fetch_url shouldn't both accept follow_redirects and support follow_redircts via module.params
* Default follow_redirects for open_url should be 'urllib2'
* Add redirect test for get_url
This commit fixes two bugs in the openswitch shared module. The first
bug was a wrong argument type for the use_ssl argument. It was set
to int and should be bool. The second changes the default ports for http
(was 80, now 8091) and https (was 443, now 18091). This change aligns
the default port values with the OS
The find_mount_point function does not resolve the mount point of paths with a soft-link correctly and returns the wrong mount-point.
I have mounted an NFS filesystem on /nfs-mount. This directory contains a directory called "directory". I also created a soft-link to this last directory: /soft-link-to-directory -> /nfs-mount/directory. I created the following task to copy a file into /soft-link-to-directory:
- name: copy file to nfs-mount
copy:
src: "file"
dest: "/soft-link-to-directory/file"
This throws an exception:
invalid selinux context: [Errno 95] Operation not supported
This is caused by the find_mount_point function to return '/' as the mount point for '/soft-link-to-directory/file'. This should have been /nfs-mount. Because the find_mount_point returns the wrong mount-point, the is_special_selinux_path function does not recognise the file is on an NFS mount and tries to set the default SELinux context (system_u:object_r:default_t:s0), which fails. The context should have been: system_u:object_r:nfs_t:s0
Full Ansible output:
TASK [copy file to nfs-mount] **************************************************
fatal: [hostname]: FAILED! => {"changed": false, "checksum": "f34b60930a5d6d689cf49a4c16bd7f9806be608c", "cur_context": ["system_u", "object_r", "nfs_t", "s0"], "failed": true, "gid": 24170, "group": "foundation", "input_was": ["system_u", "object_r", "default_t", "s0"], "mode": "0644", "msg": "invalid selinux context: [Errno 95] Operation not supported", "new_context": ["system_u", "object_r", "default_t", "s0"], "owner": "root", "path": "/soft-link-to-directory/.ansible_tmpWCT6Z4file", "secontext": "system_u:object_r:nfs_t:s0", "size": 37, "state": "file", "uid": 0}
The setup module calls /bin/lsblk once for each device appearing in the /etc/mtab file. However, the same device appears there mutliple times when the system uses bind-mounts. As a result, /bin/lsblk is being called repeatedly to get the uuid of the same device.
On a system with many mounts, this leads to a TimeoutError in the get_mount_facts function of the setup module as described in #14551.
Fixes#14551
ansible_os_family on openSUSE Leap has the wrong value:
"ansible_os_family": "openSUSE Leap",
It should be:
"ansible_os_family": "Suse",
This change fixes that by adding the relevant key and ensuring that dict
lookups replace ' ' with '_' so the key does not contain a space.
This commit fixes a situation where connection errors would be caught
but no useful information display. The connection error is now caught
and emitted in a call to fail_json
This commit fixes a situation where connection errors would be caught
but no useful information display. The connection error is now caught
and emitted in a call to fail_json
This commit fixes a situation where connection errors would be caught
but no useful information display. The connection error is now caught
and emitted in a call to fail_json
This commit fixes a situation where connection errors would be caught
but no useful information display. The connection error is now caught
and emitted in a call to fail_json
This commit fixes a situation where connection errors would be caught
but no useful information display. The connection error is now caught
and emitted in a call to fail_json
When working around "bad systems that insist on not allowing
updates in an atomic manner", we should not run previous exception
management code that tries to perform atomic move in case of
exception since the dirty non atomic move has already been
performed.
