Files
Gustavo Iñiguez Goia 66ee50bf7d tasks: allow to load tasks from disk
Now it's possible to load tasks from disk.

There's a central file which contains the defined tasks:
/etc/opensnitchd/tasks/tasks.json

with this format:
{
    "tasks": [
        {
            "enabled": false,
            "name": "downloader",
            "configfile":
"/etc/opensnitchd/tasks/downloader/downloader.json",
        }
    ]
}

The field "name" defines the type of task to load, defined in each task.
It's static.

Whenever the tasks.json is modified, if the tasks are enabled, the task
configuration file defined in the "configfile" field will be loaded.

Configuration format of each task:

{
  "name": "downloader",
  "parent": "downloader",
  "data": {}
}

The field "name" is dynamic, unique, and identifies the instance of the
task. If there're two tasks configured with the same name, only one will
be loaded.
The "parent" field is used to know what's the base task. If it's not
specified, we'll try to use the "name" as the base task.

This allows you to run multiple instances of the same task with
different configurations: a downloader to update malware blocklists,
another to update IP blocklists, etc.

The "data" field depends of each task. It's generic, and each task is
responsible for defining it. For example for the Downloader task:

"data": {
    "interval": "1h",
    "timeout": "5s",
    "urls": [
        {
            "name": "adaway",
            "enabled": true,
            "remote": "https://adaway.o/hosts.txt",
            "localfile": "/tmp/blocklist/ads-adaway-hosts.txt"
        }
    ]
}

The tasks configuration file are also monitored for changes, and
whenever a change is detected the task is reloaded.

----

Notifications (WIP)

It's not yet fully defined and it'll change, but this is the state as
of today.

For real-time tasks, like pid-monitor, sockets monitor and node monitor,
the GUI initiates the task with a unique ID (a timestamp), to know who
is sending what, and display the data properly on the GUI.

For permanent tasks we use a unique ID defined for each task.

Right now, if we don't have the notifications channel opened and the
notification ID corresponds with one of the tasks, we'll post an alert
to the GUI, to display a desktop notification.

Each task can define if send notifications or not. For example:

{
  "name": "downloader",
  "data": {
      (...)
      "notify": {
          "enabled": true
      }
  }
}

then in each task, act accordingly to what is defined in the
configuration.
2025-09-11 12:19:38 +02:00
..