Blogbejegyzések

E-mail cím változtatás kihívás

Informatikusként a magán dolgaimat eléggé hanyag módon eddig egy e-mail címen kezeltem. Eddig egy személyes e-mail címem volt. Ez volt regisztrálva mindenféle közműhöz, szolgáltatóhoz, rendszeres előfizetésekhez. Ezt adtam meg akkor, ha valamit rendeltem. Továbbá ezt adtam meg barátaimnak és családtagjaimnak is. Sajnos egy személyes oknál fogva számomra ez az e-mail cím rossz emlékké vált, ezért úgy döntöttem, hogy megszüntetem és az e-mailezési szokásaimat is átszervezem.

- Külön e-mail címet és postafiókot csinálok a hivatalos dolgaimnak, a közműveknek, a szolgáltatóknak és a rendszeres előfizetéseknek.
- Ennek a postafióknak csinálok egy alias-t, amit kifejezetten a webáruházakból történő rendelésekhez fogok használni. Az erre érkező e-maileket szabállyal külön mappába pakoltatom, így az esetlegesen érkező reklám annyira talán nem fog zavarni. Ezt a mappát csak akkor figyelem majd, ha éppen valamit rendelek és úton van egy csomag.
- Lesz egy külön e-mail cím és postafiók a személyes levelezésre, amit családtagjaimnak, rokonaimnak és barátaimnak adok meg.

Ez a terv talán jó is és nemrég el is kezdtem megvalósítani. Azokban van egy bökkenő! Egyes szolgáltatóknál e-mail címet változtatni nem olyan egyszerű ám! Tapasztalatok:

Kedves kis etnikai tisztogatás

Biztos csak jót akarnak a magyar kisebbségnek azok az áldott jó emberek...: https://index.hu/kulfold/2023/08/31/ukrajna-iskola-igazgato-karpatalja/

Csináltak még pár ilyet az "egységesítés" nevében, a jó öreg kommufasoviniszta téveszmék által irányítva, pl. a turulszobor lebontása vagy vereckei emlékmű megrongálása, de azok nem egy közösség alapvető jogait veszik el. (Walesben és Írországban érdekes módon működik a regionális/őshonos nyelvhasználat támogatása és ott az emberek maguk mondanak le róla, nem kulturális/etnikai tisztogatás folyik.)

https://index.hu/kulfold/2023/03/24/ukrajna-karpatalja-turul-szobor-per…

https://pestisracok.hu/tombolo-magyargyulolet-ukrajnaban-a-vereckei-eml…

Sajnos ez nem politika, hanem az egyértelmű, szomorú tények.

Aki talál "indokot", hogy ezt az ukrán rendszert támogassa, az egyszerűen szociopata.

Az iptables szabályokat ufw-be raktam ...

root@debian:~#  cat setup_routing.sh 
#!/bin/bash

echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -v -t nat -C POSTROUTING -o enp7s0 -j MASQUERADE || iptables -v -t nat -A POSTROUTING -o enp7s0 -j MASQUERADE
iptables -v -C FORWARD -i enp7s0 -o wlp6s0 -m state --state RELATED,ESTABLISHED -j ACCEPT || iptables -v -A FORWARD -i enp7s0 -o wlp6s0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -v -C FORWARD -i wlp6s0 -o enp7s0 -j ACCEPT || iptables -v -A FORWARD -i wlp6s0 -o enp7s0 -j ACCEPT
 

helyett:

/etc/default/ufw
DEFAULT_FORWARD_POLICY="ACCEPT"

/etc/ufw/sysctl.conf
net/ipv4/ip_forward=1

/etc/ufw/before.rules végére

# NAT
*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 192.178.0.0/24 -o enp7s0 -j MASQUERADE

COMMIT

systemctl restart ufw.service

NAT ellenőrzése:

root@debian:/etc/ufw# iptables -t nat -L -v
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 262 packets, 24719 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  296 22972 MASQUERADE  all  --  any    enp7s0  192.178.0.0/24       anywhere

root@rock64:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether be:c2:d9:9a:28:d8 brd ff:ff:ff:ff:ff:ff
    inet 192.178.0.213/24 brd 192.178.0.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever

