openssh 的升关联新的 openssl 升级异常 升级 openssh 的版本在编译的时候就出现了错误，提示 ssl 的版本不匹配，最低需要 1.1 编译openssl 所以我们安装了一个最新版本的 openssl-1.1.1新版 ./config --prefix=/usr/local/openssl1.1.1 shared zlib make && make install 再次尝试 这次配置的时候关联了 openssl 的目录 ./configure --prefix=/usr --sysconfdir=/etc/ssh --with-md5-passwords --with-privsep-path=/var/lib/sshd --with-pam --with-ssl-dir=/usr/local/openssl1.1.1 但是配置仍然报错，内容如下： checking OpenSSL header version... failed 查看了配置参数，只有这一个是指定路径的，所以参数名应该是没有问题的，于是我又更换为了 openssl 解压后的源码目录，但仍然是相同的错误 继续排查 又怀疑是 openssl-1.1.1 版本太低，于是又下载了一个 openssl-3.3.1 使用上面相同的方式测试，但结果仍然是一样的报错 接下来，详细的查看了 openssh 当前目录下的 config.log 日志，发现有如下错误： error while loading shared libraries: libcrypto.so.3 ./conftest: error while loading shared libraries: libcrypto.so.3: cannot open shared object file 应该就是动态库文件没有找到，所以还是把动态库加入到 ldconfig 算了，加入到环境变量中，这样应该就不会找不到了 echo /usr/local/openssl/lib64 >> /etc/ld.so.conf.d/ssl3.conf && ldconfig && ldconfig -pv 果然再次编译没有任何错误 安装完成 还要还原 /etc/pam.d/sshd，第一次从 rpm 源码升级，rpm 卸载会重命名备份这个文件为 sshd.rpmsave 复制启动脚本到 并且设置开机自启 接着为了保证配置跟以前一致，可以还原之前的配置，避免前后端口不一致导致连不上了 再接下来测试配置文件 sshd -t ，保证配置文件测试无误后重启

openssh 的升级 软件下载 官方下载：http://www.openssh.com/portable.html 推荐下载最新版 前置准备 为了防止 ssh 升级失败或中途断开后无法登录，需要做一些前置工作 Centos6.X开启telnet服务 安装telnet服务端以及超级守护进程 yum install telnet-server xinetd openssl-devel pam-devel -y 修改telnet的状态为开启：编辑 `/etc/xinetd.d/telnet` 文件修改disable对应的值为 no 重启xinetd服务： service xinetd restart 操作系统还需要创建一个普通用户来登陆，因为 telnet 默认不允许 root 登陆，且 telnet 传输方式是明文的原因，也不推荐使用 root 登陆，避免额外的安全隐患 Centos7.X开启telnet服务 安装 telnet 服务 yum -y install telnet-server 启动并且设置为自启 systemctl start telnet.socket systemctl start xinetd 安装依赖包： yum install pam-devel zlib-devel gcc -y 编译源码 解压源码后进入到目录中编译，一定要使用 `--with-pam`，否则一些场景下会出现使用问题 ./configure --prefix=/usr --sysconfdir=/etc/ssh --with-md5-passwords --with-privsep-path=/var/lib/sshd --with-pam && make 备份原配置文件 cp -a /etc/ssh /opt/ssh 卸载旧版本的ssh rpm -qa | grep openssh | xargs rpm e -nodeps 执行安装 make install 安装完毕检测回显，可能会提示 key 文件权限问题，根据提示的文件设置为 600 即可 检查升级之后的ssh版本 `ssh -V` 拷贝启动脚本作为服务 并 设置自启 cp contrib/redhat/sshd.init /etc/init.d/sshd && chkcoonfig --add sshd;chkconfig sshd on 还原配置文件 `/etc/ssh/sshd_config` ，之前的配置文件可能做了修改，比如端口，加密套件等 还原 `/etc/pam.d/sshd`` `，从 rpm 源码升级，rpm 卸载会重命名备份这个文件为` ``sshd.rpmsave` 没有问题了，先测试配置文件再重启 ssh 服务 sshd -t && service sshd restart 重启无异常且测试远程登录后，关闭 telnet服务

