Add a new class to sysadm: sysadm/firewall
This is the new firewall manager (ipfw), for setting options for the system firewall.
Initial API Call: "action":"known_ports"
This will return a list of all known ports and any names/descriptions for them (this is a static list - it does not reflect which ports are in-use or opened on the system. It is just for matching a port to a name/description)
REST Request (example):
-------------------------------
PUT /sysadm/firewall
{
"action" : "known_ports"
}
WebSocket Request:
-------------------------------
{
"id" : "fooid",
"namespace" : "sysadm",
"args" : {
"action" : "known_ports"
},
"name" : "firewall"
}
Response:
-------------------------------
{
"args": {
"1/tcp": {
"description": "#TCP Port Service Multiplexer",
"name": "tcpmux",
"port": "1/tcp"
},
"1/udp": {
"description": "#TCP Port Service Multiplexer",
"name": "tcpmux",
"port": "1/udp"
},
"100/tcp": {
"description": "#[unauthorized use]",
"name": "newacct",
"port": "100/tcp"
}
}
"id": "fooid",
"name": "response",
"namespace": "sysadm"
}
Last round of new "action"s for the sysadm/services class,
"action":"[enable/disable]"
Required input arguments:
"services":["service1","service2","etc"]
Exactly the same syntax as the start/stop/restart API calls, just a different action and the output field is "services_[enabled/disabled]" as well.
Add the "is_running" output field to the sysadm/services "list_services" output.
This also cleans up the is_enabled detection routine so it should be more reliable.
Add 3 new API calls (all almost the same - just different "actions" and the return message will be slightly different)
"action":"start" OR "stop" OR "restart"
This will [start/stop/restart] services on the system.
REQUIRED ARGUMENTS:
"services" : <string with a single service, or array of services>
EXAMPLE "start" command (change "services_started" in responce to "services_[started/stopped/restarted]" as needed to match the action:
REST Request (example):
-------------------------------
PUT /sysadm/services
{
"action" : "start",
"services" : [
"cupsd"
]
}
WebSocket Request:
-------------------------------
{
"args" : {
"action" : "start",
"services" : [
"cupsd"
]
},
"name" : "services",
"id" : "fooid",
"namespace" : "sysadm"
}
Response:
-------------------------------
{
"args": {
"services_started": [
"cupsd"
]
},
"id": "fooid",
"name": "response",
"namespace": "sysadm"
}
Modify the output fields for the sysadm/services, "list_services" action:
Now each service entry will look like this:
"accounting": {
"description": "",
"is_enabled": "false",
"name": "accounting",
"path": "/etc/rc.d/accounting",
"tag": "accounting_enable"
}
I will probably be adding an "is_running" [true/false] field here soon as well - the backend for that still needs to be written first.
Add a new API class/call to sysadm:
namespace: sysadm
name: services
This class is for managing all the background daemons on the system.
Initial API call:
args : {"action" : "list_services" }
This will return a list of all services available on the system.
*Note: return message shortened for example purposes - there are usually tons of services available
REST Request (example):
-------------------------------
PUT /sysadm/services
{
"action" : "list_services"
}
WebSocket Request:
-------------------------------
{
"args" : {
"action" : "list_services"
},
"id" : "fooid",
"namespace" : "sysadm",
"name" : "services"
}
Response:
-------------------------------
{
"args": {
"services": {
"accounting": {
"name": "accounting",
"tag": "accounting_enable"
},
"addswap": {
"name": "addswap",
"tag": "addswap_enable"
},
"amd": {
"name": "amd",
"tag": "amd_enable"
},
"apm": {
"name": "apm",
"tag": "apm_enable"
},
"apmd": {
"name": "apmd",
"tag": "apmd_enable"
},
"atm": {
"name": "atm",
"tag": "atm_enable"
}
}
},
"id": "fooid",
"name": "response",
"namespace": "sysadm"
}
Add a new action to the sysadm/users class: "groupmod"
This action allows for modifying a given group on the system
REQUIRED: "name"="<name of group to modify>"
and any one of these options is also required:
"users":["array of users"] (will set the list of users for this group)
"add_users":["array of users"] (will add the listed users to the current users)
"remove_users":["array of users"] (will remove the listed users from the current users)
Example API Request (JSON)
{
"id":"sample",
"namespace":"sysadm",
"name":"users",
"args":{
"action":"groupmod",
"name":"operator",
"users":["user1","user2"]
}
}
In the sysadm/users "action"="usershow" output, put a "canremove"="false" within the object of the currently-active user (so the client knows which user(s) cannot be removed right now). We might be able to extend this later on the server side to set that flag for *all* active users on the system instead.
Modify a couple sysadm/users API calls:
"action"="usermod":
Add in the optional PersonaCrypt arguments:
1) "personacrypt_init"="<device>" AND "personacrypt_password"="<password for device>"
This will initialize a personacrypt device and move the current home directory contents onto the device.
2) "personacrypt_import"="<base64-encoded contents of a PC key file>"
This will import an existing key for the designated user and allow a previously initialized device to be used for this user.
3) "personacrypt_disable"="<device password>"
This will disable the personacrypt key for this user, and merge any data from the device back onto the local system (if <device password> is valid/non-empty)
Add a new optional input argument to the sysadm/updates, "checkupdates" action:
"force":"[true/false]" (default is false)
This tells the check system to skip all previous checks for updates and re-run the update routines to look for new updates (if force==true), otherwise it might return the previous result of the update check if not enough time has passed since the other check.
Add a new field in the output args for the sysadm/updates check for updates:
"last_check":"<ISO date/time stamp>"
This returns the timestamp the last time a "full" check was performed (since some checks are flagged as quick/automatic and just re-use the previous check unless a significant amount of time has passed first - 12 hours is what it is set to right now).
This will look for any currently-running pc-updatemanager processes and kill/stop them as needed.
Example:
{
"id":"dummy",
"namespace":"sysadm",
"name":"update",
"args": {
"action":"stopupdate"
}
}
Output arguments:
"args":{
"stopupdate":{
"result":"success" or "error:<error text>"
}
}
Remove the "fbsdupdate" and "fbsdupdatepkgs" options within the sysadm-update API call for starting an update. These options are no longer available with base pkgs (everything is run through the "pkgupdate" option instead).
Add a new API call: sysadm/users, action=personacrypt_listdevs
This will run personacrypt and return any removeable devices which may be used as PC devices.
REST Request (example):
-------------------------------
PUT /sysadm/users
{
"action" : "personacrypt_listdevs"
}
WebSocket Request:
-------------------------------
{
"namespace" : "sysadm",
"name" : "users",
"id" : "fooid",
"args" : {
"action" : "personacrypt_listdevs"
}
}
Response:
-------------------------------
{
"args": {
"da0": "<SanDisk Cruzer 1.26> 7.5G"
},
"id": "fooid",
"name": "response",
"namespace": "sysadm"
}
Add new "usermod" action to the sysadm/users class. This is nearly identical to the "useradd" action, but performs changes to an existing user only (limited access users may modify their own settings, but not other users settings).
Additional OPTIONAL input: "newname" change the username to this instead.
REST Request (example):
-------------------------------
PUT /sysadm/users
{
"action" : "usermod",
"comment" : "somecomment",
"name" : "test2"
}
WebSocket Request:
-------------------------------
{
"name" : "users",
"namespace" : "sysadm",
"args" : {
"name" : "test2",
"comment" : "somecomment",
"action" : "usermod"
},
"id" : "fooid"
}
Response:
-------------------------------
{
"args": {
"result": "success"
},
"id": "fooid",
"name": "response",
"namespace": "sysadm"
}
Add a new API call to the sysadm/users framework as well as add a bunch more output to current users requests (error/success reporting instead of just the overall good/bad flag).
New API call: "action":"userdelete"
REQUIRED: "name":<username>
OPTIONAL: "clean_home"="true/false" (default is "true")
REST Request (example):
-------------------------------
PUT /sysadm/users
{
"name" : "test",
"action" : "userdelete"
}
WebSocket Request:
-------------------------------
{
"id" : "fooid",
"name" : "users",
"args" : {
"action" : "userdelete",
"name" : "test"
},
"namespace" : "sysadm"
}
Response:
-------------------------------
{
"args": {
"result": "success"
},
"id": "fooid",
"name": "response",
"namespace": "sysadm"
}
