Lehetne amd64-re AIX-ot tenni?

Mert ha igen, akkor létre tudnék hozni egy ilyen szabályt a /etc/syslog.conf-ban:
*.warning /var/log/warning.log rotate size 1m time 1m files 4 compress

Na ezzel szemközt a Gnu/Linux az meg van könnyítve, ott ilyen nincsen, viszont van syslog-ng, van systemd-journald, van itt minden jóság, csak egyvalami nincs: tartalom a /var/log/warning.log fájlban. Hát ez az egy nincs, de számít ez egyáltalán a megkönnyített és felhasználóbaráttá tett szoftverek világában?!

Szerk: ne adjuk fel a csüggedést, de aki nem kiváncsi a rossz hírekre, az most ne olvasson tovább: ez a syslog-ng magyar termék :(
Így persze az sem csoda, hogy az rpm-ből telepített csodaság configja a /opt/ alá került, hova máshová.

( NevemTeve | 2023. 06. 27., k – 14:54 )

Szerkesztve: 2023. 06. 27., k – 14:55

No, hiszti off, az alábbit tákolva a kernel üzeneteit megkapjuk. Igaz, hogy én az sshd-ét akartam volna olvashatni, de ne legyünk nagyralátóak, talán majd legközelebb.

filter f_warn_emerg { level(warn .. emerg); };
destination d_warn { file("/var/log/warning.log"); };
log { source(s_src); filter(f_warn_emerg); destination(d_warn); };

Igaz, hogy én az sshd-ét akartam volna olvashatni

De miért itt? Az sshd az ugye syslogba logol, alapértelmezetten AUTH facilityvel és INFO szinten.
Az, hogy a syslog implementációd hova logol, az a te syslogod beállításától függ. Nincs olyan syslog szabvány, ami előírná ennek a fájlnak a létezését. Az, hogy AIX-on hogyan van, az meg egy implementációs részletkérdés.

Most, hogy így mondod, fogadni mertem volna, hogy ennek warning-nak kellene lennie, de nem, csak info:

Jun 27 15:31:58 randomaix auth|security:info sshd[53936206]: Authentication refused: bad ownership or modes for directory /home/teve

Ugyanis pont ezt az üzenetet akartam tesztelni.

Az alábbival már szinte tökéletes:

filter f_warn_emerg { level(warn .. emerg); };
destination d_warn_emerg { file("/var/log/warning.log"); };
log { source(s_src); filter(f_warn_emerg); destination(d_warn_emerg); };

filter f_info_emerg { level(info .. emerg); };
destination d_info_emerg { file("/var/log/info.log"); };
log { source(s_src); filter(f_info_emerg); destination(d_info_emerg); };

A 'szinte' arra utal, hogy az sshd üzenetei még mindig nincsenek meg, hasonlóan a logger(1) és a saját tesztprogram üzeneteihez, de ez már tényleg apróság.

Nem akarom megnevezni az illetőt, aki sshd-t szokott patchelni (may Lennart rot in hell), de szerintem nem az sshd megpatkolása a probléma, hanem a teljes syslog-infrastruktúráé: a derék üzenetek megvannak valamilyen bináris fájlban, például ezzel a paranccsal szeptember 22-től június 6-ig megkapom a kérdéses üzeneteket:

journalctl _COMM=sshd

de hát syslog esetén nincs is előírás arra, hogy hol legyen és milyen formátumban a log. Az, hogy bináris formátumban van, teljesen szabványkövető. Mi a probléma? Hogy az egyik syslog implementáció nem ugyanúgy működik, mint a másik? Hát, szar a szabvány akkor.

( persicsb | 2023. 06. 27., k – 15:22 )

Szerkesztve: 2023. 06. 27., k – 15:23

Miért kéne léteznie a  /var/log/warning.log fájlnak egyáltalán? 
A UNIX nem írja elő, hogy létezzen.
Azt írja elő, hogy létezzen egy logger nevű utility, ami nem specifikált helyen és formában tárolja a logot.

https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/utilities/…

 The locations of the saved messages, their format, and retention period are all unspecified. There is no method for a conforming application to read messages, once written.

> Miért kéne léteznie a  /var/log/warning.log fájlnak egyáltalán?

Ez jogos felvetés, valamiért a pont a létrehozást nem csinálja meg a syslogd, de ha kézzel megcsinálom a fájlt (touch(1)), és újraindítom a syslogd-t, akkor hajlandó írni bele a fenti szabály alapján (és rotálja a szabályok alapján).

 *.warning   /var/log/warning.log   rotate size 1m time 1m files 4 compress

( Nyosigomboc v | 2023. 06. 27., k – 22:27 )

Elvileg nem latom akadalyat. QEmuval lehet architekturak kozott forditani, mondjuk az AIX-en megszokott hardware-eket meg valoszinuleg le kell implementalnod, de utana tehetsz egy lightweight x64-es Linux retegre egy virtualis AIX-et. A licenc mar mas kerdes.

A strange game. The only winning move is not to play. How about a nice game of chess?

Angyali naivitás. :-D

Először kellene az AIX forrása... Ami persze sokak szerint egy másik linux. ;) Pedig egy ideálisan összehangolt hw-sw rendszer, ami kicsit nagyobb falat, mint a C64-ben a CP/M dugó. (Z80)

