Blog költözködés
Sziasztok,
Éppen költöztetjük ezt a blogot a céges wordpress blog alá, ezen időszak alatt ideiglenes problémák még előfordulhatnak a blogon.
Elnézést a kellemetlenségekért, remélhetőleg hamarosan minden visszaáll a régi kerékvágásba.
[.] TovábbGrafikon készítése SAR kimenetből
Ahogy azt már egy korábbi posztomban említettem (http://pzolee.blogs.balabit.com/hu/2009/11/teljesitmenyteszt-elemzes/), a sar egy nagyon hasznos eszköz rendszer illetve teljesítményadatok gyűjtésére.
Ha minden adatot szeretnénk összegyűjteni a rendszerről, akkor azt ilyen formában tudjuk megtenni:
sar -o test.log -A 1 3 2>&1 >/dev/null
Ez egy bináris fájlt fog készíteni a kimenetből, amit az sadf paranccsal tudunk kiíratni:
sadf -t -d test.log — -A
Időnként azonban grafikont szeretnénk készíteni ezekből az adatokból, mivel azokat egyszerűbb értelmezni és könnyebb áttekinteni is.
Erre az egyik legjobb eszköz a kSar, ami klasszisokkal jobb mint mondjuk office-ban kézzel készíteni a kimenetből diagrammot.
A program letölthető a következő oldalról: http://ksar.atomique.net/
Ez tulajdonképpen egy java alapú program grafikus felülettel, ami képes feldolgozni a sar kimenetét, és abból grafikonokat készíteni, ami aztán elmenthető képként vagy akár PDF formátumban is.
Azt azonban tudnunk kell, hogy csak a sar szöveges formátumú kimenetét tudja feldolgozni, ami a bináris fájlból így állítható elő:
sar -A -f test.log >> sardata.txt
Ezután ezt már a Data menü “Load from text file…” segítségével tudjuk betölteni a kSar-ral, és máris megkapjuk a grafikonjainkat.
A programnak ezen kívül van még néhány igen hasznos funkciója, például SSH-n keresztül távolról is tudja futtatni a sar parancsot a távoli gépen, ezekről a weboldalon olvashatunk többet.
Text fájl betöltése:
És végül néhány kép a grafikonokról:
GRUB2 és Truecrypt Windows-Linux dual-boot esetén
Mint azt előző posztomban már említettem, a gépemen van egy NTFS partíció amin Windows 7 fut és mellette még egy titkosított is, amin Linux, egészen pontosan Ubuntu 10.04 van. Biztonsági okokból szerettem volna letitkosítani az NTFS partíciót is, nem csak a Linuxot. Mivel a Bitlocker nem elérhető csak Windows 7 Ultimate verziótól kezdődően, az ingyenes Truecrypt mellett döntöttem (www.truecrypt.org). A Google segítségével találtam egy csomó leírást, hogy hogyan lehet megvalósítani a titkosítást és a dual-boot-ot is egyszerre, így úgy éreztem, hogy ez nem fog gondot okozni. Az elmélet nagyjából úgy szólt, hogy miután a Truecrypt feltelepült, egy live cd-ről bebootolva lemásolom az MBR első szektorát, majd ezt a fájlt a GRUB chainloader segítségével fogom betölteni, így a GRUB menüjéből ki fogom tudni választani mind az Ubuntut, mind a Windowst.
Nos, tévedtem, mégpedig két helyen is. Az egyik, hogy az Ubuntu telepítésekor a 10.04 default boot loader-ét választottam ki (ami a GRUB2), a másik pedig hogy Ext4 fájlrendszerrel telepítettem azt. A probléma pedig az, hogy a GRUB2 egy kicsit máshogy települ az MBR-be, így a Truecrypt boot loadere úgy érzékeli, hogy megsérült (és ezért nem is tudja betölteni a Windowst), ezért aztán hiába adjuk meg a chainloadernek, nem fog menni. Ilyenkor indítás után, ilyesmi hibaüzenetet fog adni a Truecrypt boot loadere:
“TrueCrypt Boot Loader Load damaged! Use Rescue Disk: Repair > Options > Restore Truecrypt Boot Loader”.
Bővebben: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/484102
A másik probléma pedig az, hogy mindez GRUB1-el egyébként működik, csak épp az meg nem ismeri még az Ext4-et…
A megoldás végül is egy kis workaround lett, mégpedig az, hogy nem a GRUB chailoader fogja betölteni a Truecrypt-et, hanem a Truecrypt boot loadere a GRUB-ot.
Ha már megcsináltuk a Truecrypt-tel a Windows titkosítását (például a következő leírás alapján: http://www.steve-oh.com/blog/index.php/ubuntu-vista-dual-boot-full-encryption-with-truecrypt/), akkor most nagyjából ott állhatunk, hogy a GRUB az MBR-ben van, és az Ubuntut el is tudjuk indítani, de a chainloadelt truecryptes particion lévő Windowst már. Ebben az esetben a következő lépésekre lesz még szükségünk:
Inditsunk el az Ubuntut, és telepítsük fel a GRUB2-öt a linuxos partícióra de ne az MBR-be.
Az én esetemben így néznek ki a partíciók:
root@thor-t410:/home/pzolee# fdisk -l
/dev/sda lemez: 320.1 GB, 320072933376 bájt
240 fej, 63 szektor, 41345 cilinder
Egység: cilinderek 15120 * 512 = 7741440 bájt
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Lemezazonosító: 0x5cced388
Eszköz Indítás Eleje Vége Blokkok Az Rendszer
/dev/sda1 * 1 16808 127066112 7 HPFS/NTFS
/dev/sda2 16808 16873 487424 83 Linux
/dev/sda3 16873 41346 185015297 5 Kiterjesztett
/dev/sda5 16873 41346 185015296 83 Linux
A /dev/sda2 a boot partícióm, így oda telepítem a GRUB-ot:
root@thor-t410:/home/pzolee# grub-install –force /dev/sda2
/usr/sbin/grub-setup: warn: Kísérlet a GRUB telepítésére partícióra az MBR helyett. Ez egy ROSSZ ötlet..
/usr/sbin/grub-setup: warn: A beágyazás nem lehetséges. A GRUB csak blokklisták használatával telepíthető erre az eszközre. A blokklisták azonban NEM MEGBÍZHATÓK, és használatuk nem ajánlott..
Installation finished. No error reported.
A warningok nem befolyásolják a folyamat sikerességét. A Truecrypt boot loadere úgy működik, hogyha a jelszó beírása helyett az ESC billentyűt nyomjuk meg, akkor a következő partíción lévő rendszert próbálja meg betölteni (mint egyfajta chainloader), ami a GRUB lesz a /dev/sda2-ön.
Ezután már csak egy dolgunk van, tegyük be a truecrypt helyreállító cd-t (amit akkor készített amikor titkosítottuk a partíciót) indítsuk újra a gépet, és válasszuk ki a truecrypt boot loader helyreállítását. Ezután a következő induláskor már a Truecrypt boot menüje fog fogadni, ahol a jelszót beírva a Windowst tudjuk elindítani, escapet nyomva pedig bejön a GRUB menüje, ahol indíthatjuk az Ubuntut.
Truecrypt telepítés Lenovo T410/Core i5 cpu esetén
És még egy kis hasznos információ (bár nem tartozik szorosan a cikkhez), de a Truecrypt nem tudja megtalálni a titkosított partíciót, ha be van kapcsolva a virtualizáció támogatás és/vagy a hálózatról való bootolás a fenti gépen (és/vagy processzor esetén)… Ilyen esetben a jelszó beírása után MMAP:1, illetve MMAP:2 hibákat fog visszaadni a pretest során és nem tudja elindítani a rendszert. A “megoldás” pedig az jobb híján az, hogy tiltsuk le ezt a két opciót a BIOS-ban.
[.] TovábbGrub helyreállítás titkosított és LVM partíciók esetén
Biztosan mindenki szembesült már azzal az esettel, amikor egy elrontott telepítés miatt csak a GRUB boot shellje (vagy még az sem) fogad a gép újraindítása után és kellő szakmai tapasztalat vagy Google nélkül nem tudjuk visszavarázsolni az eredeti bootloadert a hozzá tartozó menürendszerrel.
Mostani posztomban ebből is egy speciális esetet veszünk szemügyre, amikor önkínzó (avagy paranoid) hajlamunknak köszönhetően úgy telepítettük az Ubuntut, hogy alatta legyen hagyományos Ext4 partíció és egy titkosított is és ezen belül LVM-mel hoztunk létre még további Ext4 partíciókat is. Nincs is ezzel semmi gond, egészen addig, amíg véletlenül el nem rontjuk a GRUB-ot, például egy Windows telepítéssel. Ilyenkor a GRUB helyreállítása komoly nehézségekbe ütközhet.
Mivel az én esetemben a fenti feltételek teljesültek, így nézzük hogy egy ilyen elrontott rendszer esetén hogyan lehet ezt helyrehozni.
Az én esetemben a partícióik így néznek ki:
root@thor-t410:/home/pzolee# fdisk -l
…
Eszköz Indítás Eleje Vége Blokkok Az Rendszer
/dev/sda1 * 1 16808 127066112 7 HPFS/NTFS
/dev/sda2 16808 16873 487424 83 Linux
/dev/sda3 16873 41346 185015297 5 Kiterjesztett
/dev/sda5 16873 41346 185015296 83 Linux
…
Az első partíción egy Windows van, amit bizonyos okok miatt újra kellet telepítenem, és ez okozta az egész problémát, mivel a Windows (7) telepítője nem ismer semmilyen egyéb nem Windows operációs rendszert vagy bootloadert, így minden figyelmeztetés nélkül felül fogja csapni telepítéskor az MBR-ben helyet foglaló egyéb bootloadert, jelen esetünkben a GRUB-ot.
Első körben nézzük meg bővebben, hogy normál esetben hogyan néznek ki a partícióik (ezt a parted parancs segítségével tudjuk megtenni):
root@thor-t410:/home/pzolee# parted -l
…
Szám Kezdet Vég Méret Típus Fájlrendszer Zászlók
1 1049kB 130GB 130GB primary ntfs boot
2 130GB 131GB 499MB primary ext4
3 131GB 320GB 189GB extended
5 131GB 320GB 189GB logical
Model: Linux device-mapper (linear) (dm)
/dev/mapper/thor–lvm-Home lemez: 120GB
Szektorméret (logikai/fizikai): 512B/512B
Partíciós tábla: loopSzám Kezdet Vég Méret Fájlrendszer Zászlók
1 0,00B 120GB 120GB ext4Model: Linux device-mapper (linear) (dm)
/dev/mapper/thor–lvm-Rendszer lemez: 60,0GB
Szektorméret (logikai/fizikai): 512B/512B
Partíciós tábla: loopSzám Kezdet Vég Méret Fájlrendszer Zászlók
1 0,00B 60,0GB 60,0GB ext4Hiba: /dev/mapper/sda5_crypt: unrecognised disk label
Illetve a mount parancs kimenetét normális működés közben:
root@thor-t410:/home/pzolee# mount
/dev/mapper/thor–lvm-Rendszer on / type ext4 (rw)
/dev/mapper/thor–lvm-Home on /home type ext4 (rw)
/dev/sda2 on /boot type ext4 (rw)
…
Összegezve a fentieket, látható hogy normál működés közben a /dev/sda2 egy ext4 fájlrendszer ami a /boot alá van felmountolva, az sda5 pedig egy kiterjesztett partíció ami titkosítva van (lásd az sda5-os hibaüzenetet) és egyébként ezen belül van a két LVM-es partícióm, amiből az egyik a rendszer ami a “/” alá van mountolva, a másik pedig a “/home” alá.
Nézzük hát a helyreállítás lépéseit, jelen esetben Ubuntu 10.04 esetén.
Tegyük be az Ubuntu install cd-t a gépbe és bootoljunk be róla.
Miután elindult a live rendszer, indítsunk egy terminált:
Applications/Accessories/Terminal a fenti menüsorban.
Hogy root jogosultságunk legyen: sudo su
Ilyenkor ha ismét kiadjuk a parted parancsot, a következőket láthatjuk:
root@ubuntu:/home/ubuntu# parted -l
Model: ATA ST9320423AS (scsi)
Disk /dev/sda: 320GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 1049kB 130GB 130GB primary ntfs boot
2 130GB 131GB 499MB primary ext4
3 131GB 320GB 189GB extended
5 131GB 320GB 189GB logical
Warning: Unable to open /dev/sr0 read-write (Read-only file system). /dev/sr0
has been opened read-only.
Error: /dev/sr0: unrecognised disk label
Mint azt láthatjuk, nem mutatja az LVM köteteket és a titkosítottat sem ismeri fel.
Hozzuk létre a /mnt/system mappát, ahová a rendszert akarjuk majd felmountolni.
root@ubuntu:/home/ubuntu#mkdir /mnt/system
Probáljuk meg ide felmountolni a /dev/sda5-ot:
root@ubuntu:/home/ubuntu# mount /dev/sda5 /mnt/
mount: unknown filesystem type ‘crypto_LUKS’
Mint láthatjuk ez nem megy, mivel ez egy titkosított kötet. Hogy feloldjuk a titkosítást adjuk ki a következő parancsot (és persze írjuk be a helyes jelszót):
root@ubuntu:/home/ubuntu# cryptsetup luksOpen /dev/sda5 encrypted-volume
Enter passphrase for /dev/sda5:
Key slot 0 unlocked.
A kötet neve encrypted-volume lesz, ami a /dev/mapper alatt lesz megtalálható:
root@ubuntu:/home/ubuntu# ls -la /dev/mapper/encrypted-volume
brw-rw—- 1 root disk 252, 0 2010-07-10 12:04 /dev/mapper/encrypted-volume
Most hogy feloldottuk a partíció titkosítását még mindig nem férünk hozzá az LVM kötetekhez. Ha megpróbálnánk mountolni, hibaüzenetet kapnánk:
root@ubuntu:/home/ubuntu# mount /dev/mapper/encrypted-volume /mnt/system/
mount: unknown filesystem type ‘LVM2_member’
Alapból az Ubuntu cd nem tartalmazza az LVM támogatást, nekünk kell azt feltelepíteni. Ehhez vagy előre letöltjük a csomagokat, vagy ha van internet elérésünk, akkor a következő paranccsal telepíthetjük:
root@ubuntu:/home/ubuntu# apt-get install lvm2
Miután feltelepült, derítsük fel milyen LVM köteteink vannak:
root@thor-t410:/home/pzolee# vgscan
Reading all physical volumes. This may take a while…
Found volume group “thor-lvm” using metadata type lvm2
A kötet neve “thor-lvm”. Aktiváljuk:
root@ubuntu:/home/ubuntu# vgchange -ay
2 logical volume(s) in volume group “thor-lvm” now active
Ellenőrizzük hogy tényleg aktívak lettek:
root@thor-t410:/home/pzolee# lvscan
ACTIVE ‘/dev/thor-lvm/Rendszer’ [55,88 GiB] inherit
ACTIVE ‘/dev/thor-lvm/Home’ [111,76 GiB] inherit
És persze a kötetek megjelennek a /dev/mapper mappa alatt is:
root@ubuntu:/home/ubuntu# ls /dev/mapper/
control encrypted-volume thor–lvm-Home thor–lvm-Rendszer
Most hogy ezzel megvagyunk mountoljul fel a rendszerünket a /mnt/system alá:
root@ubuntu:/home/ubuntu# mount /dev/mapper/thor–lvm-Rendszer /mnt/system/
Erre azért van szükség, mert később majd a chroot segítségével fogunk belépni ebbe a rendszerbe és gyakorlatilag ezen belül hajtjuk végre a GRUB helyreállítását és nem a külső live rendszer alatt. A chroot működéséről bővebben: link
Mountoljuk fel még a /mnt/system alá a szükséges eszközöket is:
root@ubuntu:/home/ubuntu# mount /dev/mapper/thor–lvm-Home /mnt/system/home/
root@ubuntu:/home/ubuntu# mount /dev/sda2 /mnt/system/boot/
root@ubuntu:/home/ubuntu# mount -o bind /dev/ /mnt/system/dev/
root@ubuntu:/home/ubuntu# mount -o bind /proc/ /mnt/system/proc/
Majd lépjünk be a rendszerünkbe:
root@ubuntu:/#chroot /mnt/system
Telepítsük a GRUB-ot a /dev/sda MBR-be:
root@ubuntu:/# grub-install /dev/sda
Installation finished. No error reported.
Majd updateljük:
root@ubuntu:/# update-grub
Generating grub.cfg …
Found linux image: /boot/vmlinuz-2.6.32-21-generic
Found initrd image: /boot/initrd.img-2.6.32-21-generic
Found memtest86+ image: /memtest86+.bin
Cannot find list of partitions!
done
Ez a /boot/grub/grub.cfg fájlt fogja updatelni (mivel én GRUB2-t használok), és ha minden jól ment akkor felismeri a gépen lévő operációs rendszereket és felveszi azokat a GRUB indító menüjébe.
Ezután nincs más hátra mint újraindítani a gépet, és az újraindítás után már a korábbi GRUB menü fog bejönni, ahol a listából kiválaszthatjuk az indítani kívánt operációs rendszert. Ha esetleg mégsem mutatja mindet (nekem előfordult hogy a Windows-t nem ismerte fel a live cd-ről), akkor az Ubuntu elindulása után adjuk ki ismét a update-grub parancsot:
[.] Továbbroot@thor-t410:/home/pzolee# update-grub
Generating grub.cfg …
Found linux image: /boot/vmlinuz-2.6.32-21-generic
Found initrd image: /boot/initrd.img-2.6.32-21-generic
Found memtest86+ image: /memtest86+.bin
Found Windows 7 (loader) on /dev/sda1
done
ZeroCD technológia és a Windows 7
Nemrégiben váltottam át Windows XP-ről Windows 7-re, és bár szinte minden zökkenőmentesen ment, sikerült belefutnom egy komoly problémába. Van néhány régebbi (de azért nem túl régi, 2-3 éves) USB-s eszközöm, mint például egy Samsung SHG-Z810-es usb-s modemem ami XP alatt tökéletesen működik. Sajnos Windows 7 alá nincs hozzá natív driver és valószínűleg már nem is lesz, van viszont 2000/XP/Vista alá. Mielőtt bárki megörülne, nem, a Vistás driver nem jó Win 7 alá, pontosabban szólva feltelepül, csak épp nem képes lekezelni ezeknek az USB-s eszközök az új “csoda” módszerüket, ami nem más, mint a ZeroCD technika.
Na de, mit is jelent mindez?
A ZeroCD lényege nagyjából a következő:
Amikor az eszközt csatlakoztatjuk a géphez, akkor az első körben mint egy virtuális cd meghajtó fog megjelenni a gépben, és ha a gépen engedélyezve van az automatikus indítás (a legtöbb windowson ez az alapértelmezett), akkor erről a virtuális cd-ről elindul a driverek telepítője. Ha a driver feltelepült, akkor az észleli az eszközt és átváltja azt “normál” módra, magyarán pl. az usb modem tényleg modemnek fog látszani.
A technika előnyére könnyen rájöhetünk, anélkül is lehet használni az eszközt, hogy külön driver cd-ről (vagy a netről) kellene telepíteni a szükséges drivereket és programokat. Így aztán tényleg “plug and play” eszközt kapunk.
Kivéve, ha nincs megfelelő driver az operációs rendszerünkhöz, mert ilyenkor nem történik meg az átváltás, és az eszközt akkor sem tudjuk használni, ha egyébként minden szükséges program fenn van a gépen ahhoz, hogy az eszköz valódi funkcióját tudjuk használni (néhány eszköznél egyébként ez a mód a készülékben is állítható, pl. mobiltelefonok esetén, ekkor szerencsénk van).
Mint azt az elején említettem, az én eszközeim ZeroCD-t használnak, cserébe nincs hozzájuk Windows 7-es driver, a Vista alá adott driver pedig nem képes az eszköz üzemmódját átváltani. Mielőtt felkiáltanánk hogy “de a win 7-nek van egy csomó kompatibilitást állító módja!”, nem, egyik sem fog működni, hiába telepíted a drivert XP kompatiblis módban és hasonlók, nem fog menni.
Igazi megoldás sajnos nincs a problémára (amíg a gyártó ki nem ad megfelelő drivert), így csak egy workaround módszert fogok bemutatni, ami bár nem túl kényelmes, de legalább működik.
Windows XP Mode
A probléma megkerülésének módszere az, hogy telepítünk egy virtuális Windows XP-t, arra feltelepítjük a szükséges drivereket, és az adott eszközt felcsatoljuk erre a virtuális gépre. A virtuális XP-ben futó driver viszont már át tudja váltani az eszközt annak valódi módjára. Ez az eljárás egy kicsit bonyolultabb és jóval erőforrás igényesebb is (hisz gyak. egy másik oprendszert kell futtatnunk virtuálisan, azért, hogy egy egyszerü funkciót igénybevegyünk, de sajnos nincs más megoldás).
Windows 7-hez alapból letölthető az un. Windows XP Mode, ami tulajdonképpen nem más, mint egy VirtualPC-ben előre telepített XP (korábban csak hardveres virtualizációt támogató rendszerekre lehetett telepíteni, de a közelmúltban a Microsoft eltörölte ezt a korlátozást). Ez sajnos home premium esetében nem elérhető, csak professional-től kezdődően és eredetiség vizsgálatot is végre fog hajtani a gépen. A célra természetesen egyéb virtualizációs módszerek is igénybevehetőek (pl. Vmware, Virtualbox), de én most a Windows XP Mode használatával fogom a fenti eszközöm működésre bírni, mivel ez volt a leggyorsabb és legegyszerűbb megoldás (nem kellett XP-t beszereznem és telepítenem az egész egyben jön). Igazából majdnem mindegy, hogy melyik virtualizációs rendszerben indítjuk az XP-t, a lényeg hogy az adott virtualizációs rendszer fel tudja csatolni a külső rendszer USB-s eszközeit.
Kezdésként, ha még nincs telepítve, akkor töltsük le a Microsoft weboldaláról a Windows XP mode eszközt. Ez különösebb beállítást nem igényel, a letöltés után elindul a telepítés és a végén a Start menüben fogjuk megtalálni az indítóikonját. A telepítés végén indítsuk is el (fontos tudni, hogy ez az XP külön rendszerként fog viselkedni, tehát célszerű bekapcsolni az automatikus frissítéseket, és egy egyszerűbb vírusírtó sem árthat, ha rendszeresen akarjuk használni).
További információk a Windows XP Mode-ról: link
Samsung SGH-Z810 beállítása
Csatlakoztassuk a modemet a géphez, várjunk egy kicsit, majd csatoljuk fel az eszközt a VirtualPC ablakában (USB/USB MMC Storage). Ezután az XP fel fogja ismerni azt és elkezdi telepíteni róla a szükséges drivereket, végül a driver átváltja az eszközt modem módba. Ekkor fel kell csatolni ezt is (USB/SAMSUNG Mobile Modem).
Ezután elindul a Samsung Connection Manager, amivel máris tudunk csatlakozni az internetre.
Eddig egyszerűnek és könnyűnek tűnik, de most jön egy kis csavar a dologban. Az igaz ugyan, hogy így már használni fogjuk tudni a modemet az XP alatt, de továbbra sem lesz internet kapcsolatunk a külső rendszerben, tehát a Win 7 alatt lévő programok továbbra sem lesznek képesek elérni az internetet, márpedig mi ezt szeretnénk.
Anélkül, hogy mélyebben belemélyednék az elméleti részletekbe, a következőket fogjuk csinálni:
-felveszünk egy virtuális hálózati kártyát Win 7 alatt
-megtesszük ugyanezt XP alatt is.
-virtuálisan összekötjük őket, így a két gép “látni” fogja egymást
-megosztjuk a modemes internet kapcsolat XP alatt, így innentől kezdve a Windows 7 alatt is el fogjuk érni az internetet, ezen a virtuális “hídon” keresztül.
Lássuk hogyan tudjuk ezt megtenni a gyakorlatban:
A Windows 7 alatt (ez a külső rendszerünk) tegyük a következőket:
- Először is, telepítsük a microsoft visszacsatoló adaptert (angolul loopback adapter). Erről egy képes leírás (igaz angolul) itt található:how-to-install-a-loopback-adapter-in-windows-7Angolul kevésbé tudóknak: indítsuk el a hdwwiz.exe nevü alkalmazást, majd kövessük a képen látottakat (elég jól beazonosítható, hogy mi micsoda) és keressük meg a hálózati adapterek/microsoft/microsoft visszacsatoló adapter-t és telepítsük
- Ezután nyissuk meg a hálózati kapcsolatok panelt, jobb klikk/tulajdonságok a visszacsatoló adapterre, TCP/IPv4, és állítsuk be a következőket:
- IP cím: 192.168.0.2, hálózati maszk: 255.255.255.0, átjáró: 192.168.0.1, DNS szerver: 192.168.0.1
Windows XP Mode-ban pedig:
- Nyissuk meg a VirtualPC-ben az eszközök/beállítások menüpontot és a felugró ablakban válasszuk a Hálózatok pontot.
- Állítsuk le közben a Windows XP Mode-t (de ne zárjuk be az előző ablakot)
- Az adapterek számát állítsuk kettőre, az első legyen az alapértelmezetten (NAT), a másodikon pedig válasszuk ki a korábban feltelepített visszacsatoló adaptert. Az XP számára ez induláskor egy hálózati kártyaként fog megjelenni, mégpedig hálózati kapcsolat 2 néven.
- Indítsuk el ismét a Windows XP Mode-t.
- Csatlakoztassuk a modemet a géphez és csatoljuk fel a VirtualPC-ben, ahogy feljebb írtam
- Nyissuk meg az XP-ben is a hálózati kapcsolatokat, jobb klikk a Samsung modemre, és válasszuk ki az internet kapcsolat megosztását, és adapternek válasszuk ki ezt a visszacsatoló hálózati adaptert. Ezután a windows automatikusan be fogja állítani a 192.168.0.1-es címet ennek az adapternek, ezért fogja látni a két gép egymást (emlékezzünk, a másiknak 192.168.0.2-es címet adtunk így egy hálózatban lesznek)
- Pingeljük meg Win 7 alól ezt a címet, hogy meggyőződjünk tényleg látják a gépek egymást. Ha minden jól ment, ilyesmit kimenetet kell látnotok
C:\>ping 192.168.0.1
Pinging 192.168.0.1 with 32 bytes of data:
Reply from 192.168.0.1: bytes=32 time<1ms ttl=”63″ bytes=”32″ ttl=”63″ bytes=”32″ ttl=”63″ bytes=”32″ ttl=”63″ sent =” 4,” received =” 4,” lost =” 0″ minimum =” 0ms,” maximum =” 0ms,” average =” 0m”
Ezután már nincs más hátra, mint a virtuális XP-ben csatlakozni a modemmel az internethez, és máris lesz internetünk a Windows 7 alatt is.
Végezetül, ha már ennyire belejöttünk a Virtual XP Mode használatába, megosztanék még egy eszköznek a használatát Windows 7 alatt, mivel ezzel is problémákba futottam. Ez pedig nem más mintegy Mio C250-es GPS. Ez ugyan nem használ ZeroCD-t, de ehhez sincs driver Windows 7 alá.
Mio C250 beállítása
Töltsük le a Mio oldaláról az XP-hez szükséges drivert és szoftvert (Mio Transfer), majd másoljuk fel a virtuális XP-re és telepítsük fel. Ezután csatlakoztassuk az eszközt a számítógéphez. Várjunk egykicsit, amíg a számítógép észleli azt, majd csatoljuk fel az USB eszközt a VirtualPC ablakában, hogy átadjuk azt a virtuális XP-nek. Ebben az esetben a virtuális XP észlelni fogja a GPS-t, és a MioTransfert elindítva látni fogja azt.
Ha esetleg mégsem látná, akkor töltsük le az USB drivert innen.
Persze Windows 7 alatt továbbra sem fogjuk látni a GPS-t, de az XP Mode-ban automatikusan felcsatolódnak az XP alá a külső rendszer meghajtói, így a fájlok másolása nem fog gondot okozni.
syslog-ng 2.x upgrade 3.0-ra
Ha eddig 2.x-es vagy korábbi syslog-ng-t használtál, akkor épp itt az ideje hogy upradeljük 3.0-ra (főleg, hogy a korábbi változatok már nem támogatottak). De hogyan teheted meg ezt és mire kell odafigyelned?
A következő leírás a fontosabb tudnivalókról fog szólni.
Az első lépés, hogy be kell szerezned egy 3.0-ás csomagot. Ez lehet hogy a disztribúciód részeként jön, vagy letöltheted a Balabit weboldaláról (https://www.balabit.com/network-security/syslog-ng/opensource-logging-system/upgrades/).
Néhány szó a weboldalon található csomagfajtákról:
-Letölthetsz natív rpm csomagokat rpm alapú platformokhoz (pl. RHEL, SUSE). Az rpm csomag telepítéskor automatikusan detektálni fogja az előző verziójú syslog-ng-t és upgradeli azt.
-Letölthetsz natív deb csomagokat deb alapú platformokhoz (pl. Debian, Ubuntu). Ez a telepítő egy picit okosabb mivel a debian telepítő rendszer lehetőséged ad interaktív bevitelre is, így a telepítő meg fog kérdezni az upgradelés módjáról (előző konfig használata vagy új létrehozása).
-És végül, letölthetsz .run kiterjesztésű telepítőcsomagokat is. Ezek a csomagok főleg olyan platformokhoz készültek, ahol nehéz vagy bonyolult natív csomagokat gyártani (ez főleg a PE által támogatott platformok egy részére igaz), de természetesen ezek a csomagok telepíthetőek olyan platformokra is, ahová egyébként van natív telepítő csomagunk is (mint pl. a fenti platformok). Ez azt jelenti, hogyha használni kívánt platform például Debian Etch, akkor választhatsz a .deb és a .run telepítők között, mindkettővel telepíthető a syslog-ng.
További különbség, hogy a .run telepítő felhasználóbarátabb és több beállítási lehetőséges tesz lehetőséget, mint a natív telepítők (pl. silent mód, parancssori paraméterek által konfigurálható telepítés).
A mostani leírásban, én a .deb csomagunkat fogom használni, az operációs rendszer pedig Ubuntu.
Kezdjünk is neki rögtön.
A régi syslog-ng-m verziója:
root@thor:~# dpkg -l syslog-ng
||/ Név Verzió Leírás
+++-===============================
ii syslog-ng 2.0.9-4.1 Next generation logging daemon
Most pedig telepíteni fogom az új verziót. A telepítés során feljövő ablakban a régi konfiguráció használatát fogom választani, ahogy a mellékelt kék ablakban is látható. Ha a nemet választanád, a telepítő egy új friss konfigurációt generálna neked.
root@thor:~# dpkg -i syslog-ng_3.0.5_amd64.debÚj csomag kiválasztása: syslog-ng.
(Adatbázis olvasása … Most 192868 fájl és könyvtár telepített.)
Kicsomagolás: syslog-ng innen: syslog-ng_3.0.5_amd64.deb …
Beállítás: syslog-ng (3.0.5) …
Starting syslog-ng: Configuration file has no version number, assuming syslog-ng 2.1 format. Please add @version: maj.min to the beginning of the file;
WARNING: global: the default value of chain_hostnames is changing to ‘no’ in version 3.0, please update your configuration accordingly;
WARNING: input: sources do not remove new-line characters from messages by default in version 3.0, please add ‘no-multi-line’ flag to your configuration if you want to retain this functionality;
WARNING: file source: default value of follow_freq in file sources is changing in 3.0 to ’1′ for all files except /proc/kmsg;
Your configuration file uses an obsoleted keyword, please update your configuration; keyword=’log_prefix’, change=’program_override’
WARNING: template: the default value for template-escape is changing to ‘no’ in version 3.0, please update your configuration file accordingly;
A telepítés végén a syslog-ng automatikus elindul, de ahogy látod, kaptunk néhány warningot. Ezek csak figyelmeztetések, a syslog-ng indulását nem befolyásolják, de fontos információkat közölnek velünk (később fogok foglalkozni ezek feloldásával).
A telepítés után ellenőrizzük le, hogy tényleg rendben települt-e a syslog-ng:
root@thor:~# dpkg -l syslog-ng
||/ Név Verzió Leírás
+++-=================================-
ii syslog-ng 3.0.5
root@thor:~# ps aux | grep syslog-ng
root 31980 0.0 0.0 29560 884 pts/14 S 15:37 0:00 supervising syslog-ng
root 31981 0.0 0.0 35968 2380 ? Ss 15:37 0:00 /opt/syslog-ng/sbin/syslog-ng –no-caps
Visszatérve a warningokhoz, néhány dolog megváltozott a 3.0-ban a korábbi változatokhoz képest (pl.: alapértelmezett értékek). Mivel én a telepítés során a régi konfiguráció használatát választottam, a telepítő átmozgatta a /etc/syslog-ng/syslog-ng.conf fájlt a /opt/syslog-ng/etc alá, és a syslog-ng most ezt használja és ezért ad bizonyos dolgokról figyelmeztetést induláskor. Ezek a warningok minden esetben ki lesznek jelezve, amikor a syslog-ng elindul.
Mindenképp ellenőrizd le a figyelmeztetések minden sorát és javítsd ki őket ha szükséges (felhasználva a figyelmeztetés szövegét, vagy a dokumentációt). Ha változtatások nélkül szeretnéd használni a konfigurációt, akkor helyezd a következő stringet a konfiguráció legelső sorába: @version: 3.0
Mindenképp győződj meg arról, hogy tényleg megértetted a változtatásokat, mert a verzió string ugyan eltüntetni a warningokat, de ettől még a syslog-ng működése az új lesz (tehát ha valaminek megváltozott az alapértelmezett értéke, akkor a syslog-ng az új értéket fogja használni, de most már figyelmeztetést sem ad rá).
Miután kijavítottam a szükséges dolgokat, ismét elinditom a syslog-ng-t:
root@thor:~# /etc/init.d/syslog-ng start
Starting syslog-ng: Your configuration file uses an obsoleted keyword, please update your configuration; keyword=’log_prefix’, change=’program_override’
ahogy látod a warningok már eltüntek, már csak néhány elavult/elvetett dologra figyelmeztet. Ebben a példában a konfigurációban használva van a log_prefix opció, ami helyett a program_override-t kellene használni, mivel a 3.0-ban ez már nem használatos (de még működik).
További változások:
Ha megnézed a ps kimenetét (lásd feljebb), akkor látni fogod, hogy már nem csak egy syslog-ng folyamat fut, hanem mindjárt kettő, amiből az újat “supervising syslog-ng”-nek hívják. Ez is egy új funkció a 3.0-ban, a supervisor process felügyeli a másik syslog-ng folyamatot (amelyik tulajdonképpen az igazi syslog-ng), és ha a syslog-ng elszállna, akkor automatikusan újraindítja azt.
Ezt letilthatod ha a syslog-ng-t a –process-mode=foregroud|background parancssori opciókkal indítod, de ez nem ajánlott a legtöbb platformon, kivéve ahol a platform saját service kezelője gondoskodik a szolgáltatások újraindításáról (pl. AIX). Engedélyezni pedig a –process-mode=safe-background parancssori opcióval lehet (de alapvetően ez a default beállítás is).
További részleteket az újdonságokról a dokumentációban olvashatszt:
https://www.balabit.hu/dl/html/syslog-ng-v3.0-guide-admin-en.html/ch01s04.html
Windows 7 – Automatikus lemezformázást kérő ablak letiltása
Bizonyára rajtam kívül is vannak páran, akik a teljes külső meghajtójukat vagy esetleg egy teljes pendrive-ot letitkosítanak (például Truecryptel vagy egyéb teljes lemezt titkosítani tudó programmal). Ezzel csak akkor van gond, ha ezután ezt a lemezt az operációs rendszer nem csak hogy üresnek, vagy nem ismert típusúnak jelzi, hanem makacsan ragaszkodik ahhoz, hogy felkínálja formázásra minden alkalommal amikor csatlakoztatjuk a géphez, mint ahogyan azt a Windows 7 (és gondolom a Vista is) teszi, a következő kérdés feltevésével: “A meghajtóban (X:) található lemezt használat előtt formázni kell. Formázza?”
Ez a következő szép kis ablakban jelenik meg a meghajtó csatlakoztatása után:
Ez elég kellemetlen tud lenni, mert ezeket a külső USB-s háttértárakat az ember általában elég gyakran húzza ki/dugja be a gépébe, és ilyenkor azon kívül hogy megjelenik az idegesítő popup ablak, még azon is stresszelhet, hogy nehogy véletlenül leformázza a külső merevlemezét egy véletlen kattintással. Végülis hosszas nyomozás után, csak egy megoldást találtam erre:
-Csatlakoztassuk a meghajtót a gépbe
-Válasszuk a Start menü/Számítógép (jobb klikk)/Kezelés menüpontot.
-A megjelenő ablakban nyissuk le a Tárolás fület, azon belül válasszuk a Lemezkezelés funkciót, majd válasszuk ki a kívánt meghajtót. Jobb klikk a meghajtóra, majd a felbukkanó menüből válasszuk a Meghajtóbetűjel és elérési út módosítását, majd távolítsuk el a meghajtóhoz rendelt betűjelet.
Innentől kezdve a Windows nem fogja többet feldobni a fenti figyelmeztető ablakot (mivel nincs meghajtó betűjel társítva hozzá), miközben mi továbbra is tudjuk a titkosított kötetet csatlakoztatni, ahogy eddig.
Mindez képekben:
Hibakeresés Linuxon – tippek, trükkök
Ez alkalommal néhány egyszerű, de hasznos praktikát szeretnék bemutatni Linux alapokon. Néhány esethez több parancsot is bemutatok, mivel gyakran előfordul, hogy az egyik disztribúción az egyik parancs létezik, a másikon pedig egy másik. Természetesen a parancsok paraméterezése változhat a különböző rendszereken, én csak az általam leggyakrabban használt paraméterezést adtam meg, bővebben a parancsok man oldalán lehet utánanézni a paraméterek használatának.
Melyik folyamat tart nyitva egy meghatározott fájlt?
fuser paranccsal:
Használat: fuser -av fájlnév
Példa:
pzolee@thor:~$ fuser -av .file.txt.swp
USER PID ACCESS COMMAND
.file.txt.swp: pzolee 30694 F…. vim
Ha egyből ki is szeretnénk lőni ezt a folyamatot: fuser -av -ki fájlnév (ilyenkor azért a biztonság kedvéért még rá fog kérdezni, erre szolgál a -i paraméter)
lsof paranccsal:
Használat: lsof fájlnév
Példa:
root@thor:/home/pzolee# lsof /var/log/messages
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
syslog-ng 1255 root 10w REG 8,2 313880 75944 /var/log/messages
Melyik folyamat tart nyitva egy meghatározott portot?
fuser paranccsal:
Használat: fuser -av port/protocol
Példa:
root@thor:~# fuser -av 22/tcp
USER PID ACCESS COMMAND
22/tcp: root 1275 F…. sshd
lsof paranccsal:
Használat: lsof -i protocol:port
Példa:
root@thor:/home/pzolee# lsof -i :22
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
sshd 1306 root 3u IPv4 5196 0t0 TCP *:ssh (LISTEN)
sshd 1306 root 4u IPv6 5199 0t0 TCP *:ssh (LISTEN)
netstat paranccsal:
Használat: netstat -antp
root@thor:/home/pzolee# netstat -antp | grep 22
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1306/sshd
Milyen fájlokat tart nyitva egy meghatározott folyamat?
lsof paranccsal:
Használat: lsof -p PID
Példa:
root@thor:/home/pzolee# lsof -p 5251
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
syslog-ng 5251 root cwd DIR 8,2 4096 8182 /opt/syslog-ng/var/run
syslog-ng 5251 root rtd DIR 8,2 4096 2 /
syslog-ng 5251 root txt REG 8,2 1524414 34 /opt/syslog-ng/libexec/syslog-ng
syslog-ng 5251 root mem REG 8,2 66905 75946 /var/log/logstore.log
syslog-ng 5251 root 6u unix 0xffff8800280d1e00 0t0 42237 /opt/syslog-ng/var/run/syslog-ng.ctl
syslog-ng 5251 root 8u unix 0xffff8800280d0300 0t0 42233 /dev/log
Egy fájl nyomtatható (ember által is olvasható) sorainak megjelenítése
Időnként előfordulhat, hogy van egy bináris fájlunk (például egy program vagy egy core dump), amiből szeretnénk kinyerni az olvasható szövegeket. Erre a strings parancs használható.
Használat: strings fájlnév
Például kiírni egy fájlból a 32 karakter vagy annál hosszabb sztringeket:
pzolee@pzolee-laptop:~$ strings -n 32 /opt/syslog-ng/libexec/syslog-ng
g_markup_parse_context_end_parse
g_option_context_add_main_entries
OPENSSL_add_all_algorithms_noconf
/opt/syslog-ng/etc/syslog-ng.conf
/opt/syslog-ng/var/syslog-ng.persist
/opt/syslog-ng/var/run/syslog-ng.ctl
Configuration reload request received, reloading configuration
…
Egy program könyvtár függőségeinek megjelenítése
Erre az ldd parancs használható.
Használat: ldd fájlnév
Példa:
pzolee@pzolee-laptop:~$ ldd -v /bin/ps
linux-gate.so.1 => (0×00221000)
libproc-3.2.8.so => /lib/libproc-3.2.8.so (0x0028b000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x003c8000)
/lib/ld-linux.so.2 (0x00ed8000)Version information:
/bin/ps:
libproc-3.2.8.so (_3_2_5) => /lib/libproc-3.2.8.so
…
Egy mobiltelefon időseknek
Szokásomtól eltérően, most nem a szoftvertesztelésről vagy hibakeresésről írok, hanem egy másik technikai területről, annak is egy speciális ágáról. Mindazonáltal, bár a poszt nem igazán informatikai jellegű és sokkal inkább magánjellegű okai vannak, hogy miért erről írok, azért a tesztelői hozzáállásomat így sem sikerült teljesen elrejtenem.
Miközben egyre újabb és újabb, még nagyobb tudású mobiltelefonok jelennek meg a piacon, amik lassan már tényleg önálló számítógépként is képesek viselkedni és akár egy ssh-t is futtathatok rajtuk, ha be szeretnék lépni bárhonnan a gépemre (ezzel kielégítve a technológiai elvárásaimat), addig a gyártók elfelejtkeznek egy másik felhasználói csoportról, azokról akik a telefonjukat tényleg nem akarják másra használni, mint telefonálni, esetleg SMS-t küldeni, ezt viszont minél egyszerűbben szeretnék megtenni.
Ezek közül is kiemelnék egy csoportot, az idősek csoportját, például a nagyszüleinket, akik sokszor már nem is képesek megtanulni eligazodni a menük bonyolult halmazában vagy egyéb fizikai okok miatt nem képesek erre (például nem képesek koordinálni rendesen az ujjaik mozgását mert remeg a kezük, vagy egyszerűen csak túl nagyok és vastagok az ujjaik egy 20 évesével szemben és így képtelenek kezelni az apró gombokat a mobiltelefonon). Biztosan mindenki találkozott már azzal a jelenséggel is, hogy egy idős ember számára már a billentyűzár kioldása is kihívást jelent, és ez tényleges vészhelyzet esetén (amikor az ember egyébként is leblokkol) könnyedén okozhatja a segítség hívás elmaradását vagy felesleges késleltetését.
Szerencsére egy-két gyártó már elkezdett nekik is többé-kevésbé megfelelő készüléket gyártani (bár Magyarországon még elég csekély a választék), így szeretnék egy ilyen készüléket bemutatni, mivel az én nagyszüleimnek is pont most volt szüksége egy ilyenre és csak hosszas keresgélés után sikerült találnom egyet.
Az igények szempontjából a legfontosabb az volt, hogy a telefonnal egy gombnyomással lehessen segítséget hívni és ezt lehetőleg automatikusan kellő hangerő mellet lehessen megtenni, mivel már az én nagyszüleim hallása sem igazi, illetve, hogy a segítségkérés akkor is létrejöhessen, ha valamiért a szóbeli kommunikáció nem lehetséges (mert például a túloldal nem veszi fel a telefont).
A szűkös választékból (a T-Mobile forgalmaz egy Emporia talk premium típusú telefont, amit időseknek fejlesztettek ki, illetve a Myphone 1070-es típusú kártyafüggetlen telefonja) végül a 1070-est választottam, kifejezetten egy ok miatt, mivel csak ezen a telefonon volt külön egy nagy segélyhívó gomb a telefon hátoldalán. A következőkben így ezt a telefont mutatom be a saját tapasztalataim alapján, hogyha valaki hasonló cipőben jár, akkor könnyebb legyen eldöntenie, hogy tényleg tudja-e ez a telefon azt amit szeretne.
Mint az a képen is látható, a telefon jó nagy gombokkal rendelkezik, amiket idős emberek számára is könnyű kezelni, és a kijelző fontmérete is elég nagy méretű, így rosszabb látású emberek is könnyedén el tudják olvasni. Egy negatívummal találkoztam itt, a kijelző sajnos elég lassú, így az én fürge gombnyomásaimat nem tudta időben követni, szerencsére ez a nagyszüleimnél nem fog problémát okozni, mivel ők egyébként sem nyomkodják gyorsan a gombokat.
További pozitívum, hogy a billentyűzár külön tolókapcsolóval kap
csolható, ami a telefon oldalán kapott helyett. Ha bekapcsoljuk, akkor egy jókora méretű lakat fog megjelenni a kijelzőn, amit könnyű észrevenni és így rájönni a probléma okára. Továbbá a billentyűzár kapcsolója felett van a beépített lámpa hasonló tolókapcsolója, ez egy kis LED-et kapcsol be a telefon tetején, így a telefon elemlámpa helyett is tud funkcionálni (bár nem hinném hogy ez annyira gyakori funkció, de időnként jól jöhet).
Ennyi bevezetés után, jöjjön a lényegi funkció, az SOS hívó gomb.
Mint az a képen is látszik, a telefon hátoldalán kapott helyett, egy nagy narancssárga gomb formájában, ezt a gombot lefelé tolva automatikusan bekapcsol a vészhívó funkció. Akkor is bekapcsol, ha a billentyűzár be van kapcsolva, ami számomra egy plusz pontot jelent és nem kell attól sem félni, hogy magától véletlenül bekapcsolódna, mivel a gomb elhelyezkedése miatt illetve hogy ez a gomb nem jár egyszerűen (konkrétan némi erővel szükséges lehúzni, nem lötyög és nem laza járatú), ezért véletlenül csak nagyon nehezen kapcsolódhat be. Erre a vészhívó funkcióra 5 telefonszámot lehet beállítani, amikre először egy előre megírt SMS-t küld el (sajnos csak 60 karakter lehet az SMS, nem tudom mi ennek az oka), majd sorban elkezdi őket tárcsázni. Ha a hívott fél nem veszi fel, vagy maga a hívó kinyomja a hívást (a piros elutasító gombbal), akkor automatikusan hívja a következő számot, egészen addig amíg valaki fel nem veszi a telefont az 5 hívott szám közül, vagy vissza nem nyomjuk az SOS gombot alapállapotba. Ha a végére érne az 5 számnak anélkül, hogy valaki felvenné, akkor ismét kezdi az elejéről tárcsázni őket a telefon és így tovább. Egy valamire kell csak odafigyelni, a telefon nem képes észrevenni ha hangposta veszi fel a hívást, így ha ezt történne, akkor megszünteti a vészhívást (és a további tárcsázást), mintha tényleg sikerült volna elérni a túloldalt, egészen addig amíg újra nem aktiváljuk a vészhívó funkciót. Épp ezért célszerű olyan számokat előre rakni, ahol nincs hangposta, vagy biztosan tudjuk hogy fel fogják venni a telefont, és az olyan számokat hátrébb rakni, ahol jó esély van rá hogy hangposta fogja felvenni. A lényeg viszont, hogy az SMS-eket mindenképp elküldi a megadott számokra, mivel az SMS küldés megelőzi a tényleges hívást.
További tudnivaló, hogy a vészhívás bekapcsolása esetén a telefon őrületes nínózásba kezd (bal oldalon lévő képen éppen egy ilyen hívás indul), ez hasznos 
olyan szempontból, hogy a hívó biztosan tudja hogy a telefon vészhívó állapotban van, illetve bizonyos esetekben megkönnyítheti a hívó megtalálását (például ha valaki elesik hátul a kertben és nem képes mozogni, vagy később eszméletét veszti és nem képes magára felhívni a figyelmet, így a segítségére érkezők nem találnák meg idejében), ami viszont negatívum, hogy nem lehet kikapcsolni, csak a vészhívás kikapcsolásával. Ugyanakkor, ha a túloldal felveszi a telefont, akkor automatikusan kikapcsolás a hívás idejére, így az idősebbeknek talán könnyebb észrevenni a hívás létrejöttét. Még egy nagyon fontos dolog, hogy a telefon menüjében beállítható, hogy vészhívás esetén milyen legyen a hívás hangereje (a telefon automatikusan kihangosított állapotba kerül, és ezen belül szabályozható a hangerő), így nagyot hallók számára is jól használható hallókészülék nélkül is (az én tesztjeim alapján ilyen állapotban még a szomszéd szobában is hallható volt amit a túloldal mondott, bár maximum hangerőn már egy kicsit recsegett a telefon hangszórója, így érdemes 1-2 fokozattal a maximum alá állítani a hangerőt ilyen esetben).
Mindezek mellet természetesen a telefon rendelkezik a szokásos normális funkciókkal is, így lehet vele SMS-t küldeni és fogadni (MMS-t nem), van rajta számológép, ébresztőóra, gyorshívó funkció (az egyes gombokhoz, illetve a csillag és kettőskereszt gombokon még egy lány illetve fiú arc figura is megtalálható) és még néhány kevésbé érdekes funkció (pl. rádió).
Összeségében, a telefon jó választás lehet időseknek, és bár lenne egy-két ötletem, hogy mit lehetne még rajta fejleszteni, a hibái nem vészesek, cserébe viszont olyan funkciókkal rendelkezik, amik nagyon hasznosak időseknek és amikkel jelenleg más telefon nem igazán rendelkezik az itthon kapható készülékek közül. Bár a telefon még friss és csak pár hete használják a nagyszüleim, mégis elég gyorsan megkedvelték, így valószínűleg a fentiekben leírt tapasztalataim tényleg helytállóak a telefon kezelésében kapcsolatban (és remélhetőleg még egy jó darabig nem lesz szükség a vészhívó gomb használatára).
[.] Továbbsyslog-ng Agent for Windows hibakeresés
Már biztos hallottál róla, hogy a syslog-ng Agent a syslog-ng PE része. Ez a program képes arra, hogy windows platformokon összegyűjtse az eseménynaplóban lévő logokat és elküldje azokat egy távoli syslog-ng-nek. Természetesen nem csak eseménynaplóból tud logokat olvasni, hanem tetszőleges fájlból is (hasonlóan mint a syslog-ng).
Időnként viszont, mint ahogy az más programok esetén is előfordulhat, azt tapasztalhatjuk, hogy valami nem jól működik. Például hibát jelez telepítés közben, vagy nem akar elindulni. A következőkben azt fogom bemutatni, hogy ilyen esetekben hogyan lehet kideríteni a hiba okát.
Telepítés során felmerült hibák kiderítése
Az agent a telepítése során automatikusan létrehoz egy log fájlt, ami az agent telepítési könyvtárában jön létre (ez alapértelmezetten a C:\Program Files\syslog-ng Agent), install.log néven. Ebben a fájlban találhatóak meg azok a műveletek, amiket a telepítő végrehajtott.
Példa:
File: overwriteflag=1, allowskipfilesflag=2, name=”C:\DOCUME~1\pzolee\LOCALS~1\Temp\1\nskFB8.tmp\nsExec.dll”
File: skipped: “C:\DOCUME~1\pzolee\LOCALS~1\Temp\1\nskFB8.tmp\nsExec.dll” (overwriteflag=1)
Jump: 3383
Jump: 3387
Jump: 3394
Call: 2438
Call: 2438
detailprint: syslog-ng Agent for Windows not configured. Not starting service syslog-ng Agent.
Jump: 3427
Sajnos ez a log nem mindig jól értelmezhető mezei halandó számára (mivel egy jó részét a telepítőt generáló külső rendszer adja), de azért sokszor találunk benne hasznos információkat, mint például hogy melyik fájlt nem tudta létrehozni vagy törölni, vagy mint a fenti példában hogy nem sikerült elindítania az agentet, mivel nem talált hozzá konfigurációt.
Beépített hibakereső paraméterek használata
Az agentnek, ahogy a syslog-ng-nek is, rengeteg hibakereső paramétere van. A paraméterek lekéréséhez futassuk le a következő parancsot:
c:\Program Files\syslog-ng Agent>syslog-ng-agent.exe -h
Usage:
EventLog: -EventLog, -E, -e
Debug: -Debug, -D, -d
Install: -Install, -i
Remove: -Remove, -R, -Uninstall, -u
Version: -Version, -v
Help: -Help, -h, -?
Terminate: -Terminate, -t
Set XML Configuration File: -XmlConfig, -c
Ezek közül a két legfontosabb a hibakeresés szempontjából a -e és -d paraméter. A -e opció azt mondja az agentnek, hogy a hibakereső (debug) logokat az eseménynapló/alkalmazás tárolóba helyezze el.
Példa egy ilyen üzenetre:
TransmitThread : Failed to connect to Primary Server ’10.30.0.32′
Ez egy gyors módszer az agent hibakeresésére, de nem túlzottan hatékony. Egyrészt nehéz az eseménynaplóban több tiz vagy száz esemény áttekintése, másrészt tulajdonképpen összeszemeteli az eseménynaplót hibakereső üzenetekkel. Épp ezért ezt a módszer nem javaslom hosszasabb hibakeresésre, helyette használjuk a -d opciót. Ha ezzel az opcióval indítjuk az agentet, akkor a logokat a Microsoft igyenes DebugView nevű hibakereső eszközével tudjuk megtekinteni. Csak töltsük le ezt a programot a Microsoft weboldaláról és az elindítás után automatikusan meg fogja kapni az agent által generált logokat. További információkat a DebugView használatával kapcsolatban a DebugView oldalán találhatunk: http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx
Fejlettebb hibakereső módszerek
Az agent 3.0.7-es és 3.1.0-ás verziójától kezdve, néhány további hasznos hibakereső módszer is használható.
Első körben hozzuk létre a registryben a HKEY_LOCAL_MACHINE\SOFTWARE\BalaBit\syslog-ng Agent\AgentDbgLog DWORD tipusú kulcsot és állítsuk be “2″-re. Ez azt fogja mondani az agentnek, hogy a hibakereső logokat egy szöveges fájlba írja bele, amit az agent telepítési könyvtárában fogunk megtalálni syslog_ng_Agent.txt néven.
Ha futás közben belenézünk ebbe a fájlba, akkor ehhez hasonló logokat fogunk látni benne:
Wed Feb 10 10:59:10 2010 TransmitThread : Trying to connect to host ’10.30.0.32′
Wed Feb 10 10:59:10 2010 Connected to the Syslog server: 10.30.0.32
Wed Feb 10 11:00:15 2010 Event Entry : PROBADOMAIN\pzolee: Application EventCreate: [Information] testmessage (EventID 1000)
A logokat némi angol tudással könnyedén megfejthetjük, a fenti példában az agent megpróbál csatlakozni a 10.30.0.32-es címre, ami sikerül is neki, majd ezután egy beérkező eseményt mutat.
Vagy nézzünk gyorsan egy másik példát. Az agent SSL használatára lett beállítva, de a túloldal mégsem kap tőle logokat. Ilyenkor például a következő logokat láthatnánk ebben a fájlban:
Wed Feb 10 11:02:47 2010 Event Entry : NT AUTHORITY\SYSTEM: Application syslog-ng Agent: [Error] Failed to get certificate with subject; ‘wrongcertsubject’ (EventID 34)
Wed Feb 10 11:02:47 2010 Event Entry : NT AUTHORITY\SYSTEM: Application syslog-ng Agent: [Error] Failed to find client certificate (EventID 32)
Ahogy azt már kitalálhattad a logokból, az agent nem talál olyan subjecttel rendelkező tanúsítványt, amit megadtam neki (mert például elírtam a nevét, vagy tényleg nem létezik ez a tanúsítvány az adott gépen).
Ha a AgentDbgLog kulcsot 1-re állítanád (a “2″ helyett), akkor ezeket a logokat a szöveges fájl helyett a debugview ablakában látnád (ahogy a -d opcióval).
Hibakeresés tartományi környezetben
Az agent a konfigurációját nem csak helyi, registryben tárolt konfigurációból tudja felolvasni, hanem megkaphatja azt csoportházirendeken keresztül is (erről bővebben a syslog-ng dokumentációjában olvashatsz).
Mi történik azonban, ha az agent nem kap vagy nem megfelelő konfigurációt kap, egyáltalán hogyan lehet ezt ellenőrizni? Nos, a szokásos windows tartományi hibakeresésen kívül (mivel az agentes csoportházirendeket a windows terjeszti le, ugyanúgy mint minden más csoportházirendet is), ezt is tudod ellenőrizni az agent segítségével.
Csak hozd létre a GpoDbgLog DWORD tipusú kulcsot a registryben ugyanott ahol az előzőt is, és állítsd az értékét “2″-re. Ebben az esetben a csoportházirend frissítés alatt (például gépinduláskor, vagy ha kiadod a gpupdate parancsot), a gép SYSTEM32 könyvtárában létre fog jönni egy fájl syslog_gpext.txt néven. Ez a fájl fogja tartalmazni a csoportházirend frissítés során történő dolgokat.
Példa:
…
Wed Feb 10 11:50:59 2010 Changed gpo: {31B2F340-016D-11D2-945F-00C04FB984F9}
Wed Feb 10 11:50:59 2010 Reg file not found: \\probadomain.balabit\sysvol\probadomain.balabit\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\Machine\BalaBit\syslog-ng\Settings.reg
Wed Feb 10 11:50:59 2010 OpenProcessToken() is OK
Wed Feb 10 11:50:59 2010 SetPrivilege
Wed Feb 10 11:50:59 2010 Using RegRestoreKey instead of reg.exe import
Wed Feb 10 11:50:59 2010 Restore Filename: \\probadomain.balabit\sysvol\probadomain.balabit\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\Machine\BalaBit\syslog-ng\Settings.reg.bin
Wed Feb 10 11:50:59 2010 Can’t merge this settings, because the gpo config version (3.1.0) is newer than current agent version(3.0.7)
Wed Feb 10 11:50:59 2010 Abort update.
Wed Feb 10 11:50:59 2010 Restore
…
A logban látható, hogy milyen csoportházirendeket kapott meg az agent (UUID-val azonosítva) és néhány belső logüzenet is. Ebben a példában a csoportházirendből érkező konfiguráció újabb mint az aktuális agent verzió ezért ezt nem tudja feldolgozni az agent és így konfiguráció hiányában nem fog majd elindulni.
A hibakeresés után mindig tartsuk észben, hogy a hibakeresésre használt registry kulcsokat töröljük ki, mivel az így létrejövő fájlok egy idő után nagy nagy méretűek is lehetnek.
Core dump készítése
Állítsuk be a HKEY_LOCAL_MACHINE/Software/Balabit/syslog-ng Agent/WriteMinidump kulcsot “1″-re. Ilyenkor, ha az agent valamiért elszállna, a telepítési könyvtárban automatikusan létrejön egy dump fájl syslog-ng-agent.dmp néven.
Hibajelentés küldése
Ha a fenti hibakereső módszerek sem vezettek eredményre, előfordulhat, hogy be szeretnéd nekünk jelenteni a hibát, de nem tudod, hogy mire lesz nekünk szükségünk hiba kijavításához vagy megoldásához.
A legfontosabb, hogy küldj el minden hibakereső logot és a core dumpot (ha elszállást tapasztaltál) ami a rendelkezésedre áll.
Ezenkívűl az agent pontos verziója is nagyon fontos, csak futtasd le a “syslog-ng agent.exe -v” parancsot, és a teljes kimásolt kimenetet is foglald bele a jelentésbe.
Továbbá, minden egyéb fontosnak vélt információt is. Például: mi okozza a problémát, mikor jelentkezik az, hogyan lehet reprodukálni, vagy hogy milyen platformon jelentkezik a hiba. Minnél több információt tudsz kideríteni, annál nagyobb az esélye, hogy sikerrel tudjuk megoldani a felmerült problémát.
Végezetül már csak az agent konfigurációját kell kimásolnod. Ha xml konfigurációt használsz, akkor csak küld el nekünk ezt a fájlt, ha tartományi vagy helyi konfigurációt, akkor exportáld ki a teljes HKEY_LOCAL_MACHINE\SOFTWARE\BalaBit\syslog-ng Agent kulcsot (az egész alatta lévő részfát is), és ezt a fájlt küld el nekünk.