Jump to content

NixOS/zh: Difference between revisions

From NixOS Wiki
Weijia (talk | contribs)
Created page with "尽管 NixOS 通常尽可能以声明式方式进行配置,但在某些情况下,命令式操作仍然是必需的;这包括了用户环境管理和频道管理。"
Weijia (talk | contribs)
Created page with "==== 用户环境 ===="
Line 76: Line 76:
尽管 NixOS 通常尽可能以声明式方式进行配置,但在某些情况下,命令式操作仍然是必需的;这包括了用户环境管理和频道管理。
尽管 NixOS 通常尽可能以声明式方式进行配置,但在某些情况下,命令式操作仍然是必需的;这包括了用户环境管理和频道管理。


<div lang="en" dir="ltr" class="mw-content-ltr">
<span id="User_Environments"></span>
==== User Environments ====
==== 用户环境 ====
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">

Revision as of 20:04, 28 August 2025

Introduction to Nix

Tools and applications

☶︎
This article or section needs to be expanded. 此篇文章需要是一个简单的入门介绍,因为它将是新用户在此处阅读的首批文章之一。因此,内容需要简化一些,更复杂的主题应转移到其他文章中。 Further information may be found in the related discussion page. Please consult the pedia article metapage for guidelines on contributing.

NixOS 是一个基于 Nix 包管理器与构建系统的 Linux 发行版。它支持声明式的系统级配置管理以及原子化升级和回滚,同时它仍支持命令式的包管理和用户管理。在 NixOS 中,发行版的所有组件 — 包括系统内核、已安装的软件包和系统配置文件 — 均由 Nix 从被称为 Nix 表达式纯函数中构建。

由于 Nix 使用了二进制缓存机制,这便为面向二进制分发(如 Debian)和面向源码分发(如 Gentoo)的方法提供了一种独特的折中方案。预编译的二进制程序被视作标准组件,在其无法获取时,自助编译的软件包与模块将被自动构建。

NixOS 稳定版本每年发布两次(大约在五月底和十一月底)。NixOS 由 Eelco DolstraArmijn Hemel 创建,并于 2003 年首次发布。目前由 NixOS 基金会 管理下的社区开发与维护。

安装

完整的安装指南请参阅 NixOS 手册的 Installation 章节。此维基还包含替代或补充指南,例如 桌面设备上的 NixOS

大多数用户通过 任一 ISO 镜像 安装 NixOS。每个支持架构均有 “graphical”(图形化安装)和 “minimal”(最小化安装)两种 ISO 变体;“graphical” 镜像适用于计划安装桌面环境的用户,而 “minimal” 镜像适用于计划将 NixOS 充当服务器或期望更小 ISO 镜像文件的用户。ISO 镜像为混合镜像,可以刻录到光盘介质或原封不动地复制到 USB 驱动器上并直接启动。请参阅安装指南以了解详情。

除了 ISO 镜像,下载页面 还提供了多种安装 NixOS 的替代方法。这些方法包括:

  • OVA 格式的虚拟机(兼容 VirtualBox);
  • Amazon EC2 AMIs;

此外,许多现有的 Linux 安装可以通过 nixos-infectnixos-in-place 转换为 NixOS 安装;这对于在不原生支持 NixOS 的主机提供商平台安装 NixOS 十分有用。

系统架构

NixOS 对大多数 x86_64 设备和通用 ARM64 设备提供了开箱即用的支持。

32位 x86 架构

对于32位 x86 架构(即 i686)的支持正在减少。大多数包仍然可以编译和运行,但它们的缓存可用性显著降低[1]。32位 x86 架构不再提供预构建的 ISO 镜像文件,但其仍可手动构建。

64位 x86 架构

大多数 x86_64 设备都能顺利运行 NixOS。

32位 ARM 架构

Main article: NixOS on ARM

NixOS 不官方支持 ARM32 设备(例如 armv6arm71),不过对于其中部分设备,可能存在社区支持。

64位 ARM 架构

Main article: NixOS on ARM

只要设备支持通用 systemd 引导过程,NixOS 便可开箱即用。但是,使用专有引导加载程序的特定设备可能存在运行问题。

MIPS 架构

Main article: NixOS on MIPS

NixOS 对于 MIPS 架构的支持有限, Nixpkgs 中可能存在部分对于此架构的支持。但并未有官方支持。

用法

声明式配置

NixOS 的一个核心特征便是其声明式配置模型,其中整个系统状态 — 包括已安装的软件包、系统服务和设置 — 均在配置文件中描述。主配置文件通常位于 /etc/nixos/configuration.nix

配置的更改通过使用 nixos-rebuild switch 原子化应用,从而确保可复现性并能回滚到之前状态。大多数用户使用版本控制系统来追踪配置文件,以实现一致且可移植的系统设置。在其他系统中,这些缺陷通常是事后才通过 Puppet、Ansible 或 Chef 等配置管理解决方案来弥补,甚至完全无法弥补。这些工具将系统配置与预期的状态描述进行协调。然而,其并未集成到操作系统的设计中,而只是简单地叠加在操作系统之上。因此,当操作系统配置的某个方面未在预期状态描述中指定时,其配置仍然可能会有所不同。

与传统发行版通常将系统配置散布于各处需手动编辑的文件中不同,NixOS 将配置管理直接集成到操作系统中。这种方式消除了配置漂移,使得 NixOS 十分适合自动化、可复现的部署。

