Creating a central controlpanel

[Magnusp]

Hi,
I´m using slackware 9.1 and I´m trying to build a controlpanel (via www) for some users where they can e.g. add pop accounts, change password, see their quota, password protect folders (htaccess) and so on.

I don´t want to put the files for the controlpanel in the users homedir, I want to have them on a central place to be easy to manage and update and so on.

How do I decide which user the script should run as? Some things should be run by the user who logged in through htaccess and some things have to be run by root (password change and so on).

I appreciate all tips!

Thanks!

Regards,

Magnus - Sweden

[SeanW]

Way back when I was involved in something similar... We ran the CGI as the web server (ie nobody), any requests for changes went in to a queue which was processed by a daemon or cron job running as root.

Have you looked into webmin, or any other existing projects?

Sean

[Magnusp]

Hi,
Thanks for Your answer.

I´ve been thinking about the same thing You said. Maybe I put every "command" the user does into a database and then with a perlskript in crontab check the database for changes. That would work. But what about things that could be run directly, e.g. htaccess creating. Then I want the script to be run as the user, is this possible?

One question, even if the perl scripts is installed in a central place I don´t want users to read my scripts. How do I protect my scripts as good as possible? I´ve tried perlcc and I now I can create C code with perl. I understand that I never can protect my scripts to 100% but I want to make it harder.

Regards,
Magnus

[SeanW]

I wouldn't put the commands directly into the database, if your CGI were broken somehow, someone could put in "rm -rf /"

Sean

[Magnusp]

Hi,
I can´t see the big different from putting the commands in a database or put them in a queue. It´s always a big risk to let root do something automatic.

Lets say You have one database:

One table, two columns:
command, username

command could be add_pop which tell the perl script to add an pop account (passwd, shadow and so on) and username could be foo (to tell who´s the "owner").
It must be the script that run automatic via crontab who checks the command against an hash with allowed commands and what to do with the specific command.

Am I completely out in the fog here?

Thanks again.

/Magnus

[SeanW]

I think you're on the right path.

I'd be more inclined to store an operation followed by a list of parameters, since depending on the operation, different amounts of information might be needed. For example

create_user name=fred password=abc123
delete_user name=fred
add_alias alias=[e-mail] dest=fred

The process parsing the queue (be it a flat file or a database or whatever) acts as a dispatcher, ie if the command is create_user it sends it off to the appropriate module and so forth.

Needing to match up allowed commands then isn't necessary, either the dispatcher knows how to handle an operation or it doesn't, the front end has no concept of unix commands.

This also allows you to abstract the larger operation from the implementation, ie if you moved to LDAP accounts, you want to be changing the backend, not the front end.

If you did it as a database you have a 1:N relationship between operations and parameters, so you'd need two tables, one to hold the operation, and one to store a list of the key-value pairs pointing back to the operation.

Now that I think of it, I'd probably implement the queue submission as a SOAP server with a flat file backend ;)

Sean