追寻梦想的青春

作为管理的角度来说，通常建议直接是在/etc/sudoers.d/目录下新增配置文件，然后开启/etc/sudoers配置文件中的加载/etc/sudoers.d的配置。从权限的角度来说，确实是这样，但是，由于root用户是超级用户，拥有对所有文件的完全访问权限，换句话说，即便文件权限是000，root用户依然可以查看和修改。为了安全，/etc/sudoers配置文件的权限是440，也就是说，只允许root用户和root用户组的用户查看，难道说，该文件不允许修改？命令修改/etc/sudoers文件。

systemd-journald的作用是收集系统启动阶段的日志以及服务在启动和运行中的日志，因此，如果服务是用systemd管理的，打印到标准输出的信息就会作为日志被systemd-journal获取到。前面systemd-journald的配置可以看出，日志在保存时可以保存在内存，也可以保存在磁盘，保存在内存中的日志，当机器重启就没了，但是性能会比较好，保存在磁盘中的日志，重启还在，但是性能会差一些。为了提高日志存储的效率，日志保存的格式肯定会采用二进制的方式，因此，无法直接打开日志文件查看，需要使用。

之后就可以拉取镜像了，由于一些原因，无法从DockerHub拉取镜像，此时通常有两种办法，一种是找国内对应的镜像仓库，另一种方式是找代理。，之后就可以基于上述镜像去编译自己的程序。与x86的主要区别是基础镜像要用。

当然也跟服务的FQDN格式有关，可以看到如果用全的FQDN格式，其中就有4个点号，而且，根据服务名的规范，服务名中是不能包含点号的，因此，服务的FQDN中只有4个点号。这里提到一个重要的配置项：ndots，该配置项会作为是否需要优先与search配置的域名后缀拼接还是直接查询域名的判断依据，也就是说，如果域名中的点号超过ndots，说明域名足够长，大概率是全域名，直接查询该域名，如果域名中的点号小于ndots，说明该域名比较短，大概率需要与域名后缀拼接。，会直接报错查询不到；

前文已经说过，Fanotify相比Inotify，比较大的优势是获取的数据多以及Fanotify的阻断能力。阻断能力，顾名思义，就是在用户操作文件时，如果判断出文件是有问题的，可以不让用户操作。

fanotify是另一种文件监控机制，在使用上两者类似，都是先调用init函数初始化句柄，然后调用类似watch的函数添加监控路径，再使用select+read的方式读取出变化的事件，根据事件中给出的参数获取文件的路径、事件类型以及其他需要的数据。如果是监控主机上的路径，directed结合FAN_EVENT_ON_CHILD标志就只能监控目录以及目录下的文件，per-mount可以监控pathname所在的挂载点中所有文件或者目录的变化，而global模式可以监控整个文件系统。

AddressSanitizer是进行内存异常使用分析的工具，该工具已经集成到编译器中，因此，只能用于分析C/C++语言的内存问题分析。与Valgrind相比，运行速度更快，但是，从场景来说，AddressSanitizer主要用于检测内存的非法使用，当然也包括内存未正确释放的问题，而Valgrind则可以分析出导致内存增长的调用栈。如果出现内存偏高的问题，可以使用Valgrind工具分析如果出现内存导致的core问题，可以使用gdb的watchpoint或者AddressSanitizer分析。

Valgrind是Linux上的一套开源的动态分析工具集，通常用来检测和分析程序中的错误，提高程序的稳定性和性能。Valgrind整体架构上包含内核和周边工具集，将程序放到内核模拟的仿真环境中运行，并提供一些能力接口，然后基于这些接口实现周边工具。当程序运行过程中，内存持续增长，一段时间后就可能造成OOM，此时可以使用Valgrind的Massif工具分析程序执行过程中的堆分配内存量。

不管什么语言开发的程序，都会遇到两类比较棘手的问题：崩溃和性能问题，其中性能问题又可以分为CPU占用高和内存占用高。C/C++需要获取core文件，根据堆栈分析出现问题的代码行，开发环境可以配置core路径，正式环境可以使用Breadpadgolang中可以将GOTRACEBACK设置为crash让程序崩溃时生成core文件(但是，发现用gdb打开时没有程序的符号名，并且core文件很大)，也可以在程序退出时利用中的Stack()获取堆栈。

