AIX 7.2

AIX

https://kruemcke.wordpress.com/2015/10/05/aix-7-2-and-october-power-sof…

---

AIX V 7.2 Standard Edition (5765-G98)

New AIX Release
- Live Kernel Update for Interim Fixes
- RDS v3 support over RoCE 40GB adapters
- Restructured bos.net.tcp.client packaging
- Support for POWER7 and later processors
- Dynamic System Optimizer included
- Obsolete packages removed
- Server based Flash Caching (w/AIX 7.1 TL4)
- NIM support for HTTP (w/AIX 7.1 TL4)
- SRIOV vNIC adapter support (w/AIX 7.1 TL4)

( Huncraft v | 2015. 10. 05., h – 16:46 )

ohh.. Hogy már publikus? Utoljára mikor néztem még csak házon belül lehetett róla beszélni :)
De hogy ontopic is legyek: Linux alatti live patchingnél is előjött az, hogy hiába tudod a kernelt magát patchelni, a szolgáltatást magát így is úgy is újra kell indítani a különböző library függőségek miatt (amik viszont időközben változhattak). Szóval nem tudom AIX alatt ez mennyire lesz ténylegesen kihasználva.
____________________________________
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!"..

Technikailag erre eddig is volt lehetőség, igaz ezt az IBM semmilyen formában nem támogatta. Gondolom ezért is nyitottak ebe az irányba, mert rájöttek, hogy jobb ha az ügyfelek igényeit elégítik inkább ki, mintsem hogy elkezdjék őket perelni, és így veszítsék el őket..
____________________________________
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!"..

Igen, de a szolgaltatas-ujrainditast szet lehet huzni, hiszen a mar futo processzek less likely fognak behuzni uj verzios fuggosegeket, ami kell neki, az joreszt a memoriaban van. Vagyis a kernel patching az lemehet egyszerre mindenutt, a service restart meg lemehet maintenance idoablakban.
--
Blog | @hron84
Üzemeltető macik

5.2 jó ideje nem támogatott, az 5.3ra is már csak extended support van (az is csak jövő Áprilisig).
Aki nagyon akarja, az még 7.1es AIX alatt futtathat 5.3as WPAR-t, de azt se sokáig (A pontos időpont még nem hivatalos)
Utána az 5.xes korszak lényegében lezárul teljesen
____________________________________
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!"..

"És ez miben jobb mint az XY linux disztribució?"
"Hol lehet esetleg kipróbálni?"
"Ez még él? Azt hittem az IBM már dobta az OpenPower / OpenKVM óta"

Folytassam? :)
____________________________________
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!"..

Igazad van, rosszul fogalmaztam.

Az általad megjósolt ravasz fogós kérdések eltörpülnek a "szakértő fórumozók" hajmeresztő tájékozatlanságához képest. Egy másik fórumon olvastam, hogy a hozzászóló valamilyen pentium órajelét jól felhúzván közölte: ennek is van olyan gyors a memóriája! Mindez valamilyen POWER6 vagy 7 cikkel kapcsolatban.

A néhány soros bejelentésről szóló cikkecske előtt tisztázni lehetne, hogy ez egy teljesen - és mennyire más platform. (Nem, nem erre a topicra gondoltam.) A HUP AIX FAQ sem lát el elegendő információval - meg én sem értek mindent belőle. Annak meg, aki alig külöböztet meg egy raspáj, egy pc és egy power platformot nem sokat mond.

Mondok én is jó kérdéseket:
A Pentium 4 2 CPU-ként látszik a windows eszközkezelőjében, meg a POWER5 is annak látszana (ha azon a vacakon futna a windows:)) - mi is a különbség? Miért volt jobb már tíz éve az AIX lvm a jelenlegi linuxosnál? Mi az a fabric bus? Mi a különbség az Intel, az AMD és a POWER alapú virtualizáció között a CPU és szerver architektúrát figyelembe véve? (Meg a mikroparticionálás...)

Szerinted itt a hupon hányan hallottak ezekről a dolgokról és hányan tudnának rá válaszolni?
Azaz miért csodálkoznál a hülye kérdéseken?

Így már némileg tisztább..
A fenti 3 kérdés kb egy mini-válogatás volt azok közül amiket néha-néha én is megkapok szakmai körökben ( @NagyZ :)), és amelyek már rég temetnék az AIX-et, mivel szerintük a "Linux már rég túlnőtte", "Linux alatt ezt is, meg ezt is, meg.. is lehet csinál így meg így.." és így tovább. Az általad emlegetett különbségek általában szóba se kerülnek, mert az vagy nem létszükséglet nekik, vagy nem látják, hogy a saját környezetükben ez milyen előnnyel járna (pl egy házi PC-n abszolút semmi értelme külön Entitled Capacity-t állítani)
____________________________________
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!"..

