1 |
On 17/01/2015 23:29, Stefan G. Weichinger wrote: |
2 |
> On 12.01.2015 17:46, Alan McKinnon wrote: |
3 |
> |
4 |
>> You'd have to define it yourself in your plays somewhere |
5 |
>> |
6 |
>> Several ways present themselves: |
7 |
>> |
8 |
>> - Group customers together by customer name and use the group name. |
9 |
>> |
10 |
>> - Define the customer directly in the inventory. Generally it isn't |
11 |
>> recommended to define variable there, but I think this is one of the few |
12 |
>> case where it does make sense. Sort of like this: |
13 |
>> |
14 |
>> acme_web_server ansible_ssh_host=1.2.3.4 customer=acme |
15 |
>> |
16 |
>> {{ customer }} then is available for that host whenever the host is in scope |
17 |
>> |
18 |
>> |
19 |
>> |
20 |
>> One thing you'll find with ansible is there's always a way to do |
21 |
>> something, often more than one way (like perl). And all ways often make |
22 |
>> sense (unlike perl) |
23 |
> |
24 |
> sorry for the delay ... busy week |
25 |
> |
26 |
> I still haven't wrapped my head around how to properly define my groups |
27 |
> and sets of hosts.. but I am on my way, thanks ;-) |
28 |
> |
29 |
> "learning" ... when it is better to have a group or a when-clause (when |
30 |
> OS = Gentoo) ... |
31 |
|
32 |
My advice: |
33 |
|
34 |
Start with groups. If you find you need to have lots of "when" clauses |
35 |
to make the plays work across more than one distro, and the whens follow |
36 |
the same format, then you might want to split them into groups. |
37 |
Make for example a "gentoo-www" group and a "debian-www" group, and |
38 |
create a super-group "www" that includes both. |
39 |
|
40 |
It's one of those questions you can only really answer once you've built |
41 |
it for yourself and can see what works better in your environment |
42 |
|
43 |
|
44 |
> Reading/rsyncing all the configs in isn't first priority now. Although |
45 |
> it already is nice-to-have as a server stopped to work this week. |
46 |
> |
47 |
> OK, backups on tape etc ... but I like that basic "profile" with /etc |
48 |
> and @world as well. |
49 |
> |
50 |
> - |
51 |
> |
52 |
> I hesitate to mention it as everything with the term "systemd" in it |
53 |
> seems to trigger not-directly-helpful replies here ... but I see issues |
54 |
> with playbooks/tasks controlling services on hosts running systemd: |
55 |
> |
56 |
> I have openrc and systemd installed/merged (installed with openrc, then |
57 |
> migrated to run systemd and openrc still there, but not active ... not |
58 |
> removing openrc just to keep it as some fallback) ... and when I try to |
59 |
> control services via the service-module of ansible I don't always get |
60 |
> valid results. It seems that the module detects openrc installed and |
61 |
> doesn't check further (is openrc *active* as well?) ... so I get |
62 |
> misleading replies/states in. |
63 |
> |
64 |
> IMO ansible should correctly detect the running PID1 .. and it tries to |
65 |
> as far as I understand the code of the service-module. |
66 |
> |
67 |
> For example I tried to write a task to ensure that ntpd is down/disabled |
68 |
> and chrony is installed/enabled/started ... no real success so far. |
69 |
|
70 |
If ansible confuses installed init systems with running init system, |
71 |
then that will be a bug in ansible and should be reported |
72 |
|
73 |
> |
74 |
> I will provide more info if needed ... saturday night now, so excuse me |
75 |
> stopping here ;-) |
76 |
|
77 |
:-) |
78 |
|
79 |
|
80 |
|
81 |
|
82 |
-- |
83 |
Alan McKinnon |
84 |
alan.mckinnon@×××××.com |