Ez már nem a vacak és korszerűtlen AIX

Hanem a megkönnyített CentOS 7.8
Forrásból telepítettem az OpenSSL-1.1.1g-t, meg a curl-ből egy frisset, ebből teljesen logikusan az következett, hogy nem megy többé a yum.

There was a problem importing one of the Python modules required to run yum.
The error leading to this problem was:
/usr/lib64/python2.7/site-packages/pycurl.so: undefined symbol: CRYPTO_num_locks

Hát akkor nyomozzunk

$ readelf -d /usr/lib64/python2.7/site-packages/pycurl.so | grep NEEDED
 0x0000000000000001 (NEEDED)             Shared library: [libcurl.so.4]
 0x0000000000000001 (NEEDED)             Shared library: [libpython2.7.so.1.0]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

Ez nem is dependál a libcrypto-ra, akkor mi a lázadás tárgya?


nm -D /usr/lib64/python2.7/site-packages/pycurl.so | grep CRYPTO_
                 U CRYPTO_num_locks
                 U CRYPTO_set_id_callback
                 U CRYPTO_set_locking_callback

Ja hogy dependálni nem dependál a libcrypto-ra, de azért szimbóleumokat vesz belőle, 'miért is ne' alapon.

Hozzászólások

A csomagban lévő 1.1.1c (epel repo) nem lett volna  jó ? 

Fedora 32, Thinkpad x220

Az az igazság, hogy már fogalmam sincs, hogy honnan kezdődött az egész történet...

Talán ott, hogy `libzip` nevű komponensből olyan verziót telepített a CentOs, amit Werbőczy a Hármaskönyvben is elavultnak nevezett... Gondoltam, akkor jöjjön az is forrásból. Sajnos az a verzió már egy újabb megkönnyítőszoftvert használ, egy `cmake` nevűt.

A CentOS által telepített cmake túl régi volt... A cmake fordítása során került elő valahogy a curl, de itt már tényleg elvesztettem a fonalat.

Amúgy ez tényleg ez jó kérdés, miért kellett "kézzel" belenyúlni a történetbe ? Főleg openssl szinten, ami kb. eltörhet mindent is...  :) a yum már csak hab a tortán. De alapvetően a centos/redhat -ot nem arra tervezték, hogy a core cuccokat megpiszkálja az ember.

Amúgy is telepítsünk blekkPanthert! :)

Azt mondtam az üzemeltető kollégáknak, hogy az én Debian8.11-em (benne 3.16-os kernel) túl régi ahhoz, hogy a docker és a cgroups kölcsönhatásait a java11-gyel lehessen rajta tesztelni, adjnak pont olyat, amivel a produkciós rendszer megy. Hát adtak egy Centos7.8-at. Szerencsére az AIX5.3-on edződtem, abban is kb. ilyen szoftver-verziók vannak, mint ebben.

Szerk: Derék cmake saját curl-t akar csinálni, de nem nagyon megy neki. Egyrészt ugye tettem fel gyönyörű szép friss új curl-t, csak használni kellene. Másrészt mondtam neki, hogy LDFLAGS='-m64 -L/usr/local/lib64'
Az elsőre rá se füttyentett, a másodikra azt gondolhatta, hogy csak unalmamban beszélek hülyeségeket, és figyelmen kívül hagyta. Ez a Számítógépes Együttműködés Rendszere.

Szerk: megszórtam pár opcióval, hogy `--system-curl --system-expat --system-zlib` most bizonyára valami más hiba jön.

Beszéljünk a vasról... akarom mondani, talk about irony -- ez a derék cmake saját magát is önmagával akarja előállítani, de az sem megy neki...

Szerk: na mindegy, valahogy összeállt egy cmake, a lehető legegyszerűbb és kézenfekvőbb módszerrel:

find . -name link.txt | while read LinkTxt; do
    sed_repl '
         s/^[^ ]*g++.*$/libtool -debug-lalist --mode=link &/
        ' "$LinkTxt"
done

Már csak vissza kellene találni ahhoz a ponthoz, hogy mire is kellett ez a cmake. Ja, libzip-1.6.1-hez. Bár a méltányos az lenne, hogy az meg túl új lesz a programomnak, mint ahogy a libzip-0.10.1 (2008-ból) meg túl régi.

