nginx rewrite导致的会话问题 异常问题之重新登录 某项目反馈编辑报表页面点击任意按钮会弹出重新登录，很是怪异。 排查 通过浏览器确定了复现问题时候ng的会话变了，那么可以知道后续转发到tomcat就会有新会话，导致重新登录 首先排查了ng配置，没有发现跳转到新tomcat的相关内容，主要是故障漂移等没有触发，那么会话变化不是这里影响 ng开启了upsteam的日志，发现在复现操作的时候有一个跳转，之后upstream地址都变了，于是找到前后相关的请求，并且在浏览器的请求中对比，发现某个请求的上下文路径掉了，于是有了以下解释： 正常情况下，ng的会话是带了上下文路径的，但是这里某个请求没有路径，导致请求到达ng之后会通过rewrite重写来重新定位到此路径上，于是就返回了一个新的会话id，并且分配一个新的tomcat，最终ng会话，tomcat会话都变了，需要重新登录 有了这个推论，那么解决的话只需要开发把这个路径丢失的路径补上就好了。但是和开发交流的过程中发现了另外一个问题，不管是路径丢失还是什么其他错误请求，是不应该覆盖我当前会话的，在这个问题中，用户没有登出的情况下，最终浏览器的会话被覆盖，这也是一个不能接受的问题！于是通过排查浏览器跳转，发现当浏览器给出任意错误路径，请求中是没有cookie，但是响应给出的cookie有异常，如下： 请求的路径不是我们所需的xnzhjtcx，但是cookie却给他设置了值，导致覆盖。根据结果猜测过程，说明此请求是到达了tomcat，才返回路径和cookie，所以当前ng所做的操作可能包括：本地重写了地址，然后发往后端，但用原地址返回。在发往后端的时候发现没有cookie，认为是新请求。 附重写过程中的302： 附ng配置： server { ... if ( $request_uri !~ ^/(xnzhjtcx/.*|xnzhjtcx$) ) { rewrite ^ /xnzhjtcx; } location /xnzhjtcx { proxy_pass http://lb; } } 如何解决 要解决上面任意地址导致cookie覆盖的问题，既然是重写导致，那就需要从这里解决，尝试了如下方案： 在rewrite后面写带根的路径，请求没有cookie，响应设置了路径和cookie，但浏览器没有显示重定向（结果不行） 附ng配置： # 比较奇怪的是此rewrite之后浏览器返回的是200，而不是30x server { ... if ( $request_uri !~ ^/(xnzhjtcx/.*|xnzhjtcx$) ) { rewrite ^ /xnzhjtcx/; } location /xnzhjtcx { proxy_pass http://lb; } } rewirte后面接绝对地址，请求没有cookie，响应没有返回cookie（结果可以） 附ng配置： # 此配置返回30x但没有任何cookie server { ... if ( $request_uri !~ ^/(xnzhjtcx/.*|xnzhjtcx$) ) { rewrite ^ http://61.242.140.32:9100/xnzhjtcx/; } location /xnzhjtcx { proxy_pass http://lb; } } 使用location来配合重写，请求没有cookie，响应没有cookie（结果可以） 附ng配置： location / { rewrite ^ /XTJG/ permanent; } 疑问： 重写只接路径返回了302和cookie，中间经历了什么 基于上面重写路径后面加了根截止返回了200和cookie，中间经历了什么 重写路径修改为ip+port+路径，返回了302，中间经历了什么 其他问题 最后，不管重写的时候是相对地址还是绝对地址，如果重写的时候不以根结束，但是请求是目录，这样会多跳转一次，修改为根结束，可看下图效果： 修改后可以看到重定向少一次

linux监控进程线程数 线程数监控 有需求监控jvm线程数，以下方式是否准确呢，可以跟实际jvm线程数对比一下 yum -y install psmisc pstree -p PID | wc -l

gitlab服务器中毒之一 中毒始末 gitlab服务经常用起来比较卡，通过排查发现cpu使用率持续较高，排查后发现中毒。为了保证排查准确度，需要结合top/ps/netstat来观察，单纯某个命令不一定能发现问题所在。 已通过top排查，并不能很好显示问题，继续查看监听情况 可以看到异常进程相当多，而且名字怪异，再继续根据得到的名字搜索 根据连接的ip可以知道是进入了国外矿池，基本上就是中了挖矿病毒了 挖矿病毒不可能只启动一个进程就完事了，必须要做自启的，所以需要检查每个用户的crontab任务还有/etc/cron.d/下的自动任务 根据进程号获取到了进程文件还有脚本等，但很多时候会分布多个目录做备用，要清理的话最好找出所有文件，可以根据md5搜索吧 查看相关的脚本吧，会下载挖矿程序等

gitlab-runner之异常问题 问题现象 之前已经做好了gitlab-runner自动化构建公司首页，正常用了几天都没有问题。但是某天上午收到同事反馈首页内容没有更新。登录gitlab查看CI/CD状态，确实是失败状态。 排查过程 查看到日志错误: Running with gitlab-runner 14.10.1 (f761588f) on auto_compile_www ksmdDdXw Preparing the "shell" executor 00:00 Using Shell executor... Preparing environment 00:00 Running on iZwz9fzztquqeuad3z8pccZ... Getting source from Git repository 08:58 Fetching changes... Reinitialized existing Git repository in /home/gitlab-runner/builds/ksmdDdXw/0/product/www/.git/ fatal: unable to access 'https://gitlab-ci-token:[MASKED]@gitlab.xxx.com/product/www.git/': The requested URL returned error: 504 Cleaning up project directory and file based variables 00:04 ERROR: Job failed: exit status 1 粗略一看是504超时了。仔细分析内容的话可以知道每个时间的上面都是不同阶段。 第一段使用shell执行器符合预期 第二段从仓库获取源符合预期 第三段拉取修改，可以看到路径不是我们脚本内定义的路径，但查看以前成功的日志都是有此阶段，可以看到此阶段是失败了。 着重研究第三阶段失败的原因 分析： 既然是第三阶段最后抛异常，给我的感觉是客户端runner应该没有问题，至少客户端尝试去拉取代码了。可以怀疑是脚本不对，或者是脚本拉取代码有异常。但尝试手动执行调用的shell脚本都正常。 手动执行脚本没有问题，这也不能完全断定调用没有问题。于是修改脚本内容为echo，再测试CI/CD发现仍然是上面报错，没有脚本内容。可以得出结论并没有走到shell脚本步骤，前面拉取代码都是预处理。 接下来可以怀疑是runner的问题，在客户端执行了gitlab-runner verify，反馈正常，在gitlab查看状态正常。最后重装客户端runner，也依旧报错，至此可以完全排除是客户端runner问题。 再次分析报错内容，根据流程我们可以知道，虽然没有执行到自定义的脚本，但是客户端明显是在runner的流程下尝试拉取代码的，只是最后超时了。重心需要放到超时上，再观察超时地址是https的地址，我突然想到，也许runner的预处理阶段根本不是跟我们脚本一样使用的ssh协议，而是使用CI的token验证，用https协议获取的代码，那么问题极大可能是https协议问题，于是做了如下验证： [root@iZwz9fzztquqeuad3z8pccZ 123]# time git pull https://gitlab.xxx.com/product/www.git Username for 'https://gitlab.xxx.com': yuc Password for 'https://yuc@gitlab.xxx.com': 我们通过http协议拉取代码，再配合gitlab的product_json.log日志，可以看到日志中有验证用户通过，但是就没有后续了，一直等待ng返回超时，至此基本上是可以断定https协议无法正常获取代码，但是runner又需要在我们脚本之前使用https协议获取一次代码。既然问题定位了，那么可有两种解决方案：一是解决gitlab当前https协议异常问题，二是解决runner预处理阶段使用ssh协议/或者干脆不拉取代码。 尝试了上面两种方案都失败了。git pull https协议卡住完全找不到有用的日志，或者说日志太多了不知道该怎么去排查。runner预处理阶段也无法使用ssh协议，或者不拉取代码。 解决 既然是突然无法正常使用https协议，那么就重启gitlab吧。也算是解决问题了。

H3C二层隔离 为什么使用二层隔离？ 同一VLAN内，来自无线客户端的广播、组播报文会向所有放通该VLAN的AP上广播，而且在空间介质中广播报文通常使用最低速率进行发送。当广播报文比较多时，会占用较多的空口资源，在一定程度上影响到整个网络应用。 无线用户VLAN内二层隔离可以在AC上控制无线用户只能访问网关设备，而不能互相之间访问。这样可以大量减少整个WLAN网络的广播流量，提高WLAN网络的整体性能。 AC命令行下进行全局隔离 #只放通目标MAC（通常为网关） system-view user-isolation vlan 10 enable user-isolation vlan 10 permit-mac xxxx-xxxx-xxxx xxxx-xxxx-xxxx undo user-isolation permit-broadcast 对于VRRP，放通虚实MAC；本地转发，配置下发到AP上；超瘦模式，下发到本体设备；建议AC与对端三层交换机trunk口只放通必要的VLAN，禁止配置permit vlan all。 二层放通的需求 AC上开启ARP快达功能 此功能只允许用户单播发现应用层服务，如HTTP、FTP等，需要通过广播/组播相互发现的应用，如局域网游戏等就无法满足。 vlan 10 arp fast-reply enable user-isolation vlan 10 enable permit-unicast 原理：使能VLAN用户隔离时带上参数permit-unicast后，用户间的单播报文将不再收到限制。通过arp fast-reply，由AC帮助用户互相学习MAC地址。 验证 可以在配置之前在wireshark上配置如下过滤来抓取广播和组播报文，配置之后再次抓取，可以对比看到即使能抓取到报文，也只是本机。 wireshark抓取广播和组播报文 eth.dst.ig == 1 and ip