目录- 1 软件介绍 - 2 环境配置 - 3 系统配置 - 3.1 关闭防火墙(可选) - 3.2 修改SELINUX为disabled(可选) - 3.3 配置本地yum源（可选） - 4 软件编译 - 4.1 安装依赖包 - 4.2 Maven安装配置 - 4.3 MySQL编译安装 - 4.4 Zookeeper编译安装 - 4.5 Otter编译打包 - 5 软件配置 - 5.1 配置MySQL - 5.2 配置Manager - 5.3 配置Node - 6 软件运行 - 6.1 Otter运行 - 7 FAQ - 8 其他1 软件介绍Otter是一个分布式数据库同步系统，纯JAVA开发，基于数据库增量日志解析，准实时同步到本机或异地机房的mysql/oracle数据库。2 环境配置角色配置IP角色相关服务172.170.100.13ManagerOtter-manager，MySQL, zookeeper172.170.100.14NodeOtter-node 硬件平台服务器TaiShan 200 2280处理器2*KunPeng 920 4826内存16*32G 2666MHz系统盘1 * 1.2T SATA HDD数据盘1 * 960G SSD网盘1 * GE(板载) 软件平台软件名称版本号安装方法备注CentOS7.6https://support.huawei.com/enterprise/zh/doc/EDOC1100088654/3e971c8d本文档安装过程选择的环境为“Server with GUI”，并附加了“Development Tools”。OpenJDK1.8.0_252无需手动安装本文档使用 “Development Tools”自带的OpenJDK，如需安装其他版本，参考：https://www.huaweicloud.com/kunpeng/software/openjdk.htmlAria21.34.0-6见4.1章节Maven3.6.1见4.2章节MySQL8.0.17见4.3章节管理节点数据库对版本无特别要求，本文档以8.0.17为例。注意：同步支持的数据库为mysql系列的5.1 ~ 5.6/5.7版本，mariadb 5/10版本。Zookeeper3.4.14见4.4章节对版本无特别要求，本文档以3.4.14为例，以单机形式部署 3 系统配置3.1 关闭防火墙(可选)# 步骤 1 停止防火墙。 systemctl stop firewalld.service # 步骤 2 关闭防火墙。 systemctl disable firewalld.service3.2 修改SELINUX为disabled(可选)# 步骤 1 关闭防火墙。 sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/sysconfig/selinux       3.3 配置本地yum源（可选）若环境有外网条件，可不用配置本地源，直接用系统配置好的网上源或者自己添加网上源即可。# 步骤 1 配置源文件 mv /etc/yum.repos.d/ /etc/yum.repos.d-bak mkdir /etc/yum.repos.d echo -e "[local]\nname=local\nbaseurl=file:///mnt\ngpgcheck=0\nenabled=1" > /etc/yum.repos.d/local.repo # 步骤 2 执行cat确认上一步操作写入成功，显示如下图 cat /etc/yum.repos.d/local.repo# 步骤 3 挂载源镜像，将系统镜像通过KVM挂载 mount /dev/cdrom /mnt4 软件编译4.1 安装依赖包Node节点间依赖aria2传输，所有Node节点都需安装以下依赖# 步骤 1 添加epel源。 yum install -y epel-release # 步骤 2 安装aria2。 yum install –y aria2 4.2 Maven安装配置Maven只需要安装到编译打包的机器，其他的机器无需安装，这里安装到Manager节点# 步骤 1 下载并解压Maven 3.6.1到/home/tool目录下。 cd /home/tool wget https://archive.apache.org/dist/maven/maven-3/3.6.1/binaries/apache-maven-3.6.1-bin.tar.gz tar -zxvf apache-maven-3.6.1-bin.tar.gz mv apache-maven-3.6.1 /opt/tools/installed # 步骤 2 配置环境变量。 # 创建maven.sh文件并写入Maven环境信息 vim /etc/profile.d/maven.sh MAVEN_HOME=/opt/tools/installed/apache-maven-3.6.1 PATH=$MAVEN_HOME/bin:$PATH export MAVEN_HOME PATH #步骤 3 使环境变量生效。 source /etc/profile # 步骤 4 版本检查。 mvn -v# 步骤 5 修改配置文件优先使用鲲鹏镜像源。 # 修改/home/tool/mvn/conf/setting.xml，在profiles处添加鲲鹏镜像源 vi /home/tool/mvn/conf/setting.xml                  <profile> <repositories> <repository> <id>kunpeng</id> <url>https://mirrors.huaweicloud.com/kunpeng/maven/</url> <releases> <enabled>true</enabled> </releases> </repositories> </profile>4.3 MySQL编译安装Otter manager依赖于MySQL进行配置信息的存储，所以需要预先安装MySQL。本文档将MySQL安装到Manager所在节点，可根据实际需求安装，能相互访问即可。MySQL安装指导书参考：《数据库（mysql）环境搭建指导书.pdf》4.4 Zookeeper编译安装整个Otter架构依赖了zookeeper进行多节点调度，所以需要预先安装zookeeper。本文档以单机的形式部署到Manager节点，实际安装过程可根据需求部署，能相互访问即可。Zookeeper安装指导书参考：《Zookeeper 3.4.14环境搭建指导书》4.5 Otter编译打包# 步骤 1 下载并解压Otter-4.2.18到/home/otter下。 cd /home/otter wget https://github.com/alibaba/otter/archive/otter-4.2.18.tar.gz tar –zxvf otter-4.2.18.tar.gz cd otter-otter-4.2.18 # 步骤 2 编辑Pom.xml修改ojdbc6版本 # 默认使用的ojdbc6的版本官方已经下架，需进行相关的修改，本例修改为11.2.0.3的版本，经测试可正常运行。 # 修改Pom.xml的237行，将版本号改为11.2.0.3 vi pom.xml# 步骤 3 编辑Pom.xml配置仓库 # Otter在pom.xml限制了拉取的仓库，由于国内网络的原因，建议配置国内镜像源，本文档以鲲鹏源(arm源)和华为源为例，在55行处插入如下仓库信息： vi pom.xml<repository> <id>Kunpeng</id> <url>https://mirrors.huaweicloud.com/kunpeng/maven/</url> <releases> <enabled>true</enabled> </releases> <snapshots> <enabled>false</enabled> </snapshots> </repository> <repository> <id>huawei</id> <url>https://mirrors.huaweicloud.com/repository/maven/</url> <releases> <enabled>true</enabled> </releases> <snapshots> <enabled>false</enabled> </snapshots> </repository># 步骤 4 执行编译打包。 mvn clean install -Dmaven.test.skip -Denv=release # 步骤 5 检查编译打包结果。 # 编译完成后，会在根目录下产生target/manager.deployer-4.2.18.tar.gz和target/node.deployer-4.2.18.tar.gz ll target                              5 软件配置5.1 配置MySQLOtter manager依赖MySQL进行配置信息存储，需先初始化otter manager的系统表结构，以下命令须在能连接Manager MySQL的机器进行。# 步骤 1 下载otter manager系统表 cd /home/otter wget https://raw.github.com/alibaba/otter/master/manager/deployer/src/main/resources/sql/otter-manager-schema.sql # 步骤 2 登录mysql执行otter-manager-schema.sql # 这里主机Ip请根据实际IP填写 mysql –h 主机IP –uroot -p MySql> source /home/otter/otter-manager-schema.sql5.2 配置Manager# 步骤 1 复制并解压manager.deployer-4.2.18.tar.gz # 将4.4章节编译打包生成的manager.deployer-4.2.18.tar.gz复制到manager节点的/home/otter/manager下，具体目录请根据实际情况修改。 mkdir –p /home/otter/manager cp manager.deployer-4.2.18.tar.gz /home/otter/manager/ cd /home/otter/manager tar –zxvf manager.deployer-4.2.18.tar.gz # 步骤 2 修改manager配置文件。 # 配置访问IP，数据库，zookeeper，请根据实际情况配置 vi conf/otter.properties ## otter manager domain name #修改为正确访问地址/ip，例如本文档这里修改为172.170.100.13 otter.domainName = 127.0.0.1 ## otter manager http port，如被占用可自行更改 otter.port = 8080 ## jetty web config xml otter.jetty = jetty.xml ## otter manager database config ，修改为正确数据库信息 otter.database.driver.class.name = com.mysql.jdbc.Driver otter.database.driver.url = jdbc:mysql://127.0.01:3306/ottermanager otter.database.driver.username = root otter.database.driver.password = hello ## otter communication port,节点沟通的端口 otter.communication.manager.port = 1099 ## otter communication pool size otter.communication.pool.size = 10 ## default zookeeper address，修改为正确的地址，手动选择一个地域就近的zookeeper集群列表 otter.zookeeper.cluster.default = 127.0.0.1:2181 default zookeeper session timeout = 90s otter.zookeeper.sessionTimeout = 90000 otter arbitrate connect manager config otter.manager.address = ${otter.domainName}:${otter.communication.manager.port} 5.3 配置Node# 步骤 1 复制并解压node.deployer-4.2.18.tar.gz # 将4.4章节编译打包生成的node.deployer-4.2.18.tar.gz复制到node节点的/home/otter/node下，具体目录请根据实际情况修改。 mkdir –p /home/otter/node cp node.deployer-4.2.18.tar.gz /home/otter/node/ cd /home/otter/node tar –zxvf node.deployer-4.2.18.tar.gz # 步骤 2 修改node配置文件。 # 配置访问IP，数据库，zookeeper，请根据实际情况配置 vi conf/otter.properties otter node root dir otter.nodeHome = ${user.dir}/../node ## otter node dir otter.htdocs.dir = ${otter.nodeHome}/htdocs otter.download.dir = ${otter.nodeHome}/download otter.extend.dir= ${otter.nodeHome}/extend ## default zookeeper sesstion timeout = 60s otter.zookeeper.sessionTimeout = 60000 ## otter communication pool size otter.communication.pool.size = 10 ## otter arbitrate & node connect manager config ，修改为正确的manager服务地址 otter.manager.address = 127.0.0.1:1099 6 软件运行6.1 Otter运行# 步骤 1 启动Manager。 # 进入Manager节点otter目录，执行启动脚本 cd /home/otter/manager ./bin/startup.sh# 步骤 2 登录网页。 # 在浏览器登录5.2章节配置的访问地址，例如本文档为http://172.170.100.13:8080# 步骤 3 登录管理员账号。 # 浏览页面默认是匿名访问，需登录管理员账号才能进行管理。点击页面右上角进行登录，默认账号密码为admin和admin# 步骤 4 添加zookeeper集群。 # 点击“机器管理”下的“zookeeper管理”，之后点击“添加”添加zookeeper集群信息，填写相关信息“保存”后完成添加。注意，集群节点配置处必须以分号结束。步骤 5 添加节点。 # 点击“机器管理”下的“Node管理”，之后点击“添加”添加机器信息 # 机器名称：可以随意定义，方便自己记忆即可 # 机器ip：对应node节点将要部署的机器ip，如果有多ip时，可选择其中一个ip # 机器端口：对应node节点将要部署时启动的数据通讯端口，官方建议值：2088 # 下载端口：对应node节点将要部署时启动的数据下载端口，官方建议值：9090 # 外部ip ：对应node节点将要部署的机器ip，存在的一个外部ip，允许通讯的时候走公网处理。 # zookeeper集群：为提升通讯效率，不同机房的机器可选择就近的zookeeper集群。这里获取到机器的序号是“2”# 步骤 6 配置Node序号。 # 机器添加完成后，跳转到机器列表页面，获取对应的机器序号nid，上一步骤能得到node1序号是2， # 需要将其配置到对应Node节点的conf目录下，下面的“2”是指添加机器后的序号，请根据实际情况填写 cd /home/otter/node echo 2 > conf/nid #步骤 7 启动Node。 cd /home/otter/node ./bin/startup.sh7 FAQ支持同步的数据库有哪些？见官方声明：支持mysql系列的5.1 ~ 5.6/5.7版本，mariadb 5/10版本.   (全面支持ROW/STATEMENT/MIXED几种binlog格式的解析)编译过程jtester包无法下载Jtester包仅在google源有，由于国内网络原因，可能无法直接拉取，可以手动下载jtester-1.1.8.jar，然后通过以下命令安装到本地仓库：mvn install:install-file –Dfile=jar包所在路径 –DgroupId=org.jtester –DartifactId=jtester –Dversion=1.1.8 –Dpackaging=jar8 其他参考文档：        https://github.com/alibaba/otter/wiki

