Hiển thị các bài đăng có nhãn Nginx. Hiển thị tất cả bài đăng
Hiển thị các bài đăng có nhãn Nginx. Hiển thị tất cả bài đăng

Thứ Tư, 15 tháng 5, 2019

CLEAN URL REWRITES USING NGINX

This article will cover how to easily implement Clean URLs (also known as Semantic URLs, RESTful URLs, User-Friendly URLs and Search Engine-Friendly URLs) using NGINX Web Server; currently the second most popular web server platform worldwide.
Not using NGINX web server? No problem, Apache users can check out my article Clean URL Rewrites Using Apache.
A Clean URL is a URL that does not contain query strings or parameters. This makes the URL easier to read and more understandable to users. 

Clean URLs are a high ranking factor for many search engines, but there are many other reasons why having Clean URLs can be important to your website. Check out our article Are your URLs Letting Your Website Down for more information.

Nginx rewrite rules for MyBB SEO friendly URLs

I've recently switched a forum I run from Wordpress and bbPress to MyBB. Overall I've very happy with it but there are a few bits to watch out for with MyBB.
If you are running Nginx instead of Apache as your webserver then one of those things to watch out for is the need to manually update the rewrite rules needed for SEO friendly URLs.

MyBB SEO friendly URLs

Below is the full set of Nginx rewrite rules for rewriting MyBB's SEO friendly URLs. To activate this option in MyBB you can do so from the Admin CP:
Admin CP > Configuration > Settings > Server and Optimization Options > Enable search engine friendly URLs? = Enabled
You can also enable the "Enable search engine friendly URLs in Archive?" option - it's the option under the "Enable search engine friendly URLs?".
If you decide to enable just the "Enable search engine friendly URLs?" option you can use the following nginx rewrite rules:
rewrite ^/forums/forum-([0-9]+)\.html$ /forums/forumdisplay.php?fid=$1;
rewrite ^/forums/forum-([0-9]+)-page-([0-9]+)\.html$ /forums/forumdisplay.php?fid=$1&page=$2;
rewrite ^/forums/thread-([0-9]+)\.html$ /forums/showthread.php?tid=$1;
rewrite ^/forums/thread-([0-9]+)-page-([0-9]+)\.html$ /forums/showthread.php?tid=$1&page=$2;
rewrite ^/forums/thread-([0-9]+)-lastpost\.html$ /forums/showthread.php?tid=$1&action=lastpost;
rewrite ^/forums/thread-([0-9]+)-nextnewest\.html$ /forums/showthread.php?tid=$1&action=nextnewest;
rewrite ^/forums/thread-([0-9]+)-nextoldest\.html$ /forums/showthread.php?tid=$1&action=nextoldest;
rewrite ^/forums/thread-([0-9]+)-newpost\.html$ /forums/showthread.php?tid=$1&action=newpost;
rewrite ^/forums/thread-([0-9]+)-post-([0-9]+)\.html$ /forums/showthread.php?tid=$1&pid=$2;
rewrite ^/forums/post-([0-9]+)\.html$ /forums/showthread.php?pid=$1;
rewrite ^/forums/announcement-([0-9]+)\.html$ /forums/announcements.php?aid=$1;
rewrite ^/forums/user-([0-9]+)\.html$ /forums/member.php?action=profile&uid=$1;

Activating SEO friendly URLs in Archive

If you activate the "Enable search engine friendly URLs in Archive?" option you'll need the following extra rewrite rules:
rewrite ^/forums/archive/index.php/forum-([0-9]+)\.html$ /forums/archive/index.php?forum-$1.html;
rewrite ^/forums/archive/index.php/thread-([0-9]+)\.html$ /forums/archive/index.php?thread-$1.html;
rewrite ^/forums/archive/index.php/forum-([0-9]+)-([0-9]+)\.html$ /forums/archive/index.php?forum-$1-$2.html;
rewrite ^/forums/archive/index.php/thread-([0-9]+)-([0-9]+)\.html$ /forums/archive/index.php?thread-$1-$2.html;
At first glance the second set of rules might not seem essential, but it's those rules that enable pagination. Without them you'll just get 404 errors for page 2 or above on any of the archive forum or thread lists.

Thứ Hai, 4 tháng 12, 2017

Making simple Splunk Nginx dashboard

As a DevOps guy I often do incident analysis, post deployment monitoring and usual logs checks. If you also is using Splunk as me when let me show for you few effective Splunk commands for Nginx logs monitoring.

