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

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.

Smarthome@github

Amikor nekiálltam az építsünk okos házat projektnek, arra gondoltam, hogy az átlagos informatikai projektektől eltérően ez egy egyszerű dolog lesz, buktatók és problémák nélkül, pár hét alatt véget is ér. Annyira bíztam ebben, hogy még repository-t se csináltam, a forrásokat egyszerűen dropbox-on tartottam. Mostanra eljutottam oda, hogy az alapvetések már működnek, és újra se kell írni mindent (amíg nem jön az openhab v3). Igaz az ütemezéssel kicsit megcsúsztam, de hát mégicsak egy IT projektről van szó, ahol még azok sem mindig tudják mit akarnak, akik az általam használt komponenseket fejlesztik…

Jelenleg épp léptető motort programozok, 3D modelleket készítek nyomtatáshoz, integrálok, deriválok, szabadidőmben pedig egy megbízhatóbb MQTT kommunikációs protokol implementációján gondolkozom, az eszközök és az openhab között… Szóval az izgalmak még csak most kezdődnek (legalábbis annyi izgalom, amit az időm enged).

Újdonság viszont, hogy a projekt felkerült a github-ra, így az újabb dolgok már ott is megtalálhatók: https://github.com/voji/smarthome

Oracle adatbázis séma gyors törlése

Le akartam törölni pár nagyobb sémát Oracle alatt, aminek az lett az eredménye, hogy 20 órát futott a DROP USER… Kis olvasgatás után az körvonalazódott, hogy ezt a funkciót nem sikerült jól implementálni, ezért inkább töröljek kézzel mindent, és csak a végén töröljem a már üres sémákat… Nagy nehezen kiizzadtam magamból a lenti scriptet, ami működik is, de mivel az impdb implementációja sem sikerült teljesen ezért a végső megoldás az lett, hogy el kell dobni a teljes adatbázist, és újra kell gyártani nulláról… De ha már megírtam, akkor elmentem, hátha még jól jöhet a későbbiekben…

BEGIN
  FOR r1 IN ( SELECT 'DROP ' || object_type || ' ' || owner || '.' || object_name || DECODE ( object_type, 'TABLE', ' CASCADE CONSTRAINTS PURGE' ) AS v_sql
               FROM all_objects
               WHERE owner in ('SCHEMA1', 'SCHEMA2') AND 
                object_type IN ( 'TABLE', 'VIEW', 'PACKAGE', 'TYPE', 'PROCEDURE', 'FUNCTION', 'TRIGGER', 'SEQUENCE' ) 
                ORDER BY object_type, object_name ) LOOP 
    BEGIN 
     EXECUTE IMMEDIATE r1.v_sql; exception when others then null; 
    END; 
   END LOOP; 
  END; 
/ 

DROP USER CUSTOMER SCHEMA1 CASCADE;
DROP USER CUSTOMER SCHEMA2 CASCADE;

Indie game dev infograph

Ritkán adódik alkalom arra, hogy belelássunk egy-egy független játék készítésének költségeibe, és bevételeibe, pedig ezek elég jó támpontot nyújthatnak azoknak, akik ilyesmiben gondolkoznak. Nem is tudom mit tehetnék hozzá, beszéljenek helyettem a számok…

 

 

Svn pre-commit hook and conflict markers

Előfordul néha, hogy a nagy lelkesedésben conflict makereket tartalmazó fájlt commitolnak a fejlesztők a repository-ba. Ez nem túl gyakori hiba, de azért tud kellemetlen lenni. Keresgettem egy kicsit, de nem találtam nekem tetsző script-et, ezért írtam egyet.

 

SVNLOOK=/usr/bin/svnlook
for x in `$SVNLOOK changed "$REPOS" -t "$TXN"`; do
 if [ "$updated_file" == true ]; then
    mimetype=`$SVNLOOK propget "$REPOS" svn:mime-type -t "$TXN" "${x}" 2>/dev/null`
    #ignore binary files
    if [ -z ${mimetype} ]; then
      if $SVNLOOK cat -t "$TXN" "$REPOS" "${x}" | grep -qE '^+?(<<<<<<<|>>>>>>>)'; then
        echo "Commited conflict marker detected, commit rejected!" 1>&2 && exit 1
      fi
    fi
    updated_file=false
    continue
 else
    if [ "$x" = "U" ]; then
      updated_file=true
    fi
 fi