Ha a prod. CentOS 7.8, és tesztelni szeretnél valamit, akkor miért is kell beletúrni? Ja, hogy mint a legtöbb fejlesztőnél, nálad is a minél frissebb/magasabb verziószám okoz midnenféle gyönyört...? Akkor meg miért nem Fedora?

Lehet OS-komponensek függőségeit rommá tördelni, megmakeinstallmerazjó-t játszani - csak utána nem lesz, aki életet lehet az egész kupacba, illetve nem lesz, aki az adott környezetet üzemeltetni foggja, azonos verziókkal telepíteni fog újabb gépeket, etc.

Ha meg docker, akkor mi a péknek a "hordozó" OS-enmindenfélét gányolni? Lapátoljátok be az összes féceszt a nagy büdös konténerbe, a futtatókörnyezetet meg hagyjátok meg stabilnak.

Rendszerkomponseket turkálunk meg kézzel, a csomagkezelőt kikerülve. Ez amúgy masszív antipattern és pebkac, a csomagkezelő felségterületét nem illik kézzel baszkurálni. Ha valami nem tetszik, megprefixáljuk valami másik PATH -ra, és úgy telepítjük.

Majd legközelebb turkálj kézzel egy kicsit a C:\Windows alatti DLL-ekben, aztán ne csodálkozz.

És szigorúan az adott rendszer csomagkezelését nagyívben lesz... izé, megkerülve. Aztán egy frissítés után csodálkozni fog, hogy a gányolás után úgy-ahogy összerakott motyójából a "helyben ssütött" dolgok eltörnek... Vagy semmit sem fog frissíteni - ami production rendszerben nem elfogadható.

+1

A csomagkezelő fenntart egy lokális adatbázist minden egyes fájlról, verziókkal, telepítési dátumokkal, függőségekkel együtt. Ha megmozgatjuk azt, amit a DB elméletben precízen leképez, akkor utána borul az egész. Konténerezni vagy legalább nem csomagkezelős path -on kellene turkálni, akkor nem lesz gond. Vagy forrásból kell OS-t tákolni kézzel, mint tetszőleges slackware user x időnyi használat után :D

Szerkesztve: 2020. 06. 03., sze - 11:53

Közben találtam valamit, amit szintén nem tudtam eddig:

NAME
       strcasecmp, strncasecmp - compare two strings ignoring case

SYNOPSIS
       #include <strings.h>

       int strcasecmp(const char *s1, const char *s2);
       int strncasecmp(const char *s1, const char *s2, size_t n);

Én ennek a strings.h-nak a létezéséről sem tudtam. De úgy látszik a libzip fejlesztői sem:


/usr/local/src/libzip-1.6.1/lib/zip_name_locate.c: In function ‘_zip_name_locate’:
/usr/local/src/libzip-1.6.1/lib/zip_name_locate.c:65:34: error: ‘strcasecmp’ undeclared (first use in this function)

  cmp = (flags & ZIP_FL_NOCASE) ? strcasecmp : strcmp;

Ez valami külön jócselekedet lehet a RedHat részéről, hogy kikényszerítik a szabványos strings.h használatát.

Illetve, ha __USE_GNU van érvényben, akkor a sima string.h is deklarálja ezt a két függvényt.

Szerk: Oké, ez csak előző adásunk ismétlése: a `cmake` -t az olyan világi hívságok, mint CPPFLAGS nem érdeklik.

Szerkesztve: 2020. 06. 03., sze - 11:15

Transitive dep:
$ readelf -d /usr/lib64/libcurl.so | grep ssl
 0x0000000000000001 (NEEDED)             Shared library: [libssl.so.1.1]

$ readelf -d /usr/lib64/libcurl.so | grep crypto
 0x0000000000000001 (NEEDED)             Shared library: [libcrypto.so.1.1]
 0x0000000000000001 (NEEDED)             Shared library: [libk5crypto.so.3]

 

