adatbázis-szerkezet “verziókövetése”

Egy ideig gondot okozott, hogy vajon mivel tudnám a címben lévő problémát orvosolni. Adott az éppen aktuális fejlesztés amihez verziókövetőt használok, viszont az adatbázissal eddig nem sok mindent tudtam csinálni. Önálló részegység aminek a szerkezetváltozása elég nehezen követhető. Volt, eddig. Most úgy tűnik sikerült végre megoldást találnom a problémára.
A megoldást a binlog fogja szállítani. A mysql binlog követi és loggolja az insert update alter és hasonló, változással járó parancsokat. A másik hasznos tulajdonsága amit most használni is fogunk, hogy képes a rendelkezésre álló adathalmazból szűrni adatbázisra és időpontra (tól ig intervallumban is akár). Nézzük hogyan is valósul meg az elképzelés.
Egy fájlba fogunk dolgozni, legyen mondjuk dev/mysql_changes.sql. Ha commitolni akarunk akkor a fájl történetéből ki tudjuk deríteni azt, hogy mikor commitoltunk utoljára, tehát van egy dátumunk. Ezt így kapjuk meg:

user="connor"
revdate="$(svn log dev/mysql_changes.log | grep "| $user |" | awk '{ print $5 " " $6 }' | head -n1)"

M.j.: Ezen a ponton van az első pontatlansága a jelen megvalósításnak, hiszen ha egy futó projectbe érkezik egy új fejlesztő nála ez üres lesz. Így kézzel kellene megadni egy dátumot. Ez a dátum mondjuk lehet a fájl létrehozásának időpontja (hiszen ha saját checkoutja van a fejlesztőnek, akkor a co utáni változásokra vagyunk kíváncsiak). Így ha az elgondolás helytálló akkor ez is megteszi: stat -c “%Z” dev/mysql_changes.log

Majd a kapott dátummal listázunk a binlogokból és szükség esetén commitolunk:

database="folkradio"
mysqlbinlog /var/log/mysql/mysql-bin.0* -d $database --start-datetime="$revdate" | grep -e "^insert" -e "^update" -e "^#" -vi > dev/mysql_changes.log
svn commit -m "adatbázis szerkezet változott" dev/mysql_changes.log

Eddig a fejlesztő oldaláról. A szerver oldalon és az éles rendszeren szintúgy végig lehet szambázni a változásokon. Akkor az “svn log” parancs segítségével értelem szerűen revíziók vagy ágak közötti változásokat kell listáznunk. Ekkor egy ciklusra és az svn cat parancsra van szükség. Mivel viszont a fejlesztés közben adódhatnak hibák és fölösleges kódok a kimenetet éles rendszer frissítése előtt mindenképpen érdemes egy fájlba összehozni és végigfutni. Ha minden rendben akkor lehet rá áment mondani.

Mik az elgondolás hibái?

  • Elgondolás szinten létezik. Gyakorlatba még csak most fogom átültetni.
  • Nem tesztelt.
  • Nem tűri az olyan szerkezeteket ahol az adatbázis táblája, vagy annak sora a program számára fontos elemet tárol, amit szintúgy mozgatni, verziózni kell. Ekkor nyilvánvalóan filter (pl awk) kell a binlog kimenetére amiben táblára is tudunk szűrni.
  • Éles szerver és a fejlesztői szerver scriptjei nincsenek kidolgozva így lehetnek nem látható akadályok

Összességében viszont már így is több mint ami eddig volt. A tapasztalatot a használat fogja meghozni, így ha beválik akkor mindenképpen referálok az elkészült scriptekkel egyetemben.

client cert auth és a phpmailer

A Cultura Nostra kapcsán a phpmailer-t ki kellett bővítenem kliens hitelesítés alapú azonosításhoz a szükséges kódokkal. Meglepően egyszerű. Folt az 5.0-hoz.

Használata rém egyszerű:

$mailer = new phpmailer();
$mailer->From = '...';
$mailer->FromName = '...';
$mailer->Host = 'srv.host.hu';
$mailer->Port = 465;
$mailer->SMTPSecure = 'ssl';
$mailer->SMTPAuth = false;
$mailer->SMTPCert = '/path/to/cert.pem';
$mailer->CharSet = 'utf-8';
$mailer->IsSMTP();
$mailer->AddAddress('...');
$mailer->Subject = 'proba';
$mailer->Body = 'body';
$mailer->Send();

El lehetne bonyolítani, hiszen a stream_context_set_option() fv képes kezelni passphrase-t.

csipetnyi bunkóság egy adag tahósággal fűszerezve