Ezt írtad:
"És ez miben jobb mint az XY linux disztribució?"
Erre tudom a választ: mindenben. ;)

Lehet hogy AIX mindenben jobb mint Linux, OS üzemeltetés szempontból. Lehet. De ugye az az AIX létezik valamiért, mégpedig azért hogy mindenféle (jobbára üzleti) alkalmazásokat futtassanak rajta. Alkalmazás üzemeltetés szempontból viszont egyáltalán nem jobb egy AIX mint egy Linux. Több gond van vele, a legnagyobb pedig épp a HACMP / PowerHA (szintén app szempontból).

Szóval csak azt mondom hogy az összképbe az is beletartozik hogy nem csak OS adminok használják azt az AIX-et :-) Ahogy én látom, app oldalról sokkal szívesebben választanak Linuxot, még akkor is ha AIX _önmagában_ jobb mint Linux.

____________________
echo crash > /dev/kmem

Azért azt tegyük hozzá, hogy a HACMP/PowerHA legnagyobb problémája inkább az, hogy az emberek azt hiszik, hogy mindenre jó, és ez miatt meg is próbálják mindenre ráhúzni. A gyakorlatban viszont pont hogy csak olyan dolgokra kéne ráhúzni, ami amúgy semmiféle más clustering/HA technológiát nem támogat, mivel a HACMP alapjáraton csak azzal törődik, hogy az erőforrások elérhetőek e amik az adott app futásához kellenek (igen, van application monitoring script, de azokat vagy te írod meg, vagy a cég adja (tipikusan olyan programok mellé amik amúgy is támogatnának HA-t valamilyen más formában).
És mivel a (tapasztalatok alapján) legtöbb üzemeltetőnek fogalma nincs mire és hogy is kéne figyelni (főleg ha még valamiféle separation of duties is bejátszik), így hát nem csoda, hogy az így kreált scriptek az esetek túlnyomó részében olyan gányoltak, mint annak rendje és módja.
____________________________________
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!"..

Alapvetően egyetértek. Ha magas rendelkezésre állás kell azt app level szinten célszerű megvalósítani. Ettől függetlenül:

- Láttunk már PowerHA-t / HACMP-t elhasalni kompletten, többször is (clRGinfo ERROR-t mutat egy RG-re).
- 4 RG egy 2 node-os HACMP clusteren. Kotorászd elő mikor mi hol fut éppen.
- HA scriptek karbantartása. Jó, itt főleg app oldali trógerség van, elismerem. De akkor is nyűg.
- A failover LPAR-on x GB-al kevesebb RAM vagy kevesebb vCPU van mert kellett máshová, WLM valamiért nem ad az LPAR-nak, failover elhasal.

Nyilván ezek a problémák nem lennének ha nem kellene HACMP-t használni, de kell. Legtöbbször lenne más megoldás, de esetleg a HACMP olcsóbb. Mondjuk nem nagyon hiszem, egyszer leülök már licence pénzt számolni.
Nekem jobban tetszene az ha nem lenne HACMP, vagy csak limitált kivitelben, és mindenki rá lenne kényszerítve az app level clusteringre / HA-ra.

De ez csak egy dolog. Láttunk már olyat is hogy ipcrm nem tudta kipucolni a vonatkozó shm-et, és LPAR reboot kellett. Linuxon ilyet én még nem láttam.

Nem flame, én kedvelem AIX-et, Solaris-t is egyébként, Linux-ot is. Csak vannak körülmények amiért a többség Linux-ot részesíti előnyben.

____________________
echo crash > /dev/kmem

Hasonló hibákat én is nem1x kellett debugoljak már. És tényleg nem akarom védeni a HACMP-t, de sokszor vacak tervezés, vagy hülyén megírt script volt a ludas, bár az is tény, hogy nem egy bugba futottam bele az idők során én is (mai napig kedvenc a [name_your_app] alatti named pipe, amit a HA a mai napig nem tud lekezelni (mivel a fuser a named pipe-okat nem látja, és ez szépen bent is van a manban).

Azok közül amiket említettél tapasztalat alapján ilyesmik állnak a háttérben:
1) - Vagy el van kefélve a script, vagy HA bug, ritka esetben resource elérhetőségi probléma. Az esetek 90%-ában a script a ludas.
2) - Na ezt speciel én teljesen jól le tudom követni, bár tény, hogy kell hozzá némi rutin (meg az se árt ha a stop/start scriptjeid is jól össze vannak rakva)
3) - Már megint azok a fránya scriptek..
4) - Ez bocs, de design. Tény, hogy HA alatt van lehetőséged DLPAR-t hívogatni, de azért én erre HA megoldást nem mertem még építeni (HMC RSCT-je most pl a 8.8.1 HMC alatt pont bugos). Tapasztalat alapján az ilyet inkább érdemes a scriptekben levezényelni ha már tényleg elemi kérdés
5) - ipcrm az jogos, feltéve, ha az app normális privilege separation-t valósít meg. Ha viszont minden shared memory segment root alatt van, ott tényleg előfordulhatnak érdekes jelenségek (VMM alatt néha tracelgetek ilyeneket is - általában az jön ki, hogy valami driver még pluszban belenyúl a játékba, és olyankor a kernel nem engedi elvenni, mondván, hogy alacsonyabb szinten még használatban van).

