CentOS napi tapasztalatok

Red Hat, Fedora, CentOS

Kellene nekem egy kis segítség!

Olyanok jelentkezését várom akik napi szinten használnak és managelnek CentOS alapú rendszereket.

Az alábbi kérdésekre keresem a választ:

  1. Miért CentOS, mik voltak azok a princípiumok amik miatt ez a disztró és nem más (ha az a válasz, hogy ezt használjuk a kezdet kezdete óta a cégnél, akkor az is érdekel, hogy merült-e fel a váltás, ha igen miért, valamint, hogy volt-e olyan dolog amik kínkeservesen mentek)
  2. A gyári repo kérdésköre: van-e? Ha nincs, mennyire küzdelmes megbízhatót találni?
  3. Az utóbbi idők sec hole -jait (OpenSSL, BASH) milyen gyorsan foltozták? (Reggel 10-kor kijött a patch 10:15-re ;-) meg már volt csomag belölle)
  4. Hardening (AppArmor, GRSec, SELinux) mi van mit használsz, van-e "gyári" alap csomag?
  5. Van-e központi management platform mint amilyen mondjuk a Landscape, ha igen mi a neve?
  6. Végül hogyan áll ehez a RedHat (na ehhez jól jönne valami olvasmány)!
  7. Volt-e, van-e olyan dolog, ami miatt a pokolba kívántad, kívánod a csomag maintainer -ét?
  • 5457 megtekintés

( blackluck v | 2015. 03. 23., h – 07:56 )

1, Kozelebb all egy alapol keszebb enterprise megoldashoz: pl ldap auth-ot, selinux-ot stb. beallitani sokkal egyszerubb es sokkal reszletesebben dokumentaltabb.
2, Sokminden benne van repo-ban, epel (vagy rpmforge-ban) szinte minden benne van, de sokszor konnyebb rpm alapu csomagot talalni valamibol amit repoban nem talalsz.
3, Figyelnek az ilyenekre, hogy gyorsan kovessek.
4, Selinux van alapbol es eleg jol meg is vannak irva hozza context-ek, alapabb repo-kbol felrakott csomagok eseten ritkan kell kezzel utana igazitani.
5, Pl. spacewalk, de nincs vele tapasztalatom, egyelore ilyen szinture nem volt szukseg, inkabb csak ansible-el megoldani par feladatot.
6, RH elismeri oket, mikor kijott a 7-es foverzio akkor jelentettek be es par kozponti embert fel is vettek magukhoz, hogy kozelebb tartsak oket.
7, Centos 6 megjelenes nagyon sokaig elhuzodott RH-el kepest, de 7-es eseten ezt mar gyorsan megoldottak, amugy ha valami egzotikus dolgot vagy csak lenyegesen ujabb verziot szeretnel rendesen telepiteni akkor macerasabb lehet.

( _ventura_ v | 2015. 03. 23., h – 08:16 )

1. Hosszú támogatás, és a támogatási időszak alatt is vannak frisebb csomagok, lásd SCL.
2. A legtobb esetben eleg az epel repo esetleg az rpmforge, valamint mivel RHEL compatibilis, valoszinuleg lesz rpm is abbol ami kellhet.
3. Sose mertem milyen gyorsak :D
4. Alap selinuxot hasznalom.
5. spacewalk jo cucc, installaltam 1et, par szervert beleraktam, de sok idom nem volt meg vele foglalkozni.
6. passz
7. nem

Fedora 21, Thinkpad x220

Arra amire való, managelni sok gépet egyszerre. Van jó pár Centos szerver és ha jön hasonló bug mint bash/openssl stb, akkor pár kattintás és frissül az összes szerver. Meg másra is alkalmas. A redhat leírása alapján csináltam. Pár szervert beletettem, meg felvettem a centos6 repot + epel repot, hogy tudjak is telepíteni ha kell. kb. itt tartok

Fedora 21, Thinkpad x220

a fentebb irottak teljesen megalljak a helyuket 1 kivetelevel. A spacewalk valoban jo de olyan mint a konyhakes a mutoben.
szoval bazi nagy es nehezkes. ne akard debugolni ha vlami nem megy. beleorulsz. 4 nyelven irodott ( Java, Python, Perl es C). Az egesz egy nagy katyvasz.

Akkor inkabb local site repo es vlami management sw pl. Salt-Stack/Chef/Puppet. Sokkal gyorsabb es kezelhetobb.

A spacewalk mindent DB-ben tarol. Pl a monitoring eredmenyeket es magukat a probokat is. Monitoringra 1000x jobb dolgok is vannak mint a spacewalk.

