A következő a kérés, a jelenleg futó postgresql 8.4 szerverünket, frissitsük postgresql 9-re.
A menet a következő:
1, Teljes backupot készítünk az egész jelenlegi adatbásisunkról.
PGUSER=postgres pg_dumpall >psql_db_all.sql
2, A futó postgresql 8.4 szerverünk mellé felrakjuk a psql 9-et, a már ismert módón.
Majd pedig állítsuk le a 8.4-es postgresql-ünket és indítsul el a 9-est.
3, Beimporálás az új frissen telepített db-be:
PGUSER=postgres pgql -f psql_db_all.sql
Aki sokat foglalkozik virtualizálós szerverekkel és mondjuk Oracle szervereket is üzemeltett, biztos nem kell bemutatni az Oracle Vm virtuális szervert. AKi pedig nem ismeri, érdemes utána néznie (vagy visszajönni ide késöbb, tervek szerint lesz belőle hosszabb cikk), azonban most csak egy telepítés közben fellépő hiba elhárítást mutatunk be.
Oracle VM server telepítve, Oracle VM manager telepítve. Első dolog ilyenkor egy ugynevezett pool-t, vagyis egy "tároló" egységet létrehozni, ahol is majd az adatfile-ok tartozkodnak. Oracle honlapján is remek kis leírások vannak, azonban ez a hiba sokszor előfordul.
OVM-1011 OVM Manager communication with [URL] for operation Pre-check cluster root for Server Pool failed: <Exception: Cluster root not found.>
Ha új diszkünk van (tehát friss telepítéskor is), kell megkell adnunk egy belső szkriptel, hogy melyik diszket használja mint root repo, vagyis hova pakolja az adatfileokat.
Hozzuk létre repos.py szkriptel (ha nem találjuk, akkor find / -name repos.py), példánkban a /dev/sdb1-es diszken../repos.p --new /dev/sdb1majd tegyük root módba, az elöbb generált hosszó kódnevével:
[ NEW ] a6584256-1a81-4be0-be31-18cc193044e5 => /dev/sd
./repos.py --root a6584256-1a81-4be0-be31-18cc193044e5majd listázzuk:repos.py --list
[ R ] a6584256-1a81-4be0-be31-18cc193044e5 => /dev/sdb1
Ha ezzel megvagyunk, már simán létre tudjuk hozni a server pool-unkat. Előrordulhat azonban hogy létrehoza után a server pool status error -t mutatt. Ebben az esetben, töltsük ki mindkét szerver (tehát a oracle VM és a VM manager gép) /etc/hosts fájlát pontosan. Legyen benne mindkét oldal szerverjei és a saját hostnevek is. Ezek után a meglevő pool-t töröljük, majd újra hozzuk létre. (Ha fura másmilyen menüt add, akkor egy restart se árt :)
(via OTN forum)
Postgres adatbázis kezelő telepítésére, több módszert használhatunk, azonban elötte tudnunk kell mire fogjuk használni késöbbiekben, és ha ennek megfelelően választjuk ki a módszert igencsak megkönnyítjük a késöbbi dolgokainkat.
Következzenek tehát a lehetősegek postgres 9.0 telepítéshez Centos 5-re.
-Telepítés forrásból:
Nos ezt akkor érdemes használni, ha teljesen sajátosak az igényeink, esetleg, több rendszerre ugyanazt a beállításokat akarjuk felvinni stb, ugyanis legjobban ez konfigurálható. Most erről itt nem írnék többet, ha ez érdekel katt ide.
-Telepítés hivatalos repository-ból.
A jelenleg futó linux alapú oprendszerek "gyári" repo-iból, a 8.4 verzió érhető el. Bár sokszor ez is elég lehet (itt megint előjön az elején feltett: "mire használjuk" majd kérdés), a fejlesztők sokszor ragaszkodnak a legfrissebb, stabil verzióhoz, itt jön képbe a postgres 9.0 hivatalos tároloja. Ez RedHat/Centos/Fedora-hoz való repo-k, de ha debian/ubuntu esetleg suse-hoz kéne, se keseredjünk, itt azt is elérhetjük :)
Telepítsük tehát a reponkat:
$rpm -Uvh http://yum.pgrpms.org/reporpms/9.0/pgdg-centos-9.0-2.noarch.rpmEz szépen mindent megcsinál helyettünk, még a gpg kulcsokat is feltölti, szóval ha egy
yum repolist -et lekérdezünk meg kell hogy kapjuk többeközött a
pgdg90 PostgreSQL 9.0 5 - x86_64 enabled
választ.
Ezek után nincs más dolgunk, csak felpakolni a minket érdeklő csomagokat. Ha csak alapteleítés kell nekünk, elég két csomag:
$yum install postgresql90.x86_64 postgresql90-server.x86_64
Ezek után első inditár előtt, adjuk hozzá /var/lib/pgsql/9.0/data/pg_hba.conf fájlban a következő sort
host all all samenet trust
-Telepítés Enterprise DB telepítő file-al (Legjobban Ajánlott!!):
Nem tudtam jobb nevet adni neki, lényeg hogy létezik az enterpriseDB-nek (postgresql hivatalosan támogatott verziója), ahol is egy előre gyártott .bundle file-ban (hasonlo a win-es exe-hez), sok minden belepakolnak.
Futassuk a szkriptet:
./postgresql-9.0.1-1-linux-x64.binEgy par kérdéses varázslón visz végig, pl hova telepítse magat a szoftver és hogy hol legyenek az adat file-ok, posgres user jelszavát stb. Ha kész a telepítés, állítsuk be a környezeti változokat. Egy előre legyártott remek szkript ezt meg is teszi nekünk ami a telepítési könyvtárban létre is jön, csak source-oljuk le.
source pg_env.sh
-Buktatók, avagy mire figyeljünk:
/etc/init.d/postgresql-9.0 start
Starting PostgreSQL 9.0:
pg_ctl: another server might be running; trying to start server anyway
pg_ctl: could not start server
Examine the log output.
PostgreSQL 9.0 did not start in a timely fashion, please see /u01/pgsql/data/pg_log/startup.log for details
, ha megnezzuk az ajánlott startup.log file-t jelzi, hogy "lock file "postmaster.pid" already exists", tehát a pid file-ja már létezik. Semmi gond, töröljük a file-t :
rm -rf /u01/pgsql/data/postmaster.pidMajd pedig inditsuk újra el, most már szépen futni is fog.
/etc/init.d/postgresql-9.0 start
Starting PostgreSQL 9.0:
waiting for server to start... done
server started
PostgreSQL 9.0 started successfully
Készen is volnánk a telepítés része, azonban ez csak a bevezető volt. Oroszlán rész még csak most következik.
Ha tavolrol kapcsoladasi error-t kapunk, szervesszuk a pg_hba.conf file-t amiben is a hozzaféréseket finomhangolhatjuk. Pl azt szeretnénk ha mindenki mindenhonnan hozzáférhessen távolról is az adatbázishoz (persze jelszó attol még kell), adjuk a konfigurácios fájlhoz ezt a sort (csak másodikat)# TYPE DATABASE USER CIDR-ADDRESS METHODA CIDR-ADDRESS részhez szabadon adhatunk, tartmányokat, vagy akár pontos IP-ket honnan is fogadjon kapcsolatokat.
host all all 0.0.0.0/0 trust
Ne felejtsük a tüzfalon átengedni a postgres forgalmát (5432)!
$iptables -I RH-Firewall-1-INPUT -p tcp --dport 5432 -j ACCEPTItt sincs most korlatozas, honnan is kapcsolodhatunk az 5432-es portra, vagyis mindenhonnan engedelyezett.
-További összetevők telepítése:
Fejlesztő kollegák kérnek, telepíts nekik dblink-et, postgis-t, pgadmin, pgagent-et.
Ha ezeket gond nelkul akarjuk telepíteni és használni is, a legjobban akkor járunk, ha az egyes modulokat/programokat csomagból fordítjuk. Viszont lesz pár függőségi csomagunk amikre majd szükségünk lesz, azonban néhanyuk- a szükséges legújabb verzió - csak a pgdg90 repoban talaljuk meg (pl Geos). Szóval ha eddig nem is volt fent a repo mert nem kellet, pakoljuk szépen fel a rend kedvéért.
$rpm -Uvh http://yum.pgrpms.org/reporpms/9.0/pgdg-centos-9.0-2.noarch.rpm
PgAdmin:
A PgAdmin népszerü open source alkalmazás, amivel deszktopunkról adminolhatjuk az adatbazisunk. A deszktop kliensünkön kivül a szerver oldalón is szükségünk lesz erre a programra. Amennyiben EnterpriseDB telepito file-al telepítettük a DB-nket, ez már benne is van, semmi dolgunk vele. Ha fent van a pgdg90 repon-k , csak keressünk rá és telepítsük.$ yum install pgadmin3_90Dblink:
Egy aprocska modul, melynek segítségével a távoli sémákból és adatbázisokból is kérhetünk le adatokat. Ez egy egyszerü sql file amit be kell importálnunk az adott sémába, ahol is használni szeretnénk. Ez az sql file a postgres-contrib csomagban található, ami az EnterpriseDB telepito file-al már rajta is van, ha pgdg90-es repo változatott használtjuk telepítsük a postgresql90-contrib csomagot.
Importálás a következő:
$psql -U postgres -d adatbazisod_neve -f /eleresi/utvonal/dblink.sqlKész is, illetve kész van, ha a public sémába akartad telepíteni, ugyanis az az alapértemezett. Igen ám, de vannak fejlesztök akik nem szeretik a public sémát és törlik egyből, nekik külön dblink séma kell és abban szeretnék hasznáni. Ebben az esetben töröljuk a public scheme majd hozzuk létre a dblink nevüt és probáljuk újra futattni a dblink.sql-t. Elvileg müködnie kell, de ha mégsem mert ilyesmi hibát kapunk , hogy : dblink ERROR: no schema has been selected to create in, sincs gon, csak valtoztassuk meg a keresési útvonalat: (az utolsó parancsot, csak hiba esetén kell használnunk)
postgres=# DROP SCHEMA public;
DROP SCHEMA
postgres=# CREATE SCHEMA dblink;
CREATE SCHEMA
postgres=# ALTER USER postgres SET search_path to dblink;
ALTER ROLE
postgres=# SHOW search_path;
search_path
-------------
dblink
(1 row)
Ezek után már futathatjuk dblink.sql fájlunkat, a megfelelő helyre fogja a function-okat betölteni. Ha másik db-re is szeretnénk megcsináni, csak ugyanezt az "útvonalválasztást" be kell állítani ott is.
Postgis:
Ennek az alkalmazásnak a telepítésével postgresql szerverünk alkalmas lesz, földrajzi objektumok kezelésére is, vagyis például egy térképeket kezelő alkalmazáshoz telepítenünk kell. Mielőtt arra gondolnánk hogy ez speciális igeny, gondoljunk csak rá hogy manapság, már minden alkalmazásnak vagy honlapnak van google map kiterjesztése.
Postgis-t is megtaláljuk csomag formájában a pdgd90 repo-ban, de nekem az valahogy nem müködött rendesen, szoval töltsük le a legfrissebb verziót, majd telepítsük. Azonban elötte kikell elégíteni pár függöséget, és ehez a pdgd90 repo-ra is szüksgégünk lesz, hiába is forrásból telepítjük a postgis-t.
yum install gcc libxml2 libxml2-devel geos geos-devel proj projMwget http://postgis.refractions.net/download/postgis-1.5.2.tar.gzEgyszerű nem? Jó is lenne, de van pár buktató amire figyelnünk kell. Ha valamilyen hibát dob, pl configure: error: could not find, valami csomag hiányzik, ellenőrizzük, hogy fent vannak e a függöségek (lsd előbb).
tar zxvf postgis-1.5.2.tar.gz
cd postgis-1.5.2
./config
make
make instal
Vagy ezt a hibát dobja:
make: *** [postgis] Error 2
Semmi gond, a perl forditót nem találja, futassuk igy a make parancsot:
./configure
make PERL=$(which perl)
make PERL=$(which perl) install
Ezek után nincs már hátra, mint beimportálni a postgis.sql-t. Ha nem találjuk keressünk rá.
find / -name postgis.sql
psql -U postgres -d postgres -f /elérési/útvonal/postgis.sql
Amire még előszeretettel panaszkodik, mindenféle lib-eket keress, amik -ha másnéven is- de fent vannak. Ilyenkor csináljunk rá symlinket és el is fogadja.
PgAgent:
Pgagent alkalmazás segítségével postgresql szervereinken komplex shell és batch szkripteket futathatunk időzitve. Telepítéséhez töltsuk le a legújabb stabil verziót.
Csomagoljuk ki, majd a pgagent nevu file-t másoljuk az /usr/bin/ könyvtárba. Figyeljünk rá, hogy legyen 755 jogosultsága futni.
tar xvf pgAgent-3.0.0-Linux.tar.gz Ezek után a szokásos: keressük meg a pgagent.sql fájlt, és importáljuk az adatbázisunkba:
cd pgAgent-3.0.0-Linux/bin
cp pgagent /usr/bin/
psql -U postgres -d postgres -f /elérési/út/pgagent.sql
Majd készítsünk neki kézzel egy inditó szkriptet.
vim /etc/init.d/pgagent
#!/bin/bash
#
# /etc/rc.d/init.d/pgagent
#
# Starts the pgagent daemon
#
# chkconfig: - 65 35
# description: PgAgent Postgresql Job Service
# processname: pgagent
# Source function library.
. /etc/init.d/functions
RETVAL=0
prog="PgAgent"
start() {
echo -n $"Starting $prog: "
daemon "pgagent hostaddr=127.0.0.1 dbname=postgres user=postgres"
RETVAL=$?
echo
}
stop() {
echo -n $"Stopping $prog: "
killproc /usr/bin/pgagent
RETVAL=$?
echo
}
#
# See how we were called.
#
case "$1" in
start)
start
;;
stop)
stop
;;
reload|restart)
stop
start
RETVAL=$?
;;
status)
status /usr/bin/pgagent
RETVAL=$?
;;
*)
echo $"Usage: $0 {start|stop|restart|reload|status}"
exit 1
esac
exit $RETVAL
Adjunk neki futási jogot:
chmod 755 /etc/init.d/pgagent
Ha most elindítjuk, valószinűleg, több lib-et is keress majd, ami fentvan ő mégse találja, mivel kicsit más a nevük.
Starting PgAgent: pgagent: error while loading shared libraries: libssl.so.0: cannot open shared object file: No such file or directory
meg még
Starting PgAgent: pgagent: error while loading shared libraries: libcrypto.so.0: cannot open shared object file: No such file or directory
Symlinkeljük be neki.
ln -s /lib/libssl.so.6 /lib/libssl.so.0Most már mennie kell:
ln -s /lib/libcrypto.so.6 /lib/libcrypto.so.0
/etc/init.d/pgagent start
Starting PgAgent: [ OK ]
Nos a helyzet a következő:
Centos 5-ön készülünk cluster-t építeni, Pacemaker és OpenAIS alapokon. A clusterlabs-on remek kis leirásokat, sőt saját repo-t találunk a szükséges szoftvereinkhez. Felrakjuk a repo-okat, aztán fel yum-ozzuk, illetve csak felyummoznánk a különbözö cluster komponenseket, mivel a telepítés elszáll a következő hiba üzenettel:
"Error: Missing Dependency: libcpg.so.2(OPENAIS_CPG_1.0)(64bit) is needed by package cman-2.0.115-34.el5_5.3.x86_64 (updates)".
Plusz még 3 további függöségre is panaszkodik. De minket nem ver át, keressünk rá az említett modulokra: "locate libcpg.so.2", hoppá, de hát ezek fent vannak a gépen, mégis mi a baja? A problémája a kedvenc centos szerverünknek, hogy az openais csomag verziója kissé elavult. Nincs már dolgunk mint leszedni, majd frissiteni. A módszer a következő lépésekben a legelejéről.
1, Először is szükségünk lesz a remek EPEL repo-ra tehát telepitsük:
su -c 'rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm'
2, Továbbá szükségünk lesz a Clusterlabs saját repojára:
wget -O /etc/yum.repos.d/pacemaker.repo http://clusterlabs.org/rpm/epel-5/clusterlabs.repo 3, Most jönne a Pacemaker install, de mivel tudjuk hogy ez elszállna függöségi problémákra hivatkozva, előzzük is gyorsan meg és kérdezzük le az open is jelenlegi verzióját:
rpm -qa|grep openais
openais-0.80.6-16.el5
Ez bizony elavult, jelenleg már 1-es verzió felett járunk, természetesen a cluterlabs repojában is azt kapjuk, viszont ha ez is fent van, akkor összeakadnak. Tehát töröljuk, méghozzá ignorálva a függöségeket, mert azok kellenek majd nekünk a következő verzióhoz is:
rpm -e --nodeps openais-0.80.6-16.el5
Most már nincs akadálya a pacemaker telepítésének, gépeljük is be a parancsot azon nyomban:
yum install -y pacemaker corosync heartbeat
Szép hosszú listát kapunk, amiben vígan jelzi, hogy sikerült feloldania minden függöséget, pár perc telepítés után pedig megkapjuk a jól megérdemelt Complete! üzenetünket.
Cluster telepítésröl és annak beállításáról késöbb lesz még szó és talán még lépésről lépésre levezetett "hogyan" is, szóval érdemes lesz vissza látogatni. Cheers :)
Az android a mai mobil világban szélsebesen terjed, lényegében egy linux kernelre épülő mobil operációs rendszer. Ebben a kis értekezésben, feltörünk (rootolunk) egy HTC magic-et, majd megnézzük, milyen ügyességeket lehet vele így csinálni. A bejegyzés konkrétan HTC magic alapján készült, a módszer nagyjából megegyezik az összes HTC modelnél, maximum a titkos menüket más gombkombinációkkal érhetjük el és ROM frissítéskor figyelni kell, hogy jó verziót töltsünk le hozzá. Jelenleg az android a 2.2-es (froyo) verziónál tart, de sok telefont a mai napig 1.6-ossal árulnak és ezt szeretnénk mi update-elni.
Van ugye a hivatalos update, de azt hagyjuk meg a windows és mac user csajoknak :D. A mi módszerünk a rootolás, aztán tetszőleges ROM feltöltése a telóra. Figyelem: A lent leirt módszer, garanciavesztéshez vezethet, és a nem megfelelő működésért a linuxadmin szerkesztősége nem vállal garanciát!!
A módszer esetenként eltérő lehet, de az alapmódszer az összesnél ugyanez. Szükségünk lesz egy HTC telóra (esetünkben ez HTC magic), egy számítógépre (esetünkben ez ubuntu linux 10.04) valamint egy kis Android SDK-ra (bár enélkül is megoldható, de így linuxadminosabb :)
Töltsük le az Android SDK-t és a fastboot-ot. A telepítés linuxon nagyon egyszerű, kicsomagoljuk majd pedig mint egy szkript(./adb) futtatjuk a különböző kis utilytiket. Mivel ez egy fejlesztői környezet, amit letöltöttünk, mi pedig csak kicsit hekkelni akarjuk a telónk, sok mindenre nem lesz szükség."adb" és "fastboot"-tal be is érjük. Ha azt szeretnénk, hogy ne kelljen a könyvtárba menni, hanem a parancsokat elérjük bármikor, rakjuk be a PATH-ba.
$vi /etc/bash.bashrc
export PATH=/home/burg/android/android-sdk-linux_x86/tools:$PATH
Először is root-olnunk kell a telót, hogy bármi "extrát" csinálhassunk vele, ami megfelel az iphone jailbrakelésével. Persze míg azt büntetik, ezt támogatják, de ugye ez már más téma :) Valójában arról van szó, hogy root jogosultságot kapsz a telódhoz, ami alapból nincs benne. Bár mint ahogy írtam, ez garanciavesztéssel járhat, de ha nem bánod, megéri a dolog, egyrészt szabadon cserélgetheted a ROM-okat rajta, amiből lelkes programozók rengeteget csinálnak nap mint nap, nagy eséllyel találsz valamit, amit az igényeidhez vannak szabva. Másrészt az Android marketen is sok okos alkalmazás igényli a root jogosultságot a működéséhez.
Tehat rootoljunk.
1, Usb-vel kössük a telefont a gépre, majd pedig a telefonon állítsuk be a következőt: settings->applications->development->"USB Debugging"
2, Ellenőrizzük, hogy a gép felismeri a telefont. A következő parancsot (és az összeset ami a keretes ablakban van, terminálbol adjuk ki a gépünkön) a gépünk termináljából adjuk ki:
$adb devices
List of devices attached
HT94TKF12298 device
Ha látjuk a telefonunk sorozatszámát, akkor nyertünk. Ha nem, akkor gond van, de lehet csak nincs jól csatlakoztatva az usb.
3, Töltsük le a rootme-signed.zip ROM-ot, majd update.zip néven másoljuk fel a telefon sd kártyájára:
$adb push rootme-signed.zip /sdcard/update.zip
830 KB/s (57142984 bytes in 67.184s)
4, Rakjuk a telefonunkat "fastboot" módba, bekapcsoláskor a bekapcsoló gomb + hangerő lefele hosszan!! Ekkor megjelenik három gördeszkázó android, és felül sorban adatok a telefonról, amire szükségünk lesz. Esetünkben ez sappihire és 32B a két adat, ettől függően töltsük le a recovery img-t, amire szépen ráboot-olunk (Figyelem : fasboot módban kell lenni hozza és sudo jogosultsággal!!):
$fastboot boot recovery-RA-sapphire-v1.7.0G.img
Ekkor újra indul a telefon és a kiválasztott recovery.img-re fogunk rábootolni. Igazából van a telefonnak saját recovery-je, amit úgy érünk el bekapcsoláskor, hogy bekapcsoló gomb+home hosszan, de nekem jobb tapasztalatom volt a rábootolós verzióval és többet is tud.
5, Ha bent vagyunk az Android system recovery menüjében (lásd kép), a menüpontok közt ugrálva, először is backupoljuk az adatainkat, ha van valami amit meg szeretnénk tartani. Azután "Wipe-oljuk", vagyis töröljuk a memóriakártyát. Érdemes az összes "wipe-almenüt" végig nyomkodni (wipe data/factory reset, wipe cache, wipre dalvik-cache), ha ezt nem tesszük meg - nem feltétlenül - de hibára futhat az install. Ezek után mehet a "Flash zip From sdcard" vagyis telepíthetjük az új ROM-ot, jelen esetben a rootme-signed.zip-et. Ezután a telefonunkat pár percre magára hagyhatjuk, menjünk ki egy kávéért, és mire vissza érünk, ha minden jól ment, installation finished fogad minket. Ezek után egy Reboot system now-ra lesz már csak szükségünk, és készen is volnánk!
Android frissítés:
Mint ahogy említettem már, a rootolásnak sok előnye van, de mi most az android frissítés miatt "gyökereztük" meg a telefonunkat. Ha eddig eljutottunk, innen már pofonegyszerű, tulajdonképpen csak az előző lépéseket ismételjük meg, más update.zip csomagokkal.
Rengeted saját (tovább) fejlesztésű android firmware-t tölthetünk le, én a CynogenMod csapat, rendszeresen frissített, minden telefonra külön fejlesztett munkait ajánlanám. Ezekből az alap ROM-okbol, lelkes programozók még tovább hekkelt OS-eit, innen tölthetjük le. Itt telefonunk szerint szűrhetünk, de figyelem: nem minden ROM működik közre a telefonunkkal, még ha "papíron" supportálta is, előfordulhat, hogy többet ki kell próbálni.
1, Másoljuk fel a letöltött ROM-ot update.zip néven az sd kártyánkra:
$adb push update-cm-6.0.0-DS-signed.zip /sdcard/update.zip
2, Fastboot mod-ban, rábootolunk a Recovery image-ünkre. Figyelem sudo jogosultság kell hozzá!!
$sudo fastboot boot recovery-RA-sapphire-v1.7.0G.img
3, "Söpörjük ki" a kártyánkat, tehát a Wipe almenüben található, törlés processzeket csináljuk végig (wipe data/factory reset, wipe cache, wipre dalvik-cache).
4, Töltsük rá a telefonunkra az új ROM-ot "Flash Zip from SD card". Ezek után automatikusan telepíti a dolgokat, majd a végén restartoljuk a telefont. Első boot eltart egy ideig, azt végig várjuk és készen is volnánk!
Hibakeresés:
Bár a processz igen egyszerű, ha már tudjuk mit hogyan csináljunk, van pár buktató. Íme a tipikus hibaüzenetek és a kezelésük:
- can't symlink /system/xbin ,failure at line 12
Nem nagy ügy, egyszerűen betelt a /system partíció. Mivel úgyis épp új ROM-ot szándékozunk telepíteni, nyugodtan töröljük a partíció tartalmát.
$adb shell; rm -rf /system/*
- E: can't find update script
Nagy valószínűséggel nem tetszik neki a recovery image verziója. Próbáljunk rábootolni fastboot módban (bekapcsoláskor bekapcs gomb+hang gomb lefelé) a legújabb verzióra.
$sudo fastboot boot recovery-RA-sapphire-v1.7.0G.img
- E: No signature (208) E: Verification Failed when trying to install the latest system update !
Itt bizony nincs még a telefonunk rootolva, tehát minden ezirányú próbálkozás elszáll ezzel a hibaüzenettel.
Egy nagyon egyszerű, de annál hasznosabb és hétköznapi témát feszegetünk ma is. A backup fontosságáról most nem beszelnék, erre úgyis mindenki maga jön rá, az első jelentős adatvesztésekor. Szóval feltételezzük, ez már megvolt es szeretnénk backupolni. Mysql szerver manapság elég sok helyen megtalálható, rengeteg honlap, alkalmazás mögött fut megbízhatóan. Kezelése igen egyszerű és hatékony.
A backupplant, vagyis hogy a mentések milyen stratégia szerint készülnek, egy komoly téma, és sok-sok összetevője lehet, majd másik alkalommal kitárgyaljuk. Ez alkalommal egy nagyon egyszerű esetett veszünk gyakorlatban végig. Van egy szerverünk, amin egy belsős wiki oldal fut, amögött álló mysql szervert szeretnénk rendszeresen automatizálva mentesni.
Mysql szerver telepítéséről rengeteg jó leírás található a neten, a mai modern linux rendszereken két paranccsal kb. az egész megoldható, nem térnék erre ki, szóval feltételezzük, az adatbázisunk már fent és fut (up and running ) :)
A módszer pofon egyszerű :egy rövidke szkriptet készítünk, ami aztán a crontabbol fog futni.
A kedvenc eszközünk pedig ehhez a mysqldump lesz, amit megfelelően paraméterezünk:
#!/bin/sh
/usr/bin/mysqldump -uroot -pjelszo --opt wikidb -c | /bin/gzip -9 > /var/backup/wikidb_$(date '+%Y%m%d').sql.gz
Az értelmezése a következő: mysqdump a segédeszköz, amivel mentést készítünk (ún. dumpot készítünk, -u után következik a user amelyikkel csináljuk, itt most root szerepel, de bármelyik user megfelelő, ha van íras/olvasás joga az adott DB-re. -p jelszó, --opt adatbázis név.
A | jel utáni rész kihagyható, ez egy egyszerű tömörítési eljárás. A dumpot vagyis a mentést átadjuk a gzip programnak, majd a -9-es kapcsolóval extra magas tömörítést kérünk rá.
Elég hasznos, egy nagyobb adatbázisnál, ha csak biztonsági mentést csinálunk, töredékére tömörítheti az adatbázis mentést, amit persze kitömöríthetünk, ha szükség van rá. Ne felejtsük el futathatóvá tenni a szkriptet (chmod 755 backup_wiki.sh)
A > jelel pedig az egészet bele irányítjuk egy file-ba, ami maga lesz a mentésünk. A hozzáillesztjük a filenévhez az ún. "timestampet" akkor mindenkori mentésednek a neve (ebben az esetben) wiki_db_mentesidopontja.sql.gz lesz.
Ezek után nincs más hátra mint berakni a cronbtab-ba, hogy automatikusan futassa, az altalunk megadott időpontokba. Crontab egy remek kis időzítő eszköz a linuxban, szkripteket, parancsokat időzíthetsz és ismételhetsz, bármilyen időközönként.
A tartalmat a crontab -l paranccsal kérheted le, szerkeszteni pedig a crontab -e paranccsal lehet. Tehát szerkesszük is meg, és rakjuk bele a szkriptünket. A példánkban minden vasárnap hajnali 4 kor fog futni a szkript. Tehát - adatbázis méretétől függően - 4 után par perccel (pár 10-el, pár órával) kész a friss mentésünk az adatbázisunkról.
crontab -e
00 4 * * 0 /var/backup/backup_scripts/backup_wikidb.sh
Az cron felépítése eleinte fura lehet, de egyszerű és hatékony. 5 db * jelzi az időzítést sorban: perc, óra, nap, hónap, a hét napja (számszerint: vasárnap 0, hétfő 1, kedd 2, stb.). Utána pedig a parancs, esetünkben a szkript. Tehát ha azt akarjuk hogy valami minden nap pontban 3:30 kor fusson, a következőképpen kell rendezni a cronunkat: 30 3 * * * parancs. És így tovább.
Készen is volnánk, ezek után ha van külön backup szerverünk, akkor szinten szkriptesítve/crontabbal megoldhatjuk, hogy átmásolja azt oda, vagy pedig alapból a backupot oda irányítani. Meg érdemes egy olyan szkriptet is ami időközönként "takarít", tehát az elavult backupokat törli.
#!/bin/sh
find /var/backup/ -type f -mtime 3|xargs rm -f
A működése szerint, a /var/backup könyvtárban keresi azokat a fileokat (tehát nem könyvtárakat), amik 3 napnál régebbiek és azokat törli. Természetesen a backuplan része, hogy ezeket a mentéseket milyen gyakran töröljük. Ha kész a szkript, futatthatóvá tesszük es cronba rakjuk ezt is.
Ubuntu szerverrel kevesebbet találkozom, de mikor igen, gyakran megtréfál, mivel sok minden máshogy van rajta mint egy jó kis klasszik redhaten vagy centoson. Szóval egy ubuntu 10.10-es szerveren fut egy Oracle 11g adatbázis kiszolgáló, ami a mostani történet szempontjából nem is fontos, csak azért legyünk pontosak. Egy ártatlan apache és kernel frissítés után, jó öreg iptables barátunk eldobta az agyát, és a default policy-ket mind átállítgatta. A dolog ott tűnt fel, hogy meg egy ssh-t se tudtam létrehozni. De konkrétan minden csomagot dobott, szóval a net se ment. Nem nagy cucc visszaállítani, de volt pár köröm mire, rájöttem mi a gond (koszi DeeJayy).
Alapból az iptablesnek a következőkeppen kéne kinéznie, ha egy egyszerűen lekérdezed a státuszat:
iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Na most az upgrade ezeket szépen elállította, és ubuntus jó szokás szerint, kissé fura formázattal adta elő. No worries, adjuk ki a következő parancsokat:
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
És rendben is lettünk. Értelemszerűen visszafelé is működik, tehát ha DROP-ot raksz a parancs végére, akkor mindent eldobsz, és kobiztonságos szervered lesz :DD
Ezek után már csak adjuk hozza a szabályokat, amiket nagy okosan előtte kireseltünk.
Volt egy pár álmatlan munkanapom, amíg sikerült rendesen behegesztenem az ssl certifikaciot kedvenc tomcat webszerverünkbe. Még egy kis segítséget is kaptam a végén, amit ezúton is köszönök. Foglaljuk is össze hogyan is néz ki a telepítés és mik a buktatók.
Az SSL (Secure Socket Layer; Biztonsági Alréteg) egy protokoll réteg és amint azt a neve is mutatja, elsősorban forgalom titkosításhoz használjuk. A 7 rétegű OSI réteg, 3-as azaz Hálózati réteg és a 7-es applikációs réteg közt helyezkedik el. Titkosítás szempontjából három technológia használatos, Public-Private key azaz a nyilvános-titkos kulcs pár, a Symmetric Key azaz a szimmetrikus kulcs és a Digital Signature vagyis a digitális aláírás. Ebbe most nem megyünk bele mélyebben, ha érdekel titeket, rengeteg jó, magyar nyelvű leírás is van a google-n :)
Tehát vegyük egy kicsit gyakorlatiasabbra. A cél, hogy egy ssl szertifikációt installáljunk, tomcat alapú webszerverünkre, vagyis a tomcat alatt futó applikáció/honlap/whatever, https protokollon is elérhető legyen.
Alapfeltétel a java es a tomcat (meglepő). Itt található egy leírás ezek telepítéséről. Ha ezek megvannak, kedvenc java-s szerszámunk is a rendelkezésünkre áll, amivel könnyedén végig hegeszthetjük az egészet. Először is generáljunk egy privát kulcsot amit az ún. keystore-ban fogunk használni.
$keytool -genkey -alias sajat_alias_neved -keyalg RSA -keystore sajat_keystore_eleresiutvonal_plusznev
Enter keystore password: password
Ha nem adjuk meg a -keystore parameter, akkor egy rejtett .keystore nevű file az alapértelmezett. En a servernev.keystore konvenciót szeretem, jól átlátható és backupolható.
Itt majd kér egy passwordöt, amit adjunk meg is szépen neki. Majd még sok-sok jópofa kérdést kapunk, amire szintén válaszoljunk legjobb tudásunk szerint.
Ennek az eredménye 1 db file lesz, a már említett server.keystore, ami a kulcsokat tartalmazza, a java/tomcat számára emészthető formában.
A keytool -list -keystore saját keystore.keystore paranncsal le is kérdezhetjük, mit is tartalmaz a fileunk. Ez sokszor jól jöhet, ha már annyi cert van bele importálva, hogy összekavarodunk tőle.
Ha saját cert-el beérjük, akkor készen is lennénk, már csak a tomcat confignak kell megmutatni, hol is keresse a keystore-t. Ilyenkor van az tipikus jelenség, hogy egy http oldalra tévedsz (jellemzően intraneten), hogy a böngészővel le kell töltened a "self signed" certet es elfogadnod a rizikót, amit vállalsz a honlap megnevezésével.
Sokszor azonban nem érjük be ún. "self signed" cert-el, hanem vaskos pénzért (vagy akár olcsóbbért is) vásárolhatunk "certified" cert különböző cégektől, cserébe a böngészőnk se fog óvatoskodni.
Ilyenkor pedig a már meglévő keystore-unkbol - amiben ugye már ott pihennek a kulcsaink - egy certreq-et, vagyis egy "aláírás kérelmet" importalunk ki, amit elküldve a szolgáltatónak, visszaküld egy ellenőrzött cert-et amit aztán visszaimportalunk a keystore-unkba.
$keytool -certreq -keyalg RSA -alias sajatalias -file certreq.csr -keystore sajatkeystore
Enter keystore password: password
Az aliasnak bármit megadhatunk, amit a certifikació megkülönböztetésül használjuk majd, de jól jegyezzük meg, mert a tomcat konfigban és a visszakapott aláírt cert-ben is majd ezt kell használni!
A certreq.cst fileunkat pedig elküldjük a legszimpatikusabbnak talált cégnek aki aláírja majd és visszaküldi. A visszakapott és leellenőrzött file-t másoljuk be a szerverünkre, majd importaljuk be.
$keytool -import trustcacerts -alias sajatalias -file visszakapott.crt -keystore sajatkeystore
Ezek után még szükségünk lesz az ssl szolgáltó cégnek az ún. root és az inter (opcionális) certifikaciójára, mivel ez a egész eljárás hierarchikus felépítésű. Tehát irány a cég honlapja és onnét letöltjük a root.crt, illetve az inter.crt file-t, majd ezeket is jól beimportáljuk:
$keytool -import trustcacerts -alias root -file root.crt -keystore sajatkeystore
$keytool -import trustcacerts -alias inter -file inter.crt -keystore sajatkeystore
Ezek után nincs más hátra, mint megadni a tomcat konfigjában a helyet, hol is keresse a keystore fájlunkat. Alapból ki van kommentezve, és mivel xml a konfig, nehéz rátalálni, de ezt a sort kell keresni:
$vi /tomcat/conf/server.xml
<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile="/root/sajat.keystore" keystorePass="keystore_jelszo"
keyAlias="sajat_alias"
/>
Következzen egy szintén elég gyakori és mindennapos feladat. Samba share létrehozása. Windows uralta világunkban, elég magas számban a Linux szervereket is windows munkaállomásokról érik el. Kell egy kapocs, amivel a két eléggé különböző rendszer szót ért. Ez a kapocs a Samba, ami az ún. smb protokollt használja és elsődleges célja a nyomtató és file megosztás volt. Persze rengeteg hasznos (és haszontalan) kiegészítő érhető el hozzá, most azonban csak a legklasszikusabb felhasználásra vetünk pár pillantást.
Tehát adott egy Centos 5.5 (mi más) szerverünk, aminek egy könyvtárat (vagy többet) szeretnék hálózaton megosztani, és a hálózaton belül elérhetővé tenni. Ezt az elérhetőséget viszonylag finomat vezérelhetjük, tehát lehet bárki számára elérhető, lehet felhasználó/jelszó párossal saját samba userekkel elérni, de akár különböző címtárszolgáltatás alapú authentikációt is végezhetünk. Active Directory-val összehegeszteni mókás feladat, azonban azt majd máskor dokumentáljuk (egyszer elég volt végigcsinálni :) )
Telepítsük a samba szervert a gépünkre:
yum install samba
Ha készen vagyunk, a fő konfigurációs file szerkesztésének neki is állhatunk. Az alap konfig file, szép hosszú, rengeteg kommenttel és kikommentezett opcióval, én rendszerint ezeket lementem (mv /etc/samba/smb.conf /etc/samba/smb.conf.bak) majd újra létrehozva a file-t, csak a legfontosabb adatokat rakom bele. Így számomra jobban átlátható, de persze ez mindenkinek a saját ízlése szerint. Tehát a lecsupaszított konfig file:
vi /etc/samba/smb.conf
[global]
workgroup = windows domain vagy workgroupod
server string = Samba Server Version %v
passdb backend = tdbsam
cups options = raw
[homes]
comment = Home Directories
read only = No
browseable = No
[printers]
comment = All Printers
path = /var/spool/samba
printable = Yes
browseable = No
available = No
[shared]
comment = /shared
path = /shared
valid users = lscswebadmin
read only = No
A konfig file-ban a [global] szekció jelzi az alapbeállításokat. Mint ahogy írtam, rengeteg mást is oda lehet meg rakni. Az összes többi kapcsos zárójel, pedig a különböző megosztások és azok beállításai. Ezekből csak a [home] share ami még kötelező megadni, a többi csak saját példa.
A legegyszerűbb authentikáció, ha létrehozunk egy samba usert a saját kis beépített tool-jával.
smbasswd -a sajatsambauseredneve
remek kis tool-ok járnak a samba-hoz, sok mindent meg lehet velük oldani CLI-ben.
Pl így listázható ki a samba userek:
pdbedit -L
Ami fontos még, a megosztott könyvtárak linux szintű jogosultságai. Tehát ha hozzárendeled egy userhez a könyvtárat, amit megadsz neki a konfigurációban, sok fejfájástól kímélhet meg, ha osz szinten is van jogosultsága abba írni :) Tehát vagy írás+olvasás jogot adsz (persze ha akarsz is bele írni) nem csak a tulajnak, vagy ha pedig az egész tulajdonjogot átruházod a usernak chown-al (persze ha van olyan nevű OS user).
Első bejegyzésként, egy gyakori és mindennapos telepítéssel inditok. Mivan akkor ha legujabb tomcat-re és legújabb sun-os JDK-ra van szükségünk? Ugye a jelenlegi repo-ok csak tomcat 5-ot tartalmaznak, JDK-ból is csak OpenJDK-t. Najó van valami jdk.x86_64 csomag a centos alaprepoiban is, de ezt sose mertem kiprobálni még :)
Szóval kezdjük is el. A tomcat ugye nem más, egy java nyelven irodótt webszerver, ergo alapkövetelmény a java, szóval irány a sun, bocs az oracle honlapja, beszerezni a legfrissebb JDK-t:
http://www.oracle.com/technetwork/java/javase/downloads/jdk6-jsp-136632.html
a szerverünkön pedig, a már jó előre létrehozott /usr/java/ könyvtárba, wget-tel mentsük le. Egy szép hosszú és nehezen olvasható file lesz a jutalmunk ha letölt, ezt érdemes valami emészhető formába átnevezni mv-vel. Példánkban ez jdk.rpm.
Majd tegyük futatthatóvá a telepítő szkriptet:
$chmod 755 jdk.rpm
És akkor futassuk is:
$./jdk.rpm
Ezek után néhány enter és kész is vagyunk a sun JDK telepítéssel. Persze mégse vagyunk kész, mert most jönnek az útómunkák. Ha volt esetleg openJDK a gépünkön, akkor adjuk meg az alapértelmezett java-t neki. Ezt a jó öreg /sbin/alternatives segítségével tesszük meg:
$alternatives --config java
There are 3 programs which provide 'java'.
Selection Command
-----------------------------------------------
* 1 /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java
2 /usr/lib/jvm/jre-1.4.2-gcj/bin/java
+ 3 /usr/java/jdk1.6.0_21/bin/java
Enter to keep the current selection[+], or type selection number: 3
teszteljük, hogy tetszik e ez neki:
$java -version
java version "1.6.0_21"
Java(TM) SE Runtime Environment (build 1.6.0_21-b06)
Java HotSpot(TM) 64-Bit Server VM (build 17.0-b16, mixed mode
Ezek után adjuk meg a környezeti változokat, legegyszerübb ha bepakoljuk a /etc/profiles file-ba a következő befegyzést.
export JAVA_HOME=/usr/java/latest
export PATH=/usr/java/latest/bin:$PATH
majd file mentés, és hozzuk a tudtára hogy egyből hogy használja is a megadott környezeti változokat, "szorszoljuk" le :
$source /etc/profile
Ezek után ha a az:
echo $JAVA_HOME- ra megkapjuk hogy /usr/java/latest akkor bingo! Java JDK telepités kipipálva.
Következhet a Tomcat.
A jó öreg tomcat egy apache project, remekul kiegészítik egymást a httpd/apache2 termékkel, de ha javas környezetben, elég jól jön a tomcat, szóval barátkozzunk meg vele és használjuk lelkesen :)
A http://tomcat.apache.org/download-60.cgi címről szépen le is tölthetjük a legfrissebb változatott, majd a szintén előre létrehozott /usr/tomcat konyvtárban kicsomagoljuk. A tomcat telepítés ezzek kész is :) persze, itt is kellenek még nekünk utómunkák. Elöször az /etc/profile file-hoz, adjuk meg a tomcat környezeti változoját, vagyis:
export $CATALINA_HOME=/usr/tomcat/apache-tomcat-6.0.18A tomcat-nek illik tomcat user alatt futnia, szóval hozzuk ezt is létre:
group add tomcat
useradd -g tomcat -d /usr/tomcat/ tomcat
chown -R tomcat:tomcat /usr/tomcat
Ezek után hozzuk létre az inditó szkriptet, aminek köszönhetően, aztán service tomcat start/stop parancsal tudjuk inditani/leállítani a konzolból a tomcatünket:
vi /etc/init.d/tomcat
#!/bin/sh
# Tomcat init script for Linux.
#
# chkconfig: 2345 96 14
# description: The Apache Tomcat servlet/JSP container.
export JAVA_HOME=/usr/java/jdk1.6.0.21
export CATALINA_HOME=/usr/tomcat/apache-tomcat-6.0.18
JAVA_OPTS="$JAVA_OPTS -Xms128m -Xmx512m -XX:PermSize=32m -XX:MaxPermSize=128m "
JAVA_OPTS="$JAVA_OPTS -Xss2m -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled "
export JAVA_OPTS
/bin/su tomcat $CATALINA_HOME/bin/catalina.sh $*
Nagyjából ennyi, készen is lennénk. Bár a példánkban Centos 5.5 -os rendszert használtam, ez nagyjából minden linux disztron hasonló képen zajlik.
