Archiv pro rubriku: Operační systém

První krůčky s CzechIdM Kapitola 1: Instalace potřebných programů

czechidm

Dobrý den, vítejte u první části našeho detailního seriálu, ve kterém si ukážeme, jak nainstalovat a nakonfigurovat náš systém pro CzechIdM, a také si ukážeme základní práci s CzechIdM. V této části si nainstalujeme programy, bez kterých bychom CzechIdM nemohli zprovoznit. Každý z těchto programů je důležitý stejně tak jako jeho následné nastavení, proto vyskytnou-li se problémy, pokuste se je spravit nebo mne kontaktujte.

Nyní přistoupíme k samotné instalaci. Pro korektní běh aplikace CzechIdM jsou potřeba pouze tři věci (MySQL, Java (jdk, jre), JBoss). Všechny tři programy spolu nyní nainstalujeme, nastavíme a vysvětlíme jejich důležitost pro běh CzechIdM. Veškeré nastavení a instalace budou prováděny v rámci operačního systému Ubuntu ve verzi 14.04 64bit. Všechny příkazy začínající $ jsou příkazy pro terminál.

Instalace MySQL

MySQL je důležité pro práci s databází. V databázi budou drženi jednotliví uživatelé a CzechIdM se do MySQL bude přes konektor připojovat. Bez MySQL bychom měli sice velmi silný nástroj na správu identit, ale žádná data, se kterými bychom pracovali. Přejděme tedy k instalaci MySQL.

Nejdříve nainstalujeme MySQL a MySQL server. Tato instalace probíhá přes balíčkovací systém yum. Pokud Vám při zadání prvního příkazu instalace vyskočí chybová hláška o chybějící programu yum, jednoduše ho doinstalujte zadáním sudo apt-get install yum do Vašeho terminálu.

$yum install mysql
$yum install mysql-server

 

Nyní nastartujeme MySQL server pomocí příkazu

$sudo /etc/init.d/mysql start

Pokud nenastala žádná chyba, máme nyní úspěšně nainstalované aplikace spravující databáze.

Instalace Javy a konektoru pro připojení k MySQL

Druhým krokem, který musíme udělat, než spustíme náš server s CzechIdm, je instalace Javy a to konkrétně JDK. JDK v sobě mimo jiné obsahuje Java Runtime Enviroment, jež je potřeba ke spouštění aplikací napsaných právě v Javě. Začněme tedy s instalací.

Přejdeme na stránku http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html a stáhneme si zde JDK ve verzi 1.7 pro 64bitový systém Linux. Stažený archiv si rozbalíme a překopírujeme do adresáře /opt pomocí příkazů

$tar -xzf jdk-7u51-linux-x64.tar.gz
$mv jdk1.7.0_51 /opt/

Instalační skript pro JBoss má zadanou cestu k Javě. Jelikož by bylo zbytečně složité pokaždé přepisovat instalační skript pro instalaci, vytvoříme symbolický odkaz na složku, kde máme umístěnou Javu.

$ln -s /opt/jdk1.7.0_51 /opt/jdk

Dále nainstalujeme prostředí pro spuštění Javy

sudo add-apt-repository ppa:webupd8team/java
sudo apt-get update
sudo apt-get install oracle-java7-installer

Poslední věc, kterou musíme udělat, je nastavit JAVA_HOME v .bashrc. Nejdříve zjistíme, kde máme Javu, spustíme tedy příkaz

$which java

Dostaneme umístění Javy. V našem případě máme Javu v /usr/bin/java. Ny přejdeme do našeho domovského adresáře a otevřeme si .bashrc a vložíme následující řádky (pokud Vám příkaz which java ukázal jiné umístění, uložte do proměnné JAVA_HOME cestu, která platí pro Váš systém)

$vim .bashrc
JAVA_HOME=/usr/bin/java 
export JAVA_HOME 
PATH=$PATH:$JAVA_HOME 
export PATH

Nyní máme úspěšně staženou Javu a můžeme si stáhnout JDBC konektor. Konektor budeme používat pro připojení JBoss serveru k naší MySQL databázi, aby mohl pracovat s jejími záznamy. Přejděte na stránku http://search.maven.org/remotecontent?filepath=mysql/mysql-connector-java/5.1.8/mysql-connector-java-5.1.8.jar a uložíme si ho do adresáře /tmp.

Instalace JBoss serveru

