月度归档：2018年12月

macOS 中‘/usr/bin’目录内添加命令，出现‘Operation not permitted’

发表评论

原由：

macOS 10.11 开始引入的系统完整性保护（Rootless），不再能够随心所欲的读写很多路径下了。设置 root 权限也不行。

Rootless机制将成为对抗恶意程序的最后防线

解决：

于是尝试关闭 Rootless。重启按住 Command+R，进入恢复模式，打开Terminal（终端）。

csrutil disable

重启即可。如果要恢复默认，那么

csrutil enable

附录:

csrutil命令参数格式：

csrutil enable [--without kext | fs | debug | dtrace | nvram][--no-internal]

禁用：csrutil disable

（等同于csrutil enable –without kext –without fs –without debug –without dtrace –without nvram）

其中各个开关，意义如下：

  • B0: [kext] 允许加载不受信任的kext（与已被废除的kext-dev-mode=1等效）
  • B1: [fs] 解锁文件系统限制
  • B2: [debug] 允许task_for_pid()调用
  • B3: [n/a] 允许内核调试 （官方的csrutil工具无法设置此位）
  • B4: [internal] Apple内部保留位（csrutil默认会设置此位，实际不会起作用。设置与否均可）
  • B5: [dtrace] 解锁dtrace限制
  • B6: [nvram] 解锁NVRAM限制
  • B7: [n/a] 允许设备配置（新增，具体作用暂时未确定）

通过Nodejs读取xml文件数据

发表评论

博客是通过hexo搭建的，发布到线上也就是html静态文件了，总不能每次发版更新一个json文件吧，然后想到sitemapx.xml文件来代替json文件，因为每次hexo发布代码都需要更新sitemapx.xml文件。所以就想到用Nodejs读取xml文件。

示例

目录树：

.
├── README.md
├── app.js
├── data
│   └── post-sitemap.xml
├── node_modules
│   ├── ...
├── package-lock.json
└── package.json

app.js

const fs = require('fs');
const xml2js = require('xml2js');
const parser = xml2js.Parser();

fs.readFile('./data/post-sitemap.xml', function (err, data) {
    parser.parseString(data, function (err, res) { 
        console.dir(res);
        console.log(res.urlset.url);
    });
})

代码仓库

https://github.com/Keystion/nodejs-read-xml-example

依赖

【转】一文弄懂Nginx的location匹配

发表评论

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

语法规则

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

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

修饰符

  • = 表示精确匹配。只有请求的url路径与后面的字符串完全相等时，才会命中。
  • ~ 表示该规则是使用正则定义的，区分大小写。
  • ~* 表示该规则是使用正则定义的，不区分大小写。
  • ^~ 表示如果该符号后面的字符是最佳匹配，采用该规则，不再进行后续的查找。

匹配过程

对请求的url序列化。例如，对%xx等字符进行解码，去除url中多个相连的/，解析url中的.，..等。这一步是匹配的前置工作。

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

具体的匹配过程如下：

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

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

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

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

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

  1. 使用正则定义的location在配置文件中出现的顺序很重要。因为找到第一个匹配的正则后，查找就停止了，后面定义的正则就是再匹配也没有机会了。
  2. 使用精确匹配可以提高查找的速度。例如经常请求/的话，可以使用=来定义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配置有关，其他两点无关。

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

总结

location的配置有两种形式，前缀字符和正则。查找匹配的时候，先查找前缀字符，选择最长匹配项，再查找正则。正则的优先级高于前缀字符。

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

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

拓展

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