Using SSH Resident Keys With a YubiKey 5

2022-08-02T00:00:00+00:00

Initial checks</h3>

Start by checking that there aren't any previous ssh keys inside the FIDO2 authenticator of your YubiKey. You can check if they exist by running the command below:</p>

nix</span> shell nixpkgs#yubikey-manager -c ykman fido credentials list
</span></code></pre>
If the command above outputs a string mentioning "ssh" or "openssh", then you have already got a key generated and store on your YubiKey.</p>
Evaluating additional authentication factors</h3>
Before generating a new ssh key to store on your YubiKey you must consider which additional required authentication factors you want to use. Below you can see a table with the available factors and their corresponding command:</p>
Factors</th> Description</th> Command</th></tr></thead>

No PIN or touch are required</td> You will not be required to enter your FIDO2 PIN or touch your YubiKey each time to authenticate</td> ssh-keygen -t ed25519-sk -O resident -O no-touch-required</code></td></tr>
PIN but no touch required</td> Entering the PIN will be required but touching the physical key will not</td> ssh-keygen -t ed25519-sk -O resident -O verify-required -O no-touch-required</code></td></tr>
No PIN but touch is required</td> You will only need to touch the YubiKey to authenticate</td> ssh-keygen -t ed25519-sk -O resident</code></td></tr>
A PIN and a touch are required (most secure</strong>)</td> This is the most secure option, it requires both the PIN and touching to be used</td> ssh-keygen -t ed25519-sk -O resident -O verify-required</code></td></tr>
</tbody></table>
Generating the key</h3>
Once you've decided which option fits best for your threat model you will need to run one of the commands above. Note that if using a PIN you don't need to add an additional ssh passphrase as it's redundant due to the FIDO2 PIN being used instead. I personally went with the last and most secure option so the command I used to generate the key was:</p>
ssh-keygen</span> -t ed25519-sk -O resident -O verify-required
</span></code></pre>
Adding the new keys</h3>
Now that you have generated a key which you can use, you will need to add it to your current ssh-agent session. You can do that by first starting the agent like so:</p>
eval </span>"</span>$</span>(</span>ssh-agent</span> -s</span>)"
</span></code></pre>
Then add the key on the YubiKey with the command below:</p>
ssh-add</span> -K
</span></code></pre>
You can verify that the key was added by listing all the keys available in the current ssh-agent session:</p>
ssh-add</span> -l
</span></code></pre>
We just added our brand new ssh key temporarily to our current session. If you would like to have it permanently available on the system you can run the command:</p>
ssh-keygen</span> -K
</span></code></pre>
This retrieves our ssh key from our YubiKey and puts the private (still protected by YubiKey) and public key in the current working directory. You must now rename them accordingly to id_ed25519_sk</code> and id_ed25519_sk.pub</code> and place them in your ~/.ssh</code> directory so ssh can detect them.</p>
Authenticating with GitHub</h3>
In order to authenticate with GitHub you will have to add your new public key to your GitHub profile over at -> github.com/settings/keys</a>. You can retrieve the keypair by running</p>
ssh-keygen</span> -K
</span></code></pre>
and copy the public key directly from the newly added files to the current folder, for example, id_ed25519_sk_rk.pub</code>.</p>
Testing authentication</h4>
Now that we've added our ssh key to GitHub we can test that the setup works correctly by running:</p>
ssh</span> -T git@github.com
</span></code></pre>
If this worked correctly you should be greeted by a "welcoming message".</p>
NOTE: In order to make sure that you are using the new SSH key consider moving out existing keys from the ~/.ssh</code> directory just for this test.</p>


Building websites using Nix Flakes and Zola
2021-11-19T00:00:00+00:00
A quick first blog post introduction</h3>
Welcome! This is my new and only website, where I will share my finest thoughts and ideas.

I have been procrastinating for a while about creating my own blog, but here it is! 🎉</p>
I think it will only make sense if I start by showing how I actually</em> build this website.</h4>
Nix</h3>
Nix is an extremely powerful tool, which I use all the time as a DevOps enthusiast. I mostly use Nix for building software and for managing my machines running NixOS; it's a GNU/Linux distribution that was made with Nix at it's core. It uses Nix to manage all of its system configuration. I don't want the focus of this post to be about NixOS, so if you are interested in knowing more about NixOS, you can read more about it here</a>.</em></p>
For building this website, we make use of a new experimental feature in Nix called Flakes</strong>, whose main attraction for me is that it is pure and reproducible by default. Flakes are great because they're a standardized way to structure Nix-based projects. If you would like to learn more about Flakes, these are my go-to resources:</p>

