April 2024

30. April 2024

Wasser nach Apfel nicht ok

Wasser zu trinken, nachdem man einen Apfel oder mehrere Äpfel gegessen hat ist, noch wie vor, nicht ok und führt im schlechtesten Fall zu Durchfall.

Man googlet ja oft verschiedene Dinge und AI, die Google und andere einsetzen, ist bekannt dafür zu lügen. Aber es ist nicht die AI, die in diesem Fall lügt, sondern verschiedene Suchtreffer, die auf der ersten Seite stehen.
Dort wird behauptet, dass sinngemäß das Wasser früher zu “Großmutters Zeiten” kontaminiert war und deshalb das trinken von Wasser nachdem man Obst, in diesem Fall Äpfel, gegessen hat als schlecht oder schädlich angesehen wurde.
Wasser, ist nach wie vor, Wasser und das trinken von Wasser nach Obst sollte erst ca. 30 Minuten nachdem man Obst gegessen hat erfolgen, sonst riskiert man bestenfalls Blähungen, schlimmstenfalls, wie bei Feigen, blutigen Durchfall oder Erbrechen.

KEIN WASSER NACH OBST ist nach wie vor ein guter Rat.

#Obst #Wasser #Apfel #Gesundheit

19. April 2024

Beware of ent (entgo.io)

If you’re using Go, you’ve likely heard of ent. Some Ex-Facebook employee maintaining and developing an open source version of the public version of Meta’s entity framework for Go.

Well there’s a catch.
Migrations.

They sweet talk you in their documentation to use Atlas. Ariga’s Atlas, not the MongoDB one.
But Atlas is a proprietary cloud offering.
There might be a free tier, but who cares?
You have to give other parties access to your schema, if you want to containerize your binary or even if you’re not distributing your schema with your binary. Not just your schema, also your database.

To me that is a breach of trust.

That is “open source” software being used as bait for a lock-in cloud offering.

#go #golang #ent #scam #foss

18. April 2024

2 machines with bridge devices and same mac problem

You’re using systemd, maybe you have cockpit installed and are creating a bridge on each host because you need them for libvirt virtual machines.

One machine is your old workstation and you copied the filesystem to the new machine.

But when you create a bridge you local machine suddenly receives the same IP your old machine has received.
Why?
You search around, “How do I set a new MAC address on a bridge?”
But none of the answers work.

Then you remember, “Hey, systemd uses machine-id for each machine”.
And indeed it does.

You have to rm -f /etc/machine-id and dbus-uuidgen --ensure=/etc/machine-id
Reboot the system
Recrete the bridge

#systemd #machine-id #bridge #network

17. April 2024

How to run gitea securely with snapcraft’s gitea snap on CentOS/Rocky/Alma etc

Install gitea snap

snap install gitea --channel=latest/stable

1	snap install gitea --channel=latest/stable

Add user

useradd -r -s /bin/bash -d /home/git git

1	useradd -r -s /bin/bash -d /home/git git

systemctl edit snap.gitea.web.service

[Unit]
After=mysqld.service
AssertPathIsDirectory=/home/git
AssertPathIsReadWrite=/home/git

[Service]
User=git
Group=git
Environment="GITEA_WORK_DIR=/home/git" "GITEA_CUSTOM=/home/git/custom"
WorkingDirectory=/home/git
ExecStart=
ExecStart=/usr/bin/snap run gitea.web --config /home/git/app.ini
Restart=always

[Unit]

After=mysqld.service

AssertPathIsDirectory=/home/git

AssertPathIsReadWrite=/home/git

[Service]

User=git

Group=git

Environment="GITEA_WORK_DIR=/home/git" "GITEA_CUSTOM=/home/git/custom"

WorkingDirectory=/home/git

ExecStart=

ExecStart=/usr/bin/snap run gitea.web --config /home/git/app.ini

Restart=always

In app.ini

; ; Port number to be exposed in clone URL
SSH_PORT = 22
; ; 
; ; The port number the builtin SSH server should listen on
SSH_LISTEN_PORT = 2222

; ; Port number to be exposed in clone URL

SSH_PORT = 22

; ;

; ; The port number the builtin SSH server should listen on

SSH_LISTEN_PORT = 2222

add firewall forward rule

firewall-cmd --permanent --add-forward-port=port=22:proto=tcp:toport=2222 --zone=public

1	firewall-cmd --permanent --add-forward-port=port=22:proto=tcp:toport=2222 --zone=public

16. April 202430. April 2024

[solved] cannot install the best update candidate for package gdal36-libs-3.6.4-5PGDG.rhel9.x86_64

WTF do I have to do to get this bug fixed?

There are a bunch of search results, in the end leading to this dead end, bureaucracy bullshit ticket:
https://trac.osgeo.org/postgis/ticket/5664#ticket
pramsey says, “Please report build issues to the builder, as they won’t get fixed here.”

Typical bureaucratic bullshit.

Yes, crb is enabled.
Yes, epel is installed.

Why is this shit not getting fixed?

