No such thing as a small change | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
That's what "taint mode" is about, right? :)
Seems reasonable.
I still use mainly perl 5.8.8, but I don't plan any compatibility with 5.6 or older. It may works of course, but I won't even try.
That's natural. It will be somewhat self-contained. However It will use CPAN modules and not some strange weirdo version packaged inside like webmin does.
Mostly. I don't plan using anything but perl, but it will be using XS modules.
Sorry, no. I won't buy this one. There are too many fine webservers (even Perl ones). It won't be specific to any, but it won't carry one. For a start we'll work with SSL Apache2... I don't see the point of embedding a webserver, except maybe at a later stage for an easier quick and dirty deployment (but I'm too wary of "quick n' dirty" that lasts forever).
Yes, this is one of the first planned features :)
My main target right now is Linux. I don't see any reason why it wouldn't work on any distribution. For BSDs and Solaris, it will probably work but some modules (file sharing, network configuration, etc) will need an OS specific rewrite. However I'd rather have different modules for different OSes than "webmin style" modules, because it will make the code much simpler and cleaner.
Yes, this one is extremely important. We'll need an easy API to ease the way of anyone wanting to write a module. eBox is extremely good so I'll copy them shamelessly :)
Well I'll do my best :)
Right now it's still a matter of discussion with my team. I'm absolutely with you, but it's clear that making AJAX UIs that works flawlessly in links is a challenge. I still don't know how we'll sort this out; making a good, modern and easy to use interface is also a top priority. The interface should ALWAYS run as unprivileged user. A small, separate process should do the privileged work, and that process should not communicate with the browser. And that process is not invoked via the shell, but directly (i.e. NO system "command and parameters"), just to avoid nasty shell surprises. I'm eager to ear more for this one :) Right now I think the easiest thing to do is to use a "sudo" module, like eBox, but limits the unprivileged user (in /etc/sudoers) to execute one particular perl program, which will carry the privileged chores through an API (that limits somewhat what can and can't be done). Any other suggestion welcome... In reply to Re^2: Building a web-based system administration interface in Perl
by wazoox
|
|