Red Hat Enterprise Linux 7 RC

AlmaLinux, CentOS, Fedora, Red Hat, Rocky Linux

A Red Hat részéről Dan Courcy bejelentette, hogy elérhető tesztelésre vállalati Linux disztribúciójuk, a Red Hat Enterprise Linux 7-es verziójának RC-je. Három változat érhető el: Server, Client és Workstation. ISO-k:

[ client (SHA256) | server (SHA256) | workstation (SHA256) ]

( uid_4656 v | 2014. 04. 23., sze – 15:06 )

Próbálgattam az utóbbi napokban-hetekben a bétát és az RC-t is. Nos, van mit tanulni, mintha nem is egy RedHat linux előtt ülnék :-)

Az "újdonságok" (ezek linuxos területen nem újdonságok, de a RHEL-ben azok) köre igen széles:

- új anaconda installer, amit, khm... szokni kell (még jó, hogy nem telepítek grafikus felületről, hihetetlenül randa lett)
- /bin és /sbin mozgatása a /usr/bin és a /usr/sbin alá
- systemd, érintve pl. a logolást (systemd journal + rsyslog)
- default XFS fájlrendszer
- firewalld
- hálózati alrendszer jó nagy átalakítása (consistent network device naming, áttekinthetetlen katyvasz a régi network scriptekből és a NetworkManagerből, userspace teaming device, net-tools csomag nem része az alaptelepítésnek így nincs ifconfig stb.)
- cgroups és kapcsolódó rendszerek alapos beágyazása a rendszerbe
- egy rakás apróság (apache 2.2 --> 2.4 váltás, chrony, haproxy, keepalived...)

Az operátori szinten dolgozó linuxosoknak kb. mindent újra kell tanulniuk a RHEL-en eddig megszokottakhoz képest a változások miatt.

Közel sem teljeskörű ám az összefoglaló... Olvasnivalónak jó lehet:

- a mostani RedHat summit anyagai: http://www.redhat.com/summit/2014/presentations/
- a RHEL7 béta doksikai: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_L…

A containerek területén van két kiemelendő dolog, ha érdekel:

- Atomic Host: http://www.projectatomic.io/ (mini linux, RHEL alapokon, kimondottan Docker futtatására, felteszem lesz támogatott termék is belőle)
- Docker: https://www.docker.io/ (úgy látszik, hogy a RedHat őket szereti)

A biztonság tekintetében pedig a mindenki által úgy szeretett SElinux, annak is az MLS képességei segítenek containerek izolációjában. Amennyire néztem eddig kb. ugyanazt csinálják itt is, mint a virtualizációnál: külön MLS label-t kapnak a containerek úgy, hogy egymást és a hostot ne piszkálhassák.

Azért jegyezzük meg, hogy a systemd is hoz újdonságokat a konténereskedéshez (ott van pl. a systemd-nspawn, ami gyakorlatilag egy container, elvileg már az LXC-be is beépítették a systemd socket aktiválását [http://libvirt.org/drvlxc.html#activation])

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Passz :)

pl. lehetnek use case-k, ahol a teljes virtualizálás overkill és felveti a kérdést, hogy kinek a felelőssége a virtualizált rendszer üzemeltetése/frissítése etc. A másik ötletem, ahol ez jobb lehet, ha desktop virtualizálsz és pl. VNC-n osztod ki őket, on-demand mindenki megkapja a saját kis szemetesdombját, de nincs az mint a memory balloning nélküli virt. rendszereken, hogy indításkor bukod a fix méretű memóriát (viszont cgroup-al limitálhatod afaik még a systemd-nspawn-t is).

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Pl. VMware-t VMware-ben biztosan lehet, még használtam is:

http://www.vcritical.com/2011/07/vmware-vsphere-can-virtualize-itself/

Nagyjából arról van szó, hogy a virtualizációban virtualizációhoz kell:
- a processzorban hardvertámogatás a VM-ek közötti "váltogatáshoz"
- a hardverhez közelebbi hypervisorban kell támogatás ahhoz, hogy:
- a hardvertámogatást "átadja" a virtuális gépként futtatott hypervisornak is
- a hierarchikusan egymáson elrendezett virtuális gépeket el tudja laposítani, azaz a különböző szinteken futó virtuális gépeket a fizikai processzorral már egy szinten lévőnek láttassa.

Nem egyszerű, de működik a dolog...

Ha határozottan állítok valamit, akkor tuti, hogy hülyeséget beszélek. A memóriám kb. mint egy megrongálódott tészta szűrő. Jobb ha mindig tudatosítom a kedves olvasókban, hogy nem vagyok megbízható forrás. :)