done
set -e

Új mame, régi frontend

A mame-t minden játéktermi gépen edződött fiatal ismeri (aki valamiért mégsem, gyorsan kezdjen ismerkedni vele :). Zseniális emulátor, de a fejlesztők a minél tökéletesebb emuláción kívül nem sok mindennel foglalkoznak (szerencsére), ezért sokan gyártottak hozzá különböző front-end-eket.

Ellenben az utóbbi időben az újabb mame verziókkal valahogy semmilyen front-end nem akart működni. Ennek az az oka, hogy a mame v.162 óta megváltozott a generált gamelist.xml fájl formátuma, aminek tartalmára a front-end-ek erősen támaszkodtak. A változás miatt az újabb mame verzió által generált xml fájlon már nem nagyon igazodnak ki.

Erre jelenthet megoldást az alábbi parancs:

</pre>
sed -e "s/machine+/game+/g" -e "s/<!ELEMENT machine/<!ELEMENT game/g" -e "s/<!ATTLIST machine/<!ATTLIST game/g" -e "s/<machine/<game/g" -e "s/<\/machine/<\/game/g" < gamelist.xml > gamelist_of.xml
<pre>

Ez az új formátumú mame gamelist.xml-t konvertálja át a régi formátumra.

A problémáról az alábbi linken írnak a Mala front-end kapcsán, de ugyanúgy érinti a Maximus Arcade felhasználókat is:

http://forum.arcadecontrols.com/index.php/topic,145865.0.html

 

 

XML fájlok szerkesztése parancssorból

Egyre több program tárolja az adatokat XML formátumban, ami kezelése nem egyszerű a hagyományos parancssori eszközökkel (grep, sed, és társai). Az XML formátum kezelésére viszont léteznek már újabb eszközök, mint például az XmlStarlet. Ez gyakorlatilag egy parancssori XML szerkesztő tool, melynek segítségével könnyedén nyerhetünk ki, vagy adhatunk, módosíthatunk adatokat az XML formátumú fájlokban.

A használata során nem árt képben lenni az XPATH fogalmával, és formátumával. Ehhez jó kiindulási alap lehet az W3Schools leírása. A munka során jó szolgálatot tehetnek még az online XPATH teszterek, generátorok.

Egy sok xml-t módosító (alap) script valahogy így néz ki a gyakorlatban:

#!/bin/sh
WORKSPACE=/cygdrive/t/work/

for x in `ls -d ${WORKSPACE}/*/`;
do
  PROJ_FILE=${x}build.xml
  if [ -f ${PROJ_FILE} ]
    then
    echo Processing build file: ${PROJ_FILE}
    xmlstarlet ed -O -P -a "/project" -t attr -n default -v "rebuild_release" ${PROJ_FILE}
  fi
done

A futtatás során a megadott könyvtár alkönyvtáraiban található build.xml fájlok tartalma az alábbi képpen módosul:

Eredeti tartalom:

<?xml version="1.0" encoding="UTF-8"?>
<project name="ac">
	<import file="../build/common.xml"/>

Tartalom a módosítás után:

<?xml version="1.0" encoding="UTF-8"?>
<project name="ac" default="rebuild_release">
	<import file="../build/common.xml"/>

A példa nem vizsgálja, hogy az XML tartalmaz e már default attribútumot, de ezt igény esetén egy újabb xmlstarlet query-vel és egy if-el könnyedén ellenőrizhetnénk. Jelen működés alapján, ha kétszer futtatnák le a fenti kódot, akkor az xml-ekben 2x kerülne beszúrásra a default tag.

 

HTML alapú pdf riporting engine

Úgy látszik mások is gondolkoztak már azon amin én mostanában, hogy milyen jó lenne NodeJS-el szerver oldalon generált html-ekből PDF riportokat generálni (először grafikonok rajzolásán gondolkoztam, csak utána tovább gondoltam).

Az alábbi cikk elég jó a témában: http://www.feedhenry.com/server-side-pdf-generation-node-js/

Sajnos a sejtésem beigazolódni látszik, bár technológiailag egy működő, jó megoldás, erőforrás kell egy ilyen rendszer alá, és elsőre úgy tűnik nem is kicsi…