CentOS Linux 7 (1708) for 64 bit x86

 ( trey | 2017. szeptember 15., péntek - 7:02 )

Megjelent a Red Hat Enterprise Linux 7.4 CentOS-es megfelelője, a CentOS Linux 7 (1708) 64 bites x86 kompatibilis (x86_64) gépek számára. Részletek a bejelentésben.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Hat hét spét nem is olyan rossz!
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Ami nincs benne a relnotes-ban, es igen fajo tud lenni: a Tomcat-et unconfined alol attoltak tomcat_t context-be, amitol lenyegeben minden instance-ed meg fog dogleni, mert ahhoz is explicit allow kell, hogy pl. tudjon SMTP-n forgalmazni.

Nem lett volna baj ezzel, ha valaki esetleg szol is errol, nem csak IRC-n emliti meg valaki, hogy "ja igen, azt en reportoltam, de ugy nez ki, felkesz a policy". Mindezt persze mar akkor, amikor update utan megfinglott az instance...

Ez a különbség kb. egy fizetös, ld. Redhat illetve egy ingyenes, ld. CentOS között.

--
robyboy

Tudtommal azonos a forrás. A megváltoztatott policy ugyanolyan RH-ben is elivleg.

Pontosan.

Az igaz, csak Redhat-éknél korrektül le vannak dokumentálva a változások tudtommal. Meg Fedoráéknál is.

--
robyboy

Szerintem nagy átlagban olvas RH release notes-ot aki RH clone-t használ, már csak azért is mert az előbb jön ki :)

Igen, ez így van. A RedHat maga fizetős, de a doksijaik ugyanúgy ingyenesek a klónok felhasználói részére is.

--
robyboy

nemide

Te itt valamit nagyon benezel, a RHEL relnotes-rol beszeltem, abban nincs benne.

Nem derül ki a kommentedből, hogy RHEL relnotes-ról beszéltél egy CentOS hírben.

Tekintve, hogy egy CentOS bejelentesben nagyjabol semmi relevans info nincs soha, azon kivul, hogy a repokat most hogyan rendeztek, meg milyen ISO-k honnan tolthetok, nem tudom, miert keresnem ott a Tomcat-related kerdeseket. De esetleg te is utananezhetsz az allitasaidnak, ahelyett, hogy csipobol kioktatsz :)

Azt egyebkent a teljesseg kedveert tegyuk hozza, hogy RHEL-lel bizonyos szempontbol tenyleg beljebb lennenk, mert ott nem rolling release van, egy yum update nem pattint at vNext-re, mig CentOS-en igen. Ott lehetne jatszogatni, tesztelgetni verziougras elott. Mar ha lenne erre eroforras persze :-)

De mint mondtam, nekem nem is a rolling release a bajom, sot, verziobuzi vagyok, a dokumentacio hianya volt itt az irritalo.

A dokumentáció folyamatosan változik itt is.
A Release Notes a kiadás óta 11-szer változott. És még fog is változni.

Figyelj, szerintem eleg sokat mond a dologrol, hogy a #centos-en is osszesen 1 ember volt, aki egyaltalan tudta, hogy mirol van szo. Tortenetesen o volt az, aki a ticket-et bekuldte bugzillaba, hogy ne unconfined legyen mar a Tomcat. A megoldasrol mar neki is csak tippjei voltak, illetve az egesz policy-re annyit mondott, hogy "looks incomplete". Mert ha belegondolsz, miert is kell explicite engedelyezni egy webapp-nak, hogy levelet kuldjon? Ez annyira ritka lenne? :D Arrol, hogy cache-bol execute-ol a Tomcat, annyi volt a velemenye, hogy "insane". Hat valoban az, de mit csinaljak vele? Szoval annyi haszna legalabb volt a dolognak, hogy ravilagitott, mennyire idiota dolgokat csinal a Java es/vagy a Tomcat. Na mindegy, ez van, hozott anyaggal dolgozunk.

Ez a RHEL 7.4-ben is így van:
https://bugzilla.redhat.com/show_bug.cgi?id=1485308

És van is rá javítás:
https://access.redhat.com/errata/RHBA-2017:2579

Ez a selinux-policy-3.13.1-166.el7_4.4-tal javítja a policyt.

