talkingpumpkin

I'm looking for a forgejo cli (something similar to gh for github or glab for gitlab - neither of which I've ever used).

I found one named forgejo-cli and another named fgj but, from a quick look at the source, both seem to save my API key in a plaintext file, which... I just find unacceptable (and, frankly, quite dumb).

Do you know of any others?

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).

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.

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).

I'm not much hoepful, but... just in case :)

I would like to be able to start a second session in a window of my current one (I mean a second session where I log in as a different user, similar to what happens with the various ctrl+alt+Fx, but starting a graphical session rather than a console one).

Do you know of some software that lets me do it?

Can I somehow run a KVM using my host disk as a the disk for the guest VM (and without breaking stuff)?

I have two subnets and am experiencing some pretty weird (to me) behaviour - could you help me understand what's going on?

Scenario 1

PC:                        192.168.11.101/24
Server: 192.168.10.102/24, 192.168.11.102/24

From my PC I can connect to .11.102, but not to .10.102:

ping -c 10 192.168.11.102 # works fine
ping -c 10 192.168.10.102 # 100% packet loss

Scenario 2

Now, if I disable .11.102 on the server (ip link set <dev> down) so that it only has an ip on the .10 subnet, the previously failing ping works fine.

PC:                        192.168.11.101/24
Server: 192.168.10.102/24

From my PC:

ping -c 10 192.168.10.102 # now works fine

This is baffling to me... any idea why it might be?

Here's some additional information:

• The two subnets are on different vlans (.10/24 is untagged and .11/24 is tagged 11).

• The PC and Server are connected to the same managed switch, which however does nothing "strange" (it just leaves tags as they are on all ports).

• The router is connected to the aformentioned switch and set to forward packets between the two subnets (I'm pretty sure how I've configured it so, plus IIUC the second scenario ping wouldn't work without forwarding).

• The router also has the same vlan setup, and I can ping both .10.1 and .11.1 with no issue in both scenarios 1 and 2.

• In case it may matter, machine 1 has the following routes, setup by networkmanager from dhcp:

default via 192.168.11.1 dev eth1 proto dhcp              src 192.168.11.101 metric 410
192.168.11.0/24          dev eth1 proto kernel scope link src 192.168.11.101 metric 410

• In case it may matter, Machine 2 uses systemd-networkd and the routes generated from DHCP are slightly different (after dropping the .11.102 address for scenario 2, of course the relevant routes disappear):

default via 192.168.10.1 dev eth0 proto dhcp              src 192.168.10.102 metric 100
192.168.10.0/24          dev eth0 proto kernel scope link src 192.168.10.102 metric 100
192.168.10.1             dev eth0 proto dhcp   scope link src 192.168.10.102 metric 100
default via 192.168.11.1 dev eth1 proto dhcp              src 192.168.11.102 metric 101
192.168.11.0/24          dev eth1 proto kernel scope link src 192.168.11.102 metric 101
192.168.11.1             dev eth1 proto dhcp   scope link src 192.168.11.102 metric 101

solution

(please do comment if something here is wrong or needs clarifications - hopefully someone will find this discussion in the future and find it useful)

In scenario 1, packets from the PC to the server are routed through .11.1.

Since the server also has an .11/24 address, packets from the server to the PC (including replies) are not routed and instead just sent directly over ethernet.

Since the PC does not expect replies from a different machine that the one it contacted, they are discarded on arrival.

The solution to this (if one still thinks the whole thing is a good idea), is to route traffic originating from the server and directed to .11/24 via the router.

This could be accomplished with ip route del 192.168.11.0/24, which would however break connectivity with .11/24 adresses (similar reason as above: incoming traffic would not be routed but replies would)...

The more general solution (which, IDK, may still have drawbacks?) is to setup a secondary routing table:

echo 50 mytable >> /etc/iproute2/rt_tables # this defines the routing table
                                           # (see "ip rule" and "ip route show table <table>")
ip rule add from 192.168.10/24 iif lo table mytable priority 1 # "iff lo" selects only 
                                                               # packets originating
                                                               # from the machine itself
ip route add default via 192.168.10.1 dev eth0 table mytable # "dev eth0" is the interface
                                                             # with the .10/24 address,
                                                             # and might be superfluous

Now, in my mind, that should break connectivity with .10/24 addresses just like ip route del above, but in practice it does not seem to (if I remember I'll come back and explain why after studying some more)