suppressing autostart with debian packages

Archives Ansible Project
1

Hi.

My playbook uses an apt: action to install a bunch of Debian packages.
Some of these packages start the daemon automatically with the default
configuration. For my purposes, I want to avoid this.

One way to do this reliably is to install a /usr/sbin/policy-rc.d file
that does "exit 101". So I can do something like this:

    - name: Install policy-rc.d
      copy: src=policy-rc.d dest=/usr/sbin/policy-rc.d mode=0755

    - name: Install packages
      apt: pkg=$item state=installed
      with_items: [ git, vim, … ]

    - name: Remove policy-rc.d
      file: path=/usr/sbin/policy-rc.d state=absent

Now, this works, but it's a very big hammer indeed. It would be nice if
I could avoid installing and removing policy-rc.d unless it's required,
i.e. unless I'm actually going to install some package. It's easy to do
the removal conditionally: just turn it into a handler and notify it.

But I couldn't find any easy way to make the policy-rc.d installation
conditional. Hence my "apt_wouldinstall" proposal below:

    https://github.com/ansible/ansible/pull/3820

With my proposed module, one could do something like this:

    - name: Do we need to install anything?
      apt_wouldinstall: pkg=$item
      with_items: packages_needed
      register: pkglist

    - name: Install policy-rc.d if needed
      copy: …
      when: pkglist.changed

    - apt: …
      notify:
        - remove policy-rc.d

Note that it's vastly easier to check if a given list of packages is
installed using python-apt's cache[pkgname].is_installed in a loop,
compared to any shell-based way I've found to do it.

(There was a suggestion to use --check, but I think this was because I
didn't explain my use case sufficiently well—I want to make the decision
in the code, not interactively.)

I welcome any comments about this situation, including alternative
solutions for the problem (maybe a way to trigger handlers before
an action would be nicer?, or suggestions to improve the code.

Thank you.

-- ams

2

Yeah so I remember the pull request but didn’t get your context for it.

So for most users there’s no need of a “wouldinstall” module because you can run Ansible in check mode.

However, there’s no way to run just one task in check mode, so it seems this is a feature request for check at task level.

apt: …
check_mode: True

It is much better to implement the above rather than implement a “would” type for every module.

3

Yes, that sounds much better. Thanks for the suggestion. I'll implement
this and send an new pull request.

-- ams

4

Hi.

I'm sorry it's taken so long, but here's a pull request that allows
individual tasks to be run in check mode:

    https://github.com/ansible/ansible/pull/7439

The patch was written by my colleague Carlos Chapi (Cc:ed) and tested by
me (the original motivation for this feature was to find out if the apt
module would install certain packages, so as to take some extra actions
before and afterwards only if something's going to be installed).

For example (since the original context was so long ago):

    - name: Check if Postgres needs to be installed
      apt: name=postgresql-9.3 state=installed
      check_mode: True
      register: wouldinstall

    - name: Suppress autostart with policy-rc.d
      copy:
        content="#!/bin/bash\nexit 101\n"
        dest=/usr/sbin/policy-rc.d mode=0755
      when: wouldinstall.changed

    - name: Install Postgres
      apt: name=postgresql-9.3 state=installed
      when: wouldinstall.changed
      register: install

    - name: Remove policy-rc.d
      file: path=/usr/sbin/policy-rc.d state=absent
      when: install.changed

(My original proposal involved an "apt-wouldinstall" module, but Michael
suggested the much more sensible per-task check_mode setting.)

I can imagine many other "do x if y would happen" use-cases for this.

Thanks.

-- ams

5

I’m not finding too many use cases for this.

Maybe help me understand, but I’m wanting to reduce language clutter here and this does not seem like it would be widely utilized.

6

Thanks for having a look. I'll drop the proposal, and bring it up again
only if I find a compelling, different use-case in future.

-- ams