linux

Atrodo, jog su B. Gateso ir S. Ballmerio pasitraukimu, „Microsoft“ pradėjo iš keisti kompanijos strategiją ir aktyviai imtis atvirojo kodo projektų. Ne, atvirojo kodo „Windows“ ar „Microsoft Office“, bent jau artimiausius kelerius metus, mes tikrai neišvysim, tačiau visai neseniai kompanija pagal atvirąją MIT licenciją pateikė .NET ir „Chakra JavaScript“ sistemų išeities tekstus. Tačiau į „Windows 10“ sistemą „Microsoft“ įtraukė galimybę paleisti „Bash“ komandinę aplink ą ar net visą „Ubuntu Linux“ sistemą, tiesiai iš „Windows“, kaip vartotojo lygmens procesą.

Šiandien „Microsoft“ paskelbė, atverianti plačiai ir gan agresyviai reklamuotą savo komandinės eilutės aplinką „PowerShell“, kurią taip pat galima rasti „GitHub“ atvirojo kodo projektų talpykloje. Anot kompanijos atstovų, „PowerShell“ daugelis vartotojų naudojo sistemų administravimui, nutolusiam valdymui ar konfigūravimui, tačiau nemažai daliai nepatiko tai, kad „PowerShell“ yra tik „Windows“ sistemoje. „Microsoft“ nusprendė atsižvelgti į šiuos pageidavimus ir pateikė „PowerShell“ paketus „Apple OS X“ bei „CentOS“ ir „Ubuntu“ sistemoms. Ateityje kompanija planuoja sukurti „PowerShell“ sistemas ir kitoms platformoms.

Tačiau yra nemažai abejojančių gerais „Microsoft“ ketinimais. Pirmiausia tai net ir didžiausiems optimistams turėtų būti akivaizdu, jog tokiu būdu kompanija siekia kuo labiau susieti vartotoju su savo gaminiais. Taip yra todėl, kad pasirinkus kokią nors platformą ir pradėjus ją intensyviai naudoti, pakeisti pasirinktą platformą gali būti labai sunku, mat reikės keisti ne tik platformą, bet ir visas per platformos naudojimo laiką sukurtas sistemas. Be to, nors ir išleidusi gaminius pagal atvirąją MIT licenciją, kompanija nėra paskelbusi, perduodanti viešam naudojimui patentus, susietus su šiomis technologijomis. Kitaip tariant, jei šių atvirųjų technologijų pagrindu kas nors sukurs programinį produktą, potencialiai keliantį komercinę grėsmę „Microsoft“ pajamų šaltiniams, kompanija gali pateikti patentinius ieškinius ir taip sužlugdyti konkurentą. Būtent tokiu būdu šantažuodama patentais, „Microsoft“ privertė visus didžiuosius „Android“ telefonų gamintojus mokėti licencinius mokesčius. Pajamos iš kurių, net ir geriausiais „Windows Mobile“ laikais kelis kartus viršijo pajamas, gaunamas parduodant savo mobiliąją operacinę sistemą.

Kol kas yra žinoma nedaug - „Intel“ neviešina saugumo spragos detalių, kol nebus pateiktos operacinių sistemų pataisos, apeinančios šią aparatinę problemą. Tačiau iš to kas yra žinoma, susidaro įspūdis, kad per paskutinį dešimtmetį pagamintiems „Intel“ procesoriams aktuali problema yra tikrai rimta ir kelia grėsmę operacinių sistemų darbo saugumui. Reikia pastebėti, jog AMD gaminami procesoriai šios problemos neturi.

Kas yra apmaudžiausia šios klaidos nėra galima ištaisyti atnaujinant procesoriaus mikrokodą. Dauguma šiuolaikinių kompiuterių procesorių yra dalinai programuojami ir nemažai procesoriaus klaidų, aptinkamų po procesoriaus išleidimo į rinką, yra ištaisomos operacinės sistemos įkrovos metu, įkraunant specialų mikrokodo instrukcijų rinkinį. Tačiau ši procesoriaus projektavimo klaida yra fiziniame silicio komponentų grandyno lygmenyje ir jo funkcijų pakeisti neįmanoma. Vietoje to, operacinių sistemų sistemų kūrėjai turės pataisyti sistemų branduolius taip, kad šie išvengtų klaidingos situacijos susidarymo. O tai, išankstinių spartos testų duomenimis, OS darbą gali sulėtinti nuo 5 iki 30 proc.

Grandinėle (daisy chain) sujungus kelis LCD monitorius per „Display Port“ jungtis visi jie veikia kartotuvo režimu ir rodo tą patį vaizdą. Kompiuteris mato tik vieną monitorių. Aktyvavus „Display Port 1.2“ („Multiple Stream Transport“ - MST) funkciją, monitoriai užgęsta ir neberodo nieko. Ar galima kelis monitorius prijungti prie vienos vaizdo plokštės „Display Port“ jungties?

„Display Port“ sąsaja iš tiesų numato galimybę prijungti kelis monitorius prie tos pačios vaizdo plokštės „Display Port“ jungties. Tačiau tam būtina išpildyti keletą sąlygų. Pirma , toks jungimo būdas galimas tik, jei ir vaizdo plokštė, ir monitoriai yra suderinami su 1.2 ar naujesne „Display Port“ sąsajos versija. Taip pat būtina naudoti 1.2 sąsajos specifikacijas atitinkančius kabelius.

