openSUSE:Heroes/Meetings/20161202 摘要

内容

openSUSE Heroes 2016 团队会议记录

地点

在 SUSE 总部

何时

星期五，2016-12-02 至星期日，2016-12-04

谁

• 全天
  • Daniel Maslowski <info@xxxxxxxxxxxxx>
  • Sarah Julia Kriesch <sarah-julia.kriesch@xxxxxx>
  • Christian Boltz <opensuse@xxxxxxxxx>
  • Theo Chatzimichos <tampakrap@xxxxxxxxxxxx>
  • Gerhard Schlotter <gschlotter@xxxxxxx>
  • Markus Rückert <mrueckert@xxxxxxx>
  • Lars Vogdt <lrupp@xxxxxxx>
  • Christian Müller <cmueller@xxxxxxx>
  • Thorsten Bro <tbro@xxxxxxx>
• 临时
  • Christoph Wickert <cwickert@xxxxxxx> (仅星期五 11:30)
  • Richard Brown <rbrown@xxxxxxx> (仅星期日)

主题

• SaltStack 培训 => 星期五
• SUSE Cloud 培训 => 星期六
• 打包研讨会 => 跳过
• 处理工单
• 保护我们的基础设施
• 记录我们的基础设施
• admin / 基础设施策略
• 联系人和他们的职责 (服务地图)
• 机器列表
• 邮件列表、它们的设置和策略
• Kiwi 镜像
• build.opensuse.org => 基础设施项目
• 赞助更新
• 镜像和镜像基础设施
• 外部服务 => 将它们交给合适（外部）的人员？
• gitlab => 等待 FreeIPA
• 带回家的任务 => 请在 wiki 和 connect.o.o 上更新您的个人页面
• 监控 => 完成，见下文
• 日志分析 => 在下次会议期间深入讨论
• mediawiki
• 我们需要检查 Klaas 是否想维护 hermes AI: tbro
• 密钥管理和访问控制 => 参见 FreeIPA
• 下次会议 => 定期会议日期/时间
• 密钥签名派对
• 所有 Heroes 内部的密钥签名派对
• DNSSEC 和更多 IPv6 的使用 => 下次会议 (CloudFlare 作为起点)
• 每 6 个月从头开始重新安装所有 openSUSE 机器？
• connect.opensuse.org => 我们现在被委员会阻止了超过 12 个月。该怎么办？

议程

SaltStack 培训

• 与此同时，lrupp 大量更新了 opensuse-admin wiki 页面

处理工单

• AI Theo: 将文档从 redmine wiki 迁移到公共 wiki
• AI Theo: opensuse-admin wiki 将迁移到私有子项目 (目前是公开的，包含敏感数据)
• AI Theo: provo 项目将被移动到 opensuse-admin 以获得适当的类别 (在获得英雄邮件列表的确认 (或无异议) 之后)
• 请参阅以下内容以获取更多信息
  • https://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems
  • https://en.wikipedia.org/wiki/Comparison_of_help_desk_issue_tracking_software
• Lars 和 Darix 将提供测试实例
  • Darix: 推荐 Zammad => https://zammad.com/
  • Lars: Request Tracker => https://bestpractical.com/request-tracker
  • cmueller OTRS => https://www.otrs.com/
  • tbro BRIMIR => https://getbrimir.com/

记录我们的基础设施

• admin / 基础设施策略: https://en.opensuse.net.cn/openSUSE:Infrastructure_policy
• 我们将为每个主机使用不同的 root 密码
• 默认用户身份验证方法将通过用户 ssh 密钥通过普通用户 (通过 FreeIPA)
• 我们将使用 password-store 作为存储密码的工具
• 我们需要创建一个包含机器列表和适当人员服务的 wiki 页面 (该页面需要从内部 SUSE redmine wiki 移动)

联系人和职责

• 与其尝试在 https://en.opensuse.net.cn/index.php?title=openSUSE:Services_help 上提供静态服务列表，我们将通过在 http://status.opensuse.org/ 上监控设置中列出的服务来提供自动方法。这将回答客户关于我们机器列表的问题
• 我们的团队页面得到了改进: https://en.opensuse.net.cn/openSUSE:Heroes (openSUSE:infrastructure 和 openSUSE:Services_team 重定向到这里)。我们删除了过时的信息，进行了相应更新，并放置了过去 oSC 的视频演示。

