OpenFire, SSL si certificate intermediare CA

Dupa cite am observat in ultima vreme mai toate (sau toate?) Root CA Authorities nu mai emit direct certificate semnate de ele, ci toate folosesc un Intermediate CA ca sa semneze certificatul (din motive de securitate). Majoritatea serverelor au o optiune care sa-ti permita sa specifici acest Intermediate CA, de exemplu la Apache:


SSLCertificateFile /etc/pki/tls/certs/domeniu.crt
SSLCertificateKeyFile /etc/pki/tls/private/domeniu.key
SSLCertificateChainFile /etc/pki/tls/certs/RapidSSL_CA.pem

Din pacate Openfire nu are o astfel de optiune si aici solutia este sa introduci certificatul in 'truststore' o baza de date cu certificate 'trusted'. Solutia pentru Openfire este:

/opt/openfire/jre/bin/keytool -import -trustcacerts -keystore \ /opt/openfire/resources/security/truststore -file \
/etc/pki/tls/certs/RapidSSL_CA.pem -alias RapidSSL_CA

dupa acest pas se reporneste Openfire si se incarca certificatul. Daca nu am fi incarcat Intermediate CA-ul in truststore, ar fi dat eroare pasul in care incercam sa incarcam certificatul.

Parola implicita pentru truststore este 'changeit'.

Volume criptate in Linux

Postul asta are doua scopuri: sa-mi aduc aminte cum se foloseste cryptsetup in Linux si sa ramina "pentru posteritate".

In Linux sunt 2 solutii pentru criptarea datelor:

• cryptsetup simplu, unde criptezi cu dm-crypt o partitie, volum LVM sau un fisier. Spun ca e simplu pentru ca poti folosi o parola sau un fisier pentru securizarea datelor si cam atit. Nu ca asta le face mai putin sigure, dar e mai complicat cind pierzi parola sau fisierul.
• cryptsetup folosind LUKS (Linux Unified Key Setup) solutie care o voi descrie in contiuare. Cu LUKS exista posibilitatea de a folosi mai multe chei (sunt 8 sloturi) pentru criptarea datelor

Pentru inceput alegem device-ul ce va fi criptat, in acest exemlu /dev/sdb3

/dev/sdb3           19453       38913   156320482+  83  Linux

Alegem cifru AES-256, hash pentru parola SHA512 iar linia de comanda pentru crearea partitiei criptate va fi:

# cryptsetup -c aes -s 256 -h sha256 luksFormat /dev/sdb3

WARNING!

========

This will overwrite data on /dev/sdb3 irrevocably.

Are you sure? (Type uppercase yes): YES

Enter LUKS passphrase:

Verify passphrase:

Command successful.

Dupa aceasta operatie, avem o partitie criptata si atit. Pasul urmator e sa o "deschidem" ca sa o putem formata cu un sistem de fisiere ca sa putem folosi partitia ca pe orice alta partitie:

# cryptsetup luksOpen /dev/sdb3 sdb3

Enter LUKS passphrase for /dev/sdb3:

key slot 0 unlocked.

Command successful.

Dupa aceasta comanda, vom avea acces la partitia criptata prin /dev/mapper/sdb3 (am ales numele sa fie identic cu partitia ca sa fie mai simplu pentru mine). Pasul urmator e sa formatam partitia:

# mkfs.ext3 -i 65536 /dev/mapper/sdb3

mke2fs 1.39 (29-May-2006)

Filesystem label=

OS type: Linux

Block size=4096 (log=2)

Fragment size=4096 (log=2)

2443264 inodes, 39079863 blocks

1953993 blocks (5.00%) reserved for the super user

First data block=0

Maximum filesystem blocks=0

1193 block groups

32768 blocks per group, 32768 fragments per group

2048 inodes per group

Superblock backups stored on blocks:

        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,

        4096000, 7962624, 11239424, 20480000, 23887872

Writing inode tables: done

Creating journal (32768 blocks): done

Writing superblocks and filesystem accounting information: done

Acum putem monta partitia /dev/mapper/sdb3 unde dorim:

# mount /dev/mapper/sdb3 /mnt/

# df | grep sdb3

/dev/mapper/sdb3     156003840    192072 147995796   1% /mnt

Cind nu mai avem nevoie de partitia criptata, se va demonta si inchide device-ul (cryptsetup luksClose /dev/mapper/sdb3).