Jei turite suderinamą įrangą, ją būtina sujungti tinkama tvarka. Kompiuterio vaizdo plokštės „Display Port“ (DP) jungtį reikia prijungti prie pirmojo monitoriaus „DP In“ įvesties jungties. Priklausomai nuo turimo kabelio, gali reikėti „DP In“ arba „mini DP In“ lizdą. Tuomet kitu laidu prijungti antrą monitorių prie pirmojo, jungiant „DP Out“ jungtį pirmame monitoriuje su „DP In“. Priklausomai nuo vaizdo plokštės galimybių, taip jungiant „DP Out“ jungtį su tolimesnio įrenginio „DP In“ jungtimi, grandinėle galima sujungti iki 4 monitorių.

Prijungus monitorius, jie veiks kartotuvo režimu ir rodys tą patį vaizdą, nes paprastai monitoriuose nėra aktyvuojamos „DP 1.2“ sąsajos funkcijos leidžiančios išnaudoti sąsajoje numatyto koncentratoriaus funkciją, leidžiančią tuo pačiu kabeliu perduoti keletui įrenginių skirtą signalą („Multiple Stream Transport“ - MST). Norint, kad kompiuterius monitorius matytų, kaip atskirus įrenginius, juose reikia aktyvuoti „DP 1.2“ suderinamumą. Kaip tai padaryti ir kurį įrenginio valdymo meniu reikia sužadinti - reikia žiūrėti konkretaus monitoriaus dokumentacijoje. Naudojant „Intel HD“ vaizdo posistemį „DP 1.2“ reikia aktyvuoti visuose monitoriuose, išskyrus paskutinį grandinėje, kuriame turi likti „DP 1.1“. Kaip rašoma „Dell“ žinių bazėje, šis monitorius gali apskritai nebūti suderinamas su DP1.2 sąsaja, nes jame nebus naudojamos papildomos MST funkcijos. Kitoms vaizdo plokštėms gali reikėti sužadinti „DP 1.2“ visuose grandinės monitoriuose.

Priklausomai nuo naudojamos OS ar jos nuostatų, taip prijungti monitoriai turėtų būti atpažinti, kaip atskiri įrenginiai automatiškai arba gali reikėti papildomo sistemos konfigūravimo ir/arba vaizdo tvarkyklių atnaujinimo. Populiaraus tarp nešiojamųjų kompiuterių „Intel HD“ posistemio tvarkyklių MST funkcijos suderinamumas atsirado maždaug nuo praėjusių metų trečiojo ketvirčio. Tai reiškia, kad, pavyzdžiui, „Ubuntu 14.04 LTS“ sistemai reikės atnaujinti ir „X.Org“ grafinę aplinką ir ieškoti naujų tvarkyklių, o „Ubuntu 16.04 LTS“ jas jau turės sistemoje. Tačiau vien tvarkyklių gali nepakakti, nes, bent jau „Linux Mint“ sistemoje, MST funkciją reikia aktyvuoti patiems. Jos aktyvavimui „Linux“ branduoliui reikia perduoti TVARKYKLES_VARDAS.mst=1 parametrą, kur TVARKYKLĖS_VARDAS yra vienas iš šių: i915, radeon, r128, nvidia, nouveau arba modesetting. Jei sistemoje naudojamos keli skirtingi vaizdo posistemiai, nurodykite kelis parametrus, atitinkančius jūsų naudojamą vaizdo posistemio tvarkyklę. Koks konkrečiai modulis naudojamas, galima sužinoti paleidus lsmod | grep -E "i915|radeon|nvidia|nouveau|r128|modesetting" komandą.

„Ubuntu“ ir „Debian“ pagrindu veikiančiose sistemose, kurios naudoja „Grub“ arba „Grub 2“ įkrovos tvarkyklę, branduolio parametrai nurodomi, keičiant /etc/default/grub rinkmenos turinį. Priklausomai nuo „Grub“ versijos, šios rinkmenos kintamųjų pavadinimai gali skirtis. Naudojant „Grub 2“ reikia keisti GRUB_CMDLINE_LINUX_DEFAULT kintamojo reikšmę.

juodas ~ # grep DEFAULT /etc/default/grub
GRUB_DEFAULT=0
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash radeon.blacklist=1"

Pavyzdžiui, prie GRUB_CMDLINE_LINUX_DEFAULT kintamojo reikšmių pabaigos pridėkite i915.mst=1 parametrą, jei naudojate „Intel HD“ vaizdo posistemį, atskirdami jį tarpu. Tarp parametro pavadinimo ir reikšmės bei lygybės ženklo neturi būti tarpų.

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i915.mst=1"

Pakeitę „Grub“ nuostatų failą, reikia atnaujinti „Grub“ konfigūraciją, pasitelkiant „update-grub2“ (arba update-grub) komandą:

