Conferința How to Web de sâmbătă [1] [2] a fost mai interesantă decât mă așteptăm. Subiectele au fost atractive și organizarea foarte bună pentru o primă ediție a unui eveniment destul de mare.

Prezentările nu au fost aproape deloc tehnice (lucru nu neapărat bun) dar au fost bine adaptate la ideea conferinței, cea de a aduce împreună pasionații web-ului cu profesioniștii lui.

Printre prezentările interesante s-au numărat una despre “User Experience Design”, în care s-a arătat importanța proiectării inteligente a unei interfețe cu utilizatorul (lecția învățată a fost că o interfață trebuie să fie: usable, useful, valuable, desirable, findable, credible, accessible).

Altă prezentare a fost despre “Cloud Computing”, o noțiune destul de nouă și căutată. În prezentare s-a vorbit despre părțile bune și parțile rele ale Cloud Computing.

O prezentare care nu are neapărat legătură cu web-ul ci cu business-ul a fost “Despre Antreprenoriat”. Un cuvânt ce s-a tot rostit pe parcursul conferinței a fost ’start-up’, ce se referă la o companie (firmă) ce abia a pornit și este în drum spre succes. Prezentarea respectivă ne vorbea despre cum ar trebui abordată pornirea unei afaceri proprii.

Așteptăm ca pozele de la eveniment, precum și slide-urile, să fie postate pe site-ul oficial.

Felicitări pentru organizatori, ASPI [3] pentru o treabă bună făcută și așteptăm ediția de anul viitor.

Follow-up-ul oficial îl găsiți pe siteul How to Web [4]. Un altul, destul de lung, pe mai multe părți, aici [5], [6], [7], [8].

[1] http://www.how-to-web.net/

[2] http://alexj.info/2009/10/22/conferin%C8%9Ba-how-to-web/

[3] http://www.aspi.ro/

[4] http://www.how-to-web.net/2009/11/si-a-fost-how-to-web-2009/

[5] http://pow4ioc.wordpress.com/2009/10/31/how-to-web-part-i/

[Part I]
[Part II]

Clientul este un Linux box. Legătura la Internet este prin eth1, interfață peste care se face tunelul 6to4.

După ce am creat tunelul, am aflat că pot cere o clasă de IPv6 să fie routată prin IP-ul meu v6. Astfel, mi-a fost alocată rețeaua 2001:470:9f00::/48 ( 1208925819614629174706178 adrese adică adică aproximativ 1 milion de miliarde de miliarde de adese), pe care am început să o subnetez.

Prima rețea am alocat-o rețelei de pe eth1 (uplink-ul la Internet, precum și legătura cu alte servere locale). Pentru ușurință în denumire, am ales rețeaua 2001:0470:9f00:0141:0085:0037:0208::/112, adresă obținută prin o concatenare (la nivel de notație) a adresei IPv6 /48 alocate cu adresa IPv4/24 (141.85.37.208). Atenție, valorite în binar sunt total diferite, pentru că adresa IPv6 conține cifre în hexadecimal și IPv4 în decimal.

Configurație prin /etc/network/intefaces:

iface eth1 inet6 static
address 2001:0470:9f00:0141:0085:0037:208:1
netmask 112

Routarea IPv6 nu este implicit activată, și pachetele nu vor trece dintr-o rețea în cealaltă. Pentru aceasta, trebuie modificat fișierul /etc/sysctl.conf și decomentată (sau adăugată) linia:
net.ipv6.conf.all.forwarding=1
urmată de un restart a sysctl
sysctl -p

În continuare am alocat o altă rețea /112 pentru tunelul VPN peste care am o rețea IPv4 172.30.0.0/24 în spatele unui NAT. Partea frumoasă aici este că la IPv6 nu mai este nevoie de NAT pentru că sunt adrese routabile IPv6, deci traficul IPv4 va fi translatat la router în spatele unei singure adrese iar cel IPv6 va fi routat normal spre Internet. Rezultatul final a fost conectivitate IPv6 pe două sisteme care se află în cu totul altă rețea decât cea unde există tuneul 6to4, rețea ce se află in spatele unui NAT. Pentru a ajunge la un server IPv6 extern, aceste stații trebuiat să treacă peste printr-un tunel 6to4 aflat peste o conexiune VPN(OpenVPN) până la server unde era routat în altă rețea IPv6 care trecea peste un alt tunel 6to4 și routat mai departe doar prin IPv6.

