Kütyü blog

by Zankomp

Egy egyszerű időzített script XenServer alá

2016. március 13. 19:20 - Zankó András

Snapshot To Template How To

Az alábbi script a XenServer-ünkön futó - általunk meghatározott - virtuális gépekről készít snapshot-ot, abból egy szintén az általunk meghatározott pool-on belüli meghajtóra template-t generál, majd törli a feleslegessé vált snapshot-ot.

xen-cli.jpg

A # szimbólum után jelzem itt is, hogy éppen mit csinál a script, és természetesen .log fájlt is készítünk a futó folyamatokról.

#!/bin/sh

# Itt adjuk meg a log file lokációját
logfile="/home/backupxen.log"

# Itt adjuk meg a cél tároló uuid azonosítóját
sruuid="xxxxxxxx-yyyy-zzzz-wwww-pppppppppppp"

# Itt adjuk meg a dátumot
curdate=$(date +%Y%m%d)

# Itt a vm1 és vm2 helyére a saját szerverünkön futó vm neveket kell megadni, ezekről fogunk snapshot-ot készíteni
for vmname in vm1 vm2
do

# Itt az echo parancsok mögött olvasható, hogy mit csinál(t) a script
echo "$(date +"%Y-%m-%d %k:%M:%S") -- ${vmname} -- Snapshot készítés." >> ${logfile}

snapuuid=`xe vm-snapshot vm=${vmname} new-name-label=${vmname}-snap-${curdate}`

echo "$(date +"%Y-%m-%d %k:%M:%S") -- ${vmname} -- Snapshot kész. UUID száma=${snapuuid}. Másolás az SR-re és Template készítés." >> ${logfile}

# Itt alább látható, hogy a script angol nevet ad a fájloknak, mivel a szerverünk is angol nyelvű, ezen nem változtattam
xe snapshot-copy new-name-label=${vmname}-template-${curdate} new-name-description="Template of ${vmname} created ${curdate}" uuid=${snapuuid} sr-uuid=${sruuid}

echo "$(date +"%Y-%m-%d %k:%M:%S") -- ${vmname} -- Template létrehozva az SR-en. Snapshot törlés." >> ${logfile}

xe snapshot-uninstall force=true snapshot-uuid=${snapuuid}

echo "$(date +"%Y-%m-%d %k:%M:%S") -- ${vmname} -- Script lefutott." >> ${logfile}

done

A scriptet backupxen.sh néven a /home könyvtárba elmentve, jogosultságot adok neki a végrehajtáshoz:

chmod +x /home/backupxen.sh

Majd beidőzítem, minden nap hajnali 2 órára:

crontab -e
0 2 * * * /home/backupxen.sh

És kész is vagyunk. Ha szeretnéd a script-et kommentek nélkül elérni, akkor azt itt megteheted.

Mára csak ennyi, de ígérem, hogy legközelebb már nem a script-ek lesznek a fő téma, de hogy mi, az legyen meglepetés.

Szólj hozzá!

Script-ek automatizálása Linux rendszeren

2016. március 12. 19:20 - Zankó András

A crontab parancsról röviden

Legutóbb egy adatmentő script-et mutattam be, de azt is megígértem, hogy röviden kitérek annak automatikus futtatási lehetőségeire is. Miről is van szó? Természetesen a crontab parancsról, ami Linux rendszerek alatt teszi lehetővé számunkra az időzítés beállítását.

crontab-cli.jpg

Ha root felhasználóként belépünk rendszerünkbe, akkor adjuk ki a következő parancsot:

crontab -e

Az alapértelmezett editor programunk megnyitja nekünk a crontab root felhasználó alá tartozó modulját, ahová be tudjuk írni, hogy mikor fusson le a korábban megírt (vagy bármilyen) sript. De mit kell beírni?

A crontab egy egészen egyszerű metódust használ az időpontok definiálására. A megnyitott fájl is mutatja nekünk a lehetőségeket: a sor elejére kell az időpontot beírnunk, mely tartalmazza a perc (0-59), az óra (0-23), a nap (1-31), a hónap (0-12) és a hét napjait (0-6). Lássunk egy pár egyszerű példát, melyeket talán használni is fogunk:

0 0 1 * * = minden hónap éjfélkor a hónap első napján
0 0 * * 0 = minden héten vasárnap éjfélkor
0 0 * * * = minden nap éjfélkor
@reboot = a gép indításakor

Az alábbi ábra talán jobban szemlélteti, hogy miről is van szó:

crontab-syntax.jpg

Ha valakinek kétsége támadna, hogy megfelelően lett megadva az időpont, annak tudom ajánlani az alábbi oldalt, ahol le lehet ellenőrizni a beállítást vagy akár mi magunk meg tudjuk adni az általunk kinézett időpontot, melyet a site le is generál nekünk:

http://crontab-generator.org/

