分类目录归档：Linux系统管理

php curl报错：
CURL error: SSL certificate problem: unable to get local issuer certificate, on POST https://api.x.com/API/SELogin.php

在curl里使用了CURLOPT_CAINFO参数指定了根ca证书路径（自签名），然后去调用接口。

在centos7下，调用接口正常，请求其它可信证书的https地址也正常。
在almalinux9下，调用接口正常，请求其它可信证书的https地址报错，即上面的错误。

AI了一下，问题可能出在 OpenSSL 和 cURL 构建差异。
AlmaLinux9的cURL可能使用了更严格的 OpenSSL 验证策略。
如果设置了CURLOPT_CAINFO，它会完全忽略系统默认CA，只使用指定的ca.crt，这在AlmaLinux9下更容易触发验证失败。

# 解决方式，将系统内置的可信根证书与自签名的根证书合并

[root@web cert]# cat /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem >> ca.crt

或者参考 https://www.rootop.org/pages/5443.html
将自签名根证书放到系统中，做为内置可信根证书。

系统版本：Ubuntu 24.04

# 查看传统dns配置文件
root@rd:~# cat /etc/resolv.conf | grep -Ev "^#|^$"
nameserver 127.0.0.53
options edns0 trust-ad
search .

上面3个参数的解释
将 DNS 请求发送给本地 systemd-resolved 的 stub 代理
开启 DNS 扩展（EDNS0）并信任上游的 DNSSEC 验证状态
空值，表示不追加任何搜索域

# 同时此文件是一个软链接
root@rd:~# ll /etc/resolv.conf 
lrwxrwxrwx 1 root root 39 Apr 23  2024 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

# 查看本地是否监听53
root@rd:~# netstat -tnlp | grep -w 53
tcp        0      0 127.0.0.54:53           0.0.0.0:*               LISTEN      857/systemd-resolve 
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      857/systemd-resolve 

可以看到是由 systemd-resolve 进程控制，实际为 systemd-resolved 服务

# 修改服务配置文件 /etc/systemd/resolved.conf
找到 [Resolve] 区块，修改如下：
[Resolve]
DNS=8.8.8.8 1.1.1.1
FallbackDNS=9.9.9.9
DNSStubListener=yes

上面3个参数的解释：
主DNS服务器列表，优先使用这些服务器解析域名。多个地址之间用空格隔开，按顺序尝试。
当主DNS不可用或响应失败时使用的备用DNS。
启用或禁用本地DNS stub监听器，它通常监听在 127.0.0.53:53


重启服务使配置生效：
systemctl restart systemd-resolved

验证 DNS 是否更新：
resolvectl status
resolvectl flush-caches 