[Part I]

De la provider-ul tunelului [1] am primit următoarele:

Server IPv4 address:      216.66.80.30
Server IPv6 address:     2001:470:1f0a:68d::1/64
Client IPv4 address:     141.85.37.208
Client IPv6 address:     2001:470:1f0a:68d::2/64

Între cele două adrese IPv4 este creat un tunel ce are alocată rețeaua IPv6 2001:470:1f0a:68d::/64 ( deci aproximativ 18 milidarde de miliarde de adrese pierdute pentru 2 adrese…dar nu e problemă pentru că sunt destule ).
Configurarea tunelului poate fi făcută în mai multe feluri.

Temporară prin ifconfig/route

ifconfig sit0 up
ifconfig sit0 inet6 tunnel ::216.66.80.30
ifconfig sit1 up
ifconfig sit1 inet6 add 2001:470:1f0a:68d::2/64
route -A inet6 add ::/0 dev sit1

Temporară prin iproute2

modprobe ipv6
ip tunnel add he-ipv6 mode sit remote 216.66.80.30 local 141.85.37.208 ttl 255
ip link set he-ipv6 up
ip addr add 2001:470:1f0a:68d::2/64 dev he-ipv6
ip route add ::/0 dev he-ipv6
ip -f inet6 addr

Permanentă (on boot) prin /etc/network/interfaces
iface he-ipv6 inet6 v4tunnel
endpoint 216.66.80.30
address  2001:470:1f0a:68d::2
netmask  64
mtu 1480
up ip -6 route add 2000::/3 dev he-ipv6
down ip -6 route del 2000::/3 dev he-ipv6

[1] http://www.tunnelbroker.net/

Deși mai configurasem o adresăIPv6 și cu alte ocazii [1], nu intrasem adânc în subiect decât la clasa de BSCI de la Cisco pe care am terminat-o recent. După clasă, pentru că mi-a plăcut subiectul, am încercat să văd IPv6 în viața reală, ceea ce era puțin problematic pentru că legăturile mele la Internet vin numai în varianta IPv4.

Dar am descoperit un site interesant, TunnelBroker [2], care oferă tunele IPv6 peste conexiuni IPv4, gratuit. Provider-ul respectiv are o rețea globală de servere accesibile prin IPv4, dar care routează IPv6 în Internet. Tot ce e nevoie este un server propriu sau un workstation care să aibă un IP public (acesta va fi clientul). Configurația tunelului se face într-o parte automat, pe site și cealaltă parte pe stația locală manual. Instrucțiunile complete se găsesc pe site.

Aceeași firmă ce administrează site-ul TunnelBroker și rețeaua de servere, Hurricane Electric, oferă și o certificare [3] de atestare a cunoștințelor despre IPv6. De exemplu, primul test constă într-un quiz despre IPv6 iar al doilea presupune configurarea unui client care să fie capabil să acceseze o pagină IPv6.

Fun fact: Există un ‘experiment’ pentru a promova IPv6 [4], dar care, momentan, pare a fi mort.

[1] http://alexj.info/?p=92

[2] http://www.tunnelbroker.net/

[3] http://ipv6.he.net/certification/cert-main.php

[4] http://ubergeek.ro/2008/08/22/ipv6-experiment/

Am primit azi un email de la Juniper în care am fost acceptat la Juniper Summer School [1]. Ce a fost interesant e că mi-au trimis și un fișier în care era salvat calendarul programului. Era un fișier .ics, care am aflat că este format iCalendar (by Apple). Cum nu foloseam iCalendar, mi s-a părut inutil, dar în email era menționat faptul că pot folosi fișierul inclusiv în Google Calendar.

Astfel am aflat de funcția de import de la Google Calendar [2] . Sunt compatibile mai multe fișiere, printre care și acesta.

Pentru a importa un calendar, se intră pe Google Calendar. Sub lista de calendare există butonul de Settings, iar pe pagina de setări pentru fiecare calendar, există un link de Import Calendar. Pe pagina de Import se încarcă fișierul și se poate alege ca datele din fișier să fie integrate într-un calendar existent sau să se creeze un calendar nou.

