Tag Archives: apache

no groups file?

Ok. I just finished upgrading a web server from Apache 2.0 to 2.2. I’ve been running 2.2 on other machines for months now and have never had a problem with the upgrade process until today.

I have a Trac install on the server that’s protected with generic http auth:

This sort of config has worked for forever. It worked fine under 2.0. It works fine under 2.2. This is not the problem.

When they changed the version number to 2.2 they renamed a whole bunch of the auth modules. They also split a bunch of the behaviors out into multiple separate modules.

So, in order to get the behavior I got by including just mod_auth, I now had to include several different mods. No problem there. The docs tell you this. No problem there.

Thus, my config got a section that looked like this:

Mod_auth_basic for the fundamental behaviors. Mod_authn_file to allow me to read from an htpasswd file. Mod_authz_host because they renamed mod_access (the “allow from xxx.yyy.zzz.com” type directives).

That got apache loading and understanding all of my config file. Then I tried to go to the trac install and blam. 500 internal nastiness error of kabloomitude.

Apache log file said:

Yeah. I was pretty sure I never mentioned anything about auth groups. Checking the entire config file proved me right. 30 minutes of quality time with Google proved entirely unhelpful. Just a bunch of cries for help that were either unanswered or eventually resolved for reasons unrelated to my problem.

I did discover that including mod_authn_default at least prevents the 500’s – just turning them into auth denied errors.

Turns out in my case that in order to actually auth against usernames you must include mod_authz_user now. This wasn’t mentioned in any of the docs I dug through.

So what was happening?

The “no groups file?” error message provided is erroneous. It’s generated as part of some fallthrough code in Apache itself that happens when no existing auth mechanism is able to assume responsibility.

It requested the password and then had nothing to do with it – it didn’t know how to “Require valid-user” or something so it just bombed through, hoping another mod would answer… which of course didn’t happen since I didn’t specify a second authentication method for these url’s.

Moral of the story?

Starting from scratch with Apache config files is painful. Avoid it if possible. If upgrading versions, grab the default config file and merge your changes into it in stead of dropping your file in place and hoping it works as is.

I would have done this but I was working on a Windows server (yeah, I know, but some people in the .NET group are scared of progress – more on this particular saga later) and the windows apache installer doesn’t apparently generate a default config file if it detects one already in place. On unix, I always compile critical server applications by hand, so I always have the defaults to work from.

optional http auth

Today I encountered an interesting problem. (And please excuse any incoherent rambling right now, I’m writing this from a pretty loud office building where everyone’s getting ready to take off for lunch…)

A site I’m working on is currently restricted from public access (largely because we don’t want the client poking around while it’s in a particularly ugly stage of development :P). We’re restricting this access via the standard issue apache http basic auth system with an .htaccess file that looks something like this:

[code]
AuthType basic
AuthUserFile /not/in/var/www/mars_passwd
AuthGroupFile /dev/null
AuthName "MARS Password Required"
Require valid-user
[/code]

This is all well and good. I have a secure password that the three people working on the site can use to access the pages in question and everything is good.

Until they tell me that they want me to make searches work – searches involving both static and dynamic content. Ie, searches that can only be indexed via some sort of spider application. But, the spider must run over http… and it’s too dumb to both authenticate connections AND leave the passwords out of the url’s it saves in its index…

Now, if I were only developing this site internally, I might want to change my .htaccess file to read something more like this:

[code]
Order allow,deny
Allow from localhost
Allow from xx.yy.zz.com
Deny from all
[/code]

This would let the server do it’s thing w/o worries about the

Enter the Satisfy directive.

See, Apache is smart enough to accept any possible combination of these two methods of authentication. It is possible to require both a valid password and a valid ip OR to require only one of the two.

Satisfy takes one of two arguments, ‘all’ or ‘any’. But saying ‘Satisfy all’ is kind of redundant, as that’s the default behavior.

The final auth file looks something like this:

[code]
AuthType basic
AuthUserFile /not/in/var/www/mars_passwd
AuthGroupFile /dev/null
AuthName "MARS Password Required"
Require valid-user

Order allow,deny
Allow from localhost
Allow from xx.yy.zz.com

Satisfy any
[/code]

So, now we get the desired behavior. If connecting from one of the authorized hosts, it lets you in w/o asking for a password. Otherwise, the password is required to continue.