Ritkán veszem rá magam a disztró blogolásra, amelynek egyik oka, hogy jó ideje nem volt szükségem a váltásra, remekül megvoltam Fedorán, így nem voltak új tapasztalataim, illetve akárhányszor leírja valaki a véleményét bármilyen platformon egy-egy disztróval kapcsolatban, általában a kommentekben elindul egymás savazása, hogy melyik disztró a legjobb és miért. Ezt a felesleges flamet szeretném elkerülni azzal, hogy már most leszögezem: minden, ami a továbbiakban olvasható, csupán személyes vélemény és kizárólag az én személyes preferenciáimat tükrözik. Szerintem nincs olyan, hogy tökéletes disztró, mindenkinek más igényei vannak és mindenki azt használ, ami jól esik neki.

Az igazat megvallva, eddig nem használtam olyan sok disztrót. Annak idején a Debiannal kezdtem szerveren és nagyon szimpatikus volt az, hogy a csomagkezelő (apt-get) automatikusan telepíti a programok függőségeit, nekem ez új dolog volt. Jól elvoltam a rendszerrel szerveren, de valamiért az a hiedelem volt meg bennem, hogy a grafikus felület nem egy igazán moduláris dolog a rendszerben és nem nagyon lehet váltani egyszerűen valami számomra szimpatikusabb felületre. A Debianból pedig egy tipikus XFCE GUI-ra asszociáltam, ami annak idején nem igazán volt szimpatikus. Ezért teljesen kezdőként az Ubuntu felé kezdtem el kacsintgatni desktopon, amit utána több évig használtam dual bootos Windows-zal. Az Ubuntunak voltak érdekességei, például az alap repositorykban sehol nem volt ffmpeg anno, illetve például a midnight commander sem, mindenféle PPA-kat, meg universe repót kellett engedélyezni ahhoz, hogy ezek a szerintem alap programok felmenjenek. Ezt leszámítva egészen stabil volt a rendszer és akkor magaménak éreztem, egészen addig, amíg a sok hozzáadott PPA meg a universe repó összeakadt a gyári repók csomagjaival és egyik pillanatról a másikra azon kaptam magam, hogy az apt teljesen össze van kavarodva, jó pár csomag conflicting egymással és valahogy eljutott odáig a rendszer, hogy le akarta töröltetni a teljes grafikus felületet a frissítések telepítésére. Természetesen ez részben az én hibám, nem kellett volna annyi repót innen-onnan összeszedni, azonban úgy gondolom, hogy pár alapvető csomag (pl mc) elfért volna a hivatalos repókban. Azóta egyébként nagyon sokat fejlődött az Ubuntu, már elérhető nagyjából minden alapból, amit eddig hiányoltam, de amikor ez a jelenség fennállt, messze nem voltam hozzáértő, próbáltam megoldani a dolgokat és csak még jobban elbarmoltam a helyzetet. Szóval egy ideig kényszerből használtam még az Ubuntut frissítések nélkül, aztán egyszer, amikor volt időm, letúrtam az egész rendszert és elkönyveltem egy nem egészen olyan stabil disztrónak, mint amilyennek mondják.

Ha eleged van a reklámoktól hemzsegő Youtube-ból, vagy éppen szeretnél ambilightot faragni a TV-dre, vagy csak szeretnéd a TV-d teljesen a magadénak tudni, és egy LG webOS alapú TV-vel rendelkezel (minimum webOS 3), akkor érdemes most nekiállni a folyamatnak, ugyanis az openLGTV közösség srácai most adtak ki egy újabb root exploitot, amit még nem javított az LG, így pofonegyszerű a rootolás.

A folyamat ezen pár lépésből áll:
1.) Ha van telepítve Developer Mode app, azt le kell törölni (nem kell aggódni, a homebrew channel és a root teljesen leváltja).
2.) A TV böngészőben meg kell nyitni a rootmy.tv weboldalt és meg kell nyomni az 5-ös gombot, vagy el kell húzni a csúszkát.
3.) Követni, ami feljön a képernyőn, mint utasítás.

Ha minden jól megy, akkor a TV rebootol és feltelepül a homebrew channel app, ahol az első lépés az, hogy a beállításain belül letiltjuk a TV frissítések keresését (általában az LG alig ad ki érdemleges változást, amiért megérné frissíteni, azonban a root exploitot azonnal zárják egy frissítésben, mert nekik ez nem business), majd lehet telepíteni az alkalmazásokat!

