Yarn是一个用于node.js应用程序的高级包管理软件。它是任意一个其他Nodejs包管理器的快速、安全和可靠的替代方案，比npm更好的解决包依赖问题。本篇文章介绍在CentOS，Redhat和Fedora系统上安装Yarn的方法。

1、使用NPM安装Yarn

Yarn组件可与NPM一起安装。只需运行以下命令即可全局安装Yarn。另外，没有-g，就是仅为当前项目安装。

$ sudo npm install yarn -g

2、用脚本安装Yarn

这是安装Yarn最为推荐的方法。这将下载yarn档案并在home的.yarn目录下提取。脚本还设置了PATH环境变量。

$ curl -o- -L https://yarnpkg.com/install.sh | bash

使用此安装Yarn仅适用于当前用户。

3、使用yum安装Yarn

Yum Package Manager也提供Yarn安装包。可以使用以下命令配置yarn官方yum存储库：

$ curl -sL https://dl.yarnpkg.com/rpm/yarn.repo -o /etc/yum.repos.d/yarn.repo

现在运行下面的命令来安装它。

$ sudo yum install yarn    ## CentOS and Redhat systems 
$ sudo dnf install yarn    ## Fedora systems

可能会遇到的问题：

[root@host ~]# curl -sL https://dl.yarnpkg.com/rpm/yarn.repo -o /etc/yum.repos.d/yarn.repo
[root@host ~]# yum install yarn
已加载插件：fastestmirror
设置安装进程
Loading mirror speeds from cached hostfile
 * base: mirror.fileplanet.com
 * elrepo-kernel: repos.lax-noc.com
 * extras: repos-lax.psychz.net
 * updates: mirror.fileplanet.com
yarn                                                     | 2.9 kB     00:00 ... 
yarn/primary_db                                          |  22 kB     00:00     
解决依赖关系
--> 执行事务检查
---> Package yarn.noarch 0:1.22.4-1 will be 安装
--> 处理依赖关系 nodejs，它被软件包 yarn-1.22.4-1.noarch 需要
--> 完成依赖关系计算
错误：Package: yarn-1.22.4-1.noarch (yarn)
          Requires: nodejs
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

Yarn requires Node.js 4.0 or higher to be installed.
> Yarn was installed, but doesn't seem to be working :(.

这两种提示都是没有安装node，需要先安装nodejs。

下载

wget https://nodejs.org/dist/v12.16.1/node-v12.16.1-linux-x64.tar.xz

解压遇到问题

[root@host ~]# tar -xvf node-v12.16.1-linux-x64.tar.xz 
tar (child): xz：无法 exec: 没有那个文件或目录
tar (child): Error is not recoverable: exiting now
tar: Child returned status 2
tar: Error is not recoverable: exiting now

安装xz可以解决

yum install xz

解压并安装

[root@host ~]# tar -xvf node-v12.16.1-linux-x64.tar.xz 
[root@host ~]# cd node-v12.16.1-linux-x64
[root@host node-v12.16.1-linux-x64]# mkdir /usr/local/nodejs
[root@host node-v12.16.1-linux-x64]# mv * /usr/local/nodejs/

安装npm和node

ln -s /usr/local/nodejs/bin/npm /usr/local/bin/
ln -s /usr/local/nodejs/bin/node /usr/local/bin/

测试npm -v

[root@host bin]# npm -v
/usr/local/bin/node: /usr/local/bin/node: cannot execute binary file

这是为啥，原来是服务器配置低装的32bit系统不能运行64bit的包，或者你可能是反过来，重新下对应的包即可。可是node没有32位，只好换操作系统。

If it is necessary to transmit URI in the unprocessed form then directive proxy_pass should be used without URI part.

这段话的意思是如果你要保持输入的请求原样不变传给后端，那么你的proxy_pass指令就不能带有URI部分。

读起来比较晦涩，尤其是英文长句，举个实际例子：

#结尾不加/
 location /abc/ {
        proxy_pass http://10.1.12.123:8080;
 } 

#结尾添加/
location /abc/ {
        proxy_pass http://10.1.12.123:8080/;
 }