FHS  javaslata szerint te nem pakolhatsz libeket /usr - be kiveve /usr/local/* ,

A yum elrontasahoz meg kellett ezt szegni ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Természetesen forrásból mindent a /usr/local-ba telepítek, a tudnivaló csak annyi, hogy ne tegyem be a /etc/ld.so.conf-ba, hanem a gcc -Wl,-rpath,/usr/local/lib64 című opcióját használjam linkeléskor (vagy a libtool nevű eszközt).

Még az jut eszembe, hogy ezt akár a /usr/local/lib64/pkgconfig/*.pc-be is beletehetném, nem kér enni.

https://fedoraproject.org/wiki/SELinux  amit (még) nem ismersz - ha Fedora/RHEL/CemtOS vonalon akarsz érdemben dolgozni, akkor itt az ideje megbarátkozni vele. Itt annyi volt a gondod, hogy authorized_keys nem megfelelően volt cimkézve, és a selinux enforced módban van. (Dev/tst környezetre én a permissive módot szoktam javasolni, és persze a audit2allow és az audit2why rendszeres használatát)

Köszönöm, bizonyára igen jó segítőprogram ez a SeLinux is.
Bár egyelőre nem látom a problémát, amit megold, csak azt, amit létrehoz: Az egyik user ~/.ssh/authorized_keys -je jó karmával született, a másik useré meg rossz karmával... Nyilván amikor (root-ként) lenyomtam az F7-et, hogy megcsináljam a home-könyvtárát, már akkor rossz volt a ki bennem, és ez átöröklődött a létrehozott könyvtárra.

Na ez pont olyan dolog, amit Windows-ban természetesnek veszek, Unixban viszont nagyon nem szeretnék.

" igen jó segítőprogram ez a SeLinux is " Igen, a selinux keretrendszer jó dolog. Tessék tanulni, olvasgatni, hogy mire jó, miért jó, milyen problémákat, veszélyes helyzeteket old meg/véd ki.

" root-ként) lenyomtam az F7-et, hogy megcsináljam a home-könyvtárát " - Tessék Linux kezdőbe visszamenni, már bocs. Igen, AIX eseténben lehet így csinálni (bár a "F7" ott sem standard, sőt...), de Linuxokon az useradd a helyes megoldás. Igen, persze, lehet a passwd/group/shadow/gshadow fájlokat is kézzel szerkeszteni, de csak akkor, ha tudod mit csinálsz.

Meta: igazából abban bízom, hogy ami a nyugdíjig hátravan, azt valahogy kihúzom generikus unixos eszközök és módszerek használatával, lehetőség szerint minimalizálva a linux-only, AIX-only, RedHat-only védjegyű segítőprogramokat. (Igazából még az uefi-t és az Intel/ME-t sem tudtam megszeretni, ebből is sejthető, hogy milyen öreg lehetek.)

2-5 évente újratanulás kell, ezt meg lehet próbálni ellébecolni, de akkor nem kell csodálkozni, hogy prod.-ban szembejön olyasmi, ami a többségnek természetes.
Lehet "generikus" eszközökben, meg POSSIX-only dolgokban gondolkodni, meg abban a körben mozogva túlélést remélni, de hosszabb távon (és ez lehet akár 2-3 év is) nagyon nem kifizetődő... Ilyen ez a popszakma: csak a változás állandó.
SELinux sok éve van (kb. 20, de RHEL-ben is minimum 15), úgyhogy ennek nem lenne szabad újdonságként hatni - még akkor sem, ha a CentOS7-tel (2014-ben jött ki, szóval az is hat év...) jött veled szembe.

Szóval az a rossz, hogy unconfined_u:object_r:home_root_t:s0 és az a jó, hogy unconfined_u:object_r:user_home_t:s0

Mondjuk ezt nyilván magamtól is ki kellett volna találnom... Vagy lehet, hogy utánanézek az icacls.exe használatának, az is igen jó dolog.

Persze, hogy rá kellett volna jönni, egy getenforce parancsra kapott Enforced válasz után 9x%, hogy a selinux labellel van gond, de egy setenforce 0 után az  audit2allow < /var/log/audit/audit.log is szépen megszonta volna, hogy mi a gyíkja. Bocs, de ez most erősen pebkac volt - ahogy a yum függőségeinek kézi tákolása okozta probléma is.

Ne az icacls.exe-nek, hanem a SELinux-nak nézz utána, meg a restorecon(8) és környékének - hasznodra fog válni, nem is kicsit. Egyébiránt lehet, hogy a yum is ilyesmi okból törik...

A yum- gondjáról volt szó fentebb, a mostanit a restorecon -v -R /home/ezaneve megoldotta.

Nyilván kellően sok munkával okleveles RedHat-felhasználóvá képezhetném ki magam, de közben az is benne van a pakliban, hogy holnap átvezényelnek Tandem mainframe-re, mivel azon is van egy (nagyon távolról nézve) Posix-ra hasonlító alrendszer. Szóval a RedHat-specifikum helyett maradnék a generáliáknál, amennyire lehet.

Szerk: azt viszont enmagam gugléztam le, hogy hogyan kell a magyar lokalizációt beállítani, rendkívül meg van könnyítve az is, különösen a Debianhoz képest:

sed -i.bak 's/override_install_langs=.*$/override_install_langs=en_US,hu_HU/' /etc/yum.conf && \
    yum -y -q reinstall glibc-common

De sőt, ez segített rájönni, hogy a szakértő admin által szakértően adminolt jump-serveren is ugyanez lehet a gond, írtam is körlevelet, kb ilyesmi szöveggel:

Egyes Linux-os szervereken nem működik az ssh-kulccsal történő bejelentkezés. Ennek egyik oka az lehet, hogy nem jól áramlott a chi a rendszergazdában amikor a home-könyvtárunkat létrehozta. (Vagy valami ennél is misztikusabb magyarázat, amiben egy SeLinux  nevű csodaszoftver szerepel).

Szerencsére van megoldás, pont az, amit magunktól is gondolnánk: lépjünk be (jelszóval persze), és futtassuk ezt a parancsot:

restorecon -R -v ~

Az nem corporate policy, hogy vi /etc/passwd /etc/group /etc/shadow /etc/gshadow ; mkdir /home/jozsika, hanem más rendszerekből hozott, Linux-os környezetben khm. ellenjavalt kezelése az usereknek. De AIX-es adminoknak lehet papolni róla... (Hasonló dolog:  /etc/sudoers.d/akarmi fájl szerkesztése - nem visudo-val, hanem sudo vi /etc/sudoers.d/akarmi. Természesen hibás lett a fájl... A következményeket lehet sejteni... )

Kisarkítva írtam, és lemaradt a rootként kiadott passwd josika paracs :-)

Sajnos a "su" használata adott környezetben nem volt egyszerűen járható - tudod van, ahol a rootjelszó nem a fejekben, hanem pár kerülettel arrébb egy páncélszekrényben lévő borítékban található, és annak az előszedése kellően bőséges magyarázatot és miegyebet igényel. (Nem is ez lett a megoldás, hogy mi, azt nem részletezem, volt benne erősen bőséges mázlifaktor is)

" még nem jelenti azt, hogy unixék kézzel gyekecselik a passwd file-t. " - Viszont az, hogy a $HOME /.ssh/ könyvtár vagy benne a kulcsfájl cimkéi nem voltak rendben, az azt mutatja, hogy azt valahonnan máshonnan mozgatták oda. (Másoláskor a cél útvonalnak megfelelő cimkét kap, mozgatáskor meg "viszi" a fájl a cimkéit, hacsak nem "-Z" kapcsolóval történik a fájl vagy könyvtár mozgatása.

Egyébként ha az mkdir /home/jozsika módon hozzák létre a home-könyvtárat, akkor is pontosan ez történik:  unconfined_u:object_r:home_root_t:s0 cimkét kap a /home/jozsika könyvtár, ami után kell a restorecon:

# restorecon -v /home/jozsika/
restorecon reset /home/jozsika context unconfined_u:object_r:home_root_t:s0->unconfined_u:object_r:user_home_dir_t:s0

Jó, az F7 elfelejtődött, szánom-bánom. Bár azon is lehetne vitázni hogy mondjuk egy nem internet facing, erősen kontroll alatt tartott OS farmon minek selinux. IMHO sok a dolog vele, haszna meg kb. semmi.

De hát úgyse mi döntjük ezt el, hanem a corporate policy. Az meg vagy jó, vagy nem jó, vagy nincs.

echo crash > /dev/kmem

Aha. Tehát az "useradd" az számodra komplex és bonyolult... Mert ugyebár a selinux cimkék hiánya akkor jön elő, ha parasztütiefhét módon kreálod a home-ot, ha az useradd-ot használod "-m" kapcsolóval, vagy nem lokális userek esetén pam_mkhomedir-t használsz, akkor érdekes módonnincs gond a cimkézéssel.

 

Nem, ez most éppen az LDAP-ra meg a többi csodára vonatkozott. A selinux okozta gondok alapvető oka a selinux (amit egyébként én magam igen jó megoldásnak tartok: nevezetesen, hogy nincs hozzá probléma, amit megoldana, viszont a járulékos bonyolultságával önmaga újabb problémák forrása).

Szerkesztve: 2020. 06. 04., cs - 14:29

Csak a jelenlevők bosszantására: a tomcat-native című komponenst is forrásból fogom telepíteni, dependenciákkal együtt. Direkté élvezni fogom a legújabb (2018 augusztusi) TLS verziót! (Mondjuk furcsa is lenne, hogy az AIX5.3-on menjen a TLS1.3, egy Linuxon meg ne.)

Ha már úgyis docker, akkor bacarints bele egy konténerbe az egészet, és kész. Azzal nem fogod véletlenül se széttoszni az alaprendszert. Komolyan mondom, mert a nyugállomány után aki megörökli a szanszét hákolt egykoron CentOS volt rendszert utánad, az nagyon sokat fog téged emlegetni, és bizony nem a legkedvesebb, legbarátibb, jegerkölcsösebb jelsőkkel tarkított kontextusban. Ja, hab a tortán, hogy a CentOS 7 full support idén augusztusig tart, ergo mire nagyjából összetákolod, addigra eljut amaintenance-updates only állapotba, ami neme gy jövőbe mutató alap production-be tervezett környezethez.

Ja, engem nem bosszant, ha sorozatosan tökönbököd magadat, csak ne nekem kelljen majd a qpit eltakarítani/üzemeltetni utánad :-P

Az "akadályozó játékos" számomra mást jelent - például olyat, aki a múltból nem tud elszakadni, és nem tudja/akarja aktualizálni a tudását, sőt elvárja, hogy a világ igazodjon hozzá.
Egy docker konténer miben akadályoz meg? Logot tudsz nézni. Hálózati forgalmat dettó. Strace? Ha kell, az is van... Igen, a konténer összerakása, a "recept" elkészítése munkás feladat - viszont rögtön megtérül azzal, hogy bármikor újraépíthető az egész kóceráj pont úgy, ahogy az aktuális kinéz.

Nekem például az éles rendszerben az alkalmazás+fluentd+dockerd+kernel kombináció olyan szépen dőlt össze, hogy az egész virtuális masina újraindult. És nem esetenként, hanem rendszeresen. Igaz, nem ez a CentOS volt, hanem egy ennél is régebbi (de szintén valamilyen RedHat).

A megoldás az lett, hogy pont ugyanazt az OS verziót húzták fel az élesre, mint a QA-ra (de hogy eleve miért volt különböző, azt máig sem magyarázták el nekem).

Ezen a ponton mondtam azt, hogy saját masinát óhajtanék, még ha csak egyszerű programozó volnék is nem pedig ilyen szakértő.

Nem (úgy) akadályoz, csak sokszor fölösleges, overbloated. Én nem érzem jó iránynak azt, hogy minden vacakra húzzunk fel egy VM-et. Ez tovább ment, minden vacakra húzzunk fel egy containert a minden vacakra felhúzott VM-en belül.

Egy jó site még natív gépeken is bármikor újraépíthető. Ahhoz nem kell docker (se). Ez ne legyen már indok :)

echo crash > /dev/kmem

tl;dr: Mi lett az AIX-szel?

trey @ gépház

Köszöni, megvan, de most, hogy a docker lett az ügyeletes mindenreválaszcsodaszer (TM), egy kicsit kevesebb figyelmet kap. Szerencsére a Java meg a C elég jól tologatható AIX és Linux között, esetleg endian-gondok adódhatnak, de az mással is megesik...