You should only use the "shell" module when you need shell functions
like flow control and redirects. Also, the "command" module is safer
because it is not affected by the user's environment.
Something seems to have happened as of Ansible 2.4.0.0 where this no
longer works. I suspect it is related to the major changes to static
and dynamic imports that landed around this same time.
In practice this achieves the same function, but without the "magic"
ability to use one task for different operating systems.
Something seems to have happened as of Ansible 2.4.0.0 where this no
longer works. I suspect it is related to the major changes to static
and dynamic imports that landed around this same time.
We make sure that this tasks always runs by using the special tag of
the same name.
Ansible 2.4 changes the way includes work. Now you have to use "import"
for playbooks and tasks that are static, and "include" for those that
are dynamic (ie, those that use variables, loops, etc).
See: http://docs.ansible.com/ansible/devel/playbooks_reuse_includes.html
I'm surprised this worked all these years actually. Since Ansible
version 1.6 it has been possible to use the version_compare filter
instead of doing math logic on strings.
See: https://docs.ansible.com/ansible/playbooks_tests.html
This reverts commit 201165cff6.
Turns out this actually breaks initial deployments, because the
cache gets updated in the first task, then you add sources for
nginx and mariadb, but it doesn't update the indexes because the
cache is < 3600 seconds old, so you end up getting the distro's
versions of nginx and mariadb.
I have added cache_valid_time=3600 for the first task in each
tag that could be possibly running apt-related commands. For ex,
the "nginx" tag is also in the "packages" tag, but sometimes you
run the nginx tag by itself (perhaps repeatadely), so you'd want
to limit the update unless the cache was 1 hour old
For idempotence we need to run all apt-related tasks, like editing
source files, adding keys, installing packages, etc, when running
the 'packages' tag.
Note: I've only tested this on a Debian container, and you can't
set these sysctls on containers (the host controls them). To make
matters worse, there is no fact to make ansible skip this on hosts
that are running in containers. For now I will just skip it on
hosts that are "virtualization" servers... even though we actually
do have KVM running on Debian on real hardware. *sigh*
Signed-off-by: Alan Orth <alan.orth@gmail.com>
Needed in Ubuntu 15.04 where iptables-persistent is going away. I
have added translations of the current IPv4 and IPv6 iptables rules.
Signed-off-by: Alan Orth <alan.orth@gmail.com>
- Don't run the static files as templates
- Use a separate playbook for related tasks
- Use a template for security.sources.list
Signed-off-by: Alan Orth <alan.orth@gmail.com>
All servers with non-rotating disks (SSDs) should be running noop,
and the rest should be running deadline.
Signed-off-by: Alan Orth <alan.orth@gmail.com>
I think it was originally supposed to be `ansible_os_family` but
we don't have anything other than Ubuntu, so let's just use that.
Signed-off-by: Alan Orth <alan.orth@gmail.com>
It's just too tricky to manage this. Ubuntu / RedHat preseeds and
kickstarts can create the user and add it to groups, but only when
we control the initial boot environment (ie not on Linode, Digital
Ocean, etc), so let's just say we assume this user exists and can
get root with sudo by the some we are running ansible on it.
Signed-off-by: Alan Orth <alan.orth@gmail.com>
Need to make sure the user gets created on a fresh install, like on
Amazon EC2 or OpenStack images where the first user is `ubuntu' and
you can't assume `provisioning' is already created.
Signed-off-by: Alan Orth <alan.orth@gmail.com>
