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). _______________________________________________ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
