Karácsony és az ufók

Lassan jönnek az ünnepek, elcsendesednek a munkahelyek, a szervezetünk is elkezd felkészülni a közeljövőben bevitt több kiló cukor lebontására… Általában ez az időszak egybeesik azzal, amikor eszembe jutnak azok a dolgok amiket mindig is szerettem volna, de valamiért sose jutott rá idő.

Most se történt ez másként, elővettem a Steam library-mat és elkezdtem lapozgatni. Meg is akadt a szemem az XCOM: Enemy Unknown-on, amit már lassan 10 éve tárolok, minden gépemre lelkesen feltelepítem, van róla emlékem, hogy zseniális játék, és valamiért sose jutottam a végére.

De hát mikor, ha nem most, fel is készültem a maratoni játék session-re, letöltöttem, rányomtam hogy play, és…

Türelmes voltam, elviekben a Laser Squad-ra is várni kellett amíg betöltött a disk-ről, de ez nagyon nem akart betölteni.

Az ember ilyenkor nem esik kétségbe, gyorsan be is írtam a keresőbe. XCOM updating executable. És mit találtam? Kétségbeesett embereket redditen:

És mérges embereket a steam review-k alatt:

Meg egy csomó hülyeséget.

Kipróbáltam a laptopon is, ott elsőre elindult, és ez volt az a pont, ahol éreztem, hogy ez a játék már megint másról fog szólni, mint a földet megszálló idegenek lövöldözéséről. Pedig eskü nem én keresem a bajt, egyszerűen csak mindig én nyúlok bele ezekbe a csodás dolgokba.

Azért nem nagyon szoktam megrettenni ha valami nem megy, de nem akartam rögtön azzal kezdeni, hogy darabjaira szedem a játékot, így jöttek a szokásos dolgok, mint a process explorer, process monitor.

Az már a probléma legelején nyilvánvalóvá vált, hogy itt nem windows, directx, és egyéb dolgokról lesz szó. Az alkalmazás ugyanis egy launcher-el indul.

Mivel már ez se indul el, nagyon nem kellett nyomozni. Első körben kizártam az internetet, kipróbáltam, hogy net nélkül is elindul-e, elindult. Aztán kimásoltam onnan és megnéztem mi a minimális dolog amivel már elindul. Ez egyébként az alábbi 3:

XCOMLauncher.exe steam_api.dll SteamQuery.dll

A launcher – steam kommunikáció működött, bárhonnan indítottam, láttam a steam-en, hogy indul. Végül szétkaptam az egész XCOM launchert, gondoltam biztos abban van valami turpisság, de nem kimondottan egy bonyolult dolog, és ha kikötöttem belőle a steam api hívásokat simán működött. Szóval egyre inkább a Steam és VALVE felé terelődött a gyanú.

Persze néztem disk használatot, hálózati forgalmat, összenéztem a Steam összes app-hoz kapcsolódó konfigurációs fájlát (abból vissza is alakítottam párat a valve vdf formátumáról) de csak nem találtam annak az okát, hogy miért nem indul el, vagy hogy más státuszban lenne a telepítés mint a másik gépen, ahol meg elindul.

Végül eljutottam oda, hogy diff-eltem a két app könyvtárat, mert már tényleg csak arra tudtam gondolni, hogy ott tér el valami (bár mi, hiszen mindkettőt az internetről töltöttem). És meglepő módon két eltérés volt. A két exe fájl.

Amikor egy exe fájl vége tér el (és egy picit az eleje), meg egy képernyőn 2-nél többször szerepel a cert szó, nem nehéz dolog kitalálni, hogy mi a különbség a két bináris között. Bizony a működőt valaki digitálisan aláírta.

És tényleg. A Steam úgy tűnik letölti az alkalmazás binárisát aláírás nélkül, majd első indításnál a kliens oldalon digitálisan aláírja. Ha éppen tudja. Gondolom terheltek lehetnek a szerverek, vagy esetleg olyan balgák, hogy a teljes binárist feltöltik aláíásra, nem csak a hash-t, fene se tudja. De mindenesetre nekem sokszori próbálkozásra se sikerült aláíratnom vele az exe-t, még azon a gépen se amin egyszer már aláírta őket sikeresen.

Én nem nagyon értem, hogy a kliens oldali aláírásnak mi értelme, alapból miért nem aláírva tölti le, meg ha kicsit jobban belegondolunk ebbe, akkor én abban se vagyok biztos, hogy ne tudnék vele bármit aláíratni, de hát ők tudják mit csinálnak. Egyszer lehet utána nézek ennek, de a steam nem annyira izgi, fene se akar turkálni benne.

Mindenesetre amíg ezt a problémát nem oldják meg, feltöltöttem az aláírt exe-ket, így talán másoknak még megadatik az esély, hogy megmentsék a világot a gyilkos űrlények támadásától.

Köszi valve a játékot, az aláírt exe-k pedig mindenkinek aki szereti (2027-ig jók):

https://drive.google.com/file/d/1kQuVI4twFprei5klS_pLiV5-wzj5Xh6e/view?usp=sharing

Egy alaplap halála

A napokban a clusterből az egyik gép elkezdte az alábbi hibákat írni:

Nov 20 11:00:03 pve000 kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
Nov 20 11:00:03 pve000 kernel: ata4.00: BMDMA stat 0x26
Nov 20 11:00:03 pve000 kernel: ata4.00: failed command: READ DMA EXT
Nov 20 11:00:03 pve000 kernel: ata4.00: cmd 25/00:f8:08:12:00/00:01:00:00:00/e0 tag 0 dma 258048 in
         res 51/84:57:a9:13:00/84:00:00:00:00/e0 Emask 0x30 (host bus error)
Nov 20 11:00:03 pve000 kernel: ata4.00: status: { DRDY ERR }
Nov 20 11:00:03 pve000 kernel: ata4.00: error: { ICRC ABRT }
Nov 20 11:00:03 pve000 kernel: ata4: soft resetting link
Nov 20 11:00:03 pve000 kernel: ata4.00: configured for UDMA/133
Nov 20 11:00:03 pve000 kernel: sd 3:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
Nov 20 11:00:03 pve000 kernel: sd 3:0:0:0: [sdb] tag#0 Sense Key : Aborted Command [current] 
Nov 20 11:00:03 pve000 kernel: sd 3:0:0:0: [sdb] tag#0 Add. Sense: Scsi parity error
Nov 20 11:00:03 pve000 kernel: sd 3:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 00 00 12 08 00 01 f8 00
Nov 20 11:00:03 pve000 kernel: I/O error, dev sdb, sector 4616 op 0x0:(READ) flags 0x80700 phys_seg 59 prio class 0
Nov 20 11:00:03 pve000 kernel: ata4: EH complete

Ez azért nem jelent semmi jót, azt hittem a disk hiba, aztán kábel hiba, míg végül eljutottam odáig, hogy ez valószínű alaplap hiba. Nem kimondottan kavart fel a dolog, általában régi hw-t használok szervernek, ez is egy kidobott, majdnem 20 éves gép. 3000 forint hozzá egy alaplap, vettem is egyet gyorsan, de gondoltam mielőtt kidobom, ránézek. Azonnal feltűnt, hogy a South Bridge mellett az egyik elektrolit kondenzátor púpos. Ezt pedig már az arcade gépek óta tudom, hogy nem jelent semmi jót, meg a south bridge amúgy is I/O-val foglalkozik, szóval duplán kezdett gyanús lenni a dolog.

Gondoltam ennyi effort még belefér, úgy sincs nagyon mit vesztenem, a megfelelő eszközök meg rendelkezésre állnak, kicserélem gyorsan.

A csere után pont olyan mintha semmi se történt volna, az alaplap alján barnult meg egy kicsit a lakk, de legközelebb lehet azt is kimaszkolom ha ilyet tervezek.

A gyors teszt után megszűnt a hiba, tényleg kár lett volna kidobni egy alaplapot ezért a 200 forintos alkatrészért.

P mint performancia (és mint PHP)

Néha úgy hozza a sors, hogy az embernek be kell piszkolnia a kezét. Apache-al, PHP-val, és mindennel ami ezzel jár.

Egy web szerver készítése általában egyszerű feladat.

apt install apache2
apt install php

A bonyodalmak általában ez után következnek, mivel ami ez után történik produkcióban az meglehetősen lassú, és erőforrás igényes. Mint régi új szerver tulajdonos meglepődve konstatáltam, hogy egy normális weboldal betöltése eltart 3 másodpercig, ami bár nem sok idő (főleg egy kazettás töltéshez képest a c64-en), de általában ezzel már nem vagyok túl elégedett.

Hogy ez ne így legyen ahhoz az alábbi dolgokat kell tenni:

Kezdjük az apache-al, ami alapesetben preforkol, de az lassú, főleg ha virtualizált környezetekről van szó, célszerűbb előre létrehozni kiszolgáló szálakat, és thread-eket. Ehhez mpm módot kell váltani. Itt lehet event-et is használni, de nekem a worker alapú megoldás optimálisabb, mivel egyszerűbb és nem számítok nagy egyidejű lekérdezésre:

a2dismod mpm_prefork
a2enmod mpm_worker

Ez előtt a php modult is ki kell kapcsolni. A worker alapú megoldással az alap php modul általában nem működik, mivel nem thread safe (Apache is running a threaded MPM, but your PHP Module is not compiled to be threadsafe. You need to recompile PHP). De ez nem is akkora nagy probléma, mivel php terén is érdemes már a kezdetek kezdetén perspektívát váltani, és telepíteni a php-fpm-et:

apt install php-fpm
a2enmod proxy_fcgi
a2enconf php8.2-fpm

Ezek után a php beállításokat már az fpm-es php.ini-ben érdemes szerkeszteni (/etc/php/8.2/fpm/php.ini ). Ha ezzel megvagyunk akkor még egy opcache telepítést is érdemes megtenni.

apt install php-opcache

A telepítés után a beállítások itt találhatók: /etc/php/8.2/fpm/conf.d/10-opcache.ini

Az én beállításaim valahogy így néznek ki a teszt site-on:

zend_extension=opcache.so
opcache.jit=on
opcache.enable=1
opcache.memory_consumption=128
opcache.max_accelerated_files=10000
opcache.revalidate_freq=240
opcache.validate_timestamps=1

Érdemes továbbá a PHP által kezelt objektumokat perzisztens módon tárolni, pl. memcached-ben.

apt install memcached

A konfiguráció itt található: /etc/memcached.conf de nagyon nem kell bántani, talán a memória méretét érdmes megemelni 127 mb-ra (alapból 64)

service restart memcached
apt install php-memcached
apt-get install php-pear php-dev zlib1g-dev
pecl channel-update pecl.php.net
pecl install memcache

Php.ini-be fel kell venni: extension=memcache.so majd újra kell indítani az fpm php-t.

WordPress plugin-ből érdemes telepíteni az alábbit:

Memcached Object Cache

Így majd kapunk értesítést a wordpres-sen belül, ha esetleg új verzió lenne. Sikeres telepítés után kézzel kell átmásolni a object-cache.php fájlt a /wp-content/plugins/memcached könyvtárból a wp-content könyvtárba. Majd felvenni a WP_CACHE_KEY_SALT változót a wp-config.php-be (a plugin leáírsa – readme.txt – alapján)

Ha működik a dolog, akkor a Query monitor Overview fülén tudjuk majd ellenőrizni:

Ha ezzel mind megvagyunk nincs más dolgunk, csak a wordpress oldalon is körülnézni egy kicsit. Itt nem érdemes kézzel matatni a dolgokban, nagyszerű plugin-ek vannak, amik megteszik ezeket helyettünk. Én az alábbiakra tettem le a voksom:

Query Monitor – hogy lásd mi történik

Memcached Object Cache – a php objektumok memcached-ben történő tárolásához

WP Rocket – a legenerált oldalak gyorsítása, és további optimalizálások (css, js minify, stb.)