Ha ezzel megvagyunk, jöhet a parancs, amit futtatni szeretnénk: ezt pedig csak be kell írnunk a sor mögé. Ha visszaemlékeztek, korábban a backup.sh nevet adtuk script-ünknek, és most ezt fogom behelyettesíteni a példába. Nevezetesen azt szeretném, hogy a mentésem minden nap délután fél kettőkor induljon el:

30 13 * * * /root/backup.sh

Így ezt a sort kell bemásolnunk a crontab-ba, és értelemszerűen a script helyét is meg kell adnunk, ami jelen esetben mondjuk a /root könyvtár.

Ha le szeretnénk ellenőrizni, hogy a helyesen szerepelnek az időzítéseink, akkor a crontab -l paranccsal tudjuk listázni a root felhasználó alá tartozó időzítéseket.

Ennyi lenne röviden. Most már kész az időzített pranacsunk, mely akkor fut le, amikor mi akarjuk, és nem kell minden nap magunknak elindítanunk, hanem élvezhetjük az ebéd utáni sziesztát.

Legközelebb egy XenServer alá írt script-et fogok megosztani veletek, mely nagy segítség lehet a napi mentések automatikus elvégzéséhez.

Szólj hozzá!

Linux webszerver backup shell script

2016. március 11. 19:20 - Zankó András

Webszerver adatmentés Windows mappába egyszerűen

Sziasztok, újra itt. A mai posztban egy egyszerű shell script-et szeretnék megosztani veletek, ami lementi a LAMP szerverünk weboldalait tartalmazó adatmappánkat és kiexportálja webszerverünk MySQL adatbázisát a hálózatunkon megosztott Windows mappába.

lamp-folder-cli.jpg

Az egyszerűség kedvéért az egész scriptet bemásolom ide. A # szimbólummal ellátott sorok értelemszerűen nem részei a script-nek, de ezek magyarázzák el, hogy a szimbólumot követő sor, milyen parancsokat hajt vége. Nagyon kezdőknek jelezném, hogy a komplett script bemásolható egy általunk generált .sh fájlba, aminek bármilyen nevet adhatunk - esetünkben ez legyen most backup.sh. Vagy le is tölthető magyarázatok nélkül innen.

A parancs futtatásához meg kell adnunk a megfelelő jogosultságokat az alábbi paranccsal:

chmod +x backup.sh

Sőt, ha csak alap LAMP rendszer van telepítve, szüksége lesz egy kiegészítő csomagra is Linux rendszerünknek:

apt-get install cifs-utils

A script tökéletes működéséhez, szükségünk lesz két mappára is, melyeket létre kell hoznunk:

mkdir /backups és mkdir /mnt/cifs

No, de lássuk magát a script-et, ahol az echo kezdősorok írják ki nekünk a folyamatot jegyzetelő .log fájlba, hogy mi mikor történik:

#!/bin/sh

# Logfile-t készítünk, ami idő alapon rögzíti a történéseket
logfile=/backups/backup.log

# Meghatározzuk a time tag összetételét, ami belekerül a menteni kívánt fájlok nevébe, hogy könnyebben lehessen mentett adatokat értelmezni és visszakeresni 
time=`date +%b-%d-%y`

# Meghatározzuk a fájlnév tag-ekhez tartozó fájlformátumokat, amik az adatmappák esetében tömörített tar, míg a MySQL export esetében sql formátumot takar
filename1=wwwdata-$time.tar.gz
filename2=mysqldir-$time.tar.gz
filename3=mysqldump-$time.sql

# Meghatározzuk a forrás könyvtárakat, az itt található adatokat fogjuk lementeni
srcdir1=/var/www
srcdir2=/var/lib/mysql

# Meghatározzuk a cél könyvtárat, ahova tömöríteni és másolni fogjuk a menteni kívánt adatokat
desdir=/backups

# Megadjuk az adadtbázis eléréséhez szükséges paramétereket
mysqlusername=felhasználónév
mysqlpasswd=jelszó

# MySQL dump-ot készítünk a korábban meghatározott név és jelszó alapján, amit a cél könyvtárba exportálunk
echo "$(date +"%Y-%m-%d %k:%M:%S") -- MySQL dump indítása." >> ${logfile}
mysqldump --events --all-databases > /$desdir/$filename3 -u $mysqlusername -p$mysqlpasswd
echo "$(date +"%Y-%m-%d %k:%M:%S") -- MySQL dump elkészült." >> ${logfile}

# Felcsatoljuk a kívánt megosztott meghajtót az /mnt/cifs mappába
echo "$(date +"%Y-%m-%d %k:%M:%S") -- Megosztott mappa felcsatolása." >> ${logfile}
mount -t cifs //ipcím/megosztásnév /mnt/cifs -o username=felhasználónév,password=jelszó
echo "$(date +"%Y-%m-%d %k:%M:%S") -- A felcsatolás megtörtént." >> ${logfile}