项目名称与简介 (Project introduction)名称: CircleLinux介绍如下：Circle Linux 是国际化社区驱动的开源软件，使命在与努力专注于围绕 Linux 平台提供更强大的开源生态。提供企业级、生产环境就绪的 Linux 发行版。Global Community-driven Opensource software effort focus on delivering a robust open source ecosystem around a Linux platform.bring you Enterprise-grade, Production-ready Linux Distro.官网：www.cclinux.orgGitHub：https://github.com/circle-linux上游地址与镜像方法 (How to mirror)rsync -avh rsync://msync.cclinux.org/circle/pub/ . 镜像大小 (Mirror size)目前是400G，建议预留，随着全新版本的发布容量随之可能会到600G左右。备注 (Note)非常感谢你们提供的镜像服务，希望可以早日使用华为mirrors 提供的CircleLinux的Mirror 。Best Regards ！

1. 开启pageowner功能1.1 下载对应版本内核源码uname –a 查看对应内核的version-release方式一：下载 https://gitee.com/openeuler/kernel源码并切换到对应tag方式二：下载对应版本号的src.rpm可 配置source repo：dnf download –source 下载对应src.rpm也可通过wget 对应repo源的软件包地址，openEuler-20.03-LTS-SP1的源码包路径如下：https://repo.openeuler.org/openEuler-20.03-LTS-SP1/source/Packages/https://mirrors.huaweicloud.com/openeuler/openEuler-20.03-LTS-SP1/source/Packages/ 1.2 开启page_owner选项构建软件包以下均以arm架构下下载src.rpm的形式为例安装src.rpmrpm –ivh  kernel-xxxxx.src.rpmcd /root/rpmbuild/SPECSdnf builddep kernel.speccd /root/rpmbuild/SOURCEStar –zxvf kernel.tar.gz (如果没安装tar dnf install tar)cd kernelmake menuconfig键入/  进入搜索界面搜索 page_owner 回车确认键入1  进入配置界面键入Y  选中page_owner选项然后退出grep –rn “PAGE_OWNER” .config 查看选项是否生效使用以下命令构建export INSTALL_MOD_STRIP=1make binrpm-pkg -j200 生成的rpm存放在/root/rpmbuild/RPMS/$basearch/下kernel-xxxx.rpmkernel-headers-xxxx.rpm该软件包的release为空和社区下载的名字明显不同，后面区分grub选项用1.3 获取page_owner数据安装kernel rpm包（只需要安装主包）rpm –ivh –force kernel-xxxxx.rpm 确认grub的菜单是否存在新内核在新的启动项后增加page_owner=on选项以上操作均可以在/boot目录下的grub.cfg或/etc/grub2.cfg中确认2. 获取page_owner数据2.1重启统计page_ownercd /root/rpmbuild/SOURCES/kernel/tools/vmmake –jcat /sys/kernel/debug/page_owner > page_owner_full.txtgrep –v ^PFN page_owner_full.txt > page_owner.txt./page_owner_sort page_owner.txt sorted_page_owner.txt2.2 计算page_owner数据总值最终查看sorted_page_owner.txt文件其中每块数据首行“ times:”前的数据为申请的次数：第二行order后的数据为申请的page数量，结果为2^n个page页大小根据 getconf PAGESIZE或getconf PAGE_SIZE查看最终启动后内存占用总量为 (∑(<times> * 2 ^ <order>)) * <page_size>2.3 简单的计算脚本如下：FILE_NAME = "sorted_page_owner.txt" # 根据获取的page_owenr结果文件位置修改 PAGE_SIZE = 4028 # 根据getconf PAGESIZE或getconf PAGE_SIZE的结果进行修改 def main(fn): result = 0 with open(fn, "r") as f: times = 0 order = 0 for line in f: if " times:" in line: times = int(line.split(" ")[0]) if "order" in line and times > 0: try: line = line.replace(",", "") order = int(line.split(" ")[4]) result += times * int(pow(2, order)) print("times: [{}], order: [{}], result: [{}]".format(times, order, result)) except Exception as e: print(e) finally: times = 0 order = 0 return result if __name__ == "__main__": result = main(FILE_NAME) print("sum: {}M".format((result * PAGE_SIZE / 1024 / 1024)))  

