[ADD] dead_mans_switch_client, dead_mans_switch_server

[hbrunn]

Dead man's switch (server)

This module receives status messages by dead_mans_switch_client and notifies
you if a client instance is didn't check back in time.

As a side effect, you'll also get some statistical data from your client
instances.

Usage

Install dead_mans_switch_client on a customer instance and configure them as
described in that module's documentation. The clients will register themselves
with the server automatically. They will show up with their database uuid,
you'll have to assign a human readable description yourself.

At this point, you can assign a customer to this client instance for reporting
purposes, and, more important, add followers to the instance. They will be
notified in case the instance doesn't check back in time. Notification are only
turned on for instances in state 'active', instances in states 'new' or
'suspended' will be ignored.

You'll find the instances' current state at Reporting/Customer instances.

Known issues / Roadmap

• matching is done via the database's uuid, so take care to change this if you
  clone a database
• logging some postgres stats and disk usage would be nice too

Dead man's switch (client)

This module is the client part of dead_mans_switch_server. It is responsible
of sending the server status updates, which in turn takes action if those
updates don't come in time.

Configuration

After installing this module, you need to fill in the system parameter
dead_mans_switch_client.url. This needs to be the full URL to the server's
controller, usually of the form https://your.server/dead_mans_switch/alive

This module attempts to send CPU and RAM statistics to the server. While this
is not mandatory, it's helpful for assessing a server's health. If you want
this, you need to install psutil.

You can also have the currently online users logged, but this only works if
the im_chat module is installed.

Usage

This module doesn't have any visible effect on the client.

Known issues / Roadmap

• certificate pinning would be nice

[moylop260]

👍

[elicoidal]

Hi @hbrunn This contribution is awesome!
Please use simple headers following OCA templates
https://github.com/OCA/maintainer-tools/blob/master/template/module/__openerp__.py#L3

[elicoidal]

@hbrunn Thanks for this contribution! We will test it next week. We will probably propose a backport to v7 soon.

[elicoidal]

@hbrunn Out of curiosity, how do prevent possible DDOS on the server?
Is there a potential risk here? Technically AFAIU the code, knowing the URL is good enough to post
How to prevent it?

[hbrunn]

That bothered me too a bit, but then I figured nothing really bad happens as long as you can't guess a database uuid. uuid1 doesn't have too much entropy, but I think it's reasonable to rely on it for this purpose. Anyways, I added a few sentences about this issue: hbrunn@7be1aa3

[elicoidal]

True but even without uuid, DDOS is possible since you still need to analyze the posted lines to determine it.
I am not sure there a good protection at Odoo level though without making it complex.
Knowing the risk, you can insulate your server properly and secure it at nginx level to allow the trafic only from the selected IPs of your servers.

[hbrunn]

yes, classical ddos should indeed be handled by the proxy, not on application level

[hbrunn]

squashed all review and ci fixing commits

[hbrunn]

I configured runbut to monitor itself for review purposes: http://3135671-297-9b6c6b.runbot1.odoo-community.org/web?#view_type=kanban&model=dead.mans.switch.instance&menu_id=138&action=128

[lfreeke]

👍 (test)

[elicoidal]

👍 (tested)