Júniusban röppent fel a hír, miszerint még idén napvilágot lát a Microsoft operációs rendszerének újabb verziója. Most már az is kiderült, hogy mikor: október 5-én érkezik az új PC-kre, és ugyanekkor lehet frissíteni a régieket is. Nézzük, mivel jár a verzióváltás!

Mindenkinek egyszerre válik elérhetővé a frissítés?

Nem, szakaszokban lesz elérhető a 11-es verzió: elsőbbséget élveznek az újonnan megvásárolt eszközök, majd utána szép fokozatosan jön minden más. A Microsoft becslése szerint 2022 közepére fejeződik be a teljes átállás, ekkorra fut majd a 11-es verzió minden arra jogosult gépen. Ez egyrészről nem túl gyors folyamat, másrészről biztosan lesznek „trükkök”, amelyekkel meg lehet sürgetni a frissítést. Ám azt is érdemes figyelembe venni, hogy ebben a becslésben benne vannak mindazok, akiket a folyamat végén már noszogatni kell a frissítésre (azaz amikor már automatikusan végbemegy a folyamat, akár szeretnénk, akár nem), illetve a vállalati ügyfelek is, akiknél előbb ki kell deríteni, hogy egyáltalán szeretne-e a cég váltani, vagy kompatibilitástörő változásokat is ki kell előbb küszöbölniük.

Ingyenes lesz a frissítés?

Igen, minden jogosult eszközön ingyenesen lehet elvégezni a frissítési folyamatot, és a Windows 11-gyel kompatibilis, a megjelenés előtt még Windows 10-zel megvásárolt eszközöket is ugyanúgy lehet frissíteni, mint a régebben beszerzett hardvereket. Csupán a minimális követelményeknek kell teljesülniük. Ebben segít a PC Health Check app.

Mi történik, ha a gépem nem teljesíti a minimális követelményeket?

Ebben az esetben sajnos nem lehet frissíteni az új verzióra, és előbb vagy utóbb megszűnnek a Windows 10 biztonsági frissítései is. Azaz nem lesz más út, mint új hardvert vásárolni. Valószínűleg pontosan ezért (is) találták ki ezt az egész verziófrissítéses dolgot.

A minimális rendszerkövetelményeket itt lehet megtekinteni, de a PC Health Check appal magán a rendszeren is ellenőrizhetjük, hogy jogosultak vagyunk-e a Windows 11 beszerzésére.

Lesz rá mód ugyan, hogy telepítsünk Windows 11-et az olyan gépekre, amelyek hivatalosan nem támogatottak, ám a Microsoft állítása szerint ezek a rendszerek nem kapják meg automatikusan a biztonsági frissítéseket, így ez nem tűnik járható útnak az ilyen gépek életben tartására.

Mikor ér véget a Windows 10 támogatása?

2025. október 14-én. Innentől kezdve nem jelennek meg hozzá biztonsági frissítések, így az operációs rendszer további használata nem lesz javasolt.

Nem arról volt szó, hogy a Windows 10 után már nem lesznek újabb verziófrissítések?

De, pontosan ezt nyilatkozták 2015-ben, valamint azt, hogy onnantól kezdve egy szolgáltatásként tekintenek az operációs rendszerre. Azóta eltelt már jó pár év, és úgy tűnik, 10 év éppen elég volt egy verzióból, és ilyen vagy olyan okokból, de növelni kell egyet a számlálón.

Tényleg támogatni fogja a Windows 11 az androidos appok futtatását?

Igen, 2022-től a Microsoft Store kínálatában elérhetővé válnak androidos appok is, de az eddig rendelkezésre álló információk alapján közel sem lesz 100%-os átjárhatóság a két rendszer között.

Emiatt egyébként nem kell megvárni a Windows 11 megjelenését, hiszen ugyanerre képes a BlueStacks is, valamint korlátozott mértékben a Your Phone (Csatolt telefon) app.

További kérdések felmerülése esetén, illetve ha tanácsadásra van szükség az átállás megtervezéséhez, érdemes felvenni velünk a kapcsolatot.

A kiindulási pont

Tegyük fel, hogy van egy vagy több olyan számítógépünk, amelyre frissen telepítettük a Windows operációs rendszert, és most telepítenünk kell számos alapvető alkalmazást a gép(ek) használatba vételéhez.

A tradicionális módja a feladat elvégzésének az lenne, hogy fogjuk magunkat, egyenként letöltjük a számunkra szükséges alkalmazások telepítőit, majd egymás után, az általunk megszabott sorrendben elkezdünk mindent feltelepítgetni. Időrabló feladatnak tűnik? Az is. Szerencsére itt jön a képbe a Ninite.

A Ninite bemutatása

A Ninite egy egyszerűen használható online szolgáltatás, amely képes megkeresni az általunk kívánt szoftverek legújabb verzióját, és automatizálni a telepítők letöltését és futtatását, sőt, még néhány hasznos segítséggel is szolgál, például a 32/64 bites verziók közötti választással, vagy éppen a felesleges böngészőbővítmények, adware-ek és opcionális „ajánlatok” kihagyásával.

Nézzük a főbb előnyöket:

• A kiválasztott szoftverek legújabb verziójának automatikus telepítése az alapértelmezett beállításokkal, az alapértelmezett helyre
• A felesleges bővítmények, adware-ek és egyéb zavaró tényezők kihagyása telepítéskor
• 32 és 64 bites verzió elérhetősége esetén a megfelelő verzió automatikus kiválasztása
• A megfelelő nyelv kiválasztása, amennyiben az alkalmazásban elérhető a számítógép operációs rendszerén beállított nyelv
• Mindig a legfrissebb verziók letöltése a szoftver hivatalos webhelyéről
• Az esetlegesen már telepített alkalmazások figyelmen kívül lesznek hagyva, hacsak nem szükséges a frissítésük

És ami a legfontosabb:

A Ninite gondoskodik a telepítendő alkalmazások megfelelő telepítési sorrendjéről is, valamint a szükséges rendszer-újraindításokról. Így gyakorlatilag nekünk egyetlen telepítőfájlt kell csak letöltenünk és futtatnunk, és a folyamat innentől kezdve teljesen automatikusan végbemegy.

