From Annvix
This is a wish list list by Sean
Design Goals:
- Light Weight
- Not utilize much resources
- Not have too large (size & resources) of a tool chain or prerequisites
- Client/Server
- Able to have multiple frontends (cli, web, xml?)
- Ability to agregate across servers (ie, monitor from a central point)
- Will probably need some type of xml-rpc or soap
- Don't know about push or pull technology
Security
- Ipsvd for peer style acls
- sslsvd for encryption
- Assume localhost for initial ip
- Authenication
- http auth via web server (ie, no sessions or cookies)
- Multiple Users
- Different Permissions per user
- Two Versions with same base
- Read only, informational
- Read/Write, be able to modify existing system
- Needs to always utilize minimal priviledges to query or modify the system.
- Graphs
- Utilize bar graphs via image streaching
- SVG for line graphs (perfer on the fly generation, rather than local archival)
- Themable
- At a minimal have at least header & footer style themes, repo of colors, styles, etc
Multi-Lingual
- I don't know if there are any current users that require this support, we need to identify these users/languages and see if they would be willing to help translate.
- At a minimum stub it out so that it can easily be done; this might be easier with multiple frontends and seperation of display and logic.
Thoughts:
- Portcullis design
- Single point of entry
- Keeps Location/Screen
- Keeps State Stack
- Checks Permissions
- Might need to store screens in a tree like structure that is relatively fluid (b/c of the plugin system, and multi-level security)
- Executes Screen Handler
- Displays Screen (with themes, etc)
Plugin System:
I would imagine that these would be defined by software loaded (ie, rpms), if this is the case then we need the AWC to be installed at install
Would want a consistent directory structure for plugins, ie a directory for each rpm and/or subsystem.
I am also thinking of a subdirectory for each type of frontend {cli, web, etc}, navigation information {nav}, logic handler {server?}. I would also want a sub-directory under the frontend for any required resources (ie, images, css, etc).
The navigation sections needs to describe what is the security/auth category, screen title, parent screen, and any "tips" to the loader. On startup we will compare the list of plugin directories to a list of last run plugin directories, any modifications and we will regenerate the admin navigation tree. We would need to export the frontend resources to make them externally accessable (ie, symlink into webroot for web frontend). We potentially will have a race condition of adding or removing or upgrading awc -- we need to determine if we care or the handling of it ;-).
Backup/Restore (basic config info)
- List of all software(rpms) installed with dependency ordering
- A list of services enabled
- Will need the state (look for down file)
- Need the envdirs
- Need the peers directory
- Might try to get a list of all config files from rpms
- Might run an rpm's included a backup script that would try to produce a backup for other critical data (ie, a script that would dump a database, etc)
Random Thoughts:
Eval Lua(?)
Can we integrate with a data collector, maybe eval collectd?
