遠端伺服器上的OpenWrt配置

Question 1

你問： ”遠端伺服器上的 OpenWrt 配置：有解決方案嗎？」

我每天都要處理超過 80 個 OpenWRT 盒子（三個硬體平台，混合運行 Backfire（一些）、Attitude Adjustment（大多數）和 Barrier Braker（一些）），並且......去年我開始搜索深關於適合 OpenWRT 的「組態管理」平台。

下面是我的發現：

開放WISP: 在我看來，這是非常有前途的。他們建立了一個「自訂」韌體（只不過是添加了一些 bash 腳本和已安裝軟體包的自訂清單的「庫存」韌體），一旦刷新，只需「連接」（透過 OpenVPN 用戶端）到中央伺服器並下載配置以在本地應用。還有一個很好的網路介面，您可以透過它輕鬆地「部署」新的存取點。不幸的是，它並不完美：例如，可以定義和應用“模板”（配置），但是......之後，模板中的更改將不是被推送到子 AP。另外，整個管理軟體堆疊是用 Ruby（和 Rails）編寫的，並且...如果您不「掌握」這些語言/平台，這可能是一個問題。當我們測試它時，它是基於 Backfire 的。現在，如果我是對的，它也可以用於更新版本（態度或障礙，我不記得了）。另外，網站肯定沒有太多更新，所以...請參閱 GitHub 儲存庫以獲取詳細資訊。簡而言之：絕對值得一看。
科幻：巴西大學開發的平台（據我了解...文件好像是巴西的）這看起來很有趣。它有點舊（幾年了），但看起來又很有趣。管理平台是JavaEE（JBoss），後端是PostgreSQL。如果我是對的，它應該能夠在庫存韌體之上採用
航空鑰匙：他們宣稱自己：「AirKey 是基於 OpenWRT 的存取點的中央管理平台。「。我沒有調查太多，因為它沒有太多更新（最後一次更新，4年前！）
營運商WRT，而且，即使與中央管理不嚴格相關，也可能會引起一些興趣。據我所知，這裡的阻礙因素之一是支援的硬體有限（但是，請檢查一下自己）。

如你所說： ”我不打算重新發明輪子（除非輪子實際上沒有發明）”，您可能會想自己構建一些東西。在這種情況下，請考慮：

OpenWRT 支援JSON-RPC API透過它，您可以使用 JSON 和 REST 輕鬆地與 UCI 互動。如果你掌握了這些技術，這可能會很有趣。讓我補充一點，我嘗試（輕微地）做一些事情，但是......在BackFire 之後似乎發生了一些變化，而且——如果我是對的——與BackFire 一起工作的東西不會與AA 和BB 一起工作（再次檢查你自己））。

在這一切之後，我最終決定......是時候切換到「官方」組態管理平台了，至於 OpenWRT 平台的典型約束，我的選擇是安西布爾因為它可以在 SSH 之上運行並且沒有其他嚴重的依賴性。已經為此類場景構建了一些東西（檢查這裡和這裡）但我仍然需要測試它。

所以我同意@Michael Hampton 的評論“Ansible 非常接近理想的狀況在我看來，這應該是首先要評估的事情，因為畢竟，你真的可以將你的單一 OpenWRT 盒子視為一個通用的 Linux 系統，並使用「通用」組態管理引擎進行管理。

Answer

你問： ”遠端伺服器上的 OpenWrt 配置：有解決方案嗎？」

我每天都要處理超過 80 個 OpenWRT 盒子（三個硬體平台，混合運行 Backfire（一些）、Attitude Adjustment（大多數）和 Barrier Braker（一些）），並且......去年我開始搜索深關於適合 OpenWRT 的「組態管理」平台。

下面是我的發現：

開放WISP: 在我看來，這是非常有前途的。他們建立了一個「自訂」韌體（只不過是添加了一些 bash 腳本和已安裝軟體包的自訂清單的「庫存」韌體），一旦刷新，只需「連接」（透過 OpenVPN 用戶端）到中央伺服器並下載配置以在本地應用。還有一個很好的網路介面，您可以透過它輕鬆地「部署」新的存取點。不幸的是，它並不完美：例如，可以定義和應用“模板”（配置），但是......之後，模板中的更改將不是被推送到子 AP。另外，整個管理軟體堆疊是用 Ruby（和 Rails）編寫的，並且...如果您不「掌握」這些語言/平台，這可能是一個問題。當我們測試它時，它是基於 Backfire 的。現在，如果我是對的，它也可以用於更新版本（態度或障礙，我不記得了）。另外，網站肯定沒有太多更新，所以...請參閱 GitHub 儲存庫以獲取詳細資訊。簡而言之：絕對值得一看。
科幻：巴西大學開發的平台（據我了解...文件好像是巴西的）這看起來很有趣。它有點舊（幾年了），但看起來又很有趣。管理平台是JavaEE（JBoss），後端是PostgreSQL。如果我是對的，它應該能夠在庫存韌體之上採用
航空鑰匙：他們宣稱自己：「AirKey 是基於 OpenWRT 的存取點的中央管理平台。「。我沒有調查太多，因為它沒有太多更新（最後一次更新，4年前！）
營運商WRT，而且，即使與中央管理不嚴格相關，也可能會引起一些興趣。據我所知，這裡的阻礙因素之一是支援的硬體有限（但是，請檢查一下自己）。

如你所說： ”我不打算重新發明輪子（除非輪子實際上沒有發明）”，您可能會想自己構建一些東西。在這種情況下，請考慮：

OpenWRT 支援JSON-RPC API透過它，您可以使用 JSON 和 REST 輕鬆地與 UCI 互動。如果你掌握了這些技術，這可能會很有趣。讓我補充一點，我嘗試（輕微地）做一些事情，但是......在BackFire 之後似乎發生了一些變化，而且——如果我是對的——與BackFire 一起工作的東西不會與AA 和BB 一起工作（再次檢查你自己））。

在這一切之後，我最終決定......是時候切換到「官方」組態管理平台了，至於 OpenWRT 平台的典型約束，我的選擇是安西布爾因為它可以在 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