Külső REPO biztonságosság (Remi's repo)

Linux-haladó

Kedves Kollégák!

A DevOps tolja, hogy a PHP korábbi releasek elévülése miatt az 5.6 helyett/mellett a 7.1/7.2-t tennék fel. Ennek automatizálására (CentOS7) pedig erőszakosan kérik a Remi's repo nevű cucc használatba vételét. Szerintetek ezek a külső repo gyűjtemények mennyire megbízhatóak? Egy google repo-ban, ahonnan a Chrome jön a Linux Mint-emre megbízom, de ez a Remi egy kicsit túl nagy már nekem...

Tudom, hogy az én döntésem, hogy bróker Marcsira bízom a pénzem vagy sem, de pl. egy ilyenkülső REPO esetén elképzelhető, hogy az egyik átlag csomagot (htop) nem a CentOS-ből frissíti hanem innen (ahogy a PHP-nél is csak azt mondod, hogy yum install php) és felkerül egy kínai bloatware :)

Konkrétan a Remi-vel van-e valakinek tapasztalata?

  • 2631 megtekintés

( tigrincs | 2018. 10. 18., cs – 14:42 )

Cegnel tuti nem engednem be. Az ilyeneken nagyot lehet borulni. Ha barmi gebasz van teged vagy az adott resz uzemeltetojet fogjak elovenni, hogy akkor hogyan is volt ez?

( uid_16313 | 2018. 10. 18., cs – 15:43 )

Ezzel a CentOS féle ajánlással át is húzzák kapásból az enterprise felhasználást. Persze arra ott a RedHat.
Nem tudom ők mit ajánlanak, de kíváncsivá tett.

--
robyboy

RedHat-nek vannak erre speci subscription-jei, pl RHSCL (software collections), amiben sokkal frissebb dolgok vannak de rovidebb (nem LTS) support periodussal.

Ennek megvan a CentOS-es megfeleloje is: https://wiki.centos.org/SpecialInterestGroup/SCLo
Itt tekintheto meg a repo: http://ftp.freepark.org/pub/linux/distributions/centos/7/sclo/x86_64/
Itt pedig a keresett PHP 7.1: http://ftp.freepark.org/pub/linux/distributions/centos/7/sclo/x86_64/sclo/sclo-php71/

---
Régóta vágyok én, az androidok mezonkincsére már!

( Raynes v | 2018. 10. 18., cs – 15:49 )

CentOS helyett tegyetek fel egy frissebb verziókkal dolgozó szerverdisztrót, aminek a hivatalos tárolójában is benne van a legújabb PHP és egyéb szükséges friss dolgok. A CentOS, Debian, stb. annak való, aki millió éves verziókat akar használni.

No keyboard detected... Press F1 to run the SETUP

Ezt azért sikerült nagyon Blikkesre venni. Uborkára Canoncaltól vásárolhacc zupportot. Centosra meg mástól. (Szerintem aki zupportot akar, az amúgy se centostot, hanem rehelt fog venni.) Ráadásul a Centos7-et (azaz az utolsó verziót) miért a kettővel ezelőtti és nem a legutolsó lts-sel veted össze? (*) Amúgy igen, tudjuk, hogy rövidebb az ubi supportperiódusa. De szerencsére ahol az ilyesmi fontos, ott úgyis jön 3-4 évente egy új vas, akkor meg már lehet az akkor támogatott verzióra felrakni a szarjukat.

(*) Mintha (FIXME) 6-os sapkáig az lett volna a supportált frissítési mechanizmus, hogy nincsen főverziók között újratelepítés nélkül frissítés. Bubinál pedig egy jó ideje meg van. Szóval kinek a papsajt, kinek a paplan.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

"a Centos7-et (azaz az utolsó verziót) miért a kettővel ezelőtti és nem a legutolsó lts-sel veted össze?" - Mindkettőt 2014-ben hozták ki, azért. Egyébként meg néhány hónapon belül kibuggyanhat egy RHEL8 is a piroskalaposok vegykonyhájából, mert vannak jelek erre nézve :-)

A főverziók közötti frissítés lehetősége/lehetetlensége egy szép mondás, de normális esetben ez legtöbbször nem gond, mert a futó rendszer életciklusa bőven belefér ebbe az időtartamba - ha meg nem, akkor a migráció lesz a legkisebb probléma.

Attól, hogy idén (talán) lesz 8as, még ebben a pillanatban az a helyzet, hogy ha valaki rőtsisak vonalon halad, akkor *extra* repó kell a hetes péhápéhez, míg ha bubival gurigázik, akkor van neki olyanja alaból. Szóval még mindig nem győztél meg arról, hogy a beszólásod nem csak 7végi trollantás volt.

