OpenBSD Journal

Heads Up: Apache Removed from Base

Contributed by jj on from the puffy-vs-geronimo dept.

In a series of commits, Florian Obser (florian@) has unhooked Apache from the OpenBSD base build. This means you need to pay special attention when upgrading your systems:

/usr/sbin/httpd and the associated tools and files have been removed. Consider using nginx(8) for your http serving needs, but note that nginx is not a drop-in replacement. For people who need the old httpd(8) and cannot switch at this time, see the port www/apache-httpd-openbsd.

Packages are not yet available due to release engineering, but will follow. The following files and directories need to be removed:

    rm -r /usr/lib/apache
    rm -r /usr/share/doc/html/httpd
    rm /usr/bin/{dbmmanage,htdigest,htpasswd}
    rm /usr/sbin/{apachectl,apxs,httpd,logresolve,rotatelogs,suexec}
    rm /usr/share/man/man1/{dbmmanage.1,htdigest.1,htpasswd.1}
    rm /usr/share/man/man8/{apachectl.8,apxs.8,httpd.8,logresolve.8}
    rm /usr/share/man/man8/{rotatelogs.8,suexec.8}
    rm /etc/rc.d/httpd

The following files are associated with httpd(8) and can be deleted in some cases, but may have been replaced with user content or configuration. Warning: On systems which currently or have previously used any http daemon, care must be taken and files analyzed case by case to avoid accidental deletion of user content or important configuration files. In particular, users moving to apache-httpd-openbsd will want to keep many of these files.

    # rm -r /var/www/icons
    # rmdir /var/www/conf/{modules,modules.sample}
    # rmdir /var/www/users
    # rm /var/www/cgi-bin/{printenv,test-cgi}
    # rm /var/www/conf/{httpd.conf,magic,mime.types}
    # rm /var/www/htdocs/{apache_pb.gif,blowfish.jpg,bsd_small.gif,index.html}
    # rm /var/www/htdocs/{lock.gif,logo23.jpg,logo24.jpg,mod_ssl_sb.gif}
    # rm /var/www/htdocs/{openbsd_pb.gif,openbsdpower.gif,openssl_ics.gif}
    # rm /var/www/htdocs/smalltitle.gif

Emphasis in the original, so make sure you've run through what you need to do, take backups, sweat it out for a minute before hitting the enter key, make one final tarball of your data just in case, and then carefully go through the upgrade.

What, that's not your checklist?

(Comments are closed)


