Reading Papers - Configuration Management
# Overview
configuration management 领域相关工作的基本假设是程序的代码实现正确,仅考虑系统的 configuration 在初始化、用户人工配置、或软件更新时被设置了错误值的情况。
# Runtime Fixing
# OSDI'04 - PeerPressure
PeerPressure 利用设备群组的统计值来挖掘桌面 PC 设备 misconfiguration 的 root cause 。
OSDI'16 - Early Detection of Configuration Errors to Reduce Failure Damage
Taxonomy : configuration management / runtime fixing
Tag : statistics / database-depentent / desktop PC
PeerPressure 的方法适用于桌面 PC 设备 misconfiguration 的诊断,但为便于描述,本文仅针对 Windows 注册表进行讨论。
- Windows 注册表 misconfiguration 的出现可能有多种原因:软件缺陷导致注册表项被破坏;软件补丁包引入与现有应用程序不兼容的注册表项;软件卸载时发生错误引入不一致性;等等。
对于一台故障机器,要想判断其故障是否由 misconfiguration 导致、以及具体由哪项配置导致,可以很自然地想到,如果有一台正确运行的机器用于 differential testing 将是极佳的。然而,自动从设备群组中识别出正确运行的机器是困难的。
KEY Idea :如果某个应用程序功能在大部分设备上运行正常,则这些设备可以构成所谓 "statistical golden state" 的一个足够大的样本集。将其与贝叶斯统计相结合即可自动识别并纠正故障机器上的 misconfiguration 。
PeerPressure 的工作流程如下:
对于一次出错的执行,app tracer 捕获用作此次执行的输入的注册表项,由开发者将这些注册表项作为 suspects 输入 PeerPressure 。
将注册表项归一化为统一的格式。
自动搜索一组运行相同应用程序的设备作为样本集。本文从 GeneBank 数据库提取设备配置的快照作为样本集,但也可以通过 peer-to-peer troubleshooting community 获取。
利用贝叶斯统计方法(具体算法略,详见论文原文)计算每个 suspects 是错误表项的概率,并依次尝试修复。
错误表项的显著特征:其它设备都具有同类的配置值,仅故障设备的配置值不同。如果该项在不同设备的配置值都显著不同,则可能是 natural biological diversity ,需要被排除。
# SOSP'07 - AutoBash
AutoBash 在 Linux kernel 内部实现 OS-level causal tracking ,用以理解与 configuration 有关的操作的输入和输出,进而帮助用户找到 configuration error 的解决方案。
SOSP'07 - AutoBash - Improving Configuration Management with Operating System Causality Analysis
Taxonomy : configuration management / runtime fixing
Tag : speculative execution / causal tracking / linux kernel / database-dependent
Preceding Work : SOSP'05 - Speculative Execution
AutoBash 的目标是当系统发生 configuration error 后帮助用户找到解决方案。本文的 解决方案 指的是将系统从错误状态转换到正确状态的一系列动作,即运行时修复。
AutoBash 提供了如下三种运行模式:
observation mode :提供一个 modified bash 以帮助用户人工交互解决问题。
replay mode :从数据库中抓取相似问题的解决方案,并自动尝试修复。
health monitoring mode :周期性地运行系统健全性检查,并在出错时自动进入 replay mode 。
一方面,AutoBash 将系统运行建模为 action 和 predicate 的组合:action 是改变系统状态的指令;predicate 是测试系统正确性的指令,且对系统状态没有任何 externally-visible 的修改。
另一方面,AutoBash 利用 speculative execution 和 causal tracking 来降低用户尝试解决方案的代价和系统正确性评估的效率。
本文重点讨论了如何通过在 OS-level 跟踪和分析 causal dependency 在进程、文件和其他实体之间的传播来达成 AutoBash 的实现目标。
# Autobash Observation Mode
AutoBash 提供的 modified bash 支持 speculative execution ,将用户在其上执行的任何 action 视为可能的解决方案的一部分,允许用户在发现解决方案不正确时回滚所有指令的 side effect 。
对于简单的 action ,AutoBash 只需捕获所执行的指令本身;
对于会调用交互式程序(例如文本编辑器)的 action ,考虑到这可能涉及大量的 GUI 交互操作,以及大量的系统调用,为解决这一困难,AutoBash 会利用 output set diff 提取 state delta 用以回滚系统状态。
用户可以从 AutoBash 提供的 predicate database 中查询目标程序及相关 configuration 可用的 predicates ,也可以自行编写。
# AutoBash Causal Tracking
AutoBash 设计 causal tracking 的目标是使 predicate validation 对系统性能的影响尽可能小:通过捕获 configuration-related actions 和所有 predicates 之间的关联(包括前者的 casual effects 和后者的 causal dependency),在尝试新解决方案时只检查那些和新的 actions 有关的 predicates 。
AutoBash 将 OS kernel 内部的 process, file, directory entry, socket, pipe, signal 视为 实体 (entity) 。当进程与另一实体产生关联时,AutoBash 会追踪实体之间的因果关系,具体地讲:
当进程观测到另一实体的存在时(例如读取文件或接收信号量),称进程 因果依赖于 (causally dependent on) 这一被观测到的实体。
当进程修改另一实体时,称该实体因果依赖于修改它的进程。
当进程读写另一实体时(例如在写入文件之前检查其权限),称进程和该实体之间相互因果依赖。
AutoBash 只对受初始 predicate 或解决方案影响的实体进行 causal tracking 。
AutoBash 基于 SOSP'05 - Speculator 实现 causal tracking :
对于 potential solution 的每个 action ,利用 Speculator 在隔离的子进程上进行单独的 speculative execution ,并追踪对应进程的 output set ;
对于每个 predicate ,利用 modified Speculator 追踪对应进程的 input set ;
如果 action's output set 和 predicate's input set 不相交,则可以避免重复执行暂时不需要重新检验的 predicates 。
AutoBash 可以为已确认的解决方案提供 causal explanation ,形式为包含所有相关 actions 和 predicates 的因果关系图。
# Error Diagnose
# ICSE'11 - Static Extraction
本文利用静态分析技术获取系统中每个配置项的所有 potential use point 。
ICSE'11 - Static Extraction of Program Configuration Options
Taxonomy : configuration management / error diagnose / configuration usage extraction / automatic documentation
Tag : empirical study / static analysis
过度的可配置性 (excess configurability) 和 糟糕的文档 (poor documentation) 被认定为软件系统普遍面临的问题,但解决方案迟迟未能出现。
Argue :静态分析可以弥补 key-value style configutation 的弱点。
静态分析可以提取系统配置的 schema ,将用户配置文件和程序文档与程序的实际结构相关联。
对于重写过于困难或代价过大的已有系统而言,静态分析是高效的。
Argue :许多系统配置仅在特定的模块中使用,或仅在收到特定输入时启用,因而动态分析难以找到系统配置的所有 use point ;相比之下,静态分析更容易达到更高的覆盖率。
# Empirical Study
本文对七个使用 key-value style configuration 的开源软件系统进行了调查分析,有如下发现:
6/7 个软件系统具有 narrow 且 well-defined 的 configuration API 。通常是一个专门的类,向程序的其余部分公开了一组可以读取配置选项的 key-value 接口。
……
本文查阅了每个软件系统的文档和默认配置文件,导出一组选项列表,然后手动对每个选项进行分类,最终有如下发现:
- 略
# 静态分析
本文致力于解决的问题是获取系统中每个配置项的所有 potential use point 。本文的方法将其分解为两个主要部分,将 configuration API 和配置的语法细节相分离:
找到所有读写 configuration 的程序点;
对于每个程序点,分析其所有可能读写的配置项。
对于第一部分,本文从已发现的 configuration API 出发,找到所有的向这些方法传递简单字符串参数的方法,以处理常见的 wrapper function 情况;
对于第二部分,本文找到调用这些 API 的所有可能的参数;
本文所用的静态分析算法流程如下:
Construct points-to and call graphs.
Mark known configuration methods.
Mark option-name arguments to these methods.
while (not converged to fixpoint)
for each method m:
if an argument of m used as an option name
Mark method as conf. read call.
Mark argument as option name.
Find possible string params at call sites
Output option names and read points.
Output methods taking option names as arguments.
# ASE'11 - FCS *
FCS xxx
ASE'11 - Precomputing Possible Configuration Error Diagnosis
Taxonomy : configuration management / error diagnose
Tag : static analysis
Preceding Work : ICSE'11 - Static Extraction
本文所提出的分析方法的工作流程如下:
利用指针分析构建 call graph 。
找到所有读写 configuration 的程序点,以及每个程序点处所有可能读写的配置项;这由 ICSE'11 - Static Extraction 中的技术完成。
为每个可达的方法构建 flow summary 。
利用 stack trace 从程序崩溃点出发进行 FCS 数据流分析(详见下文)。
将前面分析的结果用于最后的过程内控制流分析。
本文提出了 failure-context-sensitive analysis (FCS) 分析技术来改善错误诊断的精度。
- ???这 FCS 我看不懂了
本文将分析技术构建为 web 服务,用户只需要上传 stack trace 或 log file 即可获取错误诊断报告。
本文的分析技术仅能报告可能与程序错误有关的配置选项,并不能给出能修复问题的正确配置值。
本文的分析技术既有误报也有漏报。
# Dynamic Detection
# OSDI'10 - ConfAid *
ConfAid 利用 dynamic information flow analysis
OSDI'10 - Automating Configuration Troubleshooting with Dynamic Information Flow Analysis
Taxonomy : configuration management / error diagnose
Tag : dynamic analysis / information flow analysis
# Early Detection
# OSDI'16 - PCheck
PCheck 利用被测程序中实际引用配置值的代码来自动生成模拟实际引用行为的检查代码,并在初始化阶段进行早期的配置检查。
OSDI'16 - Early Detection of Configuration Errors to Reduce Failure Damage
Taxonomy : configuration management / bug detection
Tag : program synthesis ? / static analysis / static taint analysis
潜在配置错误 (latent configuration error, LC error)
PCheck 为被测系统自动生成 early check 代码以尽可能减少由配置属性错误引起的 LC 错误。
配置错误存在对应的 early check 也不能保证绝对的正确性,因为检查可能是片面的(例如日志文件不仅要存在,还要具有写权限;开发者可能会错误地仅检查了前者)。
# Empirical Study
作者对六个成熟的、已被广泛部署的软件系统进行了调查研究,以了解 LC 错误的相关特征和性质。
本文的 empirical study 主要关注与系统的 RAS 相关功能 (RAS-realted features, e.g. reliability + availability + serviceability) 紧密相连的配置参数。常见的 RAS 相关功能包括 error handling, fail-over, data backup, crash recovery, error logging and notification 等,被系统中相应代码引用的配置参数是重点关注的范围(注:无论是 LC 错误的范围还是PCheck 工具的检查能力都不限于 RAS 属性,只是 empirical study 以此为标准)。
本文的 empirical study 揭示了如下发现:
许多至关重要的配置参数(即 RAS 属性)不存在显式的检查代码,而是在配置值被实际引用时才被隐式地检查合法性(例如非法的日志文件路径仅在实际 open/write 时才暴露出来)。
许多配置属性并不在系统的初始化阶段被引用,而是在后续执行中才被引用(例如在 error handling code 中)。
由以上两点综合得出,一些至关重要的配置参数没有接受任何 early check ,因此会受到 LC 错误的影响,进而严重影响系统的可靠性。
由以上发现可以推导出如下结论:
成熟的系统中仍然有配置属性 early check 缺失的问题,并因此导致危害系统可靠性的 LC 错误。
尽管缺乏显式的检查代码,许多配置属性都会在其值被引用时受到隐式的检查,而这些代码自身就蕴含了有关所引用配置属性的 specification 。
这种蕴含的特性在过去的其他工作中极少被利用,因为等到这些代码被执行时,通常为时已晚。
# PCheck 设计和实现
KEY Idea :利用如上所述的那些实际引用配置值的代码的特性,自动生成对应的检查代码,并在初始化阶段调用它们以达到 early check 的目的。
对于生成的检查代码,PCheck 需要保证其执行不会对被测系统及其外部环境产生任何副作用。
PCheck 的工作流程如下:
找到所有初始读取配置参数的指令;PCheck 利用已有工作的 common practice 来完成这一点,这要求系统自身的 specification 指定导入配置的接口。由于主流的成熟系统使用的接口都是相似的(通常是 API 、数据结构、解析函数这三种),该需求只会引入很小的人力代价。
从这些初始化指令出发进行前向的静态污点分析,找到所有引用该配置值的指令;
对每个引用指令所引用的其它变量进行回溯,获取其最近的定义,用于生成模拟执行的上下文;
利用上述指令及上下文生成检查代码。PCheck 要求在系统代码中插入额外的注解,标识初始化代码的位置以便插入检查代码。
- 01
- Reading Papers - Kernel Concurrency06-01
- 02
- Linux Kernel - Source Code Overview05-01
- 03
- Linux Kernel - Per-CPU Storage05-01