"auto_update_reboot" = "0"-"23" (hour of the day)
If this is set (to a valid number), then SysAdm will automatically reboot the system to finish performing updates at the specified hour. Any other setting (or the value not being set) disables this option.
1) In the system manager "process info" function, use the -a flag for top so we get the whole command instead of just the first binary.
2)Cleanup a bit more of the backend of the new firewall manager.
Final action for the sysadm/firewall class: "action" = "reset-defaults"
This will reset all the firewall settings back to defaults and restart the firewall.
NOTE: This will only work on TrueOS - plain FreeBSD does not have any concept of default firewall settings and this API call will return an error in that case.
REST Request (example):
-------------------------------
PUT /sysadm/firewall
{
"action" : "reset-defaults"
}
WebSocket Request:
-------------------------------
{
"id" : "fooid",
"args" : {
"action" : "reset-defaults"
},
"namespace" : "sysadm",
"name" : "firewall"
}
Response:
-------------------------------
{
"args": {
"result": "success"
},
"id": "fooid",
"name": "response",
"namespace": "sysadm"
}
Add five new "actions" for managing the firewall:
"start" - turn on the firewall
"stop" - turn off the firewall
"restart" - reload the firewall (catches any settings changes - not generally needed)
"enable" - automatically start the firewall on bootup
"disable" - do not start the firewall on bootup
They all use the same input/output syntax, just the "action" input field is different
REST Request (example):
-------------------------------
PUT /sysadm/firewall
{
"action" : "restart"
}
WebSocket Request:
-------------------------------
{
"id" : "fooid",
"args" : {
"action" : "restart"
},
"namespace" : "sysadm",
"name" : "firewall"
}
Response:
-------------------------------
{
"args": {
"result": "success"
},
"id": "fooid",
"name": "response",
"namespace": "sysadm"
}
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).
