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吧。也算是解决问题了。

汇编指令学习 汇编指令 汇编指令的一般结构： mov ecx,[rsi+07E0] 命令 结果去向,数据来源 操作码|数据1|数据2 操作码一般长度为1-3字节 寄存器和访存 x86寄存器 x86架构下只有16个寄存器 rax r8 rdx r9 rcx r10 rbx r11 rsi r12 rdi r13 rsp(特殊用途) r14 rbp r15 访问内存 一般使用中括号内既是访问内存地址 [01350CB0] [rax] [rax+10] 规定 寄存器和中括号可以在任何位置使用 一条指令中最多有一处访存 代码注入方式 AOB（array of byte) 原理：一般游戏的更新不是修改已有代码时，代码的只是位置发生变化，那编译到程序中的汇编命令的操作码间的相对位置就不会发生变化，这时将操作码视作数据来定位，使用 准确操作码|地址|地址|准确操作码|地址|地址... 的模糊方式来找到准确的注入点 特殊标签： 绝对地址->其后的指令位于内存的这个位置 普通标签： 其后的地址位于内存的某个位置->标签获得对应的地址 cheatengine 直接寻找数据 直接通过游戏变化查找对应的变化数据 间接寻找数据 ####### 同类数据 受同一指令影响的数据 寻找指令 已知数据 连续内存区域 ####### 辅助信息查找 tutorPW - Step 5: Code finder (PW=888899) 冻结指令 - Step 6: Pointers: (PW=098712) 寻找指针 - Step 7: Code Injection: (PW=013370) 指令注入 - Step 8: Multilevel pointers: (PW=525927) 多层指针 - Step 9: Shared code: (PW=31337157) 注入程序编写

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

selenium在linux下截图乱码 Linux下解决乱码问题 现象：之前在windows上运行，截图内容显示正常 问题：脚本转移到linux上，截图发现中文部分出现很多框框。测试截图多个网页都是，怀疑是没有中文字体。 处理：加入中文字体，可以选择任意免费使用的中文字体加入操作系统即可 # 安装必要软件 yum -y install fontconfig xorg-x11-font-utils # 新建目录 mkdir -pv /usr/share/fonts/chinese # 支持的中文字体放入 # 字体生效 mkfontscale && mkfontdir && fc-cache -fv && fc-list