talkingpumpkin

joined 2 years ago
[–] talkingpumpkin@lemmy.world 3 points 6 days ago (1 children)

you will have to spend a lot of time learning the Nix language

I'd say you shouldn't use any system (be it nixos, ansible or even bash scripts) if you are not willing to learn it.

That said, I too find pre-made modules less useful that I initially thought when I got into nixos: unless you want to do very basic stuff, a lot of times it's easier to just generate whatever scripts/configuration files you need directly (using one of the trivial builders in lib or writing a custom derivation) rather than learning how the corresponding nixos module works.

One could say nixos modules make easy things slightly easier, and hard things much harder (this is adapted - possibly imprecisely - from a quote on ORMs, I think by Joel Spolsky).

[–] talkingpumpkin@lemmy.world 8 points 6 days ago

In your shoes (and, in fact, in mine) I'd try to move away from interactive tools and into file-driven ones.

Personally I use nixos, run WUD (what's up docker) to be notified of available updates, and manually test/update the containers once in a while (every couple weeks or so?)

There are a bazillion other solutions (from stuff like ansible/chef/puppet, to docker-compose, to kubernetes, to... a hand-written bash script) - the idea is to setup stuff via files that you can version, reference and write comments in rather than using some gui for interactive steps that you'll forget to document in some wiki.

Monitoring is a whole different beast than configuring: you'll be probably better off using something that does just that instead of some all-in-one solution. Try looking into something like beszel before going for the full prometheus/graphana stack.

[–] talkingpumpkin@lemmy.world 2 points 6 days ago (2 children)

domain-driven design (or development?)

I'm not 100% what it is (I'm really not into nomenclature), but I think it's the practice of modeling your software after the domain you are working in... IDK if/how it differs from what everyone has always been doing since forever.

[–] talkingpumpkin@lemmy.world 7 points 1 week ago* (last edited 1 week ago)

It would seem my point is not getting through (ie. I must not have expressed it well enough).

You having freedom doesn't mean other people have a duty to support what you do - it just means they don't have legal ground to stop you.

For example, freedom of speech doesn't mean that newspaper must publish whatever you write - it just means the police won't come knocking on your door at 5am because you of something you wrote.

The "idea of linux" (by which I take you mean the idea of FOSS in general, not of the kernel specifically) isn't to support anything and everything.

Does dropping 32 bit go against the "idea of linux"? Does software being developed/tested only on specific distros go against it? Do devs that only supporting glibc because they don't care about musl go against the idea of linux?

I’m just expressing a concern where over relying on one init system will limit options

Nope, nothing actually limits the options of people who don't like systemd: if they want to run some FOSS piece of software whose upstream devs don't care about openrc (or whatever init of choice), they'll just have to fork the projects, put the work in, and the upstream devs won't be able to stop them in any way.

This is what the "freedom" in FOSS means. Twisting it to mean that upstream goes against "the idea of linux" if they don't support whatever thing you care about and they don't is entitled.

[–] talkingpumpkin@lemmy.world 33 points 1 week ago* (last edited 1 week ago) (4 children)

this doesn’t go with the idea of Linux, which is having “freedom” with your os

Err... it's "freedom" as in "you are free to run your own system using whatever software you wish" not "freedom" as in "distros and devs have a duty to support your freedom to run any specific software you happen to like".

Let's turn down the entitlement dial a bit.

[–] talkingpumpkin@lemmy.world 2 points 3 weeks ago

TLDR:

Current status for 26.04 LTS

We shipped rust-coreutils as the default in Ubuntu 25.10 to maximise real-world testing ahead of the LTS. Based on the audit findings and remediation progress, here is where we stand for Ubuntu 26.04 LTS.

We have included the latest upstream release 0.8.0 in Ubuntu 26.04, which incorporates the bulk of the security fixes.

cp, mv, and rm continue to be provided by GNU coreutils in 26.04. These utilities have remaining open TOCTOU (time-of-check to time-of-use) issues (8 as of Apr 22, 2026) that need to be resolved before we are confident shipping them.

Our plan is to address the remaining issues as soon as possible and target Ubuntu 26.10 with 100% rust-coreutils.

[–] talkingpumpkin@lemmy.world 16 points 1 month ago (2 children)

Does https://www.olivetin.app/ look like what you have in mind?

[–] talkingpumpkin@lemmy.world 2 points 1 month ago (1 children)

(OT) what did you use to annotate the picture?

[–] talkingpumpkin@lemmy.world 1 points 2 months ago* (last edited 2 months ago)

Still, some neckbeards only wanna use software from orgs who are in it “for the love of the game”.

Nope, that's just you fighting strawmen and labelling people who don't hold your same opinion "neckbeards".

I would be excited for a new FOSS browser regardless of specific features, and I could be excited for a non-FOSS one if it had particularly promising features that are not provided by any FOSS browser. As far as I can see, Orion does not fall in either category.

BTW marketing a product for its privacy (or security) without it being open source amounts to having "trust me bro" as a slogan... of course one is free to trust whoever they want to.

[–] talkingpumpkin@lemmy.world 0 points 2 months ago (3 children)

It's not FOSS, so I couldn't possibly care less. That said, best of luck to you!

[–] talkingpumpkin@lemmy.world 3 points 2 months ago (1 children)

I've not looked into it much yet, but https://radicle.xyz/ seems interesting.

