I very much did. Read up.
I very much did. Read up.
Because IRC doesn’t “work fine”.
It’s a 50-year old solution to no modern problems where everything about it has been solved in better ways.
I don’t think anyone still recognizes this wisdom you seem to be all about.
Enlightening us with that wisdom would be beneficial to everyone, no?
My point exactly. There are easier and better ways of doing this dated interaction.
Nope. Just ports and an A Record.
Yeah, but again…habit and effort.
I can’t think of a single reason that IRC is still used except for people being too lazy to adopt something else.
DNS A record points to an IP destination. Ports are then handled by the requests for a specific port thing.
Example: A record for www.dududu.com points to IP 1.2.3.4, but different service ports are listening there to pick up different traffic.
IRC is pretty dated and dead. The only people still using it are die hards, for the most part.
Matrix is probably the new IRC, XMPP close second. There is literally no reason to keep using IRC except habit.
If you’re looking for a more community based experience, get into mesh hubs or something.
Or you could similar just block those routes in whatever reverse proxy you’d use out in front of the server?
I don’t run Immich myself, but just trying to understand the technical issues and this particular solution. Seems like they should have a public facing /shared route that doesn’t require access to any others, so I see your point.
Okay…I’m terribly confused by this project here, so maybe you can clarify some things.
First, looking through the code, it seems you’re literally just taking input requests and replaying them to a target host. So if Immich is updated with changes that proxy doesn’t have yet, everything breaks.
How is this adding more security than any other proxy?
I can tell you it will be the most expensive on AWS or Azure. That’s about all I could say without pricing stuff out.
It would depend completely on how many users you let in and what kind of things they’ll be doing. Some users are super heavy with uploading images, some users aren’t.
I haven’t read the docs in a long time, but perhaps you could restrict image uploading or something. Nothing you can do about unbounded DB growth without expiring content though.
Well the question is about a container disappearing from a public registry, in which case nothing would happen if it’s already pulled locally. Figuring where to go from there is the other half of that problem.
It could be costly in a few places, so choose your host wisely:
I know that R2 has no charge for ingress/egress.
The block and db costs are technically unbounded, and will never decrease by default.
I think I saw some Moe’s branded flood lights not long ago. Check them out. Their Matter bulbs have been totally solid for me.
Retag and push to a local registry. Lots of options out there for setting one up.
Honestly, you already have the image locally if you’ve pulled it. You don’t really need to run a registry unless you’re dead set on it. You can also flatten and export containers for backup if you really want.
This is the correct answer. Healthcheck for each host to remove a dead endpoint from rotation.
Edit: missed your comment about static site
Btrfs still has some issues, but it’s not like it’s dangerous or anything.
Xfs is going to give more flexibility for managing volumes, better performance than ext4 across multiple disks, and more fault protection.
Ext4 doesn’t really have any benefits in this race but being stable I suppose. An argument could be made it might be slightly faster under LUKS.
Zfs is more complex, but a bit more flexible than XFS, has CoW, snapshots, built in encryption and dynamic storage allocation.
EFI bootloader won’t have this problem. Adjust accordingly, and things will be fine.