CGI scripting and multiple processes

[erikharrison]

Alright, design question here. I've read up on security and whatnot for CGI scriting. The realization that CGI is hard has lead me to be wary of performing certain kinds of things with CGI scripting without asking the gurus first. Especially since I'm not messing with my own server, or even my own account on somebody elses server.

The situation: A CGI script makes little files with little bits of configuration information in them. The script can latter be invoked with this configuration info, through a proper request method. After a certain period of time the files expire and are deleted. The current system has every nth user get caught with the performance hit of doing a scan and delete of these config files.

The question: would it be legit (safe, reasonable, etc) to have every nth user fork a seperate process to do this sort of scanning, and have the parent go on without waiting for the child. I haven't worked alot with multiple processes, so it'd be helpful to hear what sort of considerations this kind of design must take.

Cheers,
Erik

Light a man a fire, he's warm for a day. Catch a man on fire, and he's warm for the rest of his life. - Terry Pratchet

[Zaxo]

That can be done, and may be a useful approach for some things, but I'd prefer doing that in a cron job.

If you schedule based on some hit counter, you add to the server load as traffic increases. Since your task involves disk access, it could be a severe bottleneck.

After Compline,
Zaxo

[rob_au]

Hrmm, while your approach would certainly work, I would hold some concerns as to the scalability of this approach under high server load. From the description of your problem you might do better to look at a caching solution which automatically encompasses this type of object expiry and clean-up - The Cache modules provide a means to perform just what you require, persistent data with a specific expiry time.

An example of usage which creates a Cache::FileCache cache in /tmp/cgi-data with a default expiry time of 15 minutes and auto-purge set (upon object retrieval) ...

use Cache::FileCache;

my $cache = Cache::FileCache->new({
    'cache_root'            =>  '/tmp/cgi-cache',
    'default_expires_in'    =>  900,
    'auto_purge_on_get'     =>  1
});
$cache->set( $key, $data );

.
.
.

$cache->get( $key );

The usage of the Cache modules is relatively straight-forward, incorporating clear and self-explanatory method names, and the provided documentation is excellent. I would strongly recommend having a look at this set of modules as this approach provides you with a pre-built method to implement data persistence with expiry without having to incorporate forking and clean-up within your script.

 

[rob_au]

To follow-up on this, I have just come across a new module on CPAN which may also suit this task, File::CacheDir - This module is touted as able to keep track and clean-up temporary files, quickly and without the use of a crontab. I have not however as yet had a chance to use this module or explore it in any detail.

 

[grep]

What is wrong with 'cron' (*nix), 'at' (NT 4), or 'Scheduled Tasks' (M$2000). These systems wait for a specific time of day and then perform a task.

If your real critierion for expiration is time, then a system that uses time instead of number of uses sounds more applicable



grep

Just me, the boy and these two monks, no questions asked.

[mothra]

The situation: A CGI script makes little files with little bits of configuration information in them.

Why not eliminate the problem altogether by using cookies? Is this a possible alternative in your situation?

[merlyn]

You really don't want cookies to contain anything other than a "branding" of the browser, for all the various reasons I list in my article on browser branding with cookies.

-- Randal L. Schwartz, Perl hacker

[breakwindows]

I don't like "anonymous" website visitors in a CGI script forking off pretty much anything. An oversight in your code or configuration could lead to a disaster (http://yourhost/script.cgi?MyConfig=/etc/passwd&Delete=Yes ;).

I would rather look to other options. Good alternatives have been mentioned, Cron/AT/TS for deleting the files or possibly using cookies set to expire instead of the little config files. YAOption is having your script ignore any file modified too long ago, using stat:



my $filename = "the_users_file";
my $usable_date = "some number";
my $Modified = (stat($filename))[9];
 if ($Modified > $usable_date) { ignore_it } else { continue_as_planne
+d }


There's also a File::stat module that can make things a little more readable, while performing the same basic task.
In my personal opinion, deleting files on your server is really a system administration issue, and should not be trusted to a 755 CGI script. From there, it gets pretty easy.

my $0.02; # Nothing more, nothing less.

[dsheroh]

Multiple processes don't really enter into your question. If it's safe to do A (your script's work) and B (delete old files) sequentially, it's also safe to do A and B simultaneously. (OK, race conditions could enter into it, but I'm assuming that you won't be using an expired config file while doing actual work.) While there are definitely security issues that need to be addressed, forking doesn't add any new ones.

That said, the previous responses were correct: Use cron or an equivalent instead of making your CGI do things unrelated to servicing the current request.