Extract fileds

To make commands works Nginx log fields have to be extracted into variables.
Where are 2 ways to extract fields:
  1. By default Splunk recognise “access_combined” log format which is default format for Nginx. If it is your case congratulations nothing to do for you!
  2. For custom format of logs you will need to create regular expression. Splunk has built in user interface to extract fields or you can provide regular expression manually.

Thứ Hai, 6 tháng 11, 2017

How to Redirect Nginx traffic based on the Client’s IP Address

Sometimes developers need to redirect part of their traffic to another web area or specific URL. Depending on the IP address the visitors have, it’s ideal to geo-locate traffic or simply protect areas from unwanted specific IP addresses. So, how do you redirect traffic from IP 1.2.3.4 to http://www.thisurl.com/page2.html and the rest of the traffic to http://www.thisurl.com/? We’ll go over this today.

Redirect using Nginx HttpAccessModule

As Nginx supports conditional configurations, first let’s look at an example of how to redirect traffic using HttpAccessModule running a regex against $remote_addr variable.
server {
if ($remote_addr = 1.2.3.4) {
rewrite ^ http://www.yourwebsite.com/otherpage.htm;
}
}
In this example, 1.2.3.4 is the IP address you want to redirect.

Chủ Nhật, 22 tháng 10, 2017

Nginx: 24: Too Many Open Files Error And Solution

How do I fix this problem under CentOS / RHEL / Fedora Linux or UNIX like operating systems?

Linux / UNIX sets soft and hard limit for the number of file handles and open files. You can use ulimit command to view those limitations:
su - nginx
To see the hard and soft values, issue the command as follows:
ulimit -Hn
ulimit -Sn

Increase Open FD Limit at Linux OS Level

Your operating system set limits on how many files can be opened by nginx server. You can easily fix this problem by setting or increasing system open file limits under Linux. Edit file /etc/sysctl.conf, enter:
# vi /etc/sysctl.conf
Append / modify the following line:
fs.file-max = 70000
Save and close the file. Edit /etc/security/limits.conf, enter:
# vi /etc/security/limits.conf
Set soft and hard limit for all users or nginx user as follows:
nginx       soft    nofile   10000
nginx       hard    nofile  30000
Save and close the file. Finally, reload the changes with sysctl command:
# sysctl -p

Chủ Nhật, 18 tháng 12, 2016

Analyzing DDoS Attack with Nginx log

In this small post I would like to show a few useful commands to use if someone is experiencing a DDoS attack. In my case, there is an nginx as a front-end server. The access log format looks like this:

log_format main '$remote_addr — $remote_user [$time_local] "$host" "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" -> $upstream_response_time';

In the log file we’ll see something like this:

188.142.8.61 — - [14/Sep/2014:22:51:03 +0400] «www.mysite.com» «GET / HTTP/1.1» 200 519 «kiloccnp.com.vn/» «Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.191602; .NET CLR 3.5.191602; .NET CLR 3.0.191602» "-" -> 0.003

Thứ Sáu, 11 tháng 11, 2016

Cấu hình Nginx redirect

Redirect non-WWW sang WWW

Sửa file cấu hình của nginx (nginx.conf) thì bạn hãy sửa file cấu hình cho từng domain trong folder /etc/nginx/conf.d/

Single domain

server {
        server_name example.com;
        return 301 $scheme://www.example.com$request_uri;
}

All domains

Bảo vệ thư mục trong Nginx

Khi sử dụng Apache, thông thường để bảo vệ thư mục chúng ta thường sử dụng file .htaccess và .htpasswd. Tuy nhiên, Nginx lại không hỗ trợ .htaccess. Các bạn hãy xem hướng dẫn Basic HTTP Authentication bên dưới để có thể thực hiện bảo vệ thư mục trong Nginx.
Mục tiêu
Bảo vệ thư mục http://example.com/test/ với đường dẫn server là /home/example.com/public_html/test/, file cấu hình Nginx /etc/nginx/conf.d/example.com.conf

1. Tạo file Password

Tuning NGINX Configuration

The following are some NGINX directives that can impact performance. As stated above, we only discuss directives that are safe for you to adjust on your own. We recommend that you not change the settings of other directives without direction from the NGINX team.

Worker Processes

NGINX can run multiple worker processes, each capable of processing a large number of simultaneous connections. You can control the number of worker processes and how they handle connections with the following directives:

Creating NGINX Rewrite Rules

