idrac远程开关机 需求背景 计划机房进行节能减排，需要调度服务器定时启动、停止，在研究可行的技术后，计划使用 idrac 实现启停操作 实现方案 一开始使用的 idrac web 来实现的，通过获取对应的会话，然后模拟登录启动、停止、注销 后续发现这种方法很慢，并且对于部分机器操作后未生效，所以更换为 idrac tools 的方式来实现 配置方法 在linux上安装了合适版本的 idrac tools 后，就可以使用 racadm 命令了，此时我们可以使用命令来控制服务器的启动、停止 使用命令来查询和开机、关机： [root@localhost srvadmin]# racadm -r 192.168.10.252 -uroot -pxxx --nocertwarn serveraction powerstatus Server power status: ON [root@localhost srvadmin]# racadm -r 192.168.10.227 -uroot -pxxx --nocertwarn serveraction powerstatus Server power status: OFF 其他 常用的开机、关机方法： 开机 powerup 关机（需idrac驱动） shutdown 强制关机 powerdown 强制重启 hardreset 正常重启 warmreset 对于关机，计划是不用 racadm 调度的，可以通过服务器脚本来实现，并且关机为 powerdown ，相当于直接按电源关机，对机器的硬盘不友好。 如果想要优雅的关机 shutdown 可以有两种方案： 目的机器支持 idrac 套件，通过 idrac 辅助关机，通过启动一个服务，来优雅通知操作系统操作关机的流程，比如通知进程、卸载文件系统等 控制机器通过脚本ssh登陆后执行关机脚本 选择：计划在所有机器上安装 idrac 套件，以支持远程优雅的关机，这样无需强制关机、以及远程机器可自由关机

gitlab宕机问题、资源不足、OOM、cpu过高 现象 gitlab多次宕机，页面由nginx显示502 第一次排查 通过排查 messages 和 dmesg 再配合监控，发现存在 OOM 情况，操作系统内存、SWAP使用殆尽，其中 oom-kill 的是 puma 进程 以及 页面 502 所以合理怀疑是web宕机 解决办法：每天凌晨重启gitlab，并且修改 `/etc/gitlab/gitlab.rb` 修改 puma 单进程为集群模式，增加每个工作节点的内存 第二次排查 第二次宕机，发现内存使用率并没有达到较高的水平，且仍然有剩余内存，messsages 和 dmesg 没有任何关于 OOM 的信息，所以这次应该不是内存不足导致的宕机，但观察机器其他性能指标，发现其CPU较高，通过nginx的日志，发现在较高的时刻，以及研发反馈的时候，其日志内有大量的请求以及大量的 502 错误 继续排查，发现客户端在此时有大量的请求，大概 12 秒有 2700 个请求，并且此时其他请求非常少，说明此请求由同一个客户端发送出来 "http_user_agent":"vs-code-gitlab-workflow/5.18.1 VSCode/1.95.1 Node.js/20.18.0 (win32; x64)" 通过此 user-agent 确定是 vscode 的插件，同时发现了gitlab文档内关于puma cpu 达到 100%会出现502的问题，综合考虑猜测是vscode某插件请求量太高导致高负载异常，以下是参考文档： https://docs.gitlab.com/17.4/ee/administration/operations/puma.html#502-gateway-timeout-after-puma-spins-at-100-cpu 发现其他用户也存在请求较大而CPU过高的问题，参考文档 https://forum.gitlab.com/t/high-cpu-usage-by-puma-workers/115315/5 解决办法： 既然确定了高并发导致 puma 过载，无法继续响应请求，所以找到了用户、并发较高的请求，以及插件： /api/v4/projects/ /api/v4/version /api/graphql 先判断了几个请求的类型，发现 version 是 GET 请求，并且获取的内容是 gitlab 版本信息，所以可以考虑把此请求内容缓存，减轻 puma 的部分压力，另外两个请求都是 POST，并且内容不固定，基本都是 gitlab 支持的查询请求，无法作为缓存 跟vscode用户进行了沟通，确定该插件无法通过配置来限制并发量，所以仍然只能通过服务端来解决，计划通过限流来解决，限流的思路一共有几种： 通过客户端ip+uri 通过 user-agent+uri 通过 客户端会话+uri 最后通过权衡选择了方案3，原因是客户端ip基本都是公司出口，这里难以区分，再就是 user-agent 也可能存在多数人使用插件的情况，不能几个人一访问就直接到达并发量，所以最后计划通过用户的会话来判断单个用户是否达到限流 nginx限流 nginx限流方案配置： 修改配置文件 nginx.conf map $cookie__gitlab_session $limit_req_key { default default; "" default; ~.+ $cookie__gitlab_session; } proxy_cache_path /data/nginx/nginx_cache levels=1:2 keys_zone=cache_zone:64m max_size=100m inactive=60m; limit_req_zone $limit_req_key zone=api_zone_v1:64m rate=15r/s; limit_req_zone $limit_req_key zone=api_zone_v2:64m rate=15r/s; limit_req_zone $limit_req_key zone=api_zone_test:64m rate=3r/s; 修改配置文件 gitlab.conf 其中对POST接口做了限流，对于 GET 请求的 version 做了缓存 location /api/graphql { limit_req zone=api_zone_v1 burst=15 nodelay; proxy_pass https://127.0.0.1:18092; } location /api/v4/projects { limit_req zone=api_zone_v2 burst=15 nodelay; proxy_pass https://127.0.0.1:18092; } location = /api/v4/version { proxy_ignore_headers Cache-Control; proxy_cache cache_zone; proxy_cache_valid 200 7d; proxy_cache_key "$uri"; proxy_pass https://127.0.0.1:18092; expires 7d; } PS. 上面配置中通过 map 拿到了请求中 cookie 的其中一个变量（可以代表不同会话），以实现不同会话的限流，如果请求中没有会话字段、或者字段内容为空，那么就会设置 default 值，这些请求会归类到一个限流中，看起来是可能存在问题，如果整体的 default 的并发较高，那么很多用户会被限制，其实不是这样的，因为这两个请求都是 POST，那么对于没有会话的请求来说，它是不合法的，必须需要会话才能够请求，所以这里是无需担心的。 gitlab优化 对于 gitlab.rb 中关于 puma 的优化配置 puma['enable'] puma['worker_timeout'] = 60 # Reduce the number of running workers to the minimum in order to reduce memory usage # 设置0关闭集群模式，实验性功能，官方还不明确推荐于生产环境 --- 20240912 目前发现设置为0只有一个进程，当内存使用过高重启会导致无法访问 https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/8477 // https://docs.gitlab.com/ee/administration/operations/puma.html puma['worker_processes'] = 2 puma['preload_app'] = true puma['min_threads'] = 2 puma['max_threads'] = 2 # 设置每个 worker 进程最大内存使用，如果 worker_processes 为 0，则参数失效 puma['per_worker_max_memory_mb'] = 1536 # 1GB # 上面这个参数会直接杀死进程,有可能对请求有影响,增加 preload_app 和 max_requests 参数,使得puma工作进程能够在内存不足之前优雅重启 puma['max_requests'] = 1000 puma['port'] = 8052 puma['log_level'] = 'info' puma['worker_log'] = '/var/log/gitlab/puma/puma_worker.log' 最终解决方案 以上方法对体验有影响、且高峰使用时间仍然不能很好解决，所以除了对GET请求做缓存外，增加了服务器的配置来彻底解决