Ce am dorit să fac: un program în Java ce capturează conversații de pe IRC și le stochează într-o bază de date mySQL; din acea bază de date se ia prin PHP și se afișează pe o pagină HTML. Deși pare destul de mult de făcut, necesită puțin cod, dar multă atenție la interconectarea elementlor: programul Java, conectorul dintre Java-mySQL (JDBC), baza de date mySQL și script-ul PHP.

Am creat ‘topologoia’ necesară și programul mergea ok. Dar am descoperit rapid o problemă: pagina web (HTML+PHP) nu afișa diacritice. Și am început să caut prin fiecare element să văd unde era problema ( oricare din componente putea să ducă la problema aceasta).

Am început prin modificarea paginii PHP/HTML și forțarea ca browserul să citeacă caracterele în format UTF-8. Codul nu depinde de PHP (am presupus că el transmite corect din baza de date în HTML) ci de headerul HTML.

<head>  <meta http-equiv=”Content-Type” content=”text/html; charset=utf-8″ />   [...]  </head>

Al doilea test a fost făcut pe mySQL. Implicit, baza de date codează folosind Latin.  Și tabela unde se făcea scrierea trebuia trecută pe UTF.

CREATE TABLE `chats` ( [..] ) DEFAULT CHARSET=utf8;

Cum programul Java imprima corect la stdout diacriticile, problema trebuia să fie la JDBC. Suportul pentru UTF a fost adăugat în JDBC, dar trebuia specificat la conectarea cu baza de date. Acest lucru se face pasând un parametru la  URL-ul bazei de date.

jdbc:mysql://my_server/my_data_base?unicode=true&characterEncoding=utf-8

Având nevoie de o mașină Windows Server și având la dispoziție doar un server Linux la dispoziție am decis să instalez o soluție de virtualizare. Alegerea inițială a fost VMware server 2 [1], pe motivul că interfața web oferă un control foarte bun de la distanță. De asemenea conectarea la rețea se face foarte ușor.

Problema că serverul respectiv avea resurse modeste și VMware ar fi consumat mare parte din ele. A fost un bun moment de a testa VirtualBox ca o soluție de server.  La nivel de utilizare pe o mașină fizică locală, VirtualBox rulează destul de bine, consumând puține resurse.

VirtualBox vine în două versiuni, VirtualBox OSE, distribuită sub licență GPL și VritualBox distribuită sub licență PUEL (closed source dar gratuită pentru uz personal și educațional). Una din diferențe este că cea PUEL vine cu VRDP (VirtualBox Remote Desktop Protocol), ce oferă posibilitatea controlării mașinii de la distanță, lucru important pentru situația în care serverul era un Linux box în text mode și altă interfața (web) nu exista pentru control.

Instalarea VirtualBox s-a făcut ușor (apt-get spre deosebire de VMware care nu este oferit pe repositories) dar configurarea a fost mai grea. Neavând o interfață web, lucrurile trebuie făcute prin linia de comandă. Comnezile cheie sunt VBoxManage și VBoxHeadless. Iată un exemplu de creere mașină cu harddisk și pornirea mașinii:

VBoxManage createvm -name “win2003server” -register
VBoxManage modifyvm “win2003server” -memory “256MB” -acpi on -boot1 dvd -nic1 nat
VBoxManage createvdi -filename “win2003server.vdi” -size 10000 -register
VBoxManage modifyvm “win2003server” -hda “win2003server.vdi”

VBoxHeadless -startvm “win2003server”

Implicit, VRDP rulează pe portul 3389 și poate fi accesat printr-un client RDP (inclusiv Windows Remote Desktop), dar, aparent, acestă bucată are anumite probleme și nu a funcționat.

