Announcements > [x86] Announcements

Downtime tomorrow (July 14, 2008)

(1/6) > >>

iago:
Hey everybody,

I'm going to be swapping out the Web server tomorrow. I already have Apache and PHP installed on the new server, and I'm actually using it right now (hitting the same DB as the old server). So basically, I'm prepared to start the migration.

However, it's going to take some doing, and it's going to break stuff. I guarantee. So be prepared for a little downtime/instability tomorrow evening when I do it. I expect no more than ~30 mins of downtime, followed by a couple hours of instability (as I fix things I broke), and probably another week of minor instability as people report other broken things to me.

I'm hoping this goes smoothly. The biggest change is to security -- I will be using suphp on the new server, so everything will run in the context of its owner. That means that if somebody writes crappy code in their home directory (for example, if I upload something stupid to ~ron), it can't affect other sites on the server without a privilege escalation attack or similar. I'm also going to be making other changes that you probably won't notice.

The downside of using suphp is that PHP has to run as a CGI module instead fo an Apache module. That means it runs somewhat slower. When I first tried this, it was noticeably slower, but I upped the RAM dedicated to the Web server and now it's running the same as the old one. I guess it just likes having the extra RAM.

So yeah, expect downtime tomorrow, everything should be back to normal after that.

Camel:
If you look at the actual implementation in apache of how CGI interactions occur, you'll quickly understand why PHP became a module :)

iago:
Yeah, it's definitely understandable. But I'm willing to give up the performance gain for the added security of running scripts as their user rather than as apache.

It's odd that PHP doesn't have anything built in for that, yet...

Skywing:
Ouch.  Switching to CGI from a server module is painful.

I would make sure you have response time and CPU/memory usage graphs before and after so you'll have a baseline for how much of a performance degredation you are looking at.  (In my experience, it's been very severe.  I would not recommend it at all.)

In general, however, I would assume that any PHP code uploaded to the server can run native code, and thus simply not allow untrusted PHP code.  PHP is a mess; just look through bug reports with all the various heap corruption and other almost surely exploitable but not until somebody releases a proof of concept (for purposes of fixing them in a timely fashion, from the PHP team's perspective) problems.

I would stick with the apache module and not run untrusted PHP code, and let that be the end of it.

iago:
I do have graphs I can check, so I'll know. For the amount of traffic/weight of the apps, I'm not too worried. I wonder what hosting providers do to prevent others from looking at their code, though?

After talking to you, I think I'll install the main stuff as a module, and when others want an account or want to use code, I'll let them do it in the context of themselves.

Navigation

[0] Message Index

[#] Next page