# Betömörítjük az adatmappákat a korábban definiált név és idő sablonok alapján a cél könyvárba mozgatva
echo "$(date +"%Y-%m-%d %k:%M:%S") -- Tömörítés a cél mappába." >> ${logfile}
tar -cpzf $desdir/$filename1 -P $srcdir1
tar -cpzf $desdir/$filename2 -P $srcdir2
echo "$(date +"%Y-%m-%d %k:%M:%S") -- A tömörítés elkészült." >> ${logfile}

# Átmozgatjuk az összes mentési fájlt a felcsatolt mappába, ami ugye az /mnt/cifs
echo "$(date +"%Y-%m-%d %k:%M:%S") -- Mozgatás a megosztott mappába." >> ${logfile}
mv -f $desdir/$filename1 /mnt/cifs
mv -f $desdir/$filename2 /mnt/cifs
mv -f $desdir/$filename3 /mnt/cifs
echo "$(date +"%Y-%m-%d %k:%M:%S") -- Mozgatás vége." >> ${logfile}

# Lecsatoljuk a megosztott mappát
echo "$(date +"%Y-%m-%d %k:%M:%S") -- Megosztott mappa leválasztása." >> ${logfile}
umount /mnt/cifs
echo "$(date +"%Y-%m-%d %k:%M:%S") -- A leválasztás sikeres." >> ${logfile}

# Töröljük a cél könyvtárban lévő és már felesleges fájlokat
echo "$(date +"%Y-%m-%d %k:%M:%S") -- Fájlok törlése." >> ${logfile}
rm -f $desdir/$filename1
rm -f $desdir/$filename2
rm -f $desdir/$filename3
echo "$(date +"%Y-%m-%d %k:%M:%S") -- Fájlok törölve." >> ${logfile}

# Kész is vagyunk.

Ennyi lenne. Nem a legszebb shell script a világon, de működik, és ez a lényeg. A /backups mappában pedig vissza tudjuk nézni, hogy mi és mikor történt pontosan, hiszen nagyobb adattömörítések és másolások esetén az idő az egyik legfontosabb tényező. A példában szereplő script tehát letölthető innen is.

Azonban még nem vagyunk teljesen kész, hiszen ki szeretné minden nap manuálisan futtatni a parancsot? Erre lehet megoldás a crontab parancs, mellyel egészen egyszerűen beállítható, hogy mikor fusson le magától. Erről viszont csak a következő bejegyzéseben fogok írni.

Szólj hozzá!

Új merevlemez telepítése XenServer alá

2016. március 10. 23:18 - Zankó András

Ha már kevés a tárhely a virtualizációs rendszerünkben, elkerülhetetlen az új frissen vásárolt HDD integrálása. A következőkben erről szeretnék egy pár sort írni röviden.

xen.jpg

Természetesen leállított gépbe kell beszerelnünk az új merevlemezt. Ha ezzel megvagyunk, a rendszer felállása után lépjünk be a szerver fő konzoljába („Console” fül), ahol a következő paranccsal kérjük le a lemezek listáját:

fdisk –l

Itt látni fogjuk az új HDD-t is, melyet a Linux rendszer automatikusan észre is vesz. Általában a „default” telepítésnél a „/dev/sda” az elsődleges lemez, melyen a rendszer fut. Ha ezen kívül más lemez nincs beépítve, csak az új akkor valószínűleg az a „/dev/sdb” útvonalnevet foga viselni. Ha több lemez van telepítve, akkor érdemes a beszerelés előtt kilistázni a lemezeket, és feljegyezni az lista adatait, és csak utána szereljük be az új HDD-t vagy SSD-t. Ha megvan az elérési útvonal akkor a következő parancsot kell kiadnunk:

xe sr-create name-label=X shared=false device-config:device=/Y/Z type=lvm

Itt az X helyére a csatolni kívánt tároló új nevét kell bírni (pl. „New storage”), az /Y/Z helyére pedig az elérési útvonalat (pl. „/dev/sdb”).

Ha ezzel megvagyunk, meg is jelenik az új merevlemez a tárolók között. Azt azonban ne felejtsük el, hogy jelen leírás esetében LVM partícióként kerül felcsatolásra az új lemez, azonban aki mást szeretne, természetesen az is megoldható (pl. „ext3” behelyettesíthető az „lvm”helyére).

Szólj hozzá!

Autostart XenServer és VMware alatt

2016. március 10. 23:14 - Zankó András

A jó múltkor nagyon elfelejtettem valamit: méghozzá arra gondolni, mi történik akkor, ha a virtualizációkat futtató szerver esetleges áramkimaradás után újraindul? A virtuális gépek is újraindulnak? Sajnos nem. Ezt nekünk kell beállítani. Az alábbiakban sorra veszem az általam használt két virtualizációs platform eseteit.

xen-vmware.jpg