(Különben is, "mit keresel itt egyáltalán?")

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Idén maximum a RHEL 7.6 fog kijönni. A RHEL 8 az leghamarabb jövő év eleje vagy közepe lesz a legrosszabb esetben meg 2020-ban jön ki amikor a 6.* támogatási ideje le jár . Olyan esetleg lehet hogy a 7.6 és a 6.11 még ebben az évben kijön ha meg nem akkor jövő év elején fog kijönni leghamarabb. A RHEL 8-al annyi biztos hogy a python2.x meg egyéb régi dolgokat teljesen ki lesznek dobva. Az újdonságok a 8-as ágban a python 3.x és a php 7.2.* lesz meg az hogy a yumot lecserélik dnfre és alapértelmezett lesz talán a wayland is és a KDE 5.* LTS lesz benne az aktuális lts kernelt is bele értve. A RHEL 6.*ról a RHEL 7.*-era való közvetlen frissíthetőséget a mostani 6.10-es esetében került béta tesztelhető állapotban amit a 6.9-esben lett be vezetve ez a lehetőség.
A RHEL 6.* =>RHEL 7-re való frissíthetőségről egy ilyet talált hivatalos információ gyanánt https://access.redhat.com/solutions/637583 . Jelenleg marad még a külső repózás ha php 7.* kell.

Fedora Rawhide/Centos7, Fedora Ambassador,Translator

Miért ne? Az Archot sem muszáj naponta frissíteni. Olyan gyakran frissíted, amilyen gyakran akarod. A Gentoo-t is akartam említeni, de valami miatt az az érzésem, hogy egy CentOS-re esküsző cégnél nem fogják szeretni, jobban preferálnak valami könnyebben telepíthető alternatívát, mondjuk emiatt lehet az Archért sem lennének oda.

No keyboard detected... Press F1 to run the SETUP

A Gentoo-ból vagy hasnzálod a "saját build, olyan beállításokkal, ahogy szeretnéd" lehetőséget, ekkor lesz egy totál egyedi, unsupported rendszered, amiben ott van a komplett build környezet, toolchain, tok vonó, vagy csinálsz saját bináris repót, amibe dettó a saját beállításokkal készülő csomagok kerülnek (hogy adott beállítások együtt jól és biztonásgosan működő rendszert adnak-e, azt vagy elhiszed magadról, vagy sem), vagy fogsz egy bináris repót, és onnan rakod fel - ekkor szinte semmiben nem különbözöl az n+1. linix disztribtől - legfeljebb annyiban, hogy ehhez sem kapsz olyan supportot, amivel prod környezetben legalább a saját hátsódat tudod védeni.

Engem nem is kell meggyőznöd róla, és simán tennék akár Gentoot is szerverre. Sőt, sokkal inkább, mint CentOS-t vagy Debiant. Persze ez attól is függ, hogy milyen feladatra kéne, meg milyen határidőre, ha csak gyorsan kéne összedobni valami suffniszerveres vagy tesztelős megoldást, arra lehet elég simán egy Ubuntu Server és kész.

Az Archot is csak azért említettem, mert tényleg egy jó rendszer. Sokan instabilnak tartják a bleeding edge, rolling jellege miatt, pedig nem sok minden szokott eltörni frissítésekkor, nem több minden, mint más nagy disztrókon. Ráadásul, ami eltörhet, azok inkább desktop dolgok, GPU driver, grafikus felület, energiagazdálkodás (ideértve ilyen hibernálás,stb.) és hasonlók, amiknek szerveren nincs jelentősége. Igazából semmivel nem bugosabb vagy instabilabb, mint egy Debian vagy CentOS.

Amiről sok jót olvasok mostanában, és egyesek esküsznek rá szerverhez, az a Clear Linux. Még sose használtam, pedig tervezem egy ideje kipróbálni. Azt pont nem tudom, hogy PHP, stb. épp milyen verzióval érhető el alá, meg hogy milyen tárolók vannak hozzá.

No keyboard detected... Press F1 to run the SETUP

Sufniszerverre valóban mehet a gentoo, akár helyben buildelve egyedileg beállított csomagokkal, corporate környezetben viszont igényként szokott felmerülni a jól definiált szoftverhalmaz, ami a gépeken telepítve van, illetve a frissítés rendje is messze van az "ad-hoc, amikor van új, felrakom" módszertől. Meg mint említettem, egy-egy biztonsági, működési probléma esetén nagyon nem mindegy, hogy te vagy a rugdalható sor végén, vagy az OS-t szállító cég és annak a repository-ja (RHEL).
A másik probléma a rolling release/főverziót bármikor váltunk hozzáállással az, hogy ezt nem minden környezet, nem minden alkalmazás tolerálja, hogy finoman fogalmazzak. És ha egy fejlesztőnek azt mondod, hogy a 2-3 éve fejlesztett alkalmazása alatti környezetben (Java, PHP, Perl, akármi) főverziót váltunk, mert az OS-sel az jön, tessen az inkompatibilitásokat kireszelni, akkor finomabb esetben ad egy érezhető nagyságú költséggel járó fejlesztési ajánlatot, durvább esetben meg elküld melegebb éghajlatra.