It's kinda a bittorrent-powerd codeberg and it looks like it's worth playing around with (even though it might not get you rid of much bandwidth... IDK how popular it is, but source usually doesn't weigh that much).

[–] talkingpumpkin@lemmy.world 1 points 2 months ago (2 children)

Getting the router to actually assign an IP address to the server

You would typically want to use static ip addresses for servers (because if you use DHCP the IP is gonna change sooner or later, and it's gonna be a pain in the butt).

IIRC dnsmasq is configured to assign IPs from .100 upwards (unless you changed that), so you can use any of the IPs up to .99 without issue (you can also assign a DNS name to the IP, of course).

all requests’ IP addresses are set to the router’s IP address (192.168.3.1), so I am unable to use proper rate limiting and especially fail2ban.

Sounds like you are using masquerade and need DNAT instead. No idea how to configure that in openwrt - sorry.

 

Here it is https://codeberg.org/gmg/concoctions/src/branch/main/sh-scripts/nixos-rebuild

(if you try it and find any bugs, please let me know)

edit: I didn't realize the screenshot shows just instead of nixos-rebuild... that runs a script ("recipe") that calls nixos-rebuild so the output shown is from the (wrapped) nixos-rebuild

 

I'm trying to get my scripts to have precedence over the home manager stuff.

Do you happen to know how to do that?

(not sure it's relevant, but I'm using home-manager in tumbleweed, not nixos)


edit:

Thanks for the replies - I finally got time to investigate this properly so here's a few notes (hopefully useful for someone somehow).

~/.nix-profile/bin is added (prepended) to the path by the files in /nix/var/nix/profiles/default/etc/profile.d/, sourced every time my shell (fish, but it should be the same for others) starts (rg -L nix/profiles /etc 2> /dev/null for how they are sourced).

The path I set in homemanager (via home.sessionPath, which is added (prepended) to home.sessionSearchVariables.PATH) ends up in .nix-profile/etc/profile.d/hm-session-vars.sh, which is sourced via ~/.profile once per session (I think? certainly not when I start fish or bash). This may be due to how I installed home-manager... I don't recall.

So... the solution is to set the path again in my shell (possibly via programs.fish.shellInitLast - I din't check yet).

47
submitted 3 months ago* (last edited 3 months ago) by talkingpumpkin@lemmy.world to c/selfhosted@lemmy.world
 

I'd like to give my users some private network storage (private from me, ie. something encrypted at rest with keys that root cannot obtain).

Do you have any recommendations?

Ideally, it should be something where files are only decrypted on the client, but server-side decryption would be acceptable too as long as the server doesn't save the decryption keys to disk.

Before someone suggests that, I know I could just put lucks-encrypted disk images on the NAS, but I'd like the whole thing to have decent performance (the idea is to allow people to store their photos/videos, so some may have several GB of files).


edit:

Thanks everyone for your comments!

TLDR: cryfs

Turns out I was looking at the problem from the wrong point of view: I was looking at sftpgo and wondering what I could do on the server side, but you made me realise this is really a client issue (and a solved one at that).

Here's a few notes after investigating the matter:

  • The use case is exactly the same as using client-side encryption with cloud storage (dropbox and those other things we self-hoster never use).
  • As an admin I don't have to do anything to support this use case, except maybe guiding my users in choosing what solution to adopt.
  • Most of the solutions (possibly all except cryfs?) encrypt file names and contents, leaking the directory structure and file size (meaning I could pretty much guess if they are storing their photos or... unsavory movies).
  • F-droid has an Android app (called DroidFS) that support gocryptfs and cryfs

I'll recommend my users try cryfs before any other solution. Others that may be worth it looking at (in order): gocryptfs, cryptomator, securefs.

I'll recommend my users to avoid cryptomator if possible, despite its popularity: it's one of those commecrial open source projects with arbitrary limitations (5 seats, whatever that means) and may have nag screens or require people to migrate to some fork in the future.

ecryptfs is to be avoid at all costs, as it seems unamaintaned.

19
submitted 7 months ago* (last edited 7 months ago) by talkingpumpkin@lemmy.world to c/europe@feddit.org
 

Delusional.

 

A lot of selfhosted containers instructions contain volume mounts like:

docker run ...
  -v /etc/timezone:/etc/timezone:ro \
  -v /etc/localtime:/etc/localtime:ro \
  ...

but all the times I tried to skip those mounts everything seemed to work perfectly.

Are those mounts only necessary in specific cases?

PS:

Bonus question: other containers instructions say to define the TZ variable. Is that only needed when one wants a container to use a different timezone than the host?

 

Prometheus-alertmanager and graphana (especially graphana!) seem a bit too involved for monitoring my homelab (prometheus itself is fine: it does collect a lot of statistics I don't care about, but it doesn't require configuration so it doesn't bother me).

Do you know of simpler alternatives?

My goals are relatively simple:

  1. get a notification when any systemd service fails
  2. get a notification if there is not much space left on a disk
  3. get a notification if one of the above can't be determined (eg. server down, config error, ...)

Seeing graphs with basic system metrics (eg. cpu/ram usage) would be nice, but it's not super-important.

I am a dev so writing a script that checks for whatever I need is way simpler than learning/writing/testing yaml configuration (in fact, I was about to write a script to send heartbeats to something like Uptime Kuma or Tianji before I thought of asking you for a nicer solution).

view more: next ›