咋一看，这两个配置没什么区别。实际上最主要的区别就是proxy_pass指令后边有没有“/”，这部分内容叫做URI。

当请求是http://www.redis.com.cn/about/123时：

第一个配置处理之后传给后端应用的请求是 http://www.redis.com.cn/about/123 不变。

第二个配置会把请求 http://www.redis.com.cn/about/123 中与 location 匹配的部分（"/abc/"）替换为proxy_pass结尾的URI（ "/" ），变成 http://www.redis.com.cn/123

W3tc是一个wordpress速度优化插件，插件的运行需要很多php扩展，其中对html的优化需要用到tidy。

安装tidy库

yum install libtidy libtidy-devel -y

源码编译安装，进入php-fpm的源码路径

cd php-7.3.11/ext/tidy/

编译和安装tidy扩展库

/usr/local/php/bin/phpize
./configure --with-php-config=/usr/local/php/bin/php-config
make && make install

编辑php.ini

[root@VM_0_16_centos tidy]# vi /usr/local/php/etc/php.ini

去掉tidy.so前的分号

;extension=soap
;extension=sockets
;extension=sodium
;extension=sqlite3
extension=tidy
;extension=xmlrpc
;extension=xsl

重启php-fpm生效

location指令是nginx中最关键的指令之一，location指令的功能是用来匹配不同的url请求，进而对请求做不同的处理和响应，这其中较难理解的是多个location的匹配顺序，本文会作为重点来解释和说明。

开始之前先明确一些约定，我们输入的网址叫做请求URI，nginx用请求URI与location中配置的URI做匹配。

location格式

location有两种格式：

• 匹配uri类型，有四种参数可选，当然也可以不带参数。
• 命名location，用@来标识，类似于定义goto语句块。

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

location匹配参数解释

参数	解释
空	location后没有参数直接跟着URI，表示前缀匹配，代表跟请求中的URI从头开始匹配。
~	执行一个正则匹配，区分大小写。
~*	执行一个正则匹配，不区分大小写。
^~	普通字符匹配，多用来匹配目录。
=	执行普通字符精确匹配。
@	"@" 定义一个命名的 location，@定义的locaiton名字一般用在内部定向，例如error_page, try_files命令中。它的功能类似于编程中的goto。

location匹配顺序

nginx有两层指令来匹配请求URI。第一个层次是server指令，它通过域名、ip和端口来做第一层级匹配，当找到匹配的server后就进入此server的location匹配。location的匹配并不完全按照它们在配置文件中出现的顺序来匹配，请求URI会按如下规则跟server里配置的location匹配。

1. 寻找有没有“=”等号参数完全匹配的location，如果有完全匹配的等号location则停止匹配，执行该location中的指令，不去匹配其它类型的location。
2. 匹配所有非正则表达式URI的location(包括空，=，^~三种参数)。找到请求URI和location URI按前缀匹配最长的location，如果这个最长的location的参数是^~，则停止匹配，执行该location中的指令，否则暂存该location。
3. 匹配正则表达式URI的location(包括~，~*两种参数)，按location在配置文件中出现的顺序匹配，如果找到第一个匹配的locaiton则停止匹配，执行该location。
4. 匹配完所有正则表达式都没有匹配的location，则执行第二步中暂存的最长前缀匹配location。

简单来说按这个规则：
= > ~^ > ~ = ~* >最长前缀匹配 > /

匹配问号后的参数

请求URI中问号后面的参数是不能在location中匹配到的，这些参数存储在$query_string变量中，可以用if来判断。

例如，对于参数中带有单引号'进行匹配然后重定向到错误页面。

/plus/list.php?tid=19&mid=1124'

if ( $query_string ~* ".*[;'<>].*" ){
  return 404;
}

location URI结尾带不带/

这个很多解释不太准确，我有必要多说几句。

对于请求URI结尾是否带有/，一般的处理逻辑是带/表示访问目录，不带/表示访问文件，如果文件不存在也会去匹配目录。例如访问http://www.nginx.cn/images/和http://www.nginx.cn/images，前面的请求会匹配目录，后面的请求会先匹配文件，文件不存再匹配目录

