Category: linux

nginx IF判断表达式

一、if语句中的判断条件(nginx)

1、正则表达式匹配：

==:等值比较;
~：与指定正则表达式模式匹配时返回“真”，判断匹配与否时区分字符大小写；
~*：与指定正则表达式模式匹配时返回“真”，判断匹配与否时不区分字符大小写；
!~：与指定正则表达式模式不匹配时返回“真”，判断匹配与否时区分字符大小写；
!~*：与指定正则表达式模式不匹配时返回“真”，判断匹配与否时不区分字符大小写；

继续阅读nginx IF判断表达式

NC的命令使用详解

netcat是网络工具中的瑞士军刀，它能通过TCP和UDP在网络中读写数据。通过与其他工具结合和重定向，你可以在脚本中以多种方式使用它。使用netcat命令所能完成的事情令人惊讶。

netcat所做的就是在两台电脑之间建立链接并返回两个数据流，在这之后所能做的事就看你的想像力了。你能建立一个服务器，传输文件，与朋友聊天，传输流媒体或者用它作为其它协议的独立客户端。

下面是一些使用netcat的例子.
继续阅读NC的命令使用详解

Nginx location规则详解

由于团队在进行前后端分离，前端接管了Nginx和node层，在日常的工作中，跟Nginx打交道的时候挺多的。之前对location的匹配规则是一知半解的，为了搞明白location是如何匹配的，查了些资料总结此文。希望能给大家带来帮助。

语法规则

location [ = | ~ | ~* | ^~ ] uri { ... }
location @name { ... }

语法规则很简单，一个location关键字，后面跟着可选的修饰符，后面是要匹配的字符，花括号中是要执行的操作。

修饰符
= 表示精确匹配。只有请求的url路径与后面的字符串完全相等时，才会命中。
~ 表示该规则是使用正则定义的，区分大小写。
~* 表示该规则是使用正则定义的，不区分大小写。
^~ 表示如果该符号后面的字符是最佳匹配，采用该规则，不再进行后续的查找。
匹配过程
对请求的url序列化。例如，对%xx等字符进行解码，去除url中多个相连的/，解析url中的.，..等。这一步是匹配的前置工作。

location有两种表示形式，一种是使用前缀字符，一种是使用正则。如果是正则的话，前面有~或~*修饰符。

具体的匹配过程如下：

首先先检查使用前缀字符定义的location，选择最长匹配的项并记录下来。

如果找到了精确匹配的location，也就是使用了=修饰符的location，结束查找，使用它的配置。

然后按顺序查找使用正则定义的location，如果匹配则停止查找，使用它定义的配置。

如果没有匹配的正则location，则使用前面记录的最长匹配前缀字符location。

基于以上的匹配过程，我们可以得到以下两点启示：

使用正则定义的location在配置文件中出现的顺序很重要。因为找到第一个匹配的正则后，查找就停止了，后面定义的正则就是再匹配也没有机会了。
使用精确匹配可以提高查找的速度。例如经常请求/的话，可以使用=来定义location。
示例
接下来我们以一个例子来具体说明一下匹配过程。

假如我们有下面的一段配置文件：

location = / {
    [ configuration A ]
}

location / {
    [ configuration B ]
}

location /user/ {
    [ configuration C ]
}

location ^~ /images/ {
    [ configuration D ]
}

location ~* \.(gif|jpg|jpeg)$ {
    [ configuration E ]
}

请求/精准匹配A，不再往下查找。

请求/index.html匹配B。首先查找匹配的前缀字符，找到最长匹配是配置B，接着又按照顺序查找匹配的正则。结果没有找到，因此使用先前标记的最长匹配，即配置B。

请求/user/index.html匹配C。首先找到最长匹配C，由于后面没有匹配的正则，所以使用最长匹配C。
请求/user/1.jpg匹配E。首先进行前缀字符的查找，找到最长匹配项C，继续进行正则查找，找到匹配项E。因此使用E。

请求/images/1.jpg匹配D。首先进行前缀字符的查找，找到最长匹配D。但是，特殊的是它使用了^~修饰符，不再进行接下来的正则的匹配查找，因此使用D。这里，如果没有前面的修饰符，其实最终的匹配是E。大家可以想一想为什么。

请求/documents/about.html匹配B。因为B表示任何以/开头的URL都匹配。在上面的配置中，只有B能满足，所以匹配B。

location @name的用法
@用来定义一个命名location。主要用于内部重定向，不能用来处理正常的请求。其用法如下：

location / {
    try_files $uri $uri/ @custom
}
location @custom {
    # ...do something
}

上例中，当尝试访问url找不到对应的文件就重定向到我们自定义的命名location（此处为custom）。

值得注意的是，命名location中不能再嵌套其它的命名location。

URL尾部的/需不需要
关于URL尾部的/有三点也需要说明一下。第一点与location配置有关，其他两点无关。

location中的字符有没有/都没有影响。也就是说/user/和/user是一样的。
如果URL结构是https://domain.com/的形式，尾部有没有/都不会造成重定向。因为浏览器在发起请求的时候，默认加上了/。虽然很多浏览器在地址栏里也不会显示/。这一点，可以访问baidu验证一下。
如果URL的结构是https://domain.com/some-dir/。尾部如果缺少/将导致重定向。因为根据约定，URL尾部的/表示目录，没有/表示文件。所以访问/some-dir/时，服务器会自动去该目录下找对应的默认文件。如果访问/some-dir的话，服务器会先去找some-dir文件，找不到的话会将some-dir当成目录，重定向到/some-dir/，去该目录下找默认文件。可以去测试一下你的网站是不是这样的。
总结
location的配置有两种形式，前缀字符和正则。查找匹配的时候，先查找前缀字符，选择最长匹配项，再查找正则。正则的优先级高于前缀字符。

正则的查找是按照在配置文件中的顺序进行的。因此正则的顺序很重要，建议越精细的放的越靠前。

使用=精准匹配可以加快查找的顺序，如果根域名经常被访问的话建议使用=。

转载自:https://segmentfault.com/a/1190000013267839

Nginx 使用$hostname做为access_log名中的坑

在多节点部署的情况下，需要对nginx日志文件按节点名[hostname]做区分，但实际使用中发现日志文件夹中并没有输出这种文件，本以为access_log中不支持这个变量，其实看到error_log中的日志发现了问题所在。

        access_log  /logs/nginx/prd-$hostname-access.log main;

继续阅读Nginx 使用$hostname做为access_log名中的坑

MySQL复制报错（Slave failed to initialize relay log info structure from the repository）

机器重启以后，主从出现了问题，具体报错信息：

Slave failed to initialize relay log info structure from the repository

解决方案：
继续阅读MySQL复制报错（Slave failed to initialize relay log info structure from the repository）

logrotate参数说明

logrotate 是 Linux 下的一个日志管理工具。通过 logrotate 可以很轻松地管理（拆分、压缩等）系统的所有日志文件。 通过配置，我们可以按日志大小或者固定周期来管理日志文件。

安装 logrotate

yum install logrotate

打开配置文件

vim /etc/logrotate.conf

在文件最后增加以下配置

/PATH/TO/YOUR/LOG/*.log {
    daily          # 按日，也可以 weekly 按周，monthly 按月
    dateext        # 增加日期作为后缀
    missingok      # 如果文件不存在，忽略错误信息
    rotate 30      # 保留 30 份
    compress       # 压缩
    delaycompress  # 延迟压缩，也就是本次拆分的文件在下次执行时再压缩
    notifempty     # 忽略空白文件
    copytruncate   # 拆分文件后，清空原有文件，而不是创建一个新文件
    su root root   # 解决没权限的问题
}

马上执行 logrotate

sudo /usr/sbin/logrotate -f /etc/logrotate.conf

查看你的 log 文件所在目录，应该可以得到类似这个的结果

-rw-r--r-- 1 deploy deploy  0K 2012-06-27 23:39 production.log
-rw-r--r-- 1 deploy deploy  27M 2012-06-27 23:15 production.log-20181217

nginx开发参数调整

无论是看过的nginx有关书还是网上看到的有关nginx 配置说明的文章（http://wiki.nginx.org/EventsModule#worker_connections），无一例外，在讲到 worker_connections 和 max_clients这两个概念的关系时都一致的一笔带过，尤其是在讲到nginx作为反向代理时max_clients的计算时，都是想当然的贴出max_clients = worker_processes * worker_connections/4这个理论计算公式来。既然是理论公式，那么为什么要除以4呢？肯定是有原因的吧。我相信有些人是知道如何计算的，但是很多人都如我一样一眼扫过，真正等到别人或者自己问自己的时候就真的感觉是云里雾里，不知所以然了。
继续阅读nginx开发参数调整