关于 NixOS 配置的更多细节和示例,请参阅 NixOS 系统配置

命令式操作

尽管 NixOS 通常尽可能以声明式方式进行配置,但在某些情况下,命令式操作仍然是必需的;这包括了用户环境管理和频道管理。

用户环境

In addition to declarative system configuration, NixOS users can utilize Nix's imperative nix-env command to install packages at the user level, without changing the system state. See the user environments section of the Nix article for more information.

Channels

In the Nix ecosystem, channels are a mechanism for distributing collections of Nix packages and NixOS module definitions. A channel represents a curated, versioned set of package definitions and system configurations, typically corresponding to a particular release or the latest available development state.

When using channels, your system or user environment pulls package definitions and options from a URL pointing to a specific snapshot of the Nix Packages collection (Nixpkgs) and associated NixOS modules.

For more information on using and configuring nix channels, refer to channel branches.

Internals

Comparison with traditional Linux Distributions

The main difference between NixOS and other Linux distributions is that NixOS does not follow the Linux Standard Base file system structure. On LSB-compliant systems software is stored under /{,usr}/{bin,lib,share} and configuration is generally stored in /etc. Software binaries are available in the user environment if they are placed in one of the LSB's /bin directories. When a program references dynamic libraries it will search for the required libraries in the LSB folders (/lib, /usr/lib).

In NixOS however /lib and /usr/lib do not exist. Instead all system libraries, binaries, kernels, firmware and configuration files are placed in the Nix store. The files and directories in /nix/store are named by hashes of the information describing the built data. All of the files and directories placed in the Nix store are immutable. /bin and /usr/bin are almost absent: they contain only /bin/sh and /usr/bin/env respectively, to provide minimal compatibility with existing scripts using shebang lines. User-level environments are implemented using a large number of symbolic links to all required packages and auxiliary files. These environments are called profiles and are stored in /nix/var/nix/profiles, each user having their own profiles. Structuring the system in this way is how NixOS obtains its key advantages over conventional Linux distributions, such as atomicity and rollback support.

Usage of the Nix store

A lot of confusion for newcomers arises from the fact that configuration is stored in the read-only /nix/store tree along with all the installed packages. This fact makes it impossible to manually edit system configuration; all configuration changes must be performed by editing the /etc/nixos/configuration.nix file and executing nixos-rebuild switch. NixOS provides the module system for editing all required configurations. Users should first use the option search tool to check if the option they need exists before attempting to manually add files or configuration via low-level NixOS features like activation scripts.

The system purity makes it possible to keep system configuration in a central place, without the need to edit multiple files. This configuration can be distributed or version controlled as desired. It also provides for determinism; if you provide the same inputs, the same version of Nixpkgs and the same /etc/nixos/configuration.nix you will get the exact same system state.

Modules

The NixOS module system as defined in Nixpkgs provides the means necessary to customize the configuration of the OS. It is used to enable and customize services such as nginx, enable firmware and customize the kernel.

All module configuration is generally performed by adding options to /etc/nixos/configuration.nix. Most of the examples in the wiki show how this file can be used to configure the OS.

The NixOS module system implements a typing system which allows typechecking of option settings. It also enables options defined in multiple places to be merged automatically. This allows you to spread your configuration over multiple files, and the options you set across all of those files will be merged together:

❄︎ /etc/nixos/configuration.nix
{
  imports = [
    ./basic-webserver.nix
    ./blog.nix
  ];
}
❄︎ /etc/nixos/basic-webserver.nix
{
  services.nginx.enable = true;
  services.nginx.virtualHosts."example.com" = {
    root = "/var/www/example.com";
  };
}
❄︎ /etc/nixos/blog.nix
{
  services.nginx.virtualHosts."blog.example.com" = {
    root = "/var/www/blog.example.com";
  };
}

See the Modules section of the NixOS Manual for more details.

Generations

Every time the system state is rebuilt using nixos-rebuild switch, a new generation is created. You can revert to the previous generation at any time, which is useful if a configuration change (or system update) turns out to be detrimental.

You can roll back via:

$ nix-env --rollback               # roll back a user environment
$ nixos-rebuild switch --rollback  # roll back a system environment

NixOS also places entries for previous generations in the bootloader menu, so as a last resort you can always revert to a previous configuration by rebooting. To set the currently booted generation as the default run

$ /run/current-system/bin/switch-to-configuration boot

Because NixOS keeps previous generations of system state available in case rollback is desired, old package versions aren't deleted from your system immediately after an update. You can delete old generations manually:

# delete generations older than 30 days
$ nix-collect-garbage --delete-older-than 30d
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# delete ALL previous generations - you can no longer rollback after running this
$ nix-collect-garbage -d

List generations:

# as root
$ nix-env --list-generations --profile /nix/var/nix/profiles/system

Switch generations:

# as root switch to generation 204
$ nix-env --profile /nix/var/nix/profiles/system --switch-generation 204

delete broken generation(s):

# as root delete broken generations 205 and 206 
$ nix-env --profile /nix/var/nix/profiles/system --delete-generations 205 206

You can configure automatic garbage collection by setting the nix.gc options in /etc/nixos/configuration.nix. This is recommended, as it keeps the size of the Nix store down.

See also