Amúgy Linux alatt azért se láthattál ilyet, mert ott neked rootként jogod van direkt olvasni a memóriát (ergo töredéknyi védelem nincs, mint AIX alatt)

Amúgy félre ne érts: Sokszor tényleg a Linux jön ki győztesen, mert a customer vagy nem tudja hogy mit akar pontosan és ez miatt xarul határozza meg az igényeit (az ilyen customer általában nem is tudja mit kéne nézni), vagy tudja, csak neki erre egy Linux is bőven megteszi. Viszont van az a szint ahol ez már kevés.
____________________________________
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!"..

Nem teljes ide tartozik, de ha mar a HACMP/PowerHA szoba kerult, azert a Red Hat Cluster Suite is megerne egy miset a parhuzamosan felmountolt ext3-al majd egy gyonyoru korrupcioval osszekovtve. (A "support"-rol meg amit a Red Hat ad jobb szot nem is ejteni ilyen esetekben)

Szerintem egyik cluster suite sem ved meg a hibasan osszetakolt monitornig scriptek ellen vagy a bugos cluster managertol..

"A néhány soros bejelentésről szóló cikkecske előtt tisztázni lehetne"

Miert, a tobbi fooldali cikk eseteben tisztazva van? Tessek elovenni a Solaris bejelenteseket, ott se volt soha tisztazva, hogy ez milyen platform, es Treyen kivul gyakorlatilag senki se hype-olta a Solarist annyira, hogy valami ertelmes szovegek lettek volna korotte. Ehhez kepest az AIX mar nagyon jo helyzetben van az AIX FAQ-val, a HUP Wiki-s bejegyzessel, illetve azzal a tajekoztato munkaval, amit Gyuszk, LGee es Huncraft csinal.

En kicsit vihart erzek a biliben. Az egesz onnan indult, hogy kijott egy tobbtiz eves kereskedelmi Unix disztribucio uj verzioja, en erre felvetettem, hogy ebbol lehetne fooldali hir, mint ahogy kettonna mas cuccnak az uj verziojarol is van fooldali hir, a Puppy Linuxtol az Androidos cuccokig, ez is elferne a hirfolyamban, erre kipattant ez itten.

Kevesbe lesz jo az AIX ha a trollok megfikazzak a fooldali cikket? Vagy mi az, ami miatt ennyire aggodtok?

Lehet, hogy en ertek felre valamit, de sehogy nem jon ki a matek, pedig igencsak probalkozok.

Hogy letudjuk a kotelezo "te miert nem kuldod be" kort: 1) en nem vagyok AIX-os, sose hasznaltam, nem tudom, hogy ebbol a bejelentesbol mit lenne erdemes kiemelni 2) LGee es Huncraft az AIX ket, szeles korben is ismert arca az oldalon, toluk hitelesebb lenne egy ilyen bejelentes, foleg ugy, hogy Huncraft-rol tudni lehet, hogy egyben IBM alkalmazott is, es napi szinten dolgozik AIX-okkal, ha valaki, hat o pontosan tudja, mire lenne kivancsi az AIX-ok uj verziojara ehes kicsiny nep.
--
Blog | @hron84
Üzemeltető macik

Oda is írtam, hogy nem ebben a topicban...

Én csak a magam nevében tudok nyilatkozni. Egész egyszerűen AIX fan vagyok. Tehetem ezt azért, mert ilyen rendszereken közel 20 évet dolgoztam mint üzemeltető/rendszerprogramozó/üzemeltetés támogató. Előtte és utána is hardverfejlesztőként keres(t)em a kenyerem. Talán ezért több figyelmet fordítottam az IBM POWER szerverek belsejének megismerésére. Annyit mondhatok, hogy lenyűgöző az erőforrások harmóniája. Számomra azért is volt érdekes, mert általában a szerver nyers erejét kellett kiaknáznom, vagyis elég nagy jártasságot szereztem a rendszerek hangolásában is.