此处以openEuler 20.03LTS SP3 x86_64的iso为例1. 下载openEuler SP3 x86_64的isocid:link_0 2. 创建以下目录供后续步骤使用mkdir -p /mnt/cdrom /mnt/openEuler_file 3. 本地挂载isomount -o loop /mnt/openEuler-20.03-LTS-SP3-x86_64-dvd.iso /mnt/cdrom 4. 将/mnt/cdrom目录下的文件全部拷贝到/mnt/openEuler_file目录下cp -r /mnt/cdrom/* /mnt/openEuler_file/cp /mnt/cdrom/.discinfo /mnt/openEuler_file/cp /mnt/cdrom/.treeinfo /mnt/openEuler_file/ 5. 从openEuler的软件所仓库下载megaraid_sas的驱动rpm包，放置在/mnt/openEuler_file/Packages目录下此处以megaraid_sas.rpm包为例，如果要在iso中添加其他rpm包，请记得将rpm包的安装依赖和编译依赖软件包都同时引入。x86_64驱动：wget -P /mnt/openEuler_file/Packages  https://repo.oepkgs.net/openEuler/rpm/openEuler-20.03-LTS/contrib/drivers/x86_64/Packages/kmod-megaraid_sas-07.714.04.00-x86_64.rpmaarch64驱动：wget -P /mnt/openEuler_file/Packages  https://repo.oepkgs.net/openEuler/rpm/openEuler-20.03-LTS/contrib/drivers/aarch64/Packages/kmod-megaraid_sas-07.714.04.00-aarch64.rpm6. 修改/mnt/ openEuler_file /repodata/normal.xml文件，在最小化安装的core分组里增加软件包vi /mnt/openEuler_file/repodata/normal.xml在下添加以下信息：kmod-megaraid_sas 7. 使用createrepo命令createrepo -g /mnt/openEuler_file/repodata/normal.xml /mnt/openEuler_file/ 8. 安装genisoimage软件dnf install -y genisoimage 9. 使用mkisofs命令制作iso如果制作x86_64架构的iso，执行命令请参考：mkisofs -R -J -T -r -l -d -joliet-long -allow-multidot -allow-leading-dots -no-bak -V openEuler-20.03-LTS-SP3-x86_64 -o /opt/openEuler-20.03-LTS-SP3-x86_64.iso -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table  -eltorito-alt-boot -e images/efiboot.img -no-emul-boot ./如果制作aarch64架构的iso，执行命令请参考： mkisofs -R -J -T -r -l -d -joliet-long -allow-multidot -allow-leading-dots -no-bak -V openEuler-20.03-LTS-SP3-aarch64 -o /opt/openEuler-20.03-LTS-SP3-aarch64.iso -e images/efiboot.img -no-emul-boot ./10. ISO制作完成，可以进行安装使用

1. 下载内核源码dnf install -y kernel-source 2. 下载编译源码的依赖软件包dnf install -y rpm-build openssl-devel bc rsync gcc gcc-c++ flex bison m4 elfutils-libelf-devel 3. 如果需要向内核合入patch，请从官网下载对应的patch文件，执行以下命令将patch合入内核源码patch -d /usr/src/ linux-4.19.90-2202.1.0.0136.oe1.x86_64 -p1 < patch_file4. 进入linux源码主目录cd /usr/src/linux-4.19.90-2202.1.0.0136.oe1.x86_64/5. 修改内核的版本号，Makefile的前4个参数和版本号相关，可进行修改，修改的版本号需要比当前系统使用的内核版本号高，否则无法进行安装vi Makefile 6. 编译config文件make openeuler_defconfig（如果需要修改config文件，该文件在/usr/src/linux-4.19.90-2202.1.0.0136.oe1.x86_64/arch/x86/config 目录下） 7. 编译内核make binrpm-pkg -j{num}-j参数表示指定多线程编译，最大线程数量为CPU核数。8. 编译完成后查看对应目录下生成的内核rpm包。ll root/rpmbuild/RPMS/x86_64 9. 安装内核rpm -ivh /root/rpmbuild/RPMS/x86_64/kernel-4.19.91-1.x86_64.rpm10. 查看安装完成的内核rpm -qa | grep kernel 11. 重启机器，在进入内核选择页面时，选择编译安装的内核 12. 查看当前系统的内核版本uname -r13. 执行以下命令可以单独编译内核驱动make ARCH=x86_64 CONFIG_IGC=m drivers/net/ethernet/intel/igc/igc.ko

今天周五啦，掐指一算，好久没更新帖子了，今天继续我们上一期的话题，使用DemonCAT，如何注入Linux OS进程方面的故障呢，我们一起来看下吧！进程异常退出进程/线程死循环 进程/线程D状态进程挂起线程挂起进程Z状态线程数过多进程句柄数耗尽线程异常退出进程数过多进程页表数据被踩进程内存泄漏（分配）内核线程R死锁内核进程死锁进程内存数据被踩停止进程定时器进程内存泄漏（malloc)DemonCAT关于Linux OS 注入进程故障方面的内容就先介绍到这，当然如果有关于任何章节感兴趣的伙伴，欢迎留言或联系我们，下一期，向大家介绍文件系统方面的故障内容，尽情期待~

本文分享自华为云社区《[GaussDB(DWS) ODBC 问题定位指南](https://bbs.huaweicloud.com/blogs/334926?utm_source=zhihu&utm_medium=bbs-ex&utm_campaign=ei&utm_content=content)》，作者： power_gouge 。 用户的应用程序，调用的ODBC的API，其实是由驱动管理器提供的，这个驱动管理器在微软上就是odbcad32(.exe/.dll)，在Linux上就是UnixODBC。再由它们来调用ODBC的具体驱动（Gauss、Oracle、TD……）。 所以一般问题基本会出在以下几个方面： - 应用加载驱动管理器 - 驱动管理器加载驱动 - 驱动连接数据库 一个典型的用户应用程序如下：  # 问题处理 ## 应用程序加载驱动管理器失败 **Windows** Windows由于操作系统实现机制的问题，ODBC属于操作系统组件的一部分，除非操作系统损坏，一般不会出现应用程序加载驱动管理器失败；只会出现驱动管理器加载驱动失败。所以这里不再赘述。 **Linux** Linux上应用程序加载驱动管理器，是指的应用程序依赖于UnixODBC的相关动态库，启动时要将其加载到自己的进程空间中。加载出现问题多表现为在启动时找不到libodbc.so.x/libodbcinst.so.x等库。 解决此问题： 首先确认环境中是否安装了UnixODBC。如果安装了，那么至少会有isql/odbcinst等工具可用。例如可使用which isql这样的命令来确定安装路径。相关的lib库一般会在which isql指定的bin目录的同级目录下，将其添加到LD_LIBRARY_PATH中重启应用程序便可。 export LD_LIBRARY_PATH=/where/unixodbc/installed/lib:$LD_LIBRARY_PATH 特别注意，此语句只影响**当前shell**会话中的后续命令，其他会话不受影响，特别是后台启动的进程。如果是后台进程，请与应用程序的开发人员确认其运行环境如果修正。 如果确认LD_LIBRARY_PATH已经生效（可以打开/proc/应用程序pid/environ文件确认）,依然无法加载libodbc.so.x/libodbcinst.so.x，那么可能是.1或者.2的库的问题。 历史原因，一般的开发环境中，UnixODBC提供的库既可能叫libodbc.so.1也可能叫libodbc.so.2。用户程序可能依赖了.2，但是环境中只有.1；也有可能是存在.2，但是依赖了.1。 解决此问题，只需要在UnixODBC的lib目录下，将不存在的版本建立成软链接，保证.1与.2都存在，这样出问题的机率便会小很多。特别注意，这里强烈建议是建立软链接，而不要拷贝物理文件，不然可能出现一个应用程序进程中，加载了两个导出函数完全相同的.so，这样可能会引起一些比较难定位的启动错误，后文中会讲到。 ## 驱动管理器加载驱动失败 **Windows** 最常见x86与x64架构不同导致的加载失败；此问题的典型报错为： 在指定的 DSN 中，驱动程序和应用程序之间的体系结构不匹配 此问题可能的原因：在64位程序中使用了32位驱动，或者相反。 在64位系统上： C:\Windows\SysWOW64\odbcad32.exe：这是32位ODBC驱动管理器。 C:\Windows\System32\odbcad32.exe：这是64位ODBC驱动管理器。 **使用不同架构的应用程序时，请使用不同的驱动管理器；同时安装不同的驱动类型。** 32位系统上只能跑32位程序，也无法安装64位驱动，所以基本不用区分。 如果是64位系统，那么它既支持32位程序，也支持64位程序；如果不能确定应用程序是32还是64，可以使用以下办法： ctrl + shift + esc 打开任务管理器 查看进程列表中某进程后边有没有*32的字样（有就是32位，没有就是64位），如下图：\  **Linux** **环境中缺少psqlodbcw.so的库** 一般这个问题的报错是 [UnixODBC][Driver Manager]Can't open lib 'xxx/xxx/psqlodbcw.so' : file not found. 可能的原因有： odbcinst.ini中配置的路径不正确，最简单的办法是 ls -l 一下这个报错的文件，看看这个是不是真的存在，同时具有执行权限。 依赖的库不存在，此时最简单的办法是ldd 一下这个报错的文件，看看是不是真的缺少库，如果缺少库会出现如下问题：  要处理这个问题，需要将unixodbc的安装目录下的lib，添加到LD_LIBRARY_PATH里，例如： export LD_LIBRARY_PATH=/where/unixodbc/installed/lib:$LD_LIBRARY_PATH 同时，在UnixODBC的安装的lib目录下，看看libodbcinst.so.x后边的后缀是.1还是.2。如果是.2，那么请建立一个软链接，链接到.1，便可以解决此问题。 如果该目录下只有.1的库，没有.2的库，也建议建立一个.2的软链接，防止应用程序依赖于.2，我们依赖于.1，引起冲突。 特别注意，当前会话的LD_LIBRARY_PATH不代表应用程序运行时也是同样的LD_LIBRARY_PATH，必要的时候，与应用程序开发人员对齐。 如果是常驻进程，可以通过如下方法获取到当前进程的环境变量： cd /proc/应用程序PID cat environ 打印出来的结果可能比较乱，耐心看一下；如果内容有误，与应用程序开发人员对齐修改方法。 **既有.2又有.1的库，导致重复加载** 这种勤快的用户比较少见，但是一旦出现，很难定位，典型的报错信息是： Driver's SQLAllocHandle on SQL_HANDLE_DBC failed 这种情况这时应用与驱动加载的是不同的物理文件，便会导致两套完全同名的函数列表，同时出现在同一个可见域里（UnixODBC的libodbc.so.*的函数导出列表完全一致），产生冲突，无法加载数据库驱动。 解决此问题的办法也比较简单，查看LD_LIBRARY_PATH中的第一个unixodbc的lib目录。在其目录下，缺少.2或.1，建立对应的.2或.1的软链接便可。 # 连接问题 ## 服务器不可达 典型报错： connect to server failed: no such file or directory 此问题可能的原因： 配置了错误的/不可达的数据库地址，或者端口 请检查数据源配置中的Servername及Port配置项，确认网络是通达的。 服务器监听不正确 如果确认Servername及Port配置正确，请根据资料中listen_addresses参数的配置方法，确保数据库监听了合适的网卡及端口，特别是Servername中指定的网卡地址及LVS的虚拟IP地址。 **修改完记得重启数据库，使监听生效。** 防火墙及网闸、流控设备 请确认防火墙设置，将数据库的通信端口添加到可信端口中。 如果有网闸、流控设备，请确认一下相关的设置。 此问题一般都是第三方商业产品导致，需要咨询服务/产品提供商相关的策略。 **SSL配置不正确** 典型报错1： The password-stored method is not supported. 解决办法1： 请将数据源配置中的的sslmode调整至allow及以上级别，允许使用SSL连接。 典型报错2： Server common name "xxxx" does not match host name "xxxxx" 此问题是由于sslmode中使用了全校验(verify-full)，它不仅会校验证书，还会校验证书所在的域名/机器名是否与证书符合，不符合时将报出此问题。 解决办法2： 重新让CA机构以新的域名/机器名签发证书；或者将SSLMODE调整至verify-ca选项或其以下级别（具体级别见产品资料中的说明）。 **使用开源驱动连接问题** 我们的数据库是支持低版本及开源驱动的（V1R7C10及以后），所以可以放心使用。 但是偶尔一些从V1R6C10升级上来的数据库，接受开源驱动连接时，会碰到用户认证算法不支持的问题，典型报错如下： authentication method 10 not supported. 此问题机理比较复杂，下面详细展开，先说解决办法： 请使用管理新账号新建一个数据库的用户，并给予其相关的访问权限，使用新用户连接数据库。 更改当前业务用户的密码，使用新密码连接数据库。 解释一下此问题发生的机理： 我们的数据库在连接时，是会让客户端将认证信息发过来的。但是发过来的信息不会是明文密码，这是不安全的；客户端发到数据库的认证信息一般是经过加盐后的密码哈希(md5/sha256算法)，迭代次数也非常多。 数据库本身也并不存储用户的明文密码，存储的是一个哈希值（所以密码要是丢了，就真的丢了，只能重置不能找回）。数据库在校验这个密码的时候，是比较哈希的，这就涉及到数据库中存储的哈希是使用的什么算法得到的哈希值，常见的是sha256（高斯自研）及MD5（开源）。 V1R7C00及以前，数据库中只存储了SHA256的哈希，升级时我们也无法推导用户原有密码，所以升级后仍然只有SHA256的哈希；但是开源客户端只识别MD5的哈希，这就导致数据库无法认证；数据库也只会让客户端以SHA256的哈希来做认证，这时开源就不识别该认证请求，导致报出如上的错误。 在创建用户和修改用户密码时，我们的新版本会同时记录两份哈希，所以后续将会同时支持开源及自研的各个版本。 **因数据源配置不正确，导致的连接错误** 典型报错： Data source name not found, and no default driver specified 可能原因： 数据源名称书写错误（或含有特殊符号） 不同的操作系统用户下，数据源可见性不一样； Linux上的数据源配置文件(odbc.ini)位置不正确 解决办法： 修正数据源名称. Windows下，请在当前用户下打开驱动管理器，查看数据源配置是否正确。 请注意在64位系统上使用正确的数据源管理器： C:\Windows\SysWOW64\odbcad32.exe：这是32位ODBC驱动管理器。 C:\Windows\System32\odbcad32.exe：这是64位ODBC驱动管理器。 Linux下使用odbcinst -j 命令，查看当前环境中配置文件的正确路径，输出一般如下： unixODBC 2.3.0 DRIVERS............: /usr/local/etc/odbcinst.ini/odbcinst.ini SYSTEM DATA SOURCES: /usr/local/etc/odbcinst.ini/odbc.ini FILE DATA SOURCES..: /usr/local/etc/odbcinst.ini/ODBCDataSources USER DATA SOURCES..: /usr/local/etc/odbc.ini SQLULEN Size.......: 8 SQLLEN Size........: 8 SQLSETPOSIROW Size.: 8 其中USER DATA SOURCES就是用户数据源，优先生效；SYSTEM DATA SOURCES是系统数据源，整个系统可用。请针对这些文件路径， 注意：有时用户数据源的配置文件可能是$(HOME)/.odbc.ini **通信协议不匹配问题** 典型报错： unsupported frontend protocol 3.51: server supports 1.0 to 3.0 可能原因： 使用了新版本的数据库驱动连接老版本的数据库(V1R6C10)； 或者使用了我们的驱动，连接到了开源的数据库上。 解决办法： 请使用老版本的数据库驱动连接该数据库。 我们的数据库中，默认低版本客户端可以连接高版本数据库；使用高版本驱动连接低版本客户端，不在规格约束范围内。 这个规格也比较好理解：因为用户一般是对数据库集中管理，升级也是有计划的。但是客户端驱动可能嵌入到业务中的每一个角落，有时甚至是已经发布的装备中，升级相对比较困难。 如果是开源服务器：我们的数据库驱动不支持开源数据库，无法连接；请使用开源客户端连接。 # 其他常见疑问 **与开源的区别？** 增加了安全性，使用了SHA256算法做认证加密；同时调整密钥哈希加密次数 提升了批量性能（V1R7C10 2019-4-30及以后版本） **是否可以增加新API？** 不可以。 还是基础知识里那张图，用户引用的API是由驱动管理器提供的，我们提供的API只可供驱动管理器使用；新增API无法穿过中间层为用户提供服务。 **是否支持COPY接口？** Copy是PG的特有语法及通信协议;而ODBC是微软提出的通用调用接口，所以无此特殊接口。 Linux上的驱动管理器有哪些？ 驱动管理器在Linux上并不是操作系统的一部分，它也是由其他开源组织开发的。所以并不是只有UnixODBC一种。但是目前使用最广泛的，其实只有UnixODBC，多数据操作系统安装时基本都已经自带了UnixODBC的某个特定版本；除此之外，还有iODBC等，现在已经慢慢退出市场了。 **UnixODBC的版本有限制么？** 有。我们支持2.3.0及以上版本。 **UnixODBC的.1与.2的库有什么区别？** 没有什么区别。 这个与UnixODBC的历史有关，历史上有一段时间提供.1，后来做了一次大升级，动态库版本也跟着升级了，变成了.2。但是一大批存量业务受制无法运行，就又添加了.1的支持。 .1与.2其实只是UnixODBC的configure配置的一部分，其函数导出，功能完全一致，不必纠结于此。 **可以打印日志么？** 可以。 一般建议打印驱动管理器的日志，此日志比较清晰，定位问题比较快。操作办法： Windows上： 打开驱动管理器，调整到跟踪页面，确定日志文件路径后，点击开始跟踪便可，如图：  Linux上： 打开odbcinst.ini文件（可使用odbcinst -j 来确定文件路径），添加以下章节： [ODBC] Trace=Yes TraceFIle=/tmp/odbc.log 重启业务便可。 注意：非必要时，请关闭日志，因为每个API都存在写盘，将会引起性能损失。 **查询结果集过大，内存吃不消怎么办？** 打开UseDclareFetch开关，它将会把查询包装成游标操作。对于不支持Cursor with hold的版本慎用。同时由于使用了服务器端的游标，游标的前后滚操作也会反馈给数据库，通信会有所增加，所以性能会有部分下降；可以通过调整Fetch参数来确定每次数据库向客户端反馈的数据量大小，来降低该性能影响。 Linux下打开UseDeclareFetch的方法： 在数据源配置项中添加： UseDeclareFetch=1 Fetch=1000 Windows下打开UseDeclareFetch的方法：  其中的Cache Size选项，就是Fetch的大小。 **有性能基线数据么？** 创建连接的性能大体为0.5s内都算正常（一般0.3s左右） 数据插入的话 非批量版本（R7C10以及前）大约为400tps（SSD的测试结果） 批量版本（R8C10及以后）大约为4000tps（SSD服务器），由于数据库对象差异、网络、物理硬件等，基本2000tps以上都可以认为是正常 **语句出错怎么排查？** 运行过程中出错，ODBC是不会打屏的。错误信息需要业务里获取错误信息（API为：SQLGetDiagField/SQLGetDiagRec）。 如果用户的业务里有打印具体的错误信息，或者业务的错误信息不足以定位，请根据3.7中的描述，将ODBC的日志打印出来，在其中找SQL_ERROR相关信息。这里最好能和业务开发人员一起定位，因为API的调用序列是乱序的，由业务决定。 如果ODBC的日志仍然不足以定位支撑，请登录到连接的目标CN所在的机器，通过以下方法进入CN日志文件目录： source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile cd $GAUSSLOG/pg_log/cn_50xx #这里的cn_50xx表示CN编号，根据实际情况修改 找到对应时间点的日志，观察其中是否有错误信息。 **我们与Oracle/MYSQL的ODBC有什么关系** ODBC是一套标准，每家数据库提供自己的驱动文件。就像大家都叫显卡，每个厂商也都提供自己的驱动，自己的驱动只能驱动自己的显卡；而显卡的接口标准是微软（ODBC也是微软）制定的，只是大家不接触，不知道有这样一套标准而已。 我们的驱动文件叫psqlodbcw.so/psqlodbcw.dll。 **支持GBK么？** 支持。 但是我们ODBC驱动默认使用utf-8编码。如果要调整，需要自行在会话开始时设置client_encoding。 但是请注意，请不要在宽字节模式下使用GBK，因为宽字节编码本身就是UNICODE的一部分（一般为UCS2），此时使用GBK可能导致数据无法显示，SQL查询结果不正确等问题。 如果出现此问题，请将VS中的解决方案字符集调整为“多字节”。

       这个项目是我来到学校后第一次参加的项目，也是第一次很深程度的参加Linux相关的项目，之前在大学里头虽然也学过相关的课程，但是都浅尝辄止，并没有深入的去学习，实践过。这次实践不仅让我学习了Linux相关的知识和经验，提高了自身的知识水平，并且也对华为的工作有了更深的认知。       项目的内容主要是从X86平台向openEuler系统上进行HPC软件的移植，移植总共有6款软件nemo、QE、Gromacs、CP2K、CESM、Lammps，都是属于HPC软件。移植过程一开始来说对我来说是我有些艰难的，因为对我来说，Linux并不是主要的使用系统，相关的移植过程也知之甚少，但随着项目的进展，在老师，师兄师姐的帮助下，我也学习了很多，扩展了自己的知识面，了解了相关的信息和如何使用它们。比如鲲鹏920芯片，鲲鹏移植工具，毕昇编译器，HyperMPI等等。我认为在这期间，不仅是技术和知识方面的提高，更重要的是一种学习能力的提高。在今后的学习中，总会有很多未知的东西，这时候就要保持一定的自学能力和主观性，这样在面对新知识的时候，才能不手忙脚乱。       OpenEuler系统是华为生态系统重要的一环，迁移的这几款HPC软件也是科研界常用的那几款软件，两者相结合是可以丰富华为的一个生态圈，华为公司现在开发了大量的硬件资源供大家使用，但同时也要有相应的软件生态环境与之适配，这样子才能算是相得益彰，因为对于一个公司，一个国家来说，有一个自己独立研发的平台是十分重要的，这样子才可以避免有一天当遭遇危机时，出现技术封锁和强制干涉时，一筹莫展的困境。       作为一个小小的开发者，我也十分有幸跟随老师，师兄师姐们参与到与华为合作的这次项目，这不仅使我自己从以前的一种较为狭窄的角度中走出来，更提高了我的能力，丰富了我的知识面，加深了对Linux系统的使用和认知。在与华为的合作中，十分愉快，无论是交接还是讨论，我们都能顺利并且有效的解决问题和开展工作，也对华为的这种开放心态十分佩服，鲲鹏众智计划的开展表明了华为的这种构建自身生态的信心和决心，一种独立自主的精神。总而言之，这次项目实践，真的让我明悟了许多，使我受益匪浅。                                                                                                                             兰州大学-高性能计算系统与应用研究团队-李沛桢                                                                                                                             指导老师：张洋老师，陈文波老师

1 介绍Personal Cancer Genome Reporter (PCGR) 是一个独立的软件包，用于为精准癌症医学对单个癌症基因组进行功能注释和翻译。目前，它可以解释体细胞 SNV/InDels 和拷贝数畸变。该软件扩展了Ensembl 的变异效应预测器 (VEP) 中的基本基因和变异注释，并通过vcfanno灵活检索了与肿瘤学相关的最新注释，并生成用于临床解释的交互式 HTML 报告。语言：R、Python一句话描述：用于为精准癌症医学对单个癌症基因组进行功能注释和翻译。建议的版本建议使用版本为“pcgr 0.9.2”。2 环境要求硬件要求硬件要求如表2-1所示。表2-1 硬件要求项目说明CPUKunpeng 920GPUNVIDIA Tesla A100 软件要求软件要求如表2-2所示。表2-2 软件要求项目版本下载地址pcgr0.9.2https://github.com/sigven/pcgr/releases/tag/v0.9.2docker20.10.11 python3.6.8https://www.python.org/ftp/python/3.6.8/Python-3.6.8.tgzExagear1.2.1.1https://mirrors.huaweicloud.com/kunpeng/archive/ExaGear/ExaGear_1.2.1.1.tar.gz 操作系统要求操作系统要求如表2-3所示。表2-3 操作系统要求项目版本下载地址CentOS8.2https://www.centos.org/download/Kernel4.18.0-193.el8.aarch64https://www.centos.org/download/3 移植规划数据本章节给出pcgr软件在移植过程中涉及到的相关软件安装规划路径的用途及详细说明。表3-1 移植规划数据序号软件安装规划路径用途说明1-基础环境搭建中的各安装包安装路径。参考《HPC解决方案 基础环境搭建指导书》中“安装规划数据”章节。2/path/to/pcgrpcgr的安装规划路径。这里的安装规划路径只是一个举例说明，建议部署在共享路径中。现网需要根据实际情况调整，后续章节凡是遇到安装路径的命令，都以现网实际规划的安装路径为准进行替换，不再单独说明。3/path/to/PYTHON3Python3的安装规划路径。4 配置编译环境前提条件使用SFTP工具将各安装包上传至服务器对应目录下。配置流程表4-1 配置流程序号配置项说明1基础环境搭建参考《HPC解决方案 基础环境搭建指导书》中“安装规划数据”章节。2修改PAGE_SIZE参考4.1修改PAGE_SIZE为4KB3安装docker参考4.2安装docker4安装python3参考4.3安装python35安装Exagear for docker参考4.4安装Exagear for docker 4.1 修改PAGE_SIZE为4KB操作步骤                                步骤 1     使用PuTTY工具，以root用户登录服务器。                                步骤 2     执行以下命令创建工作组。groupadd mockbuilduseradd mockbuild -g mockbuild                                步骤 3     执行以下命令下载包。wget https://vault.centos.org/7.6.1810/os/Source/SPackages/kernel-alt-4.14.0-115.el7a.0.1.src.rpm                                步骤 4     安装相关依赖。yum install -y xmlto asciidoc newt-devel pciutils-develyum install rpm-build redhat-rpm-config asciidoc hmaccalc perl-ExtUtils-Embed pesign xmlto –yyum install audit-libs-devel binutils-devel elfutils-devel elfutils-libelf-devel –yyum install ncurses-devel newt-devel numactl-devel pciutils-devel python-devel zlib-devel -y                                步骤 5     安装rpm包。rpm -ivh kernel-alt-4.14.0-115.el7a.0.1.src.rpm注：安装完成后rpm构建工程自动部署在/root/rpmbuild/SPECS/root/rpmbuild/SOURCES                                步骤 6     rpmbuild 构建。cd /root/rpmbuild/SPECSrpmbuild -bp --target=$(uname -m) kernel-alt.speccd /root/rpmbuild/BUILD/kernel-alt-4.14.0-115.el7a/linux-4.14.0-115.el7.0.1.aarch64（以实际路径为准）make menuconfig选择Kernel Features-->Page size (64KB)--> Page size (4KB) 保存 #Page size调整为4K。make -j 64make modules_installmake install                                步骤 7     重启机器，进入iBMC选择对应的内核进入系统。                                步骤 8     验证是否修改成功。getconf PAGE_SIZE回显信息为：4096----结束4.2 安装docker操作步骤                                步骤 1     使用PuTTY工具，以root用户登录服务器。                                步骤 2     执行以下命令下载yum-utils包。yum install -y yum-utils                                步骤 3     执行以下命令添加docker储存库。yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo注：若由于证书原因添加不成功，可在/etc/yum.conf文件中加上“sslverify=false”后再添加                                步骤 4     执行以下命令安装docker。yum install docker-ce docker-ce-cli containerd.io                                步骤 5     执行以下命令启动docker。systemctl start docker                                步骤 6     通过运行hello-world 映像验证 Docker Engine 是否已正确安装。docker run hello-world回显信息如下：----结束4.3 安装python3操作步骤                                步骤 1     使用PuTTY工具，以root用户登录服务器。                                步骤 2     执行以下命令下载python3.6.8。wget https://www.python.org/ftp/python/3.6.8/Python-3.6.8.tgz                                步骤 3     执行以下命令解压安装包。tar xvf Python-3.6.8.tgz                                步骤 4     执行以下命令进入解压后目录。cd Python-3.6.8                                步骤 5     执行以下命令编译安装Python3。./configure --prefix=/path/to/PYTHON3make -j16make install                                步骤 6     执行以下命令设置Python3的环境变量。export PATH=/path/to/PYTHON3/bin:$PATHexport LD_LIBRARY_PATH=/path/to/PYTHON3/lib:$LD_LIBRARY_PATH                                步骤 7     验证Python3环境是否生效。python3 -V----结束4.4 安装Exagear for docker操作步骤                                步骤 1     使用PuTTY工具，以root用户登录服务器。                                步骤 2     执行以下命令下载Exagear安装包。wget https://mirrors.huaweicloud.com/kunpeng/archive/ExaGear/ExaGear_1.2.1.1.tar.gz                                步骤 3     执行以下命令解压安装包。tar xvf ExaGear_1.2.1.1.tar.gz                                步骤 4     安装ExaGear for Docker on CentOS with 4KB该发布件由三个包组成：exagear-core-x64a64-container-<package_version>.aarch64.rpmexagear-core-x32a64-container-<package_version>.aarch64.rpmexagear-utils-<package_version>.noarch.rpm.使用rpm包管理工具yum install完成发布件在ARM64 主机环境下的安装：（注意需要输入对应的版本package_version）yum install exagear-core-x64a64-container-<package_version>.aarch64.rpm exagear-core-x32a64-container-<package_version>.aarch64.rpm exagear-utils-<package_version>.noarch.rpm                                步骤 5     制作X86容器的pcgr镜像。下载x86容器镜像到x86系统上，并将其拷贝到你将要用ExaGear运行容器的ARM64主机系统，在安装有docker的x86机器上进行如下操作：docker pull sigven/pcgr:0.9.2 && docker save sigven/pcgr:0.9.2 > docker-pcgr-0.9.2.tar.gz                                步骤 6     将docker-pcgr-0.9.2.tar.gz 拷贝至ARM64主机系统上.。                                步骤 7     将x86容器镜像加载到ARM64主机系统上的ARM64 docker中。docker load < docker-pcgr-0.9.2.tar.gz                                步骤 8     在ARM64主机系统上运行x86 docker容器。docker run sigven/pcgr:0.9.2----结束 5 获取源码操作步骤                                步骤 1     下载pcgr安装包“pcgr-0.9.2.tar.gz”。下载地址：https://github.com/sigven/pcgr/releases/tag/v0.9.2                                步骤 2     下载pcgr数据包“pcgr.databundle.grch37.20210627.tgz”、“pcgr.databundle.grch38.20210627.tgz”。下载地址：http://insilico.hpc.uio.no/pcgr/pcgr.databundle.grch37.20210627.tgz下载地址：http://insilico.hpc.uio.no/pcgr/pcgr.databundle.grch38.20210627.tgz                                步骤 3     使用SFTP工具将安装包和数据包上传至服务器“/path/to/pcgr”目录。----结束6 编译和安装操作步骤                                步骤 1     使用PuTTY工具，以root用户登录服务器。                                步骤 2     执行以下命令解压pcgr安装包。tar xvf pcgr-0.9.2.tar.gz                                步骤 3     执行以下命令解压pcgr数据包。tar xvf pcgr.databundle.grch37.20210627.tgztar xvf pcgr.databundle.grch38.20210627.tgz                                步骤 4     执行以下命令进入解压后pcgr主程序目录。cd pcgr-0.9.2                                步骤 5     执行以下命令将数据包目录移动到主程序目录。mv ../date .----结束7 运行和验证操作步骤                                步骤 1     使用PuTTY工具，以root用户登录服务器。                                步骤 2     执行以下命令创建报告生成目录：mkdir /path/to/output                                步骤 3     执行以下命令运行测试：python3 pcgr.py --pcgr_dir /path/to/pcgr/pcgr-0.9.2 --output_dir /path/to/pcgr/output --sample_id tumor_samplr.BRCA --genome_assembly grch37 --input_vcf /path/to/pcgr/pcgr-0.9.2/examples/tumor_sample.BRCA.vcf.gz验证结果：回显信息如下最后查看output文件夹有相关报告生成----结束8 更多资源pcgr-github官网：https://github.com/sigven/pcgr

1 介绍Personal Cancer Genome Reporter (PCGR) 是一个独立的软件包，用于为精准癌症医学对单个癌症基因组进行功能注释和翻译。目前，它可以解释体细胞 SNV/InDels 和拷贝数畸变。该软件扩展了Ensembl 的变异效应预测器 (VEP) 中的基本基因和变异注释，并通过vcfanno灵活检索了与肿瘤学相关的最新注释，并生成用于临床解释的交互式 HTML 报告。语言：R、Python一句话描述：用于为精准癌症医学对单个癌症基因组进行功能注释和翻译。建议的版本建议使用版本为“pcgr 0.9.2”。2 环境要求硬件要求硬件要求如表2-1所示。表2-1 硬件要求项目说明CPUKunpeng 920GPUNVIDIA Tesla A100 软件要求软件要求如表2-2所示。表2-2 软件要求项目版本下载地址pcgr0.9.2https://github.com/sigven/pcgr/releases/tag/v0.9.2docker20.10.11 python3.6.8https://www.python.org/ftp/python/3.6.8/Python-3.6.8.tgzExagear1.2.1.1https://mirrors.huaweicloud.com/kunpeng/archive/ExaGear/ExaGear_1.2.1.1.tar.gz 操作系统要求操作系统要求如表2-3所示。表2-3 操作系统要求项目版本下载地址CentOS8.2https://www.centos.org/download/Kernel4.18.0-193.el8.aarch64https://www.centos.org/download/3 移植规划数据本章节给出pcgr软件在移植过程中涉及到的相关软件安装规划路径的用途及详细说明。表3-1 移植规划数据序号软件安装规划路径用途说明1-基础环境搭建中的各安装包安装路径。参考《HPC解决方案 基础环境搭建指导书》中“安装规划数据”章节。2/path/to/pcgrpcgr的安装规划路径。这里的安装规划路径只是一个举例说明，建议部署在共享路径中。现网需要根据实际情况调整，后续章节凡是遇到安装路径的命令，都以现网实际规划的安装路径为准进行替换，不再单独说明。3/path/to/PYTHON3Python3的安装规划路径。4 配置编译环境前提条件使用SFTP工具将各安装包上传至服务器对应目录下。配置流程表4-1 配置流程序号配置项说明1基础环境搭建参考《HPC解决方案 基础环境搭建指导书》中“安装规划数据”章节。2修改PAGE_SIZE参考4.1修改PAGE_SIZE为4KB3安装docker参考4.2安装docker4安装python3参考4.3安装python35安装Exagear for docker参考4.4安装Exagear for docker 4.1 修改PAGE_SIZE为4KB操作步骤                                步骤 1     使用PuTTY工具，以root用户登录服务器。                                步骤 2     执行以下命令创建工作组。groupadd mockbuilduseradd mockbuild -g mockbuild                                步骤 3     执行以下命令下载包。wget https://vault.centos.org/7.6.1810/os/Source/SPackages/kernel-alt-4.14.0-115.el7a.0.1.src.rpm                                步骤 4     安装相关依赖。yum install -y xmlto asciidoc newt-devel pciutils-develyum install rpm-build redhat-rpm-config asciidoc hmaccalc perl-ExtUtils-Embed pesign xmlto –yyum install audit-libs-devel binutils-devel elfutils-devel elfutils-libelf-devel –yyum install ncurses-devel newt-devel numactl-devel pciutils-devel python-devel zlib-devel -y                                步骤 5     安装rpm包。rpm -ivh kernel-alt-4.14.0-115.el7a.0.1.src.rpm注：安装完成后rpm构建工程自动部署在/root/rpmbuild/SPECS/root/rpmbuild/SOURCES                                步骤 6     rpmbuild 构建。cd /root/rpmbuild/SPECSrpmbuild -bp --target=$(uname -m) kernel-alt.speccd /root/rpmbuild/BUILD/kernel-alt-4.14.0-115.el7a/linux-4.14.0-115.el7.0.1.aarch64（以实际路径为准）make menuconfig选择Kernel Features-->Page size (64KB)--> Page size (4KB) 保存 #Page size调整为4K。make -j 64make modules_installmake install                                步骤 7     重启机器，进入iBMC选择对应的内核进入系统。                                步骤 8     验证是否修改成功。getconf PAGE_SIZE回显信息为：4096----结束4.2 安装docker操作步骤                                步骤 1     使用PuTTY工具，以root用户登录服务器。                                步骤 2     执行以下命令下载yum-utils包。yum install -y yum-utils                                步骤 3     执行以下命令添加docker储存库。yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo注：若由于证书原因添加不成功，可在/etc/yum.conf文件中加上“sslverify=false”后再添加                                步骤 4     执行以下命令安装docker。yum install docker-ce docker-ce-cli containerd.io                                步骤 5     执行以下命令启动docker。systemctl start docker                                步骤 6     通过运行hello-world 映像验证 Docker Engine 是否已正确安装。docker run hello-world回显信息如下：----结束4.3 安装python3操作步骤                                步骤 1     使用PuTTY工具，以root用户登录服务器。                                步骤 2     执行以下命令下载python3.6.8。wget https://www.python.org/ftp/python/3.6.8/Python-3.6.8.tgz                                步骤 3     执行以下命令解压安装包。tar xvf Python-3.6.8.tgz                                步骤 4     执行以下命令进入解压后目录。cd Python-3.6.8                                步骤 5     执行以下命令编译安装Python3。./configure --prefix=/path/to/PYTHON3make -j16make install                                步骤 6     执行以下命令设置Python3的环境变量。export PATH=/path/to/PYTHON3/bin:$PATHexport LD_LIBRARY_PATH=/path/to/PYTHON3/lib:$LD_LIBRARY_PATH                                步骤 7     验证Python3环境是否生效。python3 -V----结束4.4 安装Exagear for docker操作步骤                                步骤 1     使用PuTTY工具，以root用户登录服务器。                                步骤 2     执行以下命令下载Exagear安装包。wget https://mirrors.huaweicloud.com/kunpeng/archive/ExaGear/ExaGear_1.2.1.1.tar.gz                                步骤 3     执行以下命令解压安装包。tar xvf ExaGear_1.2.1.1.tar.gz                                步骤 4     安装ExaGear for Docker on CentOS with 4KB该发布件由三个包组成：exagear-core-x64a64-container-<package_version>.aarch64.rpmexagear-core-x32a64-container-<package_version>.aarch64.rpmexagear-utils-<package_version>.noarch.rpm.使用rpm包管理工具yum install完成发布件在ARM64 主机环境下的安装：（注意需要输入对应的版本package_version）yum install exagear-core-x64a64-container-<package_version>.aarch64.rpm exagear-core-x32a64-container-<package_version>.aarch64.rpm exagear-utils-<package_version>.noarch.rpm                                步骤 5     制作X86容器的pcgr镜像。下载x86容器镜像到x86系统上，并将其拷贝到你将要用ExaGear运行容器的ARM64主机系统，在安装有docker的x86机器上进行如下操作：docker pull sigven/pcgr:0.9.2 && docker save sigven/pcgr:0.9.2 > docker-pcgr-0.9.2.tar.gz                                步骤 6     将docker-pcgr-0.9.2.tar.gz 拷贝至ARM64主机系统上.。                                步骤 7     将x86容器镜像加载到ARM64主机系统上的ARM64 docker中。docker load < docker-pcgr-0.9.2.tar.gz                                步骤 8     在ARM64主机系统上运行x86 docker容器。docker run sigven/pcgr:0.9.2----结束 5 获取源码操作步骤                                步骤 1     下载pcgr安装包“pcgr-0.9.2.tar.gz”。下载地址：https://github.com/sigven/pcgr/releases/tag/v0.9.2                                步骤 2     下载pcgr数据包“pcgr.databundle.grch37.20210627.tgz”、“pcgr.databundle.grch38.20210627.tgz”。下载地址：http://insilico.hpc.uio.no/pcgr/pcgr.databundle.grch37.20210627.tgz下载地址：http://insilico.hpc.uio.no/pcgr/pcgr.databundle.grch38.20210627.tgz                                步骤 3     使用SFTP工具将安装包和数据包上传至服务器“/path/to/pcgr”目录。----结束6 编译和安装操作步骤                                步骤 1     使用PuTTY工具，以root用户登录服务器。                                步骤 2     执行以下命令解压pcgr安装包。tar xvf pcgr-0.9.2.tar.gz                                步骤 3     执行以下命令解压pcgr数据包。tar xvf pcgr.databundle.grch37.20210627.tgztar xvf pcgr.databundle.grch38.20210627.tgz                                步骤 4     执行以下命令进入解压后pcgr主程序目录。cd pcgr-0.9.2                                步骤 5     执行以下命令将数据包目录移动到主程序目录。mv ../date .----结束7 运行和验证操作步骤                                步骤 1     使用PuTTY工具，以root用户登录服务器。                                步骤 2     执行以下命令创建报告生成目录：mkdir /path/to/output                                步骤 3     执行以下命令运行测试：python3 pcgr.py --pcgr_dir /path/to/pcgr/pcgr-0.9.2 --output_dir /path/to/pcgr/output --sample_id tumor_samplr.BRCA --genome_assembly grch37 --input_vcf /path/to/pcgr/pcgr-0.9.2/examples/tumor_sample.BRCA.vcf.gz验证结果：回显信息如下最后查看output文件夹有相关报告生成----结束8 更多资源pcgr-github官网：https://github.com/sigven/pcgr

大家好，这一期我向大家介绍下，网络方面的故障吧，一起来学习下。网络大部分的故障都是借助TC工具实现的，因此请先确保OS上已安装TC工具，Atlas 产品可能存在TC工具无netem模块(注入时提示：“Error: Specified qdisc not found”，因为 Atlas的Euler OS经过裁剪，无sch_netem.ko的内核模块)，请从CMC下载相应发行版本OS的 编译环境包，并在包中找到对应的sch_netem.ko模块，并手动加载该模块，即可使用TC的 netem模块功能，进行网络包相关的故障注入。网络错包网络错包指定时长网络包延时网络包延时指定时长网络丢包网络丢包指定时长网络包重复网络包重复指定时长网络包乱序网络包乱序指定时长网卡 Down 掉网卡性能劣化端口占用停止网络服务网络链路闪断网卡带宽受限TCP 端口占用网络驱动故障这一期Linux OS 关于网络故障的内容我们就先介绍到这，下一期我们介绍下进程方面的故障，敬请期待~

 时间倒回二十年前。1993 年，那时候 BSD 正处于水深火热，Linux 刚诞生没多久，Meta 杂志 问 Linus Torvalds：能不能推测一下 Linux 在市场上对 Unix 的影响？当时，Linus 的回答是：I have gotten various mails and seen some newsgroup messages about persons who have switched over already or would like to switch over once Linux is able to run commercial binaries, but at least so far, I doubt Linux has dented the real Unix market very much.尽管我已经看到一些人已经或者想要切换到 Linux，用于运行商业二进制文件。但目前为止，我不认为 Linux 已经严重削弱了 Unix 的市场。彼时，Linux 初出茅庐，尽管锋芒毕露，但谁也不知道以后到底会发生什么。须臾二十年，形势调转，Linux 现在的地位有目共睹。另一边，BSD “灾后重建”且大受欢迎的 386BSD 因为内部意见不同出现问题，其中三个补丁包协调员 Nate Williams、Rod Grimes 和 Jordan Hubbard 另起炉灶，于 1993 年创建了 FreeBSD。尽管还有 NetBSD 和 OpenBSD，但后来的事实证明，FreeBSD 发展最好、走得最远，是 BSD 世界里的“扛把子”。在之后的日子里，FreeBSD 没能重现 BSD 的往日荣光，反而一直生活在 Linux 的阴影之下。“Linuxism” 成为 FreeBSD 内部常常挂在嘴边的一个词，其中透露出酸酸的比较之味。一方面，FreeBSD 坚定地沿袭 Unix 的一些传统，坚决地想要与 GNU/Linux 保持距离；另一方面，FreeBSD 也在积极地寻求更长足的发展，想要至少在某些方面保持优势。 世事如棋局，得势者得天下。以势定夺，怎么看 FreeBSD 领到的剧本都是一个“大败局”。 01 成也 BSDL，败也 BSDL 正是我们的许可证，使得我们独一无二。与 GPL 尤其是 GPLv3 相比，BSDL（BSD 许可证）对很多厂商来说是非常重要的。2021 年 3 月，FreeBSD 13.0 版本最新发布。在一场采访中，FreeBSD 内核开发者 John Baldwin 如是说。他说得没错。许可证是 BSD 一族与 GNU/Linux 最显著的不同，它彰显了 FreeBSD 所继承的、与 RMS 提倡的 “Free” 完全不同的 “Libre” 哲学态度，使得以 FreeBSD 为代表的这些开源软件自成一派。在 GNU 理念里，软件本该自由，专有软件不应该存在。因此，GPL 被设计得具有传染性，并且要求所有修改后的代码都要返回上游，当初 Linus 选择 GPL 正是看重后面这一点。而 BSDL 则更接近于“公共领域”（公共领域的作品属于公有文化遗产，任何人可以不受限制地使用和加工它们），几乎给了使用者最大权限的自由，不但可以自由地使用、修改源代码，不需要返回任何修改，还可以将修改后的代码作为开源或者专有软件再发布。我们并不认可 GPL，它是一种政治宣言。我们想要将我们的许可证与政治分开。 GPL 会吓跑很多潜在用户，这只会适得其反。—— FreeBSD 创建者之一 Jordan Hubbard因此，在之后的实践中 FreeBSD 也在竭力与 GPL 划清界限。多年来，FreeBSD 一直致力于删除基础设施中的 GPL 软件，以便“迁移到现代的、CopyFree 以及许可更宽松的组件”。比如：用 LLVM 的 LLDB 替代 GDB 调试器、使用 BSDgrep 替代 GNUgrep，以及删除 libgnuregex 等等。（其中，FreeBSD 为了完成向 LLVM 的迁移，花费了十年左右的时间，因为 LLVM 是在 Apache 2.0 下获得许可，限制比 GPL 更少。） FreeBSD 的这种身份主张无可厚非，但从现实层面来考量这两个许可证，就是另一码事了。阮一峰老师在《为什么 GPL 是更好的开源许可证？》一文中作了逻辑阐述：当程序员放弃代码的版权，或者选择 BSD 许可证，他可能认为自己做出了世界上最无私的行为。很大程度上，事实确实如此。但是，我们要知道，这个世界是一个商业利益占主导的世界。一旦发生像甲骨文拥有 MySQL 这一类的事情，你的代码的价值将大大削弱，大公司先是免费利用它们，然后再设法推出取代它们的私有产品。你以为自己奉献了爱心，但是实质上变成了为大公司无偿打工。从这个角度看，GPL是更好的开源许可证。它保证了自由始终是自由，既无法被剥夺，也不是一种圈套或陷阱。 FreeBSD 的贡献者就常常被调侃为 Apple 公司的无薪员工。Apple 将社区工作都纳入了 FreeBSD，在其基础上进行了一些更改，就变成了一个专有的、非自由的操作系统。糟糕的是，Apple 还对内核和其他部分进行了分叉，并将其命名为 Darwin，这一系统基本就远离了 FreeBSD 的传统。而且，由于 Apple 支付了版税，他们可以合法地将其称为 Unix，但这笔钱也没有流向 FreeBSD。更过分的是，相较于 Netflix 等，同样是 FreeBSD 受益者，Apple 为上游做贡献的积极性也不足（因为 BSDL，贡献上游这事就全凭自觉了）。但 FreeBSD 的人对此倒也看得开：“我不会因此而责怪他们。FreeBSD 是一个 BSD 许可的项目，而不是 GPL。”John Baldwin 表示。BSD 许可证就是一个复制中心，可以为所欲为，但我们不在乎。—— Marshall Kirk McKusick ，他亲身参与了 4.3BSD 和 4.4BSD 的开发和发行，后来又深度参与了 FreeBSD因为 GPL，这种事永远不会发生在 Linux 身上。在 GPL 许可下，任何人都可以使用 Linux，但是有一个强制要求，如果修改后的版本要出售或者提供给他人，则必须根据相同的 GPL 许可把完整源代码对外发布。如此一来，GPL 可以确保 Linux 永远不会成为专有产品，所有开发者做出的贡献最终会回到社区，Linux 可以得到更好的发展。在 Linus 眼里，GPL 就是他想要的，而不是 BSDL。许可证是 Linux 成功的决定性因素之一，因为它强制你必须回馈。如果你真的想创造更大的东西，如果你想围绕它创建一个社区，BSD 许可证不一定是很好的许可证。它（BSDL）会让开发人员觉得大公司在利用他们的工作。 02 “好东西都给 Linux 了”Linux 赶上了好时候。Internet 开始风行之际，Linux 的开发者及爱好者正好能透过 Internet 实时地发布新闻、想法、提问、讨论、递送程序代码及进行错误回报。这种由 Internet 连接起来的分布式合作方式带给了 Linux 惊人的活力。这种生命力直接将 Linux 送上了可以与 BSD 分庭抗礼的位置。与此同时，在 Linux 现身之时，刚好是人们开始买得起个人计算机时。那是还没从诉讼中缓过劲的 BSD 对于当时的个人计算机所使用的 80386 硬件的支持度非常不好，Linux 几乎成为当时大众的第一选择。这一波路人缘，Linux 收割得很漂亮。BSD 缺位，Linux 趁机发展，刚从灰烬里重生的 FreeBSD 碰上的局面就很残酷：Linux 占据主导地位之后，已经形成马太效应，之后的态势呈现出强者愈强、弱者愈弱的趋势。 硬件方面，Linux 可以在许多不同的平台上运行，而 FreeBSD 则不行。硬件设备制造商更愿意为 Windows、Linux 等主流的操作系统提供驱动程序，IBM、戴尔和惠普直接支持在其服务器上运行 Linux，但处于主流之外的 FreeBSD 可能不在它们的考虑范围内。此外，Linux 的开发者数量比 FreeBSD 多出数倍，这意味着 Linux 拥有更多的贡献者和测试新硬件的机会。长期下来，最终导致 FreeBSD 的兼容性和硬件支持远远不如 Linux。比如，用户需要定期更新图形驱动程序，Linux 可以更早、更快地提供支持。软件上，Linux 软件包存储库的数量远超过 FreeBSD ，具有更大的灵活性和可用性，虽然 FreeBSD 也提供了预编译的软件包，但它仍然无法与 Linux 可用的资源进行比较。其实，这都是互为因果关系的 —— 因为 FreeBSD 市占率比 Linux 低多了，开发者少，很多软件对其的支持度就不如 Linux，这又反过来加剧了其市占率的下降 —— 一个死循环。有人评论很是贴切：“所有的好东西都给了 Linux”。看着 FreeBSD 如今的现状，用户都着急了。2020 年 3 月，一些用户开始在推特上催促 FreeBSD 基金会尽快赞助 FreeBSD，以推进对 802.11ac 支持的开发工作。要知道这个时候， Windows 和 Linux 都提供了对 802.11ac（"WiFi 5"）的良好支持，并且已经开始将重心放在 802.11ax （"WiFi 6"）上了。当时面对呼吁， FreeBSD 基金会进行回复的截图 03 FreeBSD 没有商业布局Linux 内核是个操作系统“半成品”，企业支持的重要性不言而喻。支持 Linux 的著名企业有 RedHat 、SUSE、IBM 、Canonical 等等，它们不仅贡献了许多实用性很强的发行版，如 Fedora、Ubuntu、Arch Linux、Debian、Linux Mint 等，同时确保操作系统实现快速更新。有人认为， RedHat 是 Linux 快速进入商用市场的关键性因素之一。因为对于大型企业而言，或许授权费用的多寡并不是重点，他们要的是能够说服上司及股东的解决方案。透过 RedHat 所提供的技术支持，信息部门有了底气将 Linux 列入解决方案之中。这项优势几乎是 FreeBSD 所难以匹敌的，因为 FreeBSD 几乎没有商业支持。开箱即用的 FreeBSD 提供了用于强化系统的选项因为缺乏商业公司运作的商业版本，为 FreeBSD 提供支持的企业屈指可数，没有大量企业为终端用户提供大规模的技术和服务支持。在 FreeBSD 13 发行之后的那场采访中，当被问及商业模式问题时，John Baldwin 这样回答：有很多来自像 Netflix 这样的公司，内部会有FreeBSD 专家团队开发功能，这些工作直接进入上游 FreeBSD。还有一些资源来自学术和业余爱好者。最近越来越多的工作由 FreeBSD 基金会承担，基金会接受捐赠资助。可以看出，一些接受了 FreeBSD 恩惠的企业的确在以某种方式去推动 FreeBSD 的生态发展，但与 Linux 所得到的商业支持，完全不能相提并论。就像有人说得那样：“尽管 Netflix、Apple 和 Juniper Networks 等公司都在支持 FreeBSD，但它们并没有像 Canonical 和 RedHat 等公司那样投资它，共荣共生的传奇只发生在了 Linux 上 。” 04 “大独裁者”未必是坏事One of the major problems with 386BSD seems to be the lack of co-ordination: that may sound weird coming from the Linux background, but in fact the 386BSD project seems to suffer from a lot of people working on the same thing due to the long release cycle.The NetBSD project may be a step in the right direction, but I think 386BSD has been hurt by the way it has been developed.386BSD 的主要问题之一似乎是缺乏协调管理：尽管我以 Linux 的角度和身份来看很奇怪，但事实就是这样，因为较长的发布周期，386BSD 里大量的人都在做同一件事情。NetBSD 可能走对了方向，但是 386BSD 已经因为这种开发方式受到了伤害。1993 年，Linus 一语成谶。很快，386BSD 分裂成为 FreeBSD 和 NetBSD。当时有人总结到：“BSD 走的是教堂式的学院派路线，而 Linux 则是代表了市集式的骇客精神。” Linus 是著名的独裁，而 BSD 对“独裁者模式”的嗤之以鼻是一以贯之的。有一个古老的笑话是这样的：如果你把 10 个 BSD 开发人员锁在一个房间里，当你打开门时，你会发现比萨饼不见了，BSD 开发人员死了，还有 11 个 BSD 的新变种。虽然有点自负，但我认为只要我愿意充当傀儡，我本可以阻止社区分裂。当时我在那个位置上已经 10 多年了，我觉得是时候将衣钵传给他人了。老实说，我没想到会这样（指分裂），我以为会出现很多不同发行版而已。McKusick 曾这样表示。在他看来，Linux 的独裁者模式一样不可取，一旦 Linus Torvalds 离开，就会酿成灾难，Linus 在试图创造超越他自身的一些东西，而“如果我被公共汽车撞了， BSD 不会真正受到太大影响。”这样左派又带点傲气的观点，真是典型的 BSD 的啊。而 FreeBSD 之后出现的管理和开发方式问题，多多少少也带了一些遗传在身上。 从开发过程上看，FreeBSD 与 Linux 最大的不同就是 —— 没有一个大独裁者。FreeBSD 有一个核心团队，相当于公司里的董事会，他们通过授予、撤销修改、提交新代码到代码库等权利来控制访问，其首要任务是确保整个项目处于良好状态并朝着正确的方向前进，并每 2 年选举一次。“我们主要用邮件列表进行协作，这与 Linux 内核邮件列表相同。但是，FreeBSD 基础系统是一个单一的存储库，内核、C 库以及工具链，所有基础系统实用程序，如 ls 和 shell，都在一个单一的存储库中，一起构建和发布。” FreeBSD 基金会项目开发总监 Ed Maste 在 2021 年表示。这种“核心小组”型的模式最大的缺点就是很难达成共识，从而延误时机。FreeBSD 核心团队成员 Benno Rice 就曾探讨过这个问题：开发项目的源代码是其核心资产，必须妥善保管。所以项目需要一个源代码管理系统。最初，FreeBSD 使用 CVS，这在当时是一个合理的选择，但直到 2008 年 FreeBSD 还在使用 CVS。为什么呢？因为大家对于应该用什么来代替它没有达成共识。考虑过BitKeeper、Git 和 Mercurial，最后都无疾而终了。很多社区都会反复出现长期的争论，FreeBSD 也不例外。2008 年，经过八年的争论，Peter Wemm 强行推进了向 Subversion 的转换；从那以后，抱怨声相对较少了。相比之下，Python 从 CVS 开始，2004 年转移到 Subversion，2009 年转移到 Mercurial，现在又转移到 GitHub。在 Python 社区中，一旦 PEP 获得批准，就可以继续进行了，而 FreeBSD 没有这样的机制。而 Python 社区，又是另一个以独裁者领导而著称的项目。其实，“核心小组”模式并非只有 FreeBSD 一家，GNU 项目 、Apache Web 等也都采用这种模式。但很明显，FreeBSD 的这个核心团队，并没有做好这份工作。比如著名的“ Matthew Dillon 事件”（下文会详细说），他们不但没有及时引进相应的行为准则来规范大家的行为，更是对开发者互相掐架、成员参与“Gamergate”在线骚扰活动等恶劣行为无能为力。又比如，因为缺少保证质量代码的审查流程，他们还差点让 4 万行有缺陷的代码混入 FreeBSD 内核里。 05 “FreeBSD 不会再年轻了”LWN 是这么评价 FreeBSD 的：这是一个伟大的项目，但它确实存在一些问题，特别是三点：FreeBSD 很大，它很旧，而且它行动迟缓。FreeBSD 不会变得更年轻了，它难以改变一些根深蒂固的态度。的确，从 1993 年 11 月开始，FreeBSD 出生就自带故事，而且它基于的代码非常古老。Benno Rice 说，直到 2017 年 FreeBSD 开发人员才发现自动化测试，而要进行自动化测试，软件必须具有正确的结构，但 FreeBSD 这个“老家伙”并不具备。因此，当他在一场活动中看到 Rust 社区有关自动化的演讲时，他就在想：为什么 FreeBSD 不能有这么好的东西？不光是古老，FreeBSD 还失去了活力。FreeBSD 联合创始人 Jordan Hubbard 曾经是社区最为活跃的核心人物之一，2001 年他离开了 FreeBSD 社区，去了 Apple 公司，帮 Apple 捣鼓 Darwin。在他的辞职信中，他这么说：Another reason, and I hate to say this but it probably needs saying, is that being in core is honestly not what it once was. For a old-timer like myself, who was used to a core team that was far more cohesive and generally on the same page, it's simply a painful experience a lot of the time.Perhaps this is due to overly rose-colored recollections of the old core on my part, and I do certainly recall us having more than our share of disagreement and inefficiency in the past, but on the balance core still feels too much like the pre-WWII Polish Parliment sometimes, where we're fully capable of arguing some issue right up to the point where tanks are rolling through the front door and rendering the whole debate somewhat moot.还有一些原因，我本不想但不得不说，老实说核心团队已经不像从前了。作为一个老前辈，我习惯了那样的核心团队：更加团结且大家都是一条心，一起经历了许多艰难的日子。或许是我对旧时光的滤镜太重了，在回忆里我们过去的确有更多的分歧和低效，我们的核心团队实在太“反应迟钝”了（这里用了一个典故，二战时德国都已进入波兰，而波兰国会还在商讨对策）。我们完全有能力解决问题，但就是这样：坦克都已经在门前了，一切辩论都毫无意义了。 Jordan Hubbard 在这副古老的身躯上，当我们掀开 FreeBSD 那袭表面华丽的裘衣，又会赫然发现上面还爬有一些不那么体面的虱子和臭虫。在圈子里，总是会有一些有关 FreeBSD 的“小差评”：FreeBSD 是一个很棒的操作系统，但 FreeBSD 论坛是我见过的最刻薄的论坛之一。有人在里面寻求帮助却被贬低，并让其滚回到 Linux 社区。FreeBSD 论坛成员都是 FreeBSD 的狂热分子，当话题涉及到在 FreeBSD 作用不大的组件时，就会被攻击为“Linuxism”。BSD 论坛一点也不友好。不要在那里问，他们只会让你去阅读手册。你只能靠自己。在 FreeBSD 论坛寻求帮助，得到的回复往往都是：一定是你做错了，因为 FreeBSD 永远不会错。当然，人无完人，每个社区都会有这样那样的差评，这些差评或许并不能说明些什么，但是当一些群体性事件爆发出来，FreeBSD 在文化和风气上的短板就暴露无疑了。其中最著名的就是前文曾提及的“Matthew Dillon 事件”。Matthew Dillon 是 1994 年就加入 FreeBSD 的明星成员。之所以说他是明星，是因为这哥们确实实力过硬，但不合适团队合作，不怎么在乎别人的辛苦成果，是个“Rock-star”式的人物。当初还在更新 FreeBSD 5 （现在都已经 13 了）的时候，Dillon 想打破 FreeBSD 里一个很大的内核锁，John Baldwin 也想过，于是俩人就一起干了。不出意料，两人在关键部分出现了分歧，Dillon 一意孤行地提交了更改。这引发了非常激烈的争论，在长达一个月的争吵之后，Dillon 退步了，核心团队取消了他的提交权限，他最终也离开了 FreeBSD。这不是 FreeBSD 里的孤例，还有很多类似的事件发生过。而这件事直接引起了 FreeBSD 核心团队的反思：如果 FreeBSD 当时有既定的行为准则，会不会得到更好地处理呢？Dillon 走后，Gamergate 事件直接促成了 FreeBSD 的行动。简单来说，Gamergate 是一个与性别政治有关的运动，最开始是一个已经离开的 FreeBSD 成员写了一个 Perl 脚本来阻止 Gamergate 参与者的活动，并惹怒了那批人，使得 FreeBSD 惹火上身；再后来又有 FreeBSD 成员加入 Gamergate 并开始在 Twitter 上攻击那个前成员，这下完全把 FreeBSD 拖下了水。这一事件不仅引起了激烈的讨论，攻击者随后还将对话日志泄露给了 Breitbart，核心团队别无选择，只能参与进来。2018 年， FreeBSD 确立了社区行为准则（Code of Conduct，CoC），这一准则从 LLVM 衍生而来，要求社区开发者友好耐心、热情好客、体贴、相互尊敬、对他人友善、注意不要乱说话、持不同见解时多换位思考。这是一项“修补的紧急工作”，我们最初仍然诚实地认为“精英”意味着“包容”。从那以后，我们学到了很多其他东西。—— Benno Rice06 结语2022 年 1 月，FreeBSD  基金会制定了一份时间跨度近 5 年的技术路线图，决定从面向终端用户的改进（特指笔记本和台式机）、商用服务器、工具和应用和虚拟化和容器 4 个方面为重点，以扩大和增强技术团队的实力。这份蓝图代表 FreeBSD 仍在努力朝更好的方向进发，正如 Jordan Hubbard 所说的那样，现在的 FreeBSD 应该是年轻人的天下，这样才会更具活力。早在 1990 年代我就用过 FreeBSD，当时我没什么钱，住在政府为低收入者提供的房子里，是 FreeBSD 帮助我摆脱了贫困 —— 在雅虎找到工作是因为我会用 FreeBSD，而 WhatsApp 也是用 FreeBSD 服务器为数以亿计的用户提供服务。    —— WhatsApp 联合创始人兼 CEO Jan Koum不管 FreeBSD 这盘棋下得多么艰难、多么不得势，但它给世界带来的一切是如此精彩。

这一期我们一起来看，关于存储方面的故障内容吧。SCSI 访问冲突存储链路丢包存储链路演示存储链路错包磁盘丢失Linux OS 关于存储的内容就讲到这里，下一期我们一起来看下Linux OS 关于网络的内容，敬请期待~

我们继续接上一期Linux OS相关的故障，这一期我们一起来看下Linux OS 与内存相关的故障。内存泄漏内存泄露指定量内存泄露指定次数和大小系统内存曲线泄漏Slab Cache 重复释放系统内存不足好啦，本期我们就介绍到这了，这一期我们一起学习了Linux OS关于内存方面的故障，那存储方面的故障又有哪些呢，下一期我们一起来学习下，敬请期待~

网络安全一直是IT行业最为关注的话题，Java之父James Gosling曾在采访中表示“目前，我们依然有各种各样的安全问题，网络攻击不断，如果有一种方式，可以终结网络安全隐患，那将是非常好的。”在众多的操作系统中，Linux算是比较安全的，前提是你在服务器或云端上正确的安装了Linux，并且给它提供了一定的防护。尽管这样，也无法百分百保证它不面临安全威胁。VMware威胁分析部门（TAU）在其最新威胁报告中，就Linux多云环境下的恶意软件进行了详细探讨。图片来源VMware我们都知道，Linux是世界范围内的顶级云操作系统，它为人们常用网站中超过78%的网站提供支持。黑客们都是聪明人，他们也知道针对云计算的批发要比针对Windows PC零售能赚取更多的钱。因此，黑客们把更多的精力放在了脆弱的基于Linux的多云环境上。 图片来源W^3Techs破解基于Linux的多云环境虽然破解基于Linux的多云环境很困难，但成功破解后的可观收益驱使着黑客们投入更多的精力。通常，利用破解工具来攻击基于Linux的多云环境基本是不可能完成的。但他们可以针对基于容器的基础设施中那些脆弱的认证、漏洞以及错误配置，利用远程访问工具（RATs）渗透到云环境中。一旦他们在你的云中有了一个立足点，就会尝试运行勒索软件或是部署加密组件，而这一切的目的都是为了钱。日渐复杂的勒索软件工具VMware表示，由于自己之前一直没有专注于检测这些威胁，导致Linux的恶意软件检测和预防工具长时间没有过更新。这意味着，现有的工具已经不能胜任检测与预防威胁这项工作了。而检测与预防工具的落后，却要面对更加复杂的基于Linux系统而制作的勒索软件，这些勒索软件现在的安全威胁等级更高，而且更难查找。例如，现在针对Linux的勒索软件有些已经发展到针对主机图像的地步，而想要找到这些恶意软件需要开启动态分析和主机监控。这意味着如果你的计算机中真的存在这种勒索软件，你很难清楚的知道它带来的影响。现在有不少于9个勒索软件家族在针对Linux。其中包括REvil的Linux版本；DarkSide；BlackMatter以及Defray777等。其中有几个是提供给那些没什么技术但是想赚点快钱的人的。这些人也可以通过这些勒索软件来找受害者要赎金。逍遥法外的加密劫持者加密劫持者是未经授权使用他人计算机来挖矿加密货币的人的称呼。一般加密劫持者选择的加密货币是Monero加密货币（XMR）。89%的Linux加密劫持者使用的都是XMRig的相关库。这些劫持者主要使用两种方法来达到目的。其一是利用具有窃取钱包功能的恶意软件，有时也会将恶意软件冒充为基于加密货币的应用程序。其二就是利用偷来的CPU周期挖掘加密货币。无论是那种方式，挖掘加密货币的代码都是在后台运行的，因此毫无戒心的受害者是不会发现有人在使用自的计算机挖加密货币的，他们只是会好奇自己的计算机为什么运行性能降低了，程序执行也比以前滞后。目前有7个恶意软件家族在这方面针对Linux，包括XMRig、Sysrv和Mexalz等。除了针对Linux多云环境的攻击，还有许多专门针对常见的云计算配置的攻击。例如，TeamTNT的恶意软件制作者针对开放的Kubernetes pods和Docker来部署XMRig加密软件。为了逃避对恶意软件的检测，它劫持了数据库加载机制，以此隐藏在/proc文件系统的特定目录中，从而隐藏加密器的进程。为了使自己的恶意软件能够进入到受害者的系统中，这些勒索软件的开发者中，越来越多的人使用RATs。VMware的研究团队发现，自2020年2月底以来，互联网上有超过14000个活跃的Cobalt Strike团队服务器。这个Red Team的软件是为了帮助你保护你的系统，但现在有约56%的Cobalt Strike服务器被破解了或是早就已经泄露了的Cobalt Strike实例。可以说其中大部分已经被这帮黑客利用了。网络安全近几年真的是令人头疼的问题，为了避免重蹈Apache Log4j这类开源安全问题，谷歌提出了三项安全倡议。现在VMware也发布了这篇文章来提醒你，保护好你的Linux。面对这些安全威胁，我们能做的就是给自己的计算机周全的防护。参考链接：VMware Finds Linux Malware on the Rise – The New Stack————————————————版权声明：本文为CSDN博主「、左耳」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。原文链接：https://blog.csdn.net/qq_43529978/article/details/122964991