8a16f9a4d0
This also adds some stand-alone CLI options to the sysadm-binary utility: "bridge_list": List any bridge connections in the settings file. Output Format: "name (url)" "bridge_add <name> <url>": Add a bridge connection to the settings with the given name. (if websocket server is running, this change will take effect within 5 minutes). "bridge_remove <name>": Remove a bridge connection from the settings. If a websocket server is running, this change will take effect within 5 minutes (closing the connection to the removed bridge as needed). There is also a new option in the global server config file: BRIDGE_CONNECTIONS_ONLY=[true/false] If true, this will allow the websocket server to run without listening on any ports, and instead force all traffic through the existing bridge connections.
Table of Contents generated with DocToc
SysAdm
Official repo for PC-BSD's sysadm middleware WebSocket & REST server
This middleware acts as the core for controlling a PC-BSD or FreeBSD
system either locally or remotely via WebSockets or REST. It is also the
server component to PC-BSD's SysAdm GUI client.
Required Qt Modules
Qt5 Core (pkg install qt5-core)
Qt5 Concurrent (pkg install qt5-concurrent)
Qt5 Websockets (pkg install qt5-websockets)
Building SysAdm
% git clone https://github.com/pcbsd/sysadm.git
% cd sysadm/src
% /usr/local/lib/qt5/bin/qmake -recursive
% make && sudo make install
Starting SysAdm
(For WebSockets - Required for SysAdm Client)
% sudo sysrc -f /etc/rc.conf sysadm_enable="YES"
% sudo service sysadm start
(Optional for REST)
% sudo sysrc -f /etc/rc.conf sysadm_rest_enable="YES"
% sudo service sysadm-rest start
API Documentation
Contributing new API calls
SysAdm is written using the Qt toolkit, which has excellent reference documentation.
All Qt Core classes (I.E. non-gui) can be used in SysAdm server.
Adding new API calls to the middleware is very straight-forward, simply
add a new function which accepts JSON in, and returns JSON, then connect
it to the backend.
Example:
4d3b590f46
Adding new Classes for API calls
Adding a new API class requires tweaking a few more files than a new API call only.
Example:
1ba65b3388
Testing new API calls / classes
Before committing or sending a pull request, you'll need to run our
"api-test.sh" script and confirm it works properly. To do so, first add
your new call and restart the websocket server. Next do the following:
% cd sysadm/tests
% ./api-test.sh
The api-test script will prompt you to enter username, password, and some
information about which class / API call to run. When that is done, and you
have verified the functionality of your new call you should add the output
of the test script (either from copy-n-paste, or from the file /tmp/api-response)
to your commit. (This will allow us to document the new call / class)