• 3 Posts
  • 180 Comments
Joined 1 year ago
cake
Cake day: April 27th, 2024

help-circle



  • Hm, fair enough, I actually have very little experience with XMPP. (Only through prosody, which I personally am on a war footing with.) From a cursory glance, I also couldn’t find an Android lient I’d really want to use, but of course that is subjective.

    In any case: I have a matrix server up and running, and it has been a pain to get friends and family on there; I do not want to do all of that again with a new protocol/clients. As long as it’s sustainable, I want to stay with the same server installation, and that means choosing a conduwuit for me.


  • There’s nothing technically wrong with it, it’s just a glacial development speed. I tried contributing there myself when I wanted a specific feature (which had been requested years prior by someone else and was deemed a good idea), it took months before I even got a single comment back.

    In the meantime, I had switched to conduwuit because it was a much, MUCH more active project. However, conduwuit has diverged substantially from conduit, including irreconcilable database changes, so it is not possible to migrate back, that would require starting from a fresh slate and loosing all user data.






  • We have NixOS, Proxmox and TrueNAS in use.

    • TrueNAS on a dedicated NAS host. It’s great for that, and has been super stable. The snapshotting works great, and all the little tasks associated with a NAS are taken care of without needing to spare a thought.
    • Proxmox as VMS host. You haven’t mentioned it above, so I’ll leave it at this: also works really well for its purpose.
    • NixOS: acouple dozen NixOS VMs runnign on the Proxmox hosts. I like the separation (i.e.: one VM <-> one task/service), but it’s not necessary, esp. if you plan on using a stable branch. I absolutely love NixOS, and would never run server applications on anything else ever again. The documentation thing is trueish. There’s not even close to the same documentation as with e.g. Arch and the Arch Wiki, but that makes sense when you think about it: instead of hundreds of lines of documentation, you hide that complexity behind an option, e.g. graphics.nvidia.enable = true; which then becomes pretty self-explanatory, at least if you are somewhat familiar with the ecosystem already. The way I’d recommend going about documentation with nix is this:
      • go to search.nixos.org/options, search for the service you would like to host. 90% of the time, the options and descriptions shown are all you need.
      • if an option is unclear, click on its “declared in” link. You’ll be taken to the module source in nixpkgs. Look at what they are doing there/the comments explaining why. Often, this resolves any ambiguity, or helps you out with your goal.
      • if that did not help, check the NixOS wiki; often, common pitfalls are documented there, together with the nix expression to fix them.
      • another great way is to search GitHub for language:nix <thing you need to do>. As a random example: I recently wasn’t sure how to configuring scaling in hyprland on NixOS, but searching for an appropriate term will quickly show you how other people have solved the same problem. It’s not really documentation, but the declarative nature of nix means it’s easy to find TONS of working examples via a github search.
      • all else failing, ask on discourse.nixos.org. Youńll usually get useful help very quickly there.

    So, what’s my advice?

    If you are unfamiliar with NixOS, it’s probably a bit of a headache getting a NAS to run satisfactory. Truenas works so well, there isn’t really a need for nix. But running your services in nix is great, totally recommend!




  • Can’t believe noone mentioned this yet:

    Any good password manager encrypts and decrypts your password file client side. The server should not even have the ability to read your passwords.

    Even in the case of a leak of all of the server’s data, as long as your password for the manager was good, you’ve got nothing to worry about.

    I’d say pick a PW manager where both client and server are open source. Pick a strong passphrase. Enjoy.


  • Yeah, but no dark magic involved.

    • build image
    • copy to proxmox ISO store
    • import, resize disk
    • start, wait to come online
    • read ssh pubkey, save it
    • rekey secrets
    • rebuild VM

    The only “magic” parts are two nix modules for handling proper networking and hardware setup, and exposing required attributes to the script.

    Works really well, zero manual config (beyond the services you want to run…) required on nix or proxmox side.



  • Funny - same thing here. Got 3 proxmox hosts running, all virtual machines are NixOS though.

    I’d love to go full Nix, but between my GF and I, we kinda split the responsibilities: hardware is hers, applications are mine. And there’s not a chance she’ll give up her Proxmox hosts 😄

    Got it automated to a single “provision” command though that will spin up any of my nix VMS unanttended, so I’m happy with that.