És ez CentOS alatt is megvan:
http://mirror.centos.org/centos/7.4.1708/updates/x86_64/Packages/selinux-policy-3.13.1-166.el7_4.4.noarch.rpm

Korrekt, köszönjük!

--
robyboy

Akarhogy nezem, ez nem az a problema, amirol en beszeltem. Meg csak nem is hasznalunk tomcat-jsvc-t. Nekunk amik elojottek peldaul:

- Fajlhozzaferes kapasbol nem jo, hiszen eddig default_t-n volt peldaul. Ehelyett most valtozatos egyeb context-ek kellenek attol fuggoen, hogy milyen muveletek tortennek az adott mappaban, de kezdesnek a tomcat_var_lib_t eleg jo.
- Egy raklap portot whitelist-elned kell modulokkal. Nekunk amik elojottek igy fejbol: MSSQL, SMTP (587), whois portok. De pl. postgres es http forgalom megy alapbol. Csak hat ez ugye eleg szar igy dokumentacio nelkul, annyit tudsz csinalni, hogy elinditod, aztan tail -f /var/log/audit/audit.log | grep denied. Ami meg utemezve jon 2 nap mulva, azt vagy eszreveszed, vagy igy jartal.
- Vannak olyan jar-ok, amikben nativ libek is vannak. Peldaul az SQLite JDBC drivere. Ami azert szep, mert futas kozben ezt szepen befossa a temp mappaba, es onnan akar execute-olni. Erre is vehetsz fel whitelist-et, mert alapbol nem fog menni.
- Font cache generalas ledoglik, mert /usr/share/tomcat a CATALINA_HOME, aminek talan usr_t a context-je, es oda a tomcat_t scontext rohadtul nem tud irni.

Hirtelen ezek jutottak eszembe. Maradjunk annyiban, hogy picit elkapkodottnak erzem a dolgot.

Egyebkent a cr repoban volt meg egy olyan finomsag, hogy a tomcat-libs csomag broken volt, hianyzott belole a tomcat-suli.jar. Ezt akarhova akarhogyan taknyoltad bele kezzel, nem akarta megenni. Ezt utolag javitottak, de valamiert ez nem csorgott le a cr-enabled instance-re, csak ugy javult meg, ha kezzel letorolted a tomcat-libs-et, majd kezzel ujra feltetted. Fincsi...

Miről frissítettél 7.4-re? 7.3-ról?

Igen. Botorsag vagy sem, yum-cron is megy mindenhol, tehat meg azt se lehet mondani, hogy tul reg voltak frissitve, vagy valami.

Azért a tail -f /var/log/audit/audit.log satöbbi helyett vannak értelmesebb megoldások is... Fogod, setenforce 0; systemctl rotate auditd; aztán elindítod a motyót, használod a tesztrendszeren, aztán audit2allow szépen ad neked egy vázat, hogy mit kéne csinálni. A miértre meg az audit2why ad magyarázatot.

Lehet mas eszkozzel is kinyerni ugyanazt az informaciot, de az erdemi probleman ez jelen esetben nem igazan valtoztat.

Mondjuk a fentebb írt problémák azért -- azon túl, hogy tockos a doksi hiányáért -- azért kissé picsogás szagúak. Hogy a security keretrendszer, ami eddig szart a tomcatre, most nem teszi, és elvárásokat támaszt arra nézvést, hogy el kell árulni, mihez turkálhat? Hát, ez neki a dolga. Az olyanok meg, hogy a /tmp kicsomagol valamit, amit futtatna, hátizé, diplomatikusan annyit tudnék mondani, hogy ugye milyen jó, hogy a javas gyerekek fosnak mindenki másra, főleg arra a platformra, amin éppen futnak, mert nem értenek hozzá?

+1

Sane defaults. Millio csomag van a base-ben, ami a megfelelo context alatt fut, igen. Csak ezekhez csinalnak megfelelo default policy-ket is, hogy ne kelljen 20 millio rendszergazdanak egyesevel engedelyezni, es feltalani a kereket ujra. Hogy mondjuk a Tomcat tudjon mar levelet kuldeni, mert a webappoknak van egy ilyen szokasa, hogy igen gyakran levelet kuldenek. Meg a Java tudja mar generalni a Java font cache-t, mivel ezt amugy o csinalta az elmult 20 evben, es egy minor release-ben ne nekem kelljen mar kezzel engedelyeznem ezt neki, 50 masik ilyen baromsag mellett.