juodas ~ # update-grub2
Generating grub configuration file...
File descriptor 8 (pipe:[563056]) leaked on vgs invocation. Parent PID 13306: /usr/sbin/grub-probe
File descriptor 8 (pipe:[563056]) leaked on vgs invocation. Parent PID 13306: /usr/sbin/grub-probe
File descriptor 8 (pipe:[563056]) leaked on vgs invocation. Parent PID 13323: /usr/sbin/grub-probe
File descriptor 8 (pipe:[563056]) leaked on vgs invocation. Parent PID 13323: /usr/sbin/grub-probe
File descriptor 8 (pipe:[563056]) leaked on vgs invocation. Parent PID 13340: /usr/sbin/grub-probe
File descriptor 8 (pipe:[563056]) leaked on vgs invocation. Parent PID 13340: /usr/sbin/grub-probe
File descriptor 8 (pipe:[563056]) leaked on vgs invocation. Parent PID 13357: /usr/sbin/grub-probe
File descriptor 8 (pipe:[563056]) leaked on vgs invocation. Parent PID 13357: /usr/sbin/grub-probe
File descriptor 8 (pipe:[563056]) leaked on vgs invocation. Parent PID 13434: /usr/sbin/grub-probe
File descriptor 8 (pipe:[563056]) leaked on vgs invocation. Parent PID 13434: /usr/sbin/grub-probe
Found linux image: /boot/vmlinuz-3.19.0-51-generic
Found initrd image: /boot/initrd.img-3.19.0-51-generic
File descriptor 8 (pipe:[563056]) leaked on vgs invocation. Parent PID 13626: /usr/sbin/grub-probe
File  descriptor 8 (pipe:[563056]) leaked on vgs invocation. Parent PID 13626: /usr/sbin/grub-probe
Found memtest86+ image: /memtest86+.elf
Found memtest86+ image: /memtest86+.bin
File descriptor 8 (pipe:[563056]) leaked on lvs invocation. Parent PID 13837: /bin/sh
Found Microsoft Windows XP Professional on /dev/sda2
done

Pataisius „Grub“ konfigūraciją, galima perkrauti kompiuterį ir aktyvuoti MST suderinamumą. Žinoma, jei tai nėra nešiojamas kompiuteris, tai MST suderinamumą reikėtų aktyvuoti, prieš įjungiant „DP 1.2“ funkcijas, antraip vaizdas ekranuose gali dingti.

„Fedora“, „RedHat“ ir „CentOS“ sistemose taip pat reikia redaguoti /etc/default/grub failą, tačiau kintamasis vadinasi GRUB_CMDLINE_LINUX.

Namų serverio konfigūracija keitėsi ne vieną kartą. Įprastini ų programinių servisų serveris buvo paverstas virtualiųjų mašinų serveriu, tuo pačiu pasitobulinant virtualizacijos žinias bei palaipiojant ant vienokių ar kitokių grėblių. Nuo to laiko praėjo daugiau, nei metų, o kompiuterijos srityje tai labai daug - ištisa amžinybė. Per šį laiką serveryje buvo pakeistos net kelios kartos diskinių kaupiklių, daugeliu atveju dėl kaupiklių gedimų. Taip kiekvieną kartą serverio talpykla po truputį augo, senuosius diskus po vieną pakeičiant naujais didesniais kaupikliais. Duomenis visuomet pavyko išsaugoti, nors kartą berods teko atkūrinėti pabirusią failų sistemą ir prisiminti, kad rezervines kopijas galima ne tik kurti, bet ir iš jų atsistatyti duomenis.

Po paskutinės migracijos serveryje buvo likę 3 diskai, kuriuose buvo sukonfigūruoti 3 RAID5 masyvai. Jau tuomet žinojau, kad konfigūracija nėra optimali, bet sistema, kaip ir veikė. Tuo metu visi servisai jau buvo išmigruoti į Docker programinius konteinerius, o virtualios mašinos sustabdytos. Palyginus su virtualiomis mašinomis, Docker konteineriai veikė gerokai sparčiau. Taip yra dėl kelių priežasčių. Pirmiausia, konteinerio procesų virtualizavimui reikia mažiau išteklių, nes programinio konteinerio struktūra yra paprastesnė, nei viso kompiuterio virtualizavimas. Antra, Docker konteineriai tiesiog naudoja serverio failinę sistemą, todėl bendrai paėmus reikia mažiau disko I/O operacijų, kurios trunka labai ilgai (palyginus su CPU skaičiavimo operacijomis).

Taigi laikas ėjo ir vėl ėmė niežėti nagus, nes prieš keletą metų ant technologijų bangos buvęs Docker buvo išstumtas ir dabar naudojamas tik, kaip konteinerių paleidimo technologija bei kūrimo įrankis. O konteinerių infrastruktūros valdymo srityje dabar yra vienvaldis lyderis - Kubernetes. Tuo pat metu pribrendo laikas dar vienai serverio modernizacijai bei Kuberntes klasterio sukūrimui. Tiesa, kol kas klasterio dydį apribotas vienu serveriu, tačiau tai netrukdo naudoti Kubernetes privalumais. Vienas pagrindinių privalumų yra serviso teikimo užtikrinimas, kurį su Docker Compose teko spręsti įvairių Shell scenarijų ir sistemos servisų kokteiliu. Bet apie tai kitą kartą. Vos tik įdiegus Kubernetes ir numigravus pirmuosius Docker Compose servisus į Kubernetes, paaiškėjo, kad serveris ėmė veikti vėžlio greičiu, o sistemos apkrovos lygis nuolat pakildavo virš 4-5.

Atsinaujinus kompiuterio pagrindinę plokštę, nusprendžiau atnaujinti ir kompiuterio diskinius kaupiklius. Turimi ekonominės klasės 1TB diskai neblizgėjo darbo sparta, taigi visą sistemą nusprendžiau perkelti į SSD kaupiklius, o 1TB diskus palikti tik duomenims saugoti. Prieš įdendant naujus kaupiklius abiejuose 1 TB diskuose buvo po 3 skirsnius, kurie buvo sujungti į atitinkamus RAID1 (veidrodinius) masyvus: 512M md0 (/boot), 50G md1 (LVM rootvg) ir md2 881G (LVM datavg). Na bent jau aš maniau, jog diskų konfigūracija yra tokia.