A VmWare esetén könnyű viszonylag könnyű dolgunk van, mert a vSphare Client segítségével könnyen beállíthatjuk az egyes virtuális gépek automatizált indítását. Az „Inventory”-ban válasszuk ki azt a szervert, amelyen a kezelni kívánt virtuális gép fut, majd a „Configration” fül alatt kattintsunk a „Software” menü „Virtual Machine Startup/Shutdown” feliratú lehetőségre. Itt látni fogjuk a szerverünkön lévő gépeket, melyek bekapcsolási és leállítási lehetőségeit a bal felső sarokban található „Properties…” megnyomása után már rendezgethetjük is. Három lehetőség adott: „Automatic Startup”, „Any Order” és „Manual Startup”. Értelemszerűen, ha azt szeretnénk, hogy virtualizációnk áramkimaradás utáni szerver-újraindulás után automatikusan magától működébe lépjen, az „Automatic Startup” csoportba kell áthelyeznünk, és csak le kell „OK”-znunk. Ennyi. A felületen még állítható a kikapcsolás is, hiszen nagy segítségünkre lehet, ha a virtualizációkat nem kell egyesével leállítanunk, ha a főszervert „Power Off”-olni akarjuk.

Ezt a megoldást a XenServer automatikusan elvégzi nekünk, ha le akarjuk állítani az egész rendszert. Viszont az automatikus indulás az egyes gépek esetében kicsit komplikáltabb. Annyiban azért egyszerű dolgunk van, hogy ezt is be lehet állítani a XenCenter segítségével, mégpedig úgy, hogy a fő host-ra lépve kiválasztjuk a „Console” fület, „root”-ként belépünk és bepötyögünk egy pár sort.

Először engedélyeznünk kell szerverünknek az automatikus újraindítást. Kérdezzük le a pool-master UUID-jét, mely általában egy számokból és betűkből álló azonosító szám:

xe pool-list

A kapott UUID számot helyettesítsük be a következő parancsba:

xe pool-param-set uuid=UUID other-config:auto_poweron=true

Másodszor ki kell listáznunk a virtuális gépek UUID paramétereit is:

xe vm-list

Minden egyes virtuális gépnek van egy ilyen saját azonosító száma. Ha sikerült megtalálnunk a kiválasztott virtuális gépet, annak azonosítóját be kell illesztenünk a következő parancsba:

xe vm-param-set uuid=UUID other-config:auto_poweron=true

Ezzel be is állítottuk az automatikus indulást, és így nem kell attól félnünk, hogy egy esetleges áramszünet idején az újrainduló szerverünkön fontosabb virtuális gépeket manuálisan kelljen elindítani. Mert jó minőségű szünetmentes tápegység ide, BIOS-ban rendesen bekonfigurált energia-beállítások oda („Auto Power On” / „Last State”), a virtualizációk maguktól nem fognak elindulni. Hacsak nem ez a célunk.

Kiegészítés

A minap telepített egy új XenServert, de hiába állítottam be a fent vázolt módszerrel az automatikus újraindítást, nem működött. Ezért a XenServer saját vApps alkalmazását használtam a beállításokhoz XenCenter segítségével: a szerverünkön állva a „Pool” fülön a „Manage vApps” ikonra kattintva létre kell hozni egy „New vApp”-ot, amihez hozzá kell adnunk az automatikus indításra kijelölt virtuális gépeinket. A „Properties” fül alatt az indulási sorrend is megadható. Jobb esetben egy újraindítás után működik is a dolog. Nekem nem volt ekkora szerencsém, így sem indultak el a gépek.
A végső megoldást az jelenette, hogy a „Console” fülöm lekérdeztem a vApp saját UUID számát a következő paranccsal:

xe appliance-list name-label=X

Ahol az X az vApp nevét jelenti, majd a következő sorokat kellett az /etc/rc.local fájl végéhez hozzáadnom:

sleep 40
xe appliance-start uuid=Y

Itt az Y a vApp UUID számát jelöli.
Egy újraindítás után meg is oldódott a problémám. Az automatikus indítások aktivizálódtak.

Szólj hozzá!

VMware vagy XenServer? Melyiket?

2016. március 10. 23:10 - Zankó András

Rendszerkövetelmények, elérhetőség és telepítési opciók

Ebben a postban arra teszek kísérletet, hogy felvázoljam két – általam is használt – virtualizációs rendszer alaptulajdonságait és telepítését: az egyik a VMware, a másik pedig a XenServer.

Bevezetés

A mai gyorsan fejlődő számítástechnikai világban élők jól tudják, hogy ma már olyan erős hardverek léteznek – akár otthoni felhasználásra is – , hogy könnyen elfuttatnak bármilyen virtualizációs rendszert. Mondom mindezt azoknak, akik nem annyira járatosak a „pc virtualization” világában.

