Mindenkinek saját dns szervert

Amennyiben az otthoni számítógépünk nem rendelkezik fix ip-címmel, sokat segíthet a DynDNS szolgáltatás. Ennek segítségével beregisztrálhatunk magunknak egy tetszőleges domain nevet (ingyen) és a szolgáltatáshoz adott kis kliens program segítségével (linux alatt ddclient apt-get-tel telepíthető) az otthoni gépünk mindig frissítheti a saját dns-éhez tartozó ip címét (tehát akkor is elérhetjük a gépünket, ha a gonosz szolgáltató más ip-t adott neki).

Tegyük fel, adott Lajos, aki szeretné a számítógépét elérni otthonról. Beregisztrálja magának a lajos.homeip.net címet. Ezek után az otthoni számítógépét mindig eléri ezen a címen, aminek nagyon örül. Ellenben ha Lajos belső hálózatot is használ, akkor két dolgot tapasztalhat:

1. Olyan szerencsés, hogy a routere támogatja a nat loopback funkciót, és ha beírja otthon, hogy lajos.homeip.net akkor minden működik

2. Nem szerencsés

A nem szerencsés esetet két féle képpen orvosolhatjuk. Ha beírjuk a hostfile-ba, hogy lajos.homeip.net az a szerver lokális ip címe (pl 192.168.2.1). Ez jó, de ha Lajos hazamegy, midnig át kell írnia a host-fájlt, ha meg elmegy otthonról midnig vissza kell írni. Lássuk be ez nem a legelegánsabb megoldás.

Másik alternatíva, hogy Lajos saját dns szervert csinál. Ez azért is hasznos, mert megismeri a DNS szerverek működését, és felépítését (persze csak nagyon felületesen) és mert lát ilyet is…

Linux alatt dns szerverre a bind nevű csomagot szokták használni, amit az alábbi módon telepíthetünk:

sudo apt-get install bind9

Ezekután már van jól működő DNS szerverünk, ami a 67-68 udp portokon üzemel már csak konfigurálni kell. A dns szerver konfigurációját az alábbi helyen találjuk: /etc/bind

