sshine/nginx-nix
GitHub: sshine/nginx-nix
一个以教学为目的的 Nix flake 项目，演示如何通过 overlay 快速覆盖 NixOS 中 nginx 的版本，为安全应急响应提供低阻力的补丁方案模板。
Stars: 0 | Forks: 0
# nginx-nix
## 用法
### 在 NixOS 配置中应用 overlay
将此 flake 添加为输入，并将 `overlays.default` 应用于 nixpkgs。此 overlay 将 `nginxStable` 重定向至 1.30.1，`nginxMainline` 重定向至 1.31.0，以及 `nginx` 重定向至 1.30.1，因此任何已经使用 `pkgs.nginx` 或 `services.nginx` NixOS 模块的内容都会直接获取到修补后的构建版本，无需进行其他更改。
```
{
inputs = {
nixpkgs.url = "github:NixOS/nixpkgs/nixpkgs-unstable";
nginx-nix.url = "github:sshine/nginx-nix";
nginx-nix.inputs.nixpkgs.follows = "nixpkgs";
};
outputs =
{ nixpkgs, nginx-nix, ... }:
{
nixosConfigurations.my-host = nixpkgs.lib.nixosSystem {
system = "x86_64-linux";
modules = [
# your existing configuration
./configuration.nix
# enable the overlay
{ nixpkgs.overlays = [ nginx-nix.overlays.default ]; }
# use the nginx packages as usual
(
{ pkgs, ... }:
{
services.nginx.enable = true;
environment.systemPackages = [ pkgs.nginx ];
}
)
];
};
};
}
```
## 动机
及时应对事件对于系统管理员（DevOps 工程师）至关重要。就 nginx 而言，它作为一款备受瞩目的软件，其修复补丁合并到 NixOS 主线的速度比大多数人注意到该版本发布的时间还要快。我个人注意到这一点是在 2026-05-13 18:42，当时[有人链接到了][hn-changelog][更新日志][ng-changelog]，这是在 GitHub 发布之前。但我的应急响应过程是：
1. 访问[搜索 nixpkgs issue tracker 中关于 nginx 1.30/1.31 的内容][gh-nixpkgs]
2. 发现没有针对修复版本的 pull request
3. 意识到快进本地的 nixpkgs 副本需要等很久
4. 发了一条焦急的消息，问是否有人能比我更快完成这件事
5. 完全忽略了修复其实已经**推送到 master** 分支
6. 等了 2 天，开始更新 nixpkgs 并在等待期间制作了这个 flake
7. 才发现 nixpkgs 已经更新了，而这个 flake 是多余的
我希望我的响应过程应该是这样的：
1. 访问[搜索 nixpkgs issue tracker 中关于 nginx 1.30/1.31 的内容][gh-nixpkgs]
2. 发现没有针对修复版本的 pull request
3. 开始更新 nixpkgs 并在等待期间制作这个 flake
4. 发现 nixpkgs 已经更新了，这个 flake 是多余的
我的观点是：为 nixpkgs 贡献代码只花了 5 分钟，制作这个 flake 也只花了 5 分钟。做过一次之后，有了这个 flake 的模板，我可以将时间缩短到 2 分钟。把时间从 5 分钟缩短到 2 分钟很重要吗？完全不是。重要的是要知道阻力很低，这样我就更有动力去快速响应。
标签：Nginx, Nix, Nix Flakes, NixOS, Overlay, Web服务器, 安全响应, 库, 应急响应, 开源, 教育项目, 漏洞修复, 系统管理员, 系统运维, 系统配置, 网络安全培训, 软件打包