一 普通用户使用1024以下端口启动nginx
'报错'： nginx: [emerg] bind() to 0.0.0.0:443 failed (13: Permission denied)
背景： 对于非root权限用户'不能'使用1024以下的端口,因为'过高'的权限,会带来一定的'风险'
① 方式1
1) chown root nginx --> 'nginx可执行文件'
2) chmod u+s nginx --> 'nginx可执行文件' --> "SetUID"方式
说明： 让'nginx'用户加入'root'用户组,并且给's'特殊权限位,让nginx运行在root权限下
特点： ps -ef |grep nginx 查看的时候，nginx的主进程是运行在'root'下的
备注： 虽然是可以'让普通用户'运行nginx服务,但是'不是所有nginx进程'都在用户本身下运行
② 方式2
1）iptables'端口转发'
2) iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080
描述： 使用'1024以上端口[假定8080]'启动程序,然后再用iptables做一个'端口转发'
3）缺点：额外增加'开销',负载低的情况可以,'负载高了'就不太好了
③ 方式3
1) 前提条件： 'nginx内核 >2.1'
2) 赋予'普通用户'执行'nginx可执行文件'监听'1024以下'端口的能力
setcap 'cap_net_bind_service=+ep' /usr/local/nginx/sbin/nginx
注意： 只有'root'等超级用户才能执行'setcap'操作
备注： setcap 一般用于'二进制可执行文件',setcap 用于'脚本文件时无效'
特点： nginx可执行文件会变成'红色'
补充： 'e'是有效'Effective',p''是允许'Permitted'
细节： 'setcap'命令行设置是'临时'的,重启系统就会'失效'
3) 推荐'使用'
备注：可以直接用'普通用户'启用nginx了,并且可以在'高负载'情况下,减少由于端口转发部分的负载开销
建议： '启动用户'和'user'保持一致
4) 查看和删除
[1]、getcap nginx --> '查看'
[2]、setcap -r nginx --> '清除remove'所有的'附加'权限
思考： 如果取消'cap的某一个'权限呢?
linux系统cap能力讲解 setcap和getcap指令常见用法
④ 题外话cp和mv
背景： cp之后,nginx可执行文件的'cap_net_bind_service=+ep'属性丢失
原因： 这个'属性'是跟文件的'innode'号绑定的,cp之后innode改变
+++++++++++++ "mv和cp的区别" +++++++++++++
1) '功能'和'metdata'上的区别
[1] mv
1、用户可以使用该命令为文件或目录'重命名'
2、将文件由一个目录'移入'另一个目录中
重点： mv不会修改'文件的属性',可以通过'stat'命令查看
inode角度: 将存储于'indoe索引节点上的文件元信息'也指向到'新的文件名'中
[2] cp '功能'
特点： 该命令的功能是将给出的文件或目录'拷贝(备份)'到另一文件或目录中,相当于'新建'
inode角度: 只会复制'文件数据','不会'复制inode索引节点上的文件'元信息'
++++++++++++++++ "分割线" ++++++++++++++++
问题引入：
1) 在对nginx做'日志切割'的时候
2) 为什么对日志进行'mv'移动之后
例如： mv access{,.$(date +%F)}.log
3) 业务日志不往'新生成'的文件写日志,而是mv'之后'的文件中
原因分析：
1）这是因为nginx进程'读写日志文件'时，是通过'fd文件描述符'去操作的
2) 虽然我们修改了原"access.log"文件的文件名
3) 但是'原文件描述符'与'文件本身'的对应关系仍然存在
解读策略：
[1]、mv'重命名'后,我们需要让nginx重新打开一个'新'文件,以便将新的日志写入到'新文件'中
具体： nginx -s reopen
等价： kill -USR1 `cat /usr/local/nginx/logs/nginx.pid` --> 'pid文件位置'
reopen'不生效'的一个场景：
1) 先'cp access.log access.logbak',再'rm access.log'
2) 然后'mv access.logbak access.log' --> '文件名存在,reopen不生效',日志也不会写入
3) 最后'-s reopen' 不生效
fd和innode的区别
结论：
1) fd 是根据'进程'来的,每一个进程不同,fd也就不同
2) inode 是'唯一'确定的
为什么vim编辑文件会改变文件inode编号
1) 默认行为 --> 'backupcopy=no'
[1]、会使用'rename [对应mv命令]'将wzj.txt更名为'wzj.txt~'，原wzj.txt文件'消失'
[2]、然后再创建'新'的wzj.txt文件，向其中'写入'对应内容。
[3]、在此过程中,由于新创建了wzj.txt文件'inode编号'发生改变
2) 推荐 --> 'backupcopy=yes'
[1]、会创建'空'的'wzj.txt~'文件,并将wzj.txt文件的内容'copy'到wzj.txt~中
[2]、然后再对wzj.txt进行修改,此时'相当于'是对'原文件'进行修改
[3]、在此过程中,inode编号'不会'发生变化
二 nginx相对路径
问题1： nginx配置文件中关于'相对路径'是相对哪里的?
问题2： 原生的Nginx中相对路径的'场景'? 或者说'哪些指令'可以使用相对路径?
问题3： nginx生成'文件或目录'的权限和属性? --> '启动用户'还是'user指令'
① 路径说明
查看'选项'： nginx -V 2>&1 | sed 's/ /\n/g' | grep -E '^--' --> 'rpm安装默认'
1) --prefix=/etc/nginx '安装'路径
2) --sbin-path=/usr/sbin/nginx nginx'执行文件'位置
--modules-path=/usr/lib64/nginx/modules 模块'路径'
--conf-path=/etc/nginx/nginx.conf '主'配置文件
--error-log-path=/var/log/nginx/error.log '错误'日志所在位置
--http-log-path=/var/log/nginx/access.log '访问'日志所在位置
--pid-path=/var/run/nginx.pid '进程id'=所在位置
--lock-path=/var/run/nginx.lock 锁路径,防止'重复'启动nginx
--http-client-body-temp-path=/var/cache/nginx/client_temp '客户'缓存
--http-proxy-temp-path=/var/cache/nginx/proxy_temp '代理'缓存
备注： '源码'编译-->'见下图',我们一般只指定'--prefix'安装路径
注意： 源码编译和rpm安装的'区别' --> 暂时'只关注'路径
② 相对路径
前言“ 只列举'常用'的
1) include '相对|绝对路径'
思考：include可以使用哪些'通配符'? --> 常见是'*'
'意外'之喜： nginx的'include'使用'glob()' function pattern expansion -->'复杂场景'
补充： include 指令值'不能'使用'变量'
强调： include是相对路径是相对'nginx主配置文件' ps: 主配置文件不一定必须是'nginx.conf'
建议： 非必须的话,建议使用'绝对路径',不会产生'歧义'
nginx配置文件中忽略不存在的include文件 glob glob模式
题外话： redis数据库中的'订阅、发布'功能中也使用'glob'
glob: 最常用的'通配符'是 '*、?、[…]';'{}'不是glob支持的,而是shell扩展的
2) 动态'dynamic'模块、'lock'、'pid'
3) '日志'相关和'core'转储文件
4) '缓存'、'客户端请求体临时缓存'、'后端相应体临时缓存'
遗留： alias似乎不能使用'相对路径'?
5) 'ssl'相关 --> "证书路径"
nginx的ssl模块
从通用规则中学习NGINX模块的定制指令
精彩链接
您阅读本篇文章共花了：
发表评论