Tweag's three-part series blog post - 1 - Introduction and tutorial</a>, 2 - Evaluation caching</a>, 3 - NixOS systems management</a></li>
Eelco Dolstra's talk at NixCon 2019 - Nix flakes (NixCon 2019)</a></li>
Flakes' NixOS wiki page - nixos.wiki/wiki/flakes</a></li>
</ul>
Zola and static site generators</h3>
My experience with SSGs is so little that you should probably take everything I say about them with a grain (bucket) of salt.</strong></em></p>
My journey with SSGs started with Hugo. I have played around with Hugo to create a couple of fairly small sites for the sake of testing. I did not like some complexity of Hugo, like the many ways of managing "themes" and Go's HTML and text templating, so I started looking for new solution. I wanted something lightweight and minimal, so I can focus more on the actual content of the site; that's where Zola came into the picture. I read a bit about Zola and liked some of its features, like built-in syntax highlighting and Sass compilation, alongside that it has a nice command line interface and is also a single binary like Hugo, though with Hugo, if one decides to use Hugo "modules", they will also need to have Go installed.</p>
Writing the flake.nix</h3>
The nixpkgs input:</strong>

When starting to write a flake for a new project that takes use of nixpkgs</a>, one should consider if they care about it using the latest software updates from the "unstable" branch or use the more thoroughly tested software updates from the "stable" branch. I personally avoid using the "master" branch since the changes in it haven't gone through the Hydra</a> build system, so you wouldn't be able to use the provided binary cache, which means you'd have to compile/build the software on your local system. We can set the branch to use for nixpkgs by declaring the nixpkgs</code> input in flake.nix</code> like so:</p>
inputs</span>.</span>nixpkgs</span>.</span>url </span>=</span> </span>"github:nixos/nixpkgs/nixpkgs-unstable"</span>;</span>
</span></code></pre>
In the example above we declared to use the nixpkgs-unstable</code> branch. You can read about the available branches/channels here → nixos.wiki/wiki/nix_channels</a>.</p>
The flake-utils input:</strong>

In this flake we will also be using flake-utils</a>, which is a collection of pure Nix functions that don't depend on nixpkgs. They can be useful for writing other Nix flakes. We use one of its system related functions, eachDefaultSystem</code> in this case. All this function does is populate the outputs with a list of all systems nixpkgs builds for. This is a simple and clean way to make a flake output buildable for many system types and architectures. It makes sense to use it here because, fortunately, Zola on nixpkgs builds for all the system types.</p>
The outputs:</strong>