Altă soluție este instalarea unui server VNC pe mașina virtuală. Pentru acesta trebuia instalat sistemul de operare client pe un alt calculator cu VirtualBox (cu interfață grafică) și mașina migrată pe server. Punctul cel mai slab al VB este migrarea. Dacă în VMware, tot ce trebuia făcut era mutarea fișierelor, în cazut VirtualBox, mutarea fișierelor nu duce neapărat la păstrarea integrității măsinii. Din cauza fișierelor de configurare care depind de mașină (căi absolute și verificări a informațiilor măsinii fizice) nu pot fi mutate mașinile atât de ușor. După înțelegerea și editarea fișierelor XML se poate ajunge la o mașină migrată cu succes (o altă opțiune este mutarea harddisk-ului și crearea unei mașini de la zero ce folosește acel harddisk).  Și după rularea mașinii, a doua mare problemă VirtualBox este configurarea dispozitivelor de rețea care se face foarte greu.

Concluzia este că VirtualBox este departe de nivelul VMware, deși este un produs destul de promițător. Chiar dacă Sun a făcut produsul Open Source în mare parte, comunitatea încă nu a oferit unelete care să ajute soluția de virtualizare (un posibil proiect de a introduce o interfață web pentru VB, similară cu VMware Server 2, este abia la început).

[1] http://alexj.info/?p=832

Mi-am adus aminte de un mic truc pe care îl foloseam în liceu şi dintr-un motiv necunoscut nu l-am mai folosit de mult, până la un laborator de Sisteme de Operare: schimbarea mai eficientă a unei variabile.

Metoda clasică este folosirea unei variabile auxilitare în care se păstrează una din variabile. A două metodă este folosirea XOR (sau exclusiv).

var1 = var1 XOR var2
var2  =var1 XOR var2
var1 = var1 XOR var2

Partea cea mai bună este că nu este dependentă de tipul de date şi teoretic s-ar putea schimba orice. Astfel, se poate crea uşor şi un macro pentru uz general. Folosind ultimul best practice învăţat despre macro-uri ( encapsularea codului funcţiei într-un do while(0) ), codul în C ar arăta aşa:

#define swap(a, b)       \
do                                   \
{                                      \
(a) = (a) ^ (b);               \
(b) = (b) ^ (a);              \
(a) = (a) ^ (b);              \
}while(0)                     \

Probabil cel mai interesant lucru cu care am lucrat la cursul de Securitate [1] a fost Scapy. Auzisem de el, ştiam ce este şi ce face dar mi-a plăcut să îl văd prezentat de către cel ce l-a creat şi să fac un laborator cu el.

Scapy [2] este mai mult un framework scris în Python pentru manipularea traficului de reţea. Rulează peste interpretorul Python şi oferă o serie de classe/obiecte ce reprezintă protocoale de reţea. Nu are o interfaţa grafică şi nu este foarte user-friendly (decât pentru cei ce sunt obişnuiţi cu Pyton), dar este un utilitar foarte puternic pentru testarea reţelelor. Permite în primul rând capturarea pachetelor şi analizarea lor în detaliu, strat cu strat. Dar mai important oferă posibilitatea de a crea pachete şi de a le trimite pe mediu.

Ultima versiune de Scapy este disponibilă la [2] http://scapy.net (download direct de la adresă).

Tip:  puteţi să daţi “chmod +x scapy-latest.zip” şi să rulaţi Scapy cu “./scapy-latest.zip”.

Pentru o captură simplă de pachete putem folosi comanda sniff. Un exemplu:

my_cap = sniff(prn=lambda p:p.summary(), timeout=60)

În variabila my_cap va fi stocat traficul sub forma unei liste. Funcţia lamba specifică ce din trafic să salveze în listă iar timeout specifică câte secunde să captureze. Rezultatul din variabilă poate fi refolosit pentru orice analiză.

Folosind nişte biblioteci de imagine din Python putem crea o imagine vizuală a traficului. Pentru a face un graf ce conţine legăturile dintre staţii putem folosi “my_cap.conversations()” iar rezultatul este ceva de genul următor:

Pentru a genera şi trimite un pachet de date, creăm instanţe de obiecte, encapsulăm datele şi le trimitem. Exemplu (parametrii sunt flexibili) :

>>> my_packet = IP(dst=”192.168.208.1″)

>>> my_packet.ttl = 12

>>> my_segment = TCP(dport= 2346)

>>> send(my_packet/my_segment/”test”)

“/” este operatorul de encapsulare. Payload-ul (un string, “test”) este encapsulat cu un header TCP (my_segment) care este la rândul lui encapsulat într-un pachet IP.