Comparing the return, rewrite, and try_files Directives

The two directives for general‑purpose NGINX rewrite are return and rewrite, and the try_files directive is a handy way to direct requests to application servers. Let’s review what the directives do and how they differ.

The return Directive

The return directive is the simpler of the two general‑purpose directives and for that reason we recommend using it instead of rewrite when possible (more later about the why and when). You enclose the return in a server or location context that specifies the URLs to be rewritten, and it defines the corrected (rewritten) URL for the client to use in future requests for the resource.
Here’s a very simple example that redirects clients to a new domain name:
server {
    listen 80;
    listen 443 ssl;
    server_name www.old-name.com;
    return 301 $scheme://www.new-name.com$request_uri;
}

NGINX Tuning 1

Backup your original configs and you can start reconfigure your configs. You will need to open your nginx.conf at /etc/nginx/nginx.conf with your favorite editor.


# you must set worker processes based on your CPU cores, nginx does not benefit from setting more than that
worker_processes auto; #some last versions calculate it automatically

# number of file descriptors used for nginx
# the limit for the maximum FDs on the server is usually set by the OS.
# if you don't set FD's then OS settings will be used which is by default 2000
worker_rlimit_nofile 100000;

# only log critical errors
error_log /var/log/nginx/error.log crit;

# provides the configuration file context in which the directives that affect connection processing are specified.
events {
    # determines how much clients will be served per worker
    # max clients = worker_connections * worker_processes
    # max clients is also limited by the number of socket connections available on the system (~64k)
    worker_connections 4000;

Các vấn đề liên quan tới session của Nginx

Nginx một web services khá mạnh cho hiện tượng C10k . Có rất nhiều cấu hình của nó mà mình đã xem qua . Đa phần sysadmin không tìm hiểu kỹ về nó , đưa ra những tham số rất nguy hiểm cho hệ thống . Và vấn đề giải quyết các session như thế nào luôn làm các sysadmin lúng túng ,đôi khi phó mặc cho Dev phía dưới giải quyết vẫn đề này .

 Trước khi đi vào chi tiết cách giải quyết vấn đề này , đảo qua một chút về các thuật toán liên quan tới cân bằng tài của Nginx .

  • round-robin —Khi Client gửi kết nối tới server , Nginx sẽ tuần tự gửi gói tin tới những backend phía sau . 
  • least-connected — request tiếp theo của client sẽ đc gán tới backend có ít kết nối nhất .
  • ip-hash — Đây là một "hash-funcsion" (chức năng băm ) . Được sử dụng để xác định máy chủ phục vụ dựa trên địa chỉ client .
Mặc định của Nginx sử dụng thuật toán round-robin với cấu hình :

http {
    upstream myapp1 {
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://myapp1;
        }
    }
}
Khi muốn sử dụng thuật toán least-connected chỉ cần khai báo

upstream myapp1 {
        least_conn;
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }
Với 2 thuật toán này Nginx hoàn toàn koo giữ đc các session giữa client và server backend , điều này phụ thuộc vào phía ứng dụng keep các phiên làm việc tới client có thể dự trên memcache hoặc redit . . .

Thuật toán ip_hash hay còn gọi là " Session persistence " hay "Session Sticky " (duy trì phiên ) sẽ giúp việc giữ các kết nối từ 1 client tới 1 backend trong upstream nhất định . Với ip-hash, địa chỉ IP của client sẽ được sử dụng như một hashing key để xác định máy chủ dịch vụ . Phương pháp này đảm bảo rằng ,những request từ một IP sẽ được 1 máy chủ phục vụ .
upstream myapp1 {
    ip_hash;
    server srv1.example.com;
    server srv2.example.com;
    server srv3.example.com;
}

Nhưng Session persistence có tới 3 phương pháp để lưu trữ các session

1. Session Persistence Method: Cookie Insertion

upstream backend {
    server webserver1;
    server webserver2;

    sticky cookie srv_id expires=1h domain=.example.com path=/;
}

2. Session Persistence Method: Learn

upstream backend {
   server webserver1;
   server webserver2;

   sticky learn create=$upstream_cookie_sessionid
       lookup=$cookie_sessionid
       zone=client_sessions:1m
       timeout=1h;
}

3. Session Persistence Method: Sticky Routes

upstream backend {
   server webserver1 route=a;
   server webserver2 route=b;

   # $var1 and $var2 are run-time variables, calculated for each request
   sticky route $var1 $var2;
}