mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-23 21:20:42 +08:00
geekpi
GitHub
commit
7957dc54e7
@ -1,67 +0,0 @@
|
||||
[#]: subject: "3 things to know about planning for OTA updates in your homelab"
|
||||
[#]: via: "https://opensource.com/article/22/9/plan-ota-updates-edge"
|
||||
[#]: author: "Alan Smithee https://opensource.com/users/alansmithee"
|
||||
[#]: collector: "lkxed"
|
||||
[#]: translator: "geekpi"
|
||||
[#]: reviewer: " "
|
||||
[#]: publisher: " "
|
||||
[#]: url: " "
|
||||
|
||||
3 things to know about planning for OTA updates in your homelab
|
||||
======
|
||||
Define your over-the-air update plan for mobile phones, IoT devices, and edge computing before you even start coding your app.
|
||||
|
||||
![Why and how to handle exceptions in Python Flask][1]
|
||||
|
||||
Image from Unsplash.com, Creative Commons Zero
|
||||
|
||||
Updates to a system used to be relatively straightforward. When a developer needed to revise something that they'd already distributed to the public, an updater would be released for people to run. Users would run the updater, allowing old files to be replaced by new files and new files to be added. Even with these "relatively straightforward" updates, though, there was a catch. What happens when a user's installation is in an unexpected state? What happens when an upgrade is interrupted? These questions are just as relevant now when all kinds of devices are online, and sometimes in need of important security updates. Many updates today are delivered wirelessly, over-the-air (OTA), and the potential for poor connections, sudden loss of signal, or loss of power, can potentially be disastrous to what should be a minor update. These are the top three strategies you need to consider when planning to deliver over-the-air updates.
|
||||
|
||||
### 1. Verification
|
||||
|
||||
The TCP protocol has a lot of verification built in, so it's usually true that when you [send packets to a device][2], you can be confident that each packet has been received intact. However, TCP can't report errors on something it doesn't know about, so it's up to you to verify things like:
|
||||
|
||||
* Have you sent all files required for the update? A device can't receive what wasn't sent in the first place.
|
||||
* Are the files received the same as the files you sent? At the very least, check SHA sums to verify file integrity.
|
||||
* When possible, use [digital signing][3] to ensure that a file is from a trusted source.
|
||||
* You must verify that the device is able to apply an update before you allow the update to begin. Check permissions and battery state before committing to an update, and ensure that your update process overrides any unexpected user events, like a scheduled reboot or hibernation.
|
||||
* Finally, you must verify that an update that claims to have completed successfully has actually completed. Check file locations and integrity on the target device before allowing the update to officially be marked as resolved by the system.
|
||||
|
||||
### 2. Fallback and failstates
|
||||
|
||||
The worst-case scenario for an update is that a device is left in a broken state, such that it can't even be used to continue an aborted update. In that scenario, the updater files exist on the target device, but the process has been interrupted. This can leave a device in an unknown state, where some files have been replaced with updated versions, while others haven't been touched. In the worst case, files that have been updated are incompatible with files that haven't yet been updated, and so the device cannot function as expected.
|
||||
|
||||
There are a few strategies to handle this. The initial update step could be to install a special boot image or environment dedicated to completing the update, and setting a "flag" on the system to establish that an update is in progress. This ensures that even when a device suddenly loses power in the middle of an update, the update process is started fresh during the next boot. The flag signaling a successful update is removed only once the update has been verified.
|
||||
|
||||
A special boot image may not be feasible or necessary, depending on the security policy of the target device and what you're updating. The principle remains the same, though. Once it has been started, an update must establish an environment in which the pending update is the only way forward until it's resolved.
|
||||
|
||||
Up until an update has been granted permission to start, though, a user (when there is one) should have the ability to delay or ignore the update.
|
||||
|
||||
### 3. Additive
|
||||
|
||||
In many edge and IoT devices, the foundation of the target device is immutable. Updates only add to a known state of a system. Projects like [Fedora Silverblue][4] are demonstrating that this model can work across many markets, so that luxury might become commonplace. Until then, though, part of successfully applying an update is understanding the environment you're about to affect.
|
||||
|
||||
You don't need an immutable core to apply additive updates, though. You may be able to architect a system to use the same concept, using update as a way to add libraries or packages without revising the old versions. As the final step of such an update, the executable with updated paths is the only actual revision you make.
|
||||
|
||||
### OTA updates
|
||||
|
||||
The world is increasingly wireless. For mobile phones, IoT devices, and [edge computing][5], over-the-air updates are often the only option. Implementing an OTA update policy takes careful planning and careful accounting for improbable scenarios. You know your target devices best, so map out your update schema well before you begin coding so that your initial architecture is designed for robust and safe OTA.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/22/9/plan-ota-updates-edge
|
||||
|
||||
作者：[Alan Smithee][a]
|
||||
选题：[lkxed][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/alansmithee
|
||||
[b]: https://github.com/lkxed
|
||||
[1]: https://opensource.com/sites/default/files/lead-images/computer_code_programming_laptop.jpg
|
||||
[2]: https://www.redhat.com/sysadmin/beginners-guide-network-troubleshooting-linux
|
||||
[3]: https://www.redhat.com/sysadmin/digital-signatures-gnupg
|
||||
[4]: https://silverblue.fedoraproject.org
|
||||
[5]: https://www.redhat.com/en/topics/edge-computing/what-is-edge-computing?intcmp=7013a000002qLH8AAM
|
||||
@ -0,0 +1,67 @@
|
||||
[#]: subject: "3 things to know about planning for OTA updates in your homelab"
|
||||
[#]: via: "https://opensource.com/article/22/9/plan-ota-updates-edge"
|
||||
[#]: author: "Alan Smithee https://opensource.com/users/alansmithee"
|
||||
[#]: collector: "lkxed"
|
||||
[#]: translator: "geekpi"
|
||||
[#]: reviewer: " "
|
||||
[#]: publisher: " "
|
||||
[#]: url: " "
|
||||
|
||||
在家庭实验室中规划 OTA 更新需要了解的 3 件事
|
||||
======
|
||||
在开始编写应用之前，为手机、物联网设备和边缘计算定义无线更新计划。
|
||||
|
||||
![Why and how to handle exceptions in Python Flask][1]
|
||||
|
||||
图片来自 Unsplash.com，CC0 协议
|
||||
|
||||
过去对系统的更新相对简单。当开发人员需要修改他们已经分发给公众的东西时，会发布一个更新程序供人们运行。用户将运行更新程序，允许用新文件替换旧文件并添加新文件。然而，即使有了这些“相对简单”的更新，也有一个问题。当用户的安装处于意外状态时会发生什么？升级中断时会发生什么？当各种设备都在线时，这些问题同样重要，有时需要重要的安全更新。今天的许多更新都是通过无线、空中下载技术 (OTA) 的方式提供的，连接不良、信号突然丢失或断电的可能性可能会对应该是次要更新的内容造成灾难性的影响。这些是你在计划提供 OTA 更新时需要考虑的三大策略。
|
||||
|
||||
### 1. 验证
|
||||
|
||||
TCP 协议内置了很多验证功能，因此当你[向设备发送数据包][2]时，通常可以确信每个数据包都已完好无损地收到。但是，TCP 无法报告它不知道的错误，因此由你来验证以下内容：
|
||||
|
||||
* 你是否已发送更新所需的所有文件？设备无法接收最初未发送的内容。
|
||||
* 收到的文件和你发送的文件一样吗？至少，检查 SHA 和以验证文件完整性。
|
||||
* 如果可能，请使用[数字签名][3]确保文件来自受信任的来源。
|
||||
* 在允许更新开始之前，你必须验证设备能够应用更新。在提交更新之前检查权限和电池状态，并确保你的更新过程覆盖任何意外的用户事件，例如计划的重新启动或休眠。
|
||||
* 最后，你必须验证声称已成功完成的更新是否已实际完成。在将更新正式标记为系统已完成之前，请检查目标设备上的文件位置和完整性。
|
||||
|
||||
### 2. 回退和故障状态
|
||||
|
||||
更新的最坏情况是设备处于损坏状态，以至于它甚至不能继续中止的更新。在这种情况下，更新程序文件存在于目标设备上，但该过程已被中断。这可能会使设备处于未知状态，其中一些文件已被更新版本替换，而其他文件尚未被触及。在最坏的情况下，已更新的文件与尚未更新的文件不兼容，因此设备无法按预期运行。
|
||||
|
||||
有一些策略可以解决这个问题。初始更新步骤可能是安装专用于完成更新的特殊引导镜像或环境，并在系统上设置“标志”以确认更新正在进行中。这样可以确保即使设备在更新过程中突然断电，更新过程也会在下次启动时重新启动。仅在验证更新后才删除表示更新成功的标志。
|
||||
|
||||
根据目标设备的安全策略和你要更新的内容，特殊的引导镜像可能不可行或不需要。不过，原理还是一样的。当启动后，更新必须建立一个环境，在这个环境中，待处理的更新是解决问题之前的唯一途径
|
||||
|
||||
但是，在更新被授予启动权限之前，用户（如果有的话）应该能够延迟或忽略更新。
|
||||
|
||||
### 3. 附加更新
|
||||
|
||||
在许多边缘和物联网设备中，目标设备的底层是不可变的。更新只会添加到系统的已知状态。 [Fedora Silverblue][4] 之类的项目正在证明这种模式可以在许多市场上发挥作用，因此这种奢侈可能会变得司空见惯。不过，在那之前，成功应用更新的一部分是了解你将要影响的环境。
|
||||
|
||||
不过，你不需要不可变的核心来应用附加更新。你可以构建一个使用相同的概念的系统，将更新作为添加库或包的一种方式，而无需修改旧版本。作为此类更新的最后一步，具有更新路径的可执行文件是你所做的唯一实际修订。
|
||||
|
||||
### OTA 更新
|
||||
|
||||
世界越来越无线化。对于手机、物联网设备和[边缘计算][5]，OTA 更新通常是唯一的选择。实施 OTA 更新策略需要仔细规划并仔细考虑不可能的情况。你最了解您的目标设备，因此请在开始编码之前规划好你的更新架构
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/22/9/plan-ota-updates-edge
|
||||
|
||||
作者：[Alan Smithee][a]
|
||||
选题：[lkxed][b]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/alansmithee
|
||||
[b]: https://github.com/lkxed
|
||||
[1]: https://opensource.com/sites/default/files/lead-images/computer_code_programming_laptop.jpg
|
||||
[2]: https://www.redhat.com/sysadmin/beginners-guide-network-troubleshooting-linux
|
||||
[3]: https://www.redhat.com/sysadmin/digital-signatures-gnupg
|
||||
[4]: https://silverblue.fedoraproject.org
|
||||
[5]: https://www.redhat.com/en/topics/edge-computing/what-is-edge-computing?intcmp=7013a000002qLH8AAM
|
||||
Loading…
Reference in New Issue
Block a user