Az meg külön sikerélmény, ha véletlenül jól emlékszem. Ezt muszáj írásban rögzíteni ;)

Egymáshoz képest nem jobb vagy rosszabb megoldás a virtualizáció és a konténerek használata, hanem két különböző megoldás részben ugyanarra a problémakörre.

Amiben a virtualizáció erősebb:
- hardver absztrakció
- virtuális gépek fizikai gépek közötti online mozgatása

Amiben nagyjából egyforma erősek:
- szolgáltatások izolációja

Amiben a konténerek erősebbek:
- erőforrások gazdaságosabb kihasználása fizikai gépen belül
- változatosabb szoftverkörnyezetek hatékonyabb menedzsmentjének lehetősége

Pl. a RedHat azt mondja, hogy:

http://rhsummit.files.wordpress.com/2014/04/rhsummit2014-application-ce…

12. slide:

Containers vs. Virt?
•Generally complementary concepts
•Virtualization: vertical abstraction
• Containerization: horizontal segmentation
• Containers used to replace virtualization where container paradigms more applicable:
• Horizontal application isolation
• Lightweight delegation
•“Application Virtualization”
• Density
• Containers on top of Virt/Cloud common.

Kevesebb eroforraszabalas, konnyebb az atjaras koztuk (akar bind mount pl.), ecceru deploy, bizonyos szempontokbol konnyem management, konnyebb migracio (bar pl. live migration meg nincs).

Persze ezek szubjektiv szempontok, ill. nem is igazak, csak a korulmenyeket v. a peremfelteteleket kell ugy megvalasztani.

t

Ja, ezt értettem ifconfig dialektus alatt. :) Hogy mindenhol van, de azért kicsit más az ifconfigban, kicsit más a freebsdben, kicsit más solarison, gondolom aixen meg hpuxon is, de hálisten ilyeneket elég rég láttam hogy emlékezzek.. Szóval elméletileg jó lenne erre az ifconfig valóban, a gyakorlatban viszont az se ugyanaz...
Sok vizet nem zavar, max annyiban, hogy simán lehet vele a többi util által "láthatatlan" dolgokat csinálni. De ez sajnos az új linux userlandos eszközökre jellemző probléma...

nem ertem ezt a nagy ifconfig szeretetet. csak szokas. a szokasokon idokent jo valtoztatni kulonben berogzult venember lesz hamar :)

+1
ha on-the-fly uj NIC adunk hozza a rendszerhez (CentOS 6.x) az ifconfig nem latja HW, az ip parancs igen.
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/

Mondjuk az lehet az oka, hogy vannak emberek, akik csak Linuxot piszkálnak munkájuk során, egyéb *X rendszert nem. És vannak olyanok, akik egyebet is. Linuxon van ip és ifconfig parancs is, egyéb *X-en meg általában csak ifconfig. Hát mondjuk ezért.
Ezt az on-the-fly NIC hozzáadást elmagyaráznád? Hotplug PCI? Vagy USB-s Wifi?

A RHEL7-ben meg van nm-cli (vagy nmcli), nem emlékszem melyik. Viszonylag használhatatlannak tűnik elsőre, bár pl. egy wifi és 3g hálózatok között mászkáló laptopon lehet jó. Meg végülis wifi és 3g hálózatok között mászkáló szervereken is, csak az utóbbiak ritkák.

Tehát 10 évig nem nyúltak hozzá ("ami működik ne bántsd :-)"), és ezek után 3 évvel ezelőtt eldöntötte az Arch, hogy nyugdíjazza (és a többi terjesztés is mondjuk 5 éve elkezdte kukázni.
Értem és nincs vele bajom.
Én csak jeleztem, hogy pl. személy szerint nekem miért áll jobban kézre a mai napig az ifconfig/route parancspáros, mint az ip addr / ip route. Ha esetleg megnézted az SzSzKK-s admin könyveket, szerintem elég jól összeszedtem, hogy az elavult eszközöket mi módon lehet kiváltani az ip paranccsal. De attól még nekem jobban kézreáll a régi, és mivel nem csak Linuxot nyúzok, ezért nekem az ifconfig nem kopik ki a fejemből.