前些日志在研究saltstack的api,使用了https的方式来访问api,创建一对儿密钥
/etc/pki/tls/certs/localhost.crt
和/etc/pki/tls/certs/localhost.key
过了几天后发现我实验的这台机器的Apache服务宕掉了,而且重启失败,故障信息如下
1 | shell> service httpd restart |
- 当我发现重启失败且终端没有报错输出时,当时打开了
/var/log/message
和/var/log/httpd/error_log
两个log,重新重启Apache服务,发现message没有输出,而httpd的error_log有一行[notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
输出 - 发现suEXEC之后,我百度了该关键字,得知是负责处理CGI和SSI程序的请求,当我看到SSL的时候,就突然想起之前做过的salt-api的实验,当时创建了一对儿密钥,该密钥过期时间大概是24小时,猜测可能是Apache的默认配置文件加载了mod_ssl模块,而且引用了我创建密钥对儿的默认位置,而该密钥却处于失效状态,所以Apache服务无法启动(这是当时的猜测)
- 知道是SSL相关的问题之后,马上打开
/var/log/httpd/ssl_error_log
查看情况,有如下报错[warn] RSA server certificate CommonName (CN)
localhost’ does NOT match server name!?` 当看到这一行报错的时候,已经确认上面猜测的第一点,就是Apache的默认配置文件加载了mod_ssl模块,而且指定密钥对儿的位置,就是我测试salt-api时创建密钥对儿的位置。而且还有一个错误就是我密钥对儿指定的hostname和Apache指定的hostname并不相同,基于密钥对主机名不符与密钥过期两点,造成了Apache无法启动的故障。 - 确定了问题之后,解决方案有很多种,核心思想就是让Apache的ssl配置失效
- 第一种办法,可以在Apache的配置中禁用mod_ssl模块
/etc/httpd/conf.d/ssl.conf
- 第二种办法,在
/etc/httpd/conf.d/ssl.conf
配置文件中,指定其他密钥对儿的路径 - 第三种办法,我的salt-api已经测试完毕,可以把创建的密钥对儿删除或更名
- 第一种办法,可以在Apache的配置中禁用mod_ssl模块
- 最终我是选择了第三种的方法,将原有的密钥对儿加了
.bak
后缀,之后重启Apache恢复正常,问题解决,回头再去查看/etc/httpd/conf.d/ssl.conf
配置文件的时候,已经自动变成了/etc/httpd/conf.d/ssl.conf.bak
相当于Apache找不到配置文件中指定的密钥对儿后,自动禁用了mod_ssl模块
如果你想了解suexec方面的东西,可以参考以下文章: