Új Blog

Kedves Olvasóink!

Létrehoztunk egy új blog-ot, az alábbi címen:

http://blog.omikron.hu

Írásainkat az új oldalon lehet majd olvasni, ezt az oldalt megszüntetjük.

Üdvözlettel:

A Szerkesztők

Linux: Redundáns tárolórendszer tervezése - 4. Az alaprendszer kialakítása

Telepítés

A tárolórendszer node-jai CentOS 5.6 operációs rendszerrel lesznek telepítve.

A CentOS (és egyébb RHEL deriváns rendszerek) esetében a telepítést nagymértékben leegyszerűsíti és automatizálja a Kickstart szoftver. Az eljárás lényege, hogy a telepítendő rendszer paramétereit (hosztnév, hálózati beállítások, root jelszó stb.) egy fájlban megadjuk a Kickstart-nak, ami aztán automatikusan feltetepíti az operációs rendszert (unattended installation).

Ennek a módszernek - az automatizáláson kívül - vannak egyéb előnyei is:

• flexibilitás: a telepítendő OS image-et és a Kickstart fájlt is tetszőleges adattárolón/megosztáson keresztül tehetjük elérhetővé a telepítéshez (USB Pendrive, HTTP/NFS/FTP megosztás, stb.),
• öndokumentáló módszer: a Kickstart konfigurációs fájlt a rendszer telepítése után a telepítési dokumentációba illeszthetjük.

A node-okat tehát Kickstart módszerrel telepítettem, az alábbi konfiguráció szerint (nfs1 node):

# nfs1 kickstart file
# install options
reboot
text
install
url --url=http://install.server.local/centos32bit

# configuration options
lang hu_HU
keyboard hu
timezone Europe/Budapest
network --device eth0 --ip=192.168.151.11 --netmask=255.255.255.0 --gateway=192.168.151.254 --nameserver=192.168.151.254 --hostname=nfs1 --bootproto=static
skipx
bootloader --location=mbr
zerombr
key --skip

# security
auth --useshadow --enablemd5
rootpw --iscrypted $1$GvTZBQO2$hJWl9aH8DO1fOQ5soJwfR1
firewall --disabled
selinux --permissive

# partitioning
clearpart --drives=cciss/c0d0 --all --initlabel
clearpart --drives=cciss/c0d1 --all --initlabel

part raid.11 --size 10240 --ondisk cciss/c0d0
part raid.12 --size 2048 --ondisk cciss/c0d0
part raid.13 --size 1024 --ondisk cciss/c0d0 --grow

part raid.21 --size 10240 --ondisk cciss/c0d1
part raid.22 --size 2048 --ondisk cciss/c0d1
part raid.23 --size 1024 --ondisk cciss/c0d1 --grow

raid / --level 1 --fstype ext3 --device md0 raid.11 raid.21
raid swap --level 1 --fstype swap --device md1 raid.12 raid.22

# software
%packages --nobase
openssh
openssh-clients
openssh-askpass
openssh-server

# scripts
%post
#!/bin/bash

# Installing grub to the MBR at the end of install:
/sbin/grub --batch --device-map=/dev/null <<EOGRUB
device (hd0) /dev/cciss/c0d0
root (hd0,0)
setup (hd0)
quit
EOGRUB

/sbin/grub --batch --device-map=/dev/null <<EO2GRUB
device (hd0) /dev/cciss/c0d1
root (hd0,0)
setup (hd0)
quit
EO2GRUB

A konfigurációs fájl egy-két beállítása magyarázatra szorul:

• konfigurálás: a node-ok nevei és a SAN hálózathoz tartozó IP címeik az előző blogbejegyzésben szerepelnek;
• biztonság: a root jelszó: password;
• partícionállás: a root és swap fájlrendszerek RAID1 tömbre kerülnek, a fennmaradó partíciókat (raid.13, .23) adattárolásra fogom használni és a telepítés után konfigurálom azokat;
• szoftverek: csak egy minimális rendszert telepítek fel (core szoftvercsomag a base csomag nélkül) és csak az SSH-val egészítem ki;
• szkriptek: a telepítés után (%post szekció) futtatok le egy szkriptet, mely mindkét merevlemezre kiírja a GRUB-ot (e beállítások nélkül, boot-oláskor, problémák adódnának).

Névfeloldás

