DEV Community: Hayden Young

Nix, the shell bootstrapper

Hayden Young — Sun, 19 Jul 2020 16:58:21 +0000

So recently I swapped out Arch Linux for NixOS, mainly because I could bootstrap my entire PC with a configuration file. I never really looked into nix as a tool until today. Of course, I've been using nix as a package manager for about a month due to NixOS, but I'd never looked into nix itself for development purposes. And oh boy, was I glad that I did. And here's why.

with import <nixpkgs> {};

stdenv.mkDerivation {
  name = "node";
  buildInputs = [
    nodejs
  ];
  shellHook = ''
    export PATH="$PWD/node_modules/.bin/:$PATH"

    alias run='npm run'
  '';
}

So what the fork is this?! Well, calm down a little and I'll tell you.

This beautiful piece of functional code you see before you is a Nix Derivation. It's used in this instance to make a complete dev environment for me for nodejs. It lives in a file called default.nix, and allows for anyone to just come along and run nix-shell and have a full Node.js development environment complete with an alias of npm run to run.

The fact that I can do this without having to go download NVM or nodenv or similar is... Well, let's just be calm and say it saves me a lot of headaches.

So let's break that file down.

with import <nixpkgs> {};

This tells Nix to import the nixpkgs package registry, which is the official source for nix packages. This becomes important later.

stdenv.mkDerivation {
  # ...
}

Does what it says on the tin really. Makes a new nix derivation, defined & configured by the contents of the block. This is what Nix evaluates to produce our dev environment.

name = "node";

This just gives our derivation a name, duh. I've called it node here, but you could call it stopwritingpostsondevyoudontknowanything for all I care.

buildInputs = [
  nodejs
];

This is where that nixpkgs import line comes in handy. This is telling Nix to install the latest LTS version (at least the current LTS version recorded in the nixpkgs repo) of Node.js, and make it available to us in the dev environment. You could add anything here. Need to build native extensions? Throw gcc and automake in here!

shellHook = ''
  export PATH="$PWD/node_modules/.bin/:$PATH"

  alias run='npm run'
'';

So this is essentially a bash script that will be called when the environment is created. In this instance, it's adding the node_modules/.bin directory to our PATH variable, so we can call any NPM-installed binaries as if they were globally installed on our system. Really cool for those obscure linting commands you only ever need to run once or twice.

It also aliases npm run to run, allowing me to do run build instead of npm run build. Tiny amount of time saved, but I love tiny, insignificant time saving measures.

So that's the default.nix file covered.

But Hayden, you keep telling me how cool and epic and amazing and <insert other synonym for 'cool' here>, but you haven't shown me anything yet.

no talk me, i angy.

Well, don't be so angy. You want a demo putting it all together? Have one.

See? It's fantastic.

Well, that about wraps this up.

TL;DR, Nix is brilliant and you should try it out now. Go. Leave the room please. Go. I don't want you around anymore. Go try Nix. Now. BYE!

Systemd for service management

Hayden Young — Tue, 02 Jun 2020 11:55:24 +0000

LinuxCast 01 - Managing services with systemd

systemd is possibly the most common init system you'll come across on Linux,
it's pre-installed on Ubuntu, Arch, Fedora and many more popular distributions.

It's also incredibly trivial to manage your services with it, and I'm going to
show you how to do just that in this inaugural LinuxCast.

So without further ado, let's jump in.

Starting and stopping services is probably the most common task you'll perform
using systemd. And it's incredibly easy.

On this computer, I'm running Arch Linux, and I have the containerization tool
'Docker' installed. It's a wonderful tool, but it doesn't automatically start
up. We can start it ourselves very easily and have it run in the background
using the power of systemd.

The command you use to do any task with systemd is systemctl, standing for
"system control", not cuttlefish. Who could've seen that coming?

In this instance, we want to start a service, so we're going to pop open a
terminal, and we'll type the following.

# Start up the Docker service
$ sudo systemctl start docker.service

Now, if all has gone well, you'll notice that there wasn't any output. That's
good. So if we now run docker ps, we should see that familiar table from
Docker, just as expected.

But what if we realise it's taking up a ton of RAM, so we want to stop the
Docker service? For that, there's a very similar subcommand -- stop.

# Stop the Docker service
$ sudo systemctl stop docker.service

And now, again, notice how systemctl gave us no output to work with. Again,
that's what we were expecting. It means that Docker has now stopped. So if we
run docker ps again, we should find that the client fails to connect to the
Docker socket.

What if you forgot whether or not you started a service or not? That's easy
too.

To do that, we want to view the status of the service. Can you guess the
command for that yet?

# Check the status of the Docker service
$ sudo systemctl status docker.service

Look at that, we have a lot of command-line output. The only thing we're
interested in, however, is the line that says "Active", and we can see that the
Docker service is "inactive" or "dead", meaning the service isn't running right
now.

Now, what about starting services when your computer boots up? Well, to
control whether services do that or not, we can use the enable and disable
systemctl commands.

Let's say I want Docker to start when my computer does. That's easily done.

# Tell systemd to start Docker on boot
$ sudo systemctl enable docker.service

This time round, we get output. Systemd is telling us that it's created
a symlink from the service file for Docker into the directory containing all
the services that are run on startup.

What about if I want to stop Docker starting when my computer does? Again,
easily done. It's as easy as using that disable command I mentioned earlier.

# Tell systemd to stop running Docker on boot
$ sudo systemctl disable docker.service

And we can see it's removed the docker service from that folder from earlier.

Now Docker will no longer start when our computer does.

Thanks for giving this a read. Drop me a follow if you found it useful, I'll be writing some more of these.