On Wednesday, June 10, 2015 at 11:17:25 PM UTC+2, Brian Coca wrote:
>
> @Christian, those are my thoughts for the future of the service
> module, this package module will serve as a template on how to split
> it and keep backwards compatibility using the generic module as a
> placeholder. Just need to add service system detection to facts and
> then use those internally.
>
Cool!
> As for keeping the policy in a single place, the same can be achieved
> by just making the ssl cipher string into a common variable and then
> have each template reference it. This does not work for all cases but
> I find it better to keep specific tasks for each OS and then abstract
> the common data, than the reverse which abstracts the common task but
> requires abstracting the non-common data.
>
That's only a partial solution -- you still have multiple copies of the
policy "we set the SSL cipher string to something custom." The thing I want
to achieve is "disable SSLv3 on our Apache servers", not "define a cipher
string that disables SSLv3" and "set that cipher string on Debian" and "set
that cipher string on RedHat" etc.
Say, you want to add support for Arch in the future. You add another
include file but happen to forget to add the lineinfile task. Your
playbooks run fine, POODLE happened a long time ago and you don't even
think about SSLv3 anymore, but all your Arch servers will offer it
(assuming Arch's default config still has it enabled, of course...).
My playbooks will fail on Arch hosts if I forget to add Arch's config
filename to my "disable SSLv3" task, reminding me about my "no SSLv3"
policy.
> Again, I'm all for choice, in this case I think it is an illusion as
> you update 1 common yaml file and 2 non-common yaml files vs 2 common
> yaml files and 1 non-common yaml file.
>
I am only editing 1 common yaml file -- roles/apache/tasks/main.yml -- that
includes all the relevant data ("!platform" is a YAML tag that I add to the
YAML parser (mis)using a vars_plugin, which, granted, is somewhat hacky and
will hopefully still work in v2 ;-) ).
Re your other comment about package versions: yes, we will always have to
manually curate some OS details. But cfg mgmt should help making that
easier, not say "package NAMES are different anyways, so we won't even let
you abstract the package MANAGER."
My task for installing PHP (different number of packages in different
distros) looks like this:
- include: install_packages.yml
pkgs: !platform
- php::
Debian: php5
RedHat: php55w
- Debian: php5-cli
RedHat: php55w-cli
- Debian: php5-curl
notify:
- reload apache
tags:
- apache/php/setup
That installs the logical "php" package (which is provided by "php5" on
Debian, and "php55w" on RedHat, and "php" everywhere else, i.e. Gentoo in
my case). In addition, it will install the CLI SAPI on Debian and RedHat
(that's included in "php" on Gentoo), and the curl extension on Debian
(included in "php55w" on RedHat). All in one single yaml file.
Different versions of distros can be treated as distinct distros. Until
recently (before we killed our last Ubuntu 10 and 12 servers), I had this
in my Apache role:
lineinfile:
dest: !platform
Ubuntu14: /etc/apache2/sites-enabled/000-default.conf
Ubuntu12: /etc/apache2/sites-enabled/000-default
Ubuntu10: /etc/apache2/sites-enabled/000-default
This wasn't perfect: there's still some duplication, but at least it's very
close together and not spread over multiple files.
Rolling-release distributions are tricky -- luckily I am able to keep all
my (few) Gentoo servers in sync, so I don't need to support multiple
"versions" of Gentoo.
--
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/1588482b-67f1-48c9-840e-5c2e34c06922%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