Ez már egy számítógép esetén is rengeteg időmegtakarítást jelenthet, de az igazi előnyeit akkor fogjuk csak megtapasztalni, ha egyszerre több gépen kell a nulláról történő telepítést elvégezni.

Mikor nem használható a Ninite?

Mint minden szolgáltatás esetén, itt is előfordulhat, hogy a Ninite esetleg nem tud maradéktalanul megfelelni az elvárásainknak. A legfőbb akadályt az jelentheti, ha a telepítendő alkalmazást nem találjuk a Ninite webhelyén. Ilyenkor az oldal megfelelő hivatkozását használva kérvényezhetjük az alkalmazás felvételét (Suggest an app/Show suggestion form), ám ez csak abban az esetben lehetséges, ha az alkalmazás telepítője kompatibilis a Ninite által használt automatizálási módszerrel. Értelemszerűen a készítők csak a legnépszerűbb, azaz a legtöbb felhasználó által kért alkalmazásokat fogják felvenni a repertoárba.

A másik akadályt az jelentheti, ha egyszerre rengeteg számítógépre kell telepítenünk a szoftverekből álló alapcsomagot, ilyenkor ugyanis hiába nyerünk időt azzal, hogy csak egy telepítőt futtatunk. 50 azonos paraméterű gép esetén például teljesen feleslegesen futtatjuk egyenként az operációs rendszer, majd pedig a Ninite telepítőjét, hiszen sokkal jobban járunk, ha egy gépre feltelepítünk mindent, és a kész állapotról készítünk egy rendszerlemezképet, amelyet aztán az összes többi gépre visszaállítunk. Erre szolgálnak például az Acronis megoldásai.

Mire jó a Ninite Pro verziója?

A Ninite fizetős verziójában lehetővé vélik számunkra, hogy egyszerre több gépen menedzseljük a telepített alkalmazásokat, valamint mindig naprakészen tartsuk a telepített verziókat. A megoldás egy ügynökszoftver az érintett gépekre történő telepítéséből, valamint a teljes flottánk egy webes felületen történő kezeléséből áll.

A segítségével megspórolhatjuk a telepítők többször történő letöltését is, hiszen ha kijelölünk a hálózaton gyorsítótárként funkcionáló gépeket, csak oda lesz az internetről letöltve a telepítőfájl, a többi gép már onnan szipkázza át a legfrissebb verziót telepítés vagy frissítés esetén, így sokkal kevesebb internetes sávszélességet kell használni a művelethez.

A telepített szoftververziókat könnyedén áttekinthetjük a webes felületen, és rögzíthetünk is egyes verziókat, ha nem a mindenkori legújabb verziót szeretnénk használni.

Természetesen a Pro verzió is csak azokkal a szoftverekkel működik, amelyek a Ninite webhelyén fel vannak sorolva, illetve csak a fenti Windows operációs rendszereket képes kezelni. A használatának költségei havi szinten vannak megadva, és az ár a számítógépflotta méretétől függően számítható ki.

Az Adobe Flash Player 2021. január 1-től már nem használható a naprakész rendszereken, ám számos oldal, többek között népszerű játékok készítői sem álltak át egy naprakész technológia használatára, hanem gyakorlatilag magukra hagyták a zsákutcának bizonyuló Flashre megírt kódjaikat és vele együtt számos felhasználójukat.

Szerencsére egyelőre még nem kell teljesen búcsút mondanunk ezeknek a tartalmaknak, ugyanis a Ruffle elnevezésű emulátorral újra életet lehelhetünk kedvenc játékainkba és flashes oldalainkba.

Mindehhez csupán a következő feltételeknek és követelményeknek kell teljesülniük.

Támogatott operációs rendszerek

• Windows
• Linux
• macOS

Támogatott böngészők

• Firefox
• Edge
• Chrome
• Safari

Az éppen aktuális verziót a hivatalos oldalról lehet beszerezni.

Mi az alábbiakban azt mutatjuk be, hogyan lehet Windows rendszeren futó Firefox böngészőben elérhetővé tenni a Flash-tartalmakat. (Két okból esett erre a választásunk: egyrészt ennek a legjobb a támogatottsága, másrészt pedig külön böngészőverziót telepítünk hozzá, így teljesen szeparáltan kezelhetjük a flashes és a nem flashes oldalakat.)

A Ruffle telepítésének lépései Windowson

• Először is töltsük le a Firefox Nightly verziót, a Ruffle bővítmény ugyanis csak ennél a verziónál lesz feltelepíthető.

• Indítsuk el a böngészőt, és írjuk be a címsorába az about:config kifejezést, majd nyissuk meg a beállításokat tartalmazó oldalt. Itt a keresőbe írjuk be az xpinstall.signatures.required kifejezést, és az értékét állítsuk false-ra.

• Keressük fel a Ruffle oldalát, majd telepítsük a bővítmény legfrissebb Firefox-verzióját. A biztonsági kérdésnél válasszuk a Hozzáadást (Add).

• Keressünk fel egy Adobe Flasht használó oldalt, és kattintsunk a lejátszás ikonra.

• És készen is vagyunk! Innentől kezdve rendelkezünk egy külön böngészővel a flashes tartalmakhoz, így nagyobb biztonságban is tudhatjuk a dolgainkat, mint ha a hétköznapi feladatokhoz használt böngészőnkre telepítettük volna a bővítményt.

Kiindulási helyzet

Adott egy Windows 10-es rendszert futtató számítógép, amely HDD-t, azaz hagyományos merevlemezt használ, ennek hasznos kapacitása 340 GB környékén van. Mivel a mozgó alkatrészekkel rendelkező háttértároló nem csupán zajos, de mellette az új technológiákhoz képest sokkal lassabb is, ráadásul jobban ki van téve bármilyen külső behatásnak, így arra a döntésre jutottunk, hogy érdemes lenne lecserélni egy SSD-re. A választás egy 240 GB-os SSD-re esik, mivel a munkához használt gépünkön nem tárolunk túl sok fájlt, és egyébként is fillérekért lehet manapság hozzájutni az 500 GB alatti flashmeghajtókhoz.

MEGJEGYZÉS

A fenti példában szereplő értékek tulajdonképpen nem bírnak különösebb jelentőséggel, és csak szemléletési célból tüntettük fel őket. A továbbiakban szereplő leírás mindaddig érvényes bármilyen eszközre, ameddig a kiindulási (forrás-) meghajtó nagyobb méretű, mint a célmeghajtó, emiatt pedig méretcsökkentésre van szükség. Az azonos gyártók azonos kapacitású és sorozatú eszközeit leszámítva egyébként általában nincs két pontosan ugyanolyan kapacitással rendelkező eszköz, azaz névlegesen azonos méret esetén is előfordulhat, hogy az egyik egy kicsit nagyobb a másiknál, így akár közel azonos méretű meghajtókat vásárolva is szembesülhetünk (kicsiben) a fenti problémával.

 

Természetesen az alábbiakban leírtak működnek HDD-ről HDD-re, vagy éppen SSD-ről SSD-re, de akár SSD-ről HDD-re történő klónozás esetén is. Annyi a lényeg, hogy az átméretezésre akkor van szükségünk, ha a kiindulási meghajtónk nagyobb a célmeghajtónknál. Fordított esetben elég csak a klónozást végrehajtanunk, és ha nem szeretnénk elvesztegetni a maradék helyet, akkor vagy létrehozhatunk egy újabb partíciót a fennmaradó helyből, vagy csökkentés helyett megnövelhetjük a partícióméretet a GPartedben vagy a Lemezkezelésben (ennek mikéntjét lásd alább).

Az alapvető eszközeink megvannak a költözéshez (vagy van elég bővítőhely a számítógépben ahhoz, hogy egyszerre legyen beszerelve a forrás- és célmeghajtó, vagy van külső USB-s adapterünk a célmeghajtó csatlakoztatásához), és hallottunk is mindenféle szuper windowsos adatklónozó eszközökről, amelyek csodákra képesek. De vagy szembesültünk már azzal, hogy ezek közül az ingyenesek általában csak beetetésre jók, vagy olvastuk az Ultimate Boot CD-ről szóló írást, amely bizonyított és profi, ráadásul ingyenes segédeszközök óriási kínálatával kecsegtetett. Mikor máskor lenne érdemes tenni velük egy próbát, ha nem ebben a helyzetben?

A forrásmeghajtó adatpartíciójának átméretezése

A fentiekben leírtaknak megfelelően tehát adottak a feltételek, azaz a számítógéphez van csatlakoztatva a forrásmeghajtó, a célmeghajtó, és elkészítettük az Ultimate Boot CD adathordozóját is (pendrive, CD stb.). Indítsuk is el a rendszert ez utóbbiról, majd a főmenüben válasszuk a Parted Magic lehetőséget. Miután elindult a rendszer, első lépésben kattintsunk duplán a Partition Editor (Partíciószerkesztő) parancsra, győződjünk meg arról, hogy a forrásmeghajtó van kiválasztva, és méretezzük át az adatainkat tartalmazó partíció(ka)t úgy, hogy a forrásmeghajtón található összes partíció mérete együttesen nem haladja meg a célmeghajtó méretét.

Ennek lépései:

1. A jobb felső sarokban a legördülő listából válasszuk ki a célmeghajtót. (Általában /dev/sdb, /dev/sdc, vagy valami hasonló névre hallgat, és a mérete, valamint a partíciói alapján tudjuk a legegyszerűbben beazonosítani, azaz egyrészt kisebb a forrásmeghajtónál, és ha újonnan szereltük be, akkor teljesen üres.)
2. Jegyezzük fel a teljes méretét. (Ezt zárójelben láthatjuk a neve után, a fenti képen látható példában 8,00 GiB.)
3. Válasszuk ki a forrásmeghajtónkat a legördülő listából. (Általában /dev/sda a neve, és számos partíció látható rajta, ha Windows 10-et tartalmaz, melyek közül több is ntfs fájlrendszerrel lett formázva.)
4. Válasszuk ki a legnagyobb, az adatainkat is tartalmazó partíciót, majd kattintsunk a Resize/Move (Átméretezés/Áthelyezés) gombra.
5. Ekkor megjelenik egy új ablak, amelyben a csúszka elhúzásával vagy a pontos érték beírásával megadhatjuk az új méretét. Akkora méretet kell megadnunk, hogy az átméretezést követően a forrásmeghajtón lévő összes partíció együttes mérete (ha csak egy megabájttal is, de) kisebb legyen a célmeghajtó méreténél (ezért kellett feljegyezni ennek értékét). Ha pontosan be szeretnénk lőni ezt az értéket, akkor egy számológép segítségével kell összeadnunk az egyes partíciók megjelenített értékét. Ha lazábban vesszük a dolgokat, nagyobb ráhagyással is dolgozhatunk, és akár a klónozás elvégzése után is visszanövelhetjük a partíciónk méretét.
6. Ha megvan a kívánt érték, akkor az Apply (Alkalmaz) gombra kell kattintanunk, és a művelet megerősítését követően máris elkezdődik az átméretezés. Ez a meghajtó méretétől, a csatlakoztatásának módjától és szabványától (belső, külső, SATA stb.), valamint az adatok mennyiségétől függően eltarthat egy kis ideig.

Az átméretezett partíció felismertetése és helyreállítása Windows 10 alatt

Ha mindezzel megvagyunk, akkor kattintsunk duplán a Quit (Kilépés) ikonra, és indítsuk újra a rendszerünket a forrásmeghajtóról elindítva a Windows 10-et.

