Pika

To add some more information to this, you can see the context yourself. (so you don’t need to search like I did) they are referencing a post the Op made from five months ago. Admitting that’s how it worked

I tried to hyperlink it but Anubis gets in the way and throws a not found on the link for some reason, that or the original post was deleted

edit: I finally was able to get it to work. Post is here (not instance agnostic, still not 100% how to do that)

Simply speaking. No

Lets be real, while many do care, it isn’t going to be a “I need to leave the platform” level care.

Furthermore, the people impacted by it, may also not actually be in the majority either. For example they are doing similar to how discord is doing their age verification, where they are using existing metrics to infer your age without hard requiring it. Reddit has stated that said metrics include account age, email provider and topics you navigate.

Unless they have a super heavy handed way of doing this, I doubt anything super meaningful like another mass exodus like how the API issue was will happen.

That is an interesting concept, I would argue that it wouldn’t tackle the root cause of why most would want to federate due to rules just being universally applied to both the user instance and the community instance for the mega instances, and it still wouldn’t do anything with it being against the spirit of the fediverse in terms of needing to spread or web out, but I agree it would be nice.

I tend to agree that the majority of communities are hosted on 3 major instance’s its a concern that makes it difficult remove any of the 3 or 4 mega instances regardless of policies or practices.

I see many saying just boycott or block .world but, a decent source of communities im in are listed there. I know it’s against the spirit of fediverse but I don’t see that changing any time soon.

I use proxmox on one server, but currently my layout is:

• docker 1:
  • Authentik first network
  • heimdall
  • immich
  • jellyfin
  • NPM first network
  • zipline
• docker 2:
  • authentik second network
  • npm second network
  • blorp
  • gitlab-runner
  • ladder
  • metube
  • photon
  • privatebin
  • tandoor
  • bar assistant
  • sponsor block

LXCS:

• database server
• pihole
• wireguard
• mail server (postfix/dovecot)
• zoneminder
• zabbix
• gitlab
• matrix
• xmpp/openfire
• revolt/stoat
• gamevox (temporary)
• pufferpanel - minecraft
• pufferpanel - ark
• palworld
• discord development container
• projects container

VMs:

• homeassistant
• ipa server
• firewall
• Syncthing / immich storage / PXE server/ File storage

Also thank you for making this post, it helped me realize I have a few containers and services I don’t use and I don’t think have activity on them anymore so I can start a deprecation cycle on them lol

I use proxmox on one server, but currently my layout is:

• docker 1:
  • Authentik first network
  • heimdall
  • immich
  • jellyfin
  • NPM first network
  • zipline
• docker 2:
  • authentik second network
  • npm second network
  • blorp
  • gitlab-runner
  • ladder
  • metube
  • photon
  • privatebin
  • tandoor
  • bar assistant
  • sponsor block

LXCS:

• pihole
• wireguard
• mail server (postfix/dovecot)
• zoneminder
• zabbix
• gitlab
• matrix
• xmpp/openfire
• revolt/stoat
• gamevox (temporary)
• pufferpanel - minecraft
• pufferpanel - ark
• palworld
• discord development container
• projects container VMs:
• homeassistant
• ipa server
• firewall
• Syncthing / immich storage / PXE server/ File storage

Also thank you for making this post, it helped me realize I have a few containers and services I don’t use and I don’t think have activity on them anymore so I can start a deprecation cycle on them lol

As someone who ran Ubuntu server for a few years before moving to Debian. I would recommend Debian over Ubuntu just because I have had to do less maintenance with it. When I was on Ubuntu updating it was a constant concern of “will something change that is bad” for example they pushed the kernel live patch and the Ubuntu subscription banner as an update instead of an upgrade, so I updated as normal, and there it was.

I dislike OS’s that install new packages as part of their update procedures (an update that installs a new package instead of replacing an existing one should be reserved for upgrades), and Debian has never done that with me, so Debian is where I stay.

I noticed this myself by complete coincidence when itjust.works updated and I could click on my own comments and they wouldn’t pull anything.

I had thought that it might have been a bug with the server so I switched over to the standard Lemmy instance and it would load fine.

Then I dug through the settings more and I found the toxic mode hidden in the advanced settings. and realized that when I enabled toxic mode I could see the comment tree.

Weirdly enough, I did a deep dive into all the black lists that it has hard-coded when I saw and I couldn’t for the life of me find out what was flagging that post from being able to be seen. None of the instances of anyone in the comment train were in the black list, I guess it’s possible that the instance itself was in a blacklist, but I forgot to check that.

it’s actually the recommended way if you use jellyfin, theres a few security/privacy vulnerabilities with publicly exposing the jellyfin server anyway, they are being worked on but, the safest way to do it is just use a vpn regardless.

I’m not sure, I was running 2.7.5 myself but i am not sure what version of immich I started with. I didn’t think this would effect fully docker setups much. I think this would mostly effected people who had configured with a preexisting database. I believe the docker edition with postgres built in upgraded for you awhile back unless you supplied an environment variable telling it to do otherwise.

you’re welcome, glad it worked for your use case.

