• Taint mode is just the first step. Each parameter should be validated as strictly as possible.

I've been thinking more about it. The main problem I see is that by definition, the administrative interface has to be able to do almost everything : modify base system files (/etc/hosts, /etc/passwd, /etc/resolv.conf etc.), start and stop daemons, run many different programs, partition drives, etc. That makes "whitelisting" command and parameters practically unmanageable.

• Perl 5.6 or even perl 5.005 should be no big problem unless you need Unicode. In that case, the minimum requirement should be perl 5.8.1.

Yes, however this is extremely low on my priority list. My main priority is to get something that works for common Linux systems, is clean and easy to extend. Other OSes come second; ancient stuff like Solaris 7 or IRIX I'll let to others :)

• "Own webserver" does not mean that you should write the 10.000th implementation of the server side of the HTTP protocol. But the HTTP server for the tool should be independant of any other parts of the system.

I want to make it webserver agnostic (this isn't hard, anyway). I plan to run the existing webserver ( apache for instance) with a special user and configuration. That's simple, and you can use any other webserver simply by using a different startup file in /etc/init.d/ or equivalent.

• OS compatibility: Just don't expect any system to behave like a linux system, or a specific linux distribution, and most things should just work. If you need external tools, don't expect them to work like GNU tools. Don't expect them to be in /usr/bin, don't expect the default shell to be a recent version of bash. Using different plugins for different OSes is a good idea, but for components like an Apache configurator, one tool should be able to handle all OSes. That means that pluigins need a configuration space, e.g. to set the location of apachectl and httpd.conf.

I'll be pragmatic. I'll stick as much as possible to Perl internals and core modules. However for external commands and shell, I'll try to stick to common basics. If necessary, I'll use bash or GNU core tools because they're readily available for any modern OS anyway. Of course, every module needs to have a site-specific configuration file.

• AJAX is nice for some enhancements, like auto-completion or maybe a pure-Javascript terminal. Restrict yourself to use Javascript only as an enhancement, not for basic functions, and you will get a "modern" interface which still works nicely in links, lynx, NN3, TV internet set-top boxes, and old smartphones. Valid and semantic (X)HTML and valid CSS would also be good for this purpose.

Usability + ease of use are first in the prerequisites. If necessary, modules may need an AJAX and a pure HTML version.

• sudo would also be my first tool for the privileged helper process, but as soon as we leave modern Linux distributions, sudo may disappear. On some distributions, sudo is still optional today.

Optional still means available. I don't see the point reinventing this wheel, I already have a carriage to build :)