graybeard

232 readers
51 users here now

founded 1 year ago
MODERATORS
1
39
submitted 2 weeks ago* (last edited 2 weeks ago) by [email protected] to c/[email protected]
 
 

Bloody solarwinds

2
 
 

Leaving a builder account enabled after build has completed is a fairly big oversight.

3
 
 

Manners maketh man.

4
 
 

This does imply a cups server being open to the internet or an already breached network.

3.6 roentgen.

5
 
 

Hey, we own a few thousand of those! Oh, wait...

Might be a long few days coming 😮‍💨

6
 
 

Admittedly, I have a fairly serious bias against Microsoft, so it's unlikely they'll every say much I can trust; but I am genuinely surprised their marketing department didn't even bother coming up with another name to try selling this atrocity.

7
 
 

The company I'm at right now is on this boat as well

8
 
 

Archive link

I have finally found an quick and easy write up by somebody on Reddit that worked for me first time!

Dual display on Sway has become much more usable now!

9
 
 

According to Mehta this kind of connectivity could support 512 GPUs in as few as eight racks, acting as a single scale-up system.

That's a biggin!

10
 
 

Despite early promises, moving between providers remains a complex and costly endeavor

Yea, it feels an awful lot like VC funded businesses - they lure you in with low pricing, bankrupt and buy out the competition and then hold you by the balls.

11
 
 

Cracked Labs examines how workplace surveillance turns workers into suspects

TL;DR - world is going down the drain

12
 
 

Wasn't aware of OpenTofu - will have a look and try to sell the switch at work!

13
11
submitted 3 months ago* (last edited 3 months ago) by [email protected] to c/[email protected]
 
 

Ha 😀

Comment section is a gold mine!

14
 
 

All that Windows and Crowstrike bollocks.

15
 
 

He also links a Mastodon thread where he had documented the first few days with pictures.

I genuinely cannot fathom the talent and drive combo some people possess.

16
 
 
17
 
 

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!

18
 
 

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: "[email protected]"
    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: "[email protected]"
    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: "[email protected]"
    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!

19
 
 

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!

20
 
 

No good deed goes unpunished.

21
 
 

Saw this posted somewhere on Lemmy already, but lost it.

This is a great write-up of the famous Ken Thompson's lecture "Reflections on Trusting Trust".

The author implements a bad compiler and explains what bits do what. I've found this an easy-yet-informative read.

Would highly recommend!

22
 
 

Twenty two point nine petabit a second. Mental.

23
 
 

Doesn't happen very often, but I agree with AWS. Open source has very much become a vendor-sponsored affair and there are fewer and fewer actual community-driven projects.

24
 
 

Just spent a few hours trying to figure out why the VM was impossible to access via SSH and Linode's recovery console.

Very difficult to say what the cause is, but for a few seconds I did see BPF errors in the console about not being able to find something.

Booting rescue image, chrooting and installing 6.5.12-hardened fixed it.

25
 
 

Facepalm. That's all I can say.

The local authority declined to provide an answer on how the original advice to disable HTTPS was approved internally.

view more: next ›