36
submitted 5 months ago* (last edited 5 months ago) by Illecors@lemmy.cafe to c/graybeard@lemmy.cafe

There are a few reasons why pict-rs might not be running, upgrades being one of them. At the moment the whole of lemmy UI will crash and burn if it cannot load a site icon. Yes, that little thing. Here's the github issue.

To work around this I have set the icon and banner (might as well since we're working on this) to be loaded from a local file rather than nginx.

Here's a snippet of nginx config from the server block:

location /static-img/ {
      alias /srv/lemmy/lemmy.cafe/static-img/;

      # Rate limit
      limit_req zone=lemmy.cafe_ratelimit burst=30 nodelay;

      # Asset cache defined in /etc/nginx/conf.d/static-asset-cache.conf
      proxy_cache lemmy_cache;
    }

I have also included the rate limitting and cache config, but it is not, strictly speaking, necessary.

The somewhat important bit here is the location - I've tried using static, but that is already used by lemmy itself, and as such breaks the UI. Hence the static-img.

I have downloaded the icon and banner from the URLs saved in the database (assuming your instance id in site is, in fact, 1):

SELECT id, icon, banner FROM site WHERE id = 1;
 id |                     icon                     |                     banner
----+----------------------------------------------+------------------------------------------------
  1 | https://lemmy.cafe/pictrs/image/43256175-2cc1-4598-a4b8-2575430ab253.webp | https://lemmy.cafe/pictrs/image/c982358f-6a51-4eb6-bf0e-7a07a756e600.webp
(1 row)

I have then saved those files in /srv/lemmy/lemmy.cafe/static-img/ as site-icon.webp and site-banner.webp. Changed the ownership to that of nginx (www-data in debian universe, http and httpd in others.

I have then updated the site table to point to the new location for icon and banner:

UPDATE site SET icon = 'https://lemmy.cafe/static-img/site-icon.webp' WHERE id = 1;
UPDATE site SET banner = 'https://lemmy.cafe/static-img/site-banner.webp' WHERE id = 1;

Confirm it got applied:

SELECT id, icon, banner FROM site WHERE id = 1;
 id |                     icon                     |                     banner
----+----------------------------------------------+------------------------------------------------
  1 | https://lemmy.cafe/static-img/site-icon.webp | https://lemmy.cafe/static-img/site-banner.webp
(1 row)

That's it! You can now reload your nginx server (nginx -s reload) to apply the new path!

29
submitted 6 months ago by Illecors@lemmy.cafe to c/graybeard@lemmy.cafe

docker compose


I'm using a v2 - notice the lack of a dash between docker and compose.

I've recently learnt of the default filenames docker compose is trying to source upon invocation and decided to give it a try. The files are:

  • compose.yml
  • compose.override.yml

I have split the default docker-compose.yml that lemmy comes with into 2 parts - compose.yml holds pict-rs, postfix and, in my case, gatus. compose.override.yml is responsible for lemmy services only. This is what the files contain:

compose.yml

x-logging: &default-logging
  driver: "json-file"
  options:
    max-size: "20m"
    max-file: "4"

services:
  pictrs:
    image: asonix/pictrs:0.5.0
    user: 991:991
    ports:
      - "127.0.0.1:28394:8080"
    volumes:
      - ./volumes/pictrs:/mnt
    restart: always
    logging: *default-logging
    entrypoint: /sbin/tini -- /usr/local/bin/pict-rs run
    environment:
      - PICTRS__OLD_REPO__PATH=/mnt/sled-repo
      - PICTRS__REPO__TYPE=postgres
      - PICTRS__REPO__URL=postgres://pictrs:<redacted>@psql:5432/pictrs
      - RUST_LOG=warn
      - PICTRS__MEDIA__MAX_FILE_SIZE=1
      - PICTRS__MEDIA__IMAGE__FORMAT=webp
    deploy:
      resources:
        limits:
          memory: 512m
  postfix:
    image: mwader/postfix-relay
    environment:
      - POSTFIX_myhostname=lemmy.cafe
    volumes:
      - ./volumes/postfix:/etc/postfix
    restart: "always"
    logging: *default-logging

  gatus:
    image: twinproduction/gatus
    ports:
      - "8080:8080"
    volumes:
      - ./volumes/gatus:/config
    restart: always
    logging: *default-logging
    deploy:
      resources:
        limits:
          memory: 128M


compose.override.yml is actually a hardlink to the currently active deployment. I have two separate files - compose-green.yml and compose-blue.yml. This allows me to prepare and deploy an upgrade to lemmy while the old version is still running.

compose-green.yml

services:
  lemmy-green:
    image: dessalines/lemmy:0.19.2
    hostname: lemmy-green
    ports:
      - "127.0.1.1:14422:8536"
    restart: always
    logging: *default-logging
    environment:
      - RUST_LOG="warn"
    volumes:
      - ./lemmy.hjson:/config/config.hjson
    # depends_on:
    #   - pictrs
    deploy:
      resources:
        limits:
          # cpus: "0.1"
          memory: 128m
    entrypoint: lemmy_server --disable-activity-sending --disable-scheduled-tasks

  lemmy-federation-green:
    image: dessalines/lemmy:0.19.2
    hostname: lemmy-federation-green
    ports:
      - "127.0.1.1:14423:8536"
    restart: always
    logging: *default-logging
    environment:
      - RUST_LOG="warn,activitypub_federation=info"
    volumes:
      - ./lemmy-federation.hjson:/config/config.hjson
    # depends_on:
    #   - pictrs
    deploy:
      resources:
        limits:
          cpus: "0.2"
          memory: 512m
    entrypoint: lemmy_server --disable-http-server --disable-scheduled-tasks

  lemmy-tasks-green:
    image: dessalines/lemmy:0.19.2
    hostname: lemmy-tasks
    ports:
      - "127.0.1.1:14424:8536"
    restart: always
    logging: *default-logging
    environment:
      - RUST_LOG="info"
    volumes:
      - ./lemmy-tasks.hjson:/config/config.hjson
    # depends_on:
    #   - pictrs
    deploy:
      resources:
        limits:
          cpus: "0.1"
          memory: 128m
    entrypoint: lemmy_server --disable-http-server --disable-activity-sending

#############################################################################

  lemmy-ui-green:
    image: dessalines/lemmy-ui:0.19.2
    ports:
      - "127.0.1.1:17862:1234"
    restart: always
    logging: *default-logging
    environment:
      - LEMMY_UI_LEMMY_INTERNAL_HOST=lemmy-green:8536
      - LEMMY_UI_LEMMY_EXTERNAL_HOST=lemmy.cafe
      - LEMMY_UI_HTTPS=true
    volumes:
      - ./volumes/lemmy-ui/extra_themes:/app/extra_themes
    depends_on:
      - lemmy-green
    deploy:
      resources:
        limits:
          memory: 256m

compose-blue.yml

services:
  lemmy-blue:
    image: dessalines/lemmy:0.19.2-rc.5
    hostname: lemmy-blue
    ports:
      - "127.0.2.1:14422:8536"
    restart: always
    logging: *default-logging
    environment:
      - RUST_LOG="warn"
    volumes:
      - ./lemmy.hjson:/config/config.hjson
    # depends_on:
    #   - pictrs
    deploy:
      resources:
        limits:
          # cpus: "0.1"
          memory: 128m
    entrypoint: lemmy_server --disable-activity-sending --disable-scheduled-tasks

  lemmy-federation-blue:
    image: dessalines/lemmy:0.19.2-rc.5
    hostname: lemmy-federation-blue
    ports:
      - "127.0.2.1:14423:8536"
    restart: always
    logging: *default-logging
    environment:
      - RUST_LOG="warn,activitypub_federation=info"
    volumes:
      - ./lemmy-federation.hjson:/config/config.hjson
    # depends_on:
    #   - pictrs
    deploy:
      resources:
        limits:
          cpus: "0.2"
          memory: 512m
    entrypoint: lemmy_server --disable-http-server --disable-scheduled-tasks

  lemmy-tasks-blue:
    image: dessalines/lemmy:0.19.2-rc.5
    hostname: lemmy-tasks-blue
    ports:
      - "127.0.2.1:14424:8536"
    restart: always
    logging: *default-logging
    environment:
      - RUST_LOG="info"
    volumes:
      - ./lemmy-tasks.hjson:/config/config.hjson
    # depends_on:
    #   - pictrs
    deploy:
      resources:
        limits:
          cpus: "0.1"
          memory: 128m
    entrypoint: lemmy_server --disable-http-server --disable-activity-sending

#############################################################################

  lemmy-ui-blue:
    image: dessalines/lemmy-ui:0.19.2-rc.5
    ports:
      - "127.0.2.1:17862:1234"
    restart: always
    logging: *default-logging
    environment:
      - LEMMY_UI_LEMMY_INTERNAL_HOST=lemmy-blue:8536
      - LEMMY_UI_LEMMY_EXTERNAL_HOST=lemmy.cafe
      - LEMMY_UI_HTTPS=true
    volumes:
      - ./volumes/lemmy-ui/extra_themes:/app/extra_themes
    depends_on:
      - lemmy-blue
    deploy:
      resources:
        limits:
          memory: 256m


The only constant different between the two is the IP address I use to expose them to the host. I've tried using ports, but found that it's much easier to follow it in my mind by sticking to the ports and changing the bound IP.

I also have two nginx configs to reflect the different IP for green/blue deployments, but pasting the whole config here would be a tad too much.

No-downtime upgrade


Let's say green is the currently active deployment. In that case - edit the compose-blue.yml file to change the version of lemmy on all 4 components - lemmy, federation, tasks and ui. Then bring down the tasks container from the active deployment, activate the whole of blue deployment and link it to be the compose.override.yml. Once the tasks container is done with whatever tasks it's supposed to do - switch over the nginx config. Et voilà - no downtime upgrade is live!

Now all that's left to do is tear down the green containers.

docker compose down lemmy-tasks-green
docker compose -f compose-blue.yml up -d
ln -f compose-blue.yml compose.override.yml
# Wait for tasks to finish
ln -sf /etc/nginx/sites-available/lemmy.cafe-blue.conf /etc/sites-enabled/lemmy.cafe.conf
nginx -t && nginx -s reload
docker compose -f compose-green.yml down lemmy-green lemmy-federation-green lemmy-tasks-green lemmy-ui-green

lemmy.hjson


I have also multiplied lemmy.hjson to provide a bit more control.

lemmy.hjson

{
  database: {
    host: "psql"
    port: 5432
    user: "lemmy"
    password: "<redacted>"
    pool_size: 3
  }
  hostname: "lemmy.cafe"
  pictrs: {
    url: "http://pictrs:8080/"
    api_key: "<redacted>"
  }
  email: {
    smtp_server: "postfix:25"
    smtp_from_address: "lemmy@lemmy.cafe"
    tls_type: "none"
  }
}

lemmy-federation.hjson

{
  database: {
    host: "psql"
    port: 5432
    user: "lemmy_federation"
    password: "<redacted>"
    pool_size: 10
  }
  hostname: "lemmy.cafe"
  pictrs: {
    url: "http://pictrs:8080/"
    api_key: "<redacted>"
  }
  email: {
    smtp_server: "postfix:25"
    smtp_from_address: "lemmy@lemmy.cafe"
    tls_type: "none"
  }
  worker_count: 10
  retry_count: 2
}

lemmy-tasks.hjson

{
  database: {
    host: "10.20.0.2"
    port: 5432
    user: "lemmy_tasks"
    password: "<redacted>"
    pool_size: 3
  }
  hostname: "lemmy.cafe"
  pictrs: {
    url: "http://pictrs:8080/"
    api_key: "<redacted>"
  }
  email: {
    smtp_server: "postfix:25"
    smtp_from_address: "lemmy@lemmy.cafe"
    tls_type: "none"
  }
}


I suspect it might be possible to remove pict-rs and/or email config from some of them, but honestly it's not a big deal and I haven't had enough time, yet, to look at it.

Future steps

I'd like to script the actual switch-over - it's really trivial, especially since most of the parts are there already. All I'd really like is apply strict failure mode on the script and see how it behaves; do a few actual upgrades.

Once that happens - I'll post it here.

So long and thanks for all the fish!

26
submitted 6 months ago by Illecors@lemmy.cafe to c/spacetime@lemmy.cafe
42
submitted 6 months ago by Illecors@lemmy.cafe to c/statecraft@lemmy.cafe

Proper cocked up cover up. Now live!

33
submitted 6 months ago by Illecors@lemmy.cafe to c/general@lemmy.cafe

The process went through smoothly. I have also used the opportunity to split up a singular lemmy container into individual tasks - this has enabled a seemless upgrade process with no downtime, bar a few process quirks I need to work out.

There have been some federation fixes merged into this release, so the situation should definitely be improving overall!

I will make a more detailed write up of the whole setup later on, other admins might find it useful. Or not.

[-] Illecors@lemmy.cafe 45 points 6 months ago

OSM is run by a foundation - https://www.openstreetmap.org/about

This makes it a lot more difficult to cock it up compared to a shareholder run company.

58
submitted 6 months ago by Illecors@lemmy.cafe to c/graybeard@lemmy.cafe

Using optimization techniques, the wireless spec can support a theoretical top speed of more than 40Gbps, though vendors like Qualcomm suggest 5.8Gbps is a more realistic expectation

That is insane! Not that I would, but this could utilise the full pipe of my home connection on wifi only!

111
[APOD] Thor's Helmet (apod.nasa.gov)
submitted 6 months ago by Illecors@lemmy.cafe to c/spacetime@lemmy.cafe
23
submitted 6 months ago by Illecors@lemmy.cafe to c/statecraft@lemmy.cafe

Archive link

This feels sensible. There will always be naysayers, there will always be exports to poorer countries, but arguing against such a policy makes it sound like protecting the status quo for the sake of it.

55
submitted 6 months ago by Illecors@lemmy.cafe to c/statecraft@lemmy.cafe

Archive link

It's a theoretical pathway, but it's a nice read overall for someone who's not into warring all that much. I've found the explanations understandable.

68
submitted 6 months ago by Illecors@lemmy.cafe to c/folderol@lemmy.cafe

Some really beautiful shots in the video.

42
submitted 6 months ago* (last edited 6 months ago) by Illecors@lemmy.cafe to c/folderol@lemmy.cafe

Archive link

In a surprise to absolutely nobody - it sucks.

54
submitted 6 months ago by Illecors@lemmy.cafe to c/spacetime@lemmy.cafe

The launch has been successful!

[-] Illecors@lemmy.cafe 58 points 6 months ago* (last edited 6 months ago)

Most of them.

  • Debian world - apt sucks. For something with a sole purpose of resolving a dependency tree, it's surprisingly bad at that.

  • Redhat world - everything is soooo old. I can see why business people like it, buy I rarely, if ever, agree with business people.

  • Opensuse world - I've only tried it once, probably 15 years ago. Didn't really know my way around computers all that much at the time, but it didn't click and I've left it. Later on I found out about their selling out to Microsoft and never bothered touching it again.

  • Arch - it was my daily for a year or two. Big fan. It still runs my email. At some point the size of packages started to annoy me, though. Still has the best wiki. I've never really bothered with the spinoffs, as the model of Arch makes them useless and more problematic to deal with.

I've got the Gentoo bug now. For the first time I genuinely feel ~/. A lean, mean system of machines :)

[-] Illecors@lemmy.cafe 45 points 7 months ago* (last edited 7 months ago)

I wholeheartedly support this dumbass decision. Nothing makes youngsters learn basic computing better than a ban that can be arbitralily overcome using basic networking skills.

[-] Illecors@lemmy.cafe 58 points 7 months ago

It's not. TempleOS is a famous from scratch OS created by a guy with serious mental illness. It's a sad story, but the capability of that guy was incredible. He's gone now :(

[-] Illecors@lemmy.cafe 66 points 7 months ago

I'll believe it when I see it.

[-] Illecors@lemmy.cafe 66 points 8 months ago

that doesn't necessarily mean it will be an RTS, and whatever shape it takes will depend on the person or team who goes to bat for it.

So... it's not Starcraft, then. It's just another game.

[-] Illecors@lemmy.cafe 56 points 8 months ago* (last edited 8 months ago)

This is a shit article from a shit source. It references itself, which, in turn, references guardian. There's no mention of police pulling data from period tracking services. The only related thing I could find in OP was a quote from whatever tortoisemedia is:

We already know that police routinely remove phones and computers from women suspected of having an [illegal] abortion and it’s even happening following miscarriage and pregnancy loss.

And it sucks, but this is not a dystopian surveillance bullshit OP is trying to sell. Put a password on your shit and you're good to go.

[-] Illecors@lemmy.cafe 50 points 8 months ago

Hasn't made life hell, but the general dumb following of compliance has left me baffled:

  • users must not be able to have a crontab. Crontab for users disabled.
  • compliance says nothing about systemd timers, so these work just fine 🤦

I've raised it with security and they just shrugged it off. Wankers.

[-] Illecors@lemmy.cafe 63 points 8 months ago

That's a drop in profit, right? Not an actual loss

[-] Illecors@lemmy.cafe 66 points 11 months ago

Why does this feel like an ad

[-] Illecors@lemmy.cafe 43 points 1 year ago

I'm an Android guy, but what you've just done is called hypocrisy.

[-] Illecors@lemmy.cafe 43 points 1 year ago

As a sysadmin - I sort of welcome every dumb thing reddit does. I'll get more sign ups on my Lemmy instance :D

view more: ‹ prev next ›

Illecors

joined 5 years ago
MODERATOR OF