Történt az Úr 2009. esztendejének Új kenyér havának 17. napján egy mulatságos, tragikomikus epizód az kedves családom és jómagam életében. Sógoromnak van egy Skodája. Felicia. Benzines. Ez utóbbi tény lesz érdekes történetünk folyamán. Pár napja, tudván hogy előbb-utóbb be fog következni egy tankolás megkérdeztem az autó folyadékszükségletének jellemzőit. Kérdésemre rávágta, hogy dízel. Majd még poénkodott valamit, de mivel az információt már megkaptam több másra már nem figyeltem, lévén birtokában vagyok minden infónak mit nekem más apróság??!
Ma útra keltem üzlettársamhoz vinni és hozni ezt-azt. Indulás előtt a benzinszint jelző alacsony szintje miatt a kagylónál töltöttem bele egy keveset. Szerencsémre csak 5 litert. Dízelt, mi mást?! Eljutottam kerepesre. Majd mikor indultam vón haza az autó nem akarta az igazságot. Egynehány próbálgatás majd az utca aljáig gurulás után feladtam a dolgot szóltam bátyámnak. Kiderült a turpisság és sógorom jó humorát áldva szedtük össze a kellékeket a leszíváshoz és az újratöltéshez. Utólag okos vagyok mert elég lett volna csak rátankolni. Ezt viszont akkor még nem tudtam. Betoltuk az autót egy építkezés bejáratához majd elsétáltunk a szerszámokért és bátyám bevárásába kezdtünk.
Megérkezése után realizáltuk a leszívás próbálgatása után hogy ez biz’ dupla tankos. Nem fog menni. Hajrá hátsó ülés alól kiszedtük a tank szivattyút majd elkezdtük leengedni. Ez így leírva egy mondat kivitelezve kicsit több volt. A leengedés végéhez közeledtén megérkezett sógorom a teherautóval. Már öten szurkoltunk hogy sikerüljön a haditerv. Nem sokra rá megérkezett az építkezés gazdája. Itt kezdődtek az érdekességek. Ahelyett hogy a jóember megkérdezte vón, hogy segíthet-e, mi történt vagy ezek szabad variációi, “ja csak lerobbantak” megjegyzéssel sarkon fordult bevárta a fehér-dzsippes társát és elviharoztak. Láttam már érdekes embereket, no para. Hamarosan végzünk aztán irány haza!
Leszívás után rátöltöttünk egy keveset, majd megpróbáltuk az indítást. Köhögött még ugyan de erős gáz után tisztulni látszott. Leáll, töltés tovább. Ekkor érkezett meg a következő delikvens, a szembe szomszéd. Hogy mi mi a frászt csinálunk itt és hogy kuss és hogy aludni szeretne és hogy gyerek meg mittom én. Mintha mi a hullócsillagok utáni vágyunktól vezérelvén épp bulihoz készülődünk ott és igazából senki nem akart már rég otthon ülni egy üveg sör kíséretében! Zajongani és a környezetben élőket idegesíteni volt éppen kedvünk! Ez már a fáradtságot se vette hogy akármit is megkérdezzen. Nem is azért jött. Ha még vár 5 percet már nem is talált vón ott minket. Fölösleges műbalhé.
Most jönne a dolgok ilyetén summázása: “na ezért tart itt ez az ország”. De inkább ezt most kihagyom. Komolyan ennyire nehéz megkérdezni, hogy “bocs segíthetek?”.
Ha másért nem, azért egy nagy haszna volt ennek a kis kiruccanásnak. Jobb hatással van ránk egy ilyen esti kaland mint egy hetes “teambuilding”. 🙂

kézzel gzippelt tartalom

A mod_gzip és a hasonló on-the-fly tartalomtömörítéssel az a gondom, hogy a processzort eszi (ha nem is nagyon de azért jobban mintha nem tenné). Statikus tartalom esetén is jó ha sávszélességet spórolunk. Ez a megoldás pont ezt a tartalomtípust veszi célba. Ha létezik tömörítve az eredeti helyett azt szolgálja ki, így spórolva a processzoridővel és a sávszélességgel. A megoldás bővíthető a végtelenségig bármilyen fájltípusra.

AddType image/jpg jpg jpgz
AddEncoding gzip jpgz

RewriteEngine on
RewriteCond %{HTTP:Accept-encoding} gzip
RewriteCond %{REQUEST_URI} ^(.*).jpg$
RewriteCond %{DOCUMENT_ROOT}%{SCRIPT_FILENAME}.jpgz -f
RewriteRule ^(.*)$ $1.jpgz [L]

mj: ModRewrite debuggolás.
RewriteLog “logpath.log”
RewriteLogLevel 9

tracker magyar stopwords hiba

Úgy tűnik a mai nap a hibakeresésé. 🙂
Tracker-ben ha keresést indítottam a daemon egyszerűen kilépett. Ennyit hagyott maga után:

0xb7ce08f8 in sb_stemmer_stem (stemmer=0x0, word=0x8f4d820 "hup", size=3) at libstemmer.c:91
91  libstemmer.c: No such file or directory.
  in libstemmer.c

