[pmwiki-users] Host concerns

[Patrick R. Michaud]

On Thu, Mar 29, 2007 at 07:42:10AM -0400, Dan Knight wrote:
>    I would like to use pmwiki for some in-house projects, but my host is
>    concerned about write permissions and runaway processes:
> 
>    "Is there a way it can run without having the webserver writing files to
>    your directory?  Or is that impossible?  I just hate to give the web
>    server any sort of ability to do that, for fear of runaway processes
>    filling up the drive, etc."
>
>    How do I answer him?

Well, the ability to fill up a drive is really somewhat unrelated to
writing files in a directory.  Even if PmWiki were using a database-backend
to store its data, a runaway process could *still* fill up a drive unless the
database imposed limits on table sizes.  (And the default settings on most
databases are such that the drive will fill up before the table maximums
are reached anyway.)  

So, it's not really a question of file-based storage versus other
formats -- *any* method of storing pages is going to use up disk space,
and a runaway process can fill up a drive unless there's something
in place to prevent it.

Most web hosting environments use disk quotas to protect against this, 
but I suspect your host isn't wanting to go there for some reason.  So,
let's frame the question slightly differently... does it occur?

I know of only one instance where PmWiki was in a "runaway" state
such that it consumed resources (cpu in this case), and there we were 
able to track the problem down to the operating system and not PmWiki 
itself [1].  Given PmWiki's long history (~5 years), it's not very 
common to find a runaway PmWiki process.

Even if PmWiki ever did get into a "runaway" state, it can't get very far 
because PHP imposes time limits on any given process (usually 30 seconds)
that prevents it from continuing indefinitely.

I also did a quick search of the mailing list archives for the terms 
"disk" and "full" -- only 26 messages were returned, and none
of them report PmWiki actually causing a disk full condition.  (Most of
them ask about PmWiki's performance when it encounters a disk full
or quota full condition caused by something other than PmWiki.)

I think this indirectly gets to the answer you want to give to your
host administrator:  PmWiki currently has thousands of installations
around the world, a great many of which are running on commercial web
hosting environments that have strict limits on resource utilization
such as disk space and cpu.  For many people, myself included, 
exceeding those limits would result in very real financial penalties, 
since web hosting services generally impose steep surcharges for that [2].

But since nobody seems to be reporting problems like this, that's a
really strong indication that it just doesn't happen.  And if it did,
I guarantee there'd be a fix for it right away.

Hope this helps,

Pm

References:
[1] http://thread.gmane.org/gmane.comp.web.wiki.pmwiki.user/6810 describes
    an issue where the OS diff(1) command was a runaway process.  Even in
    this case, PmWiki now no longer uses diff(1), so it wouldn't be an
    issue.

[2] My web hosting provider charges an extra $2.50/month for every 1GB of
    disk space used over my allocation.  

P.S.:  If disk usage is _really_ a sticking point for your host 
administrator, it wouldn't be too difficult to develop a cookbook recipe 
that would cause PmWiki to self-impose a quota on the total disk space it 
uses.

P.P.S.:  You may also be interested in
http://thread.gmane.org/gmane.comp.web.wiki.pmwiki.user/38406/focus=38429 ,
which is a discussion about whether PmWiki could be used by an attacker
to bring down an operating system (short answer: not likely).