root@rock64:~# cat /etc/os-release 
PRETTY_NAME="Armbian 23.02.2 Jammy"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04 (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.armbian.com"
SUPPORT_URL="https://forum.armbian.com"
BUG_REPORT_URL="https://www.armbian.com/bugs"
PRIVACY_POLICY_URL="https://www.armbian.com"
UBUNTU_CODENAME=jammy

Rock64-en a DG=WLAN TCP/IP címe:

root@rock64:~# ip r s
default via 192.178.0.100 dev eth0 proto static metric 100 
192.178.0.0/24 dev eth0 proto kernel scope link src 192.178.0.213 metric 100 

root@rock64:~# chronyc sources
MS Name/IP address         Stratum Poll Reach LastRx Last sample               
===============================================================================
^+ prod-ntp-3.ntp1.ps5.cano>     2   7   377   333  -1279us[-1619us] +/-   30ms
^* prod-ntp-4.ntp4.ps5.cano>     2   8   377   274    -11ms[  -11ms] +/-   34ms
^+ prod-ntp-5.ntp1.ps5.cano>     2   8   377   136  -8625us[-8625us] +/-   37ms
^- alphyn.canonical.com          2  10   375   402    -45ms[  -45ms] +/-  241ms
^+ ntp2.niif.hu                  2   8   377   335  -9079us[-9419us] +/-   40ms
^+ mail.zsurob.hu                3   8   377   466  -6680us[-7011us] +/-   52ms
^+ ntp1.niif.hu                  2   8   377   270  -1259us[-1259us] +/-   28ms
^- inspektor-vlan196.debrec>     2   7   377     7  -7916us[-7916us] +/-   41ms
^? 192.178.0.213                 0   9   377     -     +0ns[   +0ns] +/-    0ns
 

Aldi és a PKI

Aldi-nál se pörgetik az IT-t valami mesterfokon. Egy órája még nyavalygott a browser az aldi.hu-ra h. lejárt a cert-jük. Ahogy nézem most cserélhették le (biztos épp nyaralt az üzemeltetős mérnök). Érintett még vagy 5-6 másik országot a SAN alapján.

(Gonosz mód on: lehet h. valamelyik napközben kasszás v. árupakolós ember mellesleg az IT-s is náluk, csak épp nagy volt a sor ezért neki is be kellett ugrania kasszába a cert lecserélés helyett)

Nem hogy állnának át LetsEncrypt-re ők is, az automatizálható állítólag elég jól.

Isten segítse meg mindnyájukat!

Az egyik jóember belerakott egy if-et a JBoss7-be, hogy ne induljon el 7-nél újabb Javával. A másik jóember kitalálta, hogy az xmlsec nevű komponensből újabb verzió kellene, mert ez (remélhetőleg)  EC-s kulccsal is tud XML-t aláírni. A harmadik jóember annyira híve a görög ABC-nek, hogy pár lambdát is rakott az xmlsec újabb verziójába. A végeredmény kitalálható. Én kérek elnézést.

CodeLlama olcsó PC-n

https://about.fb.com/news/2023/08/code-llama-ai-for-coding/ - itt van ugye ez az új model, ha nincs AI-képes GPU-d, akkor is tudod használni, ma délelőtt összelegóztam.

https://huggingface.co/TheBloke/CodeLlama-13B-oasst-sft-v10-GGML - innen kell a codellama-13b-oasst-sft-v10.Q6_K.gguf

git clone https://github.com/ggerganov/llama.cpp.git
cd llama.cpp
make -j8

és már mehet is:

./main -m ../codellama-13b-oasst-sft-v10.Q6_K.gguf -i -f yourprompt.txt

Minimál teszt Drupal 10 modul írására: https://twitter.com/NovakAron/status/1696068699856253088 - i9-9900K-en sokkal lassabb a ChatGPT-4-nál, kevésbé teljes választ ad, de van jópár részlet, amit kidolgozottabban csinált meg.

Quake 3 Arena + High-Resolution Textures

Aki hasonlóval szeretett volna játszani mostanában annak eddig is ott volt az OpenArena, ami a maga nemében nem rossz, de azért mégis másabb és mégsem azok a textúrák, hangok, skin-ek és nem azok a pályák amikkel régen játszottunk... A Steam-en fent lévő Quake 3 Arena sajnos csak Windows-os verzió, ahelyett viszont jó választás az ioQuake3, ami akár megy linuxon is. Rákeresve pedig van néhány lehetőség a kinézetet is túrbózni kicsit:

Az elméleti biológia Bauer elve az ős-hit szellemkvantum elméletének a tükrében

Az élet fizikai értelmezése a modern tudományban tabu, vagy ha nem is tabu, hát kínosan kerülendő kérdés. A fizikai törvények értelmezése megáll az élettelen anyagnál, az élővel nem tud mit kezdeni, ha egy követ leejtünk annak kiszámítható a pályája, tudjuk hová fog esni, de ha egy élő madarat ejtünk le, arra nem vonatkoznak a fizika jelenlegi törvényei, pedig a madár is anyagból van, illetve anyagból is, de tartalmaz még „életet” emellett. Az „élő anyag” viszont nem követi a fizika alapelveit.

Debian 12 + PHP <= 7.3 + Opcache = szívás

Figyelj, ha a sury.org repóból régebbi PHP verziókat (<=7.3) használsz, és a Debian 11 (Bullseye) rendszeredet Debian 12 (Bookworm) verzióra frissítenéd!
A Debian 12-es csomagokban a Zend Opcache el van törve. Azt fogod észrevenni, hogy egyes oldalgenerálások a timeout-ig futnak és 100% CPU-t esznek!

Workaroundként, az opcache kikapcsolása megoldani látszik a problémát.

A probléma reprodukálásához ezt a kódrészletet sikerült összehoznom:

$x = 0;
$y = hexdec("0200");

for ($i = 0; $i < 100; $i++) {
    if ($x >= $y) {
        $i += $y % 4;
        $x = 0;
    }

    $x++;
}

Ez a kód ilyen formában nekem 100%-os reprodukálhatósággal lerohad PHP 7.3 FPM használatával, ha az opcache be van kapcsolva.

Ugyanakkor:

Bár a var_dump($y) típusa és értéke int(512), de ha csinálok rá type cast-ot, akkor a kód máris nem rohad le:

$y = (int)hexdec("0200");

Az if() feltételben található kifejezésnek soha nem szabad teljesülnie, mert a ciklus 100-szor jár körbe, és a $x soha nem lesz nagyobb vagy egyenlő 512-vel, de ha az if()-en belül megváltoztatom a $i += $y % 4; értékadást $i += 5; -re, akkor szintén nem rohad le.

You have been warned.