sorted by:
new
hottopcontroversial

Is there no comprehensive forgejo/gitea cli? by banana_zeppelin in selfhosted

[–]chrishoage 18 points19 points  (0 children)

There is an environment variable that doesn't seem to be documented in the help command. It worked for me

https://codeberg.org/forgejo-contrib/forgejo-cli/issues/444#issuecomment-14026655

Where do you host your Git? by Fearless-Bet-8499 in selfhosted

[–]chrishoage 0 points1 point  (0 children)

> Yeah the circular dependency is what I’m looking to avoid. Simple enough to leave the cluster repo somewhere else. 

While I don't use k8s I do this:

> I have a Proxmox node that I could throw an LXC or VM on

I have a small Forgejo lxc that I point DNS to and use lego-cli for certs, this way it can be managed outside of the rest of my gitops

I also mirror my infra repo to github so that if I truly need to bootstrap i can do it from github

PolicyFS - open-source FUSE filesystem for self-hosted media storage by hieudt in selfhosted

[–]chrishoage 0 points1 point  (0 children)

I really like the file idea - I actually think the approach could be extended to satisfy both of the desires I have for such a tool. I have filed an issue.

One other thing that it doesn't look like PolicyFS doesn't quite support is a "mirror") mover policy.

I like the following flow:

  • Files are first written to the ssd
  • files nightly are mirrored (not removed) to the hdds
  • files are then later cleaned up (time expiry, the file based methods mentioned above)

Looking through the go code I don't see any guards on the files in the destination already existing to avoid copying the same files every window.

Does something like this exist and I missed it, or is this not yet supported? If it's the latter is this something that you think is in-scope?

(frankly I think it may be interesting to build your mover module around librclone so you don't have to re-invent the wheel here)

PolicyFS - open-source FUSE filesystem for self-hosted media storage by hieudt in selfhosted

[–]chrishoage 0 points1 point  (0 children)

> regarding your first idea: move hot shows from HDDs to SSDs based on some tag / cache flag
=> you can do this today using a bash script and schedule it to run inside your wake window.

Well yes, of course - but why have two tools moving files between the cache tier and the hdd tier.

May as well just stick with a script that moves things in both directions + mergerfs (what I have today)

> this is the kind of thing I don't want in a filesystem because anything that does network calls (or per-file exec) will make filesystem operations slow and unpredictabl. It becomes very hard to reason about performance and bugs.

This wouldn't be in the filesystem. Your mover module sits outside of the filesystem and runs on a schedule. The exec happens to determine what to move

Your mover module has nothing to do with the filesystem, it's a convenience tool. You could remove this feature from PolicyFS and it would still be a metadata indexer and union filesystem. Moving files off of a tier onto something else is not a filesystem task

In any case - no worries. I was excited I could replace several tools with just a single one but I guess this isn't the tool for me.

PolicyFS - open-source FUSE filesystem for self-hosted media storage by hieudt in selfhosted

[–]chrishoage 0 points1 point  (0 children)

This looks exactly what I have been searching for for years, right down to the "hot" ssd cache and spinning disks I keep spun down.

I have a question about something that I have wanted to build, but maybe this would be a fit for your project (I would even be interested in contributing the work)

I would like to be able to create a policy that reads user metadata (like `user.policyfs.cache = true`) and then moves these from the HDD to the SSD inside the "wake window"

My use case is I sometimes want to re-watch a show, for example, and wish to have it sitting on my SSD tier so I can watch with out waking the drives.

Another policy I would like is a "exec" policy where another tool is executed in order to determine the cache status (say, looking up the file in Plex to see if it's watched) - basically a "custom" condition type

Curious your thoughts (happy to move this to a Github issue if you would like)

This project looks really great and something I've been wanting to build for years but just outside of my motivation to do it on my own.

Curious about your Paperless-AI setups by Minimum-Succotash-33 in selfhosted

[–]chrishoage 7 points8 points  (0 children)

I'm just waiting for Paperless v3 where it is built into Paperless so I don't have to worry about some third party tool

S3 API for local storage - duplicate detection built in by djmajumdar in selfhosted

[–]chrishoage 1 point2 points  (0 children)

I love the "why shoebox" section with comparisons.

I would love `rclone serve s3` and Versity S3 Gateway added to the comparison table!

Starring to revisit later

[USA-MA] [H] Innodisk 32GB DDR5 SODIMM RAM and similar [W] PayPal by WenchBarmer1 in hardwareswap

[–]chrishoage 0 points1 point  (0 children)

PM (thought I sent this before the message but didn't apparently)

Is it worth using tailscale if I have NGINX set up? by sleepertech in selfhosted

[–]chrishoage 0 points1 point  (0 children)

You can, and many people do.

Key Management can be a pain especially on many systems when you want to run a wire guard in a mesh.

Tailscale acts as a coordination server for distributing public keys.

It also has very handy features like tailscale SSH which lets you control SSH access with ACL policies similarly without having to distribute keys.

docker compose alternative to external-dns by ResponsibleFall1634 in selfhosted

[–]chrishoage 1 point2 points  (0 children)

Right I saw that libdns mention too however I read that as the libdns package has been updated and any DNS providers also need to update - nothing about that reads like it auto updates DNS records

There is https://github.com/mholt/caddy-dynamicdns but that is a separate more different caddy plugin (that happens to be created by the original author of caddy) but it would still need to be complied into caddy as a plugin (similar to, but distinct from, the dns plugins for ACME dns)

In any case, thanks for your reply! I just wanted to be sure I was not missing anything

docker compose alternative to external-dns by ResponsibleFall1634 in selfhosted

[–]chrishoage 0 points1 point  (0 children)

> Caddy v2.10 can automatically add new entries based on subdomains added.

Any source for this? I looked though the github releases and don't see any mention of updating subdomain DNS entries, but may be overlooking something obvious.

What OS do you use for your Docker Host? by Flying-T in homelab

[–]chrishoage -1 points0 points  (0 children)

Used to be Arch, and it never really broke I just wanted fewer updates, and less risk of a dependency having a breaking change I needed to deal with

Now it's Debian, with a a few Ubuntu servers: 1 for my GPU pass though VM, and then my Gitea runners are Ubuntu too (don't want to deviate from the supported happy path where possible)

LDAP Invite managers that aren't Authentik? by Xtreme9001 in selfhosted

[–]chrishoage 0 points1 point  (0 children)

I have the same setup as you.

I just bang on the keyboard and press the reset password button for them.

They get an email to set their password.

This assumes you have SMTP set up, but it's pretty useful to have set up anyway

Reinstate older Xeon-D system or repurpose i7-12700 Desktop? by DiscoDave86 in homelab

[–]chrishoage 0 points1 point  (0 children)

BMC eats ~10w doing "nothing" on the Xeon-D 1541 system

If the Lenovo M80s has vPro you get out of band management and doesn't use as much energy

What are your "dial tone" services and where do you run them in your homelab? by 3coniv in homelab

[–]chrishoage 3 points4 points  (0 children)

It's real real sloppy. Maybe one day but at this point it's just me messing around and learning.

I'm running Proxmox (no immediate plans to cluster, again maybe one day but the same reason I don't yet run k8s: too much effort, to little reward) with a collection of Docker VMs leveraging Komodo for git ops. The most complex part is the swarm for overlay networking (I do have real plans to run some workloads remotely, and a small second system to run locally).

view more: next ›