Smush – kép tömörítés és konverzió webp formátumra (és igény esetén átméretezés adott limitre)

Ha mindent jól csináltunk, akkor egy viszonylag gyenge szerveren (Intel Pentium Processor E6700 és 1 Gb memória), az alábbit kellene látunk egy Elementor által generált oldal esetén.

Ui: eredetileg egy oldalbetöltés 3s volt…

Docker windows alatt

Szerintem operációs rendszerek esetén jó taktika, ha csak az fut rajta, amit az ember használ is. A docker is egy ilyen dolog, amit csak ritkán használok, és ha használom, akkor csak linux alatt, ami ugye az esetemben WSL ubuntu (windows subsystem for linux).

Ubuntut viszonylag egyszerű telepíteni windows alá, de nekünk olyan ubuntu kell, ami WSL2-t használ.

Akit érdekel mi is az a wsl2 járjon utána

A telepített wsl példányokat az alábbi módon tudjuk kilistázni:

wsl -l -v

A WSL2-nek van pár peremfeltétele, aminek meg kell felelni, és amin a többség elvérzik:

  • Top verziót használjunk a windows 10 vagy 11-ből (Windows update)
  • Biosban be legyen kapcsolva a virtualizácó
  • Windows alatt telepítve legyen a Virtual Machine feature
  • Le legyen töltve a wsl2 kernel frissítés (külön exe)

Hogy ezeket az előfeltételeket hogy lehet megteremteni, arról van egy jó leírás itt:

https://s1gr1d.medium.com/how-to-set-up-linux-on-windows-with-wsl-2-debe2a64d20d

Ha ezek megvannak (a restart fontos, én pl. kihagytam), akkor két út van:

Még nincs WSL linux telepítve, és szeretnénk, ez esetben nincs más dolgunk, mint alapértelmezetté tenni a wsl2-t

wsl --set-default-version 2

majd telepíteni a microsoft app store-ból.

Ha már van WSL linuxunk, de nem WSL2 akkor frissíthetjük az alábbi módon:

wsl --set-version Ubuntu 2

Ahol az ubuntu az a név, amit a fenti wsl -l -es parancs kimeneténél a name mezőben látsz.

Ha a frissítés hiba nélkül lefut, akkor a wsl -l már kettes verziót fog kiírni. Ha nem fut le hiba nélkül akkor vagy az előfeltételek közül hiányzik valami (nem írja ki, hogy mi, nálam a restart volt 🙂 ), vagy valami egyéb hiba van, amiből azért lehet bőségesen

Ha ez megvan, és rendelkezünk egy WSL2-es linuxal, akkor már csak a dockert-t kell életre kelteni. Ennek a módja az alábbi:

Győződjünk meg róla, hogy semmilyen docker maradvány nincs a rendszeren:

apt remove docker docker-engine docker.io containerd runcsudo apt remove docker docker-engine docker.io containerd runc

Telepítsük az előfeltételeket, és adjuk hozzá a docker-t a source listához:

sudo apt install --no-install-recommends apt-transport-https ca-certificates curl gnupg2
source /etc/os-release
curl -fsSL https://download.docker.com/linux/${ID}/gpg | sudo apt-key add -
echo "deb [arch=amd64] https://download.docker.com/linux/${ID} ${VERSION_CODENAME} stable" | sudo tee /etc/apt/sources.list.d/docker.list
sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io
sudo usermod -aG docker $USER

Ezek után még szükség lesz egy docker specifikus könyvtárra, ahol a socket elérhető a dockerd számára. Ehhez kell egy config:

sudo mkdir /etc/docker
sudo nano /etc/docker/daemon.json

A fájl tartalma legyen:

{
   "hosts": ["unix:///var/run/docker.sock"]
}

Ha ez megvan már csak indítani kell a docker démont a használat előtt:

sudo dockerd

És utána működni fognak a docker-es utasítások.

Java classpath

Kérdés: melyik jvm verziónál fog szöget ütni valaki fejében a gondolat, hogy a classpath paraméterében az egyik platformon pontosvesszővel, a másikon kettőspont az elválasztó karakter?