Pirminė užduotis buvo migruoti md0 ir md1 masyvus į SSD diskus. Tam abu SSD kaupikliai buvo prijungti, kaip SATA1 ir SATA2 ir pirmą kartą sistemą priverstinai įkrauta iš SATA3 kaupiklio. Pernelyg nenustebau, kai sistema įsikrovė lyg niekas nebuvo pasikeitę (pabandykite su Windows pakeisti pagrindinę plokštę ir perjungti kaupiklius prie kitų SATA jungčių ;)).

Įsikrovus sistemai diskinio posistemio konfigūracija buvo maždaug tokia:

root@juodas:~# pvs
PV VG Fmt Attr PSize PFree
/dev/md1 juodas-rootvg lvm2 a-- 49,96g <29,96g
/dev/md2 juodas-datavg lvm2 a-- 880,88g 8,16g
root@juodas:~# cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid10]
md0 : active raid1 sdc1[1] sdd1[0]
523712 blocks super 1.2 [2/2] [UU]

md2 : active raid1 sdc3[1] sdd3[0]
923677376 blocks super 1.2 [2/2] [UU]
bitmap: 1/7 pages [4KB], 65536KB chunk

md1 : active raid1 sdc2[1] sdd2[0]
52396032 blocks super 1.2 [2/2] [UU]

Migracija iš paprastų konteinerių į „Kubernetes“ buvo pradėta gan seniai ir prieš keletą mėnesių buvo sėkmingai užbaigta, kai į „Kubernetes“ persikėlė paskutinės tarnybos, tokios kaip „Transmission“ ir „Minecraft“. Žinoma, tobulinti dar yra ką - didelė dalis tarnybų naudoja „host network“ tinklo ryšius bei "host path" tipo duomenų saugyklas. Visa tai turės būti pakeista į labiau „Kubernetes“ klasteryje įprastus „Ingress“ ir „Persistent Volume“ išteklius. Tačiau iki šiol visas „Kubernetes“ klasteris buvo sudarytas iš vieno kompiuterio ir tai ėmė kelti savų iššūkių. Pirmiausia, kartais tiesiog jau ėmė  trūkti kompiuterio išteklių. Be to, turint vieną kompiuterį - nelabai yra galimybių išsibandyti apkrovos balansavimo technologijas. Todėl atėjo laikas klasterio plėtrai.

Kadangi elektra šiais laikais yra gan brangus išteklius, net ir turintiems Saulės elektrinę, todėl įprastiniai duomenų centrų serveriai, neretai srebiantys po pusę kilovato ar daugiau, nebuvo svarstomi. Tuo labiau, kad nors kiek ekonomiškesnių serverių kainos yra gerokai aukštesnės, nei norėčiau išleisti namų duomenų centrui, kuris neneša tiesioginių pajamų. Todėl jau kokį pusmetį žiūrinėjau į mažųjų kompiuterių pasiūlą. Galiausiai buvo apsispręsta, kad serverinėje spintoje turės įsikurti 3 mažieji „Lenovo ThinkCentre M93“ kompiuteriai. Šie mažyliai su 8GB RAM, 200GB SSD disku ir i7-4765T procesoriais pastebimai padidins „Kubernetes“ klasterio skaičiavimo pajėgumus, neiškeldami elektros sąnaudų į kosmosą. Kad ir kokia apkrova būtų - jie nepajėgūs naudoti didesnę, nei 65W galią, nes tik tiek gali tiekti jiems elektrą tiekiantys nešiojamųjų kompiuterių maitinimo šaltiniai. Todėl sumoje šie trys kompiuteriai neturėtų naudoti daugiau, nei 220W.

Taigi, po pusdienio darbo, iš kurio didžiąją dalį sugaišau kurdamas USB laikmeną sistemos diegimui (nes iš vienos laikmenos sistema užsispyrusiai nenorėjo krautis), ant stalo sukrauta tapo mano „Kubernetes“ klasterio dalimi. Tiesa, kol kas kompiuteriams dar nėra priskirta jokia rolė, nes įdiegus sistemą, kompiuteriai buvo išjungti ir supakuoti į dėžę. Klasterio plėtimas atidedamas iki kito savaitgalio, nes tvarkingai išvedžioti už kompiuterių matomą kabelių „kūšį“ reikia laiko.

$ kubectl  get nodes
NAME      STATUS   ROLES                  AGE     VERSION
k8s1      Ready    <none>                 119m    v1.23.0
k8s2      Ready    <none>                 9m17s   v1.23.0
k8s3      Ready    <none>                 8m23s   v1.23.0
vm-serv   Ready    control-plane,master   670d    v1.23.0

Šiandien į rinką turėtų iššokti nauja „openSUSE“ versija - „openSUSE Leap 42.1“. Nuo paskutinės „openSUSE“ versijos praėjo metai ir per tą laiką SUSE autoriai smarkiai pakeitė tai, kaip bus kuriama, prižiūrima ir plainama „openSUSE“ sistema.

