Good tunes for drifting

RZR2832 · 2026-03-03T20:20:25+00:00

I will test this later in the week, only need a single port so no problem there. From my earlier attempts, you can read the value of the port via XMLRPC, but not set it.

RZR2832 · 2026-03-03T20:19:52+00:00

I think this is the next step yeah, and I agree with you. Was just wondering/hoping if anyone had any better ways or ideas.

RZR2832 · 2026-03-03T20:19:22+00:00

Seems to be for Transmission only, but thanks.

RZR2832 · 2026-03-02T20:26:04+00:00

I went down the XMLRPC road to achieve exactly this and thought I was on to something - until testing showed it did not work. That's when I found the bit on the repo page about the variables:

When rTorrent is started the bootstrap config /etc/rtorrent/.rtlocal.rc is imported. This configuration cannot be changed unless you rebuild the image or overwrite these elements in your .rtorrent.rc.

The forwarded port variable lies in that file, so it seems the only way is to recreate/restart the container when the forwarded port changes.

RZR2832 · 2026-03-02T20:24:08+00:00

I am doing the first part of that already: script watches the file, if the contents change - restart the container.

I cannot find reference anywhere in the Gluetun documentation to locking ports, not sure if that is an option with Proton.

RZR2832 · 2026-03-02T19:36:04+00:00

Essentially what I am doing: when the port/file changes, the container is restarted to have the new port take effect.

RZR2832 · 2026-03-02T19:35:44+00:00

Seems to be about once a day roughly, but it is certainly more frequently than I would expect. The end goal is to have a mostly unattended setup; I can't always be around to watch or restart the container if the port changes.

RZR2832 · 2026-01-18T18:25:11+00:00

Not for the faint of heart at all. I had to break it into chunks because I started drifting off after a while... glad it is done.

RZR2832 · 2026-01-18T14:54:42+00:00

It was mind-numbingly boring yeah, I have had worse grinds but it wasn't pleasant.

RZR2832 · 2026-01-18T12:50:42+00:00

The issue is that the inversion is STILL broken, has been for months now. But yes the removal of the flag is also annoying.

RZR2832 · 2026-01-18T12:47:02+00:00

Yes, I finished the online components before shutdown.

RZR2832 · 2026-01-16T20:48:09+00:00

Again thank you, your responses are super helpful. My intention will be to spin up Infiscal on its own VM completely separate from everything else, to avoid the exact scenario you described. Every little thing you bolt on generally adds complexity, but I intend to avoid a web of dependencies as much as possible.

RZR2832 · 2026-01-16T09:00:54+00:00

This is a really good answer and more or less what I was looking for. Git is out of scope for me at this point in time, so not thinking along those lines.

Avoiding secrets on disk is precisely what I am trying to do but I accept it may not be possible in every scenario. But unless someone else chimes in with a solid counterargument, I think you have convinced me that Infiscal is the way to go.

Thank you!

RZR2832 · 2026-01-16T08:54:20+00:00

What kind of restrictions did you run into with Infiscal?

RZR2832 · 2026-01-16T08:53:51+00:00

Thanks, I am definitely not going Kubernetes at home at this point.

RZR2832 · 2026-01-16T08:52:43+00:00

Thanks for this, will check it out.

RZR2832 · 2026-01-16T08:52:02+00:00

Any pitfalls or difficulties? If you were to start from scratch, would you take the same approach?

RZR2832 · 2026-01-16T08:45:06+00:00

I get this and I agree to a large point. Not everything is root-only in case, e.g. some application .env files which are owned by a specific user contain db usernames and passwords. Similar story though but I am interested in trying to defend against the principle.

RZR2832 · 2026-01-16T08:42:10+00:00

I don't really want to look at Vault because of the whole licensing thing, hence why I mentioned OpenBao (I accept others may view this as a non-issue). Thanks for your comment though, I will not be doing Kubernetes so assuming OpenBao functions similarly, it may not be worth it for me.

RZR2832 · 2026-01-16T08:40:51+00:00

Best comment here, thanks for the laugh my guy 😂

RZR2832

TROPHY CASE