A fentiek alapján mertem megítélni, hogy a AIX FAQ alapján nem sokat lehet megtudni erről a nagyszerű rendszerről. Nem vagyok IBM bérenc! A jelenség olyasmi, mint amikor a fejedet ütöm: Nézd meg már milyen jó csaj megy az utca túlodalán!! És sajnálkozom, ha gyengébben látsz, vagy nem a lányokat szereted. ;)

Kevesbe lesz jo az AIX ha a trollok megfikazzak a fooldali cikket? Vagy mi az, ami miatt ennyire aggodtok?
Hát, hogy megint a vak ember szidja Rembrandtot! ;)
Talán nem kellene ennyire komolyan venni...

"Nem vagyok IBM bérenc!"

Senki sem allitott ilyent

"A fentiek alapján mertem megítélni, hogy a AIX FAQ alapján nem sokat lehet megtudni erről a nagyszerű rendszerről."

Ez igaz, viszont ez a mennyiseg pont eleg. Az informatikusok nagy tobbsege a kozelebe nem kerul egy ilyen gepnek, reszint azert, mert keves ceg engedi meg maganak azt a luxust, hogy ilyen rendszert futtato gepe legyen, reszint mert az AIX nem PC-kompatibilis, vagyis kis esellyel fog random szervereken felbukkanni. Azoknak, akik csak tenyszeruleg erdeklodnek a tema irant ("olvastam valami AIX-rol, minek a roviditese ez, egyaltalan ezt eszik vagy megisszak?"), annak az AIX FAQ boseges tajekoztatast nyujt, aki pedig melyebben el akar merulni a temaban, az amugy is az IBM sajat dokumentaciojat veszi elo.

"Talán nem kellene ennyire komolyan venni..."

Hat, nem volt a kommentben smiley, en meg csak kapkodtam a fejem, hogy hirtelen A-bol hogy jutottunk el Z-be a tobbi betu erintese nelkul... :-)
--
Blog | @hron84
Üzemeltető macik

+1
Én is az IBM doksikból okosodtam. Persze volt egynéhány gép is a kezem alatt, meg otthon is, amin dolgoztam. Tehát sok dolgot ki is tudtam próbálni. Most csak porosodik szegény. :(

A smiley azért maradt el, mert elégnek találtam a "vak embert". ;)

Csak egy gondolat bánt engemet: HUP=Hungarian UNIX Pc... Vagy mégse? ;)

Bedobtam trey-nek, meglátjuk mi lesz belőle.. Sokat ne várjatok, nem vagyok jó hivatalos szöveg összedobásában.
Plusz a másik nagy bajom, hogy csomó olyan dolog van amit simán nem írhatok bele, akármennyire is tudnék róla oldalakat írni.
____________________________________
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!"..

Flame war akkor keletkezik, ha elkezditek etetni a trollokat. Egyebkent meg... flame war ide vagy oda, ez szvsz fontos hir egy kereskedelmi disztrorol, viszont alig ismerek olyat, aki AIX-ezne rajtatok kivul (oke, meg NevemTeve), szoval ha ti nem rakjatok ki, senki. Treynek nem biztos, hogy a radarjan van ilyesmi.
--
Blog | @hron84
Üzemeltető macik

( asm v | 2015. 10. 07., sze – 18:54 )

LTO7-rol is lehetne egy cikk, de az IBM mar csak ilyen underrated manapsag...

( NevemTeve | 2015. 10. 08., cs – 16:51 )

Bezzeg ha azt kérdezném, hogy a libpthreads.a[shr_xpg5_64.o]-ból miért hiányzik a __pthreads szimbóleum az 5.3 egyes alverzióiban, akkor nem lenne ennyi hozzászólás.

Ami azt illeti valószínű ugyan ez lenne a helyzet ha nem 5.3as AIXról lenne szó, hanem mondjuk 14.04es Ubunturól. Ez a fórum nem pont fejlesztőknek szól, azt azért be kell látni.
____________________________________
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!"..

Ugyebár ha nincs opensource, akkor az ember saját kútfőből tákol-bákol, esetünkben ebből a fájlból csinálok a shared libet, és hozzálinkelem a problémás komponenshez (Ora12.1 ProC): 


/* lib__pthreads.c */

/* valamiért ez hiányzik az Oracle-nak...
   és a libpthreads[shr_xpg5_64]-ban kellene legyen
 */

int __pthread;

Aztán vagy jó lesz, vagy nem.