Linux: java -cp “.:lib/*”

Windows: -cp “.;lib/*”

Mondjuk így legalább mindenki gyorsan megtanulja, mit értenek a fejlesztők platformfüggetlen megoldások alatt.

Flutter 2 install

Nekem is úgy mondták (öregszem), de már egy napja megjelent a Flutter 2, ami mindennél is jobb. Mindig is szerettem a UI absztrakciókat, és azokat a durvábbnál durvább hackeket amibe aztán mindenki belebonyolódik az absztrakciók következményeként (SWT és társai ugye). Gondoltam felrakom, és jól megnézem, 2021-ben mit sikerült összehozni.

A telepítés (ami másolás) gond nélkül lement, aztán azt javasolták futtassam a flutter doctort, ami azt mondta, fogadjam el az android licenszeket egy újabb flutter doctor futtatással. Mégpedig ezzel:

flutter doctor --android-licenses

Lelkes voltam, futtattam és mint lenni szokott, megint egy szuper kis kaland vette kezdetét. Ugyanis a várt nyomj Y-t és fogadd el a licenszek helyett ezt kaptam:

C:\Users\voji\AppData\Local\Android\Sdk\tools\bin>flutter doctor --android-licenses
Exception in thread "main" java.lang.NoClassDefFoundError: javax/xml/bind/annotation/XmlSchema
        at com.android.repository.api.SchemaModule$SchemaModuleVersion.<init>(SchemaModule.java:156)
        at com.android.repository.api.SchemaModule.<init>(SchemaModule.java:75)
        at com.android.sdklib.repository.AndroidSdkHandler.<clinit>(AndroidSdkHandler.java:81)
        at com.android.sdklib.tool.sdkmanager.SdkManagerCli.main(SdkManagerCli.java:73)
        at com.android.sdklib.tool.sdkmanager.SdkManagerCli.main(SdkManagerCli.java:48)
Caused by: java.lang.ClassNotFoundException: javax.xml.bind.annotation.XmlSchema
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:606)
        at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:168)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
        ... 5 more

Nem igazán értettem a dolgot. Na jó értettem, ez a class ugyanis a jaxb része, ami már java 9 óta deprecated 11 óta meg benne sincs a JDK-ban. Elég sokan, elég sokat szívtak már ez miatt a nagyvilágban.

Szóval vagy átírogatom mindig a környezeti változókat, hogy java8-java15-java8 vagy keresek valami értelmesebb megoldást. Az utóbbit preferáltam, így legalább lehetőségem nyílt kicsit megismerkedni a dart nyelvvel is, ami állítólag flutterhez nem hátrány.

Szóval az történt, hogy flutter doki megpróbálja nyaggatni az android sdk parancssoros kezelőjét, az sdkmanager.bat-ot. Ha ezt önmagában lefuttatjuk, akkor ugyanezt a hibát fogjuk kapni, mert ott még valaki nem vette észre, hogy egy 2017 óta deprecated dolgot használ.

A megoldás innen már egyszerű: le kell tölteni egy jaxb-t, és megoldani, hogy a classpath-on legyen.

A letöltés viszonylag egyszreű, innen lehet megtenni. FYI a jobb oldali Download felirat nem egy menü, hanem funkció. Lehet a JDK fejlesztők se találták elsőre a letöltés gombot, azért maradt ki a jaxb a JDK-ból. Tanúság: tessék jól látható letöltés gombokat használni, lehetőleg az oldal közepén.

Na de visszatérve a problémára, azt az sdkmanager.bat generálta, célszerű itt is megoldani. Ez alapesetben itt található:

%USERPROFILE%\AppData\Local\Android\Sdk\tools\bin\sdkmanager.bat

A problémás rész pedig itt (ahol látható, hogy szépen felülírják a classpath-ot, pedig az első próbálkozásom az volt, hogy oda felteszem a dependenciákat mint környezeti változó):

set CLASSPATH=%APP_HOME%\lib\dvlib-26.0.0-dev.jar;%APP_HOME%\lib\jimfs-1.1.jar;%APP_HOME%...

Ha belematatjuk ezt a kis kiegészítést (ide lett kitömörítve a csomag: d:\work\libs\jaxb-ri):

set CLASSPATH=d:\work\libs\jaxb-ri\mod\jaxb-api.jar;d:\work\libs\jaxb-ri\mod\jaxb-runtime.jar;d:\work\libs\jaxb-ri\mod\istack-commons-runtime.jar;d:\work\libs\jaxb-ri\mod\javax.activation-api.jar;%APP_HOME%\lib\dvlib-26.0.0...

Máris boldogabb lesz egy flutter pingvin a google főhadiszállásán…

C:\Users\voji>flutter doctor --android-licenses
                                                                                
7 of 7 SDK package licenses not accepted. 100% Computing updates...
Review licenses that have not been accepted (y/N)?

Gradle parametrizált task

A gradle task-ok nem tudnak paramétereket fogadni by design. Globális build paramétereket lehet olvasni belőlük, de hát azért a gányolásnak is van határa…

És bár paramétert nem lehet task-nak adni, task-ot viszonylag egyszerűen lehet létrehozni. És igény esetén kicsit bonyolultabban is.

Tegyük fel angular-t szeretnénk fordítani, különböző build target-ekkel. Vagy másolunk sokat, vagy csinálunk egy ilyet:

def createAngularTask(build, language) {
    return tasks.create("buildAngular_${build}_${language}", Exec) {
        group = "generated"
        workingDir = project.ANGULAR_APP_PATH
        inputs.dir(Paths.get(workingDir.toString(), "/src"))
        outputs.dir(Paths.get(workingDir.toString(), "/dist_hu"))
        def cmdArray = ["npm", "run", "${build}:${language}"]
        if (System.getProperty('os.name').toUpperCase().contains('WINDOWS')) {
            cmdArray.addAll(0, ["cmd", "/c"])
        }
        commandLine cmdArray
    }
}

Kicsit emlékeztet ez a C-s define varázslásokra, de úgy tűnik a groovy-s csapatot ez nem rettentette el. Szóval ha csináltunk egy ilyet, akkor már csinálhatunk ilyesmiket is:

createAngularTask("aembuild", "hu")
createAngularTask("aembuild", "en")
createAngularTask("jarbuild", "hu")
createAngularTask("jarbuild", "en")

És ha ilyeneket csináltunk, akkor már csinálhatunk csoportos build task-okat copy paste nélkül:

task buildAngularAem {
    group = BasePlugin.BUILD_GROUP
    dependsOn('buildAngular_aembuild_hu')
    dependsOn('buildAngular_aembuild_en')
}

A fenti játékot el lehet játszani akár string tömbökből is, ha nagyon sok task lenne. Így a task-oknak, csak a képzeletünk szab határt…

Microsoft Xbox wireless controller

A Microsoftnak valahogy mindig sikerül félre pozícionálni egy terméket, bármennyire is jó az. Elkezdték ezt a dolgot a konzolok nevével (tegye fel a kezét, akinek nincs xbox-ja, és sorrendbe tudja tenni, hogy az xbox, xbox one, xbox360, xbox s, xbox x volt előbb vagy utóbb) de a controllerekkel se jobb a helyzet.

De ne szaladjunk ennyire előre. Kezdjük onnan, hogy minek is controller PC-hez? A válasz egyszerű, mert jobb vele játszani. Főleg ha egy laptop, Tv, vagy esetleg mobil eszközök kerülnek a képbe. És mobil eszközök alatt nem csak a telefont értem, hanem mondjuk tabletet, a Steam in home streaming-jét, vagy a geforceNow-t. És persze ott vannak maguk a játékok. A csak controllerrel élvezhető játékok első zászlóshajója a Resident Evil széria volt (kb. az összes rész), de mostani játékokból is van bőven, ami egyszerűen játszhatatlan egérrel (pl. Detroit: become human), és azok amik jobbak controllerrel (pl. a Cyberpunk 2077).

A fentiek önmagukban még nem győznének meg arról, hogy Microsoft által gyártott controllert kell vennem, ugyanis elérhető közelségben van egy Nintendo Pro controller, ami papíron hasnálható PC-vel. Csak sajnos a Nintendo ezt a feature-t nem gondolta túl: ha kábellel próbálod használni PC-n, akkor utána a controller nem kapcsol ki soha, amíg le nem merül, vagy újra nem párosítod a switch-hez ami ki tudja kapcsolni. Amit biztos meg kell tenned, mert egy kábeles PC-s használat elég ahhoz, hogy elfelejtse ő valójában egy Nintendo Switch-el párosított controller, szóval onnantól nincs se távoli bekapcsolás, se instant játék… Tehát papíron a feature pipa, gyakorlatban használhatatlan.

És ha ez nem lenne elég, a Microsoft megcsinálta azt, amit a Nintendon’t. Képesek voltak szabványos bluetooth protokollt is implementálni a vezérlőjükbe, ami kommunikál androiddal és IOS-el. Ez volt az a pont, ami meggyőzött, hogy jó lesz még egy controller a háznál.

Szóval az első probléma, ha controllert akarunk venni, hogy melyiket. Szerencsére ezen a részlegen már nem voltak olyan kreatívok a marketingesek, mint a gép név választásnál, így csak számokat kaptak a controllerek nevek helyett, amik növekednek, de… Na lépjünk is tovább, a lényeg, hogy a legújabb controller a 1914-es.

A webshop-ok kínálatában a beszédes Microsoft Xbox Wireless Controller néven fogjuk megtalálni a legtöbb helyen, akárcsak az összes többit… Természetesen a számot nem szokták odaírni.

Viszont ha ezt vesszük, akkor az IOS támogatásra még várni kell, mert az még csak “coming in the future”. Szóval vagy a legújabb controller IOS támogatás nélkül, vagy az egyel régebbi a 1708-as. A típusokat leginkább csak kép alapján lehet megkülönböztetni egymástól, a Microsoft is különböző körülírásokkal hivatkozik az egyes controller generálciókra (a vezérlő, amin van share gomb, vagy a verzérlő aminek a felső része egybe van a gobokkal, stb), ami valahol azért elég vicces…

Ha már választunk controllert, akkor arra is érdemes figyelni, hogy az adott típusból is több van, nagyjából egy árban. A csak vezérlő (xbox-hoz), vagy a pc-hez csomagolt kábellel, és a wireless dongle-s. Itt fontos látni, hogy a controller ugyanaz, de usb-usb-c kábelt pár ezer forintból be lehet szerezni az ebay-en, viszont Microsoft USB dongle-t nem, és az boltban bőven tízezer forint fölötti összeg. Plusz infó, hogy az usb dongle nem bluetooth dongle, egyedi protokollon keresztül kommunikál, ami hatékonyabb jelátvitelt, rövidebb latency-t, és extra feature-ket is tud, mint pl. 8 vezérő is csatlakoztatható hozzá egyidőben (Bluetooth-on keresztül max. 1).

Ha megérkezik a csoda controller, akkor jön csak az igazi nagy meglepetés. Mégpedig ez:

Bizony. A Microsoft Windows 10 nem ismeri fel, a Microsoft XBOX dongle-t. Semmi leírás, semmi driver, elviekben plug and play. Nem akartam elhinni, és ma is nehezen hiszem, hogy ezt így ebben a formában sikerült összerakni a Microsoftnak, de sikerült.

Ha valaki mégis szeretné Microsoft Windows alatt használni, a Microsoft által gyártott eszközét, akkor az alábbit kell tenni:

  1. Elolvasni a Microsoft FAQ-t, ahol azt állítják, hogy minden plug and play, szóval, arrafelé sötétség van a fejekben.
  2. Különféle forum bejegyzéseket keresni, amiből elég sok lesz (nem meglepő módon), és megtalálni azt, ami a mi vezérlőnkről szól, és működik.
  3. Vagy egyszerűen csak tovább olvasni ezt a szuper leírást 🙂

Első körben meg kell néznünk, milyen típusú vezérlőnk van. Ezt a Device Managerben az alábbi képernyőn viszonylag egyszerűen megtehetjük:

Ezek után kell túrni egy hozzá megfelelő drivert a windows update catalog-ban:

http://www.catalog.update.microsoft.com/Search.aspx?q=USB%5CVID_045E%26PID_02FE

2 találat lesz, a nagyobb méretű kell:

Az eredmény egy cab file lesz, amit az explorer megnyit és pár fájl lesz benne:

Ezt másoljuk ki egy könyvtárba, és a Device Managerben mondjunk egy Update Driver-t.

Ne is próbálkozzunk drivereket találni, használjuk a sajátunkat.

Adjuk meg a könyvtárat ahova a fájlokat tettük a cab-ból, és láss csodát:

A jelenség nem egyedi, 3 teljesen külön win10-en is kipróbáltam, amiből kettő már átesett a 20H2 update-n is. Pedig maga a hardware job mint a Nintendo Pro controller (a dpad biztos), a funkciói is jobbak, hogy pont a telepítését sikerült így elszúrni, arra nem számítottam…

Ha ezzel megvagyunk, akkor még nincs vége a megpróbáltatásainknak. A vezérlőt a windows update nem frissíti, ahhoz egy külön programot kell letöltenünk, amit a Microsoft Store-ba találunk meg. A neve:

Miután ezt letöltöttük, és elindítottuk el is indul a firmware frissítés, amennyiben szükséges.

Securing apache

Ha esélyt szeretnénk adni Apache szerverünknek az életre, érdemes az alap beállításokon módosítani pár dolgot.

A legfontosabb szabály, a szerverünk mindig legyen naprakész (apt update, apt upgrade, esetleg a paranoiásaknak chkrootkit)

Aztán érdemes meggyőzni az Apache-ot, hogy ne mondja el mindenkinek a verziószámát, így talán nehezebb lesz expolit-ot keresni benne:

ServerSignature Off
ServerTokens Prod

A második a mod_security. Ezt sajnos kicsit macerásabb beállítani, de megéri. Ehhez az alábbi lépésekre van szükség:

apt-get install libapache2-mod-security2
cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

Ezután érdemes bekapcsolni a security használatát az újonnan létrehozott (modsecurity.conf) konfig fájlban (alapból csak detektálásra van állítva)

SecRuleEngine On

Ha ez megvan, már nincs másra szükségünk, csak friss biztonsági szabályokra (persze csak egy gyors backup után).

mv /usr/share/modsecurity-crs /usr/share/modsecurity-crs.bak
git clone https://github.com/coreruleset/coreruleset.git /usr/share/modsecurity-crs

Majd ezt lehet frissítgetni időnként az alábbi paranccsal:

cd /usr/share/modsecurity-crs
git pull

Ezután még példányosítani kell a configot:

cp /usr/share/modsecurity-crs/crs-setup.conf.example /usr/share/modsecurity-crs/crs-setup.conf

Ha ez megvan, és a szerveren futtatunk valamilyen speciális dolgot (Pl. WordPress) akkor érdemes azt kivételként megadni. Az új configunkban (crs-setup.conf) az alábbi sorokat kell kicommentelni, és a megfelelő rendszerhez 1-est írni:

 SecAction \
  "id:900130,\
   phase:1,\
   nolog,\
   pass,\
   t:none,\
   setvar:tx.crs_exclusions_cpanel=0,\
   setvar:tx.crs_exclusions_dokuwiki=0,\
   setvar:tx.crs_exclusions_drupal=0,\
   setvar:tx.crs_exclusions_nextcloud=0,\
   setvar:tx.crs_exclusions_phpbb=0,\
   setvar:tx.crs_exclusions_wordpress=1,\
   setvar:tx.crs_exclusions_xenforo=0"

És már meg is tettük az első lépéseket egy biztonságosabb Apache szerver felé.

Sose feledjétek: biztonságos rendszer nincs, max. biztonságosabb…