I am considering a strategy for migrating a server from Apache to Nginx (I've never used nginx before so I'll be doing all this on a test box first).
The strategy is something like: install nginx alongside apache but using (say) port 81. Configure all the virtual hosts so that if <url> works now (on Apache), <url>:81 should also work on nginx, running concurrently. Test. (The idea is to get customers to do some final checks on their own sites, so this should work with minimum fuss.) When ready, kill apache and switch the port over on nginx.
All the sites are running PHP/MySQL (except for a few static sites).
Aside from making sure I have enough RAM to run both alongside each other, any reason to avoid this approach?
On Tue, 5 Mar 2013 13:00:32 +0000 Mark Rogers mark@quarella.co.uk allegedly wrote:
I am considering a strategy for migrating a server from Apache to Nginx (I've never used nginx before so I'll be doing all this on a test box first).
Presumably you are considering that for performance reasons? If so, have you also considered lighttpd?
Mick ---------------------------------------------------------------------
blog: baldric.net gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312
---------------------------------------------------------------------
On 5 March 2013 13:59, mick mbm@rlogin.net wrote:
Presumably you are considering that for performance reasons? If so, have you also considered lighttpd?
Yes to the first question, not really to the second.
I'm open to suggestions to be honest - Apache is just a resource hog in my experience and I think it's time I got to know something else. I have marginally more experience of nginx (in that I looked into doing this a while ago and have some idea what the configuration is like) but no real preference at this stage.
On Tue, 5 Mar 2013 18:02:42 +0000 Mark Rogers mark@quarella.co.uk allegedly wrote:
On 5 March 2013 13:59, mick mbm@rlogin.net wrote:
Presumably you are considering that for performance reasons? If so, have you also considered lighttpd?
Yes to the first question, not really to the second.
I'm open to suggestions to be honest - Apache is just a resource hog in my experience and I think it's time I got to know something else. I have marginally more experience of nginx (in that I looked into doing this a while ago and have some idea what the configuration is like) but no real preference at this stage.
I haven't used apache for well over a decade now. I have no experience of nginx, but I do use lighttpd. It is very efficient on really small devices. I have it on 3 Linksys NSLU2s (32 MB RAM), a Sheevaplug (512 MB) plus 4 VMs (only one of which has more than 512 MB RAM). My blog runs on a standard wordpress LAMP stack but with lighttpd instead of apache.
Mick
---------------------------------------------------------------------
blog: baldric.net gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312
---------------------------------------------------------------------
On 05 Mar 13:00, Mark Rogers wrote:
I am considering a strategy for migrating a server from Apache to Nginx (I've never used nginx before so I'll be doing all this on a test box first).
Why are you wanting to migrate to nginx? I've seen many instances of nginx falling over and then not being able to be restarted cleanly, leading to all manner of fun.
Where you using mod_php in apache? Are you planning on using the same system in nginx? i.e. you're still not seperating users from each other and you still have all the issues of php to deal with, except now you're in a less tested environment with a relatively young and unproven webserver.
The strategy is something like: install nginx alongside apache but using (say) port 81. Configure all the virtual hosts so that if <url> works now (on Apache), <url>:81 should also work on nginx, running concurrently. Test. (The idea is to get customers to do some final checks on their own sites, so this should work with minimum fuss.) When ready, kill apache and switch the port over on nginx.
Customers tend not to test things, no matter how nicely you ask them. What actually happens is that they say "yeah, that's all fine!", then 2 weeks after you've changed things they go "oh, hang on, this bit is broken, and this, and this..."
All the sites are running PHP/MySQL (except for a few static sites).
So, erm, the only thing that nginx is supposedly better at than apache is serving static sites... not a lot of yours are... erm... why are you moving to it again? (Please, don't tell me it's because "I heard of nginx and someone told me it was cool!")
Aside from making sure I have enough RAM to run both alongside each other, any reason to avoid this approach?
Only as outlined above - i.e. why fix something that isn't broken.
Cheers,
On 6 March 2013 09:20, Brett Parker iDunno@sommitrealweird.co.uk wrote:
Why are you wanting to migrate to nginx? I've seen many instances of nginx falling over and then not being able to be restarted cleanly, leading to all manner of fun.
Interesting, this isn't something I was aware of.
I've only heard good things about nginx. Maybe I look in the wrong places!
Where you using mod_php in apache? Are you planning on using the same system in nginx? i.e. you're still not seperating users from each other and you still have all the issues of php to deal with, except now you're in a less tested environment with a relatively young and unproven webserver.
No, the plan is to move to FGM. This is one of the motivations for the move, although FastCGI isn't limited to nginx.
Customers tend not to test things, no matter how nicely you ask them. What actually happens is that they say "yeah, that's all fine!", then 2 weeks after you've changed things they go "oh, hang on, this bit is broken, and this, and this..."
Don't get me wrong, all sites would get a proper amount of testing by me too. By "proper" I mean extensive for commercial sites but rather less for the handful of "freebies" that always seem to accumulate... The server in question is mostly either internal or personal stuff so a failure is not critical - I wouldn't use anything I didn't know in a production environment for important sites and this exercise was partly about trialling something new, and partly about learning it's quirks so that if we do use it production at a future date I know it well enough to do so.
So, erm, the only thing that nginx is supposedly better at than apache is serving static sites... not a lot of yours are... erm... why are you moving to it again? (Please, don't tell me it's because "I heard of nginx and someone told me it was cool!")
I heard of nginx and, er, hmmm....
However, yes nginx touts static as a major strength (although lets be fair: even a heavily PHP based site will still likely be serving substantial amounts of images and Javascript/CSS files so static performance is always relevant).
My biggest concern is the memory usage of Apache; in recent months I've had several issues due to running out of RAM on systems that really ought not have an issue, and memory footprint is my prime motivation for looking at alternatives. Yes, Apache can be tuned (and largely this is something I haven't done), but fundamentally the event model seems better than the options that Apache (2.2) gives me. To be fair I have no knowledge of the event model used by Apache 2.4 (I didn't know it existed until yesterday) but that would also trip a lot of the "relatively young and unproven" tests.
Aside from making sure I have enough RAM to run both alongside each other, any reason to avoid this approach?
Only as outlined above - i.e. why fix something that isn't broken.
Because what I have now is broken, ie it's not stable due to memory requirements. Every time I've had a major issue the logs have suggested that Apache caused the system to run out of memory. Don't get me wrong: I'm not just assuming that Apache is the underlying problem here, as it's likely to be the code that Apache is running (via mod_php or whatever) that is the real culprit. But it has prompted me to look at alternatives, and until now I'd not heard a bad word said against nginx.
Aside: Another motivation is that we do a lot of work with ARM based systems which rarely have more than 512MB (think Raspberry Pi sort of spec). We usually end up with Apache on these systems because it's what we know, but I really think that nginx/lighttpd/other would be a better fit when resources are tight.
On 06 Mar 10:23, Mark Rogers wrote:
On 6 March 2013 09:20, Brett Parker iDunno@sommitrealweird.co.uk wrote:
Why are you wanting to migrate to nginx? I've seen many instances of nginx falling over and then not being able to be restarted cleanly, leading to all manner of fun.
Interesting, this isn't something I was aware of.
Serving statics on ftp.uk.debian.org actually was one of the things that we've watched it die from... ;)
I've only heard good things about nginx. Maybe I look in the wrong places!
There's plenty of people that love it, I just ain't one of 'em... which means that when I do hear bad things, I tend to remember 'em :)
(Also, I kinda like the sheer flexibility I've got with apache, so, erm... yeah :)
Where you using mod_php in apache? Are you planning on using the same system in nginx? i.e. you're still not seperating users from each other and you still have all the issues of php to deal with, except now you're in a less tested environment with a relatively young and unproven webserver.
No, the plan is to move to FGM. This is one of the motivations for the move, although FastCGI isn't limited to nginx.
Do you mean FPM? As in PHP-FPM? But anyways - that's just fastcgi, really... and for that I'd use mod_fcgid, a small wrapper script, mod_suexec, and a seperate small wrapper script for each user (the wrapper script potentially sets various envvars and ulimits, maybe even chroots them in to a new and interesting place).
Customers tend not to test things, no matter how nicely you ask them. What actually happens is that they say "yeah, that's all fine!", then 2 weeks after you've changed things they go "oh, hang on, this bit is broken, and this, and this..."
Don't get me wrong, all sites would get a proper amount of testing by me too. By "proper" I mean extensive for commercial sites but rather less for the handful of "freebies" that always seem to accumulate... The server in question is mostly either internal or personal stuff so a failure is not critical - I wouldn't use anything I didn't know in a production environment for important sites and this exercise was partly about trialling something new, and partly about learning it's quirks so that if we do use it production at a future date I know it well enough to do so.
Fair enough - I'd suggest waiting for the apache2-event-mpm to become more stable if you really want to use an event based webserver...
So, erm, the only thing that nginx is supposedly better at than apache is serving static sites... not a lot of yours are... erm... why are you moving to it again? (Please, don't tell me it's because "I heard of nginx and someone told me it was cool!")
I heard of nginx and, er, hmmm....
However, yes nginx touts static as a major strength (although lets be fair: even a heavily PHP based site will still likely be serving substantial amounts of images and Javascript/CSS files so static performance is always relevant).
Most of which, if it's an even remotely busy site, will be in the filesystem cache, and once there, apache is going to be able to serve them fairly much as quickly anyways....
My biggest concern is the memory usage of Apache; in recent months I've had several issues due to running out of RAM on systems that really ought not have an issue, and memory footprint is my prime motivation for looking at alternatives. Yes, Apache can be tuned (and largely this is something I haven't done), but fundamentally the event model seems better than the options that Apache (2.2) gives me. To be fair I have no knowledge of the event model used by Apache 2.4 (I didn't know it existed until yesterday) but that would also trip a lot of the "relatively young and unproven" tests.
Have you got limits set in PHP? Are large files being uploaded? Could it be that there's a bad PHP script that's leaking all over the place, and using a frequently restart fastcgi script would limit the problems?
Aside from making sure I have enough RAM to run both alongside each other, any reason to avoid this approach?
Only as outlined above - i.e. why fix something that isn't broken.
Because what I have now is broken, ie it's not stable due to memory requirements. Every time I've had a major issue the logs have suggested that Apache caused the system to run out of memory. Don't get me wrong: I'm not just assuming that Apache is the underlying problem here, as it's likely to be the code that Apache is running (via mod_php or whatever) that is the real culprit. But it has prompted me to look at alternatives, and until now I'd not heard a bad word said against nginx.
OK - so, I'd be switching to a mod_fcgid based php setup, and limiting the resources that apache uses. We recently had an issue with mod_python (*sigh* - we are moving to mod_wsgi, and the world is becoming better, but first we have to get rid of the legacy crap...).
So, what one can do is limit the overall memory for a process, what I use here is (in /etc/default/apache2):
ulimit -v 1048576
Which means that each apache process can only use up to 1G of memory (yes, that's a ridiculous amount, and I'd much rather it was much less)...
Then, instead of your server falling over and dying in a messy heap, apache goes "bum, that went wrong" and closes down that thread and fires up a new one (whilst returning a memory error to whatever was looking at the page that caused the issue).
Aside: Another motivation is that we do a lot of work with ARM based systems which rarely have more than 512MB (think Raspberry Pi sort of spec). We usually end up with Apache on these systems because it's what we know, but I really think that nginx/lighttpd/other would be a better fit when resources are tight.
Depends what you're serving from the Pi, really. But nginx wouldn't be my choice for a pi... lighttpd, maybe, perhaps. Boa, maybe too. But I'd be looking that end for anything simple, not fully functioning web stacks, but small "good enough" stacks.
Cheers,
On 6 March 2013 11:01, Brett Parker iDunno@sommitrealweird.co.uk wrote:
Serving statics on ftp.uk.debian.org actually was one of the things that we've watched it die from... ;)
When was that (ie was it a while back and things could have improved)?
Since your first comment I've done quite a lot more Googling, and the conclusion seems to be: - the number of people saying nginx is better than Apache outweighs the reverse - a lot of people talking about memory leaks in lighttpd, and in general more people favouring nginx - a lot of issues in nginx with PHP pre FPM, but a general consensus that nginx with FPM is "great". - a lot of people talking about stability issues with Apache due to running out of memory (ie my problem), and that things have been better since they switched.
Of-course everyone has an anecdote, and one from someone I "know" (ALUG counts :-) carries more weight.
Do you mean FPM? As in PHP-FPM? But anyways - that's just fastcgi, really... and for that I'd use mod_fcgid, a small wrapper script, mod_suexec, and a seperate small wrapper script for each user (the wrapper script potentially sets various envvars and ulimits, maybe even chroots them in to a new and interesting place).
Yes, FPM, that's what I typed, the keyboard just had other ideas :-)
"Most people" still use Apache with mod_php though, don't they? Which means Apache with FastCGI has many of the same "fewer people use it" arguments against it as nginx. Mind you, if "fewer people use it" was a big factor I'd have a Windows desktop... (Aside: It read that Nginx now has the number 2 web server spot, having overtaken IIS? Still only about 10% compared with 5/6x that for Apache though.)
Fair enough - I'd suggest waiting for the apache2-event-mpm to become more stable if you really want to use an event based webserver...
However long I wait, nginx will have been doing it longer than Apache. A bigger issue is that running Apache 2.2 and Apache 2.4 alongside each other on the same server isn't as easy.
Most of which, if it's an even remotely busy site, will be in the filesystem cache, and once there, apache is going to be able to serve them fairly much as quickly anyways....
None of my sites are remotely busy, to be honest. All the more reason Apache shouldn't struggle for RAM. I think getting hit by search engine spiders is the biggest demand it faces.
Have you got limits set in PHP?
Yes. Not finely tuned though.
Are large files being uploaded?
No. Large memory processes tend to be badly written sitemap generators on sites with lots of products, etc.
Could it be that there's a bad PHP script that's leaking all over the place, and using a frequently restart fastcgi script would limit the problems?
Yes, although likely not leaking as such, just inefficient. The sort of code that does a "SELECT * FROM table" and builds an array from the results, regardless of whether that's 100 or 100k results it has to hold in memory.
OK - so, I'd be switching to a mod_fcgid based php setup, and limiting the resources that apache uses.
Assuming I go this route, [how] can I migrate an existing server virtual host by virtual host?
Depends what you're serving from the Pi, really. But nginx wouldn't be my choice for a pi... lighttpd, maybe, perhaps.
I pretty much expect to be able to do on the Pi whatever I do on anything else, mainly because starting with that assumption hasn't caused me any major headaches so far!
That's two suggestions I should look at lighttpd in this thread, so that's something I will do.
But, returning to the original post: any reason why I can't install (lighttpd|nginx) alongside Apache (on a different port) and dual-run for a period of time? Memory constraints permitting of-course.
On 06 Mar 11:42, Mark Rogers wrote:
On 6 March 2013 11:01, Brett Parker iDunno@sommitrealweird.co.uk wrote:
Serving statics on ftp.uk.debian.org actually was one of the things that we've watched it die from... ;)
When was that (ie was it a while back and things could have improved)?
Within the last 6 months...
Since your first comment I've done quite a lot more Googling, and the conclusion seems to be:
- the number of people saying nginx is better than Apache outweighs the reverse
A lot of them also aren't serving any thing large, or have long running php processes... the event model is fine, except in those cases... then it can get "interesting".
- a lot of people talking about memory leaks in lighttpd, and in
general more people favouring nginx
lighttpd isn't my favourite, and I wouldn't run it on anything internet facing... but then, I wouldn't expect the Raspberry PI to be internet facing...
- a lot of issues in nginx with PHP pre FPM, but a general consensus
that nginx with FPM is "great".
Apparently FPM is now part of the standard PHP build, so maybe it'll eventually properly replace the old fastcgi module they had... who knows. Either way, PHP is generally a PITA...
- a lot of people talking about stability issues with Apache due to
running out of memory (ie my problem), and that things have been better since they switched.
And if you're running the same PHP in the same way under nginx you'll have the same issue...
Of course, you're not going to do that, as nginx doesn't have a mod_php... So, not even a like for like comparison... and all the posts that claim nginx to be faster and more stable also say they switched from apache and mod_php! Apples, meet Oranges.
Of-course everyone has an anecdote, and one from someone I "know" (ALUG counts :-) carries more weight.
Do you mean FPM? As in PHP-FPM? But anyways - that's just fastcgi, really... and for that I'd use mod_fcgid, a small wrapper script, mod_suexec, and a seperate small wrapper script for each user (the wrapper script potentially sets various envvars and ulimits, maybe even chroots them in to a new and interesting place).
Yes, FPM, that's what I typed, the keyboard just had other ideas :-)
"Most people" still use Apache with mod_php though, don't they? Which means Apache with FastCGI has many of the same "fewer people use it" arguments against it as nginx. Mind you, if "fewer people use it" was a big factor I'd have a Windows desktop... (Aside: It read that Nginx now has the number 2 web server spot, having overtaken IIS? Still only about 10% compared with 5/6x that for Apache though.)
Depends on the difinition of "most people"... If most people is people that set up their own hosting and aren't security focused and do trust mod_php (or are, infact, the only people hosting at all on that server), then yes, it's still the most common way of running PHP... However, I can't remember the last sysadmin I've encountered that would consider running PHP in anything other than a fastcgi environment as a seperate user from the web server, and as locked down as they could make it...
Fair enough - I'd suggest waiting for the apache2-event-mpm to become more stable if you really want to use an event based webserver...
However long I wait, nginx will have been doing it longer than Apache. A bigger issue is that running Apache 2.2 and Apache 2.4 alongside each other on the same server isn't as easy.
Erm, it certainly used to be easy enough to run multiple version of apache in parallel...
But, anyways - I'm still not convinced that event driven web serving is any better for the interesting work loads that a PHP driven site can do, and I don't think it's any good for large file serving, but hey :)
Most of which, if it's an even remotely busy site, will be in the filesystem cache, and once there, apache is going to be able to serve them fairly much as quickly anyways....
None of my sites are remotely busy, to be honest. All the more reason Apache shouldn't struggle for RAM. I think getting hit by search engine spiders is the biggest demand it faces.
I'd have been trying to tie the breakages in with the apache logs, really... but meh, whatever! :)
Have you got limits set in PHP?
Yes. Not finely tuned though.
Still, mod_php is leaky even with it's limits set, so I'd advise the /etc/defaults/apache2 setting as per earlier post.
Are large files being uploaded?
No. Large memory processes tend to be badly written sitemap generators on sites with lots of products, etc.
Right - so, erm, a coding issue, which is only going to be "magically" fixed because the fastcgi processes will be restarted after a certain number of requests...
Could it be that there's a bad PHP script that's leaking all over the place, and using a frequently restart fastcgi script would limit the problems?
Yes, although likely not leaking as such, just inefficient. The sort of code that does a "SELECT * FROM table" and builds an array from the results, regardless of whether that's 100 or 100k results it has to hold in memory.
I know those ones all too well, but apparently maiming developers is frowned upon... I don't know why!
OK - so, I'd be switching to a mod_fcgid based php setup, and limiting the resources that apache uses.
Assuming I go this route, [how] can I migrate an existing server virtual host by virtual host?
Setup a second virtual host with the other port number, remember to use the Listen and NameVirtualHost directives for the other port... setup the required wrappers and SuExec directives, done...
Depends what you're serving from the Pi, really. But nginx wouldn't be my choice for a pi... lighttpd, maybe, perhaps.
I pretty much expect to be able to do on the Pi whatever I do on anything else, mainly because starting with that assumption hasn't caused me any major headaches so far!
I'd class the Pi as embedded kit, it hasn't got that much in the way of power, and thus although I *could* treat it as Just Another Box, I'd be looking to use the lowest footprint software possible unless some bit of functionality is required.
That's two suggestions I should look at lighttpd in this thread, so that's something I will do.
I've seen a fair few holes in lighttpd, I don't actually recommend it for anything facing the general internet, but it is small...
But, returning to the original post: any reason why I can't install (lighttpd|nginx) alongside Apache (on a different port) and dual-run for a period of time? Memory constraints permitting of-course.
Absolutely none. Why would there be?
On 6 March 2013 13:09, Brett Parker iDunno@sommitrealweird.co.uk wrote:
Apparently FPM is now part of the standard PHP build, so maybe it'll eventually properly replace the old fastcgi module they had... who knows. Either way, PHP is generally a PITA...
No argument there!
- a lot of people talking about stability issues with Apache due to
running out of memory (ie my problem), and that things have been better since they switched.
And if you're running the same PHP in the same way under nginx you'll have the same issue...
True. Although the memory footprint it starts with is considerably bigger, and on a low memory system that is always a mark against Apache.
Of course, you're not going to do that, as nginx doesn't have a mod_php... So, not even a like for like comparison... and all the posts that claim nginx to be faster and more stable also say they switched from apache and mod_php! Apples, meet Oranges.
Fair comment. Which is why I'd certainly consider Apache+FastCGI as an alternative.
However, I can't remember the last sysadmin I've encountered that would consider running PHP in anything other than a fastcgi environment as a seperate user from the web server, and as locked down as they could make it...
This is the direction I'm heading in. To be fair, whilst I have seen issues in the past with code uploaded and run as the Apache user, I've not yet seen it "travel" outside the docroot of the affected (infected) vhost. Generally, I like to think that my own code is also fairly robust, but increasingly it's the "standard" packages that have thrown issues at me and FastCGI would make me a lot happier.
However, I've spent some time playing with nginx this afternoon, and I have to say that the biggest PITA so far as been working with FastCGI (in which I have little experience), so I'm not looking forward to either route.
Erm, it certainly used to be easy enough to run multiple version of apache in parallel...
Something I should have mentioned: I don't put any build tools on my servers and I rely on the O/S provider to manage security patches, which means that unless I can: apt-get install apache-2.2 apache-2.4 .. it's going to be hard, and since they likely wouldn't want to share config directories anyway... From that point of view installing Apache and Nginx alongside each other is rather easier.
But, anyways - I'm still not convinced that event driven web serving is any better for the interesting work loads that a PHP driven site can do, and I don't think it's any good for large file serving, but hey :)
What would it take to convince you? Today's research hasn't found anything that contradicts this position, putting 2.4 (event) ahead of 2.2 but behind nginx performance-wise. Every benchmark I found had flaws so i wouldn't put any forward as "proof" but it certainly felt like the general consensus pointed that way.
(I'm not arguing the case for it myself!)
I'd have been trying to tie the breakages in with the apache logs, really... but meh, whatever! :)
Been there done that - or rather not found anything which ties the problem even to a single virtual host, never mind a single script.
No. Large memory processes tend to be badly written sitemap generators on sites with lots of products, etc.
Right - so, erm, a coding issue, which is only going to be "magically" fixed because the fastcgi processes will be restarted after a certain number of requests...
Not at all :-)
Certainly I don't have the time to go fixing coding issues in third party code, but I started down this route after research suggested that nginx generally made a better hash of things. I've not been completely convinced otherwise by your arguments but I'm certainly wavering! At the end of the day anyone could make a good argument for fixing the code not the webserver even if I was on IIS.
I know those ones all too well, but apparently maiming developers is frowned upon... I don't know why!
This is the biggest issue with PHP - it seems to have a sufficiently low barrier to entry that any idiot can write PHP code, and many of them do.
Setup a second virtual host with the other port number, remember to use the Listen and NameVirtualHost directives for the other port... setup the required wrappers and SuExec directives, done...
Bit late for me to start playing with this today but I'll give that a go when I get chance and see how I get on.
I'd class the Pi as embedded kit, it hasn't got that much in the way of power, and thus although I *could* treat it as Just Another Box, I'd be looking to use the lowest footprint software possible unless some bit of functionality is required.
Absolutely, however I've always tried to code down to the lowest common denominator so it's more that I (try to) treat a decent server like a Pi rather than the other way around. Most of my development stuff is on VMs running in no more than 512MB RAM. No point having a decent server if it's slowed down by inefficient code. Which so far has meant there's no point having a decent server at all, and the Pi isn't much of a step down (and we'll go up to newer ARM chips when needed).
But, returning to the original post: any reason why I can't install (lighttpd|nginx) alongside Apache (on a different port) and dual-run for a period of time? Memory constraints permitting of-course.
Absolutely none. Why would there be?
I couldn't think of a reason, but I didn't want to go through the exercise to end up with a "Doh" moment at the end. Not that this has ever happened.
Anyway, what's your favourite editor? :-)
On Wed, 6 Mar 2013 15:01:50 +0000 Mark Rogers mark@quarella.co.uk allegedly wrote:
Anyway, what's your favourite editor? :-)
Ach! Flamebait!
Mick
---------------------------------------------------------------------
blog: baldric.net gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312
---------------------------------------------------------------------
On Wed, 6 Mar 2013 13:09:20 +0000 Brett Parker iDunno@sommitrealweird.co.uk allegedly wrote:
lighttpd isn't my favourite, and I wouldn't run it on anything internet facing...
Why not? I have been doing so for years. Lighty has had memory leak problems (see the slow request vulnerability of a few years back for example) which could lead to DOS, but I don't recall it being particularly full of any more holes than any other internet facing server software.
I've seen a fair few holes in lighttpd, I don't actually recommend it for anything facing the general internet, but it is small...
Can you point to some examples? I may need to check my configurations.
Mick
---------------------------------------------------------------------
blog: baldric.net gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312
---------------------------------------------------------------------
On 06 Mar 15:05, mick wrote:
On Wed, 6 Mar 2013 13:09:20 +0000 Brett Parker iDunno@sommitrealweird.co.uk allegedly wrote:
lighttpd isn't my favourite, and I wouldn't run it on anything internet facing...
Why not? I have been doing so for years. Lighty has had memory leak problems (see the slow request vulnerability of a few years back for example) which could lead to DOS, but I don't recall it being particularly full of any more holes than any other internet facing server software.
I've seen a fair few holes in lighttpd, I don't actually recommend it for anything facing the general internet, but it is small...
Can you point to some examples? I may need to check my configurations.
Checkout security.debian.org and the CVEs ;)
The latest one for lighttpd, though, is just TLS/SSL problems, so fine as long as you're not using https :)
But mostly, I wouldn't run it on anything internet facing because it fell over when I was using it behind a proxy to run fastcgi scripts... if it can't deal with the simple things it tends to not go at the front.
:)
On Wed, 6 Mar 2013 15:37:31 +0000 Brett Parker iDunno@sommitrealweird.co.uk allegedly wrote:
On 06 Mar 15:05, mick wrote:
Can you point to some examples? I may need to check my configurations.
Checkout security.debian.org and the CVEs ;)
The latest one for lighttpd, though, is just TLS/SSL problems, so fine as long as you're not using https :)
As I said, lighty seems no better or worse than any other internet server. A quick check over the last ten years shows that apart from 2008 (when lighty had four or five problems) it shows fewer reported issues than apache. Granted, however, that may be a reflection of the relative sizes of the userbase (and hence attention).
But mostly, I wouldn't run it on anything internet facing because it fell over when I was using it behind a proxy to run fastcgi scripts... if it can't deal with the simple things it tends to not go at the front.
Fair enough. Can't argue with that. Bad experience is bound to affect your choice.
Mick (vi)
---------------------------------------------------------------------
blog: baldric.net gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312
---------------------------------------------------------------------
On 6 March 2013 16:42, mick mbm@rlogin.net wrote:
Fair enough. Can't argue with that. Bad experience is bound to affect your choice.
Which is why I want to ditch Apache...
To be fair to Apache, I just revisited the configuration on one server that's had issues, and it had MaxClients=20 - with each one running at around 30-35MB that's potentially a bit more than the system's 512MB available RAM. So I've tweaked that and we'll see what happens.
Mark (joe - although I didn't seriously want to start an editor war!)
On 06 Mar 16:55, Mark Rogers wrote:
On 6 March 2013 16:42, mick mbm@rlogin.net wrote:
Fair enough. Can't argue with that. Bad experience is bound to affect your choice.
Which is why I want to ditch Apache...
To be fair to Apache, I just revisited the configuration on one server that's had issues, and it had MaxClients=20 - with each one running at around 30-35MB that's potentially a bit more than the system's 512MB available RAM. So I've tweaked that and we'll see what happens.
I'd also guess, due to running PHP under mod_php you're using mpm-pre-fork, which is not the bestest way to run apache to start with... worker is the current recommendation, but mod_php doesn't work in that (what with it being entirely un thread safe and all...). :)
Mark (joe - although I didn't seriously want to start an editor war!)
Mark Rogers // More Solutions Ltd (Peterborough Office) // 0844 251 1450 Registered in England (0456 0902) @ 13 Clarke Rd, Milton Keynes, MK1 1LG
main@lists.alug.org.uk http://www.alug.org.uk/ http://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!
On 6 March 2013 17:31, Brett Parker iDunno@sommitrealweird.co.uk wrote:
I'd also guess, due to running PHP under mod_php you're using mpm-pre-fork, which is not the bestest way to run apache to start with... worker is the current recommendation, but mod_php doesn't work in that (what with it being entirely un thread safe and all...). :)
Cheap point, but well made :-)
The conclusion is that I should be focusing on FastCGI not changing webserver, but that brings its own issues (see other thread) that I don't really see a good solution to at the moment, so the status quo is currently winning :-(
On Wed, 6 Mar 2013 10:23:02 +0000 Mark Rogers mark@quarella.co.uk allegedly wrote:
Aside: Another motivation is that we do a lot of work with ARM based systems which rarely have more than 512MB (think Raspberry Pi sort of spec). We usually end up with Apache on these systems because it's what we know, but I really think that nginx/lighttpd/other would be a better fit when resources are tight.
In that case (as in my earlier reply) I'd say take a look at lighttpd. I originally picked it because I needed something really lightweight for the slugs.
Mick ---------------------------------------------------------------------
blog: baldric.net gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312
---------------------------------------------------------------------
-
Brett Parker -
Mark Rogers -
mick