suppressing autostart with debian packages

241 views
Skip to first unread message

Abhijit Menon-Sen

unread,
Aug 13, 2013, 3:02:08 PM8/13/13
to ansible...@googlegroups.com
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

Michael DeHaan

unread,
Aug 13, 2013, 8:33:12 PM8/13/13
to ansible...@googlegroups.com
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.






-- ams

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.



--
Michael DeHaan <mic...@ansibleworks.com>
CTO, AnsibleWorks, Inc.
http://www.ansibleworks.com/

Abhijit Menon-Sen

unread,
Aug 13, 2013, 10:48:08 PM8/13/13
to ansible...@googlegroups.com
At 2013-08-13 20:33:12 -0400, mic...@ansibleworks.com wrote:
>
> 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

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

-- ams

Abhijit Menon-Sen

unread,
May 17, 2014, 1:25:54 PM5/17/14
to ansible...@googlegroups.com, car...@2ndquadrant.com
At 2013-08-13 20:33:12 -0400, mic...@ansibleworks.com wrote:
>
> 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

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

Michael DeHaan

unread,
May 18, 2014, 10:57:31 PM5/18/14
to ansible...@googlegroups.com, car...@2ndquadrant.com
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.





-- ams

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/20140517172554.GA13533%40toroid.org.
For more options, visit https://groups.google.com/d/optout.

Abhijit Menon-Sen

unread,
May 19, 2014, 12:23:28 AM5/19/14
to ansible...@googlegroups.com, car...@2ndquadrant.com
At 2014-05-18 22:57:31 -0400, mic...@ansible.com wrote:
>
> 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.

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
Reply all
Reply to author
Forward
0 new messages