sysadmin1138's questions

我们正在使用mod_auth_openid 插件为我们网站的一部分提供 OpenID 支持。它工作得很好，但我们遇到了“这样做，除非什么时候”的条件之一，我不确定我错过了哪里。

有一些 URI 是我们不希望应用的。从表面上看，这很简单。

<Directory "/opt/homeapp/web">
  AuthType openid-connect
  SetEnvIf Request_URI "^/(callbacks.php.*)$" allow

  require claim hd:example.com
  require env allow
  require valid-user
</Directory>

这适用于命中callbacks.php文件的内容以及任何其他实际文件。

我的问题出现的地方是尝试匹配 Symfony 路由。如果传入的请求是 to /combobulator/newForm，它似乎Request_URI应该等于/combobulator/newForm。但是，事实并非如此。

SetEnvIf Request_URI "^/combobulator/(.*)" allow
SetEnvIf Request_URI "combobulator/(.*)$" allow
SetEnvIf Request_URI "combobulator" allow
SetEnvIf Request_URI "(combobulator)" allow

所有这些都不做事。

您如何将路线与 匹配SetEnvIf，或者这甚至可能吗？

我需要在 2.6.32 linux 内核上提供具有静态加密的高可用性 MySQL 数据库。“高可用性”部分并不难，但事实证明，与 HA 结合使用时，“静态加密”是一个挑战。

关键问题在于安装加密存储。在我们所有其他的静态加密系统上，有一个命令需要由人来运行，然后系统会提示输入加密密钥。当涉及到服务必须自动启动的集群安排时，该模型有一个相当明显的缺陷。

我目前不知道如何在 HA 环境中提供静态加密，而不是在同一系统上存储密钥密码。

我可以看到两种可能的情况，其中任何一种都适用于我的环境，但我不确定使它们起作用的细节。或者即使有可能。

场景 1：CLVM 和集群

• 我的集群成员之间共享一个卷。
• 本卷设置大致如下：
  • 物理设备上的 cryptsetup 内容
  • 新加密设备上的 LVM 内容
• 集群服务设置为不自动加入集群，依赖于手动干预。
• 集群服务是通过人类运行的命令启动的，它提供解密密钥，进而激活 CLVM 的东西。

通过这种方式，运行中的节点可以访问 CLVM 卷，因此它们可以在集群管理器通知时启动服务。节点的重启仍然需要人工操作，而且 crypt 密码永远不会保存在磁盘上的任何地方。

场景二：DRBD & 集群

• 在每个集群成员上创建一个卷
• cryptsetup 东西在物理设备上运行
• drbd 配置在加密设备之上，以在每个节点之间复制它
• LVM 或文件系统位于 drbd 卷之上
• 集群服务设置为不自动加入集群，依赖于手动干预。
• 集群服务由提供解密密钥的人启动，这反过来使 LVM（或文件系统）可见但未安装。

与 CLVM 设置一样，节点在了解可能共享的存储之前不会加入集群。

问题是，我不确定以上任何一种是否以这种方式工作。两者都假设可以将 LVM PV 置于加密卷之上（例如pvcreate /dev/mapper/cryptmysql）。这可能是不可能的。

这非常依赖于系统，但几乎可以肯定我们会越过某个悬崖并陷入真正的麻烦。我很好奇对于良好的 RAM 与磁盘空间比率存在什么样的经验法则。我们正在规划我们的下一轮系统，需要就 RAM、SSD 以及每个新节点将获得多少做出一些选择。

但现在了解一些性能细节！

在单个项目运行的正常工作流程中，MongoDB 的写入百分比非常高 (70-80%)。一旦处理管道的第二阶段命中，它的读取量就非常高，因为它需要对在处理的前半部分识别的记录进行重复数据删除。这是“将您的工作集保存在 RAM 中”的工作流程，我们正在围绕该假设进行设计。

整个数据集不断受到来自最终用户派生源的随机查询的影响；尽管频率不规则，但大小通常很小（10 个文档为一组）。由于这是面向用户的，因此回复需要低于 3 秒的“现在无聊”阈值。这种访问模式不太可能在缓存中，因此很可能会导致磁盘命中。

二次处理工作流是对可能持续数天、数周甚至数月的先前处理运行的高度读取，并且运行频率不高，但仍需要快速。将访问上一次处理运行中最多 100% 的文档。我怀疑再多的缓存预热也无济于事。

完成的文档大小差异很大，但中值大小约为 8K。

正常项目处理的高读取部分强烈建议使用 Replicas 来帮助分配读取流量。我在别处读到1:10 RAM-GB 到 HD-GB 是慢速磁盘的一个很好的经验法则，因为我们正在认真考虑使用更快的 SSD，我想知道是否有类似的规则快速磁盘的拇指。

我知道我们使用 Mongo 的方式缓存一切都不会飞起来，这就是为什么我正在寻找方法来设计一个可以在这种使用中存活下来的系统。整个数据集可能会在半年内达到一个 TB 的大部分，并不断增长。