对于locatioin中的URI来说，如果URI的结尾带有/，并且location要执行的命令式是proxy_pass、fastcgi_pass、uwsgi_pass、scgi_pass、memcached_pass、grpc_pass之一。例如:

location  /images/ {
  proxy_pass http://www.redis.com.cn
}

对于这种情况，nginx会做特殊处理，不管images命名的文件或目录存在不在，如果你访问http://www.nginx.cn/images会被重定向到http://www.nginx.cn/images/。

所以如果你想这两种请求对应不同的处理，就要明确增加不带/结尾的location配置。

location  /images {
  proxy_pass http://www.rabbitmq.cn
}
location  /images/ {
  proxy_pass http://www.redis.com.cn
}

命名location

带有"@"的location是用来定义一个命名的location，这种location不参与请求匹配，一般用在内部定向。例如用在error_page, try_files命令中。它的功能类似于编程中的goto。

location  /images {
  try_files $uri $uri/ @name;
}
location  @name {
  ...
}

例子

location  = / {
  # 只匹配请求 "/"
  [ configuration A ] 
}
location  / {
  # 匹配任何请求，因为所有请求都是以"/"开始
  # 但是更长字符匹配或者正则表达式匹配会优先匹配
  [ configuration B ] 
}
location /documents/ {
  # 匹配所有 /documents/ 开头的请求，在没有正则表达
  # 式匹配时选择该locaiton
  [ configuration C ]
}
location ^~ /images/ {
  # 匹配任何以 /images/ 开始的请求，并停止匹配其它location
  [ configuration D ] 
}E
location ~* .(gif|jpg|jpeg)$ {
  # 匹配以 gif, jpg, or jpeg结尾的请求. 
  # 但是所有 /images/ 目录的请求将由 [Configuration D]处理.   
  [ configuration E ] 
}

请求URI例子:

1. / -> 匹配A
2. /index.html -> 匹配B
3. /documents/a.html -> 匹配C
4. /images/1.gif -> 匹配D
5. /documents/1.jpg -> 匹配E

不知道有没有解释不清楚的地方，希望没把大家带沟里去。

留言告诉我吧。

nginx 1.17 已发布，这是 nginx 目前最新的版本，同时也是 mainline 主线版。

我们都知道，nginx 都会同时维护着两个分支，分别为 mainline 主线版和 stable 稳定版。

• mainline 是更新活跃的开发分支，其添加了最新功能和错误修复。其版本号的第二位用奇数表示，例如 1.17.0。
• stable 接收针对高严重性错误的修复，但不会使用最新的功能。其版本号的第二位用偶数表示，例如 1.16.0。

不过在 nginx 中，“稳定”指的是功能和更新频率，它与软件质量无关。稳定分支在其生命周期中从不接收新功能，并且通常仅接收一个或两个更新，用于修复严重的错误。

稳定分支的生命周期一般是一年，每年四月官方就会停止对当前稳定分支的维护，不再提供错误修复补丁。这会触发两个事件：

• 第一，官方会 fork 当前的 mainline 版本，以用于创建下一个稳定版本。这样一来，稳定分支就继承了过去一年中 mainline 版本的所有错误修复补丁、新增功能和其他变更。上个月发布的 nginx 1.16.0 稳定版就是 fork 自 1.15.12 mainline 版本。
• 第二，mainline 分支将会获得新的版本升级，即其版本号的第二位奇数会增加为下一个奇数，mainline 分支每 4-6 周就会发布一个新版本，nginx 1.17.0 是最新 mainline 版本的首次发布。

▲ 看图比较容易理解 nginx 版本的演进过程

生成环境应该选择nginx哪个版本

官方还建议用户采用主线分支，因为它能最快地用上新特性、性能改进和增强功能，还可以及时修复错误。总之，按官方的说法，主线分支完全适用于生产环境。

下面看看作为最新 mainline 版本的 1.17.0，包含了哪些新功能和改进。