当内核在执行audit_set_pid时，内核会占用audit_cmd_mutex，然后判断是否已经有其他进程占用audit，如果有就会尝试发送消息，从而判断用户态进程在正常接收审计日志，那么该调用就会返回File exists的报错。因此，在存在该问题的系统上，不能先执行audit_set_pid，然后通过结果判断，而是应该先干掉占用的进程，只在audit_pid为0时才调用audit_set_pid。当用户态程序消费审计日志过慢，造成缓存队列满时，会触发内核的睡眠机制，造成系统卡顿。

通过auparse就可以快速方便的实现字段的解析和提取，但是需要注意的是，一旦调用auparse_feed将数据给到auparse，auparse会先放到队列，然后进行解析，因此，如果审计日志量级比较大，有可能放到队列的操作会失败，也就是调用auparse_feed失败，如果想增大日志处理的吞吐量，可以创建一个比较大缓存队列，收到日志后，先放到队列，然后再从队列中取出后调用auparse_feed。在序列号后面就是若干字段。

从代码中只看到audispd中队列的处理，先将事件放到队列中，然后再从队列中读，对于auditd和audispd之间的缓冲应该是依赖socketpair创建的socket的缓冲区，但是，socket的缓冲区大小是由系统配置决定的，而且auditd的代码中也没看到调用setsockopt设置缓冲区大小的代码。从上面对几个配置文件进行分析可以发现，auditd和audispd只是作为审计日志转发的中间组件，并且使用队列作为中间缓冲，而对于内核的日志发送者来说，日志的接收者只有auditd。

proc/pid中包含了进程的许多信息，这些信息可以供用户查看，也可以供程序读取，程序可以从这里获取到进程的文件、网络等信息并进行分析，但是，频繁读取也可能影响业务性能。

ftrace提供tracefs的接口供用户使用，4.1内核以前的版本，tracing所有的控制文件都在debugfs中，tracefs通常会挂载到/sys/kernel/debug/tracing，为了向后兼容，新的内核在挂载debugfs时，会同时将tracefs挂载到/sys/kernel/debug/tracing和/sys/kernel/tracing。但是，有时候我们除了想知道事件发生了多少次，还需要对事件的某个属性进行分类的统计，或者分析函数的调用栈，总之，希望可以得到更多详细的数据。

将容器中对应路径的so拷贝到/root/gdb_root中，例如，当缺少/usr/lib/libgcc_s.so.1时，就将容器中的/usr/lib/libgcc_s.so.1放到宿主机的/root/gdb_root/usr/lib/libgcc_s.so.1，然后用gdb开启调试，此时就可以读取到对应的so，但是这种方式就需要将依赖的so都下载放到这里。当程序使用release模式进行编译后，还需要对二进制进行strip去掉里面的符号，一方面可以减小二进制的大小，另一方面当然也是防止程序被逆向。

发送数据时，将整个msghdr发送给内核，内核收到数据后，进行解包然后执行对应的逻辑，然后返回数据，此时，用户态程序就需要以类似的逻辑来解析收到的数据：使用recvmsg接收数据，将接收到的数据转换成nlmsghdr，再通过NLMSG_开头的一些宏(NLMSG_OK：正常收到数据；parse_diag_msg：将收到的数据转成inet_diag_msg后，就可以通过其中的inet_diag_sockid获取连接的信息。程序开始时，会通过解析选项，将选项变成下面的struct filter和一些变量的值。

rules：审计规则，其中配置了审计系统需要审计的操作auditctl：用户态程序，用于审计规则配置和配置变更kaudit：内核空间程序，根据配置好的审计规则记录发生的事件auditd：用户态程序，通过netlink获取审计日志用户通过auditctl配置审计规则内核的kauditd程序获取到审计规则后，记录对应的审计日志用户态的auditd获取审计日志并写入日志文件。audit的主要应用场景是安全审计，通过对日志进行分析发现异常行为。

如果升级了内核版本，重启系统后，新安装的版本一般在最上面，因此，如果是升级内核，在安装新版本内核后，直接重启即可。如果yum中也没有或者由于网络原因不能安装yum源，那可以单独去下载kernel包，由于某个发行版中可能没有更新kernel，因此，需要去找到该内核版本所在的发行版本，然后去对应的发行版本中找，例如要下载2.6.32-642.1.1.el6.x86_64版本的内核包，可以执行命令。下载，然后使用rpm进行安装，安装过程中可能某些依赖也需要更新，可以找对应的yum源更新。安装对应的内核包即可。

C++和Linux相关内容

APUE第四章习题解答

radix tree的基本概念和实现

linux程序运行时的数据分布