Although is not in OVH, it would make a lot of sense to add it to the ansible inventory and monitor it. @fpoulain do you think that would be a bad idea for some reason?



For the record, I did a apt-get dist-upgrade + reboot today.


Monitoring is good!

Monitoring an external service is pretty easy, but monitoring an external VM hasn’t been done with the current Icinga2 setup and would require some adjustments to handle any heterogeneity in the cluster.

Unless you mean introducing the VM in the inventory as an Enough VM? Then if it’s well named and have the infrastructures’ postfix config, it should go straightforward[*], provided that the needed ports are open.

[*] But since we never did it, it may not be so simple. :slight_smile:


Yes, that’s what I had in mind. The VM is not otherwise used and there is no risk of us destroying something. The installation of the VM was done manually, as explained in the datafin related post

This is the challenging part. We need to open the firewall to accept incoming connections from this VM for both icinga & postfix.


Yes, that’s what I had in mind.


This is the challenging part. We need to open the firewall to accept incoming connections from this VM for both icinga & postfix.

Ok. For what I understand the openstack API is only about IP block in CIDR notation at rule level. So we should duplicate security rules of internal group over a few new security groups (['ouvreboite', ..., 'ansible']?). The groups’ rules could define a remote_ip_prefix in /32, taken from a list host some trusted hosts (a inventory group?). Then this VM (and at least the ansible VM) would be in trusted hosts.

I suppose we could put rules in the default security group but this is a proposal for organizing them.

And then as an exercice we could retry to introduce the ansible-host in inventory before try with external host.


That sounds like a sensible approach. We could have security groups

  • postfix for the postfix host (and this one would have the /32 for remote trusted host)
  • icinga for the icinga master (and this one would have the /32 for remote trusted host)

The ouvre-boite host would belong to the group external-trusted-host (by group I mean ansible group, same as pets) so the /32 is added. Other hosts already have access to postfix and icinga and do not need to be added explicitly because they are in the OVH OpenStack infrastructure.

We have a limited amount of security groups (100) and if we are to multiply the Enough instances, creating one security group per Enough instance would not work. What about we have security-groups specified for each host? Like so, in molecule.yml

  - name: postfix-host
    flavor: "s1-2"
    security-groups: [postfix]

The molecule/infrastructure/roles/firewall role would then create the designated security-groups, if they do not already exist. Enough instances would all have the same security-groups.

  - name: wereport-host
    flavor: "s1-2"
    security-groups: [website, enough]
  - name: cloud-host
    flavor: "s1-2"
    security-groups: [website, enough]
  - name: website-host
    flavor: "s1-2"
    security-groups: [website]

We could then have a firewall role for postfix (in molecule/postfix/roles/firewall) which could add postfix specific rules to the postfix security group. And we could have a firewall role for enough (in molecule/enough/roles/firewall) for all hosts running Enough.

I think it would make sense to have a security group infrastructure implicitly set for all hosts: they all need the ssh port open.

Note although we could, in theory, create and apply the security group after the VM is created, I think to remember it does not work. It’s worth checking because it would be more flexible.