Már egy jó ideje Linuxot használok napi szinten a gépeimen és tökéletesen kielégíti minden igényemet a setup, azonban az audió támogatás sokak szerint elég puritán pl. a Windowshoz képest. Az alapok itt is szinte minden disztróban megvannak, hogy van egy szoftver (pl. Spotify), ami átadja a hangot a rendszerre telepített audió szervernek (vagy közvetlenül az ALSA-nak), mint például a PulseAudio, vagy az sndio és innen megy az ALSA felé az adatfolyam, ami már a kernel részeként közvetlenül a hardverrel kommunikálva továbbítja a hangot a hangszórókra/fülhallgatókra.

Ez mind szép és jó, de ebből a folyamatból hiányzik az a lehetőség, hogy rendszerszinten finomhangolni tudjuk a hangzást. Elképzelhető, hogy tévedek, de nem találtam kész módot arra, hogy akár egy equalizert rakjak a hangkimenetemre. Természetesen az működhet, ha már a zenelejátszó (pl. foobar2000 wine alól futtatva) képes EQ-zni, vagy belenyúlni az audióba, de nem minden app támogatja ezt, köztük akár a Spotify sem ad túl sok lehetőséget a finomításokra.

Annak idején a nagy nyomtatóválogatás közepette sikerült lecsapni egy Samsung M2070 Series lézernyomtatóra, ami tökéletesen kielégítette az igényeket a mai napig. Ugyan a lézer zsebbenyúlós történet, amennyiben színes nyomtatást is szeretnénk, ide tökéletes volt a fekete-fehér konfiguráció is. És a lézernek hála nem kell attól rettegni, hogy beszáradna, vagy túl gyorsan fogyna ki a patron. Bár a Samsung nyomtatókat azóta átbrandelték HP-vá, szerencsére még mindig széles körben támogatott a termék ilyen szempontból is.

A vásárlás során volt lehetőség wifivel kérni a printert, de ez ha jól emlékszem 8000 forintot dobott volna a vételáron, illetve már eleve volt egy ZyXEL NAS-om otthon, amire USB-n csatlakoztatva a nyomtatót hálózati printert lehet varázsolni az eszközből egyszerűen. Illetve ami sokszor unszimpatikusnak tűnt, hogy sok wifis nyomtató inkább saját wifit sugároz, ahelyett, hogy az otthoni hálózatra tenné magát, sokszor kell egy tucat gyártói szoftver a wifis nyomtatáshoz, mert kevés gyártó követi a standardot, illetve hallottam ilyen hálózati printerekről, amelyek tucatnyi exploitnak voltak kitéve. Ilyenkor persze lehet számítani a gyártóra, hogy lesz olyan kedves és patcheli a sebezhetőséget, de nem találkoztam még olyan emberrel, aki otthon elgondolkozott volna a nyomtató firmware frissítésén, illetve legyünk őszinték, egy ilyen belépő szintű otthoni kis printert max három év support után a gyártó valószínűleg teljesen elenged szoftveresen.

Az előző részben kifejtettem fő problémáimat a WebOS rendszerrel kapcsolatban és eljutottam odáig, hogy frissült a tanúsítvány, emiatt ismét működött a Plex elérése, illetve a YouTube is reklámmentes lett.

A következő áthidalásra váró probléma nem közvetlenül a TV hibája, ugyanakkor nézhetetlenné teszi a médiafogyasztást Plexen. Konkrétan a TV beüzemelését követően kb két hónapig semmi baj nem volt a lejátszással, aztán egyszer csak elkezdett akadozni mindenféle lejátszás. Minden más tökéletesen ment, kivéve a Plex lejátszást.

Eleinte arra gyanakodtam, hogy egy szoftverfrissítéssel fogta vissza a gyártó a TV-t, nade ennyire, hogy egy 480p lejátszás se megy neki? Meg ugyanezt, sőt jobbat is tud Netflixen/YouTube-n teljesíteni?

Ekkor a hálózatra kezdtem gyanakodni, mivel valószínűtlen lett volna, hogy ennyire drasztikusan visszaesik a TV teljesítménye. A hálózati felállás nálam úgy néz ki, hogy Telekomos legnagyobb optikai csomag otthon, a TV az itthoni gigabites routeren kapcsolódik 5 GHz-en, a Plex szerver pedig a messzi Finnországban foglal helyet és gigabites uplinkkel rendelkezik. Elméletben nem kéne gondnak lenni, a gyakorlatban viszont valami nem kerek.

Az okostévék piaca egy nagyon zárt világ a tapasztalataim szerint. De ma már az ember nehezen ússza meg, hogy új TV vásárlásakor ne smart TV-be ruházzon be. Igen ám, de az okos TV fogalma meglepő módon 2021-ben is kimerül azzal, hogy a TV-d felmegy az otthoni wifire, telepíthetsz rá pár előre megírt alkalmazást és esetlegesen az adott TV keretrendszerét kihasználva fejleszthetsz rá újabb alkalmazásokat. Ennyiben viszont ki is merül a tudomány. Ennek ellenére vannak modellek, amelyek egészen használhatóak Netflixezni stb.