Úspěšně jsme nainstalovali MySQL a rozběhli Javu, která je důležitá pro běh JBoss serveru. Přejděme tedy k tomu nejdůležitějšímu, a to je instalace JBoss serveru společně s CzechIdm. Ze stránky http://download.czechidm.com/doku.php si stáhneme nejnovější release a stažený balíček rozbalíme

$tar -xzf czechidm-jboss-2014q1.tar.gz

Nyní přejdeme do složky scripts, kde je uložen instalační skript. Tento skript zkontroluje, zda máme nainstalované všechny potřebné programy, a pokud ano, nainstaluje JBoss.

$cd czechidm-jboss-2014q1/scripts

Pomocí příkazu

$./install_jboss.sh

skript spustíme.

Při instalaci budeme vyzváni k zadání hesla pro uživatele root v MySQL. Pokud jste heslo nenastavovali, nechte pole prázdné a potvrďte, jinak zadejte heslo. Nemusíte se ničeho obávat, toto heslo se nikde neukládá, vyplňujeme me ho pouze proto, aby instalační skript mohl vytvořit databázi pro CzechIdM. Další věc, kterou musíme při instalaci udělat, je zadat absolutní cestu k našemu staženému konektoru. JDBC jsme si stáhli do složky /tmp zadáme tedy tuto cestu

$/tmp/mysql-connector-java-5.1.8.jarm

Pokud při instalaci nenastaly žádné problémy, budeme uvítáni následujícím textem:

================================================
WELCOME to JBoss & CzechIdM installation script!
================================================

Creating home directory for CzechIdM: /opt/czechidm... done.

Creating repository and its admin for CzechIdM...
  (MySQL root) Enter password: 
Done.

Installing JBoss AS to /opt/czechidm... done.

Adding MySQL connector to JBoss...
  Enter the location of the MySQL connector JAR file (or type SKIP to configure it manually):
/tmp/mysql-connector-java-5.1.8.jar 
Done.

Configuring JBoss as a service to /etc/init.d/jboss... done.

JBoss for CzechIdM installation completed.

You can start JBoss with the command 'service jboss start'.

JBoss máme nainstalovaný, takže spustíme server příkazem:

$service jboss start

Samotné spuštění chvilku trvá, většinou se připravte na 2 až 3 minuty čekání. Mezitím se tedy přesuneme do složky, kde je uložený log ze serveru, a budeme kontrolovat, zda-li se při startu neobjeví nějaká chyba. Přesuneme se  tedy do složky s logem a pomocí příkazu tail -f se podíváme na log.

$cd /opt/czechidm/jboss/server/default/log/
$tail -f server.log

Po úspěšném spuštění JBoss serveru budeme mít na posledním řádku zobrazeno

[org.hibernate.util.NamingHelper] (JbpmJobExecutor@127.0.0.1:Executor-1) JNDI InitialContext properties:{} 
Instalace CzechIdM

Nyní máme úspěšně nainstalované a spuštěné prostředí pro CzechIdM. Přejdeme tedy k jeho instalaci. Jako první krok se přesuneme do složky, kde máme uložený instalační skript

$cd /tmp/czechidm-jboss-2014q1/scripts

a spustíme instalaci CzechIdM

$./install_czechidm.sh

Pokud proběhne vše v pořádku, máme vyhráno. Úspěšně jsme nainstalovali CzechIdM a můžeme se s ním začít učit. Spustíme prohlížeč, zadáme adresu http://localhost:8080/idm a můžeme se začít seznamovat s CzechIdM.

Snímek obrazovky pořízený 2014-07-27 20:43:38

Odinstalace CzechIdM

Pokud se z nějakého důvodu rozhodneme odinstalovat CzechIdM z počítače, musíme nejprve vypnout JBoss server pomocí příkazu

$service jboss stop

Pak přejdeme do složky, kde máme CzechIdM

$cd /tmp/czechidm-jboss-2014q1/scripts

A spustíme odinstalaci

$./uninstall.sh

Tento skript nám odinstaluje CzechIdM z počítače.

Závěr

V tomto článku jsme si ukázali, jak nainstalovat prostředí pro spuštění CzechIdM a jak nainstalovat samotné CzechIdm do našeho počítače. Příště si ukážeme, jak vytvořit tabulku v MySQL, jak nastavíme konektor pro systém a propojíme CzechIdM s databází.

