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`.
This was originally required to allow other methods in SourcesList to
fail, but subsequent changes rendered that unnecessary, and it's just
a cleanup now, and avoids passing in module separately to save().
1. Don't test check_mode in both the caller and in the callee.
2. Don't test HAVE_PYTHON_APT inside an if that tests HAVE_PYTHON_APT
3. Don't be irritatingly vague about why the module fails ("You may be
seeing this because…").
Note that if «apt-get -y install python-apt» succeeds with rc==0, but
for some reason python_apt is not usable afterwards, this will break
because the imports in install_python_apt aren't wrapped inside a
try/except.
In other words, we assume that install_python_apt either succeeds or
fails with a traceback. This commit doesn't affect that behaviour.
Some things cannot be updated via the API, so check for those and fail
if the user is wanting to update them. Also don't try to update ipv6
stuff, as that doesn't work and will cause a traceback.
If `docker.__version__` contains non-digit characters, such as:
>>> import docker
>>> docker.__version__
'1.4.0-dev'
Then `get_docker_py_versioninfo` will fail with:
ValueError: invalid literal for int() with base 10: '0-de'
This patch corrects the parsing of the version string so that
`get_docker_py_versioninfo` in this example would return:
(1, 4, 0, '-dev')
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 `*`.
Docs imply the mysql_variables is used to operate a single variable therefore
- fail before making any db connections if variable is not set
- validate chars for mysql variable name with re.match(^[a-z0-9_]+)
- use "SHOW VARIABLE WHERE Variable_name" instead of LIKE search
- getvariable() returns only the value or None if variable is not found
- the module returns only the found variable value instead of tuple for easier operation eg. as registere variable in tasks
My project is using Ansible to automate cloud build process. Ansible has a core module gce.py for managing GCE instances.
We've come across a use case that's not yet supported - when executing ansible-playbook, if a child template is included, then metadata which is defined in and propagated from the mother template is treated as string type and not parsed correctly(which instead is dictionary type), and triggers release flow failure.
We currently put some fix by explicitly casting metadata to string type in our own branch, but would like to contribute the fix to Ansible so that everyone onboarding GCE and using Ansible for release management could benefit from it, or hear owner's opinion on fixing the issue if there's a better fix in owner's mind:)
Django since version 1.7 has built-in migrations, so no need to have south installed with recent django versions. The 'migrate' command works with built-in migrations without any change, but the output is different than the output produced by south, which breaks idempotence. This commit fixes this.
