Design notes for a new Pyramid web interface

Configuration System

The current web interface has system commands interspersed with html code. While common with PHP, this makes maintenance difficult by requiring that you search for the system command portion of the code. Three options exist:

1. Break all system code into functions that contain no web code, the web code will call these functions and these will be stored in their own include file. What language to use? Obviously now we'd use php, but would we want a different interpreter?
2. Put an xml config file in as a middle layer. This removes system code from the front end altogether. Shell/python/etc scripts could be written to parse the config file and perform any changes. The front end would have to notify the back end of changes / execute it. It's possible for the backend to watch the file, but some technique would need to exist for the backend to only update the configurations that were new. Additionally the backend could scan the system configuration files for changed settings and update the xml configuration file, which is important as we wouldn't want manual configurations to be overridden by the front end. It would make cloning configurations and backing up configurations easier as rather than tarring up an entire box to ensure all config files are saved, one could just pull the xml file, and execute the back end on a cloned system.
   • M0n0wall Config File
   • XML too heavy? MiniXML? Maybe for 16MB, but for 64MB?
3. Use the first option, but use XML-RPC or something similar to allow other languages to execute the system functions. Not sure if this works, or how difficult it would be.

Front End

The goal is to make the system more flexible than what currently exists. The new system must not have "Changes applied, click here to return" type pages, that is, all changes should be in real time and preferably not require the page to be reloaded. The ideal solution is something AJAXy, ultimately including the statistics pages but a framework is the starting point. Mimicing something similar to Webmin is the target. The initial interface must contain all the current options, and provide flexibility for adding more.

1. Interfaces
   • Ethernet, including wireless. Separate page or AJAXy popup menu?
   • Wireless support must detect madwifi type interfaces (wifi0 and children such as ath0 ath1, support VAPs) as well as normal wireless interfaces (ethX).
2. System daemons
   • need: ssh, ntp, dyndns
   • want: syslog
   • Routing: olsrd
   • captive portals: wifidog, nocatsplash
   • port forwarding (dnsmasq?)
3. Informational
   • stats page
   • routing display (troubleshooting)