Rezultatul pe destinaţie

Scapy este Open Source (sau în franceză, pentru că este este scris de un francez, Logiciel libre).

[1] http://alexj.info/?p=716

[2] http://www.secdev.org/projects/scapy/

[3] http://scapy.net

Una din direcţiile majore de dezvoltare a Cisco este Voice over IP. Cisco oferă un număr mare de echipamente, software şi soluţii pentru VoIP.

Soluţiile VoIP se conectrează în jurul a Cisco Call Manager care este un Call Agent. Este un software ce face administrarea reţelei de VoIP. Acest software vine în două variante: Cisco Call Manager (sau după noua denumire dată de Cisco Unified Communications Manager… este acelaşi lucru) ce este un software ce rulează pe un server x386 peste MS Windows sau Call Manager Express (CME sau Cisco Unified Communications Manager Express) ce este un pachet ce rulează pe un router Cisco peste IOS. Ambele oferă aceleaşi facilităţi de bază. Imaginile de IOS ce vin cu CME au, de obicei, ‘voice’ în nume.

CME este compatibil cu o suită întreagă de protocoale VoIP printre care SIP, H323 şi SCCP. SSCP ( sau Skinny) este protocolul proprietar Cisco şi este suportat de majoritatea echipamentelor Cisco de Voce.

Clienţii pentru Call Manager sunt de obicei Telefoane IP ( ex 7960, 7906G )sau Cisco IP Communicator care este un program pentru Windows ce simulează un telefon (mai este cunoscut şi ca Softphone).

Call Manager Express oferă un wizard pentru configurarea telfoniei IP prin comanda “telephony-service setup”.

Iată o configurare simplă ( liniile notate cu * sunt explicaţii)

Router>enable

Router#configure terminal

Router(config)#interface f0/0

Router(config-if)#ip address 10.0.0.254 255.0.0.0

Router(config-if)#no shutdown

Router(config-if)#exit

Router(config)#telephony-service setup

Do you want to setup DHCP service for your IP Phones? [yes/no]: yes

*Activează un pool DHCP pentru telefoane

IP network for telephony-service DHCP Pool:10.0.0.0

Subnet mask for DHCP network :255.0.0.0

TFTP Server IP address (Option 150) : 150

* Prin Opţiunea 150 de la DHCP (netransmisă implicit), telefonul IP va ştii adresa serveului TFTP

TFTP Server IP address (Option 150) :10.0.0.254

Default Router for DHCP Pool :10.0.0.254

Do you want to start telephony-service setup? [yes/no]: yes

Enter the IP source address for Cisco IOS Telephony Services :10.0.0.254

Enter the Skinny Port for Cisco IOS Telephony Services : [2000]:

How many IP phones do you want to configure : [0]: 2

*Numărul de telefoane ce se vor conecta la CME

Do you want dual-line extensions assigned to phones? [yes/no]: yes

What Language do you want on IP phones : 0

Which Call Progress tone set do you want on IP phones : 0

What is the first extension number you want to configure : 100

*Numărul de telefon primit pe prima linie a primului telefon ce se înregistrează la CME

Do you have Direct-Inward-Dial service for all your phones? [yes/no]: no

Do you want to forward calls to a voice message service? [yes/no]: no

Do you wish to change any of the above information? [yes/no]: no

Acest setup va crea in running-config setările necesare pentru VoIP.

Se observă că adresa 10.0.0.254 a fost completată de 3 ori (ca Default Gateway, TFTP server şi IOS Telephony Services). Nu este obigatoriu ca aceste adrese să coincidă, pentru că nu este obligatoriu ca routerul respectiv să indeplinească toate rourile acestea. Default Gateway este routerul setat pe telefonul IP pentru a ieşi din reţeaua locală (serverul SCCP sau TFTP poate să fie în alt broadcast domain). Serverul TFTP oferă telefonului setările sale sub forma unui fişier XML (în acest fişier se va afla adresa/protul serverului SCCP). IOS Telephony Services este serverul cu CME ce are pornit serverul SCCP şi care va procesa semnalele de telefonie.

[1] http://alex.clubcisco.ro?p=104