Nyissuk meg a Fájlkezelőt, válasszuk az Ez a gép lehetőséget, és kattintsunk a jobb gombbal a helyi lemezünkre. A Tulajdonságok párbeszédablakban válasszuk az Eszközök lapot, majd kattintsunk az Ellenőrzés gombra a Hibaellenőrzés alatt. Ha a rendszer azt jelzi, hogy nem talált problémát, mi akkor is ragaszkodjunk az ellenőrzés és javítás lefuttatásához. Ennek végrehajtásához újraindítást fog kérni a rendszer, így ezt hagyjuk jóvá.

Az újraindításkor lefut a chkdsk, és kijavítja az átméretezésből fakadó eltéréseket, majd elindítja a rendszert.

FONTOS!

Ezt a lépést kihagyva a klónozás folyamata meghiúsulna, mivel a Clonezilla észlelné a másolás során, hogy egy hibás fájlrendszert próbálunk meg új helyre átmozgatni.

Alternatív lépés: a Lemezkezelés használata az átméretezéshez

Ha valaki nagyon idegenkedik a GParted használatától, tulajdonképpen használhatja a Windows 10 beépített eszközét, a Lemezkezelést is. Ezzel az eszközzel ugyanúgy lecsökkenthetjük a partíciónk méretét, és ezt követően nem kell külön elindítanunk a helyreállításhoz a chkdsk eszközt. Ennek lépései:

1. Nyomjuk le a Windows + R billentyűkombinációt.
2. A Futtatás ablakba írjuk be a diskmgmt.msc kifejezést, majd kattintsunk az OK gombra. (Az alkalmazás futtatásához rendszergazdai jogokra lesz szükségünk.)
3. Az ekkor megnyíló Lemezkezelés ablakban válasszuk ki az adatainkat tartalmazó partíciót, kattintsunk rajta a jobb egérgombbal, majd válasszuk a Kötet zsugorítása lehetőséget.
4. Adjuk meg a kívánt méretet megabájtban (ennek kiszámításához lásd a fent leírtakat), majd nyomjuk meg a Zsugorítás gombot.

A forrásmeghajtó klónozása a célmeghajtóra

Most már minden adott ahhoz, hogy megkezdjük a másolási folyamatot, úgyhogy indítsuk el újra a rendszerünket az Ultimate Boot CD-t használva, és a menüből ismételten válasszuk a Parted Magic lehetőséget. A rendszer elindulása után azonban most a Disk Cloning (Lemez klónozása) ikonra kell duplán kattintanunk a Clonezilla elindításához. Ez egy nagyon hatékony és kifejezetten sokoldalú eszköz, amely számos dologra képes, viszont csak ASCII-szöveges felülettel rendelkezik. Megijednünk ettől még nem kell. Nézzük, pontosan milyen lehetőségeket kell kiválasztanunk a lemezünk klónozásához:

1. Az első választási lehetőségnél a device-device (eszközről eszközre) / disk_to_local_disk (helyi lemezről helyi lemezre) lehetőséget kell kiválasztanunk, ugyanis egy helyi lemezt szeretnénk egy másik helyi lemezre átmásolni.
2. Ezt követően ki kell választanunk a forráslemezünket (source disk), valamint a céllemezünket (destination disk), továbbá meg kell adnunk az -sfsck (Skip checking/reparing source file system) és az EXPERT mode beállítást (ugyanis nem azonos méretű a két lemez, és emiatt speciális beállításokat kell majd megadnunk ahhoz, hogy a művelet ne hiúsuljon meg).

3.  Az „on-the-fly advanced extra parameters” képernyőn az alapértelmezés szerint csillaggal bejelölt lehetőségeken felül az -icds paraméter mellé kell csillagot tennünk. Ezzel gondoskodhatunk arról, hogy a folyamat futtatása ne álljon le akkor, amikor a program észleli a méretbeli különbséget.

4.  Az „advanced extra parameters” képernyőn pedig a -k1 paramétert kell kiválasztanunk ahhoz, hogy megfelelő módon jöjjön létre a célmeghajtón a partíciótábla.

5.  Ezt követően a szöveges parancsfuttatás során már csak néhányszor jóvá kell hagynunk a műveletet, és máris kezdetét veszi a klónozási művelet. Ennek befejezése percekig vagy akár órákig is eltarthat, attól függően, hogy mekkora méretű lemezekről van szó, és milyen technológiával lettek csatlakoztatva.

Utolsó simítások 

Most, hogy van két azonos tartalmú lemezünk, már csak meg kell cserélnünk a kettőt, azaz véglegesen be kell szerelnünk az újonnan beüzemelt SSD-t, a régit pedig kiszerelni. (Vagy akár meg is tarthatjuk adattárolási célból, ha a zajos működése nem zavar minket.) Ha a régi merevlemezre már nincs szükségünk, akkor érdemes a tartalmát véglegesen törölni. Ha minden műveletet sikerült elvégeznünk, akkor most már sokkal gyorsabban fog betölteni a rendszerünk és a rajta lévő alkalmazások is. Mivel csak a merevlemezt cseréltük ki a rendszer alatt, így a Windows 10 újraaktiválásával nem kell foglalkoznunk, ugyanis nem történt lényegi hardverváltozás.

Alternatív lépés: a klónozás után fennmaradó szabad hely felhasználása

Amennyiben lazán vettük a dolgokat, és maradt némi felesleges szabad hely a klónozást követően, akkor mind a Lemezkezelés, mind a GParted használatával megnövelhetjük a partíciónk méretét. Ehhez csupán arra van szükség, hogy a fentiekben ismertett lépéseket követve nem kisebb, hanem nagyobb méretet adunk meg a partíció átméretezésekor. (Windows 10-es partíció GParteddel történő átméretezésekor újfent kötelező a chkdsk futtatása.)

Ha esetleg fordított volt a forrás- és célmeghajtó mérete, mint a kiindulási példánkban, akkor ugyanígy tehetjük meg, hogy a már klónozott meghajtónál megnöveljük az adatpartíció méretét, vagy akár új partíciókat is létrehozhatunk, ha éppen erre lenne szükségünk. (Például ha egy 250 GB-os meghajtóról egy 1 TB-osra helyeztük át a rendszerünket, akkor előfordulhat, hogy külön partíciókat szeretnénk létrehozni az adatainknak.)