我们正在尝试建立一个与我们网络的其余部分隔离的访客 WLAN 网络。由于几个技术原因，这被证明是困难的。我的第一选择是使用一个单独的 VLAN，我们防火墙的便捷 WLAN 端口将在该 VLAN 上处理 DHCP、DNS 和我们需要的网络隔离。不幸的是，由于我们的总部和我们的 Internet 连接本身位于通过城域以太网连接连接的不同位置，我在 VLAN 传输方面受制于我们的 ISP。

他们不会在我们两个站点之间传递第二个 VLAN。而且我的硬件不支持 802.1ad“Q-in-Q”，这也可以解决这个问题。所以不能用VLAN的方式进行隔离。至少不是不花钱。

由于我们的防火墙可以处理 IPSec 站点到站点 VPN 连接，我希望可以将我在办公室位置的 Server 2008R2（标准）服务器连接到 WLAN，并为防火墙提供网关服务。因此：

不幸的是，我不知道是否可以通过这种方式连接两者。防火墙有一个非常灵活的 IPSec/L2TP 实现（我已经用它在野外连接 iPad），但既没有 Kerberized 也不支持 NTLM。Windows 服务器上的连接安全规则视图似乎接近我认为需要完成的工作，但我无法弄清楚如何让它完成我需要它完成的工作。

这甚至可能，还是我需要寻求替代解决方案？

我们正在构建一个可能会生成非常大的 XFS 卷的产品，并且我正在尝试发现给定架构我们可能遇到的扩展瓶颈。

当我们操作文件时，它们被放置在 XFS 卷上的目录中。由于我们处理的文件数量，文件数肯定在数千万级，并且在发布后不久可能会达到数亿级。我们知道这一点是因为我们当前的产品以这种方式运行，因此有理由期望我们的下一个产品也这样做。

因此，正确的早期工程是有序的。

本周的文件基于以下粗略布局：

$ProjectID/$SubProjectID/[md5sum chunked into groups of 4]/file

它给出的目录看起来有点像：

0123456/001/0e15/a644/8972/19ac/b4b5/97f6/51d6/9a4d/file

分块 md5sum 的原因是为了避免“一个目录中有一大堆文件/目录”的问题。由于 md5sum 分块，这意味着 1 个文件会导致创建 8 个目录。这对 inode 的影响非常明显，但我不清楚一旦我们达到规模，这些影响会对 XFS 产生什么影响。

有什么影响？

顺便说一下，这是内核 2.6.32，目前是 CentOS 6.2（如果需要可以更改）。

在测试中，我使用默认值创建了 xfs 卷，并且没有使用任何挂载选项。这是为了尽早排除问题。noatime很简单，因为我们不需要它。总体 XFS 调整是我需要解决的另一个问题，但现在我担心我们现在设计的元数据乘数效应。

我已经知道更好的解决方案是什么，我只是不知道我是否有理由推动改变。

由于 md5sums 在第一位数字上非常独特，而且单个子项目很少超过 500 万个文件，所以在我看来我们只需要前两个块。这会产生如下布局：

0123456/001/0e15/a644/897219acb4b597f651d69a4d/file

一个完全完整的一级和二级目录将在每个一级目录中有 2 ¹⁶个一级目录和 2 ¹⁶个二级目录，卷上总共有 2 ^{32 个}目录。

因此，假设的 500 万个文件子项目将有 2× ¹⁶个一级目录，每个二级目录大约有 76 (+/- 2) 个二级目录，每个二级目录中有一个或两个三级目录。

这种布局的元数据效率更高。我只是不知道是否值得努力改变现在的情况。

我们刚刚在新站点中添加了一个新的 Server 2008 (sp2) 域控制器，这是我们的第一个此类配置。它通过 VPN 网关 WAN (10Mbit)。不幸的是，它显示出奇怪的网络症状。与 SMB 端口（TCP/139 和 TCP/445）的连接被主动拒绝……如果连接是通过纯 IPv4 进入的。如果传入连接是通过 6to4 隧道来的，那么这些连接会建立并正常工作。

它不是防火墙，因为可以在关闭防火墙的情况下复制此行为。此外，它实际上是向连接尝试发出 RST 数据包；只有在端口后面有服务并且服务本身拒绝访问时，Windows 防火墙才会发生这种情况。我怀疑它是网络上的一些防火墙设备，因为这个替换的服务器正在运行 Samba，并且从我们的主网络访问它运行得很好。

我认为这可能与 AD 站点和服务中的子网列表有关，但我不确定。我们没有在其中放置任何 IPv6 地址，只有 v4，并且被拒绝的是 v4 连接。不幸的是，我无法弄清楚这一点。我们需要能够从主校区与这个 DC 交谈。是否正在进行某种基于站点的 SMB 级过滤？我可以和校园里的 DC 交谈，但那是通过 v6 隧道。我无法访问该远程子网上的常规机器，这限制了我的测试能力。