Comments
  1. By jeanot (80.78.9.35) jeanot@gmail.com on

    Dear HTTPd,
    I'll miss you...
    Adieu

  2. By Laurence Rochfort (193.9.13.136) on

    What's the OpenBSD rationale for replacing Apache with nginx?

    I'm pretty familiar with Apache, but haven't touched nginx at all.

    Comments
    1. By Anonymous Coward (81.200.189.1) on

      > What's the OpenBSD rationale for replacing Apache with nginx?
      >
      > I'm pretty familiar with Apache, but haven't touched nginx at all.

      Ngix is faster and, in a basic configuration, a lot more secure than Apache.

      The other reason is that OpenBSD has maintained for many years its own branch of Apache 1.3.x (If I remember well - I may be wrong on the version number), with many additional patches, and that it was getting completely obsolete.

      Moving to Nginx is, in my opinion, a very smart move.

    2. By chronicdiscord (70.31.53.187) on

      > What's the OpenBSD rationale for replacing Apache with nginx?
      >
      > I'm pretty familiar with Apache, but haven't touched nginx at all.

      I see you've not read anything about Apache for the past four years. Basically the license and the code for the Apache 2 branch was kinda funky, then the license for the Apache 1 branch got funky too... So to avoid funk OpenBSD pretty much forked Apache 1.

      So, not wanting to tie itself to Apache, OpenBSD went elsewhere. Only took a few years to happen.

      What was OpenBSD's rationale for replacing sendmail? What was OpenBSD's rationale for replacing ipf? What rationales does OpenBSD ever have?

      They remove bad code where and when they can, they remove bad licenses where and when they can... Cover it for ya?

      And man pages should get you somewhere with regards to using it.

  3. By Aleksei K (80.235.105.78) niemi@solo.ee on

    Why not to upgrade apache to version 2.2.x or 2.4.x(with event) or try lighttpd server?

    Comments
    1. By henning (180.42.49.96) on

      > Why not to upgrade apache to version 2.2.x or 2.4.x(with event) or try lighttpd server?

      Not Apache 2 because it's shit, basic design wrong, and not under a free license to begin with.

      Not lighttpd because nginx is just better.

    2. By Anonymous Coward (207.107.158.22) on

      > Why not to upgrade apache to version 2.2.x or 2.4.x(with event) or try lighttpd server?

      Because nginx is significantly better than either of those? Lighttpd has a history of being rather broken, including plenty of security holes that get quietly patched and no announcement made. And it is basically dead, as everyone who used it switched to nginx. Apache2 has a bad license.

  4. By Sebastian Rother (srother) srother@ on https://www.mercenary-security.com

    You might could consider to keep "logresolve" + "htpasswd"...
    Since none of these tools comes with nginx.

    Except this you can replace Apache with nginx flawlessly. :-)

    Comments
    1. By Anonymous Coward (95.76.6.245) on

      > You might could consider to keep "logresolve" + "htpasswd"...
      > Since none of these tools comes with nginx.
      >
      > Except this you can replace Apache with nginx flawlessly. :-)

      I wrote a htpasswd replacement in perl specifically for this purpose. The switches and CLI are identical to the apache version.
      https://gist.github.com/ggl/4966699

    2. By Anonymous Coward (2001:470:89e9:1:1a:46b3:235a:19a4) on

      > You might could consider to keep "logresolve" + "htpasswd"...
      > Since none of these tools comes with nginx.
      >


      There is a split-logfile program available as well, to replace the perl script of the same name that sometimes is bundled with apache httpd.

      http://archive.mgm51.com/sources/split-logfile.html

  5. By TuxLyn (184.166.186.66) on http://gotux.net/

    This is actually very good. Apache is way too bloated, Nginx is so much superior. As for htpasswd you can easily generate password using perl <b>perl -le 'print crypt("password", "salt")' > /etc/nginx/htpasswd</b> or ruby by running irb command then typing <b>"password".crypt("salt")</b>

    Comments
    1. By Anonymous Coward (91.154.66.65) on

      People keep calling Apache bloated but how many of you actually looked at the code that ships with OpenBSD?

      Fact: the nginx code base is more than 60% larger.

      https://news.ycombinator.com/item?id=7404092

      Comments
      1. By Philip Guenther (166.137.208.36) guenther@openbsd.org on

        > People keep calling Apache bloated but how many of you actually looked at the code that ships with OpenBSD?
        >
        > Fact: the nginx code base is more than 60% larger.

        It would help if everyone used version numbers when referring to apache, as I suspect you're responding to a complaint about apache 2.x

        apache 1.3
        + small
        + includes openbsd security fixes
        + good license
        - local fork, no active development
        - old module API means extensions in ports don't use it

        apache 2.x
        + module API supports extensions in ports
        + active development
        - big
        - doesn't include local security work
        - bad license

        nginx
        + module API supports extensions in ports (IIRC)
        + active development
        + good license
        + not big
        + developers receptive to patches from OpenBSD
        + no need to fork

        Those last points are important, as they mean we get the benefit of staying with the main stream, and the fixes get pushed into the main stream to help everyone out there. For example, when we did an audit of the tree to fix ENFILE/EMFILE DoS attacks on daemon, the nginx goes "got it" and pulled in the fixes quickly without any "that won't ever happen!" push back. I want all the websites I visit to be robust and secure, not just those running OpenBSD!

      2. By Anonymous Coward (2001:470:b01e:3:214:51ff:fe67:4efb) on

        > People keep calling Apache bloated but how many of you actually looked at the code that ships with OpenBSD?
        >
        > Fact: the nginx code base is more than 60% larger.
        >
        > https://news.ycombinator.com/item?id=7404092


        The original comment is referring to issues such as how much memory Apache consumes which for most setups is way more than should be necessary or the poor performance. Most common setups with static pages or even PHP and with the use of event driven web servers consume a tiny fraction of the memory and are are able to attain performance levels between 2-4 times that of Apache.

    2. By Anonymous Coward (2001:8b0:648e:cc01:f2de:f1ff:fef9:a752) on

      > This is actually very good. Apache is way too bloated, Nginx is so much superior. As for htpasswd you can easily generate password using perl <b>perl -le 'print crypt("password", "salt")' > /etc/nginx/htpasswd</b> or ruby by running irb command then typing <b>"password".crypt("salt")</b>

      You can just use encrypt(1) to generate a crypted password. The default setting is to use bcrypt, which works just fine in an .htpasswd file for nginx (or for lighttpd or httpd) and you don't need to generate the salt yourself, removing another possible way that it can be misused.

      Comments
      1. By Anonymous Coward (80.153.96.240) on

        > > This is actually very good. Apache is way too bloated, Nginx is so much superior. As for htpasswd you can easily generate password using perl <b>perl -le 'print crypt("password", "salt")' > /etc/nginx/htpasswd</b> or ruby by running irb command then typing <b>"password".crypt("salt")</b>
        >
        > You can just use encrypt(1) to generate a crypted password. The default setting is to use bcrypt, which works just fine in an .htpasswd file for nginx (or for lighttpd or httpd) and you don't need to generate the salt yourself, removing another possible way that it can be misused.

        And what's about logresolve? :-)

  6. By Anonymous Coward (80.53.251.245) on

    I've just checked default sources from 5.4/i386 and it seems that included nginx is vulnerable to CVE-2014-0088. The errata for 5.4 fixes only CVE-2013-4547.

    Comments
    1. By Anonymous Coward (anon) on

      > I've just checked default sources from 5.4/i386 and it seems that included nginx is vulnerable to CVE-2014-0088. The errata for 5.4 fixes only CVE-2013-4547.

      CVE-2014-0088 relates to SPDY support in nginx 1.5.10 on 32-bit systems.

      The version of nginx included in OpenBSD base is using the 1.4 branch, and SPDY has not been enabled in any OpenBSD release (it was enabled in -current for about 3 weeks but disabled again; "Disable SPDY until we have a better understanding about code and protocol within OpenBSD"), so it doesn't apply to base nginx.

      An alternative version of nginx is in ports with more modules enabled; SPDY is enabled and a release from the 1.5 branch is available there, however it's 1.5.7 which pre-dates this bug.

      Comments
      1. By Anonymous Coward (anon) on

        > > I've just checked default sources from 5.4/i386 and it seems that included nginx is vulnerable to CVE-2014-0088. The errata for 5.4 fixes only CVE-2013-4547.
        >
        > CVE-2014-0088 relates to SPDY support in nginx 1.5.10 on 32-bit systems.

        The new CVE-2014-0133 however does affect all versions of nginx that have SPDY enabled before today's two releases.

  7. By Blake (93.158.32.94) blake at two one one two dot net on 2112.net

    Found a nice tool the other day:

    https://github.com/nhnc-nginx/apache2nginx

    little Python tool to convert Apache config files to Nginx configs...

    HtH

    Comments
    1. By Anonymous Coward (23.242.254.17) on

      > Found a nice tool the other day:
      >
      > https://github.com/nhnc-nginx/apache2nginx
      >
      > little Python tool to convert Apache config files to Nginx configs...
      >
      > HtH

      WOOT THANKS!

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]