levéljelző led asus laptopokon 2. kör

Tegnap megnéztük hogyan tudja a pidzsön villogtatni a ledet, ma megnézzük hogyan lehet ténylegesen levéljelzésre használni, Varnagy kolléga igényeinek megfelelően villogtatással.

A leveleket leszedni a mail-notification program fogja, a villogtatást pedig egy kis script végzi.

  1. Telepítsük a mail-notification csomagot.
  2. Állítsuk be a kívánt postafiókot.
  3. Töltsük le az általam írt két shell scriptet, adjunk nekik futtatás jogot.
  4. Majd a képen látható opciókhoz állítsuk be a két scriptet, hogy futtassa le a mail-notification program.

levéljelző led asus laptopokon

Azok akik asus laptopot használnak, azok a 4 ledből 1-et biztos nem használnak linux alatt ez pedig a levél jelző lámpa. Az acpi kezelésére van bízva ennek a lámpának a villogtatása, és a /proc/acpi/asus/mled fájl tartalma (0 vagy 1) adja, hogy a lámpa világít vagy sem. Ez felelős az fn fényerő, -hang, böngésző és levelező gombokért is, úgyhogy ha valamelyik ezek közül nem megy akkor az acpi-t kell előrángatni. Szóval visszatérve a led-re, ahogy felfedeztem hogy hol lehet kapcsolgatni rögtön valami megoldás után néztem, hogy hogyan tudnám ezt beépíteni és használatba venni. Az IRC-en kaptam egy tippet, hogy pidgin alá létezik egy program ami akkor villogtatja meg a led-et ha üzenetünk érkezik.
A program innen tölthető le:
http://koti.mbnet.fi/simom/pidgin/led-notification/
Ha valaki nem akar a forgatással szórakázni, akkor letöltheti a 0.1-ből készült binárist tőlem. Ezt a fájlt kitömörítés után a ~/purple/plugins/ mappába kell másolni, majd újraindítani a pidgin-t.
A forgatáshoz egyébként pidgin-dev csomag kell (a szükségeseken túl, persze).

Most pedig ezt a ledet összepasszintom a thunderbird-el.

képernyőképkészítő 2.0

Ismét egy apró scriptet szeretnék a nagyérdemű elé tárni.
Az Import programra való rácsodálkozásom óta, azt igen sokat használtam. A felismerés (és ircen gerjesztődött igény) hatására arra jutottunk, hogy az ember az elkészült képek nagy részét segítségkérés végett feltölti egy szerverre (legalább is én). Ezt követően adott volt a fejlesztés következő lépése, aminek eredménye ebben a fájlban valósult meg.

Teszteltem. Működik. Használjátok egészséggel!

grub visszatelepítés v2.0

Az idő előrehaladtával csak lustul a programozó. De ha még nem is lustulna el, megjelennek azok a felhasználók akik a root partíció hallatára sátánűző rigmusokat kezdenek el skandálni, mondván szegény embert megszállta a gonosz, a gyökér partíció hallatán meg első asszociáció a kertészkedés témakörében áll be.

Kényelmi ember lévén megalkottam ezt a csodafegyvert.
Live cd-n használva a lusta programozó megspórol egy kis gépelést, a hozzá nem értő meg egy komplett újratelepítést. Nem tesztelt, saját felelősségre és egyéb intő jelek.
Vannak nyilvánvaló mellékhatások: pl nem garantált hatás több telepített linux disztró esetén, hajhullás, sárgaság.

gutsy iftab és udev problémák

Valami miatt újraindult a fejlesztői szerverem ami egyben router is. A dist-upgrade után annó nem volt restart így most jött elő egy érdekes probléma. Arról, hogy egy hálókártya azonos helyen legyen mindig (eth*) eddig az iftab nevű beállítófájl gondoskodott. Gutsy-ban ezt a funkciót az udev vette át. A frissítéskor megfelelően áthozza a kártyákat, viszont az udev valami miatt felismerte a pci kártyát még egyszer így azt a kártyát amin a dsl modem csücsül mégegyszer hozzáadta eth2 néven. Így induláskor (és netrestartkor) problémázott a pppoe mert a kártyák beállításakor az eth1-re nem került kártya (vagy felülírta és azt eth2-n volt, vagy hozzá sem adta, mondván kétszer szerepel a beállítófájlban).

/etc/udev/rules.d/70-persistent-net.rules