Error: 
 Problem 1: cannot install the best update candidate for package gdal36-libs-3.6.4-5PGDG.rhel9.x86_64
  - nothing provides libarmadillo.so.12()(64bit) needed by gdal36-libs-3.6.4-6PGDG.rhel9.x86_64 from pgdg-common
  - nothing provides libkmlbase.so.1()(64bit) needed by gdal36-libs-3.6.4-6PGDG.rhel9.x86_64 from pgdg-common
  - nothing provides libkmldom.so.1()(64bit) needed by gdal36-libs-3.6.4-6PGDG.rhel9.x86_64 from pgdg-common
  - nothing provides libkmlengine.so.1()(64bit) needed by gdal36-libs-3.6.4-6PGDG.rhel9.x86_64 from pgdg-common
 Problem 2: package postgis34_16-3.4.2-3PGDG.rhel9.x86_64 from pgdg16 requires libgdal.so.34()(64bit), but none of the providers can be installed
  - package postgis34_16-3.4.2-3PGDG.rhel9.x86_64 from pgdg16 requires gdal38-libs >= 3.8.4, but none of the providers can be installed
  - cannot install the best update candidate for package postgis34_16-3.4.2-1PGDG.rhel9.x86_64
  - nothing provides libarmadillo.so.12()(64bit) needed by gdal38-libs-3.8.5-1PGDG.rhel9.x86_64 from pgdg-common
  - nothing provides libkmlbase.so.1()(64bit) needed by gdal38-libs-3.8.5-1PGDG.rhel9.x86_64 from pgdg-common
  - nothing provides libkmldom.so.1()(64bit) needed by gdal38-libs-3.8.5-1PGDG.rhel9.x86_64 from pgdg-common
  - nothing provides libkmlengine.so.1()(64bit) needed by gdal38-libs-3.8.5-1PGDG.rhel9.x86_64 from pgdg-common
  - nothing provides libarrow.so.900()(64bit) needed by gdal38-libs-3.8.5-1PGDG.rhel9.x86_64 from pgdg-common
  - nothing provides libdeflate.so.0()(64bit) needed by gdal38-libs-3.8.5-1PGDG.rhel9.x86_64 from pgdg-common
  - nothing provides libarmadillo.so.12()(64bit) needed by gdal38-libs-3.8.5-3PGDG.rhel9.x86_64 from pgdg-common
  - nothing provides libkmlbase.so.1()(64bit) needed by gdal38-libs-3.8.5-3PGDG.rhel9.x86_64 from pgdg-common
  - nothing provides libkmldom.so.1()(64bit) needed by gdal38-libs-3.8.5-3PGDG.rhel9.x86_64 from pgdg-common
  - nothing provides libkmlengine.so.1()(64bit) needed by gdal38-libs-3.8.5-3PGDG.rhel9.x86_64 from pgdg-common
  - nothing provides libarrow.so.900()(64bit) needed by gdal38-libs-3.8.5-3PGDG.rhel9.x86_64 from pgdg-common
  - nothing provides libdeflate.so.0()(64bit) needed by gdal38-libs-3.8.5-3PGDG.rhel9.x86_64 from pgdg-common
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

Error:

Problem 1: cannot install the best update candidate for package gdal36-libs-3.6.4-5PGDG.rhel9.x86_64

- nothing provides libarmadillo.so.12()(64bit) needed by gdal36-libs-3.6.4-6PGDG.rhel9.x86_64 from pgdg-common

- nothing provides libkmlbase.so.1()(64bit) needed by gdal36-libs-3.6.4-6PGDG.rhel9.x86_64 from pgdg-common

- nothing provides libkmldom.so.1()(64bit) needed by gdal36-libs-3.6.4-6PGDG.rhel9.x86_64 from pgdg-common

- nothing provides libkmlengine.so.1()(64bit) needed by gdal36-libs-3.6.4-6PGDG.rhel9.x86_64 from pgdg-common

Problem 2: package postgis34_16-3.4.2-3PGDG.rhel9.x86_64 from pgdg16 requires libgdal.so.34()(64bit), but none of the providers can be installed

- package postgis34_16-3.4.2-3PGDG.rhel9.x86_64 from pgdg16 requires gdal38-libs >= 3.8.4, but none of the providers can be installed

- cannot install the best update candidate for package postgis34_16-3.4.2-1PGDG.rhel9.x86_64

- nothing provides libarmadillo.so.12()(64bit) needed by gdal38-libs-3.8.5-1PGDG.rhel9.x86_64 from pgdg-common

- nothing provides libkmlbase.so.1()(64bit) needed by gdal38-libs-3.8.5-1PGDG.rhel9.x86_64 from pgdg-common

- nothing provides libkmldom.so.1()(64bit) needed by gdal38-libs-3.8.5-1PGDG.rhel9.x86_64 from pgdg-common

- nothing provides libkmlengine.so.1()(64bit) needed by gdal38-libs-3.8.5-1PGDG.rhel9.x86_64 from pgdg-common

- nothing provides libarrow.so.900()(64bit) needed by gdal38-libs-3.8.5-1PGDG.rhel9.x86_64 from pgdg-common

- nothing provides libdeflate.so.0()(64bit) needed by gdal38-libs-3.8.5-1PGDG.rhel9.x86_64 from pgdg-common

- nothing provides libarmadillo.so.12()(64bit) needed by gdal38-libs-3.8.5-3PGDG.rhel9.x86_64 from pgdg-common

- nothing provides libkmlbase.so.1()(64bit) needed by gdal38-libs-3.8.5-3PGDG.rhel9.x86_64 from pgdg-common

- nothing provides libkmldom.so.1()(64bit) needed by gdal38-libs-3.8.5-3PGDG.rhel9.x86_64 from pgdg-common

- nothing provides libkmlengine.so.1()(64bit) needed by gdal38-libs-3.8.5-3PGDG.rhel9.x86_64 from pgdg-common

- nothing provides libarrow.so.900()(64bit) needed by gdal38-libs-3.8.5-3PGDG.rhel9.x86_64 from pgdg-common

- nothing provides libdeflate.so.0()(64bit) needed by gdal38-libs-3.8.5-3PGDG.rhel9.x86_64 from pgdg-common

(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

Update:
epel is installed, but not enabled by default. Unbelievable.

#postgres #postgis