Miután feltelepült a rendszer, első lépésként be kell állítani a névfeloldást, hogy a tárolórendszer node-jain futó szoftverek név alapján azonosíthassák egymást (/etc/hosts):

# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost
::1 localhost6.localdomain6 localhost6

192.168.151.11 nfs1
192.168.151.12 nfs2

192.168.152.101 nfs1-ha
192.168.152.102 nfs2-ha

Szoftverforrások

A különféle szoftverkomponensek (Heartbeat, Pacemaker, stb.) eléréséhez további szoftverforrásokra van szükség - konkrétan az EPEL és CLUSTERLABS repository-kra -, telepítsük ezeket:

# rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm
# wget -O /etc/yum.repos.d/pacemaker.repo http://clusterlabs.org/rpm/epel-5/clusterlabs.repo

Következő lépés

Miután a tárolórendszer node-jain elindult az operációs rendszer, elkezdhetjük feltelepíteni a kalszterszoftvereket.

Linux: Redundáns tárolórendszer tervezése - 3. Rendszerterv

Rendszerterv

Az előzőekben felsorolt komponenseket rendszerré fogtam össze. Ehhez alapvetően két aspektusból kellett megvizsgálnom a készülő rendszert:

• a rendszeren futó szolgáltatások szemszögéből,
• a rendszer elemeinek kommunikációja szempontjából.
  

A szolgáltatások kialakítása

A tervezés során az alábbi rendszert alakítottam ki (a szolgáltatások közötti relációkat a Pacemaker dokumentációban használt sémák alapján vázoltam fel):

Amint a rajzon látható, a tárolórendszer node-jain egységes platformot alkot a klaszterszoftver kommunikációs (Heartbeat) és az erőforrás-kezelő (Pacemaker) rétege. Ezen a platformon épülnek ki (elindulási sorrendben) a különféle klaszter szolgáltatások.

A klaszter először a DRBD szolgáltatást indítja el, ami egy - a két node között Master-Slave üzemben replikált - virtuális blokkeszközt hoz létre (drbd0). (A redundancia növelése érdekében a drbd0 eszköz alá, mindkét node-on, RAID1 tömböket terveztem.)

Hogy az így létrehozott tárterület felosztható legyen, a drbd0 eszköz alapot képez az LVM szolgáltatás kialakítására (Physical Volume neve: drbd0). Az LVM szolgáltatás felépülése után (Volume Group neve: data) egy logikai kötet indul el (Logical Volume neve: export). Az adattár kialakítása a logikai kötetre épülő, Ext3 típusú fájlrendszer felcsatolásával (/export könyvtár) végződik.

Ha az adattár kialakításával kapcsolatos feladatok befejeződtek, a klaszter egy előre definiált, virtuális IP címet rendel az fájlmegosztó szolgáltatáshoz. Az NFS processz futásához néhány segédprogramra is szükség van, a klaszter ezeket is kezeli (portmapper).

Ha a teljes virtuális infrastruktúra (adattárolási és hálózati) kiépült, a klaszter elindítja a fájlmegosztó szolgáltatást (NFS).

A hálózat kialakítása

A tárolórendszer tervezése során többféle hálózati forgalommal kell számolnunk. Az egyes forgalmak karakterisztikája, valamint a hálózattal szemben támasztott igényeik nagyon eltérőek lehetnek. Vegyük sorra ezeket!

SAN hálózati forgalom

A SAN hálózaton keresztül közlekednek az adatblokkok a virtualizált rendszerek (VMware guest) és az NFS szerveren tárolt virtuális merevlemezeik (image) között. Értelemszerűen, ez a forgalom igényli a legnagyobb sávszélességet és a legkisebb késleltetést, ellenkező esetben a guest-eken jelentős lassulást fogunk tapasztalni a megnövekedett IOWait miatt.

Klaszter kommunikáció (Heartbeat)

A klaszter kommunikáció kis sávszélességet, de minél nagyobb redundanciát igényel a kommunikációs útvonalak tekintetében. A DRBD dokumentáció egyenesen így fogalmaz: az a klaszter, melynél a node-okat kettőnél kevesebb útvonal köti össze, nem klaszter (Heartbeat communication channels).

A blokk szintű replikáció (DRBD)

A tárolórendszer node-jai közötti blokk szintű replikáció a NAS forgalomhoz hasonló követelményekkel bír: nagy sávszélességet és alacsony késleltetést kíván.

Menedzsment forgalmak