也可以修改 /etc/netplan/*.yaml 下配置文件，最终也会是由systemd-resolved接管新的配置。


DHCP 获取的 DNS 也会被 systemd-resolved 接收。
#########################
root@rd:~# resolvectl status
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (ens33)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 8.8.8.8
       DNS Servers: 8.8.4.4

admin@rd-GMB5188:~$ ll /dev/gpcdrv 
crw------- 1 root root 236, 0 Apr 27 21:00 /dev/gpcdrv

默认此设备只有root账户可以读写，其它账号无法使用，通过udev规则实现自动修改。

# 查看设备属性等信息
root@rd-GMB5188:~# udevadm info -a -n /dev/gpcdrv 

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/virtual/gpcdrv/gpcdrv':
    KERNEL=="gpcdrv"
    SUBSYSTEM=="gpcdrv"
    DRIVER==""
    ATTR{power/async}=="disabled"
    ATTR{power/control}=="auto"
    ATTR{power/runtime_active_kids}=="0"
    ATTR{power/runtime_active_time}=="0"
    ATTR{power/runtime_enabled}=="disabled"
    ATTR{power/runtime_status}=="unsupported"
    ATTR{power/runtime_suspended_time}=="0"
    ATTR{power/runtime_usage}=="0"


# 确定可以通过KERNEL和SUBSYSTEM属性匹配设备进行修改权限。
root@rd-GMB5188:~# cat /etc/udev/rules.d/98-gpcdrv.rules 
KERNEL=="gpcdrv", SUBSYSTEM=="gpcdrv", MODE="0664"

# 重启后再次查看权限
admin@rd-GMB5188:~$ ll /dev/gpcdrv 
crw-rw-r-- 1 root root 235, 0 Apr 27 21:05 /dev/gpcdrv

Linux内核模块的文件扩展名为 .ko，代表内核对象（Kernel Object）。
每个ko文件都对应特定的内核版本，在使用ko文件时需确保它们的版本与运行中的内核版本相匹配。

在ubuntu24中insmod加载驱动后重启机器发现又没有了，所以需要实现开机自动加载。

# 复制驱动到指定内核版本下
root@rd-GMB5188:~# cp gpcdrv.ko /lib/modules/6.8.0-31-generic/kernel/drivers/

# 使用depmod命令更新模块依赖关系
root@rd-GMB5188:~# depmod 

# 加载模块
root@rd-GMB5188:~# modprobe gpcdrv
root@rd-GMB5188:~# lsmod | grep gpcdrv
gpcdrv                 20480  0


root@rd-GMB5188:~# cd /lib/modules/6.8.0-31-generic/
root@rd-GMB5188:/lib/modules/6.8.0-31-generic# grep gpcdrv *.*
modules.alias:alias pci:v00001573d00003820sv*sd*bc*sc*i* gpcdrv
modules.alias:alias pci:v00001573d00003800sv*sd*bc*sc*i* gpcdrv
grep: modules.alias.bin: binary file matches
modules.dep:kernel/drivers/gpcdrv.ko:

重启测试。

# 查看rsyslog配置，关于cron部分

[root@ip-172-31-10-235 nginx]# cat /etc/rsyslog.conf |grep cron
*.info;mail.none;authpriv.none;cron.none                /var/log/messages
# Log cron stuff
cron.*                                                  /var/log/cron

可以确定/var/log/cron日志是由rsyslog生成。

# 重启rsyslog服务，重新加载系统时间。

[root@ip-172-31-10-235 nginx]# systemctl restart rsyslog.service 

# 再次查看任务计划日志

[root@ip-172-31-10-235 nginx]# tail -f /var/log/cron
Aug 15 01:01:01 ip-172-31-10-235 CROND[26503]: (root) CMD (run-parts /etc/cron.hourly)
Aug 15 01:01:01 ip-172-31-10-235 run-parts(/etc/cron.hourly)[26503]: starting 0anacron
Aug 15 01:01:01 ip-172-31-10-235 run-parts(/etc/cron.hourly)[26512]: finished 0anacron
Aug 15 01:05:01 ip-172-31-10-235 CROND[26732]: (root) CMD (/data/html/monitor/Centrol/artisan demon:health)
Aug 15 01:10:01 ip-172-31-10-235 CROND[27073]: (root) CMD (/data/html/monitor/Centrol/artisan demon:health)
Aug 15 01:10:01 ip-172-31-10-235 CROND[27074]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Aug 15 01:15:01 ip-172-31-10-235 CROND[27379]: (root) CMD (/data/html/monitor/Centrol/artisan demon:health)
Aug 15 01:20:01 ip-172-31-10-235 CROND[27680]: (root) CMD (/data/html/monitor/Centrol/artisan demon:health)
Aug 15 01:20:01 ip-172-31-10-235 CROND[27681]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Aug 15 01:25:01 ip-172-31-10-235 CROND[27968]: (root) CMD (/data/html/monitor/Centrol/artisan demon:health)


Aug 14 21:30:01 ip-172-31-10-235 CROND[28307]: (root) CMD (/data/html/monitor/Centrol/artisan demon:health)
Aug 14 21:30:01 ip-172-31-10-235 CROND[28308]: (root) CMD (/usr/lib64/sa/sa1 1 1)

时区正常

在修改完系统时区后，nginx也需要重新reload，否则nginx日志的时区还是旧的系统时区。