openvpn持久话客户端ip 背景问题 当前 openvpn 服务端配置了参数来尝试持久化客户端ip ifconfig-pool-persist /etc/openvpn/ipp-udp.txt 如果客户端第一次获取到 ip 地址，会记录到此文件以实现持久话，下次登录会继续使用此ip。但存在一个问题，当服务器重启后此文件会被清空，所有的客户端都会从头开始分配ip地址，并没有实现真正的持久话客户端ip。 如何解决 经过了解可以使用下面参数解决 client-config-dir /etc/openvpn/ccd 目录内可以定义每个客户端的配置文件，为客户端单独推送配置，比如更多的路由，静态ip地址，由此文件配置的ip会在客户端登录的时候主动推送 具体配置方法是在此目录下写入客户端 common-name（CN） 的文件即可，内容如下： [root@localhost ccd]# more yuc ifconfig-push 192.168.9.2 255.255.255.0 push "route 192.168.100.0 255.255.255.0" 根据格式为需要持久话分配ip的客户端配置即可，或者为此客户端单独添加一条路由 最后-自动化 如果我们的目标是为每个客户端都持久话ip地址，那么每个文件都手动创建明显很费力，那么通过openvpn提供的用户登录后执行脚本来自动化创建，后续自行了解，这里不举例子 批量配置脚本 如果有一批用户要配置持久化，需要提供两列，分别是 用户名、ip，脚本如下： while read line;do read name ip <<< $(echo $line | awk '{print $1,$2}'); echo "ifconfig-push $ip 255.255.252.0" > $name; done < /tmp/name

ubuntu、centos等操作系统vnc的问题 vnc安装参考 ubuntu 的 vncserver 安装可以参考文档 https://gist.github.com/indyfromoz/739cd53d47b91ba1d3b540ab53b1f46c 异常问题 正常安装部署`` vncserver```使用基本都是没有问题的，但是在 ubuntu下确远程出现了问题，配置与之前的centos7` 一模一样 现象：灰屏、白屏、黑屏、鼠标黑叉，且通过 .vnc 目录下的日志文件可以看到错误： 05/11/24 12:23:04 rfbProcessClientNormalMessage: ignoring unknown encoding -131070 05/11/24 12:23:04 rfbProcessClientNormalMessage: ignoring unknown encoding -131069 05/11/24 12:23:04 rfbProcessClientNormalMessage: ignoring unknown encoding -309 05/11/24 12:23:04 rfbProcessClientNormalMessage: ignoring unknown encoding -258 显示编码问题，对比正常使用的vncserver服务日志，是没有类似错误的，可以确定是此问题导致 尝试更换了 vncserver 的不同发行版，但仍然不能解决 柳暗花明 后来根据 centos 正常、ubuntu 异常这个思路对比，它们的桌面版本都是使用的 gnome 且依赖都是通过包管理器安装所以肯定都没问题，那么唯一有问题的可能与桌面的 Wayland 有关，这个配置之前使用其他服务的时候明确提示了不支持，也许 vncserver 同样存在兼容性问题呢？在进行检索一番后确实应征了我这个想法，参考文档： https://help.realvnc.com/hc/en-us/articles/4417193011857-How-do-I-disable-Wayland-to-use-RealVNC-Connect 如何解决 最后根据 wayland 的关闭方法，修改配置文件 /etc/gdm3/custom.conf WaylandEnable=false PS. 那么 centos7 版本同样使用的 gnome 桌面为什么没有问题呢？ 原因是 centos7 虽然使用的 gnome 但其使用的 X11 实现的图形显示（与wayland区别）。这两个发行版都可以通过系统设置中查询具体的参数，并且 ubuntu 在关闭 wayland 后就自动切换为 X11，重启后可以确认 PS. 其他 X11 和 wayland 的区别可以自行后续了解