„openSUSE Leap“ naudos tą patį sistemos branduolį, kaip ir komercinė „SUSE Linux Enterprise“, todėl norintys stabilios darbinės sistemos, galės nesibaimindami rinktis „openSUSE Leap“. Siekdami pabrėžti pokyčius sistemoje, autoriai taip pat iš esmės pakeitė „openSUSE“ versijavimą ir pirmoji „Leap“ versija bus - 42.1. Autoriai nė nemėgina slėpti, jog skaičiai „4“ ir „2“ buvo pasirinkti atsitiktiniai, tai užuomina į atsakymą į klausimą apie gyvenimo prasmę pasaulį ir viską apskritai ir kultinio fantastinio romano „Kelionės autostopu po galaktiką vadovas.

O jei kalbant rimtai, tai naujoje „openSUSE Leap“ sistemoje bus galima rasti naujas „KDE 5“, „GNOME 3.16“, „LibreOffice 5“ paketų versijas. Nebuvo pamirštas ir operacinės sistemos branduolys, kuris buvo atnaujintas iki 4.1 versijos. O norintiems pačių naujausių programinės įrangos paketų , galima pasiūlyti nuolat atnaujinamą „openSUSE Tumbleweed“ versiją.

Nors openSUSE nesinaudoju jau daugiau, nei 5 metai, tačiau asmeninė patirtis su šia sistema buvo tikrai nebloga, ypač žiūrint pradedančiojo vartotojo pozici jų. To meto „Ubuntu“ dar buvo gan „žalia“. Tiesa, vienas dalykas man visgi užkliuvo ir galiausiai tapo priežastimi, kodėl „openSUSE“ neprigijo mano kompiuteryje.

Šia priežastimi tapo išskirtinė „openSUSE“ konfigūravimo priemonė - „YaST“. Kiekvieną kartą paleidžiant, ji keletą minučių generuodavo /etc konfigūraciją iš vidinių konfigūracijos failų, saugomų kažkur /var. Tai ne tik trukdavo ilgiau, nei deretų. Toks automatinis sistemos konfigūracijos generavimas sukeldavo keblumų, kai prireikdavo taisyti /etc katalogo konfigūracijos failus tiesiogiai, nes reikiamų nuostatų „YaST“ nebuvo numatyta. Po kiekvieno „YaST“ paleidimo, konfigūraciją tekdavo surašyt iš naujo, nes „YaST“ nesugebėdavo nusiskaityti aktyvios konfigūracijos ir ją sujungti su vidine konfigūracijos duomenų baze. Tikėtina, jog per pastaruosius metus tokios problemos jau buvo išspręstos ir nesusipratimų turėtų kilti mažiau. Vis dar ieškantiems jiems tinkamos „Linux“ sistemos, tikrai rekomenduoju išbandyti „openSUSE“. Mano pasirinkimas jau keletą metų iš eilės apsistojo ties „Ubuntu“ pagrindu sukurtomis sistemomis.

Ilgą laiką savo serveriuose naudojau stabilią „Debian“ sistemos šaką, tačiau ne kartą teko įsitikinti internete sklandančiu pokštu, kad stabili „Debian“ šaka tampa pasenusi, kai ji yra išleidžiama. Iš vienos pusės senose programų versijose yra išgaudyta daugiau klaidų ir jų atliekamos funkcijos jau yra nusistovėjusios, tad mažesnė darbo trikio tikimybė. Tačiau neretai prireikia naujo funkcionalo ir tuomet reikia eiti ieškoti paketų "testing", o kartais "unstable" paketų šaltiniuose. Be pasitaikančių įprastinių programų tobulinimo klaidų, minėti šaltiniai turi ir kitą blogybę. Jiems nėra taikoma pirmenybė, pritaikant saugumo spragų pataisas, kas šiaip yra savaime suprantama, nes tai programų tobulinimo poligonas.

Taigi, pasirodžius „Ubuntu 16.04", po neilgų svarstymų nusprendžiau, jog reikia pasikeisti savo virtualizacijos serverio OS. Kadangi jau vis vien buvau apsisprendęs trinti seną OS lauk ir rašyti naują, prieš tai nusprendžiau pabandyti atnaujinti „Debian“ į naujesnę „Ubuntu“ sistemą. Teoriškai tai turėjo pavykti, nes „Ubuntu“ yra kuriama „Debian“ sistemos pagrindu ir naudoja tą pačią paketų valdymo sistemą. Užbėgant už akių - galiu pasakyti, kad atnaujinimas pavyko, tačiau norintiems pakartoti, teks apsišarvuoti kantrybe, nes procesas nebus sklandus ir prireiks paleisti daugiau, nei vieną komandą. Taip pat yra tikimybė, kad atnaujinimas kažkur užstrigs ir vis vien teks trinti sistemą lauk ir instaliuoti iš naujo. Bent jau /home ir /var tikiuosi visi jau laiko atskirame skirsnyje ar LVM tome, ar ne?.. ;)

„Linux“ aplinkoje per „Wine“ paleista „Windows“ programa negali rasti USB ar įrenginių, prijungtų per nuosekliąsias („serial“) bei lygiagrečiąsias („paralel“) sąsajas. Tokie įrenginiai reikalingi, pavyzdžiui, automobilių diagnostikai atlikti.

Su šio tipo įrenginiais „Wine“ sistema turi keletą sunkumų. Pirmiausia pagrindinė problema yra ta, kad „Wine“ nėra suderinama su tiesiogine prieiga prie USB įrenginių, nors pačiam projektui jau daugiau, nei du dešimtmečiai. Šios problemos sprendimas vis svarstomas, tačiau realaus progreso šioje vietoje nėra daug.

