Archiv pro rubriku: Operační systém

Šifrovaný filesystém v Linuxu

Většina z nás se již někdy ocitla v situaci, kdybychom byli rádi, aby naše data byla opravdu jenom naše. Existují různé druhy ochran pro zabránění přístupu útočníka přes síť do našeho počítače, ovšem problém může nastat, když tento útočník získá fyzický přístup k našemu datovému médiu. Pak je již rychle schopen data odcizit a přečíst. Jak se však dá takovéto situaci zabránit? V tomto případě by nás mohlo zachránit šifrování našich dat.

Šifrování dat

Šifrování je proces, při kterém naše data změníme takovým způsobem, že budou pro jinou osobu (útočníka), bez znalosti informace jakým způsobem data vrátit zpět, naprosto k ničemu. Opačný proces se nazývá dešifrování. Konkrétních možností jak mít naše data v bezpečí je několik. Můžeme zašifrovat celý disk nebo diskový svazek. Také můžeme zašifrovat celý nebo část (soubory/složky) filesystému. Poslední možností je využít kryptografický filesystém. My si teď tyto způsoby rozebereme, vysvětlíme a ukážeme si jejich klady a zápory. Také si ukážeme práci s šifrovacím nástrojem cryptsetup.

Šifrování celého disku

Šifrování disku je, jak už název napovídá, metoda šifrování dat, při které zašifrujeme celý pevný disk nebo diskový svazek. Existují tři způsoby, kterými je možno disk zašifrovat. Buďto pomocí speciálního software nebo můžeme využít samošifrovacího disku.
V případě softwarového řešení nám v paměti počítače běží program, který interpretuje data mezi úložištěm a zbytkem počítače. Tento program dešifruje data z disku za pomocí klíče (většinou zpřístupněného pomocí hesla, které uživatel zadá jednou při startu PC nebo přístupu k úložišti). Naopak při zápisu data zase šifruje. Bez tohoto interpretování se data na disku tváří jako náhodná.
Samošifrovací disky využívají tzv. kryptoprocesor. Ten je napevno vystavěn do disku. Tento procesor podobně jako u softwarového šifrování interpretuje data, ale tentokrát je tato operace prováděna mezi fyzickým diskem a SATA rozhraním. Opět je nutné aby se uživatel autentizoval, což provádí před startem operačního systému.
Jak se tedy výše zmíněné možnosti liší? Šifrovací software je dostupnější, existují jak komerční tak open source programy. Za samošifrovací disk si sice připlatíme, na druhou stranu ovšem nabízí neporovnatelně lepší výkon, jelikož šifrovací a dešifrovací operace provádí kryptoprocesor, narozdíl od software, který musí využívat procesor počítače.

Šifrování na úrovni filesystému

Šifrování na úrovni filesystému nám umožňuje zabezpečit pouze část dat uložených na disku. Touto částí můžeme rozumět celý souborový systém, ale i několik složek nebo souborů. Na rozdíl od šifrování celého disku se nešifrují metadata, jako jsou informace o adresářové struktuře nebo jménech a počtu souborů ve složce, což může být nežádoucí. Tento problém řeší například filesystém ZFS, který metadata zvlášť šifruje na disk. Jedna z výhod šifrování na úrovni filesystému je taková, že můžeme různé soubory/složky šifrovat různými klíči. To je vhodné jak z hlediska bezpečnosti, tak toho můžeme využít jako autorizačního systému (různí uživatelé budou mít přístup k různým souborům). Dále je výhodné, že šifrujeme opravdu jen ta data, která chceme zašifrovat, nedochází tak ke zvýšené režii při přístupu k veřejným souborům jako v případě šifrování na úrovni disku, kde musíme dešifrovat každý soubor.

Kryptografický filesystém

Kryptografický filesystém je speciální typ filesystému, kde se již předem počítá s tím, že data v něm obsažena budou šifrována. Používá se ho většinou jako nástavba na běžný filesystém. Existují různé kryptografické filesystémy, které používají různé způsoby šifrování. Jako příklad si můžeme uvést EFS (Encrypted FileSystem) společnosti Microsoft.

Problémy