rpa、tagui在ubuntu下的安装问题 问题初现 在离线安装完 rpa 模块、tagui 后执行初始化卡住 r.init(headless_mode=True) 找到 tagui 的安装目录，在命令行执行 ./tagui 测试效果，回显 php 命令未找到，安装之 继续测试，发现测试 curl 不存在，继续安装之 问题之二 继续在命令行测试效果，报错如下： Auto configuration failed 124623513679808:error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library:dso_dlfcn.c:185:filename(libproviders.so): libproviders.so: cannot open shared object file: No such file or directory 124623513679808:error:25070067:DSO support routines:DSO_load:could not load the shared library:dso_lib.c:244: 124623513679808:error:0E07506E:configuration file routines:MODULE_LOAD_DSO:error loading dso:conf_mod.c:285:module=providers, path=providers 124623513679808:error:0E076071:configuration file routines:MODULE_RUN:unknown module name:conf_mod.c:222:module=providers 尝试使用 python 执行，错误相同 >>> import rpa as r >>> r.init(headless_mode=True) [RPA][ERROR] - following happens when starting TagUI... The following command is executed to start TagUI - "/root/.tagui/src/tagui" rpa_python headless It leads to following output when starting TagUI - Auto configuration failed 124623513679808:error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library:dso_dlfcn.c:185:filename(libproviders.so): libproviders.so: cannot open shared object file: No such file or directory 124623513679808:error:25070067:DSO support routines:DSO_load:could not load the shared library:dso_lib.c:244: 124623513679808:error:0E07506E:configuration file routines:MODULE_LOAD_DSO:error loading dso:conf_mod.c:285:module=providers, path=providers 124623513679808:error:0E076071:configuration file routines:MODULE_RUN:unknown module name:conf_mod.c:222:module=providers 弯弯绕绕 上面显示的错误关键字是 dso 和 libproviders.so ，检索这两个库一直都没有结果，并且跟其他操作系统对比，都没有 libproviders.so 这个文件，所以猜测根本原因并不是缺少这个库文件 不过在检索这两个错误的时候，发现了关键词 ssl 和 phantomjs，所以怀疑是 phantomjs 组件导致的错误，tagui 使用了这个组件我是可以确定的，所以直接进入 phantomjs/bin 目录下调用命令，果然出现的错误一致 继续通过 ldd 命令检查需要的库文件 root@succez:~/.tagui/src/phantomjs/bin# ldd ./phantomjs linux-vdso.so.1 (0x00007ffdc2fd2000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x000072e0ec126000) libfontconfig.so.1 => /lib/x86_64-linux-gnu/libfontconfig.so.1 (0x000072e0ec0dc000) libfreetype.so.6 => /lib/x86_64-linux-gnu/libfreetype.so.6 (0x000072e0ec014000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x000072e0ec00f000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x000072e0ec00a000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x000072e0ec005000) libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x000072e0ebc00000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x000072e0ebf1c000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x000072e0ebefc000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x000072e0eb800000) /lib64/ld-linux-x86-64.so.2 (0x000072e0ec153000) libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x000072e0ebecb000) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x000072e0ebec2000) libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16 (0x000072e0ebe85000) libbrotlidec.so.1 => /lib/x86_64-linux-gnu/libbrotlidec.so.1 (0x000072e0ebe77000) libbrotlicommon.so.1 => /lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x000072e0ebe54000) 可以看到 linux-vdso.so.1 库文件跟报错是相似的，并且没有显示文件路径，是不存在导致的错误吗？ 又跟其他正常机器进行了对比，确定也是没有此文件的，并且其他运行 tagui、phantomjs 命令正常的机器 ldd 显示的内容一致，至此问题毫无头绪 峰回路转 所以还是尝试排查最初的问题，通过检索 DSO support routines:dlfcn_load:could not load the shared library 这一段，发现 /etc/ssl/openssl.cnf 文件和 phantomjs 有关系，根据建议解决方案，把如下两行注释 [openssl_init] #providers = provider_sect #ssl_conf = ssl_sect 再次测试成功运行