WMS:Design
Initial design ideas. Please discuss and add ideas in your own colour! Note your colour here:
Aragon
Mufasa
BMD
Contents
ROUTERBOARD API
| Purpose | URL | Returns |
|---|---|---|
| Fetch scripts | http://noc.ctwug.za.net/web/api/update?id=FID&serial=SERIAL&init=1 | All the scripts, including ctwug_version.rsc fetch script |
| Update NOC version info | http://noc.ctwug.za.net/web/api/temp?id=FID&serial=SERIAL | Done |
| Update NOC rb info | http://noc.ctwug.za.net/web/api/update?id=".$fid."&serial=".$fserial."&update=2&version=".$fver."&cpu=".$fcpu."&freq=".$fcpufreq."&arch=".$farch."&board=".$fboard."&fw=".$ffw."&ip=".$fip."&ospf=".$fospf."&policy=".$fpolicy | Version |
| Returns the scripts version | http://noc.ctwug.za.net/web/api/update?id=Dade-RB1&serial=205E01E11CB3&update=1 | Version |
| Returns the firewall script | http://noc.ctwug.za.net/web/api/firewall/firewall.rsc | The firewall script |
| Gametime indicator | http://noc.ctwug.za.net/web/api/gametime | 0 or 1 for gametime |
DB TABLES
user
| Field name | Field type | Constraints | FK? | PK? |
|---|---|---|---|---|
| id | int | not null, unique, auto-increment | N | Y |
| username | text | not null, unique | N | Y |
| password | password | not null, hashed with salt | N | N |
| created | date | not null, default CURRENT_TIMESTAMP | N | N |
| last_seen | date | not null, default CURRENT_TIMESTAMP | N | N |
| is_admin | boolean | not null, default false | N | N |
script_group
| Field name | Field type | Constraints | FK? | PK? |
|---|---|---|---|---|
| id | int | not null, unique, auto-increment | N | Y |
| name | text | not null | N | N |
script_type
| Field name | Field type | Constraints | FK? | PK? |
|---|---|---|---|---|
| id | int | not null, unique, auto-increment | N | Y |
| name | text | not null | N | N |
script
| Field name | Field type | Constraints | FK? | PK? |
|---|---|---|---|---|
| id | int | not null, unique, auto-increment | N | Y |
| name | text | not null, unique | N | N |
| script_group_id | int | not null, references script_group(id) | Y | N |
| script_type_id | int | not null, references script_type(id) | Y | N |
| script_body | text | not null | N | N |
| created_by | int | not null, references user(id) | Y | N |
| created | date | not null, default CURRENT_TIMESTAMP | N | N |
| version | int | not null, auto-increment | N | N |
| enabled | boolean | not null | N | N |
routerboard
| Field name | Field type | Constraints | FK? | PK? |
|---|---|---|---|---|
| id | int | not null, unique, auto-increment | N | Y |
| name | text | not null | N | N |
| ros_serial | text | not null, unique | N | Y |
| last_check_in_date | datetime | N | N |
routerboard_stats
| Field name | Field type | Constraints | FK? | PK? |
|---|---|---|---|---|
| id | int | not null, unique, auto-increment | N | Y |
| routerboard_id | int | not null, references routerboard(id) | Y | N |
| ... | text | not null, unique | N | Y |
routerboard_script_group
| Field name | Field type | Constraints | FK? | PK? |
|---|---|---|---|---|
| id | int | not null, unique, auto-increment | N | Y |
| routerboard_id | int | not null, references routerboard(id) | Y | N |
| script_group_id | int | not null, references script_group(id) | Y | N |
| assigned_by | int | not null, references user(id) | Y | N |
SCRIPTS
WMS will be script oriented, where scripts are almost like apps, and WMS is like an app market to/from which wuggers can share and run apps. Scripts would be written in whatever language their target architecture uses - ROS scripting for MT devices, Bourne shell and PHP for UBNT, etc. and WMS should have mechanisms to prevent scripts of ROS architecture from running on UBNT devices.
The scripts would also be fed through a server-side template processor, so that when a wugger assigns a script to run on his RBs, he can also define run parameters. The run parameters would be used by the template processor when serving the script up to the wugger's RB.
The script store I think should be centralised, but they'd be mostly static objects that could be easily cached and distributed. The reason for making it centralised is so that all wuggers can share to/from a common script pool, in the hope this drives scripting standards. Essentially the WMS "master" that hosts all the scripts would be a very small webapp that wouldn't do much, and so can be erected elsewhere quickly if the need arises.
WUGGER ACCESS
Wuggers would administer WMS by logging into their own local WMS "slave" server. The slave servers would query the central master for script information, but when it comes to defining run parameters and router devices, that gets done and stored on the slaves. When routers are added to WMS, they'd communicate with the slave local to their area/district.
SCRIPT EXECUTION
Each router device would need some kind of bootstrap manually loaded onto it, a script/app written for the device's architecture that polls WMS for work in a standard way. In the slave WMS interface, wuggers would assign script execution to routers by CIDR mask, and WMS should be able to handle cascaded definitions, for example:
Script "A" is assigned to 172.18.87.0/24 for execution with parameters "X". Script "A" is again assigned to 172.18.87.1/32 with parameters "Y", and script "B" assigned to 172.18.87.1/32 with parameters "Z". When 172.18.87.1 asks for work, it gets scripts A and B with parameters Y and Z respectively. When 172.18.87.2 asks for work, it gets script A with parameters X only.
Licensing of code/scripts contributed
Code committed to WMS and scripts added should be remain the property of the project and available to the devs without modifications. GPL ??
I agree - GPL2 all the way ;)
