I’m trying to set a configuration up for DW but I’m going mad with the
regexps:(
My starter is the conf file found on the nginx wiki, but modified not to
point DW to the server root:
server {
server_name wiki.domain.tld;
root /var/www/dokuwiki;
root /var/www;
location /dokuwiki {
index doku.php;
try_files $uri $uri/ @dokuwiki;
}
bla bla bla
And here I’m stuck.
Original dirs exclusion:
location ~ /(data|conf|bin|inc)/ {
deny all;
}
Of course, this won’t work w/ my changes, and I’m totally unable to find
the right syntax to exclude these dirs from this conf (made many
unsuccessful tests:(
In my mind it should be: “location ~/dokuwiki/(data|conf|bin|inc)/”
but it don’t work, sniff.
On Fri, Jun 29, 2012 at 09:32:21PM -0400, Jiff wrote:
Hi there,
I don’t know dokuwiki, so this is all untested, but…
Original dirs exclusion:
location ~ /(data|conf|bin|inc)/ {
deny all;
}
Of course, this won’t work w/ my changes,
…why “of course”?
The original example wanted to block access to /data/ and
/something/data/; you now want to block access to /dokuwiki/data/
and /dokuwiki/something/data/.
This location block will match all of those (depending on what else is
in your config file).
In my mind it should be: “location ~/dokuwiki/(data|conf|bin|inc)/”
That looks to me like it should also work…
but it don’t work, sniff.
…so there is something else going on.
What one url did you access to test this?
What response did you see?
What response did you expect to see?
If you provide your config file, or at least the full list of top-level
location definitions, someone may be able to point out why the second
and third answers differ.
Original dirs exclusion:
location ~ /(data|conf|bin|inc)/ {
deny all;
}
Of course, this won’t work w/ my changes,
…why “of course”?
I’m cursed w/ IT & electronics: they hate me,
I must have pissed off Murphy in another live:)
In my mind it should be: “location
~/dokuwiki/(data|conf|bin|inc)/”
That looks to me like it should also work…
Yep, I read the docs and found a useful link toward
perl regexps, so I thought this would have worked
(I must say I didn’t understand it fully: eg: at this time
I don’t really know the difference between .* and (.*) ).
444 is what I intend to use when stable; however, for
tests my block is:
location ~ /dokuwiki/(data|conf|bin|inc)/ {
return 403;
}
What response did you expect to see?
a 200 one
If you provide your config file, or at least the
full list of top-level
location definitions, someone may be able to point
out why the second
and third answers differ.
server_name mydyndnsdom.org;
root /var/www;
listen 80;
index doku.php;
location ~ .php$ {
if (!-f $request_filename) {
return 403;
}
include fastcgi_params;
fastcgi_index doku.php;
fastcgi_param SCRIPT_FILENAME
$document_root$fastcgi_script_name;
Oh, I see; but there’s something strange: he only modify one path;
but others nest in the same place, so he logically should have
split the original block in 4 blocks, no? (last post).
Good luck with it,
Thanks.
This night, I found that the unstable Debian pkg (last version)
also fit into stable branch, so I flipped in it (easier maintenance).
Now, I’m gonna restart and modify my nginx conf+DW
according to all information you gave me.
Well, I shouldn’t work that much ]
In fact there was so much tests, comments, etc that I missed
the main problem: I use 2 files, the 2nd one being common to
different servers in the 1st one; I just didn’t saw I was refering
to an old version:(
Thanks anyway for you patience and hints that helped me to
debug that.
Jiff
HTTP 444 is not a standard return code. It is used within nginx as a
“just close the connection” signal. The config you have shown does not
include 444 anywhere that I can see.
444 is what I intend to use when stable; however, for
tests my block is:
location ~ /dokuwiki/(data|conf|bin|inc)/ {
return 403;
}
/dokuwiki/lib/tpl/default/images/button-dw.png does not match this
location, and so this config will not be used.
According to the config you posted,
/dokuwiki/lib/tpl/default/images/button-dw.png should return the content
of the file /var/www/dokuwiki/lib/tpl/default/images/button-dw.png or
else 404.
location ~ .php$ {
location ~ /dokuwiki/(data|conf|bin|inc)/ {
location ~* .(js|css|png|jpg|jpeg|gif|ico)$ {
That is the one that will match this one request.
location /dokuwiki {
location @dokuwiki {
I don’t see how the config you posted can lead to the access log you
posted. Maybe someone else will have better luck. Maybe enabling the
debug log will give more hints to where the problem it.
Oh, I see; but there’s something strange: he only modify one path;
but others nest in the same place, so he logically should have
split the original block in 4 blocks, no? (last post).
Probably not. At that point it that report, they are talking about
“xsendfile” and are learning that nginx is not the same as apache.
It’s not directly related to what you are reporting.
On Sun, Jul 01, 2012 at 12:01:19AM -0400, Jiff wrote:
Hi there,
Thanks anyway for you patience and hints that helped me to
debug that.
That sounds like you’ve found a working solution – good work.
All of the (current) search results I see for “nginx dokuwiki” seem to
indicate to me that installing not in root is a problem for people.
When you’re happy that what you have does everything it is supposed to,
could you post your config (mentioning version numbers) so that
searchers
in a year will be able to take advantage of your work?
This mailing list / forum should be ok; the dokuwiki or nginx
documentation wikis would also be good, if you have access.
#-------------------------------------------------------------
location ~ \.php$ {
if (!-f $request_filename) {
return 404;
}
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME
$document_root$fastcgi_script_name;
# Comment the line below if redirecting to localhost
(unencrypted)
fastcgi_param HTTPS $php_https; # DW checks
$_SERVER[‘HTTPS’]
# Gain the TCP/IP overhead: use socket instead
fastcgi_pass unix:/var/run/php5-fpm.socket;
}
#-------------------------------------------------------------
# For security reasons (http://www.dokuwiki.org/security) some
# directories must not be reachable from the outside. But a
# 'deny all' isn't a good solution, as it returns a 403 which
# is visible by the client. The solution comes from a nginx
# special extension: the 444 error that returns no information
# to the client and closes its connection. Useful as a deterrent
# for malware as it is silent:)
location ~ ^/dokuwiki/(bin|conf|data|inc)/ {
return 444;
}
#-------------------------------------------------------------
# Force a long expiration delay on static files
location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
expires 30d;
access_log off;
log_not_found off;
}
# This location serves static files
location ~ ^/dokuwiki/lib/ {
expires 30d;
}
#-------------------------------------------------------------
# As of nginx wiki this should go to /etc/nginx/conf.d/drop.conf,
# but I like to have everything on sight.
# NTS: It is normal not to see the pink icon about
# "data directory not properly secured": this is
# when I can see it that there's something wrong:)
location = /dokuwiki/robots.txt {
access_log off;
log_not_found off;
}
location = /dokuwiki/favicon.ico {
access_log off;
log_not_found off;
}
# Silently protect all Linux hidden files (but log get attempts)
location ~ /\. {
return 444;
}
# I spent some time to understand what this block was meant for:
# http://kbeezie.com/view/nginx-configuration-examples/
# This block is mainly for people who use vim, or any other command
line
# editor that creates a backup copy of a file being worked on with a
file
# name ending in ~.
# Hiding this prevents someone from accessing a backup copy of a
file you
# have been working on.
location ~ ~$ {
access_log off;
log_not_found off;
return 444;
}