networkupstools/nut
GitHub: networkupstools/nut
一个用于统一监控和管理 UPS、PDU 等电源硬件的开源工具集,提供断电自动安全关机和远程电源控制能力。
Stars: 4176 | Forks: 445
# Network UPS Tools 概述
// NOTE: No blank line here, document-header include processing should kick in!
//GH_MARKUP_1095//ifdef::top_srcdir[]
//GH_MARKUP_1095//include::{top_srcdir}docs/asciidoc-vars.conf[]
//GH_MARKUP_1095//endif::top_srcdir[]
//GH_MARKUP_1095//ifndef::top_srcdir[]
//GH_MARKUP_1095//include::docs/asciidoc-vars.conf[]
//GH_MARKUP_1095//endif::top_srcdir[]
//GH_MARKUP_1095_INCLUDE_BEGIN//a6bd83d48 (2025-03-20) docs/asciidoc-vars.conf: document that linkdoc may have further args
ifndef::asciidoc-vars-nut-included[]
:asciidoc-vars-nut-included: true
// NOTE: The big block of comments and definitions below comes from
// NUT::docs/asciidoc-vars.conf and is included into top-level document
// sources by maintenance recipes directly (`make maintainer-asciidocs`),
// due to current limitations of the GitHub Web UI asciidoc renderer.
// Hopefully it can be dropped in favor of compact include definitions
// (see README.adoc for anticipated example) after this issue is resolved
// on their side:
// * https://github.com/github/markup/issues/1095
//
// This file should be included into NUT documentation sources to consistently
// define certain expandable attributes, with contents defined based on the
// rendition target (e.g. GitHub Web UI, plain text, locally built HTML/PDF...)
// Note that currently GitHub Web UI references lead to nut-website (as of
// last built and published revision), not to neighboring documents in the
// source browser (which would make sense for branch revisions, etc.) due
// to certain complexity about referencing other-document sections with a
// partially functional rendering engine there. Exploration and fixes are
// welcome (actually working links like
// https://github.com/networkupstools/nut/tree/master#installing or
// https://github.com/networkupstools/nut/blob/master/UPGRADING.adoc#changes-from-274-to-280
// do seem promising)!
//
// Since the GitHub UI does not allow use of custom asciidoc configuration
// files, or generally does not process the `include:` requests at this time,
// clumsy expandable attributes had to be used (usually a set including a
// prefix with meaningful name, and one or more separators and/or a suffix
// with shortened names). For our classic documentation renditions, they
// should resolve to properly defined macros from `docs/asciidoc.conf`
// (usually named same as the variables defined here, for simplicity):
// * `linksrcdoc` allows to refer to a source of documentation file
// relative to the root of NUT code base.
// * `linkdoc` allows to refer to a file under `docs/` directory (or
// its nut-website rendition).
// * `xref` substitutes the asciidoc shorthand '<< >>' syntax with
// attributes that conditionally expand to:
// - links on GitHub (references can point at most to a section of
// level docs/common.xsl's ), or
// - xref asciidoc macros when generating docs.
// * `linksingledoc` guarantees that, when chunked HTML is generated,
// the link always points to a non-chunked file.
// * `linkman2` allows to support different names for the manpage and
// the command shown. This is also needed to properly display links
// to manpages in both GitHub and generated docs without defining an
// attribute for each manpage.
// * `linkmanext` and `linkmanext2` macros repeat the behavior of the default ones.
// These macros are intended for system man pages (e.g. HTML links might lead
// to a generic internet site, or possibly to a distro-provided library
// online or locally).
//
// Optional attributes set by callers:
// * `website-url` (defaulted below) may be used for "historic website"
// snapshot builds... hopefully
// * `website` is used as a boolean toggle in our recipes for nut-website
// vs. offline documentation renditions
// * `env-github` is used as a boolean toggle, set by GitHub Web-UI renderer
// * `(top_)srcdir` and `(top_)builddir` can be set by `Makefile.am`
// calling the `a2x` tool, since some of the files with the asciidoc
// mark-up are only generated or post-processed during build and
// (due to `make dist` restrictions) being build products, they may
// not reside in same directory as static source text files which
// reference or include them. Note that the non-`top` paths would
// normally differ based on location of the `Makefile` involved
// (e.g. workspace root, or the `docs`, or `docs/man` directories).
// These variables are expected to be absolute paths, or ones relative
// to asciidoc-selected `:base_dir`, and to end with a relevant path
// separator, or be empty -- so in all cases letting the resulting
// string resolve meaningfully in the filesystem during docs build.
//
// Please keep the remaining comments and definitions as one big block
// so it does not become a series of empty paragraphs in the rendered
// documents!
//
ifndef::website-url[]
:website-url: https://www.networkupstools.org/
endif::website-url[]
//
ifndef::srcdir[]
:srcdir:
endif::srcdir[]
//
ifndef::builddir[]
:builddir:
endif::builddir[]
//
ifndef::top_srcdir[]
:top_srcdir:
endif::top_srcdir[]
//
ifndef::top_builddir[]
:top_builddir:
endif::top_builddir[]
//
//
// Address links on GitHub vs. docs
// (note: 'env-github' attribute is set on GitHub)
//
// - when generating docs:
ifndef::env-github[]
// * xref -> xref
// syntax: {xref}{x-s}[]
// -> xref:[]
:xref: xref:
:x-s:
// * link to doc -> our macro
// syntax: {linksrcdoc}
// -> linksrcdoc:[]
:linksrcdoc: linksrcdoc:
// * link to doc -> our macro (optional 2/3/4 args)
// syntax: {linkdoc}{ld-s}[{,{,{,}}}]
// -> linkdoc:[{,{,{,}}}]
:linkdoc: linkdoc:
:ld-s:
// * link to single doc -> our macro
// syntax: {linksingledoc}{lsd-s}[]
// -> linksingledoc:[]
:linksingledoc: linksingledoc:
:lsd-s:
// * link to manpage -> our macro
// syntax: {linkman2}{lm-s}{lm-c}{lm-e}
// -> linkman2:[,]
:linkman2: linkman2:
:lm-s: [
:lm-c: ,
:lm-e: ]
:linkmanext: https://www.die.net/search/?q=
:linkmanext2: https://www.die.net/search/?q=
endif::env-github[]
//
// - on GitHub:
ifdef::env-github[]
// In our normal builds, Makefile variables convey the needed paths
// (used relatively below as `image:images/ci/...png` etc.)
:imagesdir: docs
// * xref -> link
// syntax: {xref}{x-s}[]
// In order for it to work, can reference at most a section of
// level docs/common.xsl's
// -> {website-url}docs/user-manual.chunked/.html[]
:xref: {website-url}docs/user-manual.chunked/
:x-s: .html
// * link to doc -> our macro
// syntax: {linksrcdoc}
// -> link:[]
:linksrcdoc: link:{top_srcdir}/
// * link to doc -> link (FIXME: ignore or use 2/3/4 args; currently they are all pasted as contents!)
// syntax: {linkdoc}{ld-s}[{,{,{,}}}]
// -> {website-url}docs/.chunked/index.html[]
:linkdoc: {website-url}docs/
:ld-s: .chunked/index.html
// * link to single doc -> link
// syntax: {linksingledoc}{lsd-s}[]
// -> {website-url}docs/.html[]
:linksingledoc: {website-url}docs/
:lsd-s: .html
// * link to manpage -> link
// syntax: {linkman2}{lm-s}{lm-c}{lm-e}
// All the fields are mandatory.
// -> {website-url}docs/man/.html[()]
:linkman2: {website-url}docs/man/
:lm-s: .html[
:lm-c: (
:lm-e: )]
:linkmanext: https://www.die.net/search/?q=
:linkmanext2: https://www.die.net/search/?q=
endif::env-github[]
endif::asciidoc-vars-nut-included[]
//
//GH_MARKUP_1095_INCLUDE_END//
## 描述
Network UPS Tools 是一个程序集合,为监控和管理 UPS、PDU 和 SCD 硬件提供通用接口。
它使用分层的方式将所有部分连接起来。
系统为各种设备提供了驱动程序。它们理解每个设备的特定语言,并将其映射回兼容层。这意味着无论是昂贵的高端 UPS、简单的“排插” PDU,还是任何其他电源设备,都可以通过统一的管理接口透明地进行处理。
这些信息由网络服务器 `upsd` 缓存,随后由它回答来自客户端的查询。`upsd` 包含许多访问控制功能,以限制客户端的能力。只要您愿意,就可以做到只允许经过授权的主机监控或控制您的硬件。由于通过网络进行监控的概念已内置于软件中,您可以将许多系统连接到一台大型 UPS 上,并且它们都会一起关闭。您还可以使用 NUT 通过 PDU 插座,单独或全局地为您的数据中心节点上电、断电或执行电源循环。
诸如 `upsmon` 之类的客户端会检查硬件的状态,并在必要时执行操作。最重要的任务是在 UPS 耗尽电力之前干净地关闭操作系统。此外,还提供了其他程序,用于定期记录信息、通过 Web 浏览器监控状态等等。
## NUT 与生态系统
NUT 已经为许多操作系统提供了预打包版本,并嵌入到存储、自动化或虚拟化设备中,此外还经常被几家 UPS 供应商作为软件伴侣发布。当然,自行构建也是非常正常且受支持的——无论是对于尚缺此软件的操作系统,还是对于缺少当前 NUT 版本的旧发行版;无论是为了利用新功能,还是为了在手中握有调试器的情况下排查新 UPS 部署的问题。
鉴于其在系统生命周期核心的关键地位,我们始终致力于让当前的 NUT 能够在任何地方构建和运行,尤其是在以前旧版本曾经成功运行过的地方(包括千禧年之交的服务器和操作系统等“弃件”):如果这些机器仍然在使用并且需要电源保护,它们就应该能够得到它。
# [提示]
ifndef::pdf_format[]
image:https://api.star-history.com/svg?repos=networkupstools/nut&type=Date[link="https://star-history.com/#networkupstools/nut&Date" alt="NUT GitHub Star History Chart"]
endif::pdf_format[]
您应该阅读
{xref}outlet_management{x-s}[NUT 插座管理和 PDU 说明]
章节,以了解有关何时使用此功能的更多信息。
## 网络服务器
`upsd` 负责通过网络将数据从驱动程序传递给客户端程序。它应该在您的系统启动脚本中,于 `upsdrvctl` 之后立即运行。
应尽可能保持 `upsd` 一直运行,因为它是诸如 `upsmon` 等监控客户端获取状态信息的唯一来源。
## 监控客户端
`upsmon` 提供了您期望在 UPS 监控软件中找到的基本功能:在电时安全关机。
在 NUT 软件的分层方案中,它是一个客户端。由于它非常重要,因此它在文档中拥有单独的章节。
您需要在 upsmon.conf 中配置它,告诉它您想要监控哪些 UPS。每台 UPS 可以定义为两种可能的类型之一:“主”或“从”。
Primary
```
The monitored UPS possibly supplies power to this system running `upsmon`,
but more importantly -- this system can manage the UPS (typically, this
instance of `upsmon` runs on the same system as the `upsd` and driver(s)):
it is capable and responsible for shutting it down when the battery is
depleted (or in another approach, lingering to deplete it or to tell the
UPS to reboot its load after too much time has elapsed and this system
is still alive -- meaning wall power returned at a "wrong" moment).
The shutdown of this (primary) system itself, as well as eventually an
UPS shutdown, occurs after any secondary systems ordered to shut down
first have disconnected, or a critical urgency threshold was passed.
If your UPS is plugged directly into a system's serial or USB port, the
`upsmon` process on that system should define its relation to that UPS
as a primary. It may be more complicated for higher-end UPSes with a
shared network management capability (typically via SNMP) or several
serial/USB ports that can be used simultaneously, and depends on what
vendors and drivers implement. Setups with several competing primaries
(for redundancy) are technically possible, if each one runs its own
full stack of NUT, but results can be random (currently NUT does not
provide a way to coordinate several entities managing the same device).
For a typical home user, there's one computer connected to one UPS.
That means you would run on the same computer the whole NUT stack --
a suitable driver, `upsd`, and `upsmon` in primary mode.
Secondary
```
被监控的 UPS 可能为运行 `upsmon` 的系统供电(或者,它可能是一个零 PSU 且由该 UPS 供电的监控站),但更重要的是,该系统无法管理该 UPS —— 例如,直接将其关闭(通过本地运行的 NUT 驱动程序)。
当您在同一个 UPS 上运行多台计算机时,请使用此模式。
显然,在典型的 UPS 上,只能有一台计算机连接到串口或 USB 端口,而该系统就是 primary。其他的一切都是 secondary。
对于典型的家庭用户,只有一台计算机连接到一台 UPS。这意味着您需要以 primary 模式运行驱动程序、`upsd` 和 `upsmon`。
附加信息
```
More information on configuring upsmon can be found in these places:
- The {linkman2}upsmon{lm-s}upsmon{lm-c}8{lm-e} man page
- {xref}BigServers{x-s}[Typical setups for big servers]
- {xref}UPS_shutdown{x-s}[Configuring automatic UPS shutdowns] chapter
- The stock `upsmon.conf` that comes with the package
Clients
-------
Clients talk to upsd over the network and do useful things with the data
from the drivers. There are tools for command line access, and a few
special clients which can be run through your web server as CGI
programs.
For more details on specific programs, refer to their man pages.
upsc
~~~~
`upsc` is a simple client that will display the values of variables known
to `upsd` and your UPS drivers. It will list every variable by default,
or just one if you specify an additional argument. This can be useful
in shell scripts for monitoring something without writing your own
network code.
`upsc` is a quick way to find out if your driver(s) and upsd are working
together properly. Just run `upsc ` to see what's going on, i.e.:
morbo:~$ upsc sparky@localhost
ambient.humidity: 035.6
ambient.humidity.alarm.maximum: NO,NO
ambient.humidity.alarm.minimum: NO,NO
ambient.temperature: 25.14
...
If you are interested in writing a simple client that monitors `upsd`,
the source code for `upsc` is a good way to learn about using the
upsclient functions.
See the {linkman2}upsc{lm-s}upsc{lm-c}8{lm-e} man page and
{xref}nut-names{x-s}[NUT command and variable naming scheme] for more information.
upslog
~~~~~~
`upslog` will write status information from `upsd` to a file at set
intervals. You can use this to generate graphs or reports with other
programs such as `gnuplot`.
upsrw
~~~~~
`upsrw` allows you to display and change the read/write variables in your
UPS hardware. Not all devices or drivers implement this, so this may
not have any effect on your system.
A driver that supports read/write variables will give results like this:
----
$ upsrw sparky@localhost
( many skipped )
[ups.test.interval]
Interval between self tests
Type: ENUM
Option: "1209600"
Option: "604800" SELECTED
Option: "0"
( more skipped )
----
On the other hand, one that doesn't support them won't print anything:
----
$ upsrw fenton@gearbox
( nothing )
----
`upsrw` requires administrator powers to change settings in the hardware.
Refer to {linkman2}upsd.users{lm-s}upsd.users{lm-c}5{lm-e} for information on defining
users in `upsd`.
upscmd
~~~~~~
Some UPS hardware and drivers support the notion of an instant command -
a feature such as starting a battery test, or powering off the load.
You can use upscmd to list or invoke instant commands if your
hardware/drivers support them.
Use the -l command to list them, like this:
----
$ upscmd -l sparky@localhost
Instant commands supported on UPS [sparky@localhost]:
load.on - Turn on the load immediately
test.panel.start - Start testing the UPS panel
calibrate.start - Start run time calibration
calibrate.stop - Stop run time calibration
...
----
`upscmd` requires administrator powers to start instant commands.
To define users and passwords in `upsd`, see
{linkman2}upsd.users{lm-s}upsd.users{lm-c}5{lm-e}.
CGI Programs
------------
The CGI programs are clients that run through your web server. They
allow you to see UPS status and perform certain administrative commands
from any web browser. Javascript and cookies are not required.
These programs are not installed or compiled by default. To compile
and install them, first run `configure --with-cgi`, then do `make` and
`make install`. If you receive errors about "gd" during configure, go
get it and install it before continuing.
You can get the source here:
- http://www.libgd.org/
In the event that you need libpng or zlib in order to compile gd,
they can be found at these URLs:
- http://www.libpng.org/pub/png/pngcode.html
- http://www.zlib.net/
Access Restrictions
~~~~~~~~~~~~~~~~~~~
The CGI programs use hosts.conf to see if they are allowed to talk to a
host. This keeps malicious visitors from creating queries from your web
server to random hosts on the Internet.
If you get error messages that say "Access to that host is not
authorized", you're probably missing an entry in your hosts.conf.
upsstats
~~~~~~~~
`upsstats` generates web pages from HTML templates, and plugs in status
information in the right places. It looks like a distant relative of
APC's old Powerchute interface. You can use it to monitor several
systems or just focus on one.
It also can generate IMG references to `upsimage`.
upsimage
~~~~~~~~
This is usually called by upsstats via IMG SRC tags to draw either the
utility or outgoing voltage, battery charge percent, or load percent.
upsset
~~~~~~
`upsset` provides several useful administration functions through a web
interface. You can use `upsset` to kick off instant commands on your UPS
hardware like running a battery test. You can also use it to change
variables in your UPS that accept user-specified values.
Essentially, `upsset` provides the functions of `upsrw` and `upscmd`, but
with a happy pointy-clicky interface.
`upsset` will not run until you convince it that you have secured your
system. You *must* secure your CGI path so that random interlopers
can't run this program remotely. See the `upsset.conf` file. Once you
have secured the directory, you can enable this program in that
configuration file. It is not active by default.
Version Numbering
-----------------
The version numbers historically worked like this: if the middle number
is odd, it's a development tree, otherwise it is the stable tree.
The past stable trees were 1.0, 1.2, 1.4, 2.0, 2.2 and 2.4, with the
latest such stable tree designated 2.6. The development trees were 1.1,
1.3, 1.5, 2.1 and 2.3. Since the 2.4 release, there is no real separate
development branch anymore since the code is available through a revision
control system (namely, Git -- or actually Subversion back then), development
happens in feature branches that are eventually merged into the main trunk,
and its snapshots become published releases. As a result, subsequent versions
(2.7 and 2.8) were released without regard for even/odd values of the minor
version component.
Since 2.7 line of releases, sources are tracked in Git revision control
system, with the project ecosystem being hosted on GitHub, and any code
improvements or other contributions merged through common pull request
approach and custom NUT CI testing on multiple platforms.
Major release jumps are mostly due to large changes to the features
list. There have also been a number of architectural changes which
may not be noticeable to most users, but which can impact developers.
Since NUT v2.8.2 or so, development iterations have additional version
components, to account for the amount of commits on the main branch
(`master`) since the last known Git tag, and amount of commits on the
developed feature branch that are unique to it compared to main branch.
This allows for a reasonably growing version of stable baseline and
local development, so that experimental packages can be installed as
upgrades (or well-exposed downgrades).
While the NUT releases retain the semantic versioning three-component
standard, interim builds (trunk snapshots and development branches)
can expose a much more complex structure with the amount of commits
in the trunk since last release, and amount of commits on the branch
unique to it (not in the trunk). Additional data may include overall
amount of commits in the current build since last release, and the
git commit has identifier of the built code base.
More details can be seen in `docs/nut-versioning.adoc` file in the
NUT source code base.
Backwards and Forwards Compatibility
------------------------------------
The network protocol for the current version of NUT should be
backwards-compatible all the way back to version 1.4. A newer client should
fail gracefully when querying an older server.
If you need more details about cross-compatibility of older NUT releases
(1.x vs. 2.x), please see the {xref}Project_History{x-s}[Project history] chapter.
Support / Help / etc.
---------------------
If you are in need of help, refer to the
{xref}Support_Request{x-s}[Support instructions] in the user manual.
Hacking / Development Info
--------------------------
Additional documentation can be found in:
- the {linkdoc}developer-guide{ld-s}[Developer Guide],
- the {linkdoc}packager-guide{ld-s}[Packager Guide].
Acknowledgements / Contributions
--------------------------------
The many people who have participated in creating and improving NUT are
listed in the user manual {xref}Acknowledgements{x-s}[acknowledgements appendix].
[[acknowledgements-ci-ops]]
We would like to highlight some organizations which provide continuous
support to the NUT project (and many other FOSS projects) on technological
and organizational sides, such as helping keep the donations transparent,
NUT CI farm afloat, and public resources visible. Thanks for keeping the
clocks ticking, day and night:
////////////
FIXME: Use different (better-resolution) images for PDF rendering?
FIXME: PDF cells seem to align weirdly, like setting the bottom of the first
line of text to be on the same level as bottom of the image, or similar to that.
NOTE: GitHub renderer (or CSS stack?) ignores style settings and squashes the
logo column into a fixed-width monster with either our specified heights, or
with teeny-tiny thumbnail magnitude images, so it is prettier to leave it as
a "single-column table" by default. Grid/Frame settings are also ignored, but
we can try our best anyway.
NOTE: The classic asciidoc/a2x renderer seems to not support link/url options,
but at least does not complain about them either.
////////////
ifndef::env-github[]
[frame="none",grid="none",cols="^.<1,<.<2"]
endif::env-github[]
ifdef::env-github[]
[frame="none",grid="none",cols="<1*"]
endif::env-github[]
|===
| image:images/ci/GitHub-Mark-140pxW.png[alt="GitHub logo",width="140",height="140",link="https://github.com/"]
| The link:https://github.com/networkupstools/["NetworkUPSTools" organization
on GitHub] arranges a lot of things, including source code hosting for NUT
itself and several related projects, team management, projects, issue and
pull request discussions, sponsorship, nut-website rendering and hosting,
some automated actions, and more...
| image:images/ci/jenkins-nut-transparent-bg-140pxW.png[alt="Jenkins and NUT logo",width="139",height="104",link="https://www.jenkins.io/"]
| The link:https://www.jenkins.io/[Jenkins CI] project and its huge plugin
ecosystem provides the technological foundation for the largest island of
the link:https://ci.networkupstools.org/[self-hosted NUT CI farm].
There is a fair amount of cross-pollination between the upstream project
and community, and the development done originally for the NUT CI farm.
See more at link:https://stories.jenkins.io/user-story/jenkins-is-the-way-for-networkupstools/[Jenkins
is the way to build multi-platform NUT] article.
| image:images/ci/DO_Powered_by_Badge_blue_140pxW.png[alt="DigitalOcean logo",width="140",height="29",link="https://www.digitalocean.com/?refcode=d2fbf2b9e082&utm_campaign=Referral_Invite&utm_medium=Referral_Program&utm_source=badge"]
| The link:https://www.digitalocean.com/?refcode=d2fbf2b9e082&utm_campaign=Referral_Invite&utm_medium=Referral_Program&utm_source=badge[DigitalOcean]
droplets allow us to host NUT CI farm Jenkins controller and the build agents
for multiple operating systems.
They are essentially virtual machines where the multi-platform NUT CI farm with
a link:https://github.com/networkupstools/jenkins-dynamatrix/[jenkins-dynamatrix]
link:https://github.com/networkupstools/nut/blob/master/Jenkinsfile-dynamatrix[setup]
runs to arrange builds in numerous operating environments and a lot of toolkit
versions and implementations. Some workers running on NUT community members'
machines can also dial in to provide an example of their favourite platforms.
Literally hundreds of NUT builds run for each iteration, to make sure NUT can
always build and work everywhere.
This allows us to ensure that NUT remains portable across two decades' worth
of operating systems, compilers, script interpreters, tools and third-party
dependencies.
| image:images/ci/obs-logo.png[alt="openSUSE Build Service logo",width="140",height="62",link="https://build.opensuse.org/"]
| The several variants of
link:https://build.opensuse.org/project/show/home:networkupstools[OBS NUT
packaging project] hosted on the link:https://build.opensuse.org/[openSUSE
Build Service (OBS)] allow us to propose reference packaging recipes for a
number of Linux distributions, as well as to test NUT PR and stable branch
iterations on those across several CPU architectures not available elsewhere.
| image:images/ci/CircleCI_vertical_black_logo.png[alt="CircleCI logo",width="130",height="107",link="https://circleci.com/"]
| The
link:https://app.circleci.com/pipelines/github/networkupstools/nut/[CircleCI
NUT pipeline] allows us to test NUT CI builds on MacOS.
| image:images/ci/AppVeyor_logo-ar21.png[alt="AppVeyor logo",width="120",height="60",link="https://www.appveyor.com/"]
| The link:https://ci.appveyor.com/project/nut-travis/nut/[AppVeyor
NUT pipeline] allows us to test NUT CI builds on Windows (and publish
preview tarballs with binaries).
| image:images/ci/fosshost_org_Host_Light_38px.png[alt="Fosshost logo",width="112",height="38"]
| Fosshost used to provide virtual machines where the multi-platform NUT CI farm
ran, following up from a take on multi-platform builds with Travis CI while it
was free for FOSS projects. In turn, DigitalOcean helped us move on from there
after the Fosshost project went defunct.
| image:images/ci/gandi-ar21.png[alt="Gandi.Net logo",width="120",height="60",link="https://www.gandi.net/"]
| link:https://www.gandi.net/[Gandi.Net] ultimately took up the costs of
NUT DNS hosting, which they have provided commercially for years before
that.
| image:images/ci/OC_logo_merged_140x26.png[alt="Open Collective logo",width="140",height="26",link="https://opencollective.com/"]
| https://opencollective.com/networkupstools allows us to arrange monetary
donations and spending, with public transparency of everything that happens.
|===
```
标签:Cutter, UPS管理, 内核驱动, 客户端加密, 硬件监控, 系统工具, 网络协议, 运维