Rsync is an insane tool when you look at it, half the flags you wouldn’t even know existed unless you were looking for them.

hey everyone gotta learns somewhere, and defo don’t expect you’ll ever stop learning on this adventure. That’s part of what makes this hobby fun!

is there any reason in particular that you are using both SSHFS and rsync? Rsync supports sftp which runs over an ssh connection via rsync -e ssh source dstUser@dstHost:/path

if you are only using the sshfs system to allow a local ssh directory on your system to use with rsync, you could likely skip that entire part and just use rsync.

LinuxConfig.org has a pretty decent page on it

As an FYI to people who are upgrading and use a preexisting postgres database If you still use pgvecto.rs (if the command \dx on the immich database responds with vectors not vector) you will need to install both pgvector and vectorchord in order to continue using immich. This will require restarting your postgres instance at least once if not twice.

It threw me for a loop at first because of the similar naming. Just thought I would share.

Yea hopefully. I know that short lived certs is currently an additional parameter when requesting, hopefully when the default changes they will have a higher rate limit. That won’t be for quite some time though I expect.

I wasn’t aware of that they managed registered domains the way they do. I may need to reconcider my certificate setup currently, as I currently run a certificate per service because its more secure and looked cleaner, but if they count x.website.com certificates as website.com certificates, its entirely possible that when they switch to short lived certificate defaults I may come close to that rate limit.

If the part is on par with non-Chinese counterparts at a cheaper price, definitely

this right here. If you have immich setup behind a reverse proxy, just route any requests that use the /share/ and /s/ (the custom link version) on the proxy manager to route to the immich instance, and have it 403 on anything else when the request is not via the vpn

Just be aware that immich uses links like share-* as well so be sure to have that trailing / to make it so only shared links and albums can be.

edit: Actually looking into this route further, it looks like immich as a whole needs more than just the /share/ and the /s/ endpoints exposed to function correctly. I will update this in a little when i figured out more on what is actually needed

update: So it seems immich will not support this style setup without quite a bit of hands on. You need to give at minimum /share/, /s/, /_app/ and /api/ in order to actually go this route. and at that point since you’ve given /api/ you’ve essentially publicly opened the instance anyway. While you can go through and individually do each endpoint. It requires access to /api/albums /api/assets and a few other endpoints, these endpoints do seem to need auth or some form of verification tho

for anyone wanting to still go through with it. You can reverse proxy it by allowing the endpoints

• _app/ a bunch of immich internal files for serving content
• api/
  • server/
    • config: shows basic infomation about the server
    • media-types: shows what media types the server supports
    • features: discloses what features the server supports
  • shared-links/me: 401, 403’s or shows what links the user account can sign into
  • albums/: 403’s on any album endpoint that doesn’t also include the album’s public slug in the URL
  • timeline/
    • buckets: displays timeline buckets. 401 or 403’s on no auth
    • bucket/: displays timeline info on the requested resource. 401 or 403’s on info unless info is provided about what its trying to access
  • assets/: 401 or 403’s on any request that doesn’t contain a public slug in the url

The nginx location regex I used for my testing(although not very read friendly) was

location ~ /(api/(server/(config|media-types|features)|shared-links/me|albums/|timeline/(bucket|buckets)|assets/)|(share|s)|_app/){
  proxy_pass *immich instance*;
}

note: this was found just by basic testing using NPM on my environment, I may have missed some more specific calls especially regarding videos as I don’t really do any video photography to allow for testing.

Additional note: You may end up confusing your users with the UI though, as since lets you click on the immich banner to get to login, but everything would be blocked. You may just want to use the immich public project that was linked later in this discussion…

If it’s running as root anyway, then I change my statement. No I don’t see any security risk with it. Patchmon is running as root anyway, so no matter what your permissions are on the links or the original sock, as long as it’s smart enough to follow the link it should be fine. Generally symlinks follow the same permission as their target, with the exception of changing its owner with chown or removing it. I.E they are going to almost always just be whatever the permission of the target is. So your /var/run/docker.sock is going to be whatever permissions your /run/user/{userid}/docker.sock is normally and since patchmon is running as the root user, it’s not going to care what permissions are present as root overrides all restrictions/permissions anyway.

I have my concerns that patchmon might try to change docker files while as the root user, which could create files that docker couldn’t read but since it seems to be using the docker sock anyway, I expect it’s just going to operate over the sock which means it would be using dockers built in system which would be using its docker user.

I’m not fully understanding here, are you saying that the symlink is root because root is required to access /var/run or that its root because its required by patchmon.

If its root because the rest of the /var/run is root, is it not on the table to just chown the /var/run/docker.sock symlink to be the userid? since I would assume that patchmon would be running as the docker user anyway since you are running in a rootless environment? I might be misunderstanding.

As long as your permissions to the symlink are in line with the permissions on the original sock, I wouldn’t expect there would be too much risk there. Of course a malicious vector /could/ see that a /var/run/docker.sock exists and try to manipulate it, but, since docker itself isn’t root which means that user executing the symlink isn’t root, I don’t think it would allow for escalation.