Tačiau yra šiokia tokia išimtis USB nuosekliosios sąsajos įrenginiams, kuriuos geba atpažinti „Linux“ sistema. Šiuos įrenginius, o dauguma automobilinės diagnostikos prietaisų yra būtent tokie, galima „Wine“ sistemai pateikti, kaip įprastus standartinius nuosekliosios sąsajos įrenginius. Deja, „Wine“ autoriai nusprendė, kad tiesioginė prieiga prie nuosekliųjų ir lygiagrečiųjų sąsajų nėra labai dažnai naudojama funkcija, todėl automatiškai ši prieina nėra sukonfigūruojama.

„Wine“ svetainėje yra pateikiamos papildomos konfigūravimo instrukcijos, tarp kurių yra ir nuosekliosios ir lygiagrečiosios sąsajų prieigos aktyvavimas. Norint „Windows“ programai suteikti prieigą prie šių įrenginių, reikia $HOME/.wine/dosdevices kataloge sukurti nuorodas į atitinkamus nuosekliuosius ar lygiagrečiuosius įrenginius, pasiekiamus „Linux“ sistemoje.

cd $HOME/.wine/dosdevices
ln -s /dev/ttyS0 com2
ln -s /dev/ttyUSB0 com1
ln -s /dev/lp0 lpt1

Aukščiau esančiame pavyzdyje „Wine“ aplinkai sukuriamos virtualios com1 ir com2 sąsajos, susietos su pagrindinės plokštės pirmąja nuosekliąja sąsaja ir pirmąja USB nuosekliąja sąsaja, kurios yra pasiekiamos „Linux“ sistemoje. Taip pat sukuriama virtuali lygiagrečioji sąsaja - lpt1. Tačiau „Wine“ autorių pateikiamos instrukcijos nėra išsamios ir prieiga neretai nėra galima. Pirmiausia įprasti „Linux“ sistemos vartotojai dažnai neturi teisių skaityti ir rašyti į /dev/tty* įrenginių failus. Norint apsieiti be „Windows“ programų leidimo root teisėmis, tam reikės vieno iš trijų (pavyzdyje naudojamas /dev/ttyUSB0 įrenginys):

1. Sistemos administratoriaus teisėmis pakeisti įrenginio prieigos teises ir leisti skaityti ir rašyti visiems: chmod o+rw /dev/ttyUSB0. Šią komandą greičiausiai teks paleisti kiekvieną kartą įstačius įrenginį.
2. Prisidėti savo vartotoją prie grupės, kuriai priklauso įrenginiai. Grupę galima sužinoti, paleidus ls -al /dev/ttyUSB0 ir paskui administratoriaus teisėmis paleidus gpasswd -a VARTOTOJAS GRUPE pridėti vartotoją VARTOTOJĄ į grupę GRUPE. Po pakeitimo, reikės iš naujo prisijungti prie sistemos.
3. Pakeisti įrangos inicializavimo „Udev“ taisykles ir nusistatyti norimą vartotojo grupę, bei prieigos teises. Vienas iš galimų būdų aprašytas šiame puslapyje.

Deja šių instrukcijų nėra „Wine“ autorių puslapyje. Kaip nėra ir „Wine“ registro įrašo aprašymo, reikalingo prieigai prie sąsajų. Trūkstamą aprašą, pateikiamą žemiau pavyko rasti Vienišo tranzistoriaus tinklaraštyje.

gedit  ~/.wine/system.reg

Atsivėrusioje teksto rengyklėje iškart po #arch= eilutės įrašykite šias eilutes:

[Hardware\\Devicemap\\Serialcomm] 1231984861
"Serial0"="COM1"
"Serial1"="COM2"

Tokiu būdu per „Wine“ aplinką paleista „Windows“ programa galės susieti dosdevices kataloge sukurtą virtualaus įrenginio failą su nuosekliąja sąsaja.

Turintys žaidimų konsolę, manau neretai susiduria su tokia problema, kaip interesų dėl televizoriaus konfliktas. Juk „XBox“ ar „PlayStation“ žaidimų kompiuteris gan dažnai yra jungiamas prie televizoriaus, stovinčio svetainėje. O ten laisvalaikį mėgsta leisti ne tik žaidimus žaidžiantys asmenys.

Apie šią problemą yra pagalvoję tiek „Microsoft“, tiek „Sony“ žaidimų kompiuterių kūrėjai. Ir abiems kompiuteriams yra sprendimas - žaisti žaidimus, vaizdą perduodant į nutolusį įrenginį. Dėl „Nintendo Switch“ nesu tikras ar šis kompiuteris turi galimybę žaisti žaidimus nuotoliniu būdu, nes pavyko aptikti tik vaizdo transliavimo galimybes. Kita vertus su savą ekraną turinčiu „Switch“ tokios problemos neturėtų kilti iš principo, nes tai nešiojamas žaidimų kompiuteris.