Így történt, hogy én is utánanéztem a lehetőségeimnek az okos TV fronton. A Samsung TV-ket azonnal ki kellett zárnom, mivel az általuk futtatott Tizen OS-ra még nem létezett Jellyfin/Emby kliens, ami saját médiák lejátszásánál jól jönne. A Sony Braviakról nem hallottam ekkoriban sokat, de több fórumon is azt olvastam, hogy külsős appoknak nem is engedi a hardveres gyorsítást médialejátszás közben, tehát egy Plex például igencsak nehézkesen boldogulna meg egy 4K-s tartalommal. Maradt egy harmadik nagyobb gyártó, az LG, akik szintén elkövettek pár ármányt az elmúlt évek során (pl a DTS támogatás kivétele 2020 utáni modelleknél), de ez még elfogadható korlátozásnak tűnt a többi gyártóval szemben. Így esett a végső választás egy LG TV-re.

Mivel az előző szerver diszkjei épp feladták a harcot, ideje a nulláról ismét nekiállni a folyamatnak, amit ezen írások fognak lépésről lépésre dokumentálni.

Ugyanakkor már most szeretném leszögezni, hogy az írás nem szponzorált, nem is Szentírás, minden a cikkben megnevezett szolgáltatónak vannak előnyei/hátrányai. Érdemes mérlegelni a döntés előtt, viszont én csak a saját tapasztalataimról tudok írni, így a cikk erősen az én preferenciáimat fogja tükrözni.

Bevezetésnek annyit, hogy nagyon sokáig voltam annak híve, hogy egy otthoni NAS tökéletesen ellátja a feladatát a személyes képek, videók, egyéb médiák tárolására, illetve alkalomadtán jó 1-1 linux isot is letölteni vele, amit nyilván sokáig seedben tud tartani. Valahol igaz is, hogy egy Raspberry Pi pl tökéletesen alkalmas erre a feladatra és olcsóbban nem is lehet kijönni energiafogyasztás szempontjából, de az idők során hozzászoktam pl a Plex kényelméhez, illetve azért valljuk be, egy mobil CPU még mindig nem képes egy desktop hw szintjére lépni. Viszont az otthoni szerver üzemeltetést egyrészt nem tudtam volna megoldani, mivel a feltöltési sebességem sajnos nem a legjobb, illetve némi matek után az jött ki, hogy a gép ára, illetve a fenntartási költség hónapokra lebontva számomra drágább lenne (áram, internet, diszkek), mint ugyanezt a cloudban felépíteni. Ma már simán meg lehet ezt tenni, mert a legtöbb helyen van legalább 40 Mbit/s letöltés, ami bőven elég kb mindenre, amit használok, ha meg néha otthonról kellene feltöltenem képeket, arra bőven elég a feltöltési sebességem itthon, hogy távoli szerverre toljam fel őket.

Esetemben adott volt egy bare metal dedikált szerver hosting, ami nagyon kedvező feltételek mellett megkeresett, hogy szívesen tehermentesítené a tárcámat egy közösségi projektem hostolása kapcsán. Ez a lehetőség kapóra jött, mivel pont kerestem egy barátibb konfigot CI szervernek. Igen ám, de ahogy minden túl kecsegtető ajánlat, ez is hordozott magában egy kis csavart. Az elmúlt évek során a Debian/Ubuntu szerverek iránti imádatom átvándorolt a Fedora Server felé, így egyértelmű volt, hogy a leendő szerveren is Fedora fog futni.

Ám a hosting oldalát jobban áttanulmányozva nincs sehol lehetőség egyedi lemezképről telepíteni a vasat, az elérhető operációs rendszereik közt pedig sajnos a Debiantól a CentOS-on át a Windows Server 2019-ig minden volt, csak Fedora nem. Ami persze érthető, a legtöbb szervert bérlő cég (sajnos) nem a friss csomagokkal rendelkező és alaposan felkonfigurált, SELinuxos Fedorát fogja választani, hanem az ősrégi csomagokkal megáldott Debiant...

