9.23.2014

Apache 2.4.10 appears to ignore DocumentRoot in httpd.conf

I needed to update my webserver from an ancient version of Apache 2.2 to the latest (2.4.10 at the time of this writing). I knew some access controls had changed between 2.2 and 2.4 but I figured I'd read the update guide and be all set. I downloaded the bins, set up the windows service, tweaked httpd.conf and was promptly greeted by a 403 forbidden.

My httpd.conf looked something like this:

# default configuration options for all environments

DocumentRoot "w:/"
<Directory "w:/">
    #
    # Possible values for the Options directive are "None", "All",
    # or any combination of:
    #   Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews
    #
    # Note that "MultiViews" must be named *explicitly* --- "Options All"
    # doesn't give it to you.
    #
    # The Options directive is both complicated and important.  Please see
    # http://httpd.apache.org/docs/2.4/mod/core.html#options
    # for more information.
    #
    Options -Indexes -FollowSymLinks

    #
    # AllowOverride controls what directives may be placed in .htaccess files.
    # It can be "All", "None", or any combination of the keywords:
    #   Options FileInfo AuthConfig Limit
    #
    AllowOverride None

    #
    # Controls who can get stuff from this server.
    #
    Require all granted

</Directory>

And yet the 403 errors in my error.log looked like this:

[Tue Sep 23 21:28:11.212375 2014] [authz_core:error] [pid 11608:tid 1192] [client 127.0.0.1:1931] AH01630: client denied by server configuration: C:/Program Files/Apache Software Foundation/Apache24/htdocs/

What?! I set my DocumentRoot to "W:/", why is it trying to access stuff at .../Apache24/htdocs ?! After much wailing and gnashing of teeth and Googling, I ran httpd.exe with the -S option to dump the runtime config. I noticed a "VirtualHost configuration:" entry...
What?! I didn't set up any virtual hosts! I quickly vim'd (gvim in this case) C:\...\conf\extra\httpd-vhosts.conf and saw the culprit:
<VirtualHost _default_:80>
DocumentRoot "${SRVROOT}/htdocs"
#ServerName www.example.com:80
</VirtualHost>

The virtual host config was overriding the DocumentRoot I had so carefully set in httpd.conf. I modified the DocumentRoot to match the entry in httpd.conf and all was well!

1.09.2014

using gmail smtp with redmine 2.4.1

It took me forever to get redmine emails working with gmail's smtp server.  After perusing the ruby action mailer website, I set up my redmine configuration.yml to look like this:

# default configuration options for all environments

default:
  # Outgoing emails configuration (see examples above)
  email_delivery:
    delivery_method: :smtp
    smtp_settings:
      address: 'smtp.gmail.com'
      port: 587
      domain: 'pickemupproductions.com'
      user_name: 'redmine@pickemupproductions.com'
      password: '****'
      authentication: 'plain'
      enable_starttls_auto: true

obviously replace password with your actual password.  Also, I'm using google apps with my wife's business domain.  So my username and domain are a bit differnet than what you would use for regular gmail (gmail.com).

1.03.2014

Installing new CA certs on ubuntu for chrome or firefox

I recently needed to install a new CA cert into my ubuntu VM.  There are lots of tutorials out there that show how to use

sudo dpkg-reconfigure ca-certificates

This is all well and good if you want to install the CA into the global openssl store for things like git, wget, and apt.  However, if you want Chrome or Firefox to be able to trust the new CA, you need to install the CA cert into the NSS database.  (?!).

This SO article saved me about a day of frustration and sadly I don't have enough rep to upvote Johann's answer:

http://superuser.com/questions/437330/how-do-you-add-a-certificate-authority-ca-to-ubuntu/657177#657177?newreg=ad85846ee69249969b698b48bda371c3

Basically, you need to download the NSS client tools and use them to install the CA (the same one you put in openssl's store) into the backend NSS.  Chromium has the process documented here:

https://code.google.com/p/chromium/wiki/LinuxCertManagement

To install a new cert using the NSS client tools, do this:

certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n <certificate nickname> -i <certificate filename>

<certificate nickname> can be anything.  <certificate filename> is the full path to your PEM file (*.crt or *.cer).