Self Hosted - Self-hosting your services. rutrum • Now • 100%

What to add to your SHTF document? What do you put in the paper document that contains instructions for disaster recovery, such as drive failure, cloud service loss, death, etc?

I just setup my first automated and encrypted backup with borg. It's got me thinking about other chaotic events, and how to respond accordingly. I figured now is a good time to document my infrastructure: hardware, network, a files. This way if something bad happens, like my house burns down, I or a family member has instructions for how to quickly recover data and services. Examples: 1. If my website goes down, with my nextcloud on it, what steps do I need to take to recover the data and restore service? 2. If my harddrive fails, how do I access lost data and reimplement redundancy after a replacement is stood up? 3. If someone important to me needs to access encrypted files, how can that access that data and get access to the passwords/encryption keys? 4. If my phone bricks, how to recover 2fa codes? So I'd like to have a physical printing copy that tries to cover these emergency scenarios. Of course, I'll have digital copy around as well. I'm focusing more on digital assets, like encryption keys, personal files and media, cloud service access, accessing inaccessible machines, how to restart/recover from self hosted service if its down, etc. I understand how much wider this document can be to include physical assets, so to start I want to start with digital infrastructure. So my big questions: what scenarios should be documented in this disaster recovery document? What should I prepare for? The nice correlary of this is that documenting a recovery plan will force me to actually stand up the backups/redundancy needed to recover.

Linux rutrum • Now • 100%

Recommended whiteboarding programs?

I just got a drawing tablet, and have been wanting some software that would allow me to work out math problems, draw architecture diagrams, etc. I've seen some tools like Excalidraw, which look handy for the sharing capabilities. I also have just used plain krita, which has great feedback for the pen sensitivity, but obviously is overkill for whiteboarding. Are there any tools you use or recommend for handwriting or picture drawing? Pen or mouse?

Coffee rutrum • Now • 94%

Anyone drink tea? Have suggestions for a simple recipe?

I love coffee, but have a surplus of tea bags that I want to experiment with. Does anyone have suggestions for how to get started with tea? Or a simple recipe to use as a baseline? I'm only working with tea bags at this time, which appear to be 2g. I would also love to know how much agitation you are supposed to do with the tea bag itself.

Selfhosted rutrum • Now • 97%

How do you manage your encryption keys?

I'm in desparate need of setting up borgmatic for borg backup. I would like to encrypt my backups. (I suppose, an unencrypted backup is better than none in my case, so I should get it done today regardless.) How do I save those keys? Is there a directory structure I follow? Do you backup the keys as well? Are there keys that I need to write down by hand? Should I use a cloud service like bitwarden secrets manager? Could I host something? Im ignorant on this matter. The most I've done is add ssh keys to git forges and use ssh-copyid. But I've always been able to access what I need to without keeping those (I login to the web interface.) Can you share with me best practices or what you do to manage non-password secrets?

Nix / NixOS rutrum • Now • 100%

NixOS module or docker container?

If given the option, which route do you go? I have services running in both, and I'll often just do whats easier. I dont really notice a different in performance the configuration for containers is simple enough I don't mind it. I also wish there was a nix function that parsed a docker compose and used it for the oci-container config. Then I could use my existing compose files or the ones I find in docs online.

Nix / NixOS rutrum • Now • 100%

Idea: NixOS configuration meant for hosting "for the common good" services, like tor relays, simplex relay, archive team warrior, etc.

This idea is inspired by nixos-mailserver. It was so easy to spin up the mailserver after changing some DNS records and putting in some settings. I thought it might be a good idea to do the same for services that need public, decentralized infrastructure to support. Some ideas include - Tor relay, or exit node - Encrypted messaging nodes. It looks like SimpleX chat relies on SMP servers to relay communication - Crypto miners (I know, I know, but you understand how it fits the “public contribution” usecase) - Search engines like searxng (I currently use a public instance) - Libredirect services, like proxy clients for social media Maybe federated services, but those require more than just the software running on the public internet. Those require moderation and long term maintenance. Ideally, the services in this config would be ephemeral. Does this sound like a good idea? Would you spin one of these up on a $10 VPS? I understand that this is the NixOS community, not necessarily the privacy community, but I figured thered be overlap. What other services do you think would be applicable?

NixOS rutrum • Now • 100%

Idea: NixOS configuration meant for hosting "for the common good" services, like tor relays, simplex relay, archive team warrior, etc.