A stemmer lib a szótövezésért felelős. A magyart átírva angolra rögtön jó lett. Belenéztem kíváncsiságból a magyar fájlba és azt láttam hogy az utf8 nem áll a helyzet magaslatán. Feltettem egy javított változatot:
http://workshop.connor.hu/src/stopwords.hu

Egyenlőre nem bizonyított, hogy ezért szállt el, az újraindexelés még zajlik.

érdekes vino/xdg hiba

Frissítés óta/egy ideje elkezdte pörgetni a procit az ubuntu. A hibakeresés nyomán oda jutottam, hogy a dbus gconf páros miatt megy átlag közel 50%-os procihasználattal a gép. Mivel sem a dbus sem a gconfd nem lehet önmagában hibás (mind a kettőt használja/hívogatja valami ezért elkezdtem random kilőni a programokat. A vino-server lett a hibás. A vino-server -t a /desktop/gnome/remote_access/enabled kulcs módosítása indítja el/állítja le. Ezt a kulcsot az xdg autostart funkciója figyelia (lásd: /etc/xdg/autostart/vino-server.desktop).
Valahogy sikerült az xdg-nek kétszer elindítania a vino-t. A második indulással mivel a dbus már foglalt volt az adott néven ezért ez a folyamat kilépett. A xdg ezt látva viszont rápróbált és megint elindította. Így végtelen ciklusba került és folyamatosan próbálta indítani a második változatot. Ilyenkor persze dbus-hoz és gconfd-hez próbál csatlakozni, ezért a nagy procihasználat azoknál a programoknál. Egyenlőre úgy tűnik sikerült megjavítani (desktop fájl áthelyezése máshova, X restart, fájl vissza, X restart), de reprodukálni még nem tudtam a hibát. És hogy melyik program a ludas? Jó kérdés. Önmagában a vino nem, hiszen kilép ha kétszer indul. Az xdg talán (?) nem hiszen ha egy program hibával elszáll helyes elvárás, hogy indítsa újra. A kettő találkozásakor ilyen ciklus alakulhat ki. A hiba itt van, no meg ott hogy miért indította kétszer az xdg a folyamatot?!

ape to mp3

apt-get install libjmac-java

IFS=$’\n’; for i in $(ls *.ape); do java -jar /usr/share/java/jmac.jar d “$i” $(basename “$i” ape)wav; ffmpeg -y -i $(basename “$i” ape)wav -ab 320000 $(basename “$i” ape)mp3; rm *.wav; done

ledprogram, és a frissítés

Várnagy György minden frissítés után belefut a hibába, hogy a ledvillogtató programom a /sys mappa struktúrájának változása miatt elromlik. És minden alkalommal lelkiismeretesen el is küldi a megoldást. Ím az utolsó:

A trükk az, hogy az elérési út megváltozott és ezt kell kijavítani az /etc/rc.local-ban és a szkriptedben.

A régi elérési út :
/sys/devices/virtual/leds/asus:mail/brightness

Az új pedig :
/sys/devices/virtual/leds/asus::mail/brightness

Az utóbbiban van egy plusz kettőspont a mail előtt.

A Mail Notification program is frissült már korábban. A frissítés óta a beállító grafikus felületen nincsenek meg a mezők amibe be lehetne írni, hogy mi történjen, ha új mail érkezett és ha a mailt már elolvasták. Én ezt úgy oldottam meg, hogy a régi verzió beállításait tartalmazó rejtett fájlokat átmásoltam az új verziójú program rejtett könyvtárába. Így az új Mail Notification program továbbra is indítja a led_on és exit_led_on szkripteket.

Ha az általam leírt megoldás nálad is működik és arra érdemesnek tartod, kitehetnéd az oldaladra hátha mást is érdekel a megoldás.

Gyuri

Köszi! 🙂

személyes siker

Néha vannak olyan dolgok amiknek kifejezetten tudok örülni. Ilyen az a siker is amit a hétvégén értünk el. Online kampány során sikerült 3000 kattintást kihozni 50.000 Ftból. A profi nagymenő cég ennek a számnak a felét hozta ki 150.000 Ftból. Egy hét alatt.
Elbízásra nincs ok. Még van hova fejlődni.

vendor és product id win alatt

Drivert kellett összevadászni hálókártyához. Adva van hogy a vendor és product id alapján. Mindez windows alatt így deríthető ki:
regedit: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\PCI
Itt ki kell keresni a DeviceDesc alapján amire szükségünk van, a többi értelem szerűen.

mpl és a szerver

Neten bóklászva találtam:
“Az ország bármely pontjáról elküldheti hozzánk akár postán szerverét!”
Elképzelem ahogy a magyar pósta elvisz egy rack szervert… 😀