It may or may not work, unfortunately.

I successfully ran 2x32GB in a Dell XPS 15 that “didn’t support” it, because the larger DIMMs didn’t exist at the time it was designed and documentation was done up.

It’s not going to hurt to try, but if you have two DIMM slots it’s worth a shot; the slots are already wired up to address lines! Maybe try with one first?

Edit: the CPU specs say that it supports 64GB and only up to two memory channels. It’s looking pretty good on that end.

BareOS is a great open source option. The GUI is a webUI but you also have a powerful console on the shell if you need to script.

I have a multi-WAN configuration on my router, with ipv6 VDSL then ipv4 VDSL then a prepaid 4G modem as the backup link. I rarely fail over but it’s been fantastic watching traffic stats when it does.

My only downside is the CGNAT on that connection that prevents things like a backup VPN gateway…

Simply refuting the BS claim that it’s impossible for there to be a Linux virus.

This one existed, therefore the claim is false.

There are still no viruses for Linux … because it’s not possible.

Here is just one example that proves your assertion wrong.

https://www.f-secure.com/v-descs/slapper.shtml

There are no viruses for Linux.

Blatant lies.

https://en.m.wikipedia.org/wiki/Linux_malware

I wrote some TypeScript modules to process a bunch of documentation in markdown to a ton of output formats via pandoc + latex.

No real reason for it, except that I was able to start with the export module of a node-based thing written in JavaScript and iterate from there until I had a working system in CI/CD.

Oh hey.

I’ve done this in a ton of different ways.

Manually, viis GitLab CI/CD, CI/CD with Kaniko.

My current favourite though is Kubler; I did a write-up for Lemmy a little while ago: https://lemmy.srcfiles.zip/post/32334

It’s fine with Let’sEncrypt via the DNS01 challenge; my lab typically only uses one wildcard certificate for all the services there unless I have a specific need to generate an indovidual cert for a service.

At the end of the day Traefik isn’t that hard, especially if you know the core concepts; if you know both and have a need for Traefik I’d just use that everywhere.

Here’s the secret to stuff like this:

Run a single reverse proxy / edge router for all of your containerised services.

I recommend Traefik - https://gitlab.com/Matt.Jolly/traefik-grafana-prometheus-docker

You can configure services with labels attached to the container and (almost) never expose ports directly. It also lets you host an arbitrary number of services listening on 80/443.

An example config might look like this:

# docker-compose.yml
version: '3.9'

services:
  bitwarden:
    image: vaultwarden/server:latest
    restart: always
    volumes:
      - /data/vaultwarden/:/data
    environment:
#      - ADMIN_TOKEN=
      - WEBSOCKET_ENABLED=true
    networks:
      - proxy
    labels:
      - traefik.enable=true
      - traefik.http.routers.bitwarden-ui-https.tls.certresolver=letsencrypt
      - traefik.http.middlewares.redirect-https.redirectScheme.scheme=https
      - traefik.http.middlewares.redirect-https.redirectScheme.permanent=true
      - traefik.http.routers.bitwarden-ui-https.rule=Host(`my.domain.com`)
      - traefik.http.routers.bitwarden-ui-https.entrypoints=websecure
      - traefik.http.routers.bitwarden-ui-https.tls=true
      - traefik.http.routers.bitwarden-ui-https.service=bitwarden-ui
      - traefik.http.routers.bitwarden-ui-http.rule=Host(`my.domain.com`)
      - traefik.http.routers.bitwarden-ui-http.entrypoints=web
      - traefik.http.routers.bitwarden-ui-http.middlewares=redirect-https
      - traefik.http.routers.bitwarden-ui-http.service=bitwarden-ui
      - traefik.http.services.bitwarden-ui.loadbalancer.server.port=80
      - traefik.http.routers.bitwarden-websocket-https.rule=Host(`my.domain.com) && Path(`/notifications/hub`)
      - traefik.http.routers.bitwarden-websocket-https.entrypoints=websecure
      - traefik.http.routers.bitwarden-websocket-https.tls=true
      - traefik.http.routers.bitwarden-websocket-https.service=bitwarden-websocket
      - traefik.http.routers.bitwarden-websocket-http.rule=Host(`my.domain.com`) && Path(`/notifications/hub`)
      - traefik.http.routers.bitwarden-websocket-http.entrypoints=web
      - traefik.http.routers.bitwarden-websocket-http.middlewares=redirect-https
      - traefik.http.routers.bitwarden-websocket-http.service=bitwarden-websocket
      - traefik.http.services.bitwarden-websocket.loadbalancer.server.port=3012

Here’s my config to get you started, I’ve got a bunch of services configured to work with it on my GitLab, too!

https://gitlab.com/Matt.Jolly/traefik-grafana-prometheus-docker

I run all of my containerised services behind Traefik which does LetsEncrypt for me as well as handles fun stuff like routing to different containers / reverse proxy. It’s fantastic if you want to take your new knowledge to the next level!

Elog is fantastic for this. I did up a Gentoo package.

https://elog.psi.ch/

Single binary and lightweight, backend is all text files.

Same. Their API is now too slow for LetsEncrypt DNS challenges. :(

Cloudflare is great though.

IMO opinion

You know what ‘IMO’ is an acronym for, right?

If the pictrs container doesn’t start check the docker logs.

journalctl -fexu docker

It’ll typically tell you why a container isn’t starting, usually a broken bind mount.

To prevent this from happening again, try migrating to an S3 backend; DigitalOcean have one that’s fixed-price and includes egress, so you can’t accidentally end up with a ridiculous bill one month!

I use Traefik. It’s “fine” but Dessalines hates it.

You’re on the right track. I’m on mobile so will be brief, edit from a laptop in a while.

You can use subdomains, which is my preferred way if making services work with traefik, but you could also look for, say, example.com/potato to get to the potato service; this may work better with DDNS.

Edit: each subdomain needs to be updated, you might be able to get away with making them all a CNAME that points at the DDNS.

You’re correct in your assessment that you only expose 80 and 443 for the Traefik container and access everything else through that. Also only use 80 to redirect to 443.

Don’t expose the NAS directly to the web, instrad look at port forwarding on your router, it should be able to forward requests received on only 80 and 443 to the NAS while still blocking everything else.

My only complaint about Synology stuff is that I couldn’t get Traefik in swarm mode going!

Any questions reach out.

Edit2: consider looking at a cheap VPS or a static IP to eliminate the requirement to expose your NAS directly to the web. Alternately run your internal DNS for stuff (including SSL certs from LetsEncrypt) and VPN in (I use Wireguard) when you want to access it.

Close enough to 0 downtime that it doesn’t matter.

1. Deploy updated stack file to existing stack
2. existing services are updated
3. Traefik polls the docker socket and notices updated labels
4. ???
5. Profit!

Seriously, you shouldn’t need to put anything (outside of rules that you want to re-use [e.g. http->https middleware]) in the traefik dynamic configuration because each container/service in a docker stack will bring with it its own configuration. Your only ‘dead time’ is how long it takes Traefik to pick up the new dynamic configuration via either the docker or swarm providers, which is configurable but I’ve never had to touch because, even on production systems, it’s been fine.