Épp van egy Perl-ben készült, erősen testreszabott alkalmazás, ami Ubuntu-n (tán 14.valami?) fut, ha a buguntu-t frissíteni akarom, akkor gáz van, mert az újabban lévő Perl már nem jó neki, több helyen törik. Ellenberger CentOS7-re viszont simán átmigrálható, és használható még sokáig (A CentOS 7 EOL-ig biztosan).

( MrSealRD v | 2018. 10. 18., cs – 22:02 )

Sub.

Igaz saját célra fut egy CentOS rendszerem és ott pont a friss PHP miatt van a Remi behúzva...viszont most így már annyira nem tűnik jó ötletnek...

Webtatic ugyanaz, de ott legalább:
- mindig a legfrissebb van a 5.6, 7.0, 7.1 és 7.2-es php-hez is. (Pontosítok: 7.1 és 7.2 kicsit van lemaradva 7.2.10 vs. 7.2.11)
- nem php hanem php56w (php71w) a csomag neve, így a gyári csomagokkal (php-gd) nem fésülődik össze.

De ugyanolyan "külsős" repo.

( lacesz v | 2018. 10. 18., cs – 23:09 )

Akkor ennyi erővel a Windows szervereket nem szabad sehova feltenni. Mert ugye innen onnan kell letöltögetni a programokat.
Az nagyon biztonságos ugye?! A Remi repót én már a kezdetek óta használom. Sosem volt gond vele céges környezetben sem és nagy terhelésű oldalaknál sem... Kell használni openscap-et az segít a biztonságban...

---
Amíg a test renyhe, az elme dolgozik...

( gergelykiss | 2018. 10. 19., p – 06:16 )

Szia!

Ezzel én is futottam köröket nemrégiben, nem egyszerű a helyzet, mivel a legtöbb PHP-s RPM repót egy szem fejlesztő tartja karban, és az ő "jóindulatán" múlik, hogy számíthatsz-e hosszú távon (biztonsági) frissítésekre. Ez enterprise környezetben egyértelműen nem megengedhető, ahogy a forrásból forgatás vagy saját repó fenntartása sem feltétlenül (mert pl. így nem kapod meg a backportolt javításokat).

A mi konklúziónk az lett végül, hogy a fizetős, de korrekt áron elérhető HardenedPHP-t érdemes használni, itt találod az általam nyitott topikot, ha bővebben érdekel a téma:

https://hup.hu/node/161029

Monthly plan mellett kb. 4000 Ft a havidíj egy szerverre, és a folyamatosan frissített PHP mellett egy csomó más extrát is kapsz ezért a pénzért, olyanokat, amik egy shared hosting szerveren igen hasznosak tudnak lenni.

Ha amiatt aggódsz, hogy a már telepített, megbízható forrásból származó csomagok lecserélődnek egy külső repóból, akkor használd a priorities plugint:

# yum install yum-priorities

A használata egyszerű, csak egy "priority=xxx" sort kell betenni a megfelelő repók definíciójához, amivel szabályozható, hogy a yum (dnf) melyik repóban lévő csomagot részesítse előnyben. Ha pl. a base repóknak adsz egy 1-es prioritást, akkor garantált, hogy a gyári csomagok csak innen települhetnek. Én úgy szoktam használni, hogy a base repónak 1-es prioritást adok, az EPEL-nek 2-est, minden más 99-est kap (ezzel persze lehet játszani, ha a külső repók közt is szeretnél prioritási sorrendet felállítani).

( makgab v | 2018. 10. 19., p – 07:05 )

A remi és webtatic repo-kat használom én is (centos). Ha jól tudom a forrásuk is elérhető.
Szerintem jól használhatók.

A CentOS (RH) valóban nem frissít olyan gyorsan. Élesben használok Fedora Servert és nagyon tetszik, minden szinte teljesen friss, nem kell semmi extra repo. Eddig teljesen stabilan fut 2 éve és a disztrib frissítés is nagyon jól megoldott(!).

( Taracque | 2018. 10. 19., p – 09:10 )

Szerintem nehéz megindokolni, hogy tetszőleges “AS IS without warranty” repo (és ide tartozik a CentOS is) mitől biztonságosabb bármelyik másiknál? Az RH vállal bármiféle felelősséget, ha centos repo korrumpálodik?