nginx 1.17.0 包含对带有limit_rate指令的带宽限制配置中的变量的支持，并且允许该include指令在所有配置上下文中使用，甚至在if块内。

开发团队还开始支持 QUIC 和 HTTP/3（传输协议的下一次重大更新版本），它将应用到网站、应用程序和 API。

其他变更包括：

• 支持的最低 OpenSSL 版本为 0.9.8
• include 指令在“if”和“limit_except”块中不起作用
• ……

完整内容点此查看。

来源： https://www.oschina.net/news/106928/nginx-1-16-1-17-released

if指令用来判断条件为true时要执行的指令，条件false时不执行相应的指令，if指令只能用在server、location内。

01

if指令的格式如下：

if (condition) { ... }

condition可以是如下类型：

• 变量名，如果变量的值是空字符串或者0表示false
• 变量使用“=”和“!=”来跟字符串比较
• 可以是正则表达式
• 检查文件是否存在使用“-f” 和 “!-f”
• 检查目录是否存在使用 “-d” 和 “!-d”
• 检查文件、目录、符号链接是否存在使用 “-e” 和 “!-e”
• 检查是否是可执行文件使用“-x” 和 “!-x”

if指令不支持多条件、不支持嵌套、不支持else，与常见的条件表达式不同的是if指令等值比较使用单个等号＝而不是双等号==。

02

if是一个危险的指令，除了当判断一个变量的值时必须使用if的场景，其它情况使用if时都需要仔细思考可能会出现的执行结果，能不用就不用，稍不小心就会有意想不到的执行结果。我们大多数人都按过程化顺序编程思路来判断结果，但nginx还有很多上下文环境需要考虑。

比较安全的用法是满足if条件时只执行return指令。{}内尽量只使用下面两种指令。否则，nginx可能不会按照你预想顺序执行，严重的情况下nginx会段错误崩溃。

• return ...;
• rewrite ... last;

还有就是尽量别在location中使用if，在server中使用if相对会安全些。

03

如果要在location中使用if，最好用如下模版格式：

location / {
    error_page 418 = @other;
    recursive_error_pages on;
    if ($something) {
        return 418;
    }
    # some configuration
    ...
}
location @other {
    # some other configuration
    ...
}

04

nginx不支持下面这样的多条件if：

if ($request_method = POST && $http_cookie ~* "CCCC=.+(?:;|$)")

变通办法是：

if ($request_method = POST) {
    set $test  P;
  }
  if ($http_cookie ~* "CCCC=.+(?:;|$)" ) {
    set $test  "${test}C";
  }
  if ($test = PC) {
    #rewrite rule goes here.
  }

最后，有想深入了解if指令运行原理的同学，可以参考https://agentzh.blogspot.com/2011/03/how-nginx-location-if-works.html

chrome更新到最新版 版本 80.0.3987.122 之后打开chrome浏览器报错“喔唷 崩溃啦”。

网上找答案解决chrome的崩溃办法很多，几乎都没效果。

• 有一些说跟百度卫士冲突或者禁用沙盒（ -no-sandbox ）的方法，百度这个锅背的好无辜，我是新装的win10上面几乎什么都没装就报这个错误。
• 还有一些说是要禁用一些chrome的插件，我是新装的chrome，干净的没有插件，同时chrome://plugins/ 也一样是打不开，这个方法不好使。

后来实在没办法就退回老版本chrome，同时禁用更新，防止chrome联网自动升级成新版本。

但是很多网站会检测提示chrome版本旧，忍不了，一顿操作终于找到了解决办法，禁用 RendererCodeIntegrity

找到chrome快捷方式-右键属性-目标，再双引号后面先输入空格再输入--disable-features=RendererCodeIntegrity 。

需要注意的是，添加完成后，要关所有打开的chrome，重新启动才行。

这是目前唯一能解决chrome 喔唷 崩溃啦 的办法。主要原因还是仿病毒软件的锅，虽然我几乎啥也没装，但是我安装了SEP，SEP和chrome冲突，就会出现这个问题，当然可以升级SEP来解决，那些没办法升级SEP版本的同学试试上面的办法吧。