Při šifrování dat výše zmíněnými způsoby existuje několik problémů, které je nutné řešit. Prvním takovýmto problémem je bootování systému. V případě šifrování na úrovni filesystému nám tento problém pravděpodobně nevznikne, stačí nešifrovat soubory nutné k bootování. Šifrování celého disku však musí vytvořit nezabezpečenou partici, kam se vloží tyto soubory. Dalším problémem je správa klíčů. Při filesystémové úrovni šifrování má každý uživatel jeden nebo více klíčů, které jsou sdruženy v tzv. klíčence. Ta je zašifrována na disku pomocí master klíče. Ten je chráněn pomocí hesla, které je známé uživateli.

Cryptsetup

Nyní si ukážeme vytvoření šifrovaného svazku pomocí nástroje cryptsetup. Ten nám umožňuje využívat šifrovacího subsystému dm-crypt k vytváření, používání a správě šifrovaných svazků. Cryptsetup využívá dm-crypt spolu s jeho nástavbou LUKS, která přidává k funkcím dm-cryptu správu klíčů nebo třeba dvouúrovňové šifrování.

Při vytváření nového diskového svazku, je vhodné ho zaplnit náhodnými daty. Tak znemožníme nebo alespoň ztížíme identifikaci našich šifrovaných dat na daném svazku. Tohoto můžeme docílit použitím vhodného nástroje, jako je třeba dd. Použijeme generátor náhodných čísel /dev/urandom. Tato operace však může trvat delší dobu. Parametr bs (blocksize) nám operaci urychlí.

fallocate -l 512M /root/svazek
dd bs=1M count=512 if=/dev/urandom of=/root/svazek

Nyní se můžeme pustit do vytvoření šifrovaného oddílu. K šifrování našeho svazku zvolíme šifru AES v šifrovacím módu xts. AES (Rijndael) volíme proto, že patří k těm nejrychlejším ze současně standartně používaných šifer (Serpent, Twofish, RC6, MARS). Mod XTS je zase populární díky úrovni bezpečnosti a podpoře náhodného přístupu k datům. Velikost klíče bude 512 bitů a přepínačem -y si zajistíme kontrolu hesla, které budeme v tomto kroku zadávat.

cryptsetup -c aes-xts-plain -s 512 -y luksFormat /root/svazek

Teď když máme vytvořen nový šifrovaný svazek ho musíme zpřístupnit, vytvořit na něm vhodný souborový systém a připojit.

cryptsetup luksOpen /root/svazek encrypted
mkfs.ext4 /dev/mapper/encrypted
mkdir /mnt/encrypted
mount /dev/mapper/encrypted /mnt/encrypted

Nyní máme vlastní zašifrovaný svazek. Můžeme k němu přistupovat přimo přes /mnt/encrypted. Po ukončení práce se zařizením ho zase odpojíme a zrušíme mapování.

umount /dev/mapper/encrypted
cryptsetup luksClose encrypted

Pokud budeme chtít, aby náš zašifrovaný svazek byl automaticky připojený při bootu OS, musíme upravit soubory /etc/crypttab a /etc/fstab.

echo "encrypted /root/svazek none luks" >> /etc/crypttab
echo "/dev/mapper/encrypted /mnt/encrypted ext4    defaults 0  0" >> /etc/fstab

Nyní budeme při startu systému vyzváni k zadání hesla k zašifrovanému svazku.

Protože po připojení našeho zašifrovaného svazku jsou naše data ve swapu nešifrovaná, je vhodné jej šifrovat. Toho můžeme dosáhnout následujím způsobem (předpokládáme swap file na /dev/sda5).

swapoff /dev/sda5
cryptsetup -d /dev/urandom create cswap /dev/sda5
mkswap /dev/mapper/cswap
swapon /dev/mapper/cswap

Pro připojení swapu při bootu OS, musíme opět doplnit záznamy do souborů crypttab a fstab. To uděláme následovně.

echo "cswap /dev/sda5 /dev/urandom swap" >> /etc/crypttab

Jelikož ale již máme pravděpodobně nastavený swap v /etc/fstab, musíme záznam o něm vyměnit za:

/dev/mapper/cswap none            swap    sw              0       0

Závěr

V tomto příspěvku jsme si ukázali typy šifrování souborů v našem systému. Shrnuli jsme si jejich klady a zápory a nastínili jsme některé problémy, které nás mohou potkat. Nakonec jsme si předvedli, jakým způsobem můžeme pomocí nástroje cryptsetup vytvořit a používat šifrovaný svazek. V případě dotazů mě neváhejte kontaktovat na info@bcvsolutions.eu.

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 info@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 info@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.

Continue reading

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.

Continue reading

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.

Continue reading

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.

Continue reading