The script subsystem provides an abstract script management system to allow users to manage various types of automation scripts. The subsystem consists of a central repository with layered security and some amount of organization that allows for the definition of a script, based on a bunch of text. These scripts are then integrated to other areas to allow for their use.
ServerSide scripts would be supported. Scripts from the repository could be marked active so that they can be executed and results and history can be tracked against them. Executing these scripts would run them on the server in a potentially pluggable system. The base solution would use our CLI engine and interact with our "remote" published API to allow for complex management functionality automation.
AgentSide scripts would interact with the agent for execution of scripts on the remote managed box using on box facilities (i.e. bash, etc). The script subsystem would allow an activated agent side script to be attached to one or more resources so that their execution against a resource could be tracked against that resource. The script subsystem would have first class infrastructure for installation on to box and resource relationship management. Security against the execution would be tied to the core inventory resource.
Parameterization would also be supported. Scripts could be configured with "configuration-based" parameter inputs. Basically a simple set of config prop defs, defined by the user that become a set of question-answer values for execution. This section could also be useful for other future areas of parameter-switched automation (like provisioning). Scripts would also have access to the context in which their run (e.g. access to the related resource and its information).
For security of serverside scripts, we could support running the script as the user that created or managed it so that security of each operation in the script is also check properly.
- Can scripts be attached to groups?
- How are server side scripts secured and managed if not against specific resources (general scripts)?
- How is execution of scripts on box secured? Anyone who can run any remote script has a lot of power.
- Do we secure differently the ability to create a script vs. the ability to execute it
- Do we need fine-grained security on the scripts and resources (run the restart script, but not the format disk)
- Is there global and user specific scripts? Perhaps start as user, but click share to make public?
- Do we put scripts into the content system as "executable typed" packages?
- Is there a global repos view of scripts vs. a user's scripts?
- Audit and script results tracked against the relation between the target (resource/group) and the script
- Scheduling as a first class concept for scripts
- In UI script editing, uploading, etc.