• 1 Post
  • 24 Comments
Joined 1Y ago
cake
Cake day: Jun 23, 2023

help-circle
rss

It’s a vpn client on steroids that creates a VPN network (based on your provider) which you can then use to run docker containers inside of, as well as create http & shadowsocks proxies for your VPN network etc.



Maybe give cloudflared a try. Works for me even with nextcloud’s ssl (don’t think there’s a way to start NC without the self-signed cert). Couldn’t get it to work with NPM (I admittedly don’t know much about nginx) so I brought in the big gun(s).


Backblaze b2, borgbase.com. There are also programs like dejadup that will let you backup to popular cloud drives. The alternatives are limitless.


No minimum requirements. And here you go:

#version: "3.8"
services:
  invidious:
    image: quay.io/invidious/invidious:latest
    restart: unless-stopped
    security_opt:
      - no-new-privileges
    container_name: invidious
    stop_grace_period: 3s
    ports:
      - 127.0.0.1:3000:3000
    environment:
      INVIDIOUS_CONFIG: |
        db:
          dbname: invidious
          user: invidious
          password: superstrongpassword491
          host: postgres
          port: 5432
        check_tables: true
        popular_enabled: true
        login_enabled: false
        statistics_enabled: true
        hsts: true
        hmac_key: *PICK-A-LONG-RANDOM-STRING*
        https_only: true
        external_port: 443
        use_quic: true
        database_url: postgres://invidious:superstrongpassword491@postgres/invidious?auth_methods=md5,scram-sha-256
        force_resolve: ipv4
        domain: *your.domain.com*
    healthcheck:
      test: wget -nv --tries=1 --spider http://127.0.0.1:3000/api/v1/comments/jNQXAC9IVRw || exit 1
      interval: 30s
      timeout: 5s
      retries: 2
    depends_on:
      - postgres

  postgres:
    image: postgres:15-alpine
    container_name: postgres
    security_opt:
      - no-new-privileges
    restart: always
    # purposefully excluded volumes section
    # the database will reset on recreate
    environment:
      POSTGRES_DB: invidious
      POSTGRES_USER: invidious
      POSTGRES_PASSWORD: superstrongpassword491
    healthcheck:
      test: pg_isready -U invidious -d invidious
      interval: 10s
      timeout: 5s
      retries: 5

I’ve hosted invidious relatively easy for a while now. Simple UI and just works. If anyone needs my compose and config setup, reply and I’ll post it.


Haha. Said the hoader with tonnes of content he’s never going to finish watching.


They provide the best balance for efficiency. Not too powerful enough to be a workhorse and not to weak to run multiple simple applications/services. NUCs are great in that they come with hardware video acceleration tech that’s highly optimized for media transcoding.


You don’t get any network isolation with this approach vs a service running in its own dedicated virtual network. Just for this reason, I think Wireguard as a VPN access to other local services is insecure.


I always see guys swearing by Wireguard for VPN access as a security measure and seems to me like if someone unauthorized gets your public key, they have access to the kingdom.


For accessing your VPN network outside of your LAN, there’s the shadowsocks option in the gluetun wiki.


I use restic (and dejadup just to be safe) backing up to multiple cloud storage points. Among these cloud storage points are borgbase.com, backblaze b2 and Microsoft cloud.


Jellyfin, AdGuard Home, Nextcloud, Syncthing, Invidious, SearxNG


Even though minimal, the risk of security patches introducing new changes to your software is still there as we all have different ideas on how/what correct software updates should look like.


Mostly because stability is usually prioritized above all else on servers. There’s also a multitude of other legit reasons.


Nothing too fancy other than following the recommended security practices. And to be aware of and regularly monitor the potential security holes of the servers/services I have open.

Even though semi-related, and commonly frowned upon by admins, I have unattended upgrades on my servers and my most of my services are auto-updated. If an update breaks a service, I guess its an opportunity to earn some more stripes.



Valory noted in his statement that the company was significantly impacted by the slowdown.

He added that the company is still expected to see 30% growth this year.

Which is which?


Sounds like trying to use a rolled up newspaper to kill a fly.

Isn’t this what tech/sysadmin solutions are all about now? 😆

You can do it with janky restarts of your reverse proxy container, which results in down time of all apps

Yet to see if this solution breaks up my other services but it currently fixes the downtime I’ve recently been having with the searxng docker + NPM setup.

Use something like traefik, where you can allow it to connect to your docker socket (just like watchtower), and automatically wire up the new container’s reverse proxy when it comes back online.

NPM covers most of my needs plus traefik doesn’t work for me (due to other reasons unrelated to the tech).


No worries. I ended up writing a systemd service that restarts the npm container a minute after the watchtower runs. I don’t know why I didn’t think of that earlier but I guess it’s a much simpler solution than using depends_on with npm which hosts a lot of my other services.


This is the correct answer. Takes a little bit of tinkering to setup but it’s free and works. Just make sure to change the default DNS endpoints from Cloudflare and Google to something more private.


I want to restart the NPM container (when the searxng service goes down) instead of searxng.




How to trigger a container restart based on successful update/image change of another container?
Basically have watchtower monitor and update containers whenever new images are released. I've recently noticed that with searxng (using redis as db), hosted through nginx proxy manager, will have a steady downtime of about 15mins post update then come back online. This is extremely frequent for searxng's case as I have watchtower run every day and my preferred way of running most of my containers is with the latest tag. The way out of this downtime in my experience is a restart of NPM which brings back the searxng service. I'm looking for a way to automate a restart of the NPM container after a successful update of searxng's container. I have checked the docs for watchtower, and the lifecycle hooks (a way to run sh scripts pre/post update) are able to run only from the applied container and not from the host system.
fedilink