57
A small addition to the great answer from Xaviar:
If you happen to be not so well acquainted with nginx, there's an important difference between adding the slash to the end of the proxy_pass directive.
The following does not work:
location ~* ^/dir/ {
rewrite ^/dir/(.*) /$1 break;
proxy_pass http://backend/;
but this one does:
location ~* ^/dir/ {
...
38
According to nginx documentation:
Then regular expressions are checked, in the order of their appearance
in the configuration file. The search of regular expressions
terminates on the first match, and the corresponding configuration is
used.
In your configuration, the following location is defined before the one with the proxy_pass and it matches ...
35
This is easy, if you follow the manual carefully: all members inside a character class lose special meaning (with a few exceptions). And ] loses its special meaning if it is placed first in the list. Try:
$ echo '[123]' | sed 's/[][]//g'
123
$
This says:
inside the outer [ brackets ], replace any of the included characters, namely:
] and
[
replace ...
33
The = modifier in location block is an exact match, without any wildcards, prefix matching or regular expressions. That's why it doesn't work.
On your regex attempt, [a-z] matches a single character between a and z. That's why it doesn't work for you.
You need to have your locations set up like the following. Note the order of location statements. nginx ...
26
It tells you that the URI in the proxy pass directive can't be used in a regex location. This is because nginx can't replace the part of the URI matching the regex in the location block with the one passed in the proxy_pass directive a generic way.
Simply imagine your location regex is /foo/(.*)/bar, and you specify proxy_pass http://server/test, nginx ...
25
~: If a tilde modifier is present, this location will be interpreted as a case-sensitive regular expression match.
~*: If a tilde and asterisk modifier is used, the location block will be interpreted as a case-insensitive regular expression match.
23
Since nginx 0.8.25 named captures can be used in server_name. You should use them.
Here, the sub-domain will be stored in a variable called $sub. Then you will be able to reuse it in the rewrite directive :
server {
listen 80;
server_name ~^(?<sub>\w+)\.olddomain\.com$;
rewrite ^ $scheme://$sub.doma.in$request_uri? permanent;
}
Alternatively, ...
18
2 Things:
As stated by @Rory, you need the -o option, so only the match are printed (instead of whole line)
In addition, you neet the -P option, to use Perl regular expressions, which include useful elements like Look ahead (?= ) and Look behind (?<= ), those look for parts, but don't actually match and print them.
If you want only the part inside the ...
18
location ~ ^/(static|media)/ {
proxy_pass http://backend.example.com;
) <-----------
Should be...
location ~ ^/(static|media)/ {
proxy_pass http://backend.example.com;
} <-----------
The closing needs to be a brace {}, not a parenthesis bracket ().
Can't believe how long it took to see that. Guido was right from the comments.
16
Try this
location ~ "^/[\d]{5}" {
# ...
}
~ means the a regex location
^ means the beginning of the line
[\d] is shorthand for character class matching digits
{5} shows that the digits must be exactly five, no more, no less
and () parentheses are not necessary if you do not want then to use grouping, $1, for example
Double quotes because curley ...
15
I feel that hdr_sub is better for your needs. I was using hdr_end for a while but it runs into the following problem:
requests with port 80 usually get the port stripped so the host header looks like "example.com", but if you were requesting on a port explicitly, like example.com:8080, the header will have the port, and hdr_end will fail the check for "...
15
It's really basic and simple. Just add /path/ part to proxy_pass and nginx will replace locations prefix with that path. You need to replace /string_1/ with /, so do it:
location /string_1/ {
proxy_pass http://internal_host:port/;
}
14
You can use this rule:
^%(__prefix_line)sReceived disconnect from <HOST>: 11: (Bye Bye)? \[preauth\]$
To test it with fail2ban-regex or egrep, you can just strip off the ^%(__prefix_line)s from the beginning. Add this line to the failregex variable in your /etc/fail2ban/filter.d/sshd.conf.
A run with fail2ban-regex gave me these results, confirming ...
14
I found the way to rewrite the proxy_pass URL:
location /string_1/ {
if ($request_uri ~* "/string_1/(.*)") {
proxy_pass http://internal_host:port/$1;
}
}
Regards,
@pcamacho
13
sed -n "s/^.*\(captureThis\).*$/\1/p"
-n don't print lines
s substitute
^.* matches anything before the captureThis
\( \) capture everything between and assign it to \1
.*$ matches anything after the captureThis
\1 replace everything with captureThis
p print it
12
I'm not sure why that doesn't work but this does:
echo '[123]' | sed 's/\(\[\|\]\)//g'
or this:
echo '[123]' | sed -r 's/(\[|\])//g'
You can also try a different approach and match the string inside the brackets (assuming the string can be matched easily and is not defined by the brackets):
echo '[123]' | egrep -o "[0-9]+"
I'm having the same troubles ...
12
I ended up using the following solution:
location ~ ^/newsletter/(.*)$ {
location ~ /newsletter/one(.*) {
// logic here
}
// logic here
}
This matches all the paths under /newsletter/* and then I match all the paths that begin with /newsletter/one and apply the configuration for the newsletter/one in the inner configuration block ...
11
That expression will never match, since $ is in the middle of the string. Try:
server_name ~^(?<site_id>.+)\.dev\.example\.com$;
11
Well, after almost a day of hair pulling, I finally understand a) how to do it and b) a misconception I have about sec.
In reading the sec man page and it describes desc= as essentially showing the match. So in my mind, that meant it should show whatever was matched in pattern. Well, yes, that is true, in this case the match in that pattern is the; hostname,...
11
This line does it:
^%(__prefix_line)sConnection closed by <HOST> \[preauth\]$
Tested with the following logstring:
Apr 29 12:30:12 sendai sshd[25917]: Connection closed by 127.0.0.1 [preauth]
Successfully tested with:
$ fail2ban-regex ~/ssh.log sshd.conf
Running tests
=============
Use regex file : sshd.conf
Use log file : /home/user/ssh.log
...
10
There are cases where you need to be explicit about this, such as handling redirects for wildcard SSL with multiple levels of subdomains.
Matching end (hdr_end or -m end) or substring (hdr_sub or -m sub) can have unintended side-effects of matching more than you expect. In many cases this may not really matter, since you don't have traffic for those ...
10
The reason you don't have to escape / is that / is not a delimiter.
It sounds like you are accustomed to writing regular expressions in other applications, where a delimiter is required. For instance, in Perl you might write something like:
m/\/.serverfault/
The key here is that you chose the delimiter. There is nothing special about /. In fact, you could ...
9
Old post, but I faced the same problem recently.
The regex ^(https|git)(:\/\/|@)([^\/:]+)[\/:]([^\/:]+)\/(.+).git$ works for the three types of URL.
#!/bin/bash
# url="git://github.com/some-user/my-repo.git"
# url="https://github.com/some-user/my-repo.git"
url="git@github.com:some-user/my-repo.git"
re="^(https|git)(:\/\/|@)([^\/:]+)[\/:]([^\/:]+)\/(.+)....
github
9
(?P<name>pattern) is the standard PCRE syntax for named capture-groups - the documentation is missing a P.
The "Named Subpatterns" section on Wikipedia states that (?<name>...) and (?'name'...) are valid for PCRE 7.0 onwards; presumably your version of nginx is linked against an earlier version of PCRE.
9
As of logcheck 1.1.9.1 (which was released in 2002), blank lines, lines that only consist of [:space:] characters, and comments (lines that begin with #) are filtered out before the rule files are passed to egrep.
This is mentioned in passing in the "WRITING RULES" section of docs/README.logcheck-database, which is available in /usr/share/doc/logcheck-...
9
This works but has one flaw. It will also not match on "one" followed by any characters.
location ~ ^/newsletter/(?!one).*$ {
//configuration here
}
Although, this may be better:
location = /newsletter/one {
// do something (not serve an index.html page)
}
location ~ ^/newsletter/.*$ {
// do something else
}
This works because when Nginx ...
8
First thought is "Don't block websites". This is fundamentally a management/HR problem, not a technical one. If you really have problems with employees screwing-off instead of getting their work done, time for new employees. No that isn't a pleasant process, but I absolutely guarantee you'll be happier, more productive, and more profitable in the long run.
...
8
I believe that this website may help you greatly:
http://regex101.com/r/uP4nT1
8
You need to construct two regex's that are mutually exclusive: only one can be true at a time:
How about if you make the second item be a regex like:
^/path[^/]
The [^/] means "any character that is not /".
Here are three URLs that are mutually exclusive:
acl fb1 path_reg ^/path$ # Just /path
acl fb2 path_reg ^/path/$ # Just /path/
acl ...
8
Actually it's possible since Apache 2.4 (or less) using the tag as follow :
<LocationMatch "/test/upload.js">
<If "%{QUERY_STRING} =~ /query=test/">
..
'Your directives'
..
</If>
</LocationMatch>
In this configuration directives will be applied only in the case the URL ...
Only top voted, non community-wiki answers of a minimum length are eligible