Voi reveni in alt post cu solutii de montare automata a partitiilor criptate.

WRT54GL Bridge mode

Am cautat pe google destul de mult cum poti sa pui un WRT54GL in bridge mode (adica sa nu ai routing activat, vrei ca clientii de pe wireless sa fie in aceeasi retea cu clientii de pe LAN) si jumatate din raspunsuri au fost 'nu se poate' cealalta jumatate erau 'pune DD-WRT pe el'. Cu ajutorul unui prieten m-am luminat (desi culmea el m-a intrebat cum se face pentru ca modificase ceva si nu ii mai mergea :) ).

Solutia e exterm de simpla: pui cablul in orice port de LAN in loc de portul de WAN, deoarece porturile de LAN sunt deja in bridge cu portul Wireless.
Ca sa nu ai probleme cu eventualele servere DHCP deja existente pe retea trebuie sa dezactivezi serverul DHCP din WRT54GL.
Administrarea ulterioara o faci prin IP-ul local al echipamentului.

20 de ani de Linux

Un interviu cu Linus Torvalds despre Linux: http://linuxfr.org/nodes/85904/comments/1230981

Sunet distorsionat in Flash 64bit pe Linux

Am fost ieri la un prieten care mi s-a plins ca pe majoritatea site-urilor cu flash audio-ul se auzea foarte prost. Ciudat youtube mergea bine, dar 220.ro de exemplu nu. Cautind pe google am ajuns la concluzia ca problema e in decoderul mp3 din flash pe 64bit si din acest motiv youtube merge ok (foloseste AAC). Sunt 2 bug-uri deschise la Fedora (https://bugzilla.redhat.com/show_bug.cgi?id=638477) respectiv Adobe (https://bugs.adobe.com/jira/browse/FP-5739) care bineinteles ca nici unul nu sunt rezolvate. Adobe da vina pe glibc iar glibc da vina pe Adobe (si au dreptate pentru ca Adobe nu respecta specificatiile memcpy).

Partea cea mai distractiva e ca problema a fost rezolvata de niste rusi care au scos un patch binar la ultimul plugin flash ( flash-ul impachetat rpm se poate lua de aici http://www.linux-ati-drivers.homecall.co.uk/flashplayer.x86_64/ ) care se poate lua de aici: http://www.linux.org.ru/forum/talks/5663681

Daca cineva mai are vre-o nelamurire cum se misca lucrurile in marile si renumitele companii cind e vorba de rezolvarea unui bug cred ca citirea comentariilor de la bug-uri ar trebui sa-l lamureasca :) .

Se poate vedea, ca bonus, si frecarea intre diferitele proiecte opensource care arunca pisica de la unul la altul, desi in cazul acesta problema chiar e in flash pentru ca nu respecta standardul.

Problema GRUB / Ext3

Încep cu începutul, un server (centos 5.5) care nu mai fusese oprit de
cam 1 an, nu vrea sa mai porneasca dupa reboot, stă la:

GRUB loading stage 1.5
GRUB loading, please wait...

L-am bootat cu rescue disk, incerc sa reinstall grub cu rescue disk de CentOS

root (hd0,0)
setup (hd0)

prima comanda merge, a 2-a crapa dupa cam 1 minut cu Segmentation fault, in minutul respectiv vad ca grub maninca vreo 2G ram + swap. Am zis wth? Fac fsck pe disk, e ok. Am bootat după ceva timp cu rescue de f14, am zis e mai nou, grub din f14 papa 4G ram dupa care hang (nu segmentation fault). Intr-un final am gasit ca la comanda din grub:

find /fisier

si aici cam orice cu / (existent sau inexistent) crapa. Ca sa descopar ca in / erau cam 2-300k+ fisiere (damn you webmaster!). Sters fisierele, merge grub acum. Problema ramasa e ca directorul / are
10MBytes, iar bootarea dureaza cam 1minut (GRUB loading, please wait...).

M-a luminat un prieten aici, are e2fsck o optiune, -D care face:

      -D     Optimize  directories  in filesystem.  This option causes e2fsck
             to try to optimize all directories, either by reindexing them if
             the  filesystem  supports directory indexing,  or by sorting and
             compressing directories for smaller directories, or for filesys‐
             tems using traditional linear directories.

care a mers, / are 4k acum si serverul booteaza instant