# Converted from /etc/iftab on upgrade
SUBSYSTEM==”net”, DRIVERS==”?*”, ATTRS{address}==”00:0E:2E:C0:83:BA”, NAME=”eth1″

# PCI device 0x10ec:0x8139 (8139too)
SUBSYSTEM==”net”, DRIVERS==”?*”, ATTRS{address}==”00:0e:2e:c0:83:ba”, NAME=”eth2″

Megoldás annyi, hogy az iftab-ból áthozott sort törölni kell és a udev által hozzáadott sort átszámozni (udev ezt a sort hozzáadja automatikusan ha ezt töröljük).

/etc/init.d/udev restart
/etc/init.d/networking restart

videodarabolás ffmpeg-el

Újabb ffmpeg 5 perc keretében megtanulunk kinyesni egy kicsit a filmből. Ha már előzőleg megtanultunk pozícionálni akkor most azt felhasználva továbbfejlesztjük tudományunk. És a parancs vala:

ffmpeg -i fileneve.avi -ss 00:02:00 -t 00:00:30 op.avi

-ss már tudjuk mire szolgál.
-t kimentett anyag hossza.

Az eredmény pedig a bemenet 2. percétől 30 másodperc hosszú anyag.

képlopás filmből ffmpeg segítségével

ffmpeg -i "avi" -y -ss 0:00:03 -vframes 1 -an -vcodec mjpeg op/op01.mjpeg

Magyarázat:

-i Forrásfájl amit meg akarunk nyitni.
-y Felülírja a célfájlt ha létezik.
-ss Pozícionálás. A képet ebből a pozícióból fogja szedni.
-vframes Kimentendő frame-k száma.
-an “hangsáv” letiltása.
-vcodec Kimeneti “videósáv” kódolása. (további infó ffmpeg -formats)
op/op01.mjpeg Cél képfájl.

képernyőkép készítése

Biztos mindenkinek szüksége volt már olyan lehetőségre, hogy képernyőképet készítsen a gépéről, mert megakarta valakinek mutatni mert elakadt valamiben, vagy mert éppen leírást szeretne készíteni valaki számára, hogy grafikus felületen bizonyos műveleteket hogyan tud elvéhezni. Linux alatt (de windowson is működik) egy kézenfekvő megoldás ilyenkor a printscreen billentyű megnyomása, melynek hatására az egész képernyőről kép készül (windowson vágólapra kerül, linuxon elindul a megfelelő program).

Mi van olyankor, ha mi nem az egész asztalról szeretnénk képet készíteni hanem csak egy ablakról vagy a képernyő egy részéről? Ilyenkor jöhet jól az imagemagick import programja. A programot használva lehetőségünk van egy adott területről vagy egy ablakról képet készíteni és azt fájlba kiírni. Nézzük mit kell ehhez tennünk:
Először is telepítsük fel az imagemagick csomagot. Mivel a program parancssoros így készíteni fogunk hozzá egy alkalmazásindítót a Gnome panelra, hogy minnél kényelmesebb legyen használni. Hozzunk létre egy fájlt valahol a fájlrendszeren (én a Saját mappámba tettem /home/connor), a következő tartalommal:

#!/bin/sh

import -frame ~/screen/screen_`date +%Y%m%d%H%M`.png

Hozzunk létre egy könyvtárat a Saját mappánkban screen néven, és adjunk futtatás jogot a most létrehozott fájlnak:

Ezek után jobb klikk a Gnome panelra, “Hozzáadás a panelhez…”, “Egyéni alkalmazásindító”, majd töltsük ki a megfelelő módon:

Értelem szerűen a Parancs mezőbe a saját mappánk elérési útját írjuk be.
Indításkor az egérből egy kereszt lesz amivel ha egy ablakra kattintunk, akkor az egész ablakról, ha nyomva tartjuk és egy területet jelölünk ki, akkor a kijelölt területről készül kép.

real media lementése

Ma délben volt a Katolikus rádióban az előző bejegyzésemben szereplő Szederindával egy interjú. Adott a feladat, az arhívumból lementeni valamit emberi formátumba a riportot. Egy kis google-zás és megvan a válasz, hogy hogyan kell real audiót (vagy videót) lementeni a gépre:

mplayer -noframedrop -dumpfile file.rm -dumpstream URL