A rideg tények.

Beszéltem már olyannal, akinek mesélték, hogy az AIX első verziója futott pécén.

Láttam PowerPc 604-en Windows NT-t (mert lefordították rá).

Ezek úgy 30 éve. történtek.

Viszont az AIX kifejezetten hw függő operációs rendszer. Még a diszk firmware is saját.

Persze ezt a topicnyitó is pontosan tudja, ezért tette fel az abszurd költői kérdést.

Szerintem pont az AIX forrasa nem kell hozza, ahogy a Windowse sem kell ahhoz, hogy VM-ben futtasd. Persze ha a HW nem ismert, es vissza kell fejteni, akkor segitene az AIX forrasa is, hogy hogyan hasznalja azt a HW-t. De nem ugy ismerem NevemTevet, mint aki ne ismerne az AIX-et. Meg amugy is meg szokott oldani cifra dolgokat.

Egyebkent nem tartom kizartnak, hogy a jelenlegi AIX is fut sima PC-n, csak nem arra adjak ki. De a fejlesztoknek a fejlesztes idejere kenyelmesebb, mint rogton az eles hardware-en probalgatni. Ugyanugy, ahogy iGO-t is PC-n fejlesztettunk, annak ellenere, hogy a vegen ilyen kiadas nem letezett (viszont volt mindenfele mas HW es SW architekturara).

A strange game. The only winning move is not to play. How about a nice game of chess?

Egyebkent nem tartom kizartnak, hogy a jelenlegi AIX is fut sima PC-n, csak nem arra adjak ki

Nem fut.. Az AIX-os kernel épít a PowerVM képességeire, és direktben kommunikál a hypervisorral, hogy a hardware-t on-the-fly lehessen piszkálni / cserélni igény szerint (CPU / memória csere, I/O adapter hozzáadása / eltávolítása, stb). Ezt emulálni nagyon nem kis meló lenne - ugyan a hypervisor egy real-time linux implementáció, nagyon sok proprietary része van ami nem hogy nem nyilvános, de még IBM berkeken belül is nehezen elérhető :)) 

Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Természetesen NevemTeve etalon, nem kell bemutatni. Bár jómagam fényezésére meg kell említenem, hogy csak 19 évet dolgoztam AIX alatt mint üzemeltető és rendszerprogramozó. (Még "Regisztrált IBM szovtverszállító" is voltam, számom is volt - bármit is jelentsen. ;)) Alapvetően hardveres vagyok, ezért érdekelt a POWER szerverek felépítése is. Az IBM jóvoltából elég sok olyan anyaghoz hozzájutottam, amihez mások nem, vagy csak nem hívták fel eléggé a figyelmüket a fontosságukra.