我们有一个学生实验室，它使用单色打印机和多个打印队列来处理彩色和黑白打印。我们还使用 pcounter 进行审计。我们正在从 Novell 的 NDPS 系统转移到 Windows 2008 上，在这种情况下我遇到了一些困难。打印经理希望在此实验室中拥有一台打印机（在本例中为 Ricoh 打印机），并为彩色和黑白作业拥有两个单独的打印对象，并分别对其中任何一个进行收费。

这不是一件简单的事情。PCounter 的颜色检测在这种情况下不可靠，因此我们不能使用它来将颜色作业排除在黑白队列之外。如果我们将两台不同的打印机放在具有锁定驱动程序的实验室站上，似乎可行。该模型在 Novell 环境中运行良好，因为学生必须将 Novell 客户端添加到他们的笔记本电脑才能将彩色作业打印到黑白队列中，而我们从未找到这样做的人。Windows 打印环境改变了这一切，因为现在几乎任何东西都可以打印到 Windows 打印对象。

我们的学生将能够使用无线网络（可能还有宿舍）上的个人非域机器将驱动器映射到中央文件服务器，并且大概也可以映射到中央打印服务器。我们有零种方法来管理这些私有的、非域名的笔记本电脑，因此没有任何类型的驱动程序级控制；特别是对于那些到处乱跑的 MacBook。这就是驱动级解决方案不可行的原因。

我们必须让整个学生团体都可以打印到这些打印机上，但如果假脱机程序也只接受来自特定工作站的作业，我们真的很高兴。Windows 打印环境是否支持这样的功能？

我们正在将一些目录从 NetWare 移动到 Windows，并且遇到了权限差异。因为 NetWare 使这很容易，所以我们有整个卷，在卷的顶部没有用户拥有任何权限，并且第一层、第二层和第三层目录是授予权限的地方。由于 NetWare 受托人系统的工作方式，如果您可以访问树深处的目录，则可以毫无问题地从根目录浏览到该目录。这有一个方便的副作用，即仅在您枚举您无权进入的目录时显示您有权访问的目录。

“仅显示您有权访问的目录”的问题是通过 Microsoft 的基于访问的枚举 (ABE) 解决的，是的，这是一件好事。

我们遇到的问题是弄清楚需要设置哪些权限和安全策略才能允许用户从根共享浏览到他们有权访问的目录。示例使这更容易解释。

\\server\share\finance\audit\auditreports\HR-Q4-2007

审计小组授予人力资源经理对上述审计报告目录的权限（“HR-Q4-2007”）。在 NetWare 下，这将允许 HR 经理从 \\server\share\ 开始，然后浏览财务、审计和审计报告，以进入目录。一个许可，它就奏效了。

“绕过遍历检查”安全策略意味着 HR 经理可以将驱动器直接映射到 \\server\share\finance\audit\auditreports\HR-Q4-2007\ 并且它会正常工作。这不是我们想要的，我们希望用户能够从顶部开始向下浏览。

这是否需要使用“遍历文件夹”NTFS 权限来启用此功能？如果是这样，这意味着一个更复杂的权限环境，但我们可以解决它。当ABE也在使用时，这个问题如何解决？

我一直在寻找托管服务提供商。在这个过程中，我遇到了一个似乎对 apache 1.3 有明显偏好的人。考虑到 1.3 是在 11 年前发布的，我不清楚为什么有人会有这样的偏好。

在工作中，我们仍然使用 1.3 作为我们的主要网站。但那是因为 1.3 仍然是 Solaris 8 的默认 Apache 服务器，这就是运行该网站的内容。随着内部应用程序迁移到 Linux（SLES10 和很快 11），内部应用程序越来越多地托管在 Apache 2.2 上。

哎呀，NetWare 6.5 默认附带 2.0，如果你真的想运行它，你可以下载 2.2。1.3 是 NW6.0 的默认值。

但是，我不是网络管理员，所以我不知道为什么 Apache 1.3 可以成为首选平台的兼容性细节。我知道 Apache '正常工作'，这可能是其中的一部分。1.3 对它的新兄弟有什么吸引力？

某些日志文件系统确实会因将日志托管在与文件系统本身相同的驱动器上而遭受性能损失。使用外部日志可以提高写入速度。随着 SSD 的出现，一个 SSD 完全有可能支持托管在传统旋转磁介质上的文件系统的多个外部日志。虽然 Anandtech “ SSD Anthology ” 确实涵盖了其中的一些内容，但他们没有涵盖“多期刊”测试用例。

日志往往非常小，因此即使是小型、快速的 32GB SSD 也可以为多个大型文件系统提供很大的速度。它的磨损可能比一般 I/O 模式建议的要快得多，这就是为什么拥有比您最终使用的更大的设备是个好主意的原因。

你们有没有人做过这样的事情，或者甚至只是使用外部期刊？我对现实世界的案例很好奇。