Miért is kellhet nekünk a virtualizáció? A válasz: nem kell. Ez csak egy lehetőség azoknak, akik munkahelyükön vagy otthon több rendszert szeretnének futtatni egy időben, külön számítógépek megvásárlása, összeszerelése és üzemeltetése nélkül, ami igen költséghatékony is lehet, hiszen gondoljunk bele, hogy milyen magas áramköltségekkel járna külön gépen futtatni weboldalunkat, levelezésünket, FTP-nket, SMB-nket, fejlesztői környezetünket, vállalatirányítási rendszerünket vagy akár komplett NAS háttértárunkat. A virtualizáció segítségével megoldható több számítógép egyidejű futtatása, külön menedzselése: külön ütemezett mentések vagy akár SnapShot-ok készítésére is van lehetőségünk – legnagyobb előnye ebben rejlik. Azonban számos más plusz lehetőség is adott, mely segítheti munkánkat, gondoljunk csak a kliens programokkal való elérést (VMware vSphere Client vagy Xen Citrix XenCenter) vagy akár a webes konfigurálást (VMware vSphere WebClient vagy Xen Orchestra).

Ha a fentiek alapján sikerült felkeltenem az érdeklődést, akkor lássuk röviden azt, hogy milyen főbb tulajdonságokkal és rendszerigényekkel rendelkezik a két különböző virtualizáció platform.

xen-vmware.jpg

VMware

A VMware egy elég régi virtualizációs rendszer, mely igen hardver specifikus. A gyártó honlapján lehet utánajárni, hogy szerverünk alkalmas-e a futtatására:

http://www.vmware.com/resources/compatibility/search.php

Ha specifikus és egy viszonylag jó hírű gyártó által kiadott komplett szervertípussal rendelkezünk, akkor jó esélyünk van rá, hogy a kompatibilitási listában megtaláljuk. Érdemes azonban esetlegesen a külön hardver perifériáknak is utánanéznünk (például RAID kártya), mivel ez a virtualizáció igen kényes minden nemű hardver eltérésre. Az általam korábban és most is használt Dell szerverek nagy része alkalmas a rendszer befogadására. Azonban nem szabad azt sem figyelmen kívül hagyni, hogy melyik verzió telepítése lehetséges ISO formátumból, vannak ugyanis olyan régebbi típusok, melyek nem támogatják az újabb verziók közvetlen telepítését. Sőt, az is előfordulhat, hogy egy korábbi verzió ISO alapján telepíthető, de az újabb verzió már nem: csak upgrade-del lehet a frissebb verziót feltelepíteni utólagosan. A VMware használatával kapcsolatosan még az is probléma lehet, hogy egy korábbi verzió még fut szerverünkön, de az újabb rendszer már nem fog. A Dell esetében azonban volt már arra példa, hogy a Dell Community kiadott egy Dell-specifikus telepítő ISO-t, amely a legtöbb Dell által gyártott szerverre „felkúszik”.
Én az ESXi rendszert használom már évek óta, mivel a nagyobb cégeknek van lehetőségük egy drágább és komolyabb szerver megvásárlására és üzemeltetésére, de aki próba szinten szeretné a rendszert megnézni, az olcsóbban is be tud szerezni egy régebbi masinát (például akár egy Dell PowerEdge SC440-est). Bár ezeknél sajnos fennáll annak a lehetősége, hogy a legújabb verzió már nem fog felmenni.
A telepítő csomag regisztráció után érhető el a VMware oldalán, de support igénylése és több fizikai CPU birtokában fizetős a rendszer. Maga telepítés is egyszerű: az adathordozóra kiírt ISO fájlt csak be kell tenni szerverünk optikai olvasójába (pendrive-ról is telepíthető) és végig kell követnünk a telepítési segédletet, ahol be tudjuk állítani, hogy mely merevlemezre és mely statikus IP címre akarjuk a szerverünket ültetni a hálózatunkon.

XenServer

A XenServer egy jóval rugalmasabb rendszer, sokkal több szervert és hardver perifériát támogat, mint a korábban említett VMware. Sőt: gépigénye is kisebb, ami azt jelenti, hogy egy gyengébb hardverrel bíró számítógép is alkalmas lehet a futtatására. Ez azoknak lehet hasznos, akik saját maguk rakják össze virtualizációs szerverüket. Persze itt is érdemes utána olvasni, hogyha egy drágább és előre kialakított szervert szeretnénk használni a Xen rendszer futtatására:

http://hcl.xensource.com/

Én például egy régi Asus P5E alaplappal, egy Q6600-as 4 magos processzorral és 8 GB memóriával felvértezett „őskövületre” húztam fel a legfrissebb rendszert minden akadály nélkül. A telepítés ugyan azon a módon történik, mint a korábban említett ESXi-nél, de még regisztráció sem kell a csomag letöltéséhez:

http://xenserver.org/open-source-virtualization-download.html

Viszont a support itt is pénzbe kerül. Hasonlatosan a VMware-hez, ennek a rendszernek is igen jó a közösségi fóruma: szinte minden kérdésünkre találhatunk pozitív választ, vagy akár regisztráció után magunk is tehetünk fel kérdéseket, bár mindez minimális angoltudást azért feltételez.

A telepítések után szervereink IP cím alapján web böngészőből elérhetőek, ahol egyből adódik a lehetőség a kliens programok letöltésére és telepítésére, és mindezek után már közvetlenül is el tudjuk kezdeni szerverünk menedzselését, kezdve új, virtuális gépek létrehozásával.

Összegzés