Vagy ha mar basznak rendesen megcsinalni, akkor esetleg azt az 1 mondatot talan nem lett volna tul megerolteto beleirni a relnotes-ba, hogy a Tomcat mostantol a tomcat_t context alatt fut. De nem, erre nem futotta. 2 honappal release utan meg mindig nem. Helyette kulon bekezdest szenteltek annak, hogy

Section headers (such as [Tomcat]) in PKI deployment configuration file are no longer case sensitive

El lehet donteni, hogy melyik erint tobb embert. Lehet, hogy te szeretsz a sotetben dofkodni, elvegre majdcsak eltalalod egyszer, en nem annyira. Ha ez picsogas, akkor picsogok. En elmondtam, hogy mi a problemam. Egyik problema, hogy az alapbeallitasok szarok. A masik problema, hogy ez meg csak le sincs dokumentalva emlites szintjen sem. Aztan a harmadik problema, hogy 2 honap alatt sem sikerult a RHEL-nek kivasalnia elegge blocker bugokat sem (pl. amit linkeltem mashol itt a hir alatt, lenyegeben nem mukodik a font detektalas). Es szerintem az nem csak a Java-sokat, hanem az open source kozosseget ugy zusammen minositi, hogy a mai napig nem sikerult egy olyan SQLite drivert irni, ami nem a cache-bol akar execute-olni. Akarhogy szamolom, ez egyik sem engem minosit, meg nem az en inkompetenciam, de persze jogod van a velemenyedhez.

"Vagy ha mar basznak rendesen megcsinalni, akkor esetleg azt az 1 mondatot talan nem lett volna tul megerolteto beleirni a relnotes-ba, hogy a Tomcat mostantol a tomcat_t context alatt fut. De nem, erre nem futotta. 2 honappal release utan meg mindig nem. Helyette kulon bekezdest szenteltek annak, hogy",
"lehet, hogy te szeretsz a sotetben dofkodni, elvegre majdcsak eltalalod egyszer, en nem annyira."

Igen, mint mondtam, a release note hiánya miatt korbáccsal kell végigverni az elkövető tetszőleges kilógó testrészén, abban nincs vita, ezt tovább nem ragoznám.

Viszont a policy milyenségével való kifogásaid azért kétségések.

1) "Tomcat mostantol a tomcat_t context alatt fut,
Valóban lehetett volna egy automata relabel. Kérdés persze, hogy ott tartod-e a dolgaidat az fsen, ahol azt defaultból gondolja? Mert ha nem, akkor azt bizony minden másnál is neked kell labelezni.

2) "hogy mondjuk a Tomcat tudjon mar levelet kuldeni, mert a webappoknak van egy ilyen szokasa, hogy igen gyakran levelet kuldenek"
Na, ez egy big no-no. A selinux célja, hogy korlátozza az általa szabályozott szolgáltatásokat, hogy azok kompromittálódása esetén ne tudjanak a rendszer mindenféle más részéhez hozzászólni. A tomcat alapvetően webszolgáltató, elég ordas hülyeség lenne, ha megengednénk neki alapból, hogy levelet küldjön, abban a világban, ahova a beírod a gugliba, hogy webpage sendmail, akkor tippre az első 150 oldal azzal lesz tele, hogy hogy lehet megcsinálni valahogy shared hostingnál, hogy ne legyél spamrelay a random nálad futó szemét miatt minden másnap. Szóval az egy igen sane defaultja annak a policynak, aki lábon akarja lőni magát, az lehetőleg írja alá előtte a papírt, hogy direkt volt. Ha ezt alapból lehetne, azonnal reportolnám bugnak. Lehet, hogy még valami fórumon is picsognék :D

3) "Meg a Java tudja mar generalni a Java font cache-t, mivel ezt amugy o csinalta az elmult 20 evben,"
Az emlegetett font cache is azért erősen véleményes, az a java font cache-e, nem a tomcaté. Élnék a gyanúperrel, hogy jó az úgy, legyen neki valami kapcsolója, hogy ki basztathassa, de alapból mindenféle javas fosnak nem lenne muszáj, mert szintén támadási felület.

