On machines with multiple pci domains get_device_facts would fail to
find a matching pci device causing setup to fail. Also on some platforms
there is additional information between the pci information and 'host'.
Modified get_device_facts to call lspci with the -D option and modified
the regex to account for the pci domain and to be more selective.
Migrated all examples: in DOCUMENTATION=''' string to standalone EXAMPLES=''' string
Added deprecation warning to moduledev.rst and remove deprecated example from it
Fixed up a few typos and uppercased some acronyms.
add consistency to how EXAMPLES are formatted
* Clarified the meaning of 'user'
* Changed 'sshdir' to 'path' in the example
* 'sshdir' is used internally in the module, but the argument is 'path'
* Made the capitalization consistent in the descriptions
When invoking dmidecode, first use module.get_bin_path() and secondly
use module.run_command.
Remove sub function execute() from get_dmi_facts().
Simplify get_dmi_facts() by only using two mechanisms to determine dmi
facts: first try /sys/devices/virtual/dmi and if not available, use
dmidecode executable.
When running inside a chroot userspace architecture might not
match that of the actual host.
This patch provides userspace_bits as reported by python's
platform.architecture(). Also provides userspace_architecture fact
if host is an x86 machine.
Also consolidated duplicate groups code into one get_groups_set() method.
Removed unused call to user_group_membership.
Removed sorting operations on set functions cause sets are inherently unordered.
Minor style improvements to match the rest of the code.
The new function will make the order of group names passed to the system command less determistic.
Which was already the case for modify_user_usermod() but not for other methods.
It will also strip out duplicate group names automatically which was not always the case previously.
This commit fixes a bug where the authorized_key module causes
the ~user/.ssh directory to be owned by root instead of the user,
when the manage_dir argument is not specified.
If the manage_dir argument was not specified, the module behaved as if
manage_dir was set to false, even though it's supposed to default to
true.
This module assumed that an optional argument, with no default
specified, will not be present in the module.params dictionary.
What actually seems to happen is that the argument does appear in
the module.params dictionary with a value of None.
The upside is that this line was evaluating to None instead of
true:
manage_dir = params.get("manage_dir", True)
I fixed the problem in this particular module by explicitly specifying
the default value for the manage_dir arugment. But if this bug
occurred because of a change in behavior in AnsibleModule, then other
modules may be broken as well.
