Skip to content

Month: June 2023

All of my RAM is not showing up in Unraid

Published by xavier on June 26, 2023

So I bought some RAM recently in one of those bins on clearance because it was opened, etc. I installed it with another two sticks I already had. All four sticks are DDR4, of course, but the old ones were 2x8GB 26666, and the new ones are 2×16 GB 3200. Unraid would only show 16GB usable rather than the 48GB. Unraid did notice them, but they were unable to be used.

After some googling which didn’t get me anywhere, I decided to remove all the sticks and just use the new ones in A2 and B2. Well, now Unraid shows 32GB of RAM usable. So next, I put in the other two sticks in A1 and B1. Boom!!! Now it can use all 48GB. I assume it has to do with a mismatch in either speed or capacity.

Motherboard: Asrock B450M Pro4

Leave a Comment

traefik v3 example with uptime-kuma

Published by xavier on June 20, 2023

Here is an example of Traefik, using Uptime-Kuma as an example with a domain for it plus using letsencrypt to secure the domain. We also redirect HTTP to HTTPS.

The Traefik dashboard is not secure, so please implement security or a firewall.

This is just an example.

version: "3"

services:
 uk1:
    image: louislam/uptime-kuma:1
    container_name: uk1
    volumes:
      - ./uk1-data:/app/data
    ports:
      - 3001:3001  # <Host Port>:<Container Port>
    restart: always
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.uk1.tls.certresolver=myresolver"
      - "traefik.http.routers.uk1-http.entrypoints=web"
      - "traefik.http.routers.uk1-http.rule=Host(`your_domain_here`)"
      - "traefik.http.routers.uk1-http.middlewares=uk1-https"
      - "traefik.http.middlewares.uk1-https.redirectscheme.scheme=https"
      - "traefik.http.routers.uk1.entrypoints=websecure"
      - "traefik.http.routers.uk1.rule=Host(`your_domain_here`)"
      - "traefik.http.routers.uk1.tls=true"
    depends_on:
      - traefik
 traefik:
  image: traefik:v3.0
  command:
      - "--api.insecure=true"
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--certificatesresolvers.myresolver.acme.httpchallenge=true"
      - "--certificatesresolvers.myresolver.acme.httpchallenge.entrypoint=web"
      - "--certificatesresolvers.myresolver.acme.email=your_email_address_here"
      - "--certificatesresolvers.myresolver.acme.storage=/letsencrypt/acme.json"
  ports:
    - 80:80
    - 443:443
    - 8080:8080
  volumes:
    - "./letsencrypt:/letsencrypt"
    - /var/run/docker.sock:/var/run/docker.sock

https://gist.github.com/xavier-hernandez/48042d5cdb66a89ac5e92a92ecfeb7b5

Leave a Comment

tls: failed to verify certificate: x509: certificate signed by unknown authority

Published by xavier on June 9, 2023

In building a docker image for a Go application using the Apline image, I kept getting this error “tls: failed to verify certificate: x509: certificate signed by unknown authority”. I thought it was something with the code I was writing, but it had to do with the docker image.

Adding this to your Dockerfile should fix the problem. The problem is that the docker container doesn’t have the necessary certs to validate the connection. You might also get around this issue by adding the “ca-certificates” package to the image, but I didn’t try that.

COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/

or (depends on how your building your image)

COPY /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
Leave a Comment