A tárolók menedzsmentje SSH kapcsolaton keresztül történik, ez semmilyen különleges kritériumot nem támaszt a hálózattal szemben. Biztonsági szempontból azonban fontos, hogy el legyen szeparálva a NAS/Heartbeat/DRBD forgalmaktól (utóbbiakat célszerű L3 kijárat nélküli hálózati szegmensekbe terelni).

A felsorolt kritériumok alapján az alábbi hálózat tervét rajzoltam meg:

Jellemzők:

• A SAN adat és a DRBD replikációs forgalmakat külön hálózatokba terelem (VLAN 151 és 152 - A piros számok az adott interfészhez tartozó IP címet jelölik, míg a zöld szám a NFS szolgáltatáshoz tartozó szolgáltatás IP-t.)
• A Heartbeat/Pacemaker szoftver úgy lesz kialakítva, hogy az nfs1 és nfs2 node-ok mindkét VLAN-on keresztül tartsák a kapcsolatot (redundáns útvonal). A kapcsolattartás Multicast kommunikáció útján fog történni.
• Mivel az NFS szervereken csak két fizikai interfész van, ezért a menedzsment forgalom kialakításáról lemondtam - a konfigurálást a gépek konzoljáról fogom végzni (ez a forgalom, ideális esetben, külön interfészek felhasználásával, egy külön VLAN-on keresztül haladna).
  

Következő lépés

A tervezési fázisról ennyit szerettem volna mondani. A következő részekben bemutatom az implementáció lépéseit.

Linux: Redundáns tárolórendszer tervezése - 2. Komponensek

Hardver

A tároló kifejlesztéséhez külön tesztrendszert állítottam össze. Az alábbi szerver vasak (2 db) képezik a rendszer alapját:

• Szerver típusa: HP Proliant ML 330 G3,
• Processzor: Intel(R) Xeon(TM) CPU 2.40GHz (HT, 32bit),
• Memória: 1GB,
• Háttértár: 2x 36GB SCSI,
• Hálózat: 2x 3c905c (10/100)

Amint látható a gépek nem éles környezetre alkalmas eszközök, tesztelés céljára azonban megfelelnek. A VMware ESXi hoszt már komolyabb hardver:

• Szerver típusa: Dell PowerEdge T300,
• Processzor: Intel(R) Xeon(TM) X3323 CPU 2.50GHz (64bit, 4 core),
• Memória: 8GB,
• Háttértár: 4x 146GB SAS,
• Hálózat: 2x Broadcom NetXtreme (10/100/1000)
• ESXi verzió: 4.1

Az erős VMware hoszt biztosítja, hogy ne a virtualizáció legyen a szűk keresztmetszet, ha teljesítmény méréseket végzünk a tárolórendszeren. Minden bizonnyal a "SAN" hálózati eszköz sem von majd le további hasznos százalékokat a rendszer teljesítményéből:

• Switch: Cisco WS-C3550-24 L3 switch (24x 10/100 port, PowerPC)
• IOS verzió: 12.2(25)SEB4
• Feature set: C3550-IPBASE-M
  

Szoftver

OS

Linux. Az operációs rendszernek mindenképpen valamilyen UNIX-ból származtatott OS-t szerettem volna használni. Mivel már 12 éve foglalkozom Linux-szal, legjobban ezt az OS-t ismerem, így célszerűnek tűnt ezt választani. Természetesen vannak egyébb előnyei is a Linux-nak, de ezekről majd később.

A CentOS egy szabadon elérhető rendszer, melyet a Red Hat Enterprise Linux forráskódjából készítenek, minimális változtatásokkal (gyakorlatilag a márkára utaló információkat módosítják). Az RHEL nagyvállalati célra szánt disztribúció, így olyan kellemes tulajdonságai vannak, mint például az egyes szoftververziók 7 éven át történő támogatása. A belőle származtatott CentOS disztribúció jó választásnak tűnik egy magas rendelkezésreállású tárolórendszer kialakításához.

Hálózati adattárolási protokoll

A SAN protokoll kiválasztása már keményebb dió volt. Mint említettem az alap VMware ESXi alapvetően két variánst támogat: iSCSI-t és NFS-t (az utóbbiból a NFSv3 over TCP verziót). Mindkét protokollnak vannak előnyei és hátrányai:

• Teljesítmény: eltérő véleményeket lehet olvasni arról, hogy ki-melyik protokollt tartja jobbnak VMware-es környezetben. Az biztos, hogy a TCP/IP protokoll jelentős többletterhelést ró a SCSI adatforgalomra, de az NFS esetében is növekszik a késleltetés és csökken a sávszélesség a TCP megbízható adattovábbítási módszerei miatt. Az iSCSI-hoz ráadásul léteznek kliens oldali, hardveres gyórsító kártyák melyek tovább növelik a teljesítményét.
• Használhatóság: az NFS hatalmas előnye, hogy a virtuális gépek image-ei fájlokként jelennek meg az NFS szerveren, így sokkal egyszerűbbé válik például a mentés.
• Megbízhatóság: az NFS kliens és szerver oldalon is cache-eli a fájlrendszer írási adatait és a két cache-t folyamatosan szinkronban tartja. Ez azt jelenti, hogy a kliens kiesése esetén megmaradnak a lemezre még ki nem írt adatok. Az iSCSI esetében viszont a kliens oldalán van csak fájlrendszer cache, melynek a tartalma csak meghatározott időközönkét (asszinkron módon) íródik a blokk eszközre így a kliens kiesése esetén elveszhet a tartalma.

A felsorolt érvek és ellenérvek alapján az NFS protokollt választottam.

Blokk szintű replikáció

Mint már említettem az előző blogbejegyzésben, a Linux tartalmaz merevlemezek közötti (RAID) és gépek közötti (DRBD) blokk replikációs modult is. A készülő rendszerben mindkét modult fel szeretném használni, hogy növeljem a tároló hibatűrését.

Logikai kötetkezelés

A tárolórendszer egyik legfontosabb ismérve, hogy dinamikusan változó méretű partíciókat tudunk rajta létrehozni, amire azért van szükség, hogy a folyamatosan változó tárolási igényeknek ne szabhasson gátat a merevlemezek mérete. Erre szolgálnak a különféle Logical Volume Management (LVM) megoldások.

A módszer lényege, hogy a fizikai lemezeket (Physical Volume, PV) beletesszük egy nagy logikai tárolóba (Volume Group, VG) majd a logikai tárolóból különféle szeleteket hasítunk ki, adattárolás céljára (Logical Volume, LV). Ez a módszer nagyon dinamikusá teszi az adattárolást, mert az LV-k mérete folyamatosan változtatható és ha helyszűkében vagyunk, bármikor további fizikai lemezeket (PV) adhatunk a logikai tárolókhoz (VG).

Napjaink egyik legjobb LVM implementációja a ZFS, ami logikai kötetkezelő és fájlrendszer is egyben. Olyan finomságokkal van felvértezve, mint a blokk szintű replikáció (például RAID-Z) vagy a blokk szintű deduplikáció (ez utóbbi nagyon jól jön virtualizált környezetben). Sajnos a ZFS Linux alatt még gyerekcipőben jár, ezért a Linux LVM megoldását fogom használni.

HA modul

A fentebb felsorolt szoftverek indulásának/leállásának vezérlését, működésének felügyeletét és hiba esetén a szükséges ellenintézkezések végrehajtását, mint egy karmester hangolja össze a klaszter szoftver. Linux alatt többféle klaszter is elérhető, én a Heartbeat/Pacemaker párost favorizálom.

A LinuxHA projekt hozta létre a Heartbeat klaszer keretrendszert és üzenetküldési réteget. A Heartbeat elsődleges feladata, hogy kiépítse és menedzselje a klaszert alkotó gépek közötti kommunikációt és létrehozza a klaszter infrastruktúrát.

A LinuxHA-ból kivált Pacemaker projekt létrehozott egy Cluster Resource Manager (CRM) modult, mely a klaszter különféle erőforrásait (fájlrendszerek, IP címek, szolgáltatások stb.) kezeli. A Pacemaker egy központi adatbázisban (CIB) tárolja a klaszter állapotát és minden egyes állapotváltozásra meghatározott módon reagál. A Pacemaker teljes mértékben testreszabható és nagyon komplex klaszterek alkíthatóak ki vele.

A következő fázis

Ebben a bejegyzésben bemutattam, hogy milyen hadverekből és szoftverekből tervezem megépíteni a tárolórendszert. A következő lépésben elkészítem a rendszer tervét.

Linux: Redundáns tárolórendszer tervezése - 1. Kritériumok

Miért?