Természetesen a két rendszer nem fedi le teljesen a létező virtuális platformokat. Sőt, a paletta nagyon széles. E rövid cikkel csak bevezetőt és ízelítőt szerettem volna adni azoknak, akik most fontolgatják a virtualizáció nyújtotta lehetőségek kipróbálását vagy alkalmazását. A VMware talán a nagyobb vállalatoknak, míg a XenServer a kisebb vagy otthoni rendszerek kiszolgálására alkalmasabb, bár mint korábban említettem, mindegyiknek megvan a maga előnye és hátránya is. Gondoljunk csak a Xen rendszerek natívan támogatott párhuzamos szerverfuttatására, vagy esetleg a VMware hardverspecifikus működésre és kidolgozottabb funkcióira.
Ha személy szerint kellene választanom, nem tudnék dönteni a kettő közül. Talán, mint ahogy sok más esetben is, a kettő kombinációja lenne a megfelelő: egy hibrid rendszer, mely egymás erősségeire építve alkotná meg a tökéletes virtualizációs platformot.

Szólj hozzá!

Moodle telepítése Debian LAMP szerver alá

2016. március 10. 23:09 - Zankó András

A jó múltkor a párom szeretett volna egy saját maga által készített oktatási feladatsort kiadni a diákjai számára, mely távolról is elérhető, kitölthető és ellenőrizhető. Ekkor határoztam el, hogy a Moodle elnevezésű oktatási modult fogom feltelepíteni neki, hátha a közeljövőben is szüksége lesz rá. Mivel FRISS magyar nyelvű dokumentáció nincs a telepítés folyamatáról, úgy döntöttem, leírom, hogy hogyan is kell feltelepíteni saját szerverünkre.
A Moodle LAMP szerver létét feltételezi, ezért a Linux, Apache, MySQL és PHP legyen feltelepítve gépünkre, mielőtt hozzálátnánk az installáláshoz.

lamp-moodle.jpg

A Moodle beszerzése

A programcsomag letölthető a https://download.moodle.org/releases/latest/ oldalról. A verzióhoz szükséges követelmények is itt olvashatók. Én parancssorból töltöttem le és csomagoltam ki a webes könyvtárba.

wget https://download.moodle.org/download.php/direct/stable28/moodle-latest-28.tgz

Majd kicsomagoljuk a megfelelő könyvtárba:

tar xvzf moodle-latest-28.tgz -C /var/www

Ha beszerzésen és a kicsomagoláson túlvagyunk, megadjuk a hozzáféréshez való jogosultságokat a könyvtárnak:

chown -R root /var/www/moodle
chmod -R 0755 /var/www/moodle
find /var/www/moodle -type f -exec chmod 0644 {} \;

A Moodle adatbázis létrehozása

A jogosultság megadása után, létre kell hoznunk egy külön adatbázist a Moodle-nak a MySQL adatbázisban. Ehhez először lépjünk be a MySQL-be:

mysql –u root –p
Enter password:

Írjuk be jelszavunkat, majd adjuk be a következő sort, mellyel létrehozzuk az adatbázist:

CREATE DATABASE moodle DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci;

Valamint adjunk hozzá egy user-t saját jelszóval:

GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,CREATE TEMPORARY TABLES,DROP,INDEX,ALTER ON moodle.* TO moodleuser@localhost IDENTIFIED BY ‘jelszó’;

Majd:

exit

Akinek van phpMyAdmin telepítve, az könnyedén megcsinálhatja ezeket a beállításokat onnan is, csak ne felejtse el az UTF8-as kódolást beállítani. Azt is érdemes itt megemlíteni, hogy másféle adatbázis-kezelő package-el is együtt tud működni, mint például a PostgreSQL, a MariaDB vagy a MSSQL.

A Moodle adatmappa létrehozása

Természetesen a Moodle egy saját mappát fog használni az adatok tárolására és előhívására. Érdemes nem közvetlenül a „www” mappába rakni. Ezt is létre kell hoznunk, teljes hozzáférést adva neki:

mkdir /var/moodledata
chmod 0777 /var/moodledata

A Moodle telepítése

Ha mindezzel megvagyunk, akkor nem marad más hátra, mint a közvetlen telepítés – legalábbis a hivatalos weboldal szerint, bár én itt hívnám fel a figyelmet arra, ami megakasztotta a webes telepítést nálam.

A php-curl telepítése

Erre a modulra szüksége van a Moodle-nak, és mivel nálam ez a modul hiányzott, fel kellett telepítenem:

apt-get install php5-curl

Sajnos mivel korábbi Debian disztribucióm van, a telepítés megakadt hibával, mely a javascript-common-ra hivatkozott, ezért ezt eltávolítottam:

apt-get remove javascript-common

Ezután már telepíthető a curl modul, csak ne felejtsük el az apache-ot leállítani az eltávolítás előtt:

service apache2 stop

Majd újra elindítani:

service apache2 start

Maga a telepítés