nginx限制时间段访问-安全 安全加固之限制访问时间段 之前我们做过按照 url 、客户端ip来做黑白名单，这次我们尝试通过控制时间段来做黑白名单的访问 主要的需求是开放某个日期范围内上午9点到下午18点之间访问，其余时间不允许访问。经过测试调整后的代码如下 map $time_iso8601 $deny { default 0; ~*^2024-08-(2\d|3(0|1))T(0[0-8]|1[8-9]|2[0-3]):.* 1; } server { listen 12000; default_type text/html; add_header Content-Type 'text/html; charset=utf-8'; set $checkurl 0; if ( $request_uri !~ "/bhpoc($|/$|.*\.(jpg|png|css|js|woff|ico))" ) { set $checkurl 1; } set $ss $checkurl$deny; if ( $ss = 11 ) { return 403; } location / { proxy_pass http://192.168.10.120:19836; } } 上面的关键配置部分的含义如下： 映射一个变量 deny，其默认值是 0 ，但是如果正则匹配到 $time_iso8601 的时间范围是 2024-08-23 到 2024-08-31 的 00-08 点 18-23 点，则其值为 1 设置一个变量 $checkurl，其值初始化为 0 进入 if 判断，如果客户端访问的 url 地址为上面的正则表达式，主要为首页和一些静态文件，则 $checkurl 的变量值为 1 设置一个变量 $ss， 其值为前面两个变量 $deny$checkurl 的拼接 判断变量 $ss 如果其值为 11，则认为其匹配到禁止的时间范围，以及匹配到百名单以外的 url，则范围 403，或者范围 401 也是可以的 其他情况下，不符合时间范围和url黑名单的，则范围正常的请求

zabbix之zabbix trapper监控 背景和特点 在一些无需 zabbix 主动监控，但是想统一纳入 zabbix 告警的场景下，zabbix的常用监控项明显不符合我们的需求，比如我的需求如下： 我们本身已经实现了 jvm 的内存 oom 监控，而 zabbix 的本身 jvm 监控扩展数据虽然是较多，但是配置麻烦，且没有 oom 这部分的监控告警，而我们就是想及时收到 oom 告警，并且想统一纳入 zabbix 监控告警，那么应该如何对接呢？ 首先我不想全部更换为 zabbix 自带的 jvm 模板，缺点有这些：配置麻烦、无法实现需求、需要定时检测、创建自定义监控项、指定命令和返回内容，同样我也不想再通过自定义监控项然后使用脚本来定时获取，这也有前面部分的劣势，那么有什么方案呢？ 方案研究 首先我想到的方法是能否使用 zabbix 自带的 api 直接发送一个告警内容，然后使得 zabbix 能够处理、通知，但查看了文档，发现 api 多是做一些管理上的内容、或者获取数据，想写入数据，甚至在没有主机、监控项的前提下写入告警通知完全没有找到可行的方案. 于是我开始寄托于常规的自定义监控项，但数据通过 zabbix_sender 来主动推送，但测试发现仍然较为麻烦，需要zabbix agent配置监控项，以及还有监控间隔时间的问题。因为实际上没有通过 zabbix agent主动发送、或者zabbix server 主动获取，间隔时间这块理论上是存在问题的，到最后不了了之 在一筹莫展之际了解到了 zabbix trapper 类型的监控项，了解到它是在 sender 上，原话是: # 要将监控数据直接推送给Zabbix server 或 proxy，必须将监控项类型配置为trapper https://www.zabbix.com/documentation/current/zh/manual/concepts/sender 这种似乎完全符合我们的需求，仅主动推送数据，无需 zabbix agent、zabbix server 介入 并且此监控项的另一个好处是 监控项的 key 直接在web定义就好了，无需在 agent 中设置，这样也是最简单的方案了，最后在设置好之后，我们通过 sender 来主动推送了一次数据，在此 主机 的最新数据中成功更新 工具的参数使用方法： # -z 接 zabbix server # -s 接 agent 配置文件中的主机名 # -k 接 定义的监控项，在web配置即可，无需agent配置文件中处理 # -o 接内容 ./zabbix_sender -z 192.168.3.30 -p 10051 -s host-192.168.10.120 -k custom.jvm_oom -o 1 最后在测试数据更新无问题后，我们再制作一个触发器，当值符合后即告警推送 基于OOM告警的示例 需要考虑的是，容器环境下N多个容器需要做 OOM 告警，但是zabbix主要是对接机器的，容器肯定是比机器多，那么如何规划呢？所以我考虑的是只选择一台机器做监控项，然后告警的时候取不同容器名来区分问题，实际配置大致如下 容器方面，需要加入名称作为环境变量，以OOM的时候，触发脚本可以拿到容器名发送给 zabbix zabbix_server 使用采集器的监控项，数据类型为字符串 客户端使用 zabbix_sender 推送数据，故障数据格式 SERVICENAME_DATE_1，恢复数据格式 SERVICENAME_DATE_0 接下来是触发器配置 触发器名称为 OOM-find {ITEM.VALUE} 这样多个可以标志不同的容器环境 触发器表达式为： right(last(/Template OS Linux by OOM/monitor[OOM]),1)=1，取最右边的值为 1，则表示有问题 问题事件生成模式 选择 多重，这样不同名称的容器会生成不同的问题，否则跟CPU、内存告警一样，如果一直超过90%，那么只会有第一个告警 触发器恢复较为复杂，理论如下：OOM告警后，恢复途径有几个，一是重启tomcat，然后在这时候自动给 zabbix 再发一个恢复（需要判断是否OOM过），二是手动上 zabbix 关闭问题，三是其他触发关闭 （与方法一类似），但明显前面两个都比较麻烦。所以考虑使用其他办法触发，于是选择在发送告警等待60秒后再给zabbix发送恢复（根本的需求是收到告警，而不关心zabbix上显示） 恢复配置： 时间成功迭代 选择 恢复表达式 恢复表达式内容： `right(last(/Template OS Linux by OOM/monitor[OOM]),1)=0` 事件成功关闭 选择 所有问题如果标签值匹配 接下来就是恢复的第二个问题，如何恢复给定的容器，如果 con1，con2 都告警了，那么会有两条记录，想要恢复触发只关闭相关的问题，需要使用到标记 在 7 选择 所有问题如何标签值匹配后，需要填入一个标签值，也就是字段名，例如：name 然后在触发器的右边栏添加一个触发器标签，名称填入 name，值使用正则过滤出容器名，如果按照我上面的数据格式，则是 `{ITEM.VALUE}.regsub("(.*)_(.*)_(.*)",\1)`，表示匹配三段下划线然后拿到第一段的内容 在配置 10 以后，测试触发、恢复数据，应该没问题了 标签到底是如何生效的呢？ 通过观察，触发问题的时候就会根据标签拿到值，当恢复数据到达的时候，同样也会拿到值，如果两个值匹配，那么就会恢复值相同的全部问题

dolphinscheduler与vipshop saturn的对比 安装部署 海豚调度平台 https://dolphinscheduler.apache.org/ 如果想简单试用，那么docker即可，对高可用无要求，及时宕机了部分任务一段时间没有执行可以容忍，那么使用伪集群即可 要点： 单节点最佳20个任务以下，实际使用可以伪集群，生产环境集群 架构: master、worker、api server 软件和依赖： jdk1.8+ ， mysql5.7+ ， 本体， zookeeper， psmisc(系统依赖包-进程树分析) 特性 支持非常多的任务语言、数据库sql、支持 hadoop 生态的任务调度 可以限制内存、CPU使用率 各级别任务变量传递 支持各种告警邮件、叮叮、企业微信、等等 可以上传脚本、现在编写脚本 按照项目划分、工作流划分，从而支持大规模的任务管理 支持用户隔离，用户权限等，从而支持大规模的任务管理 与saturn的对比 感觉体验没有saturn好的地方，目前仅作为shell、python等脚本调度来看，不对其他功能做评价： 复杂的用户指定、任务节点指定，在多个地方都可以设置这两个参数，如果对产品不是非常熟悉，最终哪里生效需要测试 启动用户给 sudo NOPASSWD 权限，这样的权限实在太大，配合在线编写脚本和执行脚本可以执行任何操作 saturn可以指定任意节点、多个节点、并行执行同一个任务，比如一些同样的备份或者清理任务，但海豚创建一个工作流指定多个节点，也只有第一个节点执行，其他节点作为失败备用执行，这样同一个任务多个机器需要设置多个定时任务