Már hosszú ideje kutatok egy olyan nyílt forrású NAS megoldás után, melyet a szabadon elérhető VMware ESXi hypervisor-hoz lehetne illeszteni. Az ESXi és a tárolórendszer segítségével magas rendelkezésreállású virtualizációs infrastruktúrát lehetne építeni, szabad szoftveres komponensekből. Az így kapott rendszer tesztelési célokat szolgálna, ám ha bebizonyosodik, hogy megbízthatóan működik, éles telepítésekben is használnám.

Mivel nem sikerült a követelményeknek megfelelő NAS szoftvert találnom elhatároztam, hogy tervezek egy saját rendszert. Melyek ezek a követelmények? Az alábbiakban részletezem.

A tárolórendszerrel szemben támasztott elvárások

VMware ESXi kompatibilitás

A VMware ESXi alapesetben két külső adattárolási protokollt támogat:

• iSCSI: az Internet Small Computer System Interface protokoll IP hálózaton keresztül történő, blokk szintű adattárolásra szolgál,
  
• NFS: a Network File System az egyik legősibb fájlmegosztási protokoll.

A korszerű, nyílt forráskódú NAS szoftverek (Openfiler, FreeNAS, NexentaStor, stb.) mindegyike ismeri a két protokollt, így bármelyiket fel lehetne használni a tárolórendszer alapjául.

Redundancia, hibatűrés

A NAS tervezése során a legfontosabb szempont a redundancia, ami a készülő rendszer valamennyi összetevőjénél megjelenik: redundancia a háttértáraknál (RAID), redundancia a hálózati kapcsolatoknál (EtherChannel) és redundancia a NAS eszközök terén is (Failover Cluster). A redundancia teszi lehetővé, hogy a rendszer hibatűrő legyen, azaz fel tudjon állni a bekövetkező hibákból. Komoly hiba lehet például a rendszer egy hardver vagy szoftver komponensének kiesése, melyet a rendszernek automatikusan korrigálnia kell.

Az fentebbi szoftverek közül az Openfiler az, amelyik HA modult (Heartbeat) tartalmaz. A modult konzolról kell konfigurálni, nem az elsődlegesen használt webes felületről. További probléma az is, hogy a stabil Openfiler (2.3-as verzió a bejegyzés írásakor) a Heartbeat egy régebbi, már elavultnak tekinthető verzióját tartalmazza. A régebbi verzió nem képes például a klaszter erőforrásainak monitorozására, csak a klaszterkomponensek kiesését veszi észre. Ezen felül a felépített rendszer menedzsmentje nehézkes és nem is működik stabilan...

Blokk szintű replikáció

A kialakítandó rendszert több (egész pontosan kettő) NAS eszközből álló klaszterként képzelem el, melyek között blokk szintű adatreplikáció történik. Ez azért fontos szempont, mert így a rendszer egyik node-jának kiesése esetén a másikon gyorsabban lehet helyreállítani az adattárolási szolgáltatást, mintha mentésekből probálnánk megtenni azt.

Az említett NAS szoftverek közül egyedül az Openfiler tartalmaz alapkiépítésben blokk szintű replikációs modult (DRBD). A modul konfigurálását konzolról kell végezni, nem a NAS szoftverek esetén elsődleges menedzsment interfésznek számító webes felületről. Ez a vegyes menedzselési módszer kissé nehézkessé teszi a felépített rendszer használatát.

Egyszerű menedzsment

A tárolórendszerrel szemben nem várom el, hogy bonyolult webes felülettel rendelkezzen, elég ha soros konzolról és SSH kapcsolaton keresztül menedzselhető. A kevesebb néha több (KISS elv).

Modularitás

Ha a kész rendszer moduláris, a felmerülő igényeket (pl.: hiba esetén üzenet küldése a hálózatfelyügyeleti rendszer számára) könnyebben implementálhatjuk rá. A modularitás segít abban is, hogyha valamely szoftverkomponens nem működik megbízhatóan, jó eséllyel ki tudjuk cserélni egy másikra.

Konklúzió

Mivel a fent megfogalmazott kritériumok mindegyikének egyaránt megfelelő NAS szoftvert nem találtam, magam készítem el a szám ízének megfelelő tárolórendszert. A következő bejegyzésben bemutatom, hogy milyen szoftverekből építem fel azt.

Android: Parking SMS Magyarország

Újabb remek program Androidos kütyünkre...

