unbound patch for ansible repo
unbound_ansible_v1.patch

The attache patch, unbound_ansible_v1, does not have iptables config (see code below). I need to figure out how to port the puppet defines to ansible.

{{{
iptables::firewall { 'ipv4':
tcpPorts => [ 80, 443 ],
custom => [
'-A INPUT -p tcp -m tcp -s 209.132.184.0/24 --dport 53 -j ACCEPT',
'-A INPUT -p udp -m udp -s 209.132.184.0/24 --dport 53 -j ACCEPT',
],
}
}}}

For iptables, we set that up in the base role. It looks at group or host variables to see what port(s) to allow.

Look for example at:

inventory/group_vars/keys

that has:

tcp_ports: [ 80, 443, 11370, 11371 ]

So, in migrating unbound we will also need a group_vars/unbound and a host_vars/unbound-$name for each instance. :)

Aside from that, the only other issue I see is that the semanage stuff will run everytime and show changed. So, we should either run a command that tests it and not run the semanage if it's already set, or set changed_when: to not show changes if the exit code on it says there aren't any.

Thanks for working on this!

Just need the data for host_vars for unbound machines.

Note: unbound_ansible_v1.patch needs to be applied first and then the unbound_ansible_v2.patch to get the right config.

Looks pretty nice!

Some general nitpicks:

• We don't need the fedmsg_base role here, there's no fedmsgs around unbound.

• We don't have any stg unbound instances, so you can drop the when not in staging line after the openvpn task.

• We don't need apache or mod_wsgi. Drop those tasks.

• On the creates stuff, you can still use command, there isn't a need to redirect the output, the command module itself will create the file after it runs the first time, and not run it every time after that.

For host vars:

unbound_ib01:
{{{

nm: 255.255.255.128
gw: 152.19.134.129
dns: 152.2.21.1
ks_url: http://infrastructure.fedoraproject.org/repo/rhel/ks/kvm-rhel-6
ks_repo: http://infrastructure.fedoraproject.org/repo/rhel/RHEL6-x86_64/
volgroup: /dev/ibiblio01_vg
eth0_ip: 152.19.134.150
vmhost: ibiblio01.fedoraproject.org
datacenter: ibiblio
}}}

unbound_tummy01:
{{{

nm: 255.255.255.240
gw: 66.35.62.174
dns: 198.49.126.1 66.35.36.133
ks_url: http://infrastructure.fedoraproject.org/repo/rhel/ks/kvm-rhel-6
ks_repo: http://infrastructure.fedoraproject.org/repo/rhel/RHEL6-x86_64/
volgroup: /dev/VolGroup00
eth0_ip: 66.35.62.163
vmhost: tummy01.fedoraproject.org
datacenter: tummy
}}}

unbound_telia01:

{{{

nm: 255.255.255.240
gw: 80.239.156.209
dns: 213.248.76.210
ks_url: http://infrastructure.fedoraproject.org/repo/rhel/ks/kvm-rhel-6
ks_repo: http://infrastructure.fedoraproject.org/repo/rhel/RHEL6-x86_64/
volgroup: /dev/VolGroup00
eth0_ip: 80.239.156.220
vmhost: telia01.fedoraproject.org
datacenter: telia
}}}

I have updated the unbound_ansible_v2.patch to have host_vars and to remove the roles which pointed.

I tried command module on my machine but it ran every time despite of "creates" which, as far as I understand, is not the required behavior. This could be because of different versions of ansible, I'll have to check, but in that case, do we want something which may break with version change?

If this patch looks fine, then we can apply it. I'll try to pick another puppet module :)

Replying to [comment:5 adimania]:

I have updated the unbound_ansible_v2.patch to have host_vars and to remove the roles which pointed.

Looks good. ;)

I tried command module on my machine but it ran every time despite of "creates" which, as far as I understand, is not the required behavior. This could be because of different versions of ansible, I'll have to check, but in that case, do we want something which may break with version change?

Odd. No, that should work with any version of ansible...
Was it creating the file after running?

If this patch looks fine, then we can apply it. I'll try to pick another puppet module :)

It does (aside the command weirdness, which we should figure out). We will need to destroy the current instances and redeploy them with this, I can look at doing that next week sometime, once command is sorted.

Thanks.

Replying to [comment:6 kevin]:

Odd. No, that should work with any version of ansible...
Was it creating the file after running?
No, it did not create any file and I think that is why it was running every time. Redirection using ">" fails in "command". From 1, I am getting an impression that "creates" does not create a file. It merely check for the presence of it.

Yeah, sorry, I was misremembering how that worked. ;(

So, there needs to be a play after the command runs that creates the file... (using copy module, etc)

I guess I would slightly prefer command module and a seperate play to touch the file. command is safer than shell.

host and group vars, semanage idempotent fix, iptables and some minor fixes
unbound_ansible_v2.patch

Replying to [comment:9 kevin]:

I guess I would slightly prefer command module and a seperate play to touch the file. command is safer than shell.

patch v2 is updated to use command module and handlers.

That looks good to me. ;)

Can you do a final diff against the current ansible repo HEAD and we will get it commited and try and rebuild one of the instances. ;)

Attached unbound_ansible_final.patch which is output of:
{{{
git diff origin/master HEAD
}}}

entire unbound module created by diff with origin/master
unbound_ansible_final.patch

Did some minor cleanups and pushed into ansible repo. ;)

http://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=1c64975

I'll look at running it now and replacing the existing instances...

Thanks a lot for the work!

nagios check for openvpn and unbound process
nagios_unbound.patch