赞助更新

• 英国 IT 公司 CDN77 提供了 opensuse.org <https://opensuse.net.cn/> 的免费 CDN。我们应该尝试一下并向他们提供反馈。联系人是 Oskar Gottlieb <oskar.gottlieb@xxxxxxxxx> AI: darix, theo 进行一些测试
• 目前正在与一些外部公司联系，他们希望赞助构建服务的硬件。我们在这里遇到的问题：我们需要独特的硬件来简化管理。我们可以提供一些我们要求的规格，他们想为我们购买硬件。我们的主要问题可能是仍然没有基金会，所以公司/个人无法从我们这里获得捐赠收据：他们确实花费了金钱/硬件而没有从我们这里得到任何回报。
  • 构建服务总是需要构建能力，即充当构建工作者的机器
  • 我们还可以考虑一些可用于测试服务部署的测试系统 (这些可以在 openSUSE Cloud 中部署)
  • openQA 最近获得了一些新硬件，但也一直在寻找更多的“工作者”
  • 新的交换机或其他小型基础设施硬件也是一个选择
  • 额外的存储也是一个好主意，但这从 7k 欧元开始，并且没有上限。这里的问题：我们希望获得兼容的硬件，例如可以作为 JBOD 使用
  • 作为未来想法：向我们的本地供应商询问“捐赠池”，其中包含一些可以由赞助商付费的预配置机器
  • AI: SUSE-IT 团队 (特别是 cmueller 和 tbro) 提供一个计划用于 openSUSE 的硬件清单
  • AI: cmueller 加入 donation@o.o 列表，以便快速回答有关硬件赞助的问题

软件包和 Kiwi 镜像

• 我们在 build.opensuse.org 上有一个名为 openSUSE:Infrastructure 的特定项目，其中包含未包含在基本系统中的软件包。如果适用，这些软件包应从 Factory 链接，否则从 devel 仓库，并锁定版本。
• 在子项目中，我们构建特殊的 JeOS 镜像，目前可以在 NUE 的 openSUSE 集群中使用。Theo 正在为 Provo 的 openSUSE Cloud 准备新的镜像。如有疑问：这将是 42.2 镜像。注意事项
  • 我们需要使用比 42.2 随附的新 kiwi，这就是为什么我们添加了 Virtualization:Appliances:Builder 项目
  • 从 42.1 到 42.2 的启动代码没有更改 - 因此我们使用 oemboot/suse-leap42.1 作为启动代码
  • 该镜像非常小 - 它仅包含一个基本系统 (因此您可以运行 zypper)、网络工具和一个 salt-minion。它缺少云特定的软件包/工具，这些需要添加到 openSUSE Cloud 中
  • 配置不是自动化的：这意味着 Salt 密钥不会自动集成/接受。因此，现在这将保持手动操作，除非有人想帮助 Theo 完成它。由于 Cloud 在这方面有一些自动化 (“cloud init”)，这可能是一个简单的步骤 - 但需要有人来完成它。cmueller 将与 Theo 合作解决这个问题。

基础设施仓库

• openSUSE:Infrastructure 仓库用作“生产”仓库。因此，没有空间用于测试软件包。
• 如果您想测试软件包或准备更新，请在任何其他仓库中执行此操作，并在完成后提交 (或更新 Infrastructure 仓库中的链接引用)
• 对于测试和生产，我们可以使用 Salt 功能将软件包锁定到特定版本。
• 如果您有超过 2 个需要进入 Infrastructure 仓库的机器/服务的源软件包，请使用子项目。子项目的名称和描述应注意并描述该仓库中软件包的用例 (如有疑问，请包含机器的 DNS 条目)。
• 请考虑将您的软件包移动/集成到主发行版中，以简化我们的生活并保持基础设施仓库的小型。
• 如果需要更新官方 openSUSE 仓库中的软件包，我们不会将更新的版本放入核心/主 Infrastructure 项目中。相反：这些软件包需要进入 Infrastructure 项目下方的单独子项目 - 这样只有需要这些单独软件包的机器才能添加仓库。
• Heroes 团队将每 6 个月审查 Infrastructure 仓库 (包括子项目) 中的软件包并进行清理 (包括检查机器上孤立的软件包)。
• TODO: 用上述内容增强当前策略
• Theo 目前正在花费大量精力将现有的 VM 迁移到 Leap 并将软件包迁移到 openSUSE:infrastructure 仓库。

