Hi,
I have a feature request for some form of unraid API.
I have been using Unraid for along time now and was using with with esxi. Since v6 it has taken over as my host machine and I am doing more with it than ever.
I did notice there was a previous request for this in December 2014, Link, for an API but this was highlighted as not a priority at the time and given that unraid v6 was still in early beta stages this makes sense.
At the moment almost all the control requires ssh/telnet or web console access. This to me poses a potential security risk and think that an API might be able to provide access to some of the commonly used functions without providing access to all the system functions of unraid.
Some of the features that I would like to see in this this API are below:
Access token to bypass the basic authentication for API.
Possible multiple tokens with different access. example tokens, Global, Docker only, VM only, System only, Docker and VMs only, Plugins.... This could be managed via a webpage with automatically generated token but be able to be manually set or regenerated.
Some form of system/docker/vm overview that is easily obtained. I use Zeron's jsonvars plugin to provide me with information about the server for some of my home automation applications and monitoring. I also use SNMP and each has there own advantages.
Potentially make the API available for plugins to publish information.
Docker remote control. Ability to start/stop/restart containers would be the starting point. I am sure there would be other things that people might like to see.
VM remote control. Ability to start/stop/restart vm's would be the starting point. This might be a work around the physical power button problem that has been requested, for example an arduino, home automation system or even IFTTT could be used to send commands.
Unraid system control. Starting, stopping, powerdown, restart, start parity, spinup, spindown check etc. This should probably should be limited to non destructive system functions as to limit malicious/accidental control.
This may make it easier for third-parties to develop monitoring plugins or integration into automation systems.
There could be an option to provide some form of share control. I have recently become more Ransom-ware aware and have put in processes to try an limit damage in the event of an attack. Some of the suggestions on this forum are to change the user share from read-only to write when needed. An API could potentially change a share from read/write status of a share. The control of this could handled by the user in the form of a script or webpage etc.
Possibility to run command-line command/scripts. This goes against my non-destructive comment above but could be useful for anything not covered by the API. It probably should have it own API token.
There is the possibility that this may be able to be done as a plugin. It might be a good starting location but I still think an API should be part of the core unraid functionality.
I have noticed a few businesses/enterprises these days embracing API strategies, (example Telstra Australia) and they usually cite the collaboration, efficiency and development benefits. I have seen first-hand what having everybody developing their own backdoor/link to systems can have, especially on the inability to control system load and when trying to upgrade/change systems.
The development and documentation of an API is no small task but I think it might unlock some key development/features for the future of unraid.