This idea is inspired by nixos-mailserver. It was so easy to spin up the mailserver after changing some DNS records and putting in some settings. I thought it might be a good idea to do the same for services that need public, decentralized infrastructure to support. Some ideas include - Tor relay, or exit node - Encrypted messaging nodes. It looks like SimpleX chat relies on SMP servers to relay communication - Crypto miners (I know, I know, but you understand how it fits the "public contribution" usecase) - Search engines like searxng (I currently use a public instance) - Libredirect services, like proxy clients for social media Maybe federated services, but those require more than just the software running on the public internet. Those require moderation and long term maintenance. Ideally, the services in this config would be ephemeral. Does this sound like a good idea? Would you spin one of these up on a $10 VPS? I understand that this is the NixOS community, not necessarily the privacy community, but I figured thered be overlap. What other services do you think would be applicable?

Linux rutrum • Now • 94%

Unable to run TabbyML with GPU on NixOS or Docker (solved on docker!)

[TabbyML](https://tabby.tabbyml.com/docs/welcome/) is a self-hosted code assistant. I have been unsuccessful at running it using my Nvidia GPU. There's two ways I've tried to deploy this. ## As a docker container Following the docs, it states I run the following docker run command. Below is what I run, modified to use the correct port: ``` docker run -it --gpus all \ -p 11029:8080 -v $HOME/.tabby:/data \ tabbyml/tabby serve --model StarCoder-1B --device cuda ``` Then I get the following error: ``` docker: Error response from daemon: could not select device driver "" with capabilities: [[gpu]]. ``` So this would appear that I don't have the "nvidia-container-toolkit" installed on my machine. So I go ahead and enable this in nixos: ``` hardware.nvidia-container-toolkit.enable = true; ``` To validate that this works, I should be able to run `nvidia-smi` from within a container. I can run this from the host without issue: ``` $ nvidia-smi Wed Jun 5 08:14:50 2024 +-----------------------------------------------------------------------------------------+ | NVIDIA-SMI 550.78 Driver Version: 550.78 CUDA Version: 12.4 | |-----------------------------------------+------------------------+----------------------+ ...and so on ``` But if test this from a container, [as the nvidia docs suggest](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/sample-workload.html) as follows, I unable to access it from within the container. ``` $ sudo docker run --rm --runtime=nvidia --gpus all ubuntu nvidia-smi docker: Error response from daemon: unknown or invalid runtime name: nvidia. ``` Okay, so I go and read the instructions further. Install instructions state that after installation, I need to configure the runtime like so: ``` $ sudo nvidia-ctk runtime configure --runtime=docker sudo: nvidia-ctk: command not found ``` Ah nuts. That's a bug in nixos. I made a PR for this here: https://github.com/NixOS/nixpkgs/pull/317199 Still awaiting results from this. I don't know if this is a bug that will be backported to 24.05. Regardless, _I wouldn't expect this ad-hoc configuration when I enable the nvidia-container-toolkit option in NixOS_. Anyway, this option could still work but with some more time. If you have advice doing this let me know. ## **FOUND** Docker method solution So looking closer at people with the error message "no such runtime nvidia" I found [this thread](https://stackoverflow.com/questions/52865988/nvidia-docker-unknown-runtime-specified-nvidia). It specifies that what `nvidia-ctk` is supposed to do is add a "runtime" that points to the `nvidia-container-runtime` executable. So I tried manually adding that my nixos configuration by using the `virtualisation.docker.daemon.settings` options. I was having trouble getting that working, because I needed to find the exact path to the `nvidia-container-runtime` executable. If you know Nix, you know that it isn't just in `/usr/bin/`. But that's still not a satisfying solution anyway...I shouldn't have to this. I went in deeper and looked at module for `nvidia-container-toolkit`. This module calls a script called [cdi-generate.nix](https://github.com/NixOS/nixpkgs/blob/499c8c27aa1d4d792730198569b0bff6ea62258f/nixos/modules/services/hardware/nvidia-container-toolkit/cdi-generate.nix). It outputs the results of nvidia-ctk to a file called `nvidia-container-toolkit.json`. Let's go look for that file...can't find it. I do more searching...anyway, I found the solution. The `nvidia-container-toolkit` is a new option in NixOS 24.05. It explicitly states in the release notes that it is supposed to replace the now deprecated `virtualisation.{docker, podman}.enableNvidia` options. Well, when you go [look at the module that defines docker.enableNvidia](https://github.com/NixOS/nixpkgs/blob/nixos-24.05/nixos/modules/virtualisation/docker.nix#L251) you see it there at the bottom! This file actually defines the nvidia runtime! And yes, it works. Using the now "deprecated" option is the one that actually works. I guess this is another bug to file to NixOS. This seems to work so far, but I don't know why the solution using a NixOS module doesn't work either. ## As a NixOS module Let's just do it the full NixOS module way (which is what I tried first). That should be easy. Let's enable the feature and set some options: ``` services.tabby = { enable = true; port = 11029; acceleration = "cuda"; }; networking.firewall.allowedTCPPorts = [ 11029 ]; ``` It appears to be working! VSCodium extension sees the server and prompts for a authentication token. I add the token. I type some code and set for a manual trigger...**then tabby dies**. Let''s look at the systemd logs. ``` tabby[76786]: 📄 Version 0.11.1 tabby[76786]: 🚀 Listening at 0.0.0.0:11029 tabby[76786]: JWT secret is not set tabby[76786]: Tabby server will generate a one-time (non-persisted) JWT secret for the current process. tabby[76786]: Please set the TABBY_WEBSERVER_JWT_TOKEN_SECRET environment variable for production usage. systemd[1]: tabby.service: Main process exited, code=exited, status=1/FAILURE systemd[1]: tabby.service: Failed with result 'exit-code'. systemd[1]: tabby.service: Consumed 2.285s CPU time, received 121.0K IP traffic, sent 1.6M IP traffic ``` That's it. It's not very descriptive about what happened. I've had success running it this way using the "cpu" option for acceleration (no GPU) but that's too slow to be useful. ## GPU specs I am running a Nvidia RTX 2060 and using the proprietary drivers version 550. Thanks for the read, if you have any input on what to do next let me know what I can try. Ideally, I'd like to have both options work, since I think the docker implementation may have the same problem as the NixOS module option.

Selfhosted rutrum • Now • 90%

"No code" databases

I've been seeing easy ways to store and view tabular data. I'm aware of tools like nocodb, baserow, and mathesar. I'm currently playtesting nocodb. But I wanted to start a discussion on what everyone uses for easily storing tabular data, and if anyone uses these tools. I've also tried nextcloud tables but it still is very early in development from what I can tell.

Privacy Guides rutrum • Now • 100%

Best service for filing taxes?

I'm sure doing it manually is the safest, but perhaps there's a least poison for software/services for filing US taxes. What do you recommend? (or, atleast, what do you recommend steering clear of)

Privacy Guides rutrum • Now • 100%

What's the best strategy for changing to GrapheneOS?

I have a google pixel, and I know I could install grapheneOS on it. But I'm very, very hesitant, since I depend so much on my phone. This isn't like distro hopping, where I feel more comfortable hot swapping ssds, or making partitions, or using my desktop while I tinker with my laptop. My phone has a SIM and the service I depend on can't be emulated off this phone. So what do you recommend I do? Should I move my SIM (my phone service, really) to a new phone while I tinker with this one? Can I just blow up the current OS and wing it? Or maybe theres another option that would allow me to bail back to stock android in case something goes wrong. What do you think? EDIT: how I use my phone: about everything I use is from fdroid, with the occassional app from aurora. I do use my banking app to cash checks, but I don't use whatsapp, google pay, which I know arent compatible. So as far as app compatibility I dont think it'll be a problem, Im mostly worried about my phone number not working. I dont know how SIMs work like I should, I just know Ive had the strangest issues in the past with it, so Im hesitant. Thanks for the replies so far.

Beyond All Reason rutrum • Now • 100%

Favorite youtube channels for BAR?

I've been enjoying the daily commentated reciews by BrightWorksGaming

I've recently aquired the hardware to build a home server/NAS. I'd love to know some community-guided advice on tools I should consider, and what best practices are? For instance, how does redundancy work? Whay about automated backups? What OS should be running on a NAS? What utilities can I use to monitor the safety of my data? Perhaps even a guide about how to safely share that data outside my home network for personal use, or even open for the internet, without compromising my network? Thanks for the discussion

Linux rutrum • Now • 96%

What's with all these hip filesystems and how are they different?

You know, ZFS, ButterFS (btrfs...its actually "better" right?), and I'm sure more. I think I have ext4 on my home computer I installed ubuntu on 5 years ago. How does the choice of file system play a role? Is that old hat now? Surely something like ext4 has its place. I see a lot of talk around filesystems but Ive never found a great resource that distiguishes them at a level that assumes I dont know much. Can anyone give some insight on how file systems work and why these new filesystems, that appear to be highlights and selling points in most distros, are better than older ones? Edit: and since we are talking about filesystems, it might be nice to describe or mention how concepts like RAID or LUKS are related.

NixOS rutrum • Now • 100%

New Nix Wiki: NixLang Wiki

Came across a new nix wiki attempt. The announcement post is made [on discourse with high skepticism](https://discourse.nixos.org/t/announcing-nixlang-wiki/36049). But I really like it for two reasons: * For now, its incredibly informal and the barrier to entry is low. And because I can make edits directly in the web interface, it felt easy to contribute. * The creator mentions wanting this to be like the Arch wiki. In other words, contain information useful to nix users, but not necessarily nix specifically. I was able to contribute a new article about distrobox, a tool I discovered and made a post about here a month or so ago. Maybe we don't "need" another wiki, but the opportunity to contribute really made this one stand out to me. In case you all might want to contribute or learn something, I thought I would share.

NixOS rutrum • Now • 100%

What should manage your xsession?

I'm conflicted on what should handle my login manager, desktop environment, and window manager. What are the pros and cons of doing it from a nixos configurations versus a home manager configuration?

NixOS rutrum • Now • 87%

Need to run something and nix just isn't cutting it? No worries, distrobox will save the day!

I made a post a while ago asking what you do when NixOS isn't cutting it. You need a package that isn't available as a flatpak/appimage or already in nixpkgs. You don't want to build from source, because it's either too difficult or too time consuming. One suggestion was containerization or virtual machines, but those seemed too cumbersome. Well, distrobox is the tool that fixes it. Distrobox is a shell script that wraps over docker/podman to run a container of a distribution of your choice. But it does it behind a very high level API, and integrates the container environment _seemlessly_ with your host environment. It is seriously as easy as this, if you need to install something with apt inside debian. ``` $ distrobox create -n my_debian --image debian:latest $ distrobox enter my_debian ``` And bang, your in a debian container and it won't even feel like it. It automatically integrates your shell environment and maps your root directory inside the container (or something like that.) You seriously wouldn't know unless you `neofetch`. Best part is that since everything is in the nix store, every program in your environment should work, for the most part, inside this container. I've not noticed problems yet. Tada! `apt` is available in this environment and you can install what you need. Then you can run it while inside the container. From the host machine, outside the container, you can run it directly too. Say you installed program `X` in debian: ``` $ distrobox enter my_debian -- X ``` And it will just run the command and send you back to the host machine. In the case of docker, you can type `docker ps` and it will show you your debian image `my_debian` listed. There's two more things I want to do to really polish this workflow. The first is to change my shell prompt so I know that I'm actually in debian without typing neofetch! Inside the box the variable `CONTAINER_ID` is set and the hostname is modified. I've adjusted my starship prompt to look like this when inside the box: ``` distrobox:my_debian ~ $ ``` And lastly, I really want to blur the lines. If I install X in debian, I want to just call it directly from the host as `X`, not invoke my debian instance with `distrobox enter`. When you type `X` and the program is missing, bash (and fish and zsh I'm sure) runs a hook that you can look at by typing ``` $ declare -p -f command_not_found_handle ``` By overriding this, you could first have it try the inside container if it can't find the application in the host container, like so. ``` command_not_found_handle () { distrobox enter my_debian -- $@ } ``` This is not a perfect solution, but I'm still experimenting with how to integrate this both seamlessly and also not accidentally run things inside debian and not realize it. If you have suggestions for how to improve handling calling commands from the outside environment, please share. Best case might just be adding aliases for programs explicitly. For example, `alias X=distrobox enter my_debian -- X. Anyway, distrobox is the solution! This is one more barrier removed that was preventing me from moving my main computer over to NixOS. I'm so happy to have found this and wanted to share.

Linux rutrum • Now • 95%

Thanks to dust I deleted a 70 gig file on my drive

Dust is a rewrite of du (in rust obviously) that visualizes your directory tree and what percentage each file takes up. But it only prints as many files fit in your terminal height, so you see only the largest files. It's been a better experience that du, which isn't always easy to navigate to find big files (or atleast I'm not good at it.) Anyway, found a log file at .local/state/nvim/log that was 70gb. I deleted it. Hope it doesn't bite me. Been pushing around 95% of disk space for a while so this was a huge win 👍