drix 的 FreeIPA 演示

• 计划至少为内部 DNS 和帐户管理实施 freeIPA
• 管理员将基于 LDAP 组 (和 kerberos 票证) 访问机器，这使得跟踪谁是谁以及谁可以访问哪些机器变得更容易
• 由于 FreeIPA 帐户不会连接到我们用于 openSUSE 的常规身份验证机制，只有 openSUSE 管理员才能获得 freeIPA 帐户。
• 管理员将能够通过 OpenVPN 访问 FreeIPA 实例 (我们需要有关访问的策略)
• gitlab.opensuse.org (以及可能仅为管理员提供的其他服务) 也将从本地身份验证或从 openSUSE (bugzila) 帐户切换到 freeIPA
• openSUSE (bugzilla) 和 FreeIPA 用户名需要匹配 - 这应该成为一项策略；-)
• 将有两台 FreeIPA 实例用于高可用性和访问原因
  • 一台实例将在 Nuremberg 的正常集群中运行
  • 一台实例将在 Provo 的 Admin 节点上运行 (在 Cloud 之外，以便能够访问 Cloud DMZ 网络)
  • 这些实例将通过 OpenVPN 隧道连接到彼此

cmueller 的 Cloud 培训

• Cloud 试图隐藏其功能在一些花哨的名称后面，以避免普通管理员理解正在发生的事情。但我们很顺利，经过这次培训，我们理解了双方。:-)
• 硬件节点具有不同的名称和功能
  • Crowbar => 管理节点，仅用于管理裸机内容
  • Controller => 它们运行控制云服务本身的服务的
  • Network => 特殊的控制器节点，具有额外的网络功能，以提供虚拟机的路由功能 (云语音中的“实例”)
  • Storage => 仅提供可供实例使用的原始块设备
  • 计算 => 真正运行虚拟机的宿主机（“实例” - 如上所述）
  • 实例 => 这是你真正想要的：提供你的服务的虚拟机
• 位于普罗沃的 openSUSE Cloud 包含以下裸机服务器
  • 1x 管理节点 => 将运行以下虚拟机
    • Crowbar（同时运行 Chef 服务器以管理其他 Cloud 机器）
    • 用于 Cloud 管理员的 openVPN
    • FreeIPA，包括用于 Heroes 的 openVPN 设置（以便他们可以访问他们的虚拟机）
    • 日志服务器
    • 监控服务器
    • SMT 服务器
  • 2x 控制节点
    • 将成为一个 HA 集群，运行所有必要的云服务
  • 3x 计算节点
    • 也将是网络控制器
  • 2x 10Gb 交换机
  • 1x 1Gb 交换机
• 在此处放置包含概述的图像
• 网络设置
  • 固定/内部网络 : 此网络静态链接到实例；此网络内的所有实例都可以“相互通信”
  • 浮动网络 : 这是我们的“提供商”网络（具有外部 IP 的网络）。没有 Cloud 实例可以直接访问此网络的 IP - 仅通过网络服务侧的 NAT
  • 传输/SDN 网络 : 我们使用此网络进行实例之间的计算节点间通信。如果计算节点 1 上的实例想要“与”计算节点 2 上的实例“通信”，它们将使用此网络。此网络允许更精细的调整（因此得名 SDN），但目前未使用。
  • DMZ : DMZ 网络为希望管理其机器（启动/停止/重置、获取控制台访问权限、设置新机器）的“客户”提供 Web 界面。我们不会将此 DMZ 网络暴露到外部，而是提供一个专用的 VPN 服务器，允许 openSUSE Heroes 连接到它以访问 WebUI（这可能不需要经常使用）。

Salt 拓扑

• 我们将在每个位置设置单独的 Syndics，并在不久的将来在纽伦堡设置一个 Master of Masters
• 代码库将与所有位置相同（将使用相同的 git 仓库用于状态和 pillars）
• HA 设置目前是次要的
• Salt masters 将使用与 FreeIPA 相同的 openvpn 进行相互通信

监控

