This will list all the current jails on the system.
Output syntax is almost exactly the same as the listtemplates action:
{
"listjails":{
"jails:{
"jid_1":{
[same 10 fields: jid, uuid, boot, state, tag, type, release, ip4, ip6, template]
},
"jid_2":{
[same 10 fields]
}
}
}
}
This will list all the jail templates currently available on the local system.
Example Arguments Reply:
{
"listtemplates":{
"templates" : {
"template_1" : {
"jid" : "jail_id",
"uuid": "unique_id_string",
"boot": "on/off",
"state":"jail_state",
"tag":"jail_tag",
"type":"jail_type",
"release":"freebsd_release",
"ip4":"ipv4_address",
"ip6":"ipv6_address",
"template":"template_1"
}
}
}
}
This will list the current pool which is activated for iocage to use.
Example API return (arguments):
{
"activatestatus":{
"activated":"true",
"pool":"my_zpool"
}
}
Changelog: yes
De-activate the entire sysadm/iocage class of API calls. There is enough changes in the move to the new version of iocage, and the old API class was disused enough, that it is probably best to just scrap it and start from scratch.
I will start re-enabling the individual API calls one per commit tomorrow probably (backend changes getting close to being finished).
Also finish of the conversion of a bunch more backend funtions to work with the new version of iocage.
Add a new class: sysadm/moused
This class handles all the settings for the moused daemon on the system and provides per-device input device management.
First API "action":
"list_devices": This will list all the devices detected on the system with relevant information about them.
----------------
REST Request (example):
-------------------------------
PUT /sysadm/moused
{
"action" : "list_devices"
}
WebSocket Request:
-------------------------------
{
"id" : "fooid",
"namespace" : "sysadm",
"name" : "moused",
"args" : {
"action" : "list_devices"
}
}
Response:
-------------------------------
{
"args": {
"list_devices": {
"psm0": {
"description": "PS/2 Mouse",
"device": "psm0",
"driver": "psm",
"parent": "atkbdc0"
},
"ums0": {
"description": "YSTEK G Mouse, class 0/0, rev 1.10/0.01, addr 1",
"device": "ums0",
"driver": "ums",
"parent": "uhub1"
}
}
},
"id": "fooid",
"name": "response",
"namespace": "sysadm"
}
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"]
}
}
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.
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>"
}
}
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"
}