"Aztan a harmadik problema, hogy 2 honap alatt sem sikerult a RHEL-nek kivasalnia elegge blocker bugokat sem"
Mondjuk az a bug láthatólag a redhat szerint még baromira unpsecified. Tán szólni kellene nekik a supporton keresztül, hogy ez márpedig blocker neked. Ha meg nem, akkor el kell fogadni, hogy az RH ügyfeleinek mégsem tűnik blockernek. :) Egyébként sem tudom, hogy pl a tomcat rendesen supportált-e, nem csak mondjuk tech preview véletlen?

"Es szerintem az nem csak a Java-sokat, hanem az open source kozosseget ugy zusammen minositi, hogy a mai napig nem sikerult egy olyan SQLite drivert irni, ami nem a cache-bol akar execute-olni."
Már melyiket? Én olvastam már mindenféle nyelven sqliteból úgy, hogy senki nem akart a /tmpből execelni valami odafosott trágyát, szóval maradjunk csak a javasoknál. De mondjuk ha nem is, ezt azért selinux nyakába varni erős.

"Akarhogy szamolom, ez egyik sem engem minosit, meg nem az en inkompetenciam, de persze jogod van a velemenyedhez."
Hát, azért én úgy látom, hogy technikailag kaptál egy fél pontot, ha az automata relabel valóban nem megy, meg esetleg még egy felet a font cache miatt. Az van, hogy ha bele lett volna írva a release noteba, hogy a tomcet mostantól selinux alatt fut, akkor ezeket mind végig kellett volna nézni, mert a selinux az sajnos ezt igényli, pláne, ha nem zöldmezősen kezded. Szóval igen, a doksi hiányára való teljesen jogos észrevételed után azért a tech része, hogy ezzel dolgozni kell, az bizony picsogás szagú :)

Az audit.log az adat, a kinyert információ meg az audit2allow kimenete - amitt illendően át kell nézned, és igen,dolgozni rajta. Vagy hagyni permissive módban/kikapcsolt selinix-szal az egészet, ahogy néhány foskupac cucc ezt igényli is. (az perzse más kérdés, hogy az ilyen "kapcsoljakiaselinuxot" kezdetű doksiknak nem szabad hinni, helyre lehet rázni azigénytelen motyókhoz tartozó beállításokat, csak ahhoz tényleg kell némi tudás, nem elég a neyt-next-finish r=1, uid=0 emberke.

Nem igazan vilagos, hogy miert nekem, es miert ezt valaszoltad, de oke.

5 nappal kesobb meg mindig megy a szopas:

https://bugzilla.redhat.com/show_bug.cgi?id=1484079

A font detektalassal elqrtak valamit. Bevettek valami stix font csomagot, ami mindent szetcsesz. Letorolhetned, csakhogy dependel ra nemcsak a tomcat, de meg a jdk is :))

Ha ez esetleg nem lenne eleg, a font cache-t se tudja alaphelyzetben legeneralni a nyomorult tomcat, amire mondjuk megoldas lehet egy

semanage fcontext -a -t tomcat_cache_t "/usr/share/tomcat/.java(/.*)?"
restorecon -rv /usr/share/tomcat/.java

Developing story, de ez igy majd' 2 honappal release utan kezd kicsit vicces lenni...

Valaki tudja milyen kernel és libgcc verzió van benne?
1610-ről lehet újratelepítés nélkül frissíteni?

Miert ne lehetne? Rolling release van major-on belul. Konkretan nem is tudsz mast csinalni, csak frissiteni, a 7.3 instant EOL'd innentol.

kernel-3.10.0-693.2.2.el7.x86_64
libgcc-4.8.5-16.el7.x86_64

Én sose nézem, hogy hány.x-nél jár éppen, csak kiadom a yum update-t, azt kész.

Nahh ja, bár azért néha érnek meglepetések :/

Fedora 25, Thinkpad x220

Szerencsére tomcatet nem használok :D

yum-cron a baratod.