• 未来将有一个非公开的监控安装
• 我们将把社区人员引导至 http://status.opensuse.org/ 以获取我们服务的“用户概览”
• 我们需要为 NUE 和 PRV 中的实例找到解决方案：它们正在内部、未路由、防火墙保护的网络中运行 - 但我们希望为我们的管理员提供一个独特的 WebUI，以便一次性获取“全局视图”。 => 由监控管理员检查/实施

镜像和镜像基础设施

• 通常，我们有以下机器在“download.opensuse.org”之后
  • mirrordb{3,4} => 包含数据库（85GB 大小）的 PostgreSQL 集群
  • pontifex3 => 在 download.opensuse.org 背后的 VM，使用 mirrorbrain（顺便说一句，还提供许多其他虚拟主机）
  • scanner-opensuse => 一个不断扫描外部镜像服务器的 VM。目前此 VM 位于 SUSE 网络内部，应移动到外部集群。问题可能是，外部集群使用另一个 IP 地址，因此扫描可能会在仅允许当前 IP 地址的某些镜像上失败。但这可以解决。
• https://github.com/openSUSE/mirrorpinky 应该成为 mirrorbrain 的 WebUI - 但当前状态是“休眠”（没有时间去处理它）。如果你找到愿意提供帮助的人，请联系我们 ;-)
• AI Theo：我们需要设置一个虚拟机作为 mirrorbrain 管理机器，以便社区人员也可以进行镜像管理
• 同一台机器将作为辅助扫描机器（现在的主机器位于 SUSE 网络之后）。镜像管理员将被告知新的 IP，并在六个月后我们关闭旧扫描器。
• 与镜像相关的工单需要关注
• 镜像文档也可能需要更新，如果我们的镜像专家可以过一遍就太好了。
  • https://en.opensuse.net.cn/openSUSE:Mirror_infrastructure 供镜像管理员使用
  • https://progress.opensuse.org/projects/opensuse-admin 供 mirrorbrain 管理员使用

与 rbrown (openSUSE Board) 的讨论

• progress.opensuse.org => openSUSE Heroes 将成为 redmine 实例上的管理员，以便能够帮助进行一般管理
• 赞助 => 董事会将把硬件或镜像方面的赞助提议转到 donations@xxxxxxxxxxxx，由我们的管理员接管。请注意，我们希望“借用”硬件，而不是完全将其移交给我们。
• connect.opensuse.org => openSUSE 成员的清理应在明年初的新董事会选举之前完成。这样我们就可以在完成后开始将电子邮件迁移到 Heinlein。
  • 应用程序本身该怎么办？我们目前没有该应用程序的维护者 - 但另一方面，所使用的版本非常旧，需要更新。由于此工具包含用户数据库（尤其是成员信息），因此它已成为基础设施的重要组成部分。
  • 由于维护者不再对其进行操作，我们需要找到解决方案。我们需要 openSUSE 董事会、管理员和 Heroes 的一些成员之间的会议。
• freeIPA => FYI：为了管理 openSUSE 基础设施，Heroes 将引入并使用 FreeIPA 来管理当前在管理方面分散的一些事情（用户帐户和访问限制、证书以及可能还有 DNS）。
• 如何将 openSUSE 用户帐户与当前的 Microfocus / Novell / SUSE 身份验证机制分离？好处是，我们可能会看到更多的用户/贡献者，因为对于他们来说，谁正在获取数据（在创建帐户时请求）以及谁正在使用它会更加清楚。这是目前反复出现此问题的根本原因。我们看到 bugzilla 等工具应该能够使用其他身份验证系统，但如果这样，就会出现问题。如果出现其他身份验证系统，登录数据可能会重复。我们可能会遇到身份验证领域的其他问题，并且可能需要很长时间才能解决。但如果找不到更好的解决方案，我们可能会专注于此。
• 什么时候成立基金会？从我们的角度来看，一个主要好处是赞助，这可以通过基金会来实现。现在这部分已经解决了（见上文）。董事会在一年内一直被所有技术变化（Tumbleweed、Leap 等）所困扰，并且不认为这个问题至关重要（这是没有高优先级推动的原因）。其他论点是与此类基金会相关的法律和通用问题 - 这将引入大量的额外组织开销。最终：这个问题（轻松赞助）的根本原因已经得到某种程度的解决，所以我们希望现在只需要对“如何赞助 openSUSE”进行良好的营销，并最终摆脱这个问题……