Azért az ilyen tákolásokat pont azért se díjazzák, mert elvileg az adott termék (esetünkben Oracle) csak certified verzión kéne fusson. Ha azon a verzión vagy, de ilyen hibába botlasz, akkor ott valami nagyon komoly gubanc van. Ellenkező esetben viszont sokszor tényleg oka van, hogy az adott termék adott verziója miért is nem certified adott OS adott verziójára (mert általában nem csak 1-2 library hiányzik, hanem a meglévők is másként működhetnek (WAS support team emlékszem mekkorát nézett amikor kiderült, hogy a 6.0-ás WAS azért halálozik el 1-2 nap után, mert az általuk használt hívás deprecated lett és teljesen kikerült a rendszerből (a library attól még maradt)).
Szóval az szép és jó, hogy te összefoltozgattad (mivel 12.1es Oracle ugye csak 6.1/7.1 certified), de a főnököd helyében én nagyon gyorsan elgondolkodnék egy upgrade-en, mert ha te otthagyod a céget, akkor ez az egész "vagy jó lesz, vagy nem." olyan gyorsan képes lesz összeomlani, mint a kártyavár..
____________________________________
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!"..

Igazad van, azonban a fonoke helyeben o sem donthet. Ha neki ezt a kornyezetet kell uzemeltetnie, akkor ezt kell, es kesz, a dalnak itt van vege.

Biztos vagyok benne, hogy van az IBM-nek is egy csomo dontese, amivel nem ertesz egyet, megse tudsz mast tenni, mint jelzed az aggalyaidat, nyelsz egyet, es tolod tovabb a szekeret a lejto fele.
--
Blog | @hron84
Üzemeltető macik

Stimt, de nem is kezdek el picsogni, hogy nem találok egy fórumon se segítséget egy olyan problémára, aminek amúgy nem is kéne léteznie, ha mindenki betartaná a játékszabályokat :)
____________________________________
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!"..

Off: Segítséget?! Hol láttál itt olyan topikot, ahol valaki érdemben segítséget kapott volna AIX-os kérdéssel kapcsolatban? Én csupa olyan topikot látok, ahol a kérdező és válaszadó ugyanaz a személy.

Edit: Na jó, ez felesleges flame volt, és van benne egy kis túlzás is, elnézést kérek.

<Off>
Igazából itt InstantClient-ről van szó, erről a linkről szedtem le: http://www.oracle.com/technetwork/topics/aix5lsoft-098883.html
</Off>

Egyébként valóban, és is csak akkor tákolok és gányolok, ha muszáj.
Vagy ha van előnye a megpatkolt verziónak. Például éppen ez az OraInstantClient néha olyat mond, hogy dlopen('libclntshcore.so')... aztán vagy bejön valahonnan valamilyen verzióju libclntshcore.so, vagy nem.Na ezt én terrordiktatórikus módon lecserélem dlopen('/opt/lib[64]/libclntshcore.so.12')-re

Ezzel egyutt az, amit mar nem is tudom, hany eve tolsz, erosen tul van a "takolok, ha muszaj" hatarvonalon. Nehezen tudom elhinni, hogy egy jol prosperalo, magara valamit is ado ceg ennyire regi cuccokkal dolgozzon a valtozas minimalis lehetosege nelkul. Felreertes ne essek: jol tudom, hogy vannak olyan helyek, ahol nem _lehet_ valtani, de ott viszont az altalad tolt ganyolasok sem lennenek megengedettek. Szerintem, ami korulotted tortenik, az a vezetok ostobasaga miatt van, a problema csak az, hogy te orommel vagy partner ebben. Bar ne lenne igazam.

Ami a libclntshcore.so-t illeti: a legtobb esetben ezt az LD_LIBRARY_PATH megfelelo alternativajaval szokas megoldani, hogy meg csak veletlenul se tortenhessen meg olyasmi, ami nem tamogatott szituaciokhoz vezet, pont azert, mert egy normalis cegnel kiemelten fontos, hogy egy olyan szoftver, amiert fizettunk es tartozik hozza megvasarolt/megvasarolhato tamogatas, tamogathato is legyen.

A te altalad takolt rendszerekkel az a gond, hogy ha _barmilyen_ problemad lesz a felepitett kartyavarral, csak nezheted, ahogy maga ala temet, mert az IBM mernok az elso harom parancs utan ott fog hagyni, az ugyanis mar kicsit sem hasonlit az AIX-re, ami nalatok fut. Az mar jo uton van egy custom UNIX disztro fele.
--
Blog | @hron84
Üzemeltető macik

Nem akartak. Az AIX egy kereskedelmi disztro, es a vasarloik tobbsege rendszeresen frissit az ujabb verziokra, hogy ne vesszen el a tamogatas, nem volt ertelme egy mar az IBM altal sem tamogatott rendszeren kiprobalni, hogy fut-e. Kicsit olyan ez, mintha azert menne a hoborges, hogy szoftverek nem futnak mar Win98-on. Hat igen, mert annak mar vege, kanyec filma.
--
Blog | @hron84
Üzemeltető macik

