Apache Removed from OpenBSD Base
undeadly.org
undeadly.org
The title implies some vote of no confidence by the OpenBSD team regarding Apache, when in actual fact they're just cleaning up their own mess, due to objecting to an earlier licensing change in the 2.x line.
No it doesn't. It says what it says: Apache was removed from base. Now that there is a reasonable alternative with an acceptable license, it is time to move on.
> when in actual fact they're just cleaning up their own mess
You choice of words sure reeks of negativity towards the project. The fact is, skanky old Apache 1.3 has served the project well for a long long time, and it has had a good track record as far as security goes. Keep in mind that code in the base system has been audited, patched and maintained by the project.
Apologies if you read so much negativity into my choice of words, it wasn't meant as an attack on OpenBSD, forking unmaintained software, or whatever else, just intended to point out a correction in the way probably half or more of readers will interpret the article – as some kind of indication that Nginx is technically somehow better than Apache
The only thing silly here is your opinion.
What is also silly is for a project that has so few serious developers to take on a project as massive as maintaining a fork of a project as large as Apache.
When Apache had security issues that didn't affect the OpenBSD fork it was often because the OpenBSD fork didn't have the module in question (most security issues in Apache in the past decade have been in modules, often not frequently used ones). People not using those modules wouldn't have had those security issues, and people using those modules on OpenBSD (after building from source to get those modules and a modern version of Apache) would have also been affected. I'll admit that there is a certain charm to software that has few bugs because it does very little, but Apache is what it is because people need it to be those things. It is certainly not through incompetence.
So, my opinion may be silly. But, it is not unconsidered. I've thought a lot about web service for the past 15 years, as it's a core part of my business. I could very well be wrong. Maybe OpenBSD would have been even less successful for web service had they opted to include a modern version of Apache. (And, before you say "popularity isn't a measure of being right", I will point out that no matter how secure software is, it is useless if no one uses it.)
In most things I agree with you; I use vim, bash, shell scripts for automation, Perl, etc. All things that get the ancient vs. modern argument used against them...but, when it comes to software security old nearly always means "exploitable". Since Apache 1.3 became EOL in 2010, OpenBSD developers have been solely responsible for finding and fixing 1.3 security issues. That's a lot of work. If I were responsible for Apache packages (and I am; we ship a custom build of Apache for some of our supported operating systems in Virtualmin repos), I would want to leverage the knowledge and efforts of the people who primarily work on Apache.
To continue...
There have been major architectural changes in Apache from 1.3 to 2.x. Performance on a number of use cases has nearly doubled in those 15 years, for example.
Modern web standards are more widely supported by recent versions, as well, either through modules or core HTTP protocol support changes. Wanna use SPDY? Yeah...gotta have 2.x.
A ton of security and QoS oriented capabilities are also "new" in 2.x. Given OpenBSDs security focus, I believe tools to help prevent exploits and DoS of web apps should also be considered...not just whether the web server has any directly exploitable bugs. Very few people are just serving flat files with their web server today. The code interacting with clients is often mostly in Python, Ruby, Perl, PHP, etc. Those are as much potential attack vectors as the web server itself, and 2.x has better tools for managing that risk.
Personally, lighttpd for a long time, but then it failed to be maintained in keeping with OpenSSL libraries, so it was dropped for nginx, and no looking back since.
Apache's biggest problem is that it isn't cool and hip anymore. It's config file is too easy to understand.
Good { thing we = have; nginx; }
Phew!
You can tell nginx to reload its configuration without restarting the entire server process by running "sudo /etc/init.d/nginx reload", or on ubuntu "sudo service nginx reload".
Per directory config is extremely beneficial for static hosting / VPS, but sketchy to get the security of values just right.
In 2008, my web site saw some decent traffic, and I was stuck in a spiral of buying more and more expensive servers to keep up with the demand. Some of the media files were large, and slow downloads would tie up a thread, and corresponding chunk of memory.
I spent a long time working through the documentation that was available at the time, and I couldn't get anything to work stably with Django.
Then I found a guide for lighttpd, and was floored when the resources used by my web server dropped to single digits. Much later, I'd learn that even saturating a gigabit pipe with just html/css/image traffic ran fine.
Nginx has since replaced lighttpd, since the latter doesn't seem to be well maintained these days.
As I understand it, Apache now is capable of high performance, but once bitten twice shy. The whole thing just seemed to be a big, bloated mess to me. Like you can do everything imaginable, except what you actually want to do.
I couldn't imagine a feature that would exist to convince me to move back. I expect quite a few web developers are in the same boat.
Your criticism of the config file is nonsensical. I'd use nginx with Apache style configuration over the inverse in a heart beat - though I disagree it would be an improvement.
Yeah, mod_rewrite sure is the epitome of a readable config file syntax.
Why have one or two simple to understand "if" statements when you could have a pile of incomprehensible regexps with random one letter control flow flags?
Simple. Ha.
Apache uses tons of memory regardless of which worker model is used.
Nginx is reliable and stable, we've never had memory leaks or weird shit happen. This is why it's often uses as a front-end reverse proxy.
More often, nginx is put out in front of apache where other dependencies require it (dav svn).
EDIT:
The C source files and headers under src/usr.sbin/httpd are about 100k lines. Under src/usr.sbin/nginx you have closer to 170k lines. Of course this isn't exactly apples to apples comparison as both have optional modules and at least nginx has some OS-specific code.
In any case though, it is really hard to argue that nginx is "light, small, and fast" while httpd is a bloated swiss army chainsaw with a kitten sink...
Ik can write a program that will use 100% CPU in about 10 LOC, while there can be very well-optimized pieces of software can be thousands to millions LOC.
e.g. the Quake 3 engine is probably as well optimized as you can make it and is about 300K LOC: https://github.com/id-Software/Quake-III-Arena
I agree about highly optimized code being typically larger than the simpler alternative.
Now nginx has interesting optimizations in some places (e.g. the http parser), but if you read the code, it's not like 90% of the code in nginx is there due to optimization.
I'd like to add that from an OpenBSD perspective, excess optimizations would no doubt be considered bloat as well. One of the goals is that the code is clean, correct, and secure. I know for a fact that the developers are not going to carefully audit and maintain millions of lines of micro-optimizations. What these might get you is a tick in a hypothetical feature checklist ("performance"). But if another daemon does the job and performs well enough, then that feature is unneeded complexity, hence bloat. Not something you want to include in what aims to be the world's most secure general purpose operating system.
I am not an openbsd guy obviously but know httpd is popular. Is it because adding it to base install adds too many security concerns?
Including a web server isn't necessarily a security concern, it's not running by default. The advantages is that there's a web server included, with privsep, chrooting and a sane default configuration.
The relevant thread[1] from the time may be of use, but a specific message sums it up:
"We've been clear: Their new license contains more stuff, and we do not accept MORE STUFF in licenses."
[0] http://www.openbsd.org/policy.html [1] http://www.monkey.org/openbsd/archive/misc/0406/msg00412.htm...
On the other hand it's absurd to dogmatically oppose MORE STUFF regardless of what the stuff is. The added terms in Apache-2 make sense for a US-based collaborative software project that accepts contributions from businesses that hold software patents. They may be pointless legalese for a Canadian-based project whose contributors are mostly individual developers, but that doesn't make them an assault on developers' freedoms.
We want to make available source code that anyone can use for ANY PURPOSE, with no restrictions.
That's what we call a free gift.
That is one of the project's goals.
You're right, the patent clause might not necessarily be an attack against the OpenBSD developers' freedoms. But they do not care about their own freedoms only; they want it to be free for anyone (this includes corporations who might hold patents, and also individual developers working for such corporations), for any purpose. It is really as simple as that.
You guys keep missing the point really.
We know what a free license should say.
It should say
Copyright foo
I give up my rights and permit others to:
distribute
sell
give
modify
use
I retain the right to be known as the author/owner
When it says something else, ask this:
- is it 100% gauranteed fluff which cannot ever affect anyone?
- is it giving away even more rights (the author right)?
If not, then it must be giving someone more rights, or by the same
token -- taking more rights away from someone else!
Then it is _less_ free than our requirements state!
So why even BOTHER wasting your time trying to understand what they
say?
Who cares if it is legal or not! We're not going to want to go
quibble in a court! We're trying to make it so simple that something
can't even GO to court, because it's free and, anyone can tell that it
is free because the language used to say so is SIMPLE.
Copyrights are essentially about copying. Patents aren't - you can write a clean-room program that's entirely your own work, absolutely guaranteeing that you aren't infringing anyone's copyright, but it could still infringe a patent you've never heard of. Or you could accept code from a friendly company which has a few defensive patents on it, and some years later the friendly company comes under less friendly ownership and the defensive patents turn offensive.
Apache, being based in the US (which has many software patents) and accepting code from many companies that have patents, has to deal with these scenarios. OpenBSD, being based in Canada (with far fewer - but not zero! - software patents), isn't as affected by it so Theo calls it bullshit. But it's not so black-and-white.
Now you can try to "address" software patents e.g. by obligating distributors to grant rights to their patents, but that is a restriction; it might be giving someone more rights, and by the same token is taking more rights away from someone else! More importantly, that would be a restriction imposed by the copyright holder, rather than an external restriction imposed on you by a third entity the copyright holder does not control.
OpenBSD does not want to impose such restrictions on you or anyone else. They make their code free.
You seem to think that OpenBSD or Theo simply disregard patent issues because they hail from Canada. Maybe you should learn about CARP[1][2], or figure out why many of the ports' Makefiles have a line like this:
PERMIT_PACKAGE_CDROM= patents
Patents + OSS is a huge, under-served point that unfortunately Lessig is no longer working on.
I and others that open source tons of code will be the first to wave the FOSS banner all day long, but it's not going change the reality of the present landscape.
As such, open source projects and startup founders repeatedly fail to anticipate the consequences of nonparticipating in the patent scheme. If the other side (a company) holds a (shitty) patent, and a project doesn't... they can still squish them like the cockroaches they are should the project become significant. So there's options: either play the game, fight city hall or get fucked by pretending it doesn't exist. Not choosing an action is still a choice.
Perhaps one of the larger OSS orgs would show leadership on this to help projects manage this tricky minefield.
More likely it was the patent clause of the license that made it so bad that the OpenBSD developers didn't want it. I can sort of see where they're coming from. If some company puts a bit of code into Apache 2, covered by one of their patents, that's okay, anyone using the Apache 2 gets a license. However it's pretty much impossible for anyone to tell which parts of the code is covered by the patent, so you could get in trouble, without knowing it, if you yank out that part of the code an use it elsewhere. The patent could also cover a protocol, an algorithm, whatever, the people using the Apache licensed code don't care, they where given a license for the pattern, but nobody else can do an implementation.
It's not for me to say, but I believe that the OpenBSD developers wanted an http server that came unencumbered by patent and was ensured to be free of any software patent. Instead the Apache 2.0 license presented them they the problem that you can actually tell if a given piece of code was covered under some patent.
Your best bet is to find some spare hardware and give it a try. I wouldn't switch a production box over before that.
If the problem is fixed in 9-STABLE, but you're only deploying RELEASE builds, 9.3-RELEASE should be available in a few months: http://www.freebsd.org/releases/9.3R/schedule.html