Az SMS parkolás megkönnyítésére született-e remek alkalmazás. Előnye, hogy a városokban található parkolási zónákat előre megkapjuk, és az EME mellett a többi szolgáltató telefonszáma is megtalálható benne.

CDP szolgáltatás RHEL/Centos Linuxra

Cisco eszközök fontos szolgáltatása a Cisco Discovery Protocol (CDP), melynek segítségével egy eszköz hasznos információkat oszthat meg a hozzá kapcsolt (Layer2 kapcsolat) további eszközökkel. Ilyen hasznos információk például az eszköz neve, menedzsment IP címe, a Layer2 kapcsolat két végén található portok azonosítója. Cisco hálózatokban akár a teljes topológiát fel lehet deríteni CDP parancsok segítségével.

Mit tehetünk, ha egy RHEL/Centos Linuxra épülő hálózati eszközt (pl. tűzfalat) szeretnénk Cisco infrastruktúrába integrálni úgy, hogy CDP információkat is megosszon szomszédaival? Ilyenkor segít nekünk a CDP-Tools szoftvercsomag, mely többek között CDP üzenetek küldésére alkalmas parancsot is tartalmaz.

A szoftvercsomagot a Razor's Edge repository-ból tudjuk a legegyszerűbben telepíteni, melynek beállítása után az alábbi parancsot kell lefuttatnunk:

# yum install cdp-tools

(Ha függőségi problémákba ütközünk, az EPEL repo segítségével tudjuk feloldani azokat.)

CDP üzeneteket a cdp-send parancs segítségével tudunk küldeni. A CDP szolgáltatás kialakításához már csak egy LSB kompatibilis init-szkriptre van szükségünk (amit a csomag nem tartalmaz):

/etc/init.d/cdpd:

#!/bin/bash
#
# chkconfig: 35 90 12
# description: CDP service
#

#Source function library.
. /etc/init.d/functions

# Enable CDP on this interface
INTERFACE="eth0"

start() {
echo -n "Starting CDP service: "
/usr/sbin/cdp-send $INTERFACE &
touch /var/lock/subsys/cdpd
success $"CDP service startup"
echo
}

stop() {
echo -n "Stopping CDP service: "
killproc cdp-send
rm -f /var/lock/subsys/cdpd
echo
}

case "$1" in
start)
start
;;
stop)
stop
;;
status)
status cdp-send
;;
restartreloadcondrestart)
stop
start
;;
*)
echo $"Usage: $0 {startstoprestartreloadcondrestartstatus}"
exit 1
esac

exit 0

Ha nem az eth0 interfészen szeretnénk a CDP-t használni, értelemszerűen módosítsuk az INTERFACE változót. Az init-szkript létrehozása után indíthatjuk a szolgáltatást:

# chkconfig cdpd on
# service cdpd start

Ha mindent jól csináltunk, a gépünkre kapcsolt Cisco hálózati eszközön az alábbihoz hasonló kimenetet kapunk a CDP szomszédok lekérdezése után:

sw-1#show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone

Device ID Local Intrfce Holdtme Capability Platform Port ID
test-linux-pc Fas 0/17 122 H x86_64 eth0
core-rtr Fas 0/24 153 R S I WS-C3560-8 Fas 0/8
sw-3 Fas 0/16 131 S I WS-C3550-2 Fas 0/24

Android: Gesture Search

Még csak most telepítettem, de érdekesnek tűnik ez a program. Google labs alkalmazás Androidra, melynek segítségével lehet keresni a kontaktok, alkalmazások, könyvejelzők stb. között.

Bővebben: http://www.pcworld.com/appguide/app.html?id=432099&expand=false

Hasznos programok Linuxra - 4. - dmidecode

A DMI (Desktop Management Interface - hardver adatok, BIOS, széria számok stb.) adatokat írja ki ember által is emészthető formában. Először akkor használtam amikor meg kellet mondani, hogy mennyi memória slot van a gépben és ebből mennyiben van memória és mekkora. Természetesen  elég távol voltam a géptől, hogy fizikailag odamenjek és megnézzem.

Telepítés:

• Ubuntu 10.04: sudo apt-get install dmidecode
• Fedora 13: yum install dmidecode
• Forrás: http://www.nongnu.org/dmidecode/

Android: Air Control Lite

Mostanában ez a kedvenc játékom, repülésirányítót kell játszani. Egyszerű és rövid idő alatt függőséget okoz :)