a webes felületen rémesen egyszerű, csak írjuk be az URL címet és már indulhat is, akár egy Joomla vagy WordPress esetében:

http://localhost/moodle

Az első lépésben ki lehet választani a magyar nyelvet is, ezzel is segítve a könnyű telepítést.
Arra azonban figyeljünk, hogy le fog futni egy automatikus teszt, ami ellenőrzi, hogy szerverünk alkalmas-e a végleges telepítésre. Valamint kérni fog minket a konfigurációs fájl létrehozására is, a telepítési könyvtáraknak megfelelő adattartalommal. Innen csak be kell másolnunk a megadott adatokat:

nano /var/www/moodle/config.php

Ezután már csak az utolsó simítások maradtak: végigmenni a telepítésen, beírni a MySQL-ben megadott felhasználót (moodleuser) és jelszót, valamint létrehozni az új Moodle felhasználót jelszóval… és kezdődhet is a kurzusok felvétele vagy a feladatsorok létrehozása.
Azt még megjegyezném, hogy én külön fizikális gépre szerettem volna telepíteni a saját hálózatomban, de a Moodle modul nem fogadja el a port forwarding-os beállításokat, legalábbis az én DDWRT-s router-emen keresztül, ezért érdemes saját domain-t vagy aldomain-t rendelni hozzá, ha kívülről szeretnénk elérni. Belső hálózaton, IP alapján, zökkenőmentesen működik hozzárendelés nélkül is.

Szólj hozzá!

Chipcsere festék toneren lézernyomtatóknál

2016. március 10. 23:07 - Zankó András

A korábbi üzemeltetési munkám során az egyik cégnek volt egy színes Canon LBP6020 típusú nyomtatója, amihez elég gyakran kellett új festéket vásárolni. Felmerült, hogy mi lenne, ha chip-eket vennék és azzal próbálnám meg a tonerek élettartamát megnövelni. Jó ötletnek bizonyult, mivel felével-harmadával kevesebb alkalommal kellett új tonert vásárolni. Azonban mielőtt kitérnék arra, hogy hogyan is kell azt a bizonyos chipet kicserélni, ejtenék pár szót a gyári és egyéb kazettákról.

Gyári, után-gyártott és/vagy után-töltött cartridgek, avagy miért érdemes “chip-elni”

A lézernyomtatókhoz gyárilag tartozó cartridgek úgy vannak kialakítva, hogy megfeleljenek a nyomtató egyedi használati struktúrájának és igényeinek. Összetétele alapján fényhengerből és festéktartályból áll: az előbbi végzi el azt a feladatot, hogy az utóbbi egyenletesen kerüljön fel a papírra. A chip pedig arra szolgál, hogy számolja a kazettával nyomtatott oldalak számát és továbbítsa azt a nyomtató felé. A gyártok az átlagos nyomtatható mennyiséget programozzák fel a nyomtatóba, így ha ezt a végső számot eléri a nyomatszámláló, a festékkazetta “üressé” válik. Ez azonban nem teljesen igaz: a legtöbb esetben ugyanis jóval több festékpor marad a tartályban, mint ami a lapra került volna. Persze, hiszen mikor nyomtat valaki állandóan egész oldalt befedő szöveget vagy grafikát? Nem minden nap – ez feltételezhető. Ezért ha a gyári “kifogyott” festékkazettáról leszedjük a chip-et és egy “nullkilométeres”  számlálóállapotúra cseréljük, akkor az eszköz úgy fogja érzékelni, mintha egy teljesen új cartridge került volna a gépbe.

De miért érdemes chip-elni? Manapság sokan választják azt a lehetőséget – természetesen anyagilag érthető módon -, hogy után-gyártott és/vagy után-töltött festéket vásárolnak. Habár nem feltétlenül járnak jobban, hiszen a “nem gyári” kellékek használata megrövidítheti az eszköz élettartamát, arról nem is beszélve, hogy ha garanciális időben megy tönkre a nyomtató és bizonyítható, hogy nem gyári kellékekkel volt használva, akkor a garanciális szervizelési jog is ugorhat. A legnagyobb probléma ezekkel a kellékekkel, hogy általában egy korábban kifogyott kazettát használnak “donornak” alapul. Mit is jelent ez? Az után-töltött kazetták esetében ugyanazt a vázat használják fel: szépen feltöltik valamilyen olcsóbb festékporral, szépen bedobozolják és már mehet is a gyári értékének feléért-harmadáért a piacra. Az után-gyártott típusok jobb esetben alapos bevizsgálás után teszik ugyanezt, esetlegesen valamely alkatrész cseréjével vagy legyártásával. Azonban ilyenkor a legtöbb esetben a fényhengert mindannyian felhasználják, nem számolva azzal, hogy annak is van egy bizonyos élettartama, és ezért nem lehet állandóan csak töltögetni a festékkazettákat. Így válhat a chip-elés egy köztes megoldássá a felhasználó számára.

Hogyan kell chip-et cserélni?

