This patch allows the hostname module to detect and set the hostname for a
Kali Linux 2.0 installation. Without this patch, the hostname module raises
the following error
hostname module cannot be used on platform Linux (Kali)
Kali is based off of Debian.
Fixes https://github.com/ansible/ansible/issues/11768
Test plan:
- (in a Vagrant VM) created a user 'bob' with no ssh key
- ran the following playbook in check mode:
---
- hosts: trusty
tasks:
- user: name=bob state=present generate_ssh_key=yes
- saw that ansible-playbook reported "changes=1"
- saw that /home/bob/.ssh was still absent
- ran the playbook for real
- saw that /home/bob/.ssh was created
- ran the playbook in check mode again
- saw that ansible-playbook reported no changes
- tried a variation with a different username for a user that didn't
exist: ansible-playbook --check worked correctly (no errors, reported
"changed")
PR #1651 fixed issue #1515 but the requirement for path to be defined is unecessarily strict. If the user has previously been created a path isn't necessary.
I have a task like this in a playbook. The ansible_ssh_user is 'root'
for this host.
- cron:
hour: 00
job: /home/backup/backup.sh
name: baserock.org data backup
user: backup
Running it gave me the following error:
TASK: [backup cron job, runs every day at midnight] ***************************
failed: [baserock-backup1] => {"failed": true}
msg: crontab: can't open '/tmp/crontabvVjoZe': Permission denied
crontab: user backup cannot read /tmp/crontabvVjoZe
The temporary file created by the 'cron' module is created with the
Python tempfile.mkstemp() function. This creates a file that is readable
only by 'root' (mode 600). The Busybox `crontab` program then checks if
the file is readable by the 'backup' user, and fails if it isn't. So we
need to make sure the file is world-readable before running `crontab`.
If `password` is defined as `*` `useradd` or `usermod` returns an error:
msg: usermod: Invalid password: `*'
This works very well on Linux host to not define any password for a
user (mainly useful if your setup is only based on SSH keys for
auth). On OpenBSD this does not work, so we have to ignore the encrypted
password parameter if it defined as `*`.
This change is in response to issue #1515.
Original pull request #1580.
The original problem is: in authorized_key module you have no idea about users
which will be created by Ansible at first run. I can propose next two ways to
solve this problem:
1. Combine modules system/user.py and system/authorized_key.py in one module
(so you will know everything about users in that module)
2. Use small workaround: add my commit and always provide 'path' parameter
for authorized_key module during runs with --check option.
Fixes#530.
It's more generic than #578 which only fixes spaces escaping in name (target dir to mount).
Escaping is used in both `set_mount` (important for `src`, `name` and `opts`) and
`unset_mount` (for `name`).
It's shouldn't be used in `mount` and `umount` since `name` parameter is passed as array element
to `module.run_command`.
Signed-off-by: Konstantin Gribov <grossws@gmail.com>
This adds a must_exist option to the service module, which gives callers the
ability to be tolerant to services that do not exist. This allows for
opportunistic manipulation of a list of services if they happen to exist on the
host. While failed_when could be used, it's difficult to track all the
different error strings that might come from various service tools regarding a
missing service.