Turintys „XBox“ gali pasinaudoti „Microsoft“ sukurta „XBox Console Companion“ programa, skirta „Windows 10“ operacinei sistemai. Išsamias programos naudojimo instrukcijas rasite šiame puslapyje: https://support.xbox.com/en-US/games/game-setup/how-to-use-game-streaming. Panašu, kad kompanija taip pat ketina nepamiršti ir mobiliųjų vartotojų ir „Android Play Store“ galima rasti „Xbox Game Streaming (Preview)“ programą. Taip pat galima panaudoti ir trečiųjų šalių programą - „OneCast“ (https://onecast.me/), kuri pritaikyta „Android“ ir „Mac“ sistemoms. Kadangi šiuo klausimu aš palaikau mėlynųjų komandą, tai daugiau apie nuotolinį žaidimą „XBox“ kompiuteriu papasakoti negaliu.

Turintiems „PlayStation 4“ „Sony“ sukūrė „PS4 Remote Play“ programą, pritaikytą „Windows“ ir „Mac“ kompiuteriams, kurią rasite šiame puslapyje: https://remoteplay.dl.playstation.net/remoteplay/lang/en/index.html. Kadangi langinių asmeniniame kompiuteryje apskritai nėra jau daugiau nei 8 metai, tai oficialios „Sony“ programos man buvo ne itin įdomios. Taigi kiek paieškojus pavyko rasti atvirojo kodo „Remote Play“ klientinę programą „Chiaki“ (https://github.com/thestr4ng3r/chiaki), tinkančią ir „Linux“ sistemoms (taip pat „Android“, „Mac“ ir „Windows“).

Eilinį kartą populistai politikai pasitelkia kokį nors populiarų dabartinių laikų baubą ir imituoja veiklą „mūsų pačių labui“. Šį sykį JAV, Didžiosios Britanijos, Prancūzijos ir dar keleto šalių politikieriai, prie vis labiau pradėjo šlietis dalis teisėsaugos atstovų, ėmė vis garsiau piktintis visuotinai prieinamomis patikimomis asmeninių duomenų šifravimo sistemomis. Jiems ypač užkliuvo „Apple“ ir „Google“ kompanijų sprendimas, naujose savo mobiliosiose operacinėse sistemose aktyvuoti pilną telefono duomenų šifravimą, be galimybės jį apeiti.

Pasak kompanijų, jose naudojami patikimi šifravimo algoritmai, neleidžiantys perskaityti telefone saugomų duomenų, neturint dešifravimo rakto. Savo ruožtu tai reiškia, kad kol vartotojas kam nors neatskleis slaptažodžio, kuriuo galima dešifruoti duomenis, tol niekas negalės perskaityti telefono turinio. Apie techninių galimybių dešifruoti duomenis naujose „iOS“ sistemose nebuvimą „Apple“ kompanija yra paskelbusi viešai, taip atsiribodama nuo keblių situacijų, kai į kompaniją kreipdavosi teisėsauga, reikalaudama ištraukti kokio nors įtariamojo „iPhone“ ar „iPad“ įrenginio duomenis.

Štai šioje vietoje politikai ir užčiuopė „aukso gyslą“ - paleisdami kakarynes, kad tokiu būdu „Apple“ ir „Google“ pataikauja nusikaltėliams ir „suriša rankas“ teisėsaugai. Nuo jų ėmė neatsilikti ir teisėsaugos atstovai, postringaudami, kaip šifravimas telefonuose visas teisėsaugos tarnybas nublokš į tamsiuosius amžius. Anot Čikagos polici jos departamento, po tokio „Apple“ sprendimo, „iPhone“ telefonai taps pedofilų pasirinkimu. Savo skiedalams patirštinti buvo pasitelkti iš kažkur ištraukti „faktai“, kad Prancūzijos teroro išpuolių organizatoriai išpuolio organizavimui naudojosi „PlayStation“ kompiuteriuose esančia žinučių programa, šifruojančia pranešimus ir taip sukliudžiusia teisėsaugai laiku išaiškinti teroristus.

Namų serveris pergyveno jau kelis atnaujinimus. Pernai seni WD Green diskai buvo pakeisti didesniais, o dar vėliau jie paraudonavo, keičiant 1.5 TB į 2 TB WD Red, kurie turėtų būti labiau pritaikyti NAS reikmėms. Tačiau migravimo į 2 TB diskus ilgam neužteko ir serveryje ėmė baigtis vieta - vien rezervinės kopijos užima per 800GB. Taigi vėl ėmiau sukti galvą, kur gauti daugiau vietos.

Paprasčiausias būdas - pirkti dar didesnius diskus. Bet tai brangu ir RAID1 nėra labai efektyvus disko erdvės panaudojimas. Taigi nusprendžiau RAID1 veidrodį pakeisti į RAID5 masyvą, kuriame duomenų saugumas remiasi kontrolinių sumų skaičiavimu. Naudojant Linux MD diskų masyvus, tai padaryti teoriškai yra labai paprasta. Tiesiog reikia "užauginti" RAID1 į "sugriuvusį" RAID5 ir paskui pridėti trūkstamą RAID5 diską. Ir taip nupirkus vieną papildomą diską, 2 TB veidrodis turėtų tapti 4 GB talpos RAID5 masyvu.

Ką gi, diskas buvo užsakytas prieš savaitę. Šiandien išjungiau serverį, įdėjau ir prijungiau diską ir įjungus kompiuterį niekas nesudegė. Pradžia nebloga. Tiesa, diena prieš tai visus svarbius duomenis iš serverio persikopijavau į 2 atskirus išorinius diskus. Taip dėl visa ko. :) Linux RAID dokumentacijoje masyvo migracija aprašyta labai glaustai:

mdadm --grow /dev/md/mirror --level=5
mdadm --grow /dev/md/mirror --add /dev/sdc1 --raid-devices=3