V případě jakýchkoliv dotazů, pište na michal.stejskal@bcvsolutions.eu .

Oracle – co dělat když se rozsype ASM

Na Oracle clusteru používáme ASM pro ukládání souborů databáze. Když všechno běží, je to paráda. Když se něco pokazí, je to paráda trochu menší, ale náprava naštěstí nebývá složitá. Jednoho dne se v našem ASM pokazila metadata a následkem toho ztratilo přehled o discích s daty. Co se vlastně stalo a co s tím dělat se dočtete dále.

Co to vlastně je ASM?

Diskgroups

U Oraclích databází máme dvě možnosti, kam ukládat data – buď klasicky na filesystém nebo na ASM. ASM stojí na principu tzv. groups. Grupa je zhruba analogická oddílu filesystému – může na ní ležet jedna nebo více databází, podle potřeby.

ASM potom podle nastavené redundance dat v grupě (external=žádná, normal=mirror, high=mirror s dvěma kopiemi dat) využívá datová úložiště a samo se stará o uložení a správu datových bloků, tzv. extents.

Aby to nebylo tak jednoduché, grupa je rozdělena na logické celky, kterým se říká failgroups. Pro ty platí vše, co jsme zatím zmínili o grupě. Pokud má grupa jen jeden disk, je tento disk vlastně samostatnou failgrupou.

Podle nastavené redundance je pak vyžadován určitý počet failgroup v grupě. Například pokud budeme mít normal redundancy grupu DBG a v ní failgrupu DBFG1 s jedním diskem. Po přidání dalšího disku do DBG se automaticky vytvoří DBFG2, pokud mu to ovšem explicitně nezakážeme. Tyto failgroup jsou vzájemně mirrorem. Pokud bychom přišli o celou DBFG1, databáze stále poběží, protože všechna data máme v kopii v DBFG2.

ASM instance

Ačkoli jde o datové úložiště, dokáže se ASM do určité míry chovat jako instance databáze. K této instanci pak jako klienti lokálně přistupují jednotlivé databáze.

K administraci ASM slouží utilita asmcmd, což je ekvivalent přizpůsobené a hodně osekané příkazové řádky. Protože se ale ASM dokáže chovat jako databázová instance, nic nám nebrání se k ní připojit přes sqlplus. Potom si můžeme v klasickém SQL stylu spouštět i dotazy na vlastnosti, stav a aktuální akce.

Co se vlastně stalo

„Příčina nehody: neznámá. Místo: neznámé. Čas: neznámý. Doufám, že tyto informace pomohou objasnit nehodu, ke které tu došlo.“ –Kryton, seriál Červený trpaslík

Citát to vystihuje naprosto přesně. ASM se jednoho dne prostě rozhodlo, že se mu DBFG1 nelíbí, vyhodilo z ní všechny disky a pak se ji pokusilo z DBG odebrat. Odebírání disků z grupy je běžná věc – jde o automatický mechanismus, kdy ASM při zjištění mrtvého disku (nelze z něj číst nebo na něj zapisovat) tento disk po určité době odstraní. Následně přesype data v grupě, aby vyžila s tím, co jí zůstalo, a zároveň co možná nejlépe splnila podmínky na redundanci dat. Odstraněným diskům se nastaví hromada příznaků, aby šlo poznat, co se s nimi dělo. ASM také každé odstranění zaloguje.

Stav po zjištění problému byl následující: u disků právě probíhalo odstraňování, ASM ale nepřesýpalo data, příznaky u disků byly podivně nastavené a v logách instance bylo prázdno. Podle operačního systému byly disky dostupné po celou dobu běhu serveru.

Vše tedy ukazovalo na neplechu v ASM. Takže aktuálně vyřešit nápravu a potom hledat příčinu, pokud ji vůbec máme šanci najít.

Chybový stav

Připojil jsem se do ASM jako „sqlplus / as sysasm“ a vypsal si grupy:

SQL> select mount_status, header_status, state, failgroup, os_mb, total_mb, path from v$asm_disk;

MOUNT_STATUS	HEADER_STATUS	STATE	FAILGROUP	OS_MB	TOTAL_MB	PATH
--------------------------------------------------------------------------------------------------------
MISSING		UNKNOWN		FORCING	DBFG1		0	26624
CLOSED		MEMBER		NORMAL			26624	0		/dev/mapper/dbfg1_disk
CACHED		MEMBER		NORMAL	DBFG2		26624	26624		/dev/mapper/dbfg2_disk