Ez is egy hozzáállás.

Azért ideírok egy tapasztalatot, hátha okulsz belőle. ;)
A rendszer az írások szerint működött AIX 5.1-en. De szigorúan legfeljebb azon. (Csak úgy megjegyzem, 4.3-ról raktuk át)
Kérdés: Működik-e 5.3-on?
Válasz: Végül is, csak opent meg seeket használunk, miért ne működne. ;)

Fogadni mernék, hogy AIX 7.x-en is menne! Ugyanúgy, ahogy azok a programjaim, amit 3.2.5-re írtam. Apró külöbség, hogy a fent említett termék >500MFt árú, míg az enyém ugye... :(((

Az EOL komponensek egy (viszonylag) zárt platformon azért érdekesek, mert 10 év után megfontolandó, hogy diszket cserélsz vagy ugyanannyiért veszel két gépet. Ez azért van, mert az utolsó TL lezárja a támogatott hardverek körét, és nincs tovább. Azaz esetleg van, de egy újab diszket idegenként tehetsz csak be, így meg nem tudja kihsználni az összes adottságát.

Az EOL rendszer használata döntés kérdése. Ha nem zavar a villanyszámla, van tartalék rendszer, nem kívánsz napi szintű támogatást (Ha a rendszer be van lőve, akkor NE nyúljon hozzá még az IBM se!), stb., akkor miért cserélnéd le? Ugye, ha veszel egy legújabb Mercit, azért nem vágatod le mindkét lábad, mert a Merci az modernebb? Így aztán a 16 éves szervert kukába helyezve még mindig kvalifikált és magasabb biztonsági szitű operációs rendszer volt rajta, mint a legfrissebb linux disztró. Tán ezért is hívják... ;)

Jól hiszed. Halkan megjegyzem: Sőt, még az AIX része sem volt.
Valójában később használtuk fejlesztői/üzemeltetői bejelentkezésekre, de befelé nem.
Kifelé meg PGP vagy egyedi kulcsú DES.

Mindez persze nem von le abból semmit, hogy az AIX B2 besorolású rendszer(-ré tehető) volt már huszonéve is. Eközben a linuxon már van acl is. :)

Tehát használhatod az OpenSSH-t, majd frissíted, mert újabb biztonsági rést találtak... Vagy megtervezhetsz/kialakíthatsz egy kellően védett, a feladathoz igazított biztonságú rendszert. Mondjuk figyelni kell mi történik, és kiszedni alólad a cuccost, ha rosszat szóltál. Ilyet meg még az OpenSSH sem tud.

Bár a kedvencem: "Nem elég biztonságos a rendszer! Javaslom a zmodem protokoll bevezetését!"

Kicsit feljebb irtam le:

"Felreertes ne essek: jol tudom, hogy vannak olyan helyek, ahol nem _lehet_ valtani, de ott viszont az altalad tolt ganyolasok sem lennenek megengedettek."

Azt gondolom, hogy egy > 500M forintot ero szoftverhez mar csak kotnek egy support szerzodest azz IBM-mel (lenyegesen kisebb osszegert), hogy ne fogjak nagyon padlot, ha gond van, es letornem minden, az oprendszerhez hozzanyulni akaro emberke kezet, hiszen elo support szerzodesem van az IBM-mel, ami arrol szol, hogy ok megoldjak a problemaimat.

De persze lehet, hogy rosszul latom, kerlek, homalyosits fel, hogyan kellene ezt a problemat valos szinekben latni.
--
Blog | @hron84
Üzemeltető macik

Azt, hogy mi a gányolás - már Richelieu bíboros is megmondta - a tett dátuma dönti el. ;)

Jól esik a kérdésed! Történetesen az említett szoftvert is az IBM szállította - a kopirájtjuk is benne volt. Valójában az egész szállított rendszer 3x anyiba került, a projekt 15 év után ért véget. Természetesen support is járt hozzá, amit úgy egy év után elvesztettek. Egyszerűen jobbak voltunk! :)

De lássuk a valós színeket!

Az oprendszer alapszintű (a low levelnél kicsit magasabb) parancsa hibásan működik. Ki kell javítani, majd figyelni a frissítéseket, hogy nehogy kijavítsa a javítást. ;)

Az IBM kizárólag egy adott terminálemulációval garantálja a rendszer helyes működését. Nos, amitől a rendszer auth modulja megbénul. Szerinted? Mi kicseréltük sajátra.

