Live data from Hacker News

How to set up a safe and secure Web server

arstechnica.com

51–60 of 148 posts

Re: How to set up a safe and secure Web server

#51
Vurtualization is not for production. Why to have this useless layer, which messes up your CPU caches even more, interfere with you IO and complicates memory model? What for?

Virtualization was build for server providers to make easy money, not for server owners to gain performance advantages.

Vistualization is not for production. Production servers need less code, not more.

It is the same kind of mistake as JVM - we need less code, integrated with OS, not more "isolated" crapware which needs networking, AIO and really quick access to the code from shared libraries.

And, of course, a setup without middle-ware (python-wsgi, etc) and several storage back-ends (redis, postgres) is meaningless.

Update:

Well, production is not about having a big server which is almost always 100% idle, and can be partitioned (with KVM, not a third-party product) to make a few semi-independent virtual servers 99% idle. This is virtual, imaginary advantage.

On the other side, your network card and your storage system cannot be partitioned efficiently, despite all they say in commercials. And that VM migration is also nonsense. You are running, say, a MySQL instance. Can you migrate it without a shutdown and then taking a snapshot of an FS? No. So, what migration you're talking about? It is all about your data, not about having a copy of a disk-image.

It is OK to partition development, or 100% idle machines - like almost all those Linode instances, which have a couple of page request in a day - this is what it was made for, same as old plain Apache virtual-hosting. But as long as one needs performance and low latency, all the middle-men must go away.

Re: How to set up a safe and secure Web server

#52

Vurtualization is not for production. Why to have this useless layer, which messes up your CPU caches even more, interfere with you IO and complicates memory model? What for? Virtualization was build for server providers to make easy money, not for server owners to gain performance advantages. Vistualization is not for production. Production servers need less code, not more. It is the same kind of mistake as JVM - we…

How is this the top comment? I'm sure some of your points may be salient, but practical experience says virtualization works just fine for production. Same with the JVM.

Re: How to set up a safe and secure Web server

#54

Vurtualization is not for production. Why to have this useless layer, which messes up your CPU caches even more, interfere with you IO and complicates memory model? What for? Virtualization was build for server providers to make easy money, not for server owners to gain performance advantages. Vistualization is not for production. Production servers need less code, not more. It is the same kind of mistake as JVM - we…

We have an entire 2 million GBP VMware estate which I inherited

I agree entirely with this comment. Between lun size limits, license management (which is hell), the general additional work and the fact that the benefits are suspect, I agree.

Processes and multiprogramming were invented to virtualise batch machines. That's as far as it needs to go.

I'm not impressed with the industry trend.

Re: How to set up a safe and secure Web server

#55
If you want a safe and secure Web server, use what your distribution gives you. Don't add third party sources if you can avoid it, ie. don't need features Instead, go with what your distribution gives you. The people who put your favourite distribution together work on making the system safe and secure as a whole. People who don't think it is safe and secure file bugs and they get fixed. And you have one place to get all your updates in case fixes are needed.

If you start adding third party sources, you're on your own as to managing any implications of the way you've put it together. Just because each individual component is safe and secure doesn't mean that it is as a whole. For example, Ubuntu add hardening (AppArmor) for various server daemons which you won't get if you just download apache from the project website.

If you need a guide on putting a system together yourself, then you aren't someone who can manage these implications yourself, and you're trusting the guide author in not having made any mistakes. Are you really in a position to judge his competence?

Just use your distribution's standard web server and you'll get your safe and secure Web server in one command.

Re: How to set up a safe and secure Web server

#56
Article covers main parts of the webserver setup and gathers very interesting information scattered all over the Internet. All the nginx setup and config things are REALLY useful, all the more regarding the poor quantity/quality of resources one can find out there. Really useful to me. I wish I had one guide like this when I setup my own webserver. I made a tl;dr version but the main interesting parts stay all the nginx tricks for me http://tldr.io/tldrs/50b5ccb711c0ea5051000f29.

Re: How to set up a safe and secure Web server

#57

Vurtualization is not for production. Why to have this useless layer, which messes up your CPU caches even more, interfere with you IO and complicates memory model? What for? Virtualization was build for server providers to make easy money, not for server owners to gain performance advantages. Vistualization is not for production. Production servers need less code, not more. It is the same kind of mistake as JVM - we…

Not true, for a startup, virtualization is the most cost effective way of hosting applications/websites. We have a physical server with 32GB RAM and on it four virtual machines for different purposes. None of them breaks any sweat.

Re: How to set up a safe and secure Web server

#58

Vurtualization is not for production. Why to have this useless layer, which messes up your CPU caches even more, interfere with you IO and complicates memory model? What for? Virtualization was build for server providers to make easy money, not for server owners to gain performance advantages. Vistualization is not for production. Production servers need less code, not more. It is the same kind of mistake as JVM - we…

Go to any big company's datacenter and you'll be sure to find some virtual machines that are in production. There is some performance penalty for sure, but the added flexibility and reliability covers that neatly. If your VM host seems to be failing, you can live migrate your VMs off that box and take it down for maintenance. That's not an option when running your services on bare metal. On flexibility side, it is very powerful to be able to allocate resources depending on need, not needing to buy specific hardware and hope that it's a good fit for the workload it runs.

Re: How to set up a safe and secure Web server

#59

Vurtualization is not for production. Why to have this useless layer, which messes up your CPU caches even more, interfere with you IO and complicates memory model? What for? Virtualization was build for server providers to make easy money, not for server owners to gain performance advantages. Vistualization is not for production. Production servers need less code, not more. It is the same kind of mistake as JVM - we…

How is this the top comment? I'm sure some of your points may be salient, but practical experience says virtualization works just fine for production. Same with the JVM.

1. at what cost? 2. just fine is not enough. 3. for some reasons all sites uses nginx, not jetty.)

Re: How to set up a safe and secure Web server

#60

Vurtualization is not for production. Why to have this useless layer, which messes up your CPU caches even more, interfere with you IO and complicates memory model? What for? Virtualization was build for server providers to make easy money, not for server owners to gain performance advantages. Vistualization is not for production. Production servers need less code, not more. It is the same kind of mistake as JVM - we…

EC2 seems to be doing fine on virtualization. A service of that kind would be impossible to run without a VM layer inbetween. So yes, you pay a performance penalty, but you get something in return: Flexibility. And for some use-cases flexibility is far more valuable than raw performance.
Post reply on HN