Můžete si všimnout, že disk z DBFG1 podle ASM nemá korektní hlavičku. Tady s ním moc neuděláme, podíváme se přímo do operačního systému.

kfed

Kfed je šikovná utilita, která člověku umožňuje hrabat se přímo v metadatech ASM disku. Navíc nepotřebuje, aby běželo cokoliv z Oracle stacku. Stačí mít disk namountovaný v operačním systému nebo mít fungující ASMlib (pokud je používán). Pomocí „kfed read“ si vypíšeme hlavičku disku (offsety úplně nesedí, protože DBG a DBFG jsou upravené názvy):

[root@node1 ~]# kfed read /dev/mapper/dbfg1_disk
...
kfbh.type:                            1 ; 0x002: KFBTYP_DISKHEAD
...
kfdhdb.grptyp:                        2 ; 0x026: KFDGTP_NORMAL
kfdhdb.hdrsts:                        3 ; 0x027: KFDHDR_MEMBER
kfdhdb.dskname:               	  DBG_0 ; 0x028: length=5
kfdhdb.grpname:                     DBG ; 0x048: length=3
kfdhdb.fgname:                	  DBFG1 ; 0x068: length=5
...

Stručný význam jednotlivých polí, konkrétní hodnoty si můžete vyčíst třeba zde:

type - typ hlavičky, zde nám říká, že jde o ASM diskovou hlavičku
grptyp - typ redundance grupy, kam disk patří
hdrsts - stav disku vůči grupě
dskname - jméno disku
grpname - jméno grupy
fgname - jméno failgrupy

Takže tímhle to nebude. Ještě pomocí „kfed find“ zkontrolujeme metadata disku:

[root@node1 ~]# kfed find /dev/mapper/dbfg1_disk
Block 0 has type 1
Block 1 has type 2
Block 2 has type 3
... (všechno další musí být "type 3")

Příkaz find projde bloky disku a vyzkouší, zda sedí metadata bloků. Odhalí tedy špatné checksumy, ale nikoli chyby v datech. Pokud budou v bloku poškozená data, ze kterých bude správně spočten checksum, nedozvíme se to.

Náprava

Poškozená fyzická data nás momentálně netrápí, protože databáze normálně běží a klienti v ní spouštějí dotazy. Disk z grupy vypadl před nějakou dobou, a tedy ho stejně musíme sesynchronizovat, aby obsahoval aktuální data. Protože disk nevypadá poškozený, prostě ho do grupy našťoucháme zpátky:

SQL> alter diskgroup DBG add failgroup DBFG1 disk '/dev/mapper/dbfg1_disk';

Na což Oracle zareaguje hlášením, že disk už součástí nějaké grupy je. Trochu příkaz upravíme (protože v tomto případě nic rozbít nemůžeme):

SQL> alter diskgroup DBG add failgroup DBFG1 disk '/dev/mapper/dbfg1_disk' force;

Což už projde. Inu, co nejde silou…
Teď jsme tedy přidali disk do grupy a proběhne přesýpání (tzv. rebalance). ASM má najednou více failgroup, takže si na ně rozhodí data kvůli redundanci. Proces chvilku trvá a lze ho uspíšit explicitním zvýšením priority. Konkrétní dotaz, který jsem použil při nápravě:

SQL> alter diskgroup DBG add failgroup DBFG1 disk '/dev/mapper/dbfg1_disk' force rebalance power 4;

Parametr „power“ může nabývat hodnot 0-11 (0-STOP,11-TURBO:) ), default je 1. Grupa se rebalancovala a od té doby běží vše tak, jak má.
U velkých databází může rebalance trvat dlouho, proto je dobré použít „power“ a trochu přesýpání pomoci. Aktuální činnost ASM lze získat výpisem:

SQL> select * from v$asm_operation;
GROUP_NUMBER	OPERA	STATE	POWER	ACTUAL	SOFAR	EST_WORK	EST_RATE	EST_MINUTES	ERROR_CODE
------------------------------------------------------------------------------------------------------------------
1		REBAL	RUN	4	2	475	2310		1360		0

Závěr