Azért annyira nem vagyok bátor. Romoljon el akkor frissítéstől, amikor ott vagyok.

Egy major-on belül milyen gyakran szoktak frissítések kijönni?
Frissítés után lefordult a LEDE is a gépen, ezért most már elégedett vagyok a csomagok frissességét illetően.
Régebben valami C, vagy C++ lib miatt nem fordul le.

Évente 1-2.

Ezért volt jó eddig Scientific Linux, mert ők sokáig támogatták a minor verziókat is, nem kényszerítettek az upgrade-re. Viszont úgy rémlik hogy karbantartói munka spórolása miatt ők is át fognak állni vagy CentOS-re, vagy a gyors minor ugrásokra. Habár ezt nem látom megerősíteni a release notes-ban, de konkrétan emlékszem. Nem találok forrást jelenleg.

BTW:

https://www.linux.com/learn/scientific-linux-great-distro-wrong-name

-

Fekete pont is jár: az egyik desktopon frissités után "out of range" hibával sötét a monitor :-(

Nekem ezt Intel 520+AMD Topaz XT párossal csinálta (Notebook, beépített+2 külső kijelző) a megoldás 4.x-es elrepo-s kernel lett (most 4.12.5-1.el7) - igaz, még 7.3-on áll a gép, mert nem volt időm frissíteni.

Volt rajta egy régebben fordított 4.8-as kernel-em, azzal tényleg rendesen működik. Kösz! (Egyébként Sandy Bridge.)

A frissítéssel majd vigyázz, a 4.x-ből sem mind ment nekem, talán a 4.10.13 még jó volt, utána viszont csak a mostani lett ismét jó. Egyébként pont a két külső monitor miatt váltottam elrepo-s kernelre, mert a CentOS gyárija nem tudta kezelni a két külső monitort...

Azért jár egy piros pont, hogy a 64-bit CPU / 32-bit UEFI install most már működik.

btw, aki esetleg hpvsa "modullal" dolgozik, az várjon egy kicsit a HP kmod-* driver updateekre a reboottal. Amennyiben nem vár, úgy találkozik egy kernelpaniccal:)
Mondjuk remek ez az "Enterprise-style" amikor is 3.10.0 a kernel de nem a -539 hanem a -629 és már panicot dob a modul ... Érdekes. Pedig elvileg semmi ABI/API változás nem kellett volna hogy legyen, ami miatt ezt produkálná ... Na mind1. Így sikerült.

ps.: igen meg lehet kövezni, nem dolgozunk hpvsa modullal... meg félfakeraidekkel. De nekem sikerült 1 szerveren. ennyi. én kérek érte elnézést :)

Ugyan, én így jártam 6.x verziónál. Jött egy kernel frissítés még csak minor váltás se volt, mondom simán felrakom. Aztán másnap szólnak nem megy a szerver. Meglesem sas driver elhaslt. Sebaj reboot.
Pár óra múlvva ismét. Mondom nahh meghalt a vas. Aztán míg elkezdték beszerezni a másikat, gondoltam csak felbootolok a régebbi kernellel sose lehet tudni. Azóta is azzal fut vígan.

Fedora 25, Thinkpad x220

akkor megnyugodtam hogy nem csak én szívtam meg ezt egyedül :)) Mert amúgy 7.0-1-2-3 verzióváltásnál semmi ilyen gond nem volt. 7.4 -nél valami történt a kernellel. Mert amúgy az előző verziók teljesen jól elvoltak az adott hpvsa driverrel... :/

Nekem Dell Latitude E5470 notinál a két monitoros módhoz ml kernelt kellett felpakolni - az a 4.10.13 és a 4.12.5 között sikeresen nem működött...
Alapvetés, hogy a működő kernelt meghagyja az ember, és ha gáz van, akkor első körben azzal indítja a gépet.

Erdekes ha az ilyen topic-ok alapjan neznem a linuxot meg azt gondolnam ,hogy valami takolmany bughalmaz...

mod: hjam tudom hardvert venni IS tudni kell :D

Na, a jövő heti móka és kacagás is adott. Egy "kissé" sz@rul particionált mysql tábla (blob, 128GiB az utolsó, "minden egyéb" partíció - a többi összesen van ~60GiB) gatyába rázása mellé...