Let's take a look at the outputs used in this flake:</p>
{
</span>  </span>packages</span>.</span>website </span>= </span>pkgs</span>.</span>stdenv</span>.</span>mkDerivation </span>rec </span>{
</span>    </span>pname </span>= </span>"static-website"</span>;
</span>    </span>version </span>= </span>"2021-11-19"</span>;
</span>    </span>src </span>= </span>./.</span>;
</span>    </span>nativeBuildInputs </span>= </span>[ pkgs</span>.</span>zola ]</span>;
</span>    </span>buildPhase </span>= </span>"zola build"</span>;
</span>    </span>installPhase </span>= </span>"cp -r public $out"</span>;
</span>  }</span>;
</span>  </span>defaultPackage </span>= </span>self</span>.</span>packages</span>.</span>${system}</span>.</span>website</span>;
</span>  </span>devShell </span>= </span>pkgs</span>.</span>mkShell {
</span>    </span>packages </span>= with </span>pkgs; [
</span>      zola
</span>    ]</span>;
</span>  }</span>;
</span>}
</span></code></pre>
Starting with the packages.website</code> output, this output builds a package called website</code>. This package includes a derivation called ${pname}-${version}</code>, which in this case will just be static-website-2021-11-19</code>. This derivation's src</code> is the current directory, ./.</code> and it depends on the package pkgs.zola</code>. Nix derivations are built using phases. The build phase here runs the command zola build</code>, and the install phase runs the command cp -r public $out</code>.
The end result will be that it builds the Zola site in the current directory and puts its generated contents in the $out</code> directory, which by default is a symlink called result</code> that's linked to the Nix store.</p>
Now onto the defaultPackage</code> output, this output is pretty simple. All it does is set the default output to get when running nix build</code> to the output called packages.website</code> that we just went over.</p>
And finally, the devShell</code> output, this is the output you will use to develop your website. What this output does is create a new shell environment with the package pkgs.zola</code> inside it. In order to enter that shell you have to run nix develop</code> in the root of the flake/repo.</p>
The complete flake.nix recipe</h3>
This is the complete flake.nix for the explanation we went over above.
You are more than welcome to use it for your own site.</p>
{
</span>  </span>description </span>= </span>"A flake for developing and building my personal website"</span>;
</span>
</span>  </span>inputs</span>.</span>nixpkgs</span>.</span>url </span>= </span>"github:nixos/nixpkgs/nixpkgs-unstable"</span>;
</span>  </span>inputs</span>.</span>flake-utils</span>.</span>url </span>= </span>"github:numtide/flake-utils"</span>;
</span>
</span>  </span>outputs </span>= </span>{ self</span>, </span>nixpkgs</span>, </span>flake-utils }:
</span>    flake-utils</span>.</span>lib</span>.</span>eachDefaultSystem (system:
</span>      </span>let
</span>        </span>pkgs </span>= </span>nixpkgs</span>.</span>legacyPackages</span>.</span>${system}</span>;
</span>      </span>in
</span>      {
</span>        </span>packages</span>.</span>website </span>= </span>pkgs</span>.</span>stdenv</span>.</span>mkDerivation </span>rec </span>{
</span>          </span>pname </span>= </span>"static-website"</span>;
</span>          </span>version </span>= </span>"2021-11-19"</span>;
</span>          </span>src </span>= </span>./.</span>;
</span>          </span>nativeBuildInputs </span>= </span>[ pkgs</span>.</span>zola ]</span>;
</span>          </span>buildPhase </span>= </span>"zola build"</span>;
</span>          </span>installPhase </span>= </span>"cp -r public $out"</span>;
</span>        }</span>;
</span>        </span>defaultPackage </span>= </span>self</span>.</span>packages</span>.</span>${system}</span>.</span>website</span>;
</span>        </span>devShell </span>= </span>pkgs</span>.</span>mkShell {
</span>          </span>packages </span>= with </span>pkgs; [
</span>            zola
</span>          ]</span>;
</span>        }</span>;
</span>      }
</span>    )</span>;
</span>}
</span></code></pre>
But there is more! - Declarative Zola themes management</h3>
If you want to go overkill</strong> you can even manage your Zola themes declaratively as flake inputs. This is a bit more hacky than you might think. What we are doing here is actually adding another src</code> of some sort into the build sandbox, in the configuration phase, right before the build phase. One of the things people always try to achieve when writing Nix code is making it as modular as possible. I tried to get it as modular as possible by writing a variable with the value of the theme name that is specified inside the theme's theme.toml</code>. It was done by squashing together a couple of fancy</em> built-in functions, builtins.fromTOML</code> and builtins.readFile</code>. These functions convert the TOML file into a Nix file and then grab the value of name</code> inside.</p>
themeName </span>=</span> ((</span>builtins.</span>fromTOML (</span>builtins.</span>readFile </span>"</span>${</span>deepthought</span>}</span>/theme.toml"</span>))</span>.</span>name)</span>;</span>
</span></code></pre>
In the configuration phase, we create a directory (two actually, if you consider the parent one) that is named after the value of ${themeName}</code>, which we set before. Now a simple cp -r</code> to copy the contents of the deepthought</code> (the theme used in this case) flake input. This will make the theme available in the sourceRoot</code>. For making development easier, we can add a shell hook to the mkShell</code> , which will symlink the content of the theme's input to themes/${themeName}</code> so we can use zola serve</code> as normal.</p>
The finished and only slightly</em> overkill</strong> flake.nix</code> is available below, and anyone</em> is free to use it.</p>
{
</span>  </span>description </span>= </span>"A flake for developing and building my personal website"</span>;
</span>
</span>  </span>inputs</span>.</span>nixpkgs</span>.</span>url </span>= </span>"github:nixos/nixpkgs/nixpkgs-unstable"</span>;
</span>  </span>inputs</span>.</span>flake-utils</span>.</span>url </span>= </span>"github:numtide/flake-utils"</span>;
</span>  </span>inputs</span>.</span>deepthought </span>= </span>{ </span>url </span>= </span>"github:RatanShreshtha/DeepThought"</span>; </span>flake </span>= false</span>; </span>}</span>;
</span>
</span>  </span>outputs </span>= </span>{ self</span>, </span>nixpkgs</span>, </span>flake-utils</span>, </span>deepthought }:
</span>    flake-utils</span>.</span>lib</span>.</span>eachDefaultSystem (system:
</span>      </span>let
</span>        </span>pkgs </span>= </span>nixpkgs</span>.</span>legacyPackages</span>.</span>${system}</span>;
</span>        </span>themeName </span>= </span>((</span>builtins.</span>fromTOML (</span>builtins.</span>readFile </span>"</span>${</span>deepthought</span>}</span>/theme.toml"</span>))</span>.</span>name)</span>;
</span>      </span>in
</span>      {
</span>        </span>packages</span>.</span>website </span>= </span>pkgs</span>.</span>stdenv</span>.</span>mkDerivation </span>rec </span>{
</span>          </span>pname </span>= </span>"static-website"</span>;
</span>          </span>version </span>= </span>"2021-11-19"</span>;
</span>          </span>src </span>= </span>./.</span>;
</span>          </span>nativeBuildInputs </span>= </span>[ pkgs</span>.</span>zola ]</span>;
</span>          </span>configurePhase </span>= </span>''
</span>            mkdir -p "themes/</span>${</span>themeName</span>}</span>"
</span>            cp -r </span>${</span>deepthought</span>}</span>/* "themes/</span>${</span>themeName</span>}</span>"
</span>          ''</span>;
</span>          </span>buildPhase </span>= </span>"zola build"</span>;
</span>          </span>installPhase </span>= </span>"cp -r public $out"</span>;
</span>        }</span>;
</span>        </span>defaultPackage </span>= </span>self</span>.</span>packages</span>.</span>${system}</span>.</span>website</span>;
</span>        </span>devShell </span>= </span>pkgs</span>.</span>mkShell {
</span>          </span>packages </span>= </span>[ pkgs</span>.</span>zola ]</span>;
</span>          </span>shellHook </span>= </span>''
</span>            mkdir -p themes
</span>            ln -sn "</span>${</span>deepthought</span>}</span>" "themes/</span>${</span>themeName</span>}</span>"
</span>          ''</span>;
</span>        }</span>;
</span>      }
</span>    )</span>;
</span>}
</span></code></pre>
And that's about it, thanks for reading my first ever blog post!</strong></p>

Factors</th>	Description</th>	Command</th></tr></thead>
No PIN or touch are required</td>	You will not be required to enter your FIDO2 PIN or touch your YubiKey each time to authenticate</td>	`ssh-keygen -t ed25519-sk -O resident -O no-touch-required</code></td></tr>`
PIN but no touch required</td>	Entering the PIN will be required but touching the physical key will not</td>	`ssh-keygen -t ed25519-sk -O resident -O verify-required -O no-touch-required</code></td></tr>`
No PIN but touch is required</td>	You will only need to touch the YubiKey to authenticate</td>	`ssh-keygen -t ed25519-sk -O resident</code></td></tr>`
A PIN and a touch are required (most secure</strong>)</td>	This is the most secure option, it requires both the PIN and touching to be used</td>	ssh-keygen -t ed25519-sk -O resident -O verify-required</code></td></tr> </tbody></table> Generating the key</h3> Once you've decided which option fits best for your threat model you will need to run one of the commands above. Note that if using a PIN you don't need to add an additional ssh passphrase as it's redundant due to the FIDO2 PIN being used instead. I personally went with the last and most secure option so the command I used to generate the key was:</p> ssh-keygen</span> -t ed25519-sk -O resident -O verify-required </span></code></pre> Adding the new keys</h3> Now that you have generated a key which you can use, you will need to add it to your current ssh-agent session. You can do that by first starting the agent like so:</p> eval </span>"</span>$</span>(</span>ssh-agent</span> -s</span>)" </span></code></pre> Then add the key on the YubiKey with the command below:</p> ssh-add</span> -K </span></code></pre> You can verify that the key was added by listing all the keys available in the current ssh-agent session:</p> ssh-add</span> -l </span></code></pre> We just added our brand new ssh key temporarily to our current session. If you would like to have it permanently available on the system you can run the command:</p> ssh-keygen</span> -K </span></code></pre> This retrieves our ssh key from our YubiKey and puts the private (still protected by YubiKey) and public key in the current working directory. You must now rename them accordingly to id_ed25519_sk</code> and id_ed25519_sk.pub</code> and place them in your ~/.ssh</code> directory so ssh can detect them.</p> Authenticating with GitHub</h3> In order to authenticate with GitHub you will have to add your new public key to your GitHub profile over at -> github.com/settings/keys</a>. You can retrieve the keypair by running</p> ssh-keygen</span> -K </span></code></pre> and copy the public key directly from the newly added files to the current folder, for example, id_ed25519_sk_rk.pub</code>.</p> Testing authentication</h4> Now that we've added our ssh key to GitHub we can test that the setup works correctly by running:</p> ssh</span> -T git@github.com </span></code></pre> If this worked correctly you should be greeted by a "welcoming message".</p> NOTE: In order to make sure that you are using the new SSH key consider moving out existing keys from the ~/.ssh</code> directory just for this test.</p> Building websites using Nix Flakes and Zola 2021-11-19T00:00:00+00:00 A quick first blog post introduction</h3> Welcome! This is my new and only website, where I will share my finest thoughts and ideas. I have been procrastinating for a while about creating my own blog, but here it is! 🎉</p> I think it will only make sense if I start by showing how I actually</em> build this website.</h4> Nix</h3> Nix is an extremely powerful tool, which I use all the time as a DevOps enthusiast. I mostly use Nix for building software and for managing my machines running NixOS; it's a GNU/Linux distribution that was made with Nix at it's core. It uses Nix to manage all of its system configuration. I don't want the focus of this post to be about NixOS, so if you are interested in knowing more about NixOS, you can read more about it here</a>.</em></p> For building this website, we make use of a new experimental feature in Nix called Flakes</strong>, whose main attraction for me is that it is pure and reproducible by default. Flakes are great because they're a standardized way to structure Nix-based projects. If you would like to learn more about Flakes, these are my go-to resources:</p> Tweag's three-part series blog post - 1 - Introduction and tutorial</a>, 2 - Evaluation caching</a>, 3 - NixOS systems management</a></li> Eelco Dolstra's talk at NixCon 2019 - Nix flakes (NixCon 2019)</a></li> Flakes' NixOS wiki page - nixos.wiki/wiki/flakes</a></li> </ul> Zola and static site generators</h3> My experience with SSGs is so little that you should probably take everything I say about them with a grain (bucket) of salt.</strong></em></p> My journey with SSGs started with Hugo. I have played around with Hugo to create a couple of fairly small sites for the sake of testing. I did not like some complexity of Hugo, like the many ways of managing "themes" and Go's HTML and text templating, so I started looking for new solution. I wanted something lightweight and minimal, so I can focus more on the actual content of the site; that's where Zola came into the picture. I read a bit about Zola and liked some of its features, like built-in syntax highlighting and Sass compilation, alongside that it has a nice command line interface and is also a single binary like Hugo, though with Hugo, if one decides to use Hugo "modules", they will also need to have Go installed.</p> Writing the flake.nix</h3> The nixpkgs input:</strong> When starting to write a flake for a new project that takes use of nixpkgs</a>, one should consider if they care about it using the latest software updates from the "unstable" branch or use the more thoroughly tested software updates from the "stable" branch. I personally avoid using the "master" branch since the changes in it haven't gone through the Hydra</a> build system, so you wouldn't be able to use the provided binary cache, which means you'd have to compile/build the software on your local system. We can set the branch to use for nixpkgs by declaring the nixpkgs</code> input in flake.nix</code> like so:</p> inputs</span>.</span>nixpkgs</span>.</span>url </span>=</span> </span>"github:nixos/nixpkgs/nixpkgs-unstable"</span>;</span> </span></code></pre> In the example above we declared to use the nixpkgs-unstable</code> branch. You can read about the available branches/channels here → nixos.wiki/wiki/nix_channels</a>.</p> The flake-utils input:</strong> In this flake we will also be using flake-utils</a>, which is a collection of pure Nix functions that don't depend on nixpkgs. They can be useful for writing other Nix flakes. We use one of its system related functions, eachDefaultSystem</code> in this case. All this function does is populate the outputs with a list of all systems nixpkgs builds for. This is a simple and clean way to make a flake output buildable for many system types and architectures. It makes sense to use it here because, fortunately, Zola on nixpkgs builds for all the system types.</p> The outputs:</strong> Let's take a look at the outputs used in this flake:</p> { </span> </span>packages</span>.</span>website </span>= </span>pkgs</span>.</span>stdenv</span>.</span>mkDerivation </span>rec </span>{ </span> </span>pname </span>= </span>"static-website"</span>; </span> </span>version </span>= </span>"2021-11-19"</span>; </span> </span>src </span>= </span>./.</span>; </span> </span>nativeBuildInputs </span>= </span>[ pkgs</span>.</span>zola ]</span>; </span> </span>buildPhase </span>= </span>"zola build"</span>; </span> </span>installPhase </span>= </span>"cp -r public $out"</span>; </span> }</span>; </span> </span>defaultPackage </span>= </span>self</span>.</span>packages</span>.</span>${system}</span>.</span>website</span>; </span> </span>devShell </span>= </span>pkgs</span>.</span>mkShell { </span> </span>packages </span>= with </span>pkgs; [ </span> zola </span> ]</span>; </span> }</span>; </span>} </span></code></pre> Starting with the packages.website</code> output, this output builds a package called website</code>. This package includes a derivation called ${pname}-${version}</code>, which in this case will just be static-website-2021-11-19</code>. This derivation's src</code> is the current directory, ./.</code> and it depends on the package pkgs.zola</code>. Nix derivations are built using phases. The build phase here runs the command zola build</code>, and the install phase runs the command cp -r public $out</code>. The end result will be that it builds the Zola site in the current directory and puts its generated contents in the $out</code> directory, which by default is a symlink called result</code> that's linked to the Nix store.</p> Now onto the defaultPackage</code> output, this output is pretty simple. All it does is set the default output to get when running nix build</code> to the output called packages.website</code> that we just went over.</p> And finally, the devShell</code> output, this is the output you will use to develop your website. What this output does is create a new shell environment with the package pkgs.zola</code> inside it. In order to enter that shell you have to run nix develop</code> in the root of the flake/repo.</p> The complete flake.nix recipe</h3> This is the complete flake.nix for the explanation we went over above. You are more than welcome to use it for your own site.</p> { </span> </span>description </span>= </span>"A flake for developing and building my personal website"</span>; </span> </span> </span>inputs</span>.</span>nixpkgs</span>.</span>url </span>= </span>"github:nixos/nixpkgs/nixpkgs-unstable"</span>; </span> </span>inputs</span>.</span>flake-utils</span>.</span>url </span>= </span>"github:numtide/flake-utils"</span>; </span> </span> </span>outputs </span>= </span>{ self</span>, </span>nixpkgs</span>, </span>flake-utils }: </span> flake-utils</span>.</span>lib</span>.</span>eachDefaultSystem (system: </span> </span>let </span> </span>pkgs </span>= </span>nixpkgs</span>.</span>legacyPackages</span>.</span>${system}</span>; </span> </span>in </span> { </span> </span>packages</span>.</span>website </span>= </span>pkgs</span>.</span>stdenv</span>.</span>mkDerivation </span>rec </span>{ </span> </span>pname </span>= </span>"static-website"</span>; </span> </span>version </span>= </span>"2021-11-19"</span>; </span> </span>src </span>= </span>./.</span>; </span> </span>nativeBuildInputs </span>= </span>[ pkgs</span>.</span>zola ]</span>; </span> </span>buildPhase </span>= </span>"zola build"</span>; </span> </span>installPhase </span>= </span>"cp -r public $out"</span>; </span> }</span>; </span> </span>defaultPackage </span>= </span>self</span>.</span>packages</span>.</span>${system}</span>.</span>website</span>; </span> </span>devShell </span>= </span>pkgs</span>.</span>mkShell { </span> </span>packages </span>= with </span>pkgs; [ </span> zola </span> ]</span>; </span> }</span>; </span> } </span> )</span>; </span>} </span></code></pre> But there is more! - Declarative Zola themes management</h3> If you want to go overkill</strong> you can even manage your Zola themes declaratively as flake inputs. This is a bit more hacky than you might think. What we are doing here is actually adding another src</code> of some sort into the build sandbox, in the configuration phase, right before the build phase. One of the things people always try to achieve when writing Nix code is making it as modular as possible. I tried to get it as modular as possible by writing a variable with the value of the theme name that is specified inside the theme's theme.toml</code>. It was done by squashing together a couple of fancy</em> built-in functions, builtins.fromTOML</code> and builtins.readFile</code>. These functions convert the TOML file into a Nix file and then grab the value of name</code> inside.</p> themeName </span>=</span> ((</span>builtins.</span>fromTOML (</span>builtins.</span>readFile </span>"</span>${</span>deepthought</span>}</span>/theme.toml"</span>))</span>.</span>name)</span>;</span> </span></code></pre> In the configuration phase, we create a directory (two actually, if you consider the parent one) that is named after the value of ${themeName}</code>, which we set before. Now a simple cp -r</code> to copy the contents of the deepthought</code> (the theme used in this case) flake input. This will make the theme available in the sourceRoot</code>. For making development easier, we can add a shell hook to the mkShell</code> , which will symlink the content of the theme's input to themes/${themeName}</code> so we can use zola serve</code> as normal.</p> The finished and only slightly</em> overkill</strong> flake.nix</code> is available below, and anyone</em> is free to use it.</p> { </span> </span>description </span>= </span>"A flake for developing and building my personal website"</span>; </span> </span> </span>inputs</span>.</span>nixpkgs</span>.</span>url </span>= </span>"github:nixos/nixpkgs/nixpkgs-unstable"</span>; </span> </span>inputs</span>.</span>flake-utils</span>.</span>url </span>= </span>"github:numtide/flake-utils"</span>; </span> </span>inputs</span>.</span>deepthought </span>= </span>{ </span>url </span>= </span>"github:RatanShreshtha/DeepThought"</span>; </span>flake </span>= false</span>; </span>}</span>; </span> </span> </span>outputs </span>= </span>{ self</span>, </span>nixpkgs</span>, </span>flake-utils</span>, </span>deepthought }: </span> flake-utils</span>.</span>lib</span>.</span>eachDefaultSystem (system: </span> </span>let </span> </span>pkgs </span>= </span>nixpkgs</span>.</span>legacyPackages</span>.</span>${system}</span>; </span> </span>themeName </span>= </span>((</span>builtins.</span>fromTOML (</span>builtins.</span>readFile </span>"</span>${</span>deepthought</span>}</span>/theme.toml"</span>))</span>.</span>name)</span>; </span> </span>in </span> { </span> </span>packages</span>.</span>website </span>= </span>pkgs</span>.</span>stdenv</span>.</span>mkDerivation </span>rec </span>{ </span> </span>pname </span>= </span>"static-website"</span>; </span> </span>version </span>= </span>"2021-11-19"</span>; </span> </span>src </span>= </span>./.</span>; </span> </span>nativeBuildInputs </span>= </span>[ pkgs</span>.</span>zola ]</span>; </span> </span>configurePhase </span>= </span>'' </span> mkdir -p "themes/</span>${</span>themeName</span>}</span>" </span> cp -r </span>${</span>deepthought</span>}</span>/* "themes/</span>${</span>themeName</span>}</span>" </span> ''</span>; </span> </span>buildPhase </span>= </span>"zola build"</span>; </span> </span>installPhase </span>= </span>"cp -r public $out"</span>; </span> }</span>; </span> </span>defaultPackage </span>= </span>self</span>.</span>packages</span>.</span>${system}</span>.</span>website</span>; </span> </span>devShell </span>= </span>pkgs</span>.</span>mkShell { </span> </span>packages </span>= </span>[ pkgs</span>.</span>zola ]</span>; </span> </span>shellHook </span>= </span>'' </span> mkdir -p themes </span> ln -sn "</span>${</span>deepthought</span>}</span>" "themes/</span>${</span>themeName</span>}</span>" </span> ''</span>; </span> }</span>; </span> } </span> )</span>; </span>} </span></code></pre> And that's about it, thanks for reading my first ever blog post!</strong></p>

Using SSH Resident Keys With a YubiKey 5

Building websites using Nix Flakes and Zola

A quick first blog post introduction</h3> Welcome! This is my new and only website, where I will share my finest thoughts and ideas. I have been procrastinating for a while about creating my own blog, but here it is! 🎉</p>

A quick first blog post introduction</h3>
Welcome! This is my new and only website, where I will share my finest thoughts and ideas.
I have been procrastinating for a while about creating my own blog, but here it is! 🎉</p>