Re: [lists] Re: [clo-devel] Getting clhp installed on Apache
Anthony Ventimiglia <anthony@ventimiglia.org> writes:
I've documented it pretty well in the INSTALL file, basically we need cmucl, asdf, apache, gcc and apxs (for building the module) apxs is part of apache, with the Debian system you'll need to $ apt-get install apache-dev to get apxs.
Ok, looks fairly straightforward. Any risk of this eating up all CPU or something like that? Erik.
Erik Enge writes:
Anthony Ventimiglia <anthony@ventimiglia.org> writes:
I've documented it pretty well in the INSTALL file, basically we need cmucl, asdf, apache, gcc and apxs (for building the module) apxs is part of apache, with the Debian system you'll need to $ apt-get install apache-dev to get apxs.
Ok, looks fairly straightforward. Any risk of this eating up all CPU or something like that?
I can say for the most part, no. They way it works right now is that mod_clhp fires a cmucl everytime it requests a page, and kills it after it's done, so the life of the Lisp process is fairly quick. I know this is not the most effiecient way to do it, but it is more secure in the respect that we won't get runaway processes. I eventually want to make it more persistant, but I have a few issues to work out before that can be done. The one caveat is that the code in the pages has to be written with no malicious intent. In other words someone who has access to the server and decides to try clhp can basically use anything available in CMUCL inside their pages. So if one of us were to say fork a process, or do something malicious, it could halt the server. But this is no more of a security concern as allowing a user to write CGI scripts in any language. Now as an option, you can set up apache so the clhp-handler will only work in specific directories, say just set it up so it works under /project/clhp/. That way only my pages could use it. It's really a matter of trust, do you trust all common-lisp developers to not write malicious code if they decide to use clhp? Now I would say none of us want to shutdown the server, so it should be safe. I'd like to see it eventually available site-wide, since it is quite an easy way to write dynamic web pages, and being that we're all Lispers, the rest of the site may like it. The error handling is somewhat primitive, it gives shoddy reports, but it runs in batch mode. So it ploghs through as many errors as possible and exits rather than entering the debugger. Either way, Apache kills it after the page requst is done, so even if it does enter the debugger, it will be killed. So from the design end, I don't see how it can run astray and bring down the server, of course only testing will prove that. So far I can just say that my LAN web server has been running CLHP for about a month with no problems. -- (incf *yankees-world-series-losses*)
On Thu, Nov 13, 2003 at 11:34:54AM -0500, Anthony Ventimiglia wrote:
Now as an option, you can set up apache so the clhp-handler will only work in specific directories, say just set it up so it works under /project/clhp/. That way only my pages could use it. It's really a matter of trust, do you trust all common-lisp developers to not write
Ok, I seem to have misunderstood. I though you wanted to just run it for yourself. And even for you it would IMHO need to run chrooted under clhp/public_html. I don't think we necessarily want to provide dynamic pages for projects in general. It IMHO increases the potential serverload far more then it benefits anyone. I'm kind of hoping we get slashdotted sooner or later, and that we survive it. ;) Those projects that have special needs may be provided for separately. Otherwise, my stance is that this is a production box with only a single part-time admin, so the less it is stressed the better. OTOH, maybe my paranoia is just acting up. Comments? Cheers, -- Nikodemus
Nikodemus Siivola writes:
On Thu, Nov 13, 2003 at 11:34:54AM -0500, Anthony Ventimiglia wrote:
Now as an option, you can set up apache so the clhp-handler will only work in specific directories, say just set it up so it works under /project/clhp/. That way only my pages could use it. It's really a matter of trust, do you trust all common-lisp developers to not write
Ok, I seem to have misunderstood. I though you wanted to just run it for yourself. And even for you it would IMHO need to run chrooted under clhp/public_html.
I don't think we necessarily want to provide dynamic pages for projects in general. It IMHO increases the potential serverload far more then it benefits anyone.
Those projects that have special needs may be provided for separately. Otherwise, my stance is that this is a production box with only a single part-time admin, so the less it is stressed the better.
OTOH, maybe my paranoia is just acting up. Comments?
Ok like I said, we can configure Apache so it is only usable in selected directories, not site-wide, there's no reason to chroot anything, it would be a lot of hassle for nothing. I think you're overestimating the load this will cause, all I can say is you should maybe download it and try it out to see how it works. It's in an early stage, and I'm not saying it's fit for a heavy load, but with the handful of hits /project/clhp gets daily, it's really not going to be noticable. -- (incf *yankees-world-series-losses*)
I'm answering to multiple mails here for the sake of convenience.
As far as the project goes, I consider it vital to have the home page actually running on a clhp back-end.
I'm probably missing something obvious here... but why? What kind of dynamic content do you need? Or do you mean vital in the sense of "prove it works"?
As far as the overhead for Erik, the installation is pretty straightforward,
I don't doubt this. But the only person who can gauge Erik's workload is Erik. Erik?
In my previous post I gave some of the potential problems, which are no more of a risk than running CGI scripts.
Very true. And unrestricted CGI is a Bad Idea on a production server with multiple projects. All it takes is one project with one mistake in one CGI script, and Common-lisp.net grinds to halt because the disk gets written full, or all the time is spent swapping, or an attacker uses the CGI to snoop the system, etc. On a single project website this is not that much of a problem: people can hurt themselves, but not others. Like Mario pointed out, this is why chrooting is *vital*. It's not about trust, but about security and robustness. And I'd add "running as nobody" and "cmhod -R o-w" to the list. ;)
As far as the infrastructure, I think that it would be a benifit to us all to have it available on the server. Sure we could use PHP to provide the same functionality, but I'd assume that most of us would rather use Lisp than PHP.
Very true. But then I don't think we should be offering PHP either, ;)
I'm not saying it's fit for a heavy load, but with the handful of hits /project/clhp gets daily, it's really not going to be noticable.
I'm not worried about anything as long as the number of hits is moderate. What I am worried about is what will happen when the number of hits increases. (Getting slahdotted being the worst-case scenario.) This is why I think only projects that actually need dynamic content on their pages should have the means for it. I'm not too interested in starting to differentiate between varieties of "need", as long as a clear case can be stated. Cheers, -- Nikodemus
-
Anthony Ventimiglia -
Erik Enge -
Nikodemus Siivola