Titkosított meghajtók klónozása

Ha valaki figyelembe vette a titkosításra vonatkozó ajánlásainkat, és titkosítással látta el a meghajtóját, „apróbb” akadályokba ütközhet a fenti lépések elvégzése során. Általános ökölszabály, hogy a partíciók átméretezésekor és a klónozáskor érdemes a lépések végrehajtása előtt visszafejteni, és ideiglenesen kikapcsolni a titkosítást, ugyanis ha véletlenül bármilyen hiba következne be a műveletek futtatása közben (például áramkimaradás történik a partíció átméretezése során), könnyen előfordulhat, hogy az adatok helyreállításának legnagyobb akadályává pont a titkosítás válik.

Arról nem is beszélve, hogy titkosított meghajtó esetén a szabad lemezterület is a titkosítás hatókörébe esik, így gyakorlatilag a hasznos adat és a szabad lemezterület nem sokban fog eltérni egymástól, és a Clonezilla által nyújtott előnyökkel sem tudunk élni. A dd parancs használatával ettől még lehetőségünk nyílik a klónozás végrehajtására (amennyiben a /dev/sda jelöli a forrásmeghajtót, a /dev/sdb pedig a célmeghajtót):

sudo dd if=/dev/sda of=/dev/sdb

De ez a módszer gyakorlatilag inkább csak biztonsági mentési célokra alkalmas, hiszen a szektorok szintjén másolja át az egyik meghajtó tartalmát a másikra.

Számos okból merülhet fel az igény merevlemezeink vagy más háttértáraink tartalmának végleges és biztonságos törlésére. Ilyen ok lehet, ha értékesíteni szeretnénk a laptopunkat, számítógépünket, vagy csak magát az alkatrészt, illetve ha véglegesen le szeretnénk selejtezni, ám előtte meg szeretnénk bizonyosodni arról, hogy semmilyen bizalmas adat (pl. jelszavak, képek, szerződések, levelezés stb.) sem marad rajta. Ha valamivel, a digitális adatokkal kapcsolatban bizton kijelenthetjük, hogy sosem lehetünk elég óvatosak. Ugyan sokan ilyenkor szét szokták szerelni a merevlemezeket, vagy éppen beteszik egy kis időre a mikrohullámú sütőbe, ám egyrészt ezektől a módszerektől sokan idegenkednek, másrészt pedig hallottunk már olyat is, hogy egy tűzkárból kimentett, félig-meddig folyós állagúra olvadt merevlemezről még sikerült adatokat kinyerni. Szóval sokat nem veszíthetünk azzal, ha még működőképes állapotában is végrehajtunk egy teljes adattisztítást.

Miért nem elég csak az operációs rendszerben törölni az adatokat?

Bár az adatbiztonsági szakértők hosszú évtizedek óta hangoztatják, ennek ellenére még mindig vannak, akiket meglepetésként ér, ha szembesülnek a ténnyel: amikor a törlés parancsot kiadjuk a rendszerünkben, azzal nem távolítjuk el végérvényesen az adatokat a háttértárolóról. Ennek az egyik kényelmi oka az, hogy amennyiben minden egyes alkalommal teljes és végleges törlést hajtana végre a rendszer, akkor érezhetően sokkal lassabb lenne a működése, a másik ok pedig a mögöttes tároló fizikai felépítésében és működésében keresendő. A digitális adataink ugyanis amolyan „lenyomatot” hagynak az eszközökön, így a törlésük után is „emlékszik rájuk” a háttértár, egészen addig, amíg felül nem írjuk más adatokkal.

Ennek részleteibe most nem mennénk bele jobban, elég annyit tudnunk, hogy a végleges törléshez plusz erőfeszítéseket kell tennünk, és ezt követően is érdemes új adatokkal felülírni a tároló érintett részét ahhoz, hogy véglegesen eltüntessük a korábbi adatok utolsó nyomát is. Ha valaki szeretne kicsit utánajárni a jelenleg elérhető technológiáknak, érdemes a Háttértárakat ismertető Wikipédia-cikkel kezdenie, és aztán mélyebbre ásni a témában.

Az adatok törlése Linuxon

Linux rendszer használata esetén több lehetőség is a rendelkezésünkre áll, amennyiben törlésre szánjuk el magunkat. Az egyik ilyen a shred használata.

shred -zvu -n 5 <fajlnev.kiterjesztes>

Ezzel a paranccsal 5 alkalommal lesz a fájl felülírva a törlését követően. Ha csak egy-egy fájltól szeretnénk így megszabadulni, akkor ez a legjobb módszer erre. Az elérhető lehetőségekkel kapcsolatban további információt a man shred parancs kiadását követően kaphatunk.
A másik lehetőség a wipe használata.

