Dashboard Plugin

From AuthPuppy Wiki

some of the features make sense for selected rages of time or other filters set

• Management of locations
  • list of locations
    • name/id
    • on/off
    • uptime/last seen
    • number of actual routers
    • number of actual clients
    • actual bandwith
    • total up/down traffic
    • geo data
    • contact person
    • contact email/phone,...
    • location address

• Management of devices
  • List of devices
    • name/mac/id
    • on/off
    • ip, gw, tunnel, bridge,...
    • uptime/last seen
    • number of actual clients
    • actual bandwith
    • total up/down traffic
  • Generate config for device and allow device to receive it (by polling)
    • root password
    • dhcp/static ip
    • firewall
    • wireless
    • network
    • ovpn
  • Send config update to device
  • reboot a device

• Management of clients
  • list of clients
    • name/mac/id
    • on/off
    • uptime/last seen
    • actual bandwith
    • total up/down traffic
    • vendor/model
  • allow/deny a client

Additions by gbastien

• Management of devices
  • Send wifidog config to device
  • Reboot wifidog process

How the plugin works

(as of bzr 6)

This plugin is very experimental. It has a database table containing the configs, not sure it actually works.

Every x time, the device gathers information about its processes, configurations, clients, etc and sends it (post) as an xml string to the auth server. That xml string is saved in the status_xml field of the file and that data is shown as dashboard data. The server answers this request with an xml string containing the configs and commands to the router. The router then acts on those status

Implication:

• XML is a standard format to communication between devices
• Device should have a good xml libray to encode/decode this string
• The scripts on the devices are OS dependent and can be very different from one to another. This is probably where most of the work will be.

Discussions:

• How to authentify device/auth server to avoid one knowing the right url to have access to the device's configs and avoid the device to receive data from a bad auth server
• What to send to the device?
  • A full xml with all the configs/info? But that is a lot of processing for the device
  • A diff of the config? Then the server has to process and compare what comes from the router every time
  • Have an extra table with "commands" for the device and answer only with those orders that are then deleted from the table? Could we miss something here? If a problem occurs and the order is not executed right, the server won't know next time the status comes in.