Természetesen a 15 év alatt történteket a végtelenségig lehetne sorolni. Mégis a kedvencem: Egy specifikált, de "a továbbiakban nem támogatott" interfész segítségével túrtam az adatokat. Nincs ezzel semmi baj. Ha az IBM szállít valamit, akkor annak általában van nyitott része, amit a felhasználó piszkálhat. Aztán a jobb megoldások esetleg belekerülnek a következő termékbe. - Később sor került egy tenderre, ahol hasonló megoldás látszott optimálisnak. Megkértük őket, hogy "vallják" támogatottnak. Ez egészen addig nem ment, amíg ki nem derült, hogy velük szeretnénk indulni. Láss csodát! Csak egy telefon az usába és az interfész támogatottá vált! :)

8X---

A részmegoldás erre a tread-re: AIX5L nem is létezik, csak a brossúrákon fut! Én legalábbis még nem láttam olyan gépet, amin ez futott volna.

Amikor elkészítesz egy terméknek csúfolt dolgot, azt illik becsomagolni az AIX alatt oly népszerű ;) installp formátumba. Abba lehet például ilyen is prereq libc.a 5.3.0.17 (prereq=prerequisite), de sokkal furmányosabb dolgok is. Szóval pontosan meg lehet határozni, hogy felrakhatod-e a terméket. És ha nem, akkor azt is, hogy mi hiányzik. (ckprerq)

Mi történhetett?
a) Az IBM hibázott. Valószínüleg letölthető egy gyorsjavítás (APAR)
b) Az Oracle hibázott. Ha igazad van, akkor figyelik az oprendszer frissítéseket, és onnan tölthető le egy javítás.
c) Az üzemeltető hibázott, és nem követte az a) és/vagy b) javításokat.
d) a) vagy b) nem javította a hibát - ez baj! Jöhet a gányolás! De ez kell, mert ezzel biztosítod a rendszer működését!

Kiegészítés: Még EOL terméknél is megtalálható egy összefoglaló patch gyűjtemény, ami általában beszerezhető. Ha meg az egyes szerverek nincsenek egyforma szinten - az szerintem hiba.

Az iso ilyenmegolyan szoftverkövetés kapcsán:
A westelesek nem bírtak bejelentkezni. (Automata rendszer.)
- Gyerekek! Módosítani kellene a szoftvereteket, mert hibás!
- Azt nem lehet, mert nálunk ISO van!
- De azért mégis! A westelt nem úgy írják hogy WESZTEL!!! :))))

Azért az Option D-hez lenne egy kiegészítésem: Igen, nem ritkán előfordul, hogy az IBM hibázik (szorgos kis indián kezek rendkívül jók a hibák elfedésében (nem úgy annak tényleges kijavításában). De ha már teszt adatokkal bizonyítani tudod, hogy az elérhető progi tényleg használhatatlan, sőt még patch javaslatod is van esetleg, akkor azért illik egy PMR-t nyitni, hogy ez bizony bug, és csak addig használni a "gányolást" amíg az IBM nem lesz szives így vagy úgy de megoldani a problémátokat. Ha ez nem következik be, akkor annak általában 3 oka lehet:
- A setupod nem támogatott alapjáraton se (mondjuk ezt a fent leírt esetre nagyon nem illik)
- A setup támogatott, csak épp azon a verzión amin vagy (OS/MW/App). Le kell ülni a tervező asztalhoz és átgondolni az upgrade/migrációs tervet
- A setupod támogatott, IBM is kiveszi a részét a támogatásból, csak mint kiderül a probléma nem náluk van, hanem egy külsős cég programjában. Ez esetben elő kell rántani a másik céggel kötött support contractot, és ott verni az ajtót (itt mondjuk előfordulhat olyan, hogy a 2 cég egymásra mutogat -> ilyenkor meggyőző eszkaláció, és a 2 csapat összerángatása telcoba, amíg le nem boxolják ott maguk között)

Olyan, hogy full támogatott vagy, de megoldást nem ad a cég rá nincs. Pontosabban lehet, hogy megpróbálják lenyomni a torkodon, csak nem szabad engedni (#penalty). Azért van a contract, hogy ha kell akkor magát a developert be lehessen rángatni az invesztigációba megfelelő számú eszkaláció után.

Szóval -szerintem- nyugodtan lehet tákolni (mivel te az SLA betartására szerződtél), de csak addig míg hivatalos megoldás nem lesz elérhető. Amint ez megvan azt tessék felrakni, és a tákolást megszüntetni.
____________________________________
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!"..

Olyan, hogy full támogatott vagy, de megoldást nem ad a cég rá nincs.
De bizony van. Olyan 8 centi vastag szerződésben lapozgatva próbáltuk megfogni őket. Az eredmény: Bakker! Ezek mindenre gondoltak! - Persze nem most kezdték a szakmát. ;)

Ugye itt már nem csak az OS hibáiról beszélünk. Egy komplex, számos rendszer összekapcsolásából született nagy rendszernél bonyolult feladat az egyetlen beszállítóval szót érteni. Különösen, ha a nagy egészhez nem ért. Az IBM alkalmi beszállítóinak munkáját újból elvégeztük precízen, hozzáértéssel. Egyébre esély sem volt. Se forráskód, se fejlesztő, eközben a feladat módosult és növekedett. Ebben az esetben ez volt a leggyorsabb, legolcsóbb és járható út. A rendszer IBM kezében maradt részeire is volt megoldás - amelyeknél nálunk hiányzott a szakértelem. Így lettem regisztrált IBM beszállító. ;) Az általuk szállított rendszer bizonyos részeihez semmi közük nem volt, de az én részemért csak én vállaltam garanciát. És minden működött.