Kaupiant vis daugiau patirties, vis dažniau imi vertinti išmintį: „nors ir gali, tačiau nebūtinai turi“ („just because you can, does not mean you should“). Ir namų serveris tai pat patenka į šį apibrėžimą. Ar aš galiu pasidaryti savo serverį, teikiantį duomenų saugyklos, DHCP, failų siuntimo ir kitas funkcijas? Tikrai taip! Ar aš galiu tai padaryti pigiau, nei siūlo gatavų serverių gamintojai? Tikrai taip! Ar pavyks padaryti šias paslaugas patogias naudotis? Hm, na galbūt... Ar nereiks man tam sugaišti kelis mėnesius darbo? Hm, turbūt netgi ilgiau...

Kitaip tariant, kad ir koks būtum gudrus IT specas, tačiau reikia pripažinti, kad IT rinkos kompanija, galinti nusamdyti kelis tūkstančius darbuotojų - galės paruošti gaminį, kuriuo bus galima imti ir naudotis. Ir pakartoti jo funkcionalą tame pat lygyje per protingą laiko tarpą vienas žmogus neturi jokių galimybių. Todėl nusprendžiau nesivaržyti ir tiesiog pakeisti savadarbį serverį rinkoje parduodama universalia duomenų saugykla. Tuo labiau, kad senajame vis vien jau ėmė trūkti vietos, nuo senatvės ėmė garsiai ūžti dauguma ventiliatorių, o ir elektros sąnaudos bei šilumos išsiskyrimas pas eilinį kompiuterį yra nesulyginamos su specializuota įranga.

Renkantis saugyklą, iš principo reikėjo rinktis tarp 3 vardų: „Asus“, „QNAP“ ir „Synology“, nes kiti gamintojai arba nesiūlo savo gaminių Lietuvos rinkai, arba jų gaminiai yra riboto funkcionalumo. Kelis mėnesiu varčius „Storage Review“, „NAS Compares“ puslapius bei „Youtube“ apžvalgas galiausiai apsistojau ties „QNAP-473A“ modeliu. „Asus“ saugyklos buvo atmestos, nes pas mus nebuvo naujos kartos įrenginių, o saugykla perkama mažiausiai 5 metams į priekį. QNAP papirko geresne aparatine įranga už mažesnę kainą, lyginant su „Synology“, programinės įrangos kokybės sąskaita. Kita vertus, realiai pabandęs QNAP programas, imu jau abejoti savo sprendimu. Tačiau apie viską iš eilės.

„Google“ paviešinus daugiau informacijos apie aptiktas „Intel“ procesorių architektūrines klaidas, tampa aišku, kad ši problema aktuali ne vien „Intel“ procesoriams - didesniu ar mažesniu lygiu yra pažeidžiami ir AMD, ir ARM procesoriai. Kompanijos pranešime spaudai pateikiamas ne tik procesorių klaidų paveiktų „Google“ kompanijos programų sąrašas, bet ir daugiau techninių detalių apie pažeidžiamumus.

„Intel“ taip pat paviešino oficial ų pranešimą spaudai, kuriama nurodo, jog jokių architektūrinių klaidų nėra ir procesoriai veikia taip, kaip suprojektuoti. Anot kompanijos, tai tiesiog eilinės programinės įrangos darbo klaidos ir norint išvengti saugumo problemų, reikia tiesiog laikytis saugaus darbo kompiuteriu principų. Tačiau paskaičius kitą „The Register“ naujieną, galima rimtai suabejoti tokiais teiginiais, nes ten pateikiami akivaizdūs pavyzdžiai, kaip realiu laiku iš vienos vartotojo programos galima perskaityti kitoje programoje rašomą slaptažodį. “The Register“ atvirai išsityčiojo iš „Intel“ bandymų išsukti savo uodegą ir sušvelninti situaciją, nuvertinant aptiktų saugumo spragų pavojingumą.

Daugiau duomenų apie galimus išpuolius, pasinaudojant procesorių spragomis, galima rasti specialiame Meltdown and Spectre puslapyje, kur aprašomi du jau žinomi metodai, kaip apeiti skirtingų programų adresų sričių izoliacijos metodus.

Rūpintis savo duomenų saugumu reikia nuolat ir reikia tai daryti patiems. Atsarginės kopijos turi būti daromos nuolat ar bent jau kai pagalvoji, kad gal reikėtų jas padaryti. :) Tačiau pačios sistemos apsaugojimui nuo netikėto disko gedimo rekomenduojama daryti veidrodinį ar aukštesnio lygio RAID masyvą. Ir, kaip parodė praktika - pageidautina viename diske neturėti keleto masyvų.

Bet, pasirodo yra niuansų, todėl turėdami RAID1 veidrodinį masyvą - dar negalite būti tikri, kad nusprogus vienam iš diskų, jūsų sistema liks veiksni. Jau nė nekalbant apie duomenų teisingumą. Todėl - rezervinės kopijos ir dar kartą rezervinės kopijos. Net ir sisteminiams diskams, kur saugoma sistema ir jos konfigūracija. Nes pačią sistemą įdiegti galima greitai, tačiau prie visų reikiamų programų diegimo ir konfigūravimo kartais galima praleisti ir ne vieną dieną. Blogiau, kai apie tokius niuansus išsiaiškini sugedus būtent rezervines kopijas saugančio serverio diskui. :)

Taigi apie viską iš eilės.