Nem annyira akartam belefolyni a dolog részleteibe, csak arra próbáltam felhívni a figyelmet, hogy igen is lehet különbség no warranty repok között. Az, hogy azt ki hogy értékeli, az már a saját dolga, ennek is nyilván van az az olvasata, hogy valaki szerint már baj, hogy ennyire közel vannak az RHhez.

( uid_4263 v | 2018. 10. 19., p – 15:02 )

Konténer, konténer, konténer...

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

Úgy oldja meg hogy a konténer fájlrendszere teljesen el van szigetelve az alaprendszertől, tehát akár hokijóska imageket is használhat valaki, de szerencsére vannak hivatalos, megbízható imagek is:

https://hub.docker.com/_/php/

Ez friss, megbízható és még ha nem is lenne az, nem szól bele az alap oprendszer csomagkezelőjébe (se).

szerk.: szórakoztató hogy a fenti diskurzusban egyesek megvédik a hokiJóska repók csomagkezelőbe kapcsolását azzal a felkiáltással hogy használták már és szerintük jó :)

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

Tehát nagyjából-egészéből sehogy. Ugyanis ha a hokijoóska repóban lukas a csomag, a dokkeres konténerben lévő app is lukas lesz és marad addig, amíg ki nem javítják, és a konténert újra nem buildelik az új verziót használva - addig viszont lesz egy sérülékeny alkalmazásunk, ami péhápé esetén jellemzően valami vebes szutyok, ami DB-be turkál, és aminek a lukassága konténer ide, vagy oda, kihat a DB-ben lévő adatok biztonságára is.

Figyu, ezt a kommentet nettó nem értem :)

Azt mondtuk csak hogy a docker image (ami official php -s nem mellesleg) felrakható és futtatható úgy hogy nem taknyol bele a host rendszerbe semmilyen szinten.

Tehát a host rendszer továbbra is csak támogatott, official csomagokkal bír, nekünk meg van egy biztonságis konténerben futó friss php-s runtime-unk, ami hozzá sem fér a host fs-hez vagy processekhez.

Tehát friss a phpnk, a rendszerünk meg érintetlen. De ha tudsz jobbat, szólj.

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

Amit védeni kell, az a host rendszeren felül az az adat, amihez a péhápés alkalamzás hozzáfér. Nomostan ha abban hokijóska péhápé dolgok vannak, amik vagy tartalmazzák az autuális javításokat, vagy sem, akkor az adatok, amiket védeni kell, azok bizony a sérülékeny konténeres appon keresztül kompromittálódhtanak. Ugyanez pepitában a Java-s alkalmazások esete is - fognak egy ficemfacom.0.1.1b-snapshot_190001010000.jar komponenst, aztán a build során állandóan azt használják (mert azzal működik a kódjuk), nem pedig a 8.9.10-release_201809101112.jar-t, ami nemcsak, hogy gyorsabb/nagyobb tudású, de a 0.1.1b verziókban lévő ordenáré nagy lukakat is csak release notes-ból ismeri.
Azt kell megérteni, hogy a "biztonság" az elsődlegesen a kezelt adatok védelmére szolgál, és attól, hogy az OS-t nem tudod szétcsapni, (ami senkit nem érdekel, mert 10-60 perc alatt rittyentek egy másik VM-et, ha kell) attól még úriási kárt tud okozni egy lukas alkalmazáskomponens. Ettől meg a dokker pont nem véd meg, mert üzemeltetőként nem tudod befolyásolni, hogy mi a sz@rt rak/rakat bele a konténergyártó iparos.

A Docker hub-rol elerheto sok csomag az "OFFICIAL REPOSITORY" kategoriaba tartozik, ami azt jelenti, hogy
In many cases, the images in this program are not only supported but also maintained directly by the relevant upstream projects.
For some, they're developed in collaboration with the upstream project (or with the explicit blessing of the upstream project).
Ez, szerintem, megfelel a hivatalos RedHat, CentOS, Ubuntu, stb. repokbol elerheto csomagoknak.

A hokijoóska repoban levo csomagok, valoban mas kategoria.

Sic Transit Gloria Mundi

Szóval kb ugyanúgy :) Vagy elhiszed neki, hogy az egy jó forrás, vagy nem.

> szerk.: szórakoztató hogy a fenti diskurzusban egyesek megvédik a hokiJóska repók csomagkezelőbe kapcsolását azzal a felkiáltással hogy használták már és szerintük jó :)

Igen, kb erre akartam rákérdezni, mert a szállítási tech nagyjából irreleváns. Nyilván van előnye a dockernek a sima repohoz képest, meg van neki hátránya is.