Látszólag folyamatosan az IBM-et szidom, de így nem teljes a kép. Egyszer éjjel fél háromkor 380-at kapott az egyik rendszerünk. A hardver 30%-a gyakorlatilag megsemmisült. (Jó, az AIX szerverek kiírták, hogy 001, azaz hibás a feszültség.) Szóltunk, hogy baj van, és reggel 6 órakor már az amszterdami repülőtéren pakolták a tápegységeket.

Másik esetben "hibát jelentettem": Nem az OS-hez megfelelő szoftvert szállítottátok! Zavar volt az erőben, mintha nem is létezett volna megfelelő verzió. Ekkor az egyik kolléga szlovén fejlesztő haverjai raktak ki fél órára letöltésre egy nem is létező verziót. Másnap már műkodött is!

Szóval a lényeg: Gyakran az emberi hozzáálláson több múlhat, mint a szerződésen.

"Az általuk szállított rendszer bizonyos részeihez semmi közük nem volt, de az én részemért csak én vállaltam garanciát"
Na ilyen szerződést még nem láttam :D Mondjuk ilyen esetben még simán applicable a "setupod támogatott, IBM is kiveszi a részét a támogatásból, csak mint kiderül a probléma nem náluk van, hanem egy külsős cég programjában" verzió is, de ahogy írod itt már a szerződés is egy kisebb katyvasz (kivétel a szerződési feltételeket :))..

"Gyakran az emberi hozzáálláson több múlhat, mint a szerződésen."
Ezzel mondjuk 100%-osan egyet tudok érteni. Nem egy olyan kolléga van akit hajnalban felhívsz, és fél óra alatt rábök egy kernel dumpban a hibára, de tény, hogy több az akinek ez több időbe kerülne (vagy jóval többe)
____________________________________
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!"..

Most pont nem magamra, hanem egy német kollégámra gondoltam :D Őt már láttam élesben ilyet csinálni :)
Edit: Na jó, pont nem hajnalban, hanem este 8kor..
____________________________________
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!"..

Pedig én értem miről beszélek. ;)
Eredetileg az IBM rendszer adott egy interfészt, amiből dolgoztam. Ezt a rendszerelemet eredetileg én szállítottam, vagy 10 évvel korábban.
Adott a szitu, hogy egy új funkciót kell bevezetni, amelyhez az interfészt, az előtte és utána levő részt kell módosítani.(És még sok minden mást is.)
A megrendelő érdeke, hogy egy db megrendelésből megoldja valaki a feladatot. A fővállalkozó érdeke, hogy a 2 hónapos projektre ne kelljen kiképezni valakiket egy év alatt. :) Ez áll a garanciális kérdésekre is. Nekem viszont support szerződésem is volt a rendszer kapcsolódó és egyéb részeire is. Tehát triviális, hogy egy módosítás kedvéért az IBM nem veszi át a szerződéseimet - miért is tenné.

Csak éppen a letöltött UDF image nem használható VIO-n Media Repository-ban, az 'mkvopt' parancs eldobja semmit mondó "Unable to ..." akármi hibaüzenettel.

A local contact holnap így nem fogja megúszni a datacenter-be rohangálást :D

szerk: PEBKAC... az első DVD image hibásan jött le... mentségemre mondva, az IBM nem ad chksum-ot letöltő oldalon, de hála LGee kollégának kiderült a turpisság!
------------------------------------------
"Nincs ez el**szva, csak másra lesz jó!"

( gthomas | 2016. 01. 11., h – 19:03 )

Még mindig lehet vi-al vagy cat-tal hibássá tenni a fájlrendszert?
(Könyvtárat megnyitod, és szerkeszted vi-al, aztán lemented).