Az url-t onnan lehet megtudni, hogy lementjük azt a filet amit a böngésző jobb esteben hallgatásra megnyit. Majd egy egyszerű szerkesztővel (pl gedit) megnézzük a tartalmát. rtsp:// protokollal kezdődő URL-(eke)t fogunk találni.
A lementett adat még mindig csak rm típusú így azt az ffmpeg-el alakíthatjuk a tetszőleges wav vagy mp3 formátumba:

ffmpeg -i file.rm file.wav

Ha a wav helyett mp3-at írunk, akkor mp3-ba menti, értelem szerűen.

Deb alapú disztribúció telepítése menet közben

Korábban okozott hatalmas fejtörést, hogy hogyan lehetne migrálni egy szervert sarge-ről edgy-re úgy, hogy a kiesés időtartama a lehető legkevesebb legyen. Soha nem gondoltam volna, hogy egy olyan programot kell erre használni aminek a neve eddig is ismert volt számomra, csak eddig nem használtam. A program neve debootstrap, és nagyjából ez a telepítés folyamata:

  • új merevlemez be a gépbe
  • szükséges, partíciók és fájlrendszer kialakítása, majd azok mountolás /target mappába
  • debootstrap edgy /target http://archive.ubuntu.com/ubuntu/ –include=egyénileg szükséges csomagok listája (apache, php, mysql, bind…)
  • sikeres telepítés, kézi finomhangolás elvégzése után betöltési sorrend megváltoztatásával újraindítás

S kész is az új rendszer. Ha ügyesek voltunk akkor a szolgáltatás kiesés 2 újraindulásnyi idő volt.

spam áradat elleni harc

Az utóbbi időben, ahogy a google egyre jobban megismerte a blogomat, elindult a várva várt spamáradat a hozzászólásokba. Egy ideig azzal kísérleteztem, hogy mi van akkor ha a spammer fix wordpress felületet ismerve postolja el a szöveget. A bemenő form nevek megváltoztatása úgy tűnt, hogy nem túl sikeres megoldás, így más megoldás után kellett nézni. A következő ötletem az volt, hogy aki az oldalra üzenetet akar küldeni, az postoljon kétszer. Ilyet máshol még nem láttam és bíztam abban, hogy eredményes lesz. A megoldás valahogy úgy nézett ki, hogy a teljes post tömb tartalmából készített md5 hash-t elmentettem a session tömbbe, és ha már volt egyszer benne akkor beengedtem az üzenetet ha még nem akkor ismétlést kértem.
Rá pár napra észrevettem, hogy -igaz csekély mértékben- de egy bizonyos fajta spam még mindig érkezik. Akkor azt hittem a megoldásom nem eredményes, de most már tudom, hogy nem az a megoldás is lehet hatásos. Ezt akkor nem tudtam, így kerestem tovább, hogy mi lehet a hatásosabb védelem.
Következő “ötlet”, egy már ismert, viszonylag bevett védelem lett: Tegyél fel egy kérdést, amire ha jól válaszol, akkor engeded be az üzenetet. Ez lehet találós kérdés, matematika vagy egyéb mód (pl kitehettem volna egy képet rajta egy almát is). Biztos ami biztos, ha már ott voltam megcsináltam azt is, hogy jquery küldje el az üzenetet (ezt egyébként is akartam korábban).
Ez sem volt hatásos. Egy bizonyos ip címről továbbra is érkezett spam. De ekkor már kételkedtem abban, hogy a megoldásom lenne hatástalan, lévén, hogy magyar a kérdés és a válasznak is annak kell lennie, valahogy máshogy jön be az üzenet. Mivel az IP cím nem változik, tehettem volna azt hogy apacheból kitiltom az ip-t aztán csináljon amit akar, de mégis kíváncsi voltam, így nem ezt a módot választottam.
A logok átnézése után (nem kellett nagyon böngészni) ezt találtam:

user@merlin:~$ cat /var/log/apache2/blog.connor.hu_access.log | grep 82.146.53.67
82.146.53.67 - - [18/Mar/2007:07:12:22 +0100] "POST /2007/01/01/2006-volt-2007-lesz/trackback/ HTTP/1.1" 200 78 "-" "-"
82.146.53.67 - - [18/Mar/2007:08:14:03 +0100] "POST /2007/01/01/2006-volt-2007-lesz/trackback/ HTTP/1.1" 200 78 "-" "-"
82.146.53.67 - - [18/Mar/2007:15:15:23 +0100] "POST /2007/01/01/2006-volt-2007-lesz/trackback/ HTTP/1.1" 200 149 "-" "-"
82.146.53.67 - - [18/Mar/2007:15:46:12 +0100] "POST /2007/01/01/2006-volt-2007-lesz/trackback/ HTTP/1.1" 200 149 "-" "-"
82.146.53.67 - - [18/Mar/2007:16:33:56 +0100] "POST /2007/01/01/2006-volt-2007-lesz/trackback/ HTTP/1.1" 200 149 "-" "-"