Az alábbiakban képekkel próbálom meg illusztrálni, hogy milyen módon kell a chip-eket kicserélni. Első lépésben nézzük meg, hogy miről is van szó. Az alábbi képen jól látszik, hogy a piros karikával bejelölt “fülek” rögzítik a chip-et a kazettára:

chipcsere-1.jpg

Ezeket a kis “füleket” kell eltávolítani egy éles eszköz segítségével:

chipcsere-2.jpg

Majd óvatosan kiszedni a régi chip-et:

chipcsere-3.jpg

Ha ezzel megvolt, akkor helyezzük be az új chip-et és készen is vagyunk:

chipcsere-4.jpg

Remélem hasznos segítség ez a kis bejegyzés azoknak, akik még nem csináltak ilyet és talán a kis elméleti bevezető pedig hasznos információkat tartalmaz azoknak, akik azon gondolkodnak, hogyan csökkentsék kellékanyag költségeiket úgy, hogy az hosszútávon ne legyen negatív hatással a lézernyomtató élettartamára. Ha tetszett a cikk, kérlek lájkold vagy oszd meg ismerőseiddel is!

Szólj hozzá!

WordPress telepítése Debian LAMP szerverre

2016. március 10. 23:05 - Zankó András

A minap elhatároztam, hogy meglévő saját Debian Linux LAMP szerveremre felhúzok egy weboldalt, hogy a felesleges használt számtech cuccaimat feltöltsem rá, és így esetlegesen egy kis plusz bevételhez juthassak. A választásom a WordPress-re esett, mivel korábban már volt dolgom vele, és azt a pozitív következtetést tudtam levonni, hogy egy átlagos otthoni felhasználó könnyebben elboldogul az adminisztrációs felület kezelésével. Azonban az sem elhanyagolható, hogy jók a SEO hatékonyságot elősegítő bővítményei és remek “responsive” sablonok vannak hozzá.

A telepítés természetesen egy működő LAMP szervert feltételez: Linux, Apache, MySQL és PHP. Valamint nem árt egy jó webes adatbázis-kezelő felület sem: esetünkben a phpMyAdmin.

lamp.jpg

Első lépés: A MySQL adatbázis konfigurálása a phpMyAdmin felületen

Miután “root” felhasználóként beléptünk az “Adatbázis” fülre kattintva hozzunk létre egy újat, például “wordpress” névvel.
Ezután a “Jogok” fülre lépve vegyünk fel egy új felhasználót, mondjuk ugyanezzel a névvel és egy általunk megadott jelszóval. Ha lejjebb görgetünk, láthatjuk a jogok beállítási opcióit, ahol jelöljük be az összes opciót.


Második lépés: A WordPress letöltése és telepítése

A következő feladatunk a WordPress legfrissebb csomagjának letöltése, amit az egyszerűség kedvéért szerverünkön manuálisan terminál parancssorból fogunk elvégezni – “root” felhasználóként bejelentkezve:

wget http://wordpress.org/latest.tar.gz

Amint a letöltéssel megvagyunk, csomagoljuk ki a letöltött állományt:

tar xvzf latest.tar.gz

Ezután hozzunk létre egy új mappát a “www” mappában, ugyanis ide fog kerülni az új weboldal. Esetünkben legyen például “html” a neve. Ide fogjuk átmásolni a kitömörített állományokat:

mkdir -p /var/www/html
cp -r wordpress/* /var/www/html

Harmadik lépés: A szükséges futó alkalmazások újraindítása és egyéb beállítások

A korábbi adatbázis és felhasználó felvétele, valamint a WordPress beimportálása után még el kell végeznünk egy-két beállítást. Az Apache és MySQL szolgáltatásokat újra kell indítani, és hozzáférést kell biztosítanunk a létrehozott mappához:

service apache2 restart
service mysql restart
chown -R www-data /var/www/html
chmod -R 755 /var/www/html

wordpress.jpg

Negyedik lépés: A WordPress webes telepítése és beállításai

Végezetül elértünk az utolsó lépéshez. A böngészőnkben írjuk be a megfelelő IP címet vagy domain-t (helyi gépen: localhost), ahol egyből meg is jelenik a WordPress webes beállítási felülete. Itt csak végig kell mennünk a beállítási segédlet utasításai alapján:

1, Hozzá kell rendelnünk a korábban beállított “wordpress” felhasználót és jelszót a WordPresshez.
2, El kell indítani a webes telepítést.
3, Be kell állítani az alapértelmezett információkat, mint például az oldal neve és a rendszergazdai felhasználónév (MySQL-ben felvett felhasználó, ugyanazzal a jelszóval, amit ott beállítottunk.)

Ötödik lépés: A mappa hozzáférésének visszavétele

Érdemes a hozzáférést a munka végeztével visszaadni a “root” falhasználó hatáskörébe:

chown -R root /var/www/html

Remélem érthető volt a leírás, de ha a telepítéssel kapcsolatosan bármilyen kérdésed vagy hozzászólásod lenne, akkor rajta!

Szólj hozzá!