Notice: until this page is cleaned up, it is much more easily viewed with the Vector wiki theme.
- 1A NixOS cheat sheet and comparison to Ubuntu
- 2Working with the nix store
- 2.1Get the store path for a package
- 2.9Customizing Packages
A NixOS cheat sheet and comparison to Ubuntu
This is meant to give you basic ideas and get you unstuck. NixOS is very different from most distributions, a deeper understanding will be necessary sooner or later. Please follow the links to the manual pages or browse the Wiki for more in-depth NixOS tutorials.
- Wget – cheat sheet 2014-08-27-b-background Go to background immediately after startup. If no output file is specified via the-o, output is redirected to wget-log.-o logfile / -output-file=logfile Log all messages to logfile.
- Introduced in PowerShell (PS) 3.0, the Microsoft version of Wget is supported as a core cmdlet in PS named Invoke-WebRequest. Tricks, and cheat sheets.
$ http POST name='John' Host:example.com — JSON, cookies, files, auth, and other httpie examples. One-page guide to httpie. Download Now: Basic Linux Commands Cheat Sheet Linux System Administration Skills Assessment The.nix commands curl and wget are useful for accessing URLs without resorting to a browser. Git cheat sheet. A simple A3 format git cheat sheet. This is actually the condensed notes I took as studied (and still currently studying) the excellent progit2 book. The diagram is currently edited with the online app LucidChart. I have tried to export a version of the diagram as SVG in order to avoid using Lucidchart and have a.
The system-wide column is the equivalent of using apt under Ubuntu.
TODO: Provide well-commented sample configuration.nix and ~/.nixpkgs/config.nix files with examples of common tasks.
| Task | Ubuntu | NixOS (system-wide and root) | NixOS (user) and Nix in general | |
|---|---|---|---|---|
| Basic concepts | ||||
| This column will let you do everything you can with Ubuntu and more. | This column just isn't possible in Ubuntu. | |||
| Who can install packages and who can run them? | All packages are always system-wide and only root can install packages. | Packages root installs are system-wide. It does so through /etc/nixos/configuration.nix. If root installs packages the same way users do, through ~/.nixpkgs/config.nix, they are also global. Root's default profile is the system-wide default profile. | Users can install their own packages and have their own profiles (environments) through ~/.nixpkgs/config.nix | |
| Package manager | apt which is really running on top of dpkg, sometimes wrapped by UIs like aptitude. | nix, but many system-wide operations are provided by nixos packages. | Just nix without the involvement of nixos. | |
| How do you select your official sources and major releases | These are baked into the distribution (e.g. Ubuntu version X). Upgrades are hard and permanent. | At any time you select from a collection of channels. They're system-wide when set by root. You can roll back changes or switch channels with ease. | Channels are per-user if they're not set by root. | |
| Where are packages installed? | apt installs globally into /bin/, /usr/, etc. | System-wide packages are in /run/current-system/sw/ (these are installed because of /etc/nixos/configuration.nix) and /nix/var/nix/profiles/default/bin/ (this is the profile managed by root). Note that the files are just symlinks to the real packages managed by nix /nix/store/. | User packages are in ~/.nix-profile/. Note that the files are just symlinks to the real packages managed by nix in /nix/store/. | |
| When changes take effect | As soon as the command runs. Commands are not atomic and can leave your machine in a bad state. | Most of the time you modify the configuration file and apply changes with nixos-rebuild switch TODO: How does one get nixos to do all the work for a switch and separate out the actual switching from fetching/building? | Most of the time you apply changes with nix-env -i all TODO: How does one get nix to do all the work for a switch and separate out the actual switching from fetching/building? | |
| Packages | Uniformly referred to as packages | Technically called 'derivations' but everyone calls them packages. | Technically called 'derivations' but everyone calls them packages. | |
| Package management | ||||
| Install a package for all users | 1. Add to /etc/nixos/configuration.nix: 2. Run : | Or with collections, add the package to your ~/.nixpkgs/config.nix and run | ||
| Install a package for a specific user only | Not possible | 1. Add to /etc/nixos/configuration.nix: Macbook pro 16 firmware update. 2. Run: | 1. Add to ~/.nixpkgs/config.nix: 2. Run: | |
| Install a service | 1. Add to /etc/nixos/configuration.nix: 2. Run: | Not possible | ||
| Uninstall a package | remove from /etc/nixos/configuration.nix | |||
| Uninstall a package removing its configuration | All configuration is in configuration.nix | |||
| Update the list of packages | ||||
| Upgrade packages | ||||
| Check for broken dependencies | unneeded! | |||
| List package dependencies | Show the direct dependencies: or show a nested ASCII tree of dependencies: (/run/current-system and /nix/var/nix/profiles/system are symbolic links that eventually end up at the same place.) | For installed packages: | ||
| List which packages depend on this one (reverse dependencies) | For installed packages (only print reverse dependencies *which are already installed*): | |||
| Verify all installed packages | ||||
| Fix packages with failed checksums | Reinstall broken packages | |||
| Select major version and stable/unstable | Change sources.list and apt-get dist-upgrade. A an extremely infrequent and destructive operation. The nix variants are safe and easy to use. | Add the unstable channel. At that address you will find names for other versions and variants. Name can be any string. To eliminate a channel. To show all installed channel. | When run by a user channels work locally, when run by root they're used as the system-wide channels. | |
| Private package repository | PPA | Define your package tree as in the general column, and include it in configuration.nix, then list your packages in systemPackages to make them available system wide | See [1] | |
| Install a particular version of a package | Although Nix on its own doesn't understand the concept of package versioning, you can install and play with older (or newer!) software via https://nixos.wiki/wiki/FAQ/Pinning_Nixpkgs with https://lazamar.co.uk/nix-versions.
| |||
| Package configuration | ||||
| Configure a package | Edit /etc/nixos/configuration.nix | Edit ~/.nixpkgs/config.nix; TODO: More details about how to edit | ||
| Global package configuration | Modify configuration file in /etc/ | Edit /etc/nixos/configuration.nix | ||
| Find packages | or | or | ||
| Show package description | ||||
| Show files installed by package | then | |||
| Show package for file | follow the symlink or (requires package) | (same) | ||
| Services | ||||
| Start a service | ||||
| Stop a service | ||||
| Enable a service | In /etc/nixos/configuration.nix, add , then run | |||
| Disable a service | In /etc/nixos/configuration.nix, add , then run | |||
| Where your log files live | /var/log/ | System-wide packages /var/log/ | User packages ~/.nix-profile/var/log/ | |
| Adding a user | Add to /etc/nixos/configuration.nix and then call | |||
| Misc tasks | ||||
| List binaries | ||||
| Get the current version number | ||||
| Get sources for a package | In Debian, apt-get source gets both the patched upstream source and the recipe for the package. Those need two steps in Nix.To find the package's attribute path: or To download the source as specified by the package recipe: The patched source is usually not a derivation itself, but can be produced for most packages with the following command: | |||
| Compile & install a package from source | ||||
| Install a binary package | e.g. via nix-ld | |||
| Install a .deb | Install dpkg with Nix, then While this is technically possible it will in all likelihood not work. | |||
Comparison of secret managing schemes
Manage secrets in your (system) configuration. That page tries to give an overview of different schemes that can be used and outlines the aims, requirements and implications of each.
Working with the nix store
Get the store path for a package
Adding files to the store
It is sometimes necessary to add files to the store manually.This is particularly the case with packages that cannot be downloaded automatically,for example, proprietary software packages.For most files, it is sufficient to run:
Unfortunately, `nix-store` will try to load the entire file into memory,which will fail if the file size exceeds available memory.If we have root access, we can copy the file to the store ourselves:
To add a file with fixed name (when the input filename is not stable), or to add entire directories with filter, you can use builtins.path:
Build nixos from nixpkgs repo
The following snippet will build the system from a git checkout:
This method can be used when testing nixos services for a pull request to nixpkgs.
Building nixos from a git is an alternative to using nix channels and set up permanent following this blog article.It has a couple of advantages over nixpkgs as it allows back-porting of packages/changes to stable versionsas well as applying customization.
Use the following command to build directly from a particular branch of a repository in GitHub:
Evaluate a NixOS configuration without building
Wget Pdf
If you only want to evaluate `configuration.nix` without building (e.g. to syntax-check or see if you are using module options correctly), you can use:
This creates the `.drv` file that `nixos-rebuild build` would build.
Manually switching a NixOS system to a certain version of system closure
(Or: What nixos-rebuild does under the hoods.)
Step 1: Do this for the equivalent of nixos-rebuild boot or nixos-rebuild switch, i.e. if you want the changes to persist after reboot:
If you have the store path, run this, replacing $systemClosure with store path to your system closure:
Or, if it was a previous generation, you can run this instead, replacing $generation with the desired generation number:
Step 2: Do this for all changes:
Run this, replacing $action with the action (one of boot, switch, test):
If you use a different profile name the procedure is similar, but use /nix/var/nix/profiles/system-profiles/$profileName instead of /nix/var/nix/profiles/system.
Building a service as a VM (for testing)
While nixos-rebuild build-vm allows to build a vm out of the current system configuration, there is a more light-weight alternative when only a single service needs to be tested.
Given the following configuration:
a vm can be build using the following command:
where -I nixpkgs=/path/to/nixpkgs is optionally depending whether the vm should be build from git checkout or a channel.
On non-nixos (linux) systems the following command can be used instead:
By default the resulting vm will require X11 to create a virtual display.By specifying additional arguments via the environment variables QEMU_OPTSand QEMU_KERNEL_PARAMS it is possible to reuse the current running terminal as serial console for the vm:
To forward a port you can set export QEMU_NET_OPTS. In the following example port 2222 on the host is forwarded to port 22 in the vm:
Don't forget that by default nixos comes with a firewall enabled:
Reuse a package as a build environment
As packages already contains all build dependencies, they can be reused to a build environment quickly.In the following a setup for the cmake-based project [bcc](https://github.com/iovisor/bcc) is shown.After obtaining the source:
Add the following default.nix to the project:
To initiate the build environment run `nix-shell` in the project root directory
The following is specific to bcc or cmake in general:(so you need to adapt the workflow depending on the project, you hack on)
Evaluate packages for a different platform
Sometimes you want to check whether a change to a package (such as adding a new dependency) would evaluate even on a different type of system. For example, you may want to check on `x68_64-linux` whether a package evaluates for `x68_64-darwin` or `aarch64-linux`.
Use the `system` argument:
Cross-compile packages
The following command will cross compile the tinc package for the aarch64 CPU architecture from a different architecture (e.g. x86_64).
You can add your own specifications, or look at existing ones, in nixpkgs/lib/systems/examples.nix.
Customizing Packages
Cheat Sheet Pdf
Upgrading individual packages to a different channel
One can track multiple channels on NixOS simultaneously, and then declaratively change packages from the default channel to another one.
For example one can have both the unstable and stable channels on system root:
and the following in `configuration.nix`:
which allows you to switch particular packages to the unstable channel:
Building statically linked packages
There is also an stdenv adapter that will build static binaries:
Rebuild a package with debug symbols
Download a nix store path from the cache
If you want to the exact same nix store path on a different system, you can use the --realise or short -r parameter in the nix-store command:
Install an arbitrary nix store path into a user profile
nix-env also accepts the full path to a program in the nix store:
Check the syntax of a nix file
See also
- Garbage Collection- Nix store on NFS