DNS. Egyidős protokoll a ma létező internettel, ami annak idején azért jött létre, hogy ne hosszú számsorokból álló IP címeket kelljen megjegyezni a kedvenc fórumunk meglátogatásához, hanem elég legyen csak megjegyezni a prohardver.hu címet és már ott is vagyunk a kívánt oldalon. Azóta természetesen rengeteg új feladata lett, rengeteg új rekordtípus született, de maga a protokoll nem igen változott az évtizedek során. Azóta is teljes rálátással van mindenki a DNS forgalomra, mivel az nincsen megfelelően titkosítva. Így a netszolgáltató, sőt esetlegesen a hálózat többi szereplője (pl. wifin) beleláthat a feloldási előzményeinkbe. Bár ez önmagában csak annyit jelent, hogy a szolgáltatónak például lesz egy képe arról, hogy mely fő domaineket látogatjuk napi szinten, (pl google.com), a teljes címet nem fogja egy DNS lekérés tartalmazni (tehát pl google.com/search). Illetve a titkosítás és annak validálásának hiánya miatt sokkal könnyebb eltéríteni a DNS válaszokat. Ez egy probléma, amelyet a Cloudflare ismert fel először és alkották meg a DNS over TLS specifikációját és alkalmazták azt elsőként az 1.1.1.1-es DNS szerverükön. Tovább is olvastam részletek után kutatva és meg is találtam a specifikációt: [link] Kiderült, hogy ugyan friss még a dolog, az Android 9+ már támogatja a funkciót, illetve néhány böngésző bétája is. Elhatároztam tehát, hogy teszek vele egy próbát mindenképp.

Boldogan gondolok vissza Androidos fénykoromra, mikor a zsebemből nem egy telefont, hanem egy apró méretű számítógépet húztam elő. El kell ismernem, a Google és a CyanogenMod team egy olyan élményt alkotott számomra az Android 4.2.2 alapú CM10.1 ROM-mal, amit ténylegesen élmény volt használni. Ezek után pedig következett a hanyatlás, ahogy az lenni szokott. Valamiért néhány fejes úgy gondolta, hogy jobb elvenni a már létezőt, mint adni. Azóta főverzióról főverzióra zárják el a fejlesztőktől a lehetőségeket, biztonsági kockázat címszóra hivatkozva. Értem én, saját biztonságom meg stb, de minek vettem telefont lassan egy számítógép áráért, ha a biztonságom érdekében zárják el fokozatosan előlem és a fejlesztők elől pontosan azokat a dolgokat, amelyek miatt többet költöttem telefonra.

Először jöttek a kisebb merényletek talán, hogy mobilnetet nem lehet kapcsolgatni csak úgy. Mindenképpen root szükséges, ha azt bármelyik applikációból szeretnénk mondjuk ütemezve megtenni. Nem sokkal később, a Kitkat megjelenésével nagyot lépett a Google és ráébredt, hogy mekkora biztonsági kockázat rejlik már abban, ha az alkalmazások csak úgy tudnak írni/olvasni az SD kártyára/-ról minden további nélkül. Így a KitKaten (4.4) egészen egyszerűen nem lehet mezei alkalmazásként (aka nem rendszerapp) akárhova írni, csak az adott alkalmazás saját mappájába. Hát hogy ez hogy jött nekik, meg hogy merték meglépni, azt a mai napig nem értem, de úgy tűnik sokan mások sem. Mivel a közfelháborodás hatására a következő verziók már legalább adnak lehetőséget az írásra amennyiben a felhasználó egy tallózó activity-n engedélyt ad a hozzáféréshez. Azt leszámítva, hogy ezzel is elvágták a visszafele kompatibilitást, még azt mondom egészen tűrhető az elképzelés, hogy bízzuk a felhasználóra a döntést. Bár ezt a funkciót activity-vel nem rendelkező appoknál elég macerás alkalmazni. A megvalósítás meg merem kockáztatni, hogy az utolsó pillanat műve volt... Volt viszont egy értelmesnek mondható lépésük is, az emulált tárhely bevezetése. Az alap ötlet emögött, hogy a telefont úgy lehessen számítógéphez csatlakoztatni, hogy közben a telefon is változatlanul lássa a csatlakoztatott partíció(ka)t, az ide telepített applikációk és adatok továbbra is elérhetőek legyenek. Így viszont dobni kellett a korábbi USB Mass Storage kapcsolódási módot, lett helyette az MTP. Rengeteg hátránya közt talán a kompatibilitás kérdése tűnik ki, jó ha az asztali gép felismeri, de médialejátszóknál pl. nem jellemző a támogatás. Illetve az, hogy egyszerre csupán egy fájlműveletet engedélyez. De a wiki-n fel van tüntetve a többi limitációja is. És akkor ennek tetejébe jött az aduász, a SELinux bevezetése. Ok, tényleg tök jó, hogy a kernel majd eldönti mihez ad kinek és hogyan hozzáférést, de a telefonomon nehogy már egy policy csomag határozza meg, hogy mit lehet és mit nem. Az OS adjon csak egy alapból tiszta környezetet, döntse el a user, hogy mit telepít és legyen az ő felelőssége az óvatosság. Egy generáció már lassan felnőtt az Androidon, csak működne. Vagy legyen a kettő kombinálva. Cégeknél RHEL alatt eleget kínlódtam SELinux-szal, ott meg is értem, hiszen enterprise szféra. De egy telefonon minek.