wipe -rfi <konyvtar>/*

Ez a parancs azonban csakis és kizárólag merevlemezek esetén működik, így SSD-k vagy pendrive-ok és memóriakártyák esetén NE ezt válasszuk. Az elérhető lehetőségekkel kapcsolatban további információt a man wipe parancs kiadását követően kaphatunk.
Amennyiben konkrétabb feladatokra keresünk megoldásokat, érdemes telepíteni a secure-delete csomagot, amelyben elérhető az srm parancs a fájlok és könyvtárak törléséhez, az sfill parancs, amely a szabad tárhely biztonságos törlésére szolgál, továbbá Linuxon szintén a rendelkezésünkre áll az sswap parancs a swapként használt kötethez, illetve az sdmem, amely a memóriából (RAM) távolítja el az adatokat.

Amennyiben a teljes rendszert szeretnénk nyom nélkül eltüntetni, akkor viszont már egy külső eszközről kell elindítanunk az ehhez szükséges segédprogramokat.

Hányszor kell felülírni az adatokat a végleges eltüntetésükhöz?

HDD, azaz merevlemez használata esetén az alapértelmezett algoritmusokkal 3 felülírás (pass) bőven elegendő a maximális biztonság eléréséhez. Igazából a legtöbb kormányzati szerv és műszaki szaki az utóbbi időben azt hangoztatja, hogy akár 1 felülírás is elegendő lenne, de ha valaki meg akarja nyugtatni magát, tegyen rá még két kört. Ennél több újraírás nem fogja növelni a biztonságot, viszont komolyan igénybe veheti a merevlemezt, és akár működésképtelenné is teheti. Ha a későbbiekben még használni szeretnénk, akkor semmiképpen se lépjük túl ezt a számot.

SSD esetén egy felülírás is bőven elegendő (amennyiben az eszköz támogatja az SSD-k biztonságos törlését, erről bővebben lásd fentebb), de ha meg akarjuk nyugtatni magunkat, akkor állítsuk be 2-re ezt az értéket. 

Hogyan segíthet az adatok titkosítása az „eltüntetésükben”?

A fentiekben leírt lépéseken túl sokat segíthet az, ha a kényes és bizalmas adatokat titkosított formában vagy éppen titkosított köteten tároljuk. Ez nem csupán azért jár előnyökkel, mert akkor is védelemmel látja el az adatokat (pl. az eszköz fizikai ellopása vagy elvesztése esetén), amikor még használatban vannak, hanem azért is, mert ha a titkosított adatokat részben vagy egészben ki is nyeri valaki egy háttértárról, attól még a titkosítást ugyanúgy vissza kell fejtenie. És minél kevesebb részét sikerült megszereznie ezeknek a maradványadatoknak, annál kisebb az esély arra, hogy sikerrel tud járni.

Manapság a telefonokon és táblagépeken vagy alapértelmezés szerint engedélyezve van a teljes rendszerkötet titkosítása, vagy a PIN-kód vagy egyéb azonosítási eljárás bekapcsolásakor lehet aktiválni. Egy könnyen mozdítható és eltulajdonítható, számos személyes adatot és fontos alkalmazást tartalmazó eszköz esetén nincsenek kifogások, a titkosítást muszáj használni! Egyedül arra kell ügyelnünk, hogy a fontosabb adatokról rendszeresen biztonsági mentést készítsünk a felhőbe vagy egy másik biztonságos helyre, ezt azonban más esetben is érdemes megtennünk. Ha azonban követjük az ajánlott eljárásokat, akkor arra az esetre is bebiztosítjuk magunkat, ha elfelejtenénk a jelszót vagy a PIN-kódot, ha ellopják vagy elveszítjük a készüléket, illetve ha az élettartama végén le szeretnénk selejtezni.

Windowsos gépeken sajnos a lemeztitkosítás általában nem képezi az operációs rendszer részét, lévén a Windows Pro verziótól kezdve érhető csak el a BitLocker lemeztitkosítás. Pedig kifejezetten hasznos eszköz, amely ráadásul teljesen automatikusan működik, és a gépünk beépített biztonsági (TPM) chipjével is kompatibilis, így megkerülni sem könnyű. Akinek számít az adatok biztonsága, főleg egy hordozható eszköz, például egy laptop esetén, annak nem érdemes spórolnia a Pro verzión. Szerencsére Home verzióról nagyon egyszerűen áttérhetünk a magasabb szintre, ennek lépései megtalálhatók a Microsoft oldalain. Vannak külső gyártóktól érkező megoldások is, ám ezek sosem fogják elérni ugyanazt a biztonsági és kompatibilitási szintet, mint a Microsoft saját megoldása, ezért ezekre itt most nem is térnénk ki.

macOS-gépeken a lemeztitkosítási technológia neve a FileVault, és hasonlóan működik a Microsoft megoldásához. A hivatkozással elérhető útmutató lépéseit követve lehet be- vagy kikapcsolni.

Linuxos gépeken a rendszer telepítésekor választhatjuk, hogy az egyes kötetek titkosítva legyenek-e, vagy pedig csak a felhasználói könyvtárak tartozzanak a titkosítás hatálya alá. A titkosításra vonatkozó döntést később is meghozhatjuk, ám ebben az esetben már parancssori eszközök segítségével kell majd a feladatot elvégeznünk. Arra érdemes ügyelnünk, hogy az ilyen módon titkosított felhasználói könyvtárak csak akkor olvashatók be (az ecryptfs-recover-private parancssori eszköz használatával), ha Linux rendszert indítunk.

Kaphatók beépített hardveres titkosítással rendelkező pendrive-ok is, és dönthetünk úgy is, hogy a fájljainkat különböző alkalmazások (pl. tömörített állományok) segítségével jelszóval védjük. Ám azt mindig érdemes szem előtt tartani, hogy a rendszer részét képező titkosításhoz képest ezek csak alacsonyabb szintű vagy korlátozott kiterjedésű védelmet nyújtanak.

Ökölszabályként érdemes figyelembe venni, hogy minél jobb titkosítást veszünk igénybe, annál kisebb az esélye, hogy mi magunk hozzáférjünk a saját adatainkhoz, ha esetleg már nem rendelkezünk a titkosítás visszafejtéséhez használt azonosítóeszközzel (például egy jelszóval vagy PIN-kóddal), viszont ha nem elegendő a biztonsági szint, akkor mások is játszi könnyedséggel visszafejthetik a bizalmas adatokat. Érdemes mérlegelni a titkosítandó adatok bizalmassági szintjét, és ennek megfelelően kiválasztani a titkosítási módot, ám alapesetben a legjobban az egyes rendszerek beépített titkosítási megoldásával járunk majd a legjobban.

Egy szerver rendszergazdai feladatainak ellátása elég összetett feladatot jelent, hiszen rengeteg paramétert kell szem előtt tartani, számos szolgáltatást kell összehangolt módon működtetni, és időről időre olyan változásokat kell életbe léptetni, mint új felhasználók vagy webhelyek felvétele, illetve régebbiek törlése. És akkor még nem is beszéltünk az egyes kritikus riasztásokról, például akkor, ha elfogyott a memória vagy egy szolgáltatás leállt, vagy a rendszerfrissítések automatikus telepítéséről. 

Pontosan ilyenkor jönnek jól a webes vezérlőpultok, melyek közül a legismertebbek a Plesk, az ISPConfig, illetve a cPanel. Mi az utóbbival most nem foglalkozunk, mivel munkánk során nem sűrűn találkozunk vele, lévén nem támogatja az általunk előnyben részesített linuxos disztribúciót (Ubuntu), ám az első két választási lehetőség is tökéletesen elegendő ahhoz, hogy lefedjük majdnem a teljes spektrumot. Azonban azt nem árt szem előtt tartani, hogy a két termék teljesen más megközelítést nyújt, és bár a végeredményt tekintve ugyanazt teszik – felügyeletet és monitorozást nyújtanak a kiszolgálónkhoz –, kissé eltérő célközönség számára készültek. Az alábbiakban sorra vesszük azokat a szempontokat, amelyeket érdemes figyelembe venni a számunkra ideális megoldás kiválasztása során.

Mire jó egy webes vezérlőpult?

Elsőként érdemes azt tisztázni, milyen célra szolgál egy ilyen termék (nem csupán az általunk most ismertetett kettő, hanem gyakorlatilag az összes hasonszőrű megoldás), illetve milyen műveleteket lehet automatizálni a segítségével. Általánosságban elmondható, hogy mindegyik képes az alábbi alapfeladatok ellátására:

• Webhelyek és domainek (DNS) kezelése, HTTPS-kapcsolat (SSL-tanúsítványok beszerzésének, megújításának és kezelésének) biztosítása
• Felhasználók, webhelyek, adatbázisok, FTP-kapcsolatok és egyéb elérések hozzáadása, módosítása és törlése
• Kvóták érvénybe léptetése (azaz pl. a tárhelyhasználat vagy a hálózati forgalom mennyiség- és időalapú, pl. havi korlátozása)
• E-mail-címek teljes körű kezelése (hozzáadás, módosítás, átirányítás, eltávolítás)
• Adatbázisok kezelése (létrehozás, módosítás, törlés, hozzáférések beállítása)
• Spamszűrés és más biztonsági funkciók biztosítása a szerver védelméhez
• A kiszolgáló állapotának figyelése és értesítések küldése bizonyos rendszeresemények vagy hibák bekövetkezésekor

Ki a célközönség?

Érdemes szem előtt tartani, hogy mindegyik webes vezérlőpult rendszergazdáknak, és nem végfelhasználóknak készült. Egyrészt nem helyettesítik a rendszer alapos ismeretének meglétét, másrészt pedig ugyanúgy működésképtelenné tehetjük vele a szerverünket, mint amikor valaki a parancssorban ad ki parancsot egy visszavonhatatlan műveletre. Gyakorlatilag úgy kell elképzelnünk, mint a legtöbb felhasználói felületet – ugyanazokat a feladatokat tudjuk elvégezni, mint a parancssorban, csak éppen kapcsolókkal, legördülő menükkel és számos automatizált könnyítéssel. Talán egy kicsit kisebb a hibázás lehetősége, hiszen a nagyon rossz beállítási kombinációkra felhívják a figyelmünket, az igazán végzeteseket pedig végrehajtani sem tudjuk, de minden más tekintetben szinte teljes vezérlést kapunk a szerverünk beállításai felett.

Azt is fontos tudni, hogy ezek a rendszerek elsődlegesen azoknak nyújtanak segítséget, akik több felhasználót, webhelyet, adatbázist és e-mail-címet kezelnek. Azoknak nem sokban könnyítik meg az életét, akik egyetlen gépen egyetlen webhelyet állítanak be, majd gyakorlatilag a rendszerfrissítések telepítésén kívül hozzá sem akarnak nyúlni ahhoz. Egy-két dolog automatizálásával ugyan előnyökhöz juthatnak, de ha havonta 2-3 parancssori parancsot kell csak kiadniuk, akkor könnyedén érezhetik azt, hogy felesleges volt ezért a webes felülethez folyamodniuk. Akinek azonban több felhasználója, ügyfele, webhelye és adatbázisa, valamint rengeteg e-mail-címe van, áldásként tekinthet arra, hogy ezek kezelését a több helyen történő manuális adminisztrálás helyett csupán pár kattintással elvégezheti.

A számítástechnikában (és az élet számos területén) vannak klikkesedések és egymással szemben álló felek. Természetesen itt is találkozhatunk olyannal, aki erre vagy arra a termékre esküszik, és a véleménye szerint minden más használhatatlan hulladék vagy felesleges pénzkidobás. A valóság azonban ennél sokkal árnyaltabb, kicsit ahhoz hasonlatos, mint az Android és az iOS esete. Mindkettő operációs rendszer teljes mértékben ellátja a feladatát, lehet a segítségével telefonálni, SMS-t küldeni, naptárat használni és különböző alkalmazásokat futtatni, mégis alapvetően kicsit más elképzelést szem előtt tartva lettek felépítve. Az iOS szereti vezetni a felhasználók kezét, és feltételezi, hogy a rendszer biztonságát és mélyebb működését illetően jobban tudja, mi a jó a használójának, míg az Android nagyobb teret enged a testreszabásoknak, és mélyebb szinten módosíthatja a felhasználó annak működését.

Ha ezt az analógiát követjük, akkor a Plesk az iOS-nek felel meg, ugyanis nem szereti, ha felülbíráljuk a webes felület beállításait, és inkább az általa javasolt módszerek használatát részesíti előnyben az egyedi megoldásokkal szemben, cserébe viszont a szűkebb választási lehetőségeknek hála könnyebben képes gondoskodni a rendszer integritásáról és problémamentes működéséről. (Érdemes kihangsúlyozni, hogy itt a teljes rendszerről van szó, a webhelyeket ugyanúgy 2 kattintással működésképtelenné teheti bárki, ha rossz beállításokat ad meg az adminfelületen.)

Az ISPConfig pedig inkább az Androidra hasonlít, mivel nagyobb teret enged a felhasználó egyéni megoldásainak, viszont bizonyos pontokon szigorúan megköveteli bizonyos iparági sztenderdek betartását. Emiatt lehet az, hogy utóbbinál először telepítenünk kell A tökéletes Ubuntu szervert, és konfigurálnunk kell számos dolgot, majd csak ezt követően ültetjük mindennek a tetejére az ISPConfigot. (Ehhez képest a Plesket egy tiszta telepítést (vagy egy VPS létrehozását) követően már rögtön üzembe helyezhetjük, és minden beállítást már a webes felületen adhatunk meg.) Ez viszont óriási előny lehet azoknak, akik nem szeretik, ha megkötik a kezüket, viszont mégis szeretnék élvezni az automatizálások és az átfogó rendszerfelügyelet előnyeit.

Leegyszerűsítve a kérdést mondhatjuk, hogy a Plesk a kényelmesebb vagy a kevesebb egyedi megoldást használó rendszergazdáknak készült, míg az ISPConfig inkább a tapasztaltabb és a kezük bepiszkolásától nem ódzkodóknak.

Fontos szempont még az árképzés, ugyanis ez is döntő szempont lehet a választásnál. A Plesk havi (vagy éves) licencdíj ellenében vehető igénybe, amely szerverenként fizetendő, és lépcsőzetesen növekszik attól függően, hogy a szolgáltatások teljes körét szeretnénk-e igénybe venni, vagy csak egy részhalmazát. Az ISPConfig viszont egy teljesen ingyenes, nyílt forráskódú szoftver, és csupán a részletes dokumentáció beszerzéséért kell egy névleges támogatási összeget kifizetnünk. (A rendszer használatát e nélkül is el tudjuk sajátítani, mi azonban minden ügyfelünk után meg szoktuk venni a dokumentációt, hogy ezzel is támogassuk a készítőjét és a jövőben kiadandó fejlesztéseket.) Sokhelyütt olvashatunk olyan véleményeket, hogy ennek megfelelően alakul a terméktámogatás, azaz a support kérdése is, avagy a fizetős termék mögött egy teljes ügyfélszolgálati rendszer áll, az ingyenesnél viszont a kérdéseinkre a legkönnyebben fórumokat bogarászva vagy a készítőnek küldött e-mailre érkezett válasz útján kaphatunk választ. Ezt a tévhitet itt és most megcáfolnánk, mert bár való igaz a kettő közötti jelentős különbség, az ISPConfig közössége kifejezetten aktívnak mondható, és a készítő is minden megkeresésre szívesen és készségesen reagál (bár előbb érdemes megnézni a korábban már feltett kérdéseket és a dokumentációt, mivel a legtöbb kérdésünkre már ott a válasz), így gyakorlatilag semmilyen hátrányba nem kerülünk a fizetős szoftverekkel szemben.

Milyen főbb elönyei és hátrányai vannak a Plesknek és az ISPConfignak?

A legjobban talán táblázatos formában lehet áttekinteni az eddig leírtakat:

Van-e átjárhatóság a különböző rendszerek között?

A jó hír és a rövid válasz az, hogy igen, de természetesen vannak bizonyos megkötések. A Plesk a cikk írásának pillanatában a következő rendszerekről teszi elérhetővé a migrálást:

• korábbi Plesk-verziók (Linux és Windows egyaránt)
• cPanel
• Confixx
• Helm
• Parallels Pro Control Panel
• DirectAdmin

Mint jól látható, az ISPConfig nem szerepel a lehetőségek között, és talán nem véletlenül. A használata során ugyanis megannyi egyéni módosítás történik a rendszeren, és ezt elég nehéz lenne átültetni a Pleskbe (jelentős részük az áttelepítés során egyszerűen elveszne, és az alapértékre állna át). Meg ahogy korábban írtuk, a mögöttes filozófia is teljesen más.

Az ISPConfig a cikk írásának pillanatában a következő rendszerekről teszi elérhetővé a migrálást:

• korábbi ISPConfig-verziók
• Plesk 10-12.5
• Plesk Onyx
• cPanel
• Confixx 3

Itt egy kicsit jobb már a helyzet, tehát Pleskről például könnyedén áttérhetünk ISPConfigra, de a cPanel is támogatott. Hátulütője a dolognak, hogy ehhez meg kell vásárolnunk az ISPConfig Migration Toolkitet, amely viszont egyben tartalmazza a migráláshoz szükséges kódot és az ISPConfig-szerverek üzemszünet nélküli áthelyezéséhez szükséges ISPCopy eszközt is. Ennek ára jelenleg 59 euró, ami még mindig messze elmarad a Plesk (vagy bármely másik vezérlőpanel) éves licencdíjától.

A támogatott nyelvek listája

Még egy fontos szempontot érdemes figyelembe venni a választás során, és ez a támogatott nyelvek listája. Szerencsére mindkét termék elég jól áll ezen a téren, ugyanis mind az ISPConfig, mind a Plesk számos nyelven beszél, többek között magyarul is tud mindkettő. És hogy ez miért is olyan különösen fontos?

Bár feltételezhetjük, hogy a rendszergazda tud angolul (legalább olyan szinten, hogy egy ilyen webes felületen el tudja végezni a szükséges feladatokat), ezeknek a termékeknek az egyik fő előnyük, hogy a saját webhelyeik menedzselését rábízhatjuk az ügyfelekre is. Azaz például a segítségükkel módosítani tudják a webhelybeállításokat, az e-mailes dolgaikat, vagy éppen kezelni tudják a DNS-eiket. És mindig szigorúan csak olyan keretek között, amit mi a kvótájuknál beállítottunk.

Gondolom, az önkiszolgáló felület használatának előnyeit nem kell részleteznünk (főleg olyankor, ha egy ügyfélhez több domain is tartozik, ráadásul hetente szeretne új e-mail-címeket létrehozni), de persze, ehhez az is szükséges, hogy az ügyfél tisztában legyen azzal, milyen műveletet végez éppen a felületen, ellenkező esetben csak a telefonhívásokat kapjuk majd, hogy sürgősen orvosoljuk az elérhetetlen webhelyük problémáját.

Az ISPConfig által támogatott nyelvek listája itt érhető el.