V článku jsem představil postup nápravy chybného stavu ASM za použití standardních utilit dodávaných s Oracle databází. Dále jsme si ukázali utilitku kfed, jakožto rychlého pomocníka pro orientaci v datech ASM disků. Podobný postup se uplatňuje, pokud disky skutečně oprávněně vypadnou z ASM grupy – v takovém případě není třeba nic „forcovat“. Pokud vás článek zaujal, nebo byste se chtěli zeptat na cokoliv ohledně ASM a Oracle DB, neváhejte mne kontaktovat na petr.fiser@bcvsolutions.eu.

VirtualBox na serveru – automatický start virtuálních strojů

Pokud provozujete VirtualBox na serveru, třeba způsobem zmíněným v našem jiném článku, musíte se o virtuální stroje alespoň trochu starat. Nevýhodou třeba je, že virtuály se automaticky nenastartují, pokud dojde k restartu hostitelského stroje. Pokud navíc na virtuály přistupují další lidé, kterým nechcete dát přístup do administrace VirtualBoxu, všechno najednou padá na vás. Vypadne proud, hostitelský stroj naběhne, ale stejně musíte jít a guesty ručně nastartovat. Dnes si ukážeme, jak tuto nepříjemnost vyřešit.

Pokračování textu

Prezentace Metasploit framework

V rámci interních školení u nás proběhla prezentace o Metasploit framework. Metasploit framework je nástroj, který nám dokáže poskytnout velké množství informací o bezpečnostních chybách v systému. Jak už z popisu vyplývá, je známý především mezi lidmi, kteří se pohybují okolo bezpečnosti – tedy vývojáři, analytiky, hackery, atd. Jaká témata jsme v prezentaci probrali se dozvíte z agendy níže.

Pokračování textu

Migrujeme Sun DS na 389 Directory server

Stojíte-li před podobným úkolem, najdete v tomto článku pár informací jak jsme my řešili migraci pro našeho zákazníka. Cílem bylo nahradit zastaralý adresářový server Sun Directory Server (dále jen Sun DS) verze 5.2 za novější software, který bude možné dále patchovat a udržovat. V našem případě se jednalo o nahrazení dvou multi-master serverů a několik kusů pobočkových replik za nový software.
Dobrou zprávou je, že Fedora Directory server a Sun DS mají stejný původní základ. Tento fakt migrace celkově usnadnil. Špatnou zprávou je změna replikačního protokolu mezi produkty Sun DS a 389 DS. Tedy replikaci nativní cestou mezi těmito sw produkty není možné bezpečně provozovat. Co se týče operačních systémů pod vlastní adresářové servery, tak se přechází ze Solaris 10 na Linux, konkrétně na Oracle Linux verze 6.2.

Pokračování textu

Spacewalk – centrální správa serverů

Spacewalk je OpenSource variantou k programu RH Satellite. Jeho úkolem je usnadnit administrátorům správu většího množství serverů, jejich operačních systémů RedHat nebo CentOS. Usnadnění spočívá zejména v zajištění lokálního repozitáře rpm balíčků a distribuci těchto balíčků na servery. Pod slovem distribuce je možné si představit jak manuální instalaci příkazem yum na koncovém serveru, také instalaci ze Spacewalk serveru „naklikanou“ administrátorem, ale i dávkové hromadné instalace balíčků na celé skupiny serverů.

Velkým úkolem ve větších prostředích je také zajištění shodnosti verzí balíčků na serverech.  Pokud instalujete server a následně provedete update z internetu, tak další instalace za 14 dní již může mít jiný update, protože byly vydány nové – „opravené“ verze. Výsledkem je, že verze balíčků na serverch nejsou shodné a pokud něco nebude na jednom ze serverů fungovat, je hledání problému daleko složitější. Díky Spacewalku je tedy možné garantovat i to, že budete mít jeden server s OS Linux jako druhý (stejný set balíčků) a to i v případě, že je budete instalovat s větším časovým odstupem.

Pokračování textu

VirtualBox na serveru

VirtualBox je jedna z hodně známých technologií pro virtualizaci. Je dostupný zdarma pro Linux, Windows a MacOS X. Hodně lidí ho provozuje na desktopu, na serveru jich je pravděpodobně o dost míň. Aby se snadnost použití VirtualBoxu z desktopu přenesla i na server vznikl projekt phpVirtualBox, který simuluje grafického desktopového klienta přes webové rozhraní.

Screen Shot 2012 02 23 at 13 26 17

Pokračování textu