Alper Çelik's blog

Self Hosting Vaultwarden and Setting up SSL Certificates under Tailscale in Nixos

dev.alpercelik@gmail.com (Alper Çelik) — Tue, 15 Oct 2024 00:00:00 +0000

I have been using pass but since i am experimenting with selfhosting and wanted to store passkeys inside my password manager i wanted to selfhost Vaultwarden (a Bitwarden server implementation) server but i didn’t wanted to expose it to internet so i wanted to use my Tailscale network.

so i added required config to my Raspberry 5’s Nixos config

services.vaultwarden = {
   enable = true;
};

and now i needed an easier way to access it then with ip and port so i needed to setup a reverse proxy like nginx, since i am using Tailscale i wanted to use MagicDNS feature of it but after looking at it i noticed i can’t use subdomains in it to host multiple services insede one machine since i want to try to selfhost things like nextcloud too on that machine i decided to not use MagicDNS to access my services.

Since i have a domain i decided to use that and point to static Tailscale ip of Vaultwarden server but my domain uses HSTS and HTTPS needded for some feutures of Bitwarden so i needed SSL Certificates for my Vaultwarden instance.

It would have been easy if it were a service exposed to the internet since Nixos has support for automatically getting certificate from Let’s Encrypt and automatically renewing them but it uses HTTP-01 challenge by default to prove ownership of the domain so i needed a better solution since the IP of the domain wasn’t exposed to the internet. Solution was using DNS-01 challenge since it uses dns records to prove ownership it doesn’t need the domain to be accessible from the internet and the best part is Nixos supported using DNS-01 challenge when configured with dns api key etc.

I added my cloudflare api key to my sops-nix repo and added them to my rpi5 secrets definitions:

sops = {
  secrets = {
    CLOUDFLARE_API_KEY = { };
    CLOUDFLARE_EMAIL = { };
  };
};

and then configured acme settings to use DNS-01 challenge:

security.acme = {
  acceptTerms = true;
  defaults = {
    email = "alper@alper-celik.dev";
    dnsProvider = "cloudflare";
    credentialFiles =
      let
        s = config.sops.secrets;
      in
      {
        CLOUDFLARE_API_KEY_FILE = s.CLOUDFLARE_API_KEY.path;
        CLOUDFLARE_EMAIL_FILE = s.CLOUDFLARE_EMAIL.path;
      };
    dnsResolver = "1.1.1.1:53";
  };
};

and lastly i added Nginx reverse proxy config:

services.nginx.enable = true;
services.nginx.virtualHosts."bitwarden.lab.alper-celik.dev" = {
  enableACME = true;
  forceSSL = true;
  locations."/" = {
    proxyPass = "http://localhost:${toString config.services.vaultwarden.config.ROCKET_PORT}";
  };
};

Then i deployed my changes and it didn’t used DNS-01 challenge and failed, after a bit of digging i found out i needed to set acmeRoot to null so i added that:

services.nginx.virtualHosts."bitwarden.lab.alper-celik.dev".acmeRoot = null;

After deploying again i had access to it inside my Tailscale network.

But i wasn’t over yet, i still needed to migrate 30 or so passwords from pass, after searching a bit i came across this python script: pass2bitwarden after reviewing its code i converted my password store to bitwarden format and it migrated almost everything including 2fa codes but it didn’t migrated custom fields so i manually migrated them.

and that was it. I now had a bit more polished password manager that i hosted. It was fun to setup.

Using Free Tier Noip Dynamic Dns with Your Own Domain Name

dev.alpercelik@gmail.com (Alper Çelik) — Thu, 09 May 2024 00:00:00 +0000

Since getting myself a raspbery pi 5 and getting a proper internet infrastructure at home i wanted to get into some form of selfhosting. but not having static ip prevented me from having an easy way to access raspbery pi from internet.

i did try to not care at first but ip address changes every several days and that forces me to update it regularly.

as a solution i looked at the dynamic dns services and no-ip had free tier option but in free tier you have to use a domain name under their domain like example.ddns.net

I didn’t wanted to use their domain name so i didn’t manualy updated my ip address when things broke for a while

after some thinking i remembered i needed to set CNAME records for setting up github pages on my domain name so i looked at what exactly is CNAME records are and read the awesome blogpost by Cloudflare explaining what they are.

so CNAME records allows you to point that domain to ip address of another domain name so my CNAME record pointing at alper-celik.github.io will resove ip of alper-celik.github.io and use that ip address to acces my domain.

also good thing is since webservers get the domain you’r coming from they can serve different content to different domains from same ip address.

so i created free tier no-ip account and set it up according to the getting started guide and then i added CNAME record pointing my domain to their dynamic domain so by doing that i have dynamic dns under my domain name using no-ip’s free tier