在非基础设施管理的机器上运行的 opensuse.org 服务

• planet 和 paste 在非基础设施管理的机器上运行，这违反了我们的策略。此外，人们要求我们修复我们无法访问的服务上的工单。
  • planet.o.o 需要开会讨论可能存在的当前法律问题（或者可能已经不存在）。
  • 同样适用于 paste.o.o
• 我们需要与董事会开会讨论：paste.o.o、planet 和 connect AI：Theo 设置此会议

团队会议

• 下一次面对面会议将在 5 月在纽伦堡举行的 openSUSE Conference 2017 期间举行
• IRC 会议应每月一次在每个月的第一个星期日 19:00 CET（18:00 UTC）举行；主题
  • 工单处理
  • 状态汇报
  • 特殊项目（如 wiki 迁移）
  • 上次会议以来的变化
  • 为他人的问题提供帮助
  • 我们将每次会议后记录会议纪要，会议记录人角色按用户名字母顺序轮换

mediawiki

• *.opensuse.org wiki 运行过时的 MediaWiki 版本
• 只有普罗沃的管理员才能直接访问 wiki 服务器，并且没有提供我们希望看到的响应时间和质量 ;-)
• 我们将把 wiki 迁移到即将到来的 openSUSE Cloud，以便我们获得直接访问权限并可以（并且必须 ;-）维护它
• cboltz 正在更新 wiki（到 1.27.x LTS）。将发生的变化（主要是由于上游 MediaWiki 的变化）
  • MediaWiki 身份验证框架已完全更改，因此我们将切换到 openID（作为扩展可用），而不是重写我们的 AccessManager 扩展
  • 由于 MediaWiki 的变化，openSUSE 主题（“Bento”）需要更新（状态：工作正常，但一些代码美化会很好 - 欢迎提供帮助）
  • 固定宽度主题仅被少数用户使用，为了方便维护将被放弃
  • MWSearch 扩展不再维护，将被 https://www.mediawiki.org/wiki/Extension:CirrusSearch 代替
  • 因此，搜索后端将从 Lucene 切换到 ElasticSearch
  • “此页面已被访问 X 次”计数器不再是 MediaWiki 核心的一部分。它作为扩展提供，我们将安装它，因为计数器很酷 ;-)
  • 据报道，CategoryWatch 与新的 MediaWiki 版本不兼容。替代方案可能是 https://www.mediawiki.org/wiki/Manual:CategoryMembershipChanges（尚未测试）
• cboltz 已经开始在 home:cboltz:infra 中打包 MediaWiki 和一些扩展
• AI cboltz 在 atreju 上创建一个 MediaWiki 1.27.x 测试设置（包括 salt'ing 基本系统 - 欢迎提供帮助 ;-）
• 我们有很多过时的 wiki 页面需要更新
• 我们将创建一个“需要审核”类别，并使用 ReplaceText 标记_所有_页面。在审核页面时

a)

• • 如果需要，更新页面
  • 如果页面仅具有历史意义，则将其移动到 Archive: 命名空间
  • 删除完全多余的页面

b)

• • 删除“需要审核”类别
  • 对于版本特定的页面，添加一个“更新为 42.3”类别，作为 42.3 发布时要执行的任务列表（在为 42.3 更新这些页面后，将其移动到“更新为 43.1”类别）
  • 对于不需要定期更改的页面，添加一个“稳定内容”类别（确切的类别名称尚未决定）
• 页面模板应默认包含“需要审核”模板
• 这些类别将用作待办事项列表 - 在简单的情况下，通过查看类别页面，在更复杂的情况下（例如搜索未标记的页面），通过使用 DynamicPageList 的“notcategory”过滤器
• 旧版本和不太重要的门户不应在“热门门户”框中列出。这可以通过 a) 手动维护该框或 b) 将“重要”门户添加到特殊类别或 c) 将要隐藏的门户添加到特殊类别来完成
• Christoph 有时间预算来更新 wiki（除非有更重要的事情阻止他），但这并不意味着他可以独自完成
• 所有这些都可以立即开始 - 无需等待 wiki 更新