A spacewalk egy kovulet. Azert rakta ossze tobb puzzle elembol anno a RH mert nem volt semmi a piacon ami kepes lett volna 100< szervert kezelni es kellett valami ENTERPRISE megoldas. Most a Red Hat Satellite 6 mar teljesen uj alapokon van (pupet es par custom megoldas).

A regi spacewalk mogul, amit opensourcekent letolthetsz, a RH kivonult pontosabban felhagyott a fejlesztessel. security patchek meg keszulnek es aztan annyi.

Egyebkent minden fent van a neten:
spacewalk.redhat.com
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/

( atomjani | 2015. 03. 23., h – 09:21 )

1. Mert a cPanel ezzel a rendszerrel települt fel.
2. A Centos 6-on fel akartam rakni Vanish-t, de előtte a GCC-t kellene frissíteni a megfelelő verzióban. Sem repot, sem rpm csomagot nem találtam hozzá. Talán forráskódból kéne lefordítanom.
6. A Redhat tiltja, hogy Centos-sal kapcsolatban említsük őket, pl mennyi köze van a Redhat-hoz. Ha pénzzel bírod, akkor Redhat, egyébként ott van a Centos. Elvileg a csomagkezelő és nagyon sokminden ugyanaz mind a kettőben.
7. Szívni lehet vele a rendszerrel. Melyikkel nem? De annyira talán nem, hogy pokolba kívánjuk. Tény, hogy van ami több időt, utánajárást, munkát kíván. Ugyanakkor vannak benne jó scriptek, amik meggyorsítják, leegyszerűsítik a munkát.

Én a helyedben egy NEM éles környezetben tesztelném. Webszervernek vagy amire akarod használni, beüzemeled, kísérletezel. Ha jónak tartod, használod. Ha nem tudsz mindent megoldani, többet szívsz vele, akkor használod inkább a régebbi bevált linuxot. Ez is van amire jobb, van amire kevésbé. De elvileg nagyon sokmindenre jó.

Ezt jól félreértetted. Valahol azt olvastam, hogy a Centos nem használhatja a Redhat elnevezést. Pontosan már nem emlékszem, hogy még milyen megkötések voltak. Ha jól emlékszem, Redhat klónként sem reklámozhatták magukat. Gondolom itt az üzleti érdekek miatt lehetett, hogy a Redhat felhasználók ne váltsanak tömegesen Centosra, illetve az újak a Redhat helyett ne a Centost akarják választani.

Valóban az volt egy darabig az RH álláspontja, hogy ne haszálják a RedHat nevet, illetve a redhat saját copyrightos artwörkjeit. Ezért voltak ilyen poénok, hogy a red hat helyett "upstream vendort" meg "well known / prominent north american linux distributort" meg ilyeneket irogattak (illetve nyilván kiszedték a redhat nevet meg logókat/artwörköket a centosból).

Viszont nem értett félre semmit, a linkelt press release pontosan arról szól, hogy a centos project hivatalosan partnerségre lépett a redhattal. Ennek kapcsán egyrészt több centos fejlszető redhat alkalmazott lett, másrészt a redhat gyakorlatilag a centos gitjén keresztül hozza nyilvánosságra a forrásait, szóval nem csak levegőbe beszélés volt.

Ennek megfelelően mostmár nyugodtan nevén lehet nevezni a gyereket:

http://centos.org/about/ : "The CentOS Linux distribution is a stable, predictable, manageable and reproduceable platform derived from the sources of Red Hat Enterprise Linux (RHEL)"

Természetesen a centosban továbbra is centosnak hívják magukat, de félre csak te értetted azt, hogy meg se próbáltad elolvasni a linkeket, hanem maradtál annál, hogy valamit egyszer régebben olvastál, új tényekkel meg nem zavarod össze magad...

( dotnetlinux | 2015. 03. 23., h – 09:36 )

1. Csomagjai jók, httpd+társai könnyen észreveszik egymást.
2. Gyári repo jó, EPEL-lel kiegészítve minden benne van.

Egyéb:
- CentOS7 egészen más, mint a 6.5, az elején válassz, melyiket "szereted"
- Sok helyen VPS-ben 6.5-öt adnak, de a beépített frissítője 7.0-ra frissíthető KVM környezetben. És jól megy!

Mármint hogy jók a csomagjai, kivéve azokat, amik nem a csomagjai? vagy mivan? Az, hogy a centos6ban régi a gcc, az speciel feature, nem bug, még ha te nem is értetted, hogy ez miért van így.

