• BLSA-2018:0013 – [重要] kernel的安全警告及修复方法

    BLSA-2018:0013 – [重要] kernel的安全警告及修复方法

    问题描述

           最近 kernel 暴露出安全漏洞(CVE-2017-5754),攻击者可以使用此缺陷对有目标缓存侧向通道攻击来读取特权(内核空间)内存。

    影响版本

    • BigCloud Enterprise Linux 7.3
    • Red Hat Enterprise Linux 7.3
    • CentOS Linux 7.3

    详细介绍

    安全修复

    • [CVE-2017-5754 [重要]]
      变体CVE-2017-5754被发现,在受影响的微处理器上,在对指令权限错误的推测执行过程中,生成错误访问触发的异常被抑制,直到整个指令块的退出为止,一个没有被授权的本地攻击者可以通过执行有针对性的缓存旁通道来读取特权(内核空间)内存进行发起攻击。

    解决方案

    目前,BCLinux 的官方源已经提供 kernel 的更新软件包,受影响的 BCLinux 7.3 客户端用户需要升级到 3.10.0-514.48.1.1.el7 版本。

    1. 检查YUM源设置,确保使用的是 BCLinux 官方YUM源
    [root@BCLinux7_3 ~]# ls -l /etc/yum.repos.d/
    total 24
    -rw-r--r--. 1 root root  970 Mar 29 04:26 BCLinux-Base.repo
    -rw-r--r--. 1 root root 1512 Apr  9  2017 BCLinux-CR.repo
    -rw-r--r--. 1 root root  676 Apr  9  2017 BCLinux-Debuginfo.repo
    -rw-r--r--. 1 root root 1220 Apr  9  2017 BCLinux-Kernel.repo
    -rw-r--r--. 1 root root 1027 Apr  9  2017 BCLinux-Source.repo
    -rw-r--r--. 1 root root  807 Apr  9  2017 BigCloud.repo
    
    
    1. 安装更新
    [root@BCLinux7_3 ~]# yum update kernel-3.10.0-514.48.1.1.el7
    Loaded plugins: fastestmirror
    Loading mirror speeds from cached hostfile
    Resolving Dependencies
    --> Running transaction check
    ---> Package kernel.x86_64 0:3.10.0-514.48.1.1.el7 will be installed
    --> Finished Dependency Resolution
    
    Dependencies Resolved
    
    ====================================================================================================================================================
     Package                        Arch                           Version                                        Repository                       Size
    ====================================================================================================================================================
    Installing:
     kernel                         x86_64                         3.10.0-514.48.1.1.el7                          updates                          38 M
    
    Transaction Summary
    ====================================================================================================================================================
    Install  1 Package
    
    Total download size: 38 M
    Installed size: 150 M
    Is this ok [y/d/N]: 
    
    
    
    1. 复查
    [root@BCLinux7_3 ~]# rpm -q kernel
    kernel-3.10.0-514.el7.x86_64
    kernel-3.10.0-514.48.1.1.el7.x86_64
    
    1. 重启机器

    安装升级包以后,重启机器,更新生效。

    外部链接

    1.BCLinux安全更新

    发布在 系统更新
  • BLSA-2018:0012 – [重要] bind的安全警告及修复方法

    BLSA-2018:0012 – [重要] bind的安全警告及修复方法

    问题描述

           BIND是一个应用非常广泛的DNS协议的实现,它是美国加州大学Berkeley分校开发和维护的一套DNS域名解析服务软件。最近暴露出一个安全漏洞(CVE-2017-3145),在解析器中,错误的获取清理顺序会导致bind服务崩溃。

    什么是bind?
    Berkeley Internet Name Domain(BIND)是域名系统(DNS)协议的实现。BIND包括一个DNS服务器(命名);一个解析器库(用于在与DNS交互时使用的应用程序);以及用于验证DNS服务器是否正确运行的工具。

    影响版本

    • BigCloud Enterprise Linux 7.3
    • Red Hat Enterprise Linux 7.3
    • CentOS Linux 7.3

    详细介绍

    安全修复

    • CVE-2017-3145[重要]
      bind在解析器中不正确的获取清理排序可能会导致bind服务崩溃。
      有关该安全漏洞问题(s)的更多细节,包括漏洞影响、CVSS分数和其他相关信息,请参考CVE链接页面。

    解决方案

    目前,BCLinux 的官方源已经提供 bind 的更新软件包,受影响的 BCLinux 7.3 客户端用户需要升级到 9.9.4-50.el7_3.3 版本。

    1. 检查YUM源设置,确保使用的是 BCLinux 官方YUM源
    [root@BCLinux7_3 ~]# ls -l /etc/yum.repos.d/
    total 24
    -rw-r--r--. 1 root root 1093 Mar 29 08:09 BCLinux-Base.repo
    -rw-r--r--. 1 root root 1512 Apr  9  2017 BCLinux-CR.repo
    -rw-r--r--. 1 root root  676 Apr  9  2017 BCLinux-Debuginfo.repo
    -rw-r--r--. 1 root root 1220 Apr  9  2017 BCLinux-Kernel.repo
    -rw-r--r--. 1 root root 1027 Apr  9  2017 BCLinux-Source.repo
    -rw-r--r--. 1 root root  807 Apr  9  2017 BigCloud.repo
    
    1. 安装更新
    [root@BCLinux7_3 ~]# yum update bind
    Loaded plugins: fastestmirror
    Loading mirror speeds from cached hostfile
    Resolving Dependencies
    --> Running transaction check
    ---> Package bind.x86_64 32:9.9.4-37.el7 will be updated
    ---> Package bind.x86_64 32:9.9.4-50.el7_3.3 will be an update
    --> Processing Dependency: bind-libs = 32:9.9.4-50.el7_3.3 for package: 32:bind-9.9.4-50.el7_3.3.x86_64
    --> Running transaction check
    ---> Package bind-libs.x86_64 32:9.9.4-37.el7 will be updated
    ---> Package bind-libs.x86_64 32:9.9.4-50.el7_3.3 will be an update
    --> Processing Dependency: bind-license = 32:9.9.4-50.el7_3.3 for package: 32:bind-libs-9.9.4-50.el7_3.3.x86_64
    --> Running transaction check
    ---> Package bind-license.noarch 32:9.9.4-37.el7 will be updated
    --> Processing Dependency: bind-license = 32:9.9.4-37.el7 for package: 32:bind-libs-lite-9.9.4-37.el7.x86_64
    ---> Package bind-license.noarch 32:9.9.4-50.el7_3.3 will be an update
    --> Running transaction check
    ---> Package bind-libs-lite.x86_64 32:9.9.4-37.el7 will be updated
    ---> Package bind-libs-lite.x86_64 32:9.9.4-50.el7_3.3 will be an update
    --> Finished Dependency Resolution
    
    Dependencies Resolved
    
    ====================================================================================================================================================
     Package                              Arch                         Version                                      Repository                     Size
    ====================================================================================================================================================
    Updating:
     bind                                 x86_64                       32:9.9.4-50.el7_3.3                          updates                       1.8 M
    Updating for dependencies:
     bind-libs                            x86_64                       32:9.9.4-50.el7_3.3                          updates                       1.0 M
     bind-libs-lite                       x86_64                       32:9.9.4-50.el7_3.3                          updates                       730 k
     bind-license                         noarch                       32:9.9.4-50.el7_3.3                          updates                        84 k
    
    Transaction Summary
    ====================================================================================================================================================
    Upgrade  1 Package (+3 Dependent packages)
    
    Total download size: 3.6 M
    Is this ok [y/d/N]:y 
    
    1. 复查
    [root@BCLinux7_3 ~]# rpm -q bind
    bind-9.9.4-50.el7_3.3.x86_64
    
    1. 重启应用

    安装升级包以后,重启应用,更新生效。

    外部链接

    1.BCLinux安全更新

    发布在 系统更新
  • BLSA-2018:0011 – [重要] kernel的安全警告及修复方法

    BLSA-2018:0011 – [重要] kernel的安全警告及修复方法

    问题描述

           最近 kernel 暴露出安全漏洞(CVE-2017-8824),攻击者可以利用这个漏洞,对系统安全产生影响。为了增加安全强度,建议所有使用受影响产品的用户都安装 BCLinux 提供的的更新补丁。

    影响版本

    • BigCloud Enterprise Linux 7.3
    • Red Hat Enterprise Linux 7.3
    • CentOS Linux 7.3

    详细介绍

    安全修复

    漏洞修复

    • BZ#1530128
      此修复更新了内核代码,以避免无效的vzalloc调用,并且dmesg错误不再发生。
    • BZ#1530134
      之前,如果NFSv4挂载时遇到了尚未完成初始化的NFS客户端结构,那么中继检测逻辑就会等待NFSv4挂载完成。因此,如果一个并发的NFSv4 挂载操作向NFS客户端结构的列表中添加了另一个项,那么NFS客户端就不能开始初始化,它在等待其他进程所持有的互斥锁,并且发生了死锁。此更新修复了NFS在将新结构添加到列表之前等待NFS客户端结构的初始化完成。这样死锁不再发生,NFS客户端现在可以按照所描述的情况进行初始化。
    • BZ#1535880
      如果可扩展固件接口(EFI)创建了一组新的页表并在低位地址映射了段代码,那么操作系统(OS)就无法启动。这个更新修复了EFI代码,并且操作系统在以上的描述情况下可以按照预期的方式启动。
    • BZ#1539648
      Retpoline 机制可以缓解分支目标注射,也就是所谓的幽灵变种2漏洞。 通过此次更新,Retpoline已经实施到BCLinux内核中。
    • BZ#1540088
      此更新在/ proc / cpuinfo文件中添加了新的一行,以显示IBM z系统上stfle指令报告的所有可用工具。

    解决方案

    目前,BCLinux 的官方源已经提供 kernel 的更新软件包,受影响的 BCLinux 7.3 客户端用户需要升级到 3.10.0-514.44.1.1.el7 版本。

    1. 检查YUM源设置,确保使用的是 BCLinux 官方YUM源
    [root@BCLinux7_3 ~]# ls -l /etc/yum.repos.d/
    total 24
    -rw-r--r--. 1 root root  970 Mar 29 04:26 BCLinux-Base.repo
    -rw-r--r--. 1 root root 1512 Apr  9  2017 BCLinux-CR.repo
    -rw-r--r--. 1 root root  676 Apr  9  2017 BCLinux-Debuginfo.repo
    -rw-r--r--. 1 root root 1220 Apr  9  2017 BCLinux-Kernel.repo
    -rw-r--r--. 1 root root 1027 Apr  9  2017 BCLinux-Source.repo
    -rw-r--r--. 1 root root  807 Apr  9  2017 BigCloud.repo
    
    
    1. 安装更新
    [root@BCLinux7_3 ~]# yum update kernel
    Loaded plugins: fastestmirror
    Loading mirror speeds from cached hostfile
    Resolving Dependencies
    --> Running transaction check
    ---> Package kernel.x86_64 0:3.10.0-514.44.1.1.el7 will be installed
    --> Finished Dependency Resolution
    
    Dependencies Resolved
    
    ====================================================================================================================================================
     Package                        Arch                           Version                                        Repository                       Size
    ====================================================================================================================================================
    Installing:
     kernel                         x86_64                         3.10.0-514.44.1.1.el7                          updates                          38 M
    
    Transaction Summary
    ====================================================================================================================================================
    Install  1 Package
    
    Total download size: 38 M
    Installed size: 150 M
    Is this ok [y/d/N]: y
    
    1. 复查
    [root@BCLinux7_3 ~]# rpm -q kernel
    kernel-3.10.0-514.el7.x86_64
    kernel-3.10.0-514.44.1.1.el7.x86_64
    
    1. 重启机器

    安装升级包以后,重启机器,更新生效。

    外部链接

    1.BCLinux安全更新

    发布在 系统更新
  • LINUX-2106: 网络延迟导致keepalived故障问题分析

    LINUX-2106: 网络延迟导致keepalived故障问题分析

    1 问题概述

    1.1 问题来源及发送时间

    发生时间:1月14、1月27、1月29
    问题发现:近期老生产区(I版环境)承载的虚机web网站经常出现外网无法访问,20分钟左右又自动恢复。

    1.2 问题现象及影响范围

    问题现象:虚机(10.130.0.106/107)共两台,分别在老生产区node-43、node-57计算节点上,在虚机内部使用keepalive搭建HA环境,其中10.130.0.106为主,10.130.0.107为备,VIP为:10.130.0.240,在防火墙上进行映射,供外网访问。当故障发生时,从外网访问虚机连接失败,从内网访问虚机VIP无法访问,直接访问10.130.0.106及10.130.0.107可正常访问。故障发生后,大约二十分钟故障自动恢复。
    影响范围:虚机10.130.0.106/107。

    2 问题分析及过程

    为测试问题在node-43、node-57上分别搭建两台故障虚机环境一样的测试虚机(10.130.17.196/197),其中10.130.17.196为主,10.130.17.197为备,VIP为10.130.17,240。
    查看虚机keepalived日志发现主备热切换比较频繁,其中备节点10.130.17.197日志如下:

    一般来说,如果keepalived的备节点主动切换为主节点,有可能是心跳连接断开,既一段时间内没有收到VRRP通告报文,所以需要抓包做进一步分析。
    首先,在虚机内部抓包发现,确实有将近6秒(417~423)没有收到主节点(10.130.17.196)发出来的VRRP通告报文,后面1秒内却收到多个VRRP通告报文:

    另外,在这期间有备节点(10.130.17.197)自己发出来的VRRP通告报文:

    因为备节点(10.130.17.197)3秒内没收到VRRP通告,所以它会主动切换为主节点发VRRP通告,这样如果原来主节点并没有出现故障,就会导致双活,引发脑裂的问题。很显然,在这期间keepalived心跳丢失是导致主备频繁切换的主要原因。
    从主节点(10.130.17.196)抓包来看,它在收到备节点(10.130.17.197)VRRP通告报文这段时间内,确实是每隔1秒发送一个VRRP通告:

    所以主节点(10.130.17.196)发出的VRRP通告应该是被备节点(10.130.17.197)延迟接收将近6秒,至于是在物理链路上还是虚拟链路上被延迟,需要进一步抓包分析。
    首先在备节点(10.130.17.197)所在的计算节点上的物理网卡抓包发现,同样VRRP报文延迟了将近6秒(430-436)被接收:

    另外根据交换机端抓包信息发现所以VRRP报文转发均正常,没有发生延迟:

    3 问题原因分析

    问题可以基本定位在备节点所在计算节点上,有可能由于网卡中断延迟收包导致VRRP通告数据包接收延迟,如果是网卡中断导致延迟,有可能是系统负载过高导致的。为了验证该现象,需要进一步的收集性能数据,所以在该计算节点上运行负载监控脚本一周,结果发现在每次发生延迟现象的那个点,CPU 0的idle是0.00%,也就是说该CPU负载达到了100.00%:

    另外,网卡中断IRQ基本都CPU 0上发生的:

    如果CPU 0负载持续冲高,肯定会导致网卡接收数据包出现延迟。另外,从top结果来看,基本都是某kvm虚机进程CPU占用率持续偏高,:

    因此可以认为因为kvm虚机资源占用率较高导致计算节点CPU 0过载,从而延迟了网卡中断处理,最终导致数据包延迟收发影响了虚机业务。

    4 后续处理措施、方案及计划建议

    首先对计算节点网卡中断处理进行调优,为了分散CPU处理网卡中断的请求,可以绑定网卡8个中断号(123~132,133~142)至不同的CPU核心,比如使用set_irq_affinity.sh脚本进行如下设定将会默认绑定前面8个CPU:

    ./set_irq_affinity.sh eth4 eth5
    

    另外,对于kvm虚机也需要进行CPU绑定性能调优,可以使用virsh vcpupin进行配置,例如绑定instance-0000005e 的vcpu0 到物理cpu4:

    virsh vcpupin instance-00000146 0 4
    

    性能调优方案建议如下,因为计算节点一共32个CPU,可以预留4个CPU绑定物理网卡eth4及eth5的中断号,剩下来28个CPU可以通过virsh vcpupin预留给kvm虚机。如果需要保留虚机绑定CPU的配置,建议参考openstack相关帮助手册。

    发布在 技术支持
  • BCLinux6&7 下kdump服务的配置、使用和问题定位方法

    预备知识说明:
    本文主要讲解kdump的配置、使用注意点 及 问题定位方法等,并不涉及kdump原理介绍。
    建议阅读本文档之前,先阅读这2篇原理性文章:
    1. Kdump 的基本概念
    2. Kdump 实现的基本原理

    适用系统

    • BigCloud Enterprise Linux 6.5
    • BigCloud Enterprise Linux 6.8
    • BigCloud Enterprise Linux 7.1
    • BigCloud Enterprise Linux 7.2
    • BigCloud Enterprise Linux 7.3

    对于其他系统,请谨慎参考,不保证文档中所述内容完全适用。

    BCLinux6

    安装:

    el6系列的kdump服务是基于kexec-tools的,所以,要使用kdump服务,需要安装kexec-tools工具包。

    yum install kexec-tools
    

    配置:

    首先,kdump对内存有要求,默认情况下,系统的grub中配置为:crashkernel=auto。此时,系统的物理内存必须至少满足如下的限制

    2 GB on 32-bit and 64-bit x86 architectures;     
    

    即默认配置下,系统的物理内存需要超过2G,kdump才能正常工作

    1、EL6系统crashkernel=auto时的默认内存预留策略

    EL6系列下,如果配置crashkernel=auto ,则默认预留大小为128M(即kdump服务默认假设系统的内存为2G以上),如果系统物理内存超过1T,则每T会再加上64M,即如果当前系统内存为1T,则crashkernel需要192M。 最大预留大小可为896M。

    2、kdump相关的配置文件:

    1) /boot/grub/grub.conf

    此文件中可配置crashkernel的大小:

    [root@promote ~]# egrep -v '^$|^#'  /boot/grub/grub.conf 
    ...
    	kernel /boot/vmlinuz-2.6.32-431.el6.x86_64 ro root=UUID=xxx ... crashkernel=auto  ...
    ...
    

    2)/etc/sysconfig/kdump

    此文件有如下常用配置项:

    [root@localhost ~]# egrep -v '^$|^#' /etc/sysconfig/kdump
    ...	
    //rd.memdebug 指定了调试信息级别,具体可以 man kdump.conf 查阅
    rootflags=nofail acpi_no_memhotplug rd.memdebug=3"     
    ...
    

    2) /etc/kdump.conf

    主配置文件,主要有如下配置项:

    #raw /dev/vg/lv_kdump    //将vmcore存放到裸盘上
    ...
    #nfs my.server.com:/export/tmp   //将vmcore存放到远程服务器
    ...
    path /var/crash      //vmcore文件的存放位置
    core_collector makedumpfile -l --message-level 1 -d 31   //配置kdump收集信息的方式
    ...
    #default shell       //发生crash时,kdump默认的行为,默认情况下是当检测到crash后,挂载root文件系统,并执行/sbin/init
    

    补充:如果/etc/kdump.conf 配置文件被修改,则重启kdump即会重新生成kdump.img文件:/boot/initrd-xxxx-kdump.img

    其他相关配置请阅读:CONFIGURING KDUMP ON THE COMMAND LINE

    3、如何判断捕获内核是否加载

    可通过查看 /sys/kernel/kexec_crash_loaded 的值。“1”为已经加载,当发生kernel crash时会捕获vmcore文件;“0”为还未加载。

    4、缩小 crashkernel

    可以通过向 /sys/kernel/kexec_crash_size 中输入一个比其原值小的数来缩小甚至完全释放 crashkernel

    使能kdump服务:

    chkconfig kdump on
    service kdump start
    

    验证:

    此项为必做项,在配置kdump服务的时候,在没有完全验证通过之前,均不要认为kdump服务已经配置成功了。

    确认kdump服务启动:

    ~]# service kdump status
    Kdump is operational
    

    强制系统crash:

    echo 1 > /proc/sys/kernel/sysrq
    echo c > /proc/sysrq-trigger
    

    正常情况下,执行完成后,系统将会发生crash,并自动重启,

    最后在 /var/crash 目录下生成vmcore文件,文件格式为:address-YYYY-MM-DD-HH:MM:SS/vmcore

    问题排查

    很多时候,我们会发现如果使用 crashkernel=auto,系统的kdump服务无法正常工作。

    这个时候,我们首先需要按照如下思路排查:

    1. 相关配置是否正确,kdump服务是否正常启动:

    首先根据上述的配置步骤,查看各项配置是否均正确,kexec-tools是否已经安装。

    2. 结合当前系统的物理内存大小,排查crashkernel的值是否恰当:

    如果系统的物理内存介于512M-2G,则建议crashkernel为64M,如果系统内存大于2G,则建议为128M。

    因此,如果发现kdump无法正常使用,且系统的物理内存又较小,建议按照如下配置/boot/grub/grub.conf

    title Red Hat Enterprise Linux Server (2.6.32-220.el6.x86_64)
            root (hd0,0)
            kernel /vmlinuz-2.6.32-220.el6.x86_64 ro root=/dev/sda3 crashkernel=xxxM
            initrd /initramfs-2.6.32-220.el6.x86_64.img
    

    配置语法介绍:

    crashkernel=<range1>:<size1>[,<range2>:<size2>,...][@offset] 
    
    参数说明:             
     range=start-[end] 	 
     'start' is inclusive and 'end' is exclusive. 
     
    举例:
     crashkernel=512M-2G:64M,2G-:128M
    

    配置完成后,需要重启系统,新的配置才能生效

    在重启后,可以执行上述的验证步骤再验证一下。

    3. 上述步骤后,还是无法生成vmcore文件:

    此时,建议将/boot/grub/grub.conf中的crashkernel的值修改为:crashkernel=768M@0,再重启系统,进行验证。

    如果验证能够正常产生vmcore,则再缩小crashkernel的值为256、128,直到无法生成vmcore为止,则上一次的值即为合适的值。


    BCLinux7

    安装:

    CentOS7中,最小化安装的系统会包含kdump服务,因此无需再单独安装kexec-tools工具,如果未安装,则可使用如下命令安装:

    yum install kexec-tools
    

    注意:
    从RHEL7.4 开始,Kdump中包含了对Intel IOMMU 驱动的支持。当在RHEL7.3之前的系统中使用时,建议关闭Intel IOMMU的支持。

    配置:

    对于EL7系列系统,同样,kdump对内存有要求,如果grub中配置为:crashkernel=auto,则系统内存必须至少满足如下的限制:

    • 2 GB on 32-bit and 64-bit x86 architectures;

    1、EL7系统crashkernel=auto的默认预留策略:

    EL7下,crashkernel=auto时,系统的配置大小的策略如下:

    Architecture					Available Memory 					Minimum Reserved Memory
    AMD64 and Intel 64 (x86_64) 		2 GB and more                       160 MB + 2 bits for every 4 KB of RAM. For a system with 1 TB of memory, 224 MB is the minimum (160 + 64 MB).
    

    2、kdump相关的配置文件:

    相比于EL6的直接操作/boot/grub/grub.conf文件,EL7系列多了一个配置文件,用户可以直接操作/etc/default/grub来防止一些不必要的错误发生:

    1) /etc/default/grub

    此文件可以指定crashkernel的值。

    [root@localhost ~]# egrep -v '^$|^#' /etc/default/grub 
    ...
    GRUB_CMDLINE_LINUX="rd.lvm.lv=bclinux/root crashkernel=128M rd.lvm.lv=bclinux/swap rhgb quiet"   //指定crashkernel值
    ...
    

    2)其他2个配置文件(/etc/sysconfig/kdump/etc/kdump.conf)可参考EL6系列的配置方法。

    补充:如果/etc/kdump.conf 配置文件被修改,则重启kdump即会重新生成kdump.img文件:/boot/initrd-xxxx-kdump.img

    3、如何自定义crashkernel的大小:

    建议/etc/default/grub可以采用如下配置:

    crashkernel=<range1>:<size1>[,<range2>:<size2>,...][@offset] 
    
    参数说明:  
           
    range=start-[end] 	 
    'start' is inclusive and 'end' is exclusive. 
     
     举例:
     crashkernel=512M-2G:64M,2G-:128M
    

    举例:

    如下的配置是指定预留内存的起始偏移位置:
    crashkernel=128M@16M    	//表示预留的128M内存从实际的物理内存的16M位置(0x01000000)开始算起。
    crashkernel=512M-2G:64M,2G-:128M@16M       //表示预留内存从实际的物理内存的16M位置(0x01000000)开始算起。
    

    使能kdump服务:

    systemctl enable kdump
    systemctl start kdump  
    

    验证:

    此项为必做项,在配置kdump服务的时候,在没有完全验证通过之前,均不要认为kdump服务已经配置成功了。

    确认kdump服务启动:

    systemctl status kdump 
    

    强制系统crash:

    echo 1 > /proc/sys/kernel/sysrq
    echo c > /proc/sysrq-trigger
    

    正常情况下,执行完成后,系统将会发生crash,并自动重启,最后在 /var/crash 目录下生成vmcore文件,文件格式为:address-YYYY-MM-DD-HH:MM:SS/vmcore

    问题定位

    很多时候,我们会发现如果使用crashkernel=auto,系统的kdump服务无法正常工作,如下是系统内存1G,kdump服务无法启动的情况:

    这个时候,我们首先需要按照如下思路排查:

    1、相关配置是否正确,kdump服务是否正常启动

    首先根据上述的配置步骤,查看各项配置是否均正确,kexec-tools是否已经安装。

    在此基础上,针对系统内存过小,我们可以自行指定 /boot/grub2/grub.cfg 中的 crashkernel 的大小:如果系统内存介于512M-2G,则建议crashkernel为64M,如果系统内存大于2G,则建议为128M

    方法如下:

    1)修改:/etc/default/grub 文件的 GRUB_CMDLINE_LINUX 行的crashkernel=auto 的值
    此处假设改为64M(截图中为96M):

    2)在grub2引导的系统上执行如下命令:

    grub2-mkconfig -o /boot/grub2/grub.cfg
    

    如果是uefi启动的系统,则执行如下命令:

    grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
    

    3)验证grub修改正确:

    2、crashkernel的值仍然不正确

    在kdump服务已经正常启动,但在人为触发crash时,如果仍然失败(如卡住不动等情况)。

    此时,可以尝试将 crashkernel=768M@0M ,如果此时能正常生成vmcore文件,则说明还是crashkernel的值没有配置正确导致的。

    采用上述方法验证后,发现RHEL7.1系统,之前会hang住的系统,如果配置crashkernel=768M@0M ,则会自动生成vmcore文件,可以断定是crashkernel配置的问题。

    之后再将其减少为256、128均是ok的,直到改为64M,发现无法生成vmcore文件,所以,结合验证结果,建议 当前问题系统的 crashkernel 值可以手动指定为>= 128M

    另外,也建议使用 /etc/kdump.conf 配置文件中的 debug_mem_level 参数(查看kdump.conf 发现此参数已经移到了/etc/sysconfig/kdump中)来继续测试内存需求的实际大小。

    3、/var/crash挂载点没有被kdump识别

    如果在进行了第二步后,仍然无法正常使用kdump,则查看系统的/var分区是否是一个单独的挂载点。

    如果/boot下的 initramfs-xxx-kdump.img 文件生成时,/var没有单独的挂在到某个分区下,那么在kdump.img生成好后,修改/var目录的挂载点信息(将/var单独的挂载到特定的分区中),则会导致生成的kdump.img 无法使用/var/crash目录。

    即当kdump在生成vmcore文件的时候,找不到/var路径的实际文字,从而没有权限写入vmcore文件。

    此时,可以按照如下的2种方案进行操作:

    方案一:

    更改默认的vmcore文件位置(无需重启系统,即可生效

    1)将/etc/kdump.conf 中的path /var/crash  改为 path /root    #表示系统crash时,生成的vmcore存放在/root目录下
    2)重启kdump服务:systemctl restart kdump。
    
    方案二:

    修改grub命令行参数,指明 /var分区的挂载点信息(需重启系统才能生效

    第一步:

    执行lsblk,获取`/var`分区的路径,此处假设是`rootvg/var`
    

    修改这个文件,添加红框内容:

    第二步:

    备份/boot/grub2/grub.cfg
    cp  /boot/grub2/grub.cfg  /boot/grub2/grub.cfg_bak_20180228
    

    第三步:

    grub2-mkconfig -o /boot/grub2/grub.cfg
    

    第四步:

    重启系统
    

    参考文档

    1. Redhat6 Deployment Guide:THE KDUMP CRASH RECOVERY SERVICE
    2. How should the crashkernel parameter be configured for using kdump on RHEL6?
    3. Redhat7 Kernel Crash Dump Guide: Introduction to kdump
    4. How should the crashkernel parameter be configured for using kdump on RHEL7?
    5. Kernel crash dump (vmcore) not getting generated inside partition mounted under /var/crash
    发布在 技术分享
  • BCLinux 7 系统批量授权管理

    BCLinux 7 系统批量授权管理

    BCLinux 7新增加的授权管理可以方便为系统提供离线/在线的授权管理和跟踪。如果系统未得到授权,那么将不能获得商业操作系统所提供的服务,例如软件包安装及升级服务,技术支持和维护等服务。

    在集群规模比较大的情况下,为了减少工作量,需要通过批量工具进行集群的批量授权管理。本文通过常用的ansible工具,讲述如何进行批量的授权。主要包含两部分:批量获取集群的机器码信息;批量进行集群授权。

    批量收集机器码信息

    1. 安装ansible工具(可以通过搭建本地源安装ansible软件包,这里不做赘述,假设已经搭建完成本地源);
     [root@ansible ~]# yum install ansible
    
    1. 下载有关批量授权管理的ansible脚本,下载地址如下:http://mirrors.bclinux.org/bclinux/public/license_ansible.tar.gz ,将其放置到机器某个目录下(假设放置到root根目录下)并解压;
    [root@ansible ~]# tar -xzvf license_ansible.tar.gz
    

    可以看到解压后生成的目录中,包含了批量收集机器码和批量授权两个目录,各自包含了影响的脚本等。

    1. 配置ansible配置文件hosts,将机器中节点的ip地址等添加到/etc/ansible/hosts文件中(以下例子仅仅作为示范,真实情况要视具体情况而定),并设置/etc/ansible/ansible.cfg中host_key_checking = False,同时打开日志功能 log_path = /var/log/ansible.log(可将配置文件中该选项前的注释去掉或者通过以下的命令行方式设置);
    [root@ansible ~]# cat /etc/ansible/hosts 
    [servers]
    172.16.200.192 ansible_ssh_user=root  ansible_ssh_pass=19900813  ansible_ssh_port=22
    172.16.200.188 ansible_ssh_user=root  ansible_ssh_pass=19900813  ansible_ssh_port=22
    
    [root@ansible ~]# sed -i "s/.*host_key_checking.*/host_key_checking = False/" /etc/ansible/ansible.cfg
    
    [root@ansible ~]# sed -i "s#.*log_path.*#log_path = /var/log/ansible.log#" /etc/ansible/ansible.cfg
    
    1. 执行ansible命令,执行前要确保集群网络的连通性,可以通过ping模块测试下机器中是否有网络节点不通的情况,可以通过输出结果的颜色观察或者查看日志 /var/log/ansible.log查找网络不通的节点;
    [root@ansible ~]# ansible servers -m ping 
    
    1. 清空日志 /var/log/ansible.log,收集机器码信息;
    [root@ansible ~]# echo > /var/log/ansible.log
    [root@ansible ~]# ansible servers -m shell -a "sys-id"
    [root@ansible ~]# ./License_Manager/Code_Collection/get-id.sh /var/log/ansible.log
    

    上述的第二条命令将会批量执行“sys-id”命令或者机器的机器码信息,输出到日志/var/log/ansible.log中,最后通过get-id脚本将会从日志文件中提取出机器码信息,最后的结果保存在License_Manager/Code_Collection/目录下的machine_code.text文本文件中。

    [root@ansible ~]# cat License_Manager/Code_Collection/machine_code.text 
    2DBF4D56-C527-4745-22ED-ED2182BBC149
    E24C4D56-D170-9D4E-2E9C-4FD481002D82
    

    用户通过以下命令确认机器码的数量和机器节点数目是否吻合,如果不吻合,可能是由于网络不通的原因。此时需要根据日志等途径找出网络不通的节点,然后在这些节点上手动执行"sys-id"命令获取机器码信息,再讲机器码信息追加到machine_code.text文本文件中即可。

    [root@ansible ~]# cat License_Manager/Code_Collection/machine_code.text | wc -l
    
    1. 拿到集群的机器码文本文件machine_code.text后,还需要将机器码信息上传到BCLinux客户服务平台。用户在订阅BCLinux 7系统时会得到平台的账号密码信息,凭此登录平台,平台的地址为:https://bcc.bclinux.org/app/index.html#/page/login ,如下图所示:

    客户服务平台界面

    登录平台后,点击右侧的“订阅”-->“我的订阅”,然后测试点击项目进入授权管理信息上传界面,如下图所示:

    客户服务平台授权信息上传界面

    首先点击模板下载,下载模板到本地,模板如下图所示,

    模板

    用户只需要将得到的机器码文本文件(如下图所示),直接整体复制粘贴到模板文件中的第一例即可,粘贴后的模板文件如下图示,

    machine_code

    包含机器码的模板文件

    然后选择界面的文件上传,最后保存即可。

    1. 用户通过客户服务系统平台上传了机器码信息以后,需要后台的管理员进行审批,审批通过后,用户即可再次通过平台,点击文本下载,最后生成的文本文件中包含了机器码和对应的授权信息,如下图所示。

    授权信息下载界面

    集群批量授权

    该步骤是将用户自己下载得到的包含机器码和授权码的文本文件通过ansible批量分发给各个机器,通过在各个机器上获取机器码,然后从文件文件从检索到相应的授权码信息,完成机器的授权工作。

    1. 将BCLinux返回给用户的包含授权码的文本文件重命名为''license.text'',然后放置在License_Manager/Code_Distribution/scripts/目录下即可;
    [root@ansible ~]# mv 2018-02-23.text license.text
    [root@ansible ~]# mv license.text License_Manager/Code_Distribution/scripts/
    
    1. 执行ansible-play批量将授权码分发到集群的各个节点;
    [root@ansible ~]# ansible-playbook License_Manager/Code_Distribution/playbook/license.yaml
    

    此外,对于因为网络不通导致的某些节点授权失败(可通过颜色显示或者日志查看),可以通过在这些节点上手动添加授权码到/etc/bclinux/license文件中也可以完成授权。

    发布在 产品公告
  • RE: LINUX-1021:存储节点内存分配失败问题分析

    学习了,分析的很清晰

    发布在 技术支持

与 BC-LINUX 的连接断开,我们正在尝试重连,请耐心等待