准备：

1. 有ssh权限
2. 域名使用dnspod解析
3. 开启dnspod的api
4. 设置ssh环境变量
5. 生成域名证书
6. 设置wordpress

1.需要你有一个能运行ssh命令行的云服务器。

2.把域名的dns服务器设置为dnspod。

2.dnspod如果没开API权限的，开启之后会得到ID和TOKEN，点击访问。建好之后及时记录ID和token，因为只在创建的时候显示一次，窗口关闭后就看不到了。

4. 设置ssh的环境变量为上面获取的id和token值，大小写要匹配

export DP_Id="id"
export DP_Key="token"

5.生成域名证书，执行lnmp dns dp

6.访问nginx，可以看到https全站开启成功。

可能会遇到的问题，不显示绿锁，是因为页面有非https链接。

1.设置wordpress的网址加入https。后台 ->设置 ->常规

2.查看页面还有哪些链接不是https开头，chrome F12->console可以看到Mixed Content，把其中的http替换为https。

3.对于已发布的文章内部有http链接，可以通过执行sql替换

update redis_posts set `post_content`=REPLACE (`post_content`,'http:','https:');

证书会利用crontab自动更新，如果更新失败可以手动强制更新。acme.sh --cron -f

使用pytinstaller打包命令：pyinstaller -F -w ***.py

打包过程中报 lib not found

运行程序报错： pyinstaller failed to execute script pyi_rth_qt5plugins

原因是打包命令找不到pyqt的路径，可以手工正定路径，命令中的...需要替换为你的python安装路径

pyinstaller --paths C:\...\Python35/Lib/site-packages/PyQt5/Qt/bin -F -w ccbd.py

http的情况系下，我们使用如下办法禁止未授权的域名指向我们的服务器。

 server {
    listen       80  default_server;
    server_name  _;
    return       444;
} 

如何把端口简单改成443，会宝如下错误

[root@VM_0_16_centos conf]# nginx -t
 nginx: [emerg] no "ssl_certificate" is defined for the "listen … ssl" directive in /usr/local/nginx/conf/nginx.conf:105
 nginx: configuration file /usr/local/nginx/conf/nginx.conf test failed

在我们未设置默认server的情况下，nginx会匹配配置中的第一个server来响应非自己绑定的域名。

这种情况下需要自己自定义一个签名证书来解决这个问题。

1.nginx的配置修改改为

server {
     listen 443 ssl;
     server_name _;
     ssl_certificate /usr/local/nginx/conf/ssl/default.crt;
     ssl_certificate_key /usr/local/nginx/conf/ssl/default.key;
     return       444;
 }

2.创建自定义的key

[root@VM_0_16_centos conf]# sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /usr/local/nginx/conf/ssl/default.key -out /usr/local/nginx/conf/ssl/default.crt
 Generating a 2048 bit RSA private key
 ………………………………………..+++
 ……………………+++
 writing new private key to '/usr/local/nginx/conf/ssl/default.key'
 You are about to be asked to enter information that will be incorporated
 into your certificate request.
 What you are about to enter is what is called a Distinguished Name or a DN.
 There are quite a few fields but you can leave some blank
 For some fields there will be a default value,
 If you enter '.', the field will be left blank.
 Country Name (2 letter code) [XX]:cn
 State or Province Name (full name) []:beijing
 Locality Name (eg, city) [Default City]:beijing
 Organization Name (eg, company) [Default Company Ltd]:default
 Organizational Unit Name (eg, section) []:default
 Common Name (eg, your name or your server's hostname) []:default
 Email Address []:default

3.重新加载配置

[root@VM_0_16_centos conf]# nginx -t
 nginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok
 nginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful
 [root@VM_0_16_centos conf]# nginx -s reload

80 443合并的例子

server {
    listen 443 ssl http2 default_server;
    listen [::]:443 ssl http2 default_server;
    server_name _;

    ssl_certificate /etc/nginx/ssl/nginx.crt;
    ssl_certificate_key /etc/nginx/ssl/nginx.key;
    ssl_session_tickets off;

    return 404;
}