Allgemein

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 202416. April 2024

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)

#postgres #postgis

29. February 2024

Google Chrome doesn’t delete my cookies

Yesterday I was on a site where I accidentally logged in with a banned account.
So i clicked the “2 pins” icon next to the address field and deleted the “stored data”.

Then i refreshed the page but the cookies were still set, unlike on Firefox, where the cookies are actually deleted.

This has got to be against some EU privacy law.