Maga az AIX+POWER CPU több menetes optimalizálással készült, hogy létrejöhessen az optimális operációs rendszer. De itt nem érdemes megállni, mert egy POWER szerver minden egyes eleme képes lenyűgözően együttműködni. Ezt lehet emulálni, mint a Z80-on a linux boot-ot. Tehát akár igazad is lehetne, de csak az épelméjűség határán kívül. ;) Egy harmonikus hw+oprendszer+sw rendszert pedig nem illene az iGO-val összehasonlítani, mert az csak egy sw.

POWER 5-től már "nem a gép bootol", hanem egy partíció (VM), amin az AIX fut. A hardver hotswap elemeit egy független szervizprocesszor kezeli.  Szerintem ezt elég nehéz lenne emulálni olyan hardveren, ami olyan 8-10 éves lemaradásban is lehet, amit soha nem fog utolérni. Hiszen nem ilyen jellegű szerver kialakítását célozták meg.

( Raynes v | 2023. 07. 02., v – 03:49 )

Szerkesztve: 2023. 07. 02., v – 03:50

Nyugi nem kell AIX-et feltenned amd64-re, az IBM olyan szépen bezárja a RHEL forrását, hogy lényegében AIX-et csinál belőle, és így a Pöcstering művek zseniális szésztömdí dzsörnöl szí tí eljéről sem kell feltétlen lemondanod, mert az a fogakat is tisztíccsalya.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( NevemTeve | 2024. 04. 24., sze – 12:07 )

Szerkesztve: 2024. 04. 24., sze – 12:12

Na mostan ezt próbáltam:


logger -p auth.info     "Teszt(/var/log/auth.log): logger -p auth.info"
logger -p authpriv.info "Teszt(/var/log/auth.log): logger -p authpriv.info"

De sikerült?!

Történetesen olyanom van, hogy /opt/syslog-ng/etc/syslog-ng.conf, ebben vannak /var/log/auth.log-ra vonatkozó részek, de talán mégsem olyan jók, mint kellene.

Talán ennek is van hozzá köze:

connect(3, {sa_family=AF_UNIX, sun_path="/dev/log"}, 110) = -1 ECONNREFUSED (Connection refused)

Ez a köcsög szívódott rá a /dev/log-ra:

$ netstat -anp | grep /dev/log
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node   PID/Program name     Path
unix  8      [ ]         DGRAM                    10283    1/systemd            /dev/log

$ bs2stat 1
%PID:      1          PPID:  0          NOW: 2024-04-24.14:01:01
%USERID:   root       GROUP: root       ELAPSED:    857-11:00:32
%STATION:  ?          PRI:   20 0       CPU-USED:       03:52:11
%SIZE(KB): 52260      %MEM:  0.0        %CPU:  0.0
%STATE:    S Sleeping                   WCHAN: ep_pol
%CWD:      /
%CMD:      /usr/lib/systemd/systemd --system --deserialize 20

Ösztön szerint belehaxoltam az egyik fájlba, de sikerült?! [spoiler: nem]


diff -u systemd-journald.socket.20220201 systemd-journald.socket 
--- systemd-journald.socket.20220201	2022-09-01 16:57:39.000000000 +0200
+++ systemd-journald.socket	2024-04-24 14:12:25.480114429 +0200
@@ -19,7 +19,11 @@
 [Socket]
 ListenStream=/run/systemd/journal/stdout
 ListenDatagram=/run/systemd/journal/socket
-ListenDatagram=/dev/log
+#
+# Nagyon jo dolog, ha Pöttering raszivozik a '/dev/log'-ra, peldaul azert,
+# mert akkor a 'logger(1)' vagy a 'sudo(8)' uzenetei elszallnak a semmibe
+# ListenDatagram=/dev/log
+#
 SocketMode=0666
 PassCredentials=yes
 PassSecurity=yes