És megvan! A trackback-on keresztül küldte el az üzenetet. Viszont itt már nem lehet akárhogy blokkolni a folyamatot, ha meg akarom tartani a funkciót. Valami más megoldást kell találni. Egyenlőre betettem egy fekete listát a küldő ip címével, de mivel hamisítható a REMOTE_ADDR így kizárt, hogy végső és jó megoldás lenne. De ezen elég akkor törpölni ha hatástalan lesz az is. Így tűnik a trackbackra spammelés még nem olyan elterjedt mód a spammerek körében.
Ím a kód (wp-trackback.php #8):

$black_list = array(
  'ipcim',
  'ipcim2',
  'ipcim3',
  );

if (in_array($_SERVER['REMOTE_ADDR'], $black_list)) exit;

linux windows meghajtók olvasása oda vissza

Mivel az asztali gépemen elhúzódik a linuxra migrálás, ezért egy kicsit idegesít, hogy bizonyos cuccaim (leginkább zene) ext és ntfs partíción is megtalálhatóak. Most, hogy volt egy kis időm utánnaolvastam annak, hogy windows alatt hogyan tudnám olvasni ext2/3 partícióimat (írás nem volt követelmény, olvasás elég) és a linux alatt hogyan lehet olvasni (írás itt sem követelmény, de ha megoldható…) az ntfs partíciókat.

Elvárás volt még az is hogy az adott eszköz képes legyen kezelni az utf-8 karakterkódolású szöveget, hiszen az ubuntu alatt az az alapértelmezett. Ext olvasásra és írásra az ext2fsd programot találtam ami képességeit tekintve igen meggyőző! Be lehet állítani, hogy mely partíciókat hova tegye, alapból induláskor már csatolt állapotban legyenek vagy sem, illetve csak írható vagy olvasható kötetetket akarunk. Az már csak hab a tortán hogy nem csak az utf kódolást ismeri hanem egy rakás másikat is! Meggyőző! Ezzel kapcsolatban azért még nem teljes az örömöm mert régen hallottam egy olyan véleményt, hogy a windows teljesen összekuszálja az ext partíciót ha írhatóvá tesszük. Ha valakinek esetleg van valami tapasztalata az megoszthatná. 🙂

Ntfs partíciók olvasása már régen megoldott linux alatt, de az írásra mostanában született egy igéretes magyar fejlesztésű eszköz ami megoldja az írással járó problémákat is, mindezt felhasználói térben valósítja meg (szintén magyar vonatkozású FUSE-t használja). Ez az eszköz a ntfs-3g. Ennek telepítéséről a hupwikiben lehet olvasni, első ránézésre teljesen jól működik semmi gond nincs vele. Akinek esetleg van tapasztalata ezzel kapcsolatban azt is szívesen veszem ha megosztja.

php izé, meg a pecl

Következő néhány percben a pecl.php.net-en található egyik php modult fogjuk lefordítani. A pecl a php birnáris kiterjesztéseinek gyüjtőhelye. Hasonló mint a pear csak kevesebb modul található meg a gyüjteményben, és van amit már nem is fejlesztenek. Viszont amit fejlesztenek az egész jól használható és mivel bináris, ezért nagyon gyors is! Continue reading

udma bekapcsolása

Laptopon kubuntut használok és mióta áttértem edgy-re egy kicsit minthat lomha lenne a rendszer, és a winyó piszkálása megakaszthatja a rendszert.Windowsos korszakból a tapasztalat azt mondatta velem hogy az dma nincs bekapcsolva. És igen. Megnézvén a dma módot tényleg nem volt bekapcsolva (csak azt tudnám hogy mi kapcsolta ki?).
Nosza kapcsoljuk be!

A következőkben leírtak piszkálgatását mindenki saját felelősségre tegye! Nekem nem volt gondom de ez nem jelenti azt hogy másnak sem lesz. 🙂

Első körben nézzük meg azt hogy ha gyanakszunk arra hogy nem megy a dma mód mi is a helyzet:

sudo hdparm -i /dev/hda

Értelem szerűen mindenki a saját meghajtóját írja be amire kíváncsi. Az udev-nek hála lehetőségünk lenne akár ID szerint lekérdezni a meghajtót, de mi most nem ezt tesszük, megfelele a régi jólmegszokott változat. A parancs kimenete (nálam):

/dev/hda:

Model=IC25N040ATMR04-0, FwRev=MO2OAD4A, SerialNo=MRG254KBE42LJP
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=DualPortCache, BuffSize=1740kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=78140160
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2
AdvancedPM=yes: mode=0x80 (128) WriteCache=enabled
Drive conforms to: ATA/ATAPI-6 T13 1410D revision 3a: ATA/ATAPI-2 ATA/ATAPI-3 ATA/ATAPI-4 ATA/ATAPI-5 ATA/ATAPI-6 * signifies the current active mode

A kimenet közepén látható DMA és UDMA módok a lényegesek számunkra. Ha már van udma akkor mért ne kapcsoljuk be azt:

connor@lapi:~$ sudo hdparm -X udma2 /dev/hda

/dev/hda:

Model=IC25N040ATMR04-0, FwRev=MO2OAD4A, SerialNo=MRG254KBE42LJP
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=DualPortCache, BuffSize=1740kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=78140160
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 *udma2
AdvancedPM=yes: mode=0x80 (128) WriteCache=enabled
Drive conforms to: ATA/ATAPI-6 T13 1410D revision 3a: ATA/ATAPI-2 ATA/ATAPI-3 ATA/ATAPI-4 ATA/ATAPI-5 ATA/ATAPI-6 * signifies the current active mode
A kimenetből látszik, hogy a mód bekapcsolása sikeres volt. Most már csak azt kell biztosítani, hogy ez minden indításkor aktivizálódjon. Ehhez a kedvenc szerkesztő programunkkal nyissuk meg a /etc/hdparm.conf fájlt és a végére írjuk be a következőket:

/dev/hda { transfer_mode = 66 } Hogy mi az a 66? Lehetőségünk van a módokat számokkal is megadni. A következő táblázat megmutatja, hogy melyik módnak mi a száma és fordítva:

0 1 2 3 4 5
PIO 08 09 10 11 12
SDMA 16 17 18
MDMA 32 33 34
UDMA 64 65 66 67 68 69

És készen is vagyunk. A legközelebbi újraindítás után ellenőrizhetjük, hogy eredményes volt-e a beállítás.

Grub helyreállítása XP telepítés után.

A minap szembesültem, hogy mért is nagyon jó az, amit a ubuntuban megvalósítottak, miszerint a live CD és a telepítő cd egy korongon kapott helyett. A grub helyreállítását pár kattintásból el tudtam végezni, és az egész folyamat nem tartott több ideig mint 5 perc.

A windows telepítése során hajlamos arra, hogy csak a más windows-okat vegye észre és az indítómenübe csak azokat tegye be, lehetetlenné téve a más operációs rendszerek alá való bootolást. Persze megoldható lenne, hogy a Windows maradjon az MBR-ben és az ő indítómenüjéből indítsam a többi linuxot is, de ezt megoldani sok időbe telik.

Eddig a grub helyreállítását debian alatt egy telepítés megkezdésével, majd rögtön megszakítással, és grub betelepítése menüpontra ugrással végeztem el. Még ez is gyorsabb megoldásnak bizonyult mint ha a windows-ba kéne beletenni bootoláshoz szükséges információkat.

Adott egy gép amire feltelepítettem megfelelő sorrendben az XP-t és rá az ubuntut. Aztán az XP-t újra kell telepíteni ekkor jön az a gond hogy az xp felülírja az MBR-ben a grub-ot. Nosza elő egy ubuntu desktop CD-t, be a gépbe és bootoljunk róla. Jobb esetben kapunk egy grafikus felületet ahol el tudjuk végezni a helyreállítást.

Elsőként keressük meg, hogy melyik partíció tartalmazza a root partíciót a /boot mappával, majd azt csatlakoztassuk fel mondjuk a /mnt mappába közvetlenül.

Ezek után adjuk ki a következő parancsot:

connor@midian:~$ grub-install --root-directory=/mnt /dev/hda

A /dev/hda a végén az a meghajtó kell legyen, aminek az MBR-jébe a grubot szeretnénk telepíteni.

Majd ha minden rendben zajlott és újraindítjuk a gépet akkor ismét a grub fog minket fogadni.