My First Contributions to nixpkgs and open source

dev.alpercelik@gmail.com (Alper Çelik) — Mon, 01 Jan 0001 00:00:00 +0000

in this blogpost i hope to explain my experience of contributing to nixpkgs until this moment

Note: i am not a native english speaker please let me know my mistakes and help me improve my english

Creating my first package (derivition)

i was working on my experimental accessibility program when working on accessibility abstraction of it i wanted to reflect over enums on c++ for looping over enums, doing map lookups, and for printing in program names of atspi enums for doing theses i wanted to use magic enum library for doing these but this wasn’t packaged in nixpkgs unlike my other dependencies so i went ahead and created a simple derivation(package) in my flake.nix

inputs = {
     magic-enum-repo = {
       url = "github:Neargye/magic_enum/v0.8.2";
       flake = false;
     };
}

firstly i added magic enum as a flake input and then

outputs =
...
let
pkgs = nixpkgs.legacyPackages.${system};
magic-enum = pkgs.stdenv.mkDerivation
  {
    pname = "magic-enum"; #1
    version = "0.8.2";

    src = magic-enum-repo; #2

    nativeBuildInputs = with pkgs; [ cmake ]; #3

    doCheck = true; #4
  };
in
...

i created a simple derivition:

wrote the name and version
added source from flake input
i added cmake build system as build time dependency
enabled tests to be sure library works properly

it was pretty easy to be fair magic enum is pretty trivial to package library it had cmake install scripts so nix automatically installed it to $out and it didn’t had any dependency except c++ compiler lastly it didn’t had any fetch_content() calls in cmake so no network sandbox complexity too

since it was easy to package i wanted to upstream it so i looked up how to contributing guide of nixpkgs and contributing section of nixpkgs manual then i forked and shallow cloned nixpkgs

added myself as maintainer as maintainer and commited to my fork with commit message format required for changes

...
Alper-Celik = {
    email = "dev.alpercelik@gmail.com";
    name = "Alper Çelik";
    github = "Alper-Celik";
    githubId = 110625473;
    keys = [{
      fingerprint = "6B69 19DD CEE0 FAF3 5C9F  2984 FA90 C0AB 738A B873";
    }];
  };
...

modified derivition to use fetchFromGitHub instead of simpler flake input

...
  src = fetchFromGitHub {
    owner = "Neargye";
    repo = "magic_enum";
    rev = "v${version}";
    sha256 = "sha256-...";
  };
...

added meta data about package

...
meta = with lib;{
    description = "Static reflection for enums (to string, from string, iteration) for modern C++";
    homepage = "https://github.com/Neargye/magic_enum";
    license = licenses.mit;
    maintainers = with maintainers; [ Alper-Celik ];
  };
...

lastly navigated (it at least had some organization) pkgs/top-level/all-packages.nix for finding correctish spot for package and i found it about at 22.000 th line

# about 22.000 lines
...
  magic-enum = callPackage ../development/libraries/magic-enum { };
...
# who knows how many lines at the bottom of file

and i was ready to create pr for it i created and waited about a week and @NickCao pointed out i forget to format package commit message and [recommended formatting package dependencies with nixpkgs-fmt. i was actually using nixpkgs-fmt with nul-ls.nvim, it was actually formatted but when i put one dependency to other line it expanded and this fixed formatting. to be fair i was put the formatted the pr message like that and forget to actually format commit message i fixed that.

after fixing problems with pr i thanked @NickCao for reviewing my pr with my perfect english.

after about a day later @NickCao merged my pr and i was officially a nixpkgs package maintainer

after a while i backported to 22.11 release because i was using stable release on my flake.nix and it got quickly merged by @superherointj too

after some more time i switched to using unstable release system wide instead of having stable and unstable nixos side by side this broked running Qt info gui when developing because Qt program wasn’t wrapped while developing so i updated my flake.nix to nixos-unstable too but then it started to build magic-enum instead of fetching from binary cache and failed i guess binary cache failed too and because of that nix tried to build it. after looking to logs it was about some wide characters (emojis) while building unit tests, after looking into issues tacker of magic-enum i saw it was a problem with building on gcc 12 and unstable releases updating to gcc 12 broked the package, i submitted a pr disabling building of the tests

# last shape of the pr:

# disable tests until upstream fixes build issues with gcc 12
# see https://github.com/Neargye/magic_enum/issues/235
doCheck = false;
cmakeFlags = [
  "-DMAGIC_ENUM_OPT_BUILD_TESTS=OFF"
];

after @wegank helped me with grammar, layout of the sentences and misspellings (he fixed them) he merged the pr. i will probably enable tests on next version of the library if building tests on the latest compilers gets fixed by then lastly there was no need to backport this pr since stable(22.11) was still using gcc 11