Ide kell két fájlt létrehoznunk, ami alapján a dns szerver megoldja majd a név-ip és ip-név fordítást.
db.1.168.192
;
$TTL 604800
@ IN SOA localhost. lajos.homeip.net. (
28 ; Serial
604800 ; Refresh
86400 ; Retry
241920 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost.
2 IN PTR lajos.homeip.net.

db.homeip.net
;
$TTL 604800
@ IN SOA homeip.net. lajos.homeip.net. (
28 ; Serial
604800 ; Refresh
86400 ; Retry
241920 ; Expire
604800 ) ; Negative Cache TTL
;

@ IN NS dns1.hu.
@ IN NS dns2.hu.

@ IN A 204.13.248.119
www IN A 204.13.248.119
lajos IN A 192.168.1.2

Az db.1.168.192 nevű fájl megmondja, hogy a 192.168.1 tartományban a 2 ip cím (192.168.1.2) az nem más mint a lajos.homeip.net.

A második db.homeip.net nevű fájl pedig megmondja, hogy a homeip.net domainban a sima hivatkozás nemmás mint a homeip.net szerver neve (ezt ping homeip.net-el meg lehet tudni), és a lajos.homeip.net pedig nemmás mint a 192.168.1.2 ami a szerverünk címe…

Ezek után már csak használni kell ezeket a fájlokat, a named.conf.local fájlba fel kell venni az alábbi két sort:

include “/etc/bind/zones.rfc1918”;

zone “1.168.192.in-addr.arpa” {
type master;
file “/etc/bind/db.1.168.192”;
};

zone “homeip.net” {
type master;
file “/etc/bind/db.homeip.net”;
};

Ezek után kell egy bind újraindítás (/etc/init.d/bind9 restart), ha elrontottunk valamit arról a var/log/syslog-ban fogunk kapni infót.

Az eredményről magunk is meggyőződhetünk:

dig @localhost lajos.homeip.net

Értelemszerűen a dhcp szervernek meg kell adni, hogy a DNS szerver címe a lokális szerver (192.168.1.2) legyen.

Vnc ubuntu alatt

Sokszor kell, mindig elfelejtem, most már leírom ide is:

Telepítés:
sudo apt-get install vnc4server

ezekután elindítjuk a vnc4servert (létrehoz mindenféle konfigokat, bekéri a jelszót, stb)
vnc4server

ezekután lelőjjük:
vnc4server -kill :1

kicsit átírjuk a konfigurációt ami az alábbi helyen található:
nano ~/.vnc/xstartup

A fájl tartalma ez legyen:
#!/bin/sh
unset SESSION_MANAGER
exec /etc/X11/xinit/xinitrc
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources

Biztos ami biztos adjunk jogot az xinitrc-re:
sudo chmod 755 /etc/X11/xinit/xinitrc

Csatlakozhatunk a host:5901 porton… (ahány példányt indítunk annyiszot emelkedik a portszám 1-el)

Az UltraVNC ha kis porotot adunk meg alapból hozzáad 5900-at, tehát ott elég megadni így: host:1

Spring

Manapság divatos szó a Spring. Ha már csak megjelenik a szövegkörnyezetben, rögtön betölti a levegőt a misztikum, és mindenki érzi, hogy itt valami nagyon komoly, és jó dologról van szó.
Valószínű azért, mert már önmagában a szó jelentése is tavasz, rugalmasság, tehát csupa jó dolog egy olyan világban, ahol a legtöbb dolgot már csak 3 betűs rövidítésekkel illetik (igen kreatív módon, mint pl esb, ejb, ear, stb. 🙂

Programozóknak a spring szó már önmagában olyan, mint az átlagembernek egy üveg Chteau Latour Pauillac. Nem tudja mi az, de jól hangzik, biztos jó lesz valamire.

A fentiek miatt, manapság már szinte nem is találkozni olyan dokumentummal amiben ne szerepelne ez a misztikus szó, ami önmagában örvendetes, és ugyanakkor elszomorító is.
Elszomorító, mert az esetek nagyrészében nagyon kevés ember tudja elmondani, hogy miért és legfőképp mire is használja a springet.

Hogy ezt tisztába tegyük, röviden mire is jó a Spring:
– Az alkalmazások Spring alkalmazás környezetben futnak, ami független lehet az alkalmazásszerver gyártójától, és egyéb megkötésektől. Ezáltal könnyen mozhatható az alkalmazás különböző alkalmazásszerver vendor-ok között, vagy használható az alkalamzás akár alkalmazás szerver nélkül is.

– Megvalósítja azt jól, ami az ejb-nek nem sikerült valami fényesen: alkalmazásobjektumok kezelését, és azok automatikus egymásba ágyazását, működésének meghatározását az alkalmazástól „független” konfiguráció alapján

– Segítségével könnyedén lehet integrálni sok más divatos szóval jelölt technológiát (hibernate. quartz, stb.)

Hirtelen ennyi gondolatébresztőnek, nemsokára várható pár érdekesség a témában 🙂

Excel LÁTVÁNYT.MUTAT

Lehet, hogy a korral jár, de már mindent használok, ami a munkámat könnyíti. Mostanában az Excel ez a nagy felfedezés, amiben számokon alapuló dolgokat elég jól lehet modellezni… Ez a remek kis termék ötletes funkcióival többször is meglepett, és persze az Office szoftvercsomag többi tagjához hasonlóan még többször idegesített fel (pl. valaki megmondhatná, hogy 2010-ben azonos nevű de más helyen lévő xls-t miért nem lehet megnyitni, meg miért nem tud az excel 2 vagy tetszőleges számú ablakban futni, vagy a feltételes formázás miért nem működik több munkalapon is, stb…). De ez a Microsofttól már megszokott, csinálnak valami jót (lásd Visio) és aztán a végén megfejelik olyan apró kis idegesítő bakikkal, amit ilyen szarul csak az MS berkein bellül lehet megoldani (pl. a visio layerek kezelése ékes példa erre…). Mondjuk lehet ez a védjegyük, de amíg nincs jobb, kénytelenek vagyunk ezzel élni.

Visszatérve az Excelre a legidegesítőbb dolog amit csak kitalálhattak, az a képletek lefordítása volt. Ha végre nagynehezen az ember megtalálja azt amit keresett, akkor szembesül csak azzal, hogy az órákig tartó keresgélés eredménye mitsem ér, hiszen a magyar excelbe minden magyar…

Talán maguk a magyar Excel készítői is szembesültek ezzel, ezért is került bele egy táblázat, ami minden képletet eredeti nyelven is tartalmaz 🙂

c:\Program Files\Microsoft Office\Office12\1038\FUNCS.XLS

Ha esetleg valaki nem 12 office-t használ akkor neki az a könyvtár más…

Gwt memory leak

Ezer éve nem volt módom (és időm) írni, de most sikerült, megtaláltam, és megengedek magamnak ekkora pihenőt. Jó ideje egy GWT alapú alkalmazás készülget, és eddig szinte minden „simán” ment a fejlesztés során, volt néhány kisebb trükk, pár gwt-s osztályt át kellett írni, de összességében szerintem a GWT keretrendszer jól teljesített, sőt felül is múlta az elvárásaimat.
Egészen tegnapig, amikor is azt jelezték, hogy az alkalmazás sok memóriát fogyaszt. Ilyenkor az ember hajlamos azt mondani, hogy persze, hiszen nagy alkalmazás, de a C++-hoz szokott énem rögtön kétségbe esett, ez bizony memory leak. Gyors mérések után a tünetek egyértelműek voltak. Az alkalmazás leak-el, menüpontonként pár megát. Az látszott, hogy nem a javascript memóriahasználata nő (google chrome kiírja), hanem a böngésző memória használata. Ekkor kezdtem gyanakodni, hogy ezt pedig mi rontottuk el, és a végén igazolódott is ez az állítás. A hibát csak a tanúsága miatt megosztom mindenkivel.

Az eredeti kód:


private void setLoadingVisible(boolean pVisible) {
if (pVisible) {
waitingPopup=new APopupWaiting(msgs.main_waitingmessage(), Window.getClientWidth(),Window.getClientHeight());
waitingPopup.center();
}
if (!pVisible && waitingPopup.isVisible()) {
waitingPopup.hide();
}

Ez a szolgáltatás arra szolgál, hogy ha tölteni kell, akkor kirak egy töltés dialógust. Első látásra minden rendben van, létrehoz egy újat, megjeleníti, vagy elrejti a megadott paraméter alapján. Az implementáció hibás, az már érdekesebb kérdés miért. Normál esetben maximum egy nem optimális implementáció lenne, hiszen miért hozunk mindig létre valamit, ami már egyszer létre lett hozva, ráadásul sohasem változik. Sokkal nagyobb probléma, hogy ez javascriptben fut, és a GWT a változót (és a hozzá javascript által generált HTML dom-ot) csak akkor szabadítja fel, ha már nincs rá referencia. Ellenben a PopupDialogra igen is lesz referencia, és nem a DOM-on keresztül, hanem azon eseménykezelők miatt, amikre működéséből fakadóan feliratkozott. Tehát az objektum lóg a levegőben, és fogyasztja a memóriát.

Egy lehetséges megoldás:


private void setLoadingVisible(boolean pVisible) {
if (pVisible) {
if (waitingPopup==null) {
waitingPopup=new APopupWaiting(msgs.main_waitingmessage(),
Window.getClientWidth(),Window.getClientHeight());
waitingPopup.center();
} else {
waitingPopup.center();
}
}
if (!pVisible && waitingPopup!=null) {
waitingPopup.hide();
}
}

Végezetül egy kis olvasmány (de az ellen nem véd ;):
http://code.google.com/p/google-web-toolkit/wiki/DomEventsAndMemoryLeaks

XFCE Ubuntu alatt

XFCE telepítése:
sudo aptitude update && sudo aptitude install xubuntu-desktop

Az alapértelmezett session managert az alábbi utasítással állíthatjuk be:
sudo update-alternatives --config x-window-manager

Windows XP optimalizáció (zenéhez) #2

A Windows XP a végtelenségig optimalizálható, ezt mi sem mutatja jobban, min a sok több milliószoros sebességnövekedést igérő cikk, leírás, és szoftver. Persze a hardvernek, és a Windows XP-nek is vannak korlátai, de a fölösleges doglok kikapcsolgatásával el lehet érni, hogy inkább a hardver korlátait érezzük mint a Windows korlátait.
Tehát a további optimalizációk:

http://www.connectedinternet.co.uk/2007/02/06/the-complete-guide-to-optimising-windows-xp/

És egy elég részletes, de nem túl terjengős leírás a windows szolgáltatásokról:
http://beemerworld.com/tips/servicesxp.htm

Windows DPC

Amikor az ember időkritikus (valósidejű) dolgokra használja a számítógépét, szeretne biztosra menni. Ennek elengedhetetlen kelléke egy külön telepített Windows 32 bit-es windows xp, és az előző cikkben említett Windows XP Focusrite optimalizációk. De mi a teendő akkor, ha ezek után is a félelmetes Audio Dropout jelenséggel szembesülünk (minden jól működik, csak néha van pár ms szünet amikor nem)?
A valósidejű alkalmazások rendszerint kernel driverek szintjén kommunikálnak. Ha egy valósidejű driver drop-out-ol annak legvalószínűbb oka, hogy egy másik kernel szintű driver belerondít a képbe. Ezt rendszerint Deferred Procedure Calls (DPCs) nevű csodás interfészeken keresztül teszik.
Amennyiben ez a probléma, ezt elég egyszerűen megállapíthatjuk, az alábbi alkalmazással:
DPC latency checker
Segítségével mérhetjük a macimális DPC latency-t. Ha dropout van, és ezt látjuk a DPC latency-k alakulásán is, nem kell mást tenni, mint a Device manageren sorra kikapcsolni a kernel szintű drivereket használó eszközöket. A legintenzivebb ilyen cuccok általában a WLan kártyák, modemek, usb eszközök és vezérlők, integrált hangkártyák, nem standard ide driverek… Ezekre soha sincs szükség, kapcsoljuk ki őket… (érdemes minden esetben, nem csak ha probléma van, nehogy véletlenül legyen).
És kezdőthet is a móka (valós időben!)