远程服务器上的OpenWrt配置

Question 1

你问： ”远程服务器上的 OpenWrt 配置：有解决方案吗？“

我每天都要处理 80 多个 OpenWRT 盒子（三个硬件平台，运行 Backfire（一些）、Attitude Adjustment（大多数）和 Barrier Braker（一些）的混合体）并且......去年我开始寻找深关于适合OpenWRT的“配置管理”平台。

以下是我的发现：

开放WISP：在我看来，它很有前途。他们已经构建了一个“自定义”固件（只不过是“库存”固件，添加了一些 bash 脚本和一个已安装软件包的自定义列表），一旦刷新，只需“连接”（通过 OpenVPN 客户端）到中央服务器并下载配置以在本地应用。还有一个不错的 Web 界面，您可以通过它轻松“部署”新的 AP。不幸的是，它并不完美：例如，“模板”（配置）可以定义和应用，但……之后，模板中的更改将不是推送到子 AP。此外，整个管理软件堆栈都是用 Ruby（和 Rails）编写的，如果您不“掌握”这些语言/平台，这可能会成为问题。当我们测试它时，它基于 Backfire。现在，如果我没记错的话，它也可以用于更新版本（Attitude 或 Barrier，我不记得了）。此外，该网站肯定没有太多更新，所以...请参阅 GitHub 存储库以获取详细信息。简而言之：它绝对值得一看。
科幻：由巴西大学开发的平台（据我所知......文档看起来是巴西的），这似乎很有趣。它有点旧了（几年了），但同样看起来很有趣。管理平台是 JavaEE（JBoss），以 PostgreSQL 为后端。如果我没记错的话，它应该能够在库存固件之上采用
空气钥匙：他们宣称：“AirKey 是一个基于 OpenWRT 的接入点的中央管理平台。“。我没有进行深入调查，因为它没有太多更新（上次更新是 4 年前！）
运营商WRT，即使与中央管理没有严格关系，也可能引起一些兴趣。据我记得，其中一个问题是支持的硬件有限（但请自己检查一下）。

如你所说： ”我不打算重新发明轮子（除非轮子实际上没有被发明）“，您可能会想自己构建一些东西。在这种情况下，请考虑以下几点：

OpenWRT 支持JSON-RPC API通过它，您可以使用 JSON 和 REST 轻松与 UCI 交互。如果您掌握了这些技术，这可能会很有趣。让我补充一下，我尝试（稍微）做了一些事情，但是……似乎在 BackFire 之后发生了一些变化，如果我是对的，那么适用于 BackFire 的方法将不适用于 AA 和 BB（再次检查自己）。

经过这一切，我最终决定......是时候切换到“官方”配置管理平台了，至于OpenWRT平台的典型限制，我的选择是Ansible因为它可以在 SSH 上运行，并且没有其他严重的依赖关系。已经为此类场景构建了一些内容（检查这里和这里），但我还得测试一下。

所以我同意@Michael Hampton的评论“Ansible 非常接近理想状态“在我看来，这应该是首先要评估的事情，毕竟，您真的可以将单个 OpenWRT 盒视为一个通用的 Linux 系统，并使用“通用”配置管理引擎进行管理。

Answer

你问： ”远程服务器上的 OpenWrt 配置：有解决方案吗？“

我每天都要处理 80 多个 OpenWRT 盒子（三个硬件平台，运行 Backfire（一些）、Attitude Adjustment（大多数）和 Barrier Braker（一些）的混合体）并且......去年我开始寻找深关于适合OpenWRT的“配置管理”平台。

以下是我的发现：

开放WISP：在我看来，它很有前途。他们已经构建了一个“自定义”固件（只不过是“库存”固件，添加了一些 bash 脚本和一个已安装软件包的自定义列表），一旦刷新，只需“连接”（通过 OpenVPN 客户端）到中央服务器并下载配置以在本地应用。还有一个不错的 Web 界面，您可以通过它轻松“部署”新的 AP。不幸的是，它并不完美：例如，“模板”（配置）可以定义和应用，但……之后，模板中的更改将不是推送到子 AP。此外，整个管理软件堆栈都是用 Ruby（和 Rails）编写的，如果您不“掌握”这些语言/平台，这可能会成为问题。当我们测试它时，它基于 Backfire。现在，如果我没记错的话，它也可以用于更新版本（Attitude 或 Barrier，我不记得了）。此外，该网站肯定没有太多更新，所以...请参阅 GitHub 存储库以获取详细信息。简而言之：它绝对值得一看。
科幻：由巴西大学开发的平台（据我所知......文档看起来是巴西的），这似乎很有趣。它有点旧了（几年了），但同样看起来很有趣。管理平台是 JavaEE（JBoss），以 PostgreSQL 为后端。如果我没记错的话，它应该能够在库存固件之上采用
空气钥匙：他们宣称：“AirKey 是一个基于 OpenWRT 的接入点的中央管理平台。“。我没有进行深入调查，因为它没有太多更新（上次更新是 4 年前！）
运营商WRT，即使与中央管理没有严格关系，也可能引起一些兴趣。据我记得，其中一个问题是支持的硬件有限（但请自己检查一下）。

如你所说： ”我不打算重新发明轮子（除非轮子实际上没有被发明）“，您可能会想自己构建一些东西。在这种情况下，请考虑以下几点：

OpenWRT 支持JSON-RPC API通过它，您可以使用 JSON 和 REST 轻松与 UCI 交互。如果您掌握了这些技术，这可能会很有趣。让我补充一下，我尝试（稍微）做了一些事情，但是……似乎在 BackFire 之后发生了一些变化，如果我是对的，那么适用于 BackFire 的方法将不适用于 AA 和 BB（再次检查自己）。

经过这一切，我最终决定......是时候切换到“官方”配置管理平台了，至于OpenWRT平台的典型限制，我的选择是Ansible因为它可以在 SSH 上运行，并且没有其他严重的依赖关系。已经为此类场景构建了一些内容（检查这里和这里），但我还得测试一下。

所以我同意@Michael Hampton的评论“Ansible 非常接近理想状态“在我看来，这应该是首先要评估的事情，毕竟，您真的可以将单个 OpenWRT 盒视为一个通用的 Linux 系统，并使用“通用”配置管理引擎进行管理。

Question 2

关于OpenWISP，现在有一个新的管理软件，不是Ruby依赖的，安装非常简单：OpenWISP 2 控制器

你也可以将其集成到你现有的 django 项目中通过扩展其主模块：django-netjsonconfig。

另外，您不需要为您的路由器编译新的 openwisp 固件，您只需安装配置组件，使您当前的 openwrt 安装由管理器配置：openwisp-配置。

例如，您可以通过发出以下命令来安装该组件：

opkg install http://downloads.openwisp.org/openwisp-config/latest/ar71xx/openwisp-config-nossl_0.4.1a-1_ar71xx.ipk

问候！

卡西欧

Answer