Egyébként ha vanish helyett a varnishra gondolsz (nem vagyok benne, mert kétszer is így írtad r nélkül, de olyat a neten nem nagyon látok, illetve az egy, amit találtam, az szerintem nem olyasmi, amit te használnál) akkor igazából nem értem, mit nem találtál:

https://www.varnish-cache.org/installation/redhat
http://sharadchhetri.com/2014/12/20/how-to-install-varnish-4-version-on…

Igen, Varnish.
Nem bugként említem. Azóta kijött a Varnish újabb verziója, aminek településekor egy fügösséggel települő csomagnál írta ki, hogy hiányzik a .so fájl. A neten keresve jöttem rá, hogy a gcc egy frisebb verziójával lehet megoldani, ami nincsen Centos 6-ra. Nem tudom, hogy ha megpróbálom forráskódból fordítani, az mennyire jó ötlet. Talán stabilitási okokból nem készítették el hozzá a gcc frissebb verzióját? Felhasználóként erre még nem kaptam választ.

Valószínűleg a Varnish régebbi verziója lesz a megoldás. Csak azt nem tudom, hogy mekkora különbség van a két verzió között abból a szempontból, hogy milyen eredményt hoz.

ez így egy kicsit zavaros :) Főleg azért, mert ami so a frissebb gccvel jön, annak tipikusan inkább a fordításhoz van köze, viszont a varnish oldalán úgy látom értelmes bináris csomagok vannak. Amik persze lehetnek bugosan fordítva :)

Amit még el tudok képzelni, hogy a rh leírás alján, megemlíti, hogy benne van az
EPELben is, csak nem feltétlen ugyanaz a verzió (leginkább régebbi, konkrétan úgy látom 2.valami ). Olyat meg már láttunk, hogy az EPEL más 3rd party repokkal akad kicsit.

Megpróbálhatod vagy az EPELből, vagy az EPEL kikapcsolásával (illetve hát megnézni, lehet hogy csak a dependecia feloldás rossz, és csak explicit meg kell mondani, hogy mi legyen). Abban nagyjából biztos vagyok, hogy nagy baj nem lehet azokkal a csomagokkal, jobb, mint ha te fordítanád.

Hogy eredmény szempontjából milyen a régebbi? Nézd, szépen megnézed a changelogot, aztán kitalálod, hogy a frissebben van-e olyan, ami neked muszáj, vagy jó a régebbi is. Neked kell tudni, mire kell.

( Cajga | 2015. 03. 23., h – 11:17 )

1. A vezeto enterprise Linux disztribucio a Red Hat. CentOS az a RHEL clone-ja -> legjobb valasztas ha ingyen, stabil rendszert szeretnel (ugye ez tobbek kozott azzal jar, hogy nem a legujabb csomagokat kapod meg).
2. A gyari repo az a Red Hat rebuildje (plusz 1-2 csomag). Ki lehet egesziteni az EPEL-el, amiben levo csomagok nagy tobbseget ugyancsak Red Hat-os/Fedoras emberek managelik (de nincs ra support). Az EPEL-ben levo csomagok legtobbje jo minosegu (tehat nem fognak osszeutkozni a szervereden levo tobbi csomaggal) tehat nyugodtan lehet oket hasznalni
3. Gyorsan reagalnak az ilyenekre. Mivel a RH gyorsan reagal (ebbol el ;) ) nekik legtobbszor csak rebuildelni kell az uj csomagot (a sec patch-ek altalaban nem tartalmaznak copyright-os cuccokat amivel ugykodniuk kellene)
4. SELinux (jol supportalt koszonhetoen a RH-nak)
5. Pulp+TheForeman+puppet+sajat monitoring (Spacewalk hatalmas de cserebe nem eleg flexibilis sok esetben)
6. tavaly bejelentettek, hogy osszeallnak. Tehat RH segiti oket :)
7. Sztem kiraly :)

( pirate | 2015. 03. 23., h – 12:42 )

1. Jó a támogatottsága a használt hardveren
2. EPEL-t és egyebeket is használunk, de igyekszünk csökkenteni a legszükségesebbekre
3. Nem tudom ez mennyire szempont a disztró választásban hacsaknem 2-3 ember által karbantartott disztók között válogatunk, a nagyok gyorsan reagálnak
4. SElinux
5. Cfengine
6. Hogyan áll ahhoz a RedHat, hogy CentOS-t használunk? Szerintem nem érdekli őket :)
7. Nem volt még rá példa

A 6. ponthoz: a RedHat boldogan tart tanfolyamokat, valószínüleg nem izgatja őket, hogy RH v. CentOS rendszerhez ül le utána a delikvens.

---
"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."