Új hozzászólás Aktív témák
-
LB/HA: minimum 3 lab, 3 kulonbozo foldrajzi helyen - ha egyet frissitesz, egy meg megdoglik, meg mindig legyen hol futnia az alkalmazasodnak.
Backup: legalabb 3 peldany, 3 kulonbozo foldrajzi helyen.
Backup ellenorzes: igenis minden backup utan legyen megnezve a logban, hogy rendesen lefutott-e.
Monitoring: legyen beallitva, mit monitorozol es csak az.
Monitoring dokumentacio: mi es miert kerult hozzaadasra, mi es miert kerult ki belole.
Igen, ez van megírva a nagykönyvben, az már más kérdés, hogy ez hány cégnél van kiépítve...
De egyébként ezek mellett sem árt az, ha stabil az OS-ed, ott kezdődik az egész
Jelenlegi munkahelyemen egyébként éjfélkor van backup, de nem szívesen állnék vissza arról, mert lehetnek olyan adatok, amik elvesznek. Egy operációs rendszer szintű snapshotnál viszont nagyon gyors a visszaállás.
Egy VM snapshotra sem szívesen állok vissza, legfeljebb ha biztosan tudom, hogy azóta nem keletkezett új adat, vagy ki vannak szervezve az adatok hálózatra.
Minden viccen kívűl, szerintem a magyar cégek 90%-nál ahhoz, amit leírtál, nincs kiépítve az infrastruktúra. Főleg a KKV-kre gondolok, azok közül is a kisebbeknél nagyon gyakran látom azt, hogy be van vágva a lépcső alá a "szerver", valami 10 éve nem támogatott Windows-szal, a backup az annyi, hogy a FreeFileSync néha lefut és lementi egy külső HDD-re az adatokat....
Fú, láttam pár ilyet, és mai napig PTSD-m van tőlük.olyan erzesem van, hogy Magad sem tudod, hogy egy ilyen immutable rendszer hova lenne jo a Linux vilagaban, de nem okollak erte, mert szerintem azok sem tudjak, akiknek a fejeben megfogant az otlet.
Nem, én abban kételkedek, hogy asztali gépen van-e helye, abban nem vagyok biztos. Szerveren működHET, és tök jó lenne, ha működne, de még nekem is vannak kérdéseim. és kétségeim. Hogy pl. hol akadhat el a dolog, mert elég egy apróság, és onnantól fogva nem működik a dolog. Pl. egy Falcon endpoint menne-e, és ha igen, nem lenne-e problémás?
Én most erre úgy tekintek, mint egy kísérleti technológiára, és amíg nincsenek esettanulmányok, addig így is marad.mindekozben olyan dolgokrol disputazunk, aminek nincs keresnivaloja szerveren, pl.: GNOME, network-manager es hasonszoru dolgok.
Mert mag az Aeon (és a Fedora Silverblue) asztali rendszernek készült. De az Aeon pedig a MicroOS-ből ered, az meg szerverre.
-
Az uzemeltetesi biztonsagot nem ezzel fogod megoldani, hanem az LB/HA rendes letrehozasaval, rendes rendszeres backuppal, a backup setek rendes, folyamatos ellenorzesevel, a monitoring rendes beallitasaval es figyelesevel, valamint rendes dokumentaciojaval. UPS, ami rendesen le van tesztelve legalabb havonta.
LB/HA: minimum 3 lab, 3 kulonbozo foldrajzi helyen - ha egyet frissitesz, egy meg megdoglik, meg mindig legyen hol futnia az alkalmazasodnak.
Backup: legalabb 3 peldany, 3 kulonbozo foldrajzi helyen.
Backup ellenorzes: igenis minden backup utan legyen megnezve a logban, hogy rendesen lefutott-e.
Monitoring: legyen beallitva, mit monitorozol es csak az.
Monitoring dokumentacio: mi es miert kerult hozzaadasra, mi es miert kerult ki belole.Ez az alap, de ekkor meg csak availability-d van a CIA triangle-bol, a tobbinek ezutan kell nekiallni.
ui.: olyan erzesem van, hogy Magad sem tudod, hogy egy ilyen immutable rendszer hova lenne jo a Linux vilagaban, de nem okollak erte, mert szerintem azok sem tudjak, akiknek a fejeben megfogant az otlet. Az irasodban, vagy utana vmelyik hozzaszolasban megemlitetted, hogy szerinted ennek szerveren lenne letjogosultsaga, de mindekozben olyan dolgokrol disputazunk, aminek nincs keresnivaloja szerveren, pl.: GNOME, network-manager es hasonszoru dolgok.
https://www.coreinfinity.tech
-
Igen, vannak olyan libek, amiknek a rendszerbe kell kerülniük, de onnantól fogva az a rendszer része, és így immutable lesz.
De egy átlagos gépen azért elég kevés ilyen program van, böngésző, media player, office, stb., egyiknek sem kell a rendszerben lenniük.En az oncelu es a corporate Linux fele vezeto ujdonsagok ellen vagyok, meg azok ellen, amik security-t hirdetnek, majd olyan megoldasokat kinalnak ezen belul, ami gyengiti azt, felrevezeti a felhasznalokat es hamis biztonsagerzetbe ringatja oket.
Csak ugy poenkeppen beirtam G keresobe, hogy immutable Linux, elso talalat ZDNet. Mit ir? Increases safety and security, majd kb. 20 sorral lejjeb flatpak, snap es appimage...
Ne a Blikkből tájékozódj, hanem a hivatalos prezentációkat nézegesd...
De azt nyilván senki nem gondolja, hogy csupán attól biztonságos lesz egy rendszer, mert immutable. Annyit lehet elmondani, hogy nem mókolhat bele a rendszerbinárisokba mindenféle jött-ment. Ennyi a security related vonatkozása.
Meg kell nézni, hogy a hivatalos doksik mit állítanak: https://microos.opensuse.org/
Itt pl. nem is írnak kártevőkről meg vírusokról. Én sem írtam róla semmi többet, csak egy mondatot: "Ennek a megoldás az az előnye, hogy egy hibás vagy káros szoftver nem tudja felülírni a rendszerfájlokat, még sudo jogosultsággal sem."
Mert az immutable rendszer nem a vírusok, kártevől, sebezhetőségek elleni védelem miatt érdekes, ahhoz nem ad sokat. Hanem inkább az üzemeltetési biztonságról szól, arról, hogy ha frissítés közben elmegy az áram, és leáll a géped, akkor is konzisztens állapotban fog újraindulni. Vagy ha véletlenül letörlöd a Network-Managert, és megy vele az egész asztali környezet, és azt se tudod, hogy kapj, akkor csak visszabootolsz az előző snapshotra, és meg van oldva. Vagy ha egy elbaltázott frissítés miatt nem indul a rendszered, akkor is csak visszaállsz az előző snapshotra, és kész. Persze, előfordulhat olyan eset, amikor a boot manager sem indul vagy nem tudja felhúzni a rendszert, de ez azért elég ritka.És ott vannak még olyan dolgok, mint pl. Fedora Silverblue esetén, hogy mindenki minden egyes frissítéssel ugyanazt a lemezképet kapja. A Fedorások összeállítják neked a lemezképet, tesztelik, kiadják, te meg megkapod 1:1-ben ugyanazt, egyetlen commitban.
Frissítesz, rebootolsz, ha mégsem működik, akkor meg visszaállsz az előző snaphostra (commitra).
A programok meg ott csücsülnek a rendszerimage fölött, egy overlay rétegben vagy flatpakban/distrobox konténerben.
Ennél üzembiztosabb működést én elképzelni sem tudok.Biztonsági szempontból a konténerezés, a flatpak meg a distrobox más téma, szerintem azt már kibeszéltük párszor.
-
Valoban, a felhasznalonak nincs keresnivaloja a rendszeren, de altalaban veve nem is csinal ott semmit. Arrol viszont nem a felhasznalo tehet, hogy ha telepit egy openssh-server-t, akkor a megfelelo lib-eknek oda kell kerulniuk, ahova, vagy eppen a binarisoknak. A konfiguracio elvegzese utan a usernek tenyleg semmi dolga nincs a sajat szemetdobjan kivul.
Az egy tevedes, hogy minden ellen vagyok, ami uj, sot, talaltam olyat is mondani egy magas szintu meetingen, aminek hallatan mindenki levegoert kapkodott legalabb 1 percig. (olyan otlet volt, amire addig nem gondolt senki). En az oncelu es a corporate Linux fele vezeto ujdonsagok ellen vagyok, meg azok ellen, amik security-t hirdetnek, majd olyan megoldasokat kinalnak ezen belul, ami gyengiti azt, felrevezeti a felhasznalokat es hamis biztonsagerzetbe ringatja oket.
Csak ugy poenkeppen beirtam G keresobe, hogy immutable Linux, elso talalat ZDNet. Mit ir? Increases safety and security, majd kb. 20 sorral lejjeb flatpak, snap es appimage...
"Azt írod, hogy a virtuális gépet csak kikapcsolod, ha nekiáll rendetlenkedni - de hát a konténerizált szoftverrel is pontosan ugyanezt meg tudod csinálni... és ugyanúgy el tudod szeparálni a konténerizált szoftvert, mint a virtualizáltat."
A virtualis gepen ujabb vedelmi megoldasokat tudok huzni a VM kore alkalmazasretegben, halozati retegben. Ha egy kontenerizalt alkalmazast futtatok (es akkor egyertelmusitsuk: a kontenerizalt alkalmazas alatt en azokat ertem, amelyek dockerben vagy vele egyenerteku kontenarizalt kornyezetben futnak), akkor kifejezetten csak az adott kornyezetre keszitett vedelmi eszkozeim vannak (pl. Palo Alto Prisma), a sokkal szelesebb koru OS oldali vedelmek nem allnak rendelkezesemre. Ha feltesszuk, hogy a kontenerizalt alkalmazas LB/HA konfiguracioban fut, maris sokkal nehezebb fejbecsapni, plane, ha nehany instance egy olyan remote rendszeren fut, amivel elvesztetted a kapcsolatot.
Application image-ek alatt pont ezeket az ujhullamos vackokat ertem, mint a snap, a flatpak, meg az appimage.
Meg egyszer: ha sikerul ugy megcsinalni egy immutable rendszert, hogy nem rugja fel az akar tobb evtizedes konvenciokat es megmarad a valasztas szabadsaga is, hajra, en is szivesen fogok ilyet hasznalni (noha egyebkent nincs ra szuksegem), ha nem lesz mas.
https://www.coreinfinity.tech
-
Rossz oldalról közelíted meg a dolgokat. Miért KELL, hogy az alaprendszer írható legyen, miközben a felhasználónak ott semmi keresnivalója, a programoknak meg bőven elég, ha read only módban érik el?
Amióta léteznek operációs rendszerek, azóta törekednek rá, hogy a rendszerfájlokhoz lehetőleg senki se nyúljon. Az összes modern rendszer (MacOS, iOS, Android, ChromeOS, stb.) immutable, és nagyon is jól teszik, hogy azok.Mondom, én elsősorban nem a security miatt szeretem, de security szempontból is ad valamennyi plusz az immutabilitás, nyilván nem fog megvédeni mindentől, de ha már egy valamitől véd, az is több, mint a semmi.
Nézd, amellett, hogy nagyon tisztelem a tudásod és a munkásságod, néha azt érzem, hogy te csakazértis minden ellen vagy, ami új. És sokszor nem gondolod át, amit írsz.
Azt írod, hogy a Linuxnak kernel szinten van hypervisora, de nem gondolsz bele, hogy a docker (és így a distrobox is) éppen erre épülve működik.
Azt írod, hogy a virtuális gépet csak kikapcsolod, ha nekiáll rendetlenkedni - de hát a konténerizált szoftverrel is pontosan ugyanezt meg tudod csinálni... és ugyanúgy el tudod szeparálni a konténerizált szoftvert, mint a virtualizáltat.Nem tudom pontosan, mit te értesz application image alatt. Én konkrétan docker imagekről beszélek, azokból meg elég sokat használnak szerveren.
-
No, akkor kerdezem meg egyszer: minek felrugni az eddigi konvenciokat, ha nem a security-ert csinalod? Kontenerezni pont ugyanugy lehet normalis Linux rendszereken, mint a nemnormalis immutable disztribuciokon, tehat a nehezebb hasznalhatosagon kivul nem kapsz semmit. Ebbol kifolyolag egyertelmu, hogy a security miatt lenne erdekes az immutable rendszer, de azt meg ugy probalja megvalositani, ami nem tekintheto biztonsagosnak.
"Kb. a világ rendszergazdáinak nagy többsége"
Kb. a vilag egyik rendszergazdaja sem telepit semmilyen alkalmazast application image-bol - amint azzal nyilvan tisztaban is vagy, csak megint kellett lovagolni a szavakon.
https://www.coreinfinity.tech
-
Nem a security miatt érdekes a konténerezősdi, nem azért használjuk, legalábbis én nem. Az csak egy plusz, de pl. egy sima distrobox konténernél semmilyen extra biztonságot nem kapsz (de ezt le is írtam).
Hanem mert pl. könnyebb kezelni az eltérő verziókat.
Én pont két napja jártam úgy, hogy a Tumbleweedben lévő Inkscape-en valamit elkeféltek, az ablakát nem lehet maximalizálni. Feldobtam Ubuntus distroboxba az Inkscape-et, az meg tökéletesen működik.Vagy: én itthon a Radicale-t használom CardDAV szervernek. Docker konténerből fut, ha frissíteni kell, csak lehúzom az új image-et, a régi leállítom, elindítom az újat és kész. Semmilyen szinten nem birizgál bele a rendszerbe semmit.
Ugyanúgy a Giteát is konténerből futtatom, meg hamarosan az egész Apache-PHP kombót is abból fogom.
Céges szerveren is egyre több mindent futtatunk konténerből.Mindezeken felul ki az a komoly, felelossegteljes rendszergazda, aki a szerverere barmit telepit image-bol?
Kb. a világ rendszergazdáinak nagy többsége
-
"Annyi előnye van, hogy az ember nem tölt le minden szirt-szart csak azért, mert le lehet. Amit letölt, azt is konténerbe vagy flatpakba tölti le. Nem olyan rossz dolog ez, csak néha elég macerás."
Mint mar irtam, nem kezdek bele megint, miert false az image-ek altal kinalt "security". Nem mellesleg leteznek hypervisorok, a Linuxnak kernel szinten van ilyenje, tehat egy virtualis gepet letrehozni es ott baromkodni akarmivel csak percek kerdese es ott akkor tenyleg van kikapcsologombod, ha vmi nekiall rendetlenkedni, plusz meg egyeb vedelmi retegeket tudsz felhuzni, amirol sem a kontener, sem a flatpak meg csak nem is hallott. Mindezeken felul ki az a komoly, felelossegteljes rendszergazda, aki a szerverere barmit telepit image-bol? Csak mert ha van ilyen, akkor vagy surgosen tanuljon alapveto security-t, vagy inkabb keressen mas foglalkozast, mielott valakinek baja esik emiatt.
"Állítólag a Gnome-mal van a legkevesebb probléma. Könnyű fordítani, patchelni, stb."
Hja, user szempontbol meg a lexarabb. El kellene akkor vegul is donteni, hogy a usernek szeretnenk kedvezni, vagy a disztribucio keszitoinek, valahogy disszonansnak erzem az elozo ponttal.
"Nyilván nem teljesen független, de olyan értelemben igen, hogy az alkalmazás saját csomagjai nem keverednek a rendszer csomagjaival."
Ezt kifejthetned kicsit bovebben is, mert eleg sokaig kulon voltak valasztva (/bin, /sbin), aztan valaki osszerakta oket, most meg megint szurja vkinek a szemet, vagy csak indokolni akarja, miert fogott bele egy ekkora okorsegbe.
https://www.coreinfinity.tech
-
A /usr-ben nincs keresnivaloja konfiguracios allomanynak, annak a /etc-ben van.
/usr csak a config fájlok sablonjai vannak, amiket a csomag hoz magával, és az másolódik át az /etc-be, vagy te csinálod meg kézzel. Ebben igazából nincs különbség a hagyományos rendszerekhez képest.
A masik, hogy korlatozza a usert a dolgaban. A *nix rendszerek filozofiaja pont az, hogy a user tudja, mit csinal es nem akarja korlatok koze szoritani, vagy okosabb lenni nala.
Annyi előnye van, hogy az ember nem tölt le minden szirt-szart csak azért, mert le lehet. Amit letölt, azt is konténerbe vagy flatpakba tölti le. Nem olyan rossz dolog ez, csak néha elég macerás.
Az meg, hogy valaki onkenyesen a GNOME-ot valasztotta, mint tamogatando asztali kornyezetet, a hulyeseg netovabbja.
Állítólag a Gnome-mal van a legkevesebb probléma. Könnyű fordítani, patchelni, stb.
Maga az Aeon prezentaciojanak elso sora is rossz: hogy a fenebe lehetne fuggetlen egy alkalmazas az alaprendszertol?
Nyilván nem teljesen független, de olyan értelemben igen, hogy az alkalmazás saját csomagjai nem keverednek a rendszer csomagjaival. Ha flatpakot használsz akkor azért, ha Distrobox konténert, akkor meg azért.
-
Koszi a reszletes leirast, a bemutatast, jar erte a respekt.
Viszont ez az otlet az immutable disztribuciokkal nagyon sok ponton szembe megy a Linux filozofiaval. A /usr-ben nincs keresnivaloja konfiguracios allomanynak, annak a /etc-ben van. Nem veletlenul talaltak ki ezt a felosztast. A masik, hogy korlatozza a usert a dolgaban. A *nix rendszerek filozofiaja pont az, hogy a user tudja, mit csinal es nem akarja korlatok koze szoritani, vagy okosabb lenni nala. Snap es flatpak - nem mondom ujra el, akit erdekel, vegignyalazhatja a Linux kezdoknek topicot. Az meg, hogy valaki onkenyesen a GNOME-ot valasztotta, mint tamogatando asztali kornyezetet, a hulyeseg netovabbja.
Maga az Aeon prezentaciojanak elso sora is rossz: hogy a fenebe lehetne fuggetlen egy alkalmazas az alaprendszertol? Vagy Aeont hasznalva nem is kell OS? Nyilvanvaloan okorseg.Ez olyan systemd-szintu marhasagnak tunik egyelore, semmint hasznalhato koncepcionak, pontosan az a fajta automatizalas, aminek semmi keresnivaloja Linuxon. Remelem, nem terjed el ugy, mint a systemd.
https://www.coreinfinity.tech
-
Egyszer régebben láttam ezt a képet, szerintem ez szemlélteti a legjobban a viszonyokat. Az első állomás a Factory, ez nem is egy önálló disztró, hanem a legfrissebb csomagok repója (kb. olyan, mint Debiannal az experimental). Ebből készül a Tumbleweed, és abból a komplett SUSE Enterprise (SLE) termékvonal, majd ez visszajut a közösséghez, aki hozzárak még pár csomagot, és így lesz a Leap.
Aztán szintén a TW-ből alakul ki a többi MicroOS, a Slowroll és a többiek.
Igen, kb. ugyanaz a viszony az OpenSuse rendszerek (leszámítva a Leap-et), mint a Fedora és a RHEL között.Közben megtaláltam Bernhard M. Wiedemann egyik Reddit posztját, amiben megerősíti, amit írtam korábban, hogy a SUSE többféle módon támogatja az OpenSuse projektet. Wiedemann szintén SUSE alkalmazott, ő készítette és tartja karban a Slowrollt.
https://www.reddit.com/r/openSUSE/comments/1baelw6/comment/ku3f3hr -
Nem tudom bővebben, nekem a Fedora és a Red Hat viszonya jutott eszembe, ahol az előbbi egyfajta OpenREDHAT és leginkább a Red Hat fejlesztők "játszótere". Ugyanígy a Nobara is egy Red Hat fejlesztő saját szerzeménye. Valahol gondolom az OpenSUSE-nál is ez a helyzet, viszont ezt az újrabrandelési dolgot nem teljesen értem.Az emberiség két legnagyobb találmánya az írás és a mikrohullámú sütő. / ~ / Szakmai jellegű kérdésekkel privát üzenetben NE keressetek! Ezeknek a fórumon a helyük!
-
Én ebbe azért nem mentem bele, mert hivatalosan valóban nem a SUSE rendszere, DE
- Richard Brown, az Aeon fő-fő embere mai napig SUSE alkalmazott ("SUSE Distribution Architect & Aeon Dev")
- az Aeon gyakorlatilag a MicroOS asztali változata, a MicroOS pedig tulajdonképpen egy de-brandelt SUSE Linux Enterprise Micro
- az összes OpenSuse rendszer a SUSE infrastruktúráját használja
- és tudtommal a SUSE anyagilag is, és más módon (pl. konferenciák rendezésével) is segíti az OpenSuse-t, ha nem így van, akkor FIXMEEzt a "nem a mi kutyánk kölke" játékot a SUSE már többször is eljátszotta, de valahogy sosem sikerült, ami nem olyan meglepő, lévén a fizetős SUSE rendszerek és az OpenSuse rendszerek olyan 99,8%-ban megyegyeznek
Ez a mostani OpenSuse átbrendelés is megbukni látszik, hónapok óta nincs róla semmi hír. Annyi látszik, hogy "felmenő" rendszerben már csinálják, az új rendszerek (Aeon, Kalpa, stb.) már nem használják az OpenSuse nevet.De egyébként igazad van, át is írom a cikket, hogy egyértelmű legyen.
-
Apró javítás, az OpenSUSE rendszere, nem a SUSE-é. Most éppen nem is felhőtlen a kettő szervezet viszonya, miután a SUSE "megkérte" őket, hogy brandeljék át a disztrót. [link]
[ Szerkesztve ]
Az emberiség két legnagyobb találmánya az írás és a mikrohullámú sütő. / ~ / Szakmai jellegű kérdésekkel privát üzenetben NE keressetek! Ezeknek a fórumon a helyük!
-
#4
tordaitibi
veterán
Kb. a felét értem de így is nagyon jó olvasmány.
Köszi! -
Megvannak az előnyei.
Nekem határozottan tetszik az, hogy stabilitásra mentek rá. Csak gondolj bele amikor szülőknek, IT-ben nem jártas emberkének csinálsz gépet.
Próbáld meg Windows-al - jön egy frissítés, simán törhet minden.
Próbáld sima Linux disztróval - valami olykor úgy is el fog törni frissítés alatt.Én most munkában is látnám értelmét, mert pl. a Windows 10 LTSD 2019 esetén megadták a 10 éves támogatást, de a 2021 esetén már csak 5 évet adnak. Linuxnál is küzdelmes, amikor valamelyik disztro úgy dönt, hogy Ő most fordul egy nagyot, Te meg kamillázhatsz, hogy akkor mire migrálj át...
Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.
-
Jó cikk volt, köszi.
De a koncepció inkább szerverre való, nem hiszem, hogy nagy felfutása lesz desktop vonalon.
-
Köszönöm szépen a bemutatót, nagyon olvasmányos és tartalmas volt, sokat tanultam belőle!
Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.
Nem tudom bővebben, nekem a Fedora és a Red Hat viszonya jutott eszembe, ahol az előbbi egyfajta OpenREDHAT és leginkább a Red Hat fejlesztők "játszótere". Ugyanígy a Nobara is egy Red Hat fejlesztő saját szerzeménye. Valahol gondolom az OpenSUSE-nál is ez a helyzet, viszont ezt az újrabrandelési dolgot nem teljesen értem.
Új hozzászólás Aktív témák
lo Az immutable operációs rendszer Az Aeon Desktop, az OpenSUSE immutable asztali operációs rendszere, amely a szerver...
- Google Pixel 9 128GB - Porcelain (fehér) - 35 hónap garancia
- Zsír ASUS TUF A16 Gamer Tervező Laptop 16" -30% AMD Ryzen 9 7845HX 16/1TB RTX 4060 8GB QHD 2,5 165Hz
- Szép! Lenovo Thinkpad T14 Strapabíró Laptop -60% 14" Bivaly Ryzen 5 PRO 4650U 6Mag 16/256 FHD LTE
- Új dobozos Lenovo IdeaPad Gaming 3 Gamer Laptop -20% 15,6" RYZEN 5 5500H 16/512 NVIDIA 2050 4GB FHD
- Dell 7410 Laptop 14" FHD/i7-10Gen/MS Office/DDR4 16Gb/1Tb M2/HDMI/USB-C/CAM/Wifi 1Év Gari 27% Áfá-s