Aplicatiile adaugarii unui atasament sunt suficient de multe, am sa mentionez una singura: crearea acelor footere “corporatiste” cu poze si alte minunatii.

Asadar sa presupunem ca vrem sa cream un astfel de footer, in HTML, cu o poza frumoasa care sa fie reprezentativa pentru mailurile trimise prin serverul pe care vrem sa facem configurarea.

Strict pentru partea de disclaimer/footer se poate folosi altermime fara nici o problema. Problema este ca daca dorim sa si adaugam o imagine (cea care va aparea in footer), lucrurile se complica.

Solutia este sa umblam in corpul mesajului si sa ne adaugam atasamentul asa cum vrem. Usor de spus, dar ce ne facem cand dam peste “Content-Type: multipart/mixed;
boundary=”_004_A8EC770875E1AE4A84851C05B6F730038D98AEFF4A_”"… ?

Ei bine, tocmai am facut cunostinta cu MIME. Nu voi intra in detalii inutile scopului articolului ci ma voi rezuma la esential. Ne intereseaza acel “boundary=”. Tot ce este intre ghilimele dupa semnul egal reprezinta un separator (unic pentru un mesaj) care desparte diversele atasamente/parti ale mesajului. Deci “_004_A8EC770875E1AE4A84851C05B6F730038D98AEFF4A_” este boundary-ul pe care trebuie sa-l cautam in cadrul mesajului pentru a ne putea introduce atasamentul.

O zona de continut MIME incepe cu doua semne “-” si este succedata de acel boundary, adica asa:

“–_004_A8EC770875E1AE4A84851C05B6F730038D98AEFF4A_” (desigur, exceptand ghilimelele). Zona tine pana in momentul intalnirii unui alt marcaj de acelasi fel, sau pana la intalnirea marcajului de final care este format din boundary succedat de doua semne “-”, adica asa: “_004_A8EC770875E1AE4A84851C05B6F730038D98AEFF4A_–”.

Cam asta e tot in privinta structurii unui email, cel putin asta e tot ce ne intereseaza pe noi.

Daca va intrebati totusi cum adaugam atasamentul, acum vine si raspunsul:

Atasamentul nostru se poate adauga exact inaintea marcajului final despre care am vorbit. Vom avea si exemplu la final. Ce trebuie stiut este ca un atasament intr-un email este codat base64. Asadar daca vrem sa introducem un fisier JPEG, va trebui intai sa-l convertim in base64 (uuencode -m, de exemplu) si abia apoi sa-l adaugam folosind o secventa de genul:

Content-Type: image/jpeg; name=”sign.jpg”
Content-Description: sign.jpg
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=”sign.jpg”
Content-ID: <sign.jpg@00000000>

Dupa cele de mai sus urmeaza base64 encodingul corespunzator fisierului sign.jpg

Toate acestea fiind realizate, avem un mesaj la care s-a adaugat si atasamentul iar el poate fi foarte frumos afisat din HTML-ul corespunzator footerului.

After you installed it you will need to download and install  the following 2 aditional rpm’s : nspr-4.6.7-1tfm.i686.rpm and nss-3.11.7-1tfm.i686.rpm .


cd /tmp
mkdir 1 ; cd 1
wget http://download.tfm.ro/TFM_3.2/aditional/nspr-4.6.7-1tfm.i686.rpm
wget http://download.tfm.ro/TFM_3.2/aditional/nss-3.11.7-1tfm.i686.rpm
rpm -Uvh *.rpm

Then download Adobe FMS and modified install from here:


cd /tmp
mkdir 2 ; cd 2
unzip Flashmedia3_Int_Strm_ALP.zip
tar xf FlashMediaServer3.tar.gz
cd FMS_3_0_1_r123
rm -f installFMS
wget http://download.tfm.ro/TFM_3.2/aditional/installFMS
chmod +x installFMS
./installFMS

The installation of adobe FMs is beyond this article scope so i will skip it. After you installed FMS if you need it to autostart on boot you have to edit /etc/rc.d/rc.multi and add to the end of file the following line


cd /opt/adobe/fms ;./server start ; ./adminserver start


That’s all folks. You have Adobe FMS running on TFM/GNU 32 Linux server.

From our tests one FMS can server on one live stream more than 1400 simultaneous users. If you like it or you find it usefull or even better use it , let us know. Feedback is important.

Solutia consta dintr-o serie de blocuri conectate inte ele. Astfel:

• Un block consta din :

1. Switch Gigabit (1U )
2. Enclosure AOE ( 15 HDD SATA 1TB each ) (3U)
3. Controler (1U)

• 1 Rack de 48U care va fi format din 5 blockuri + UPS

Costuri hardware:


6 * Switch Gbic 24 porturi (480$) = 2880$
5 * Enclosure AOE (4000$) = 20000$
5 * Controller (1000$) = 5000$
75 * Harddisk SATA 1 Tb (400$) = 30000$

TOTAL 57880$

Solutie Software:

Fiecare controller are in grija cite un enclosure AOE. Fiecare enclosure va avea hardurile in raid 5. Astfel pe fiecare enclosure se obtine o capacitate de 14 TB de date. Se poate organiza setul de blocuri in raid 0 (stripping) se obtine o capacitate totala de 70Tb . Insa orice failure de controller duce la compromiterea intregului sistem. ( Exista single point of failure). Fiecare controler isi exporta sistemul de fisiere folosind vlbade iar “controlerul de controlere” realizeaza raidul 5 la nivel de blocuri.

Pentru redundanta completa se organizeaza blocurile in Raid 5 capacitate (56 Tb)

Asta inseamna un cost de 1000$ / Tb redundant.

Nota1: Calculul a fost facut in martie 2007. Intre timp preturile hardiskurilor de 1Tb au scazut.

Nota2: Nu am inclus deloc costurile implementarii. Iar cum se face implementarea face diferenta intre o solutie de succes sau una proasta.

• Aflarea datei din urma cu 5 ani:

date –date=”5 years ago”

• alfarea datei din urma cu 5 ani dar in secunde

date –date=”5 years ago” +%s

• aflarea datei care va fi peste 5 ani , 6 luni si 7 zile in formatul clasic “YY-MM-DD”

date –date=”+5 years +6 months +7 days” +%y-%m-%d

Daca doriti sa lansati un proces peste o ora si 10 minute acest lucru se poate face simplu:

at -t $(date –date”+1 hours +10 minutes” +%Y%m%d%H%M.%S)

Comanda date este foarte flexibila . Urmatoarele exemple dovedesc asta:

date –date=”yesterday”

date –”tomorrow”

date –date “last thursday”

date –date “+4 weeks yesterday”

• Ramona Modroiu – Deschidere ROSDEV_2008

• Razvan Rughinis – Open Source in Mediul Academic. Partea 1

• Razvan Rughinis – Open Source in Mediul Academic. Partea 2

• Mihai Jalobeanu – Linux si Mediile Virtuale de Instruire

• Bogdan Radulescu – Distributia Linux Nimblex

• Liviu Andreicut – Sisteme monitorizare video / administrare centralizata servere

• Zoltan Orban – AbelCRM

• Zsolt Bodi – Code Igniter

• Virgi Adrian Teaca – DARKSTAR Part 1

• Virgi Adrian Teaca – DARKSTAR Part 2

• Daniel Constantin Mierla – Open Source si VoIP

• Cosmin Elefterescu – Platforma VoIP Open Source in Campusul Universitar

• Catalin Balan – OForge

• Craciun Attila – Bluewhite64

• Razvan Deaconescu – ROSEdu

• Marian Banica – Open Source for Higher Education

• Iulian Nicu Serbanoiu – Generator Minimal de Voce

• Angelescu Ovidiu – RoFreeSBIE

Sistem minimal 64 este gata . Booteaza , ajunge in prompt. In mare parte pachetele sint aceleasi din tfm-ul vechi cu o exceptie notabila: udev.

kernel 2.6.21.1 , glibc 2.5 , gcc 4.1.2 , perl 5.8.8 , udev 111

Acum urmeaza in primul rind sa adaug mc ( pentru ca merit ) si rpm-ul ca sa pot utiliza o parte din specurile din tfm3.1 ( modificind ce e necesar )

Pachete instalate ( extra base ):

• glib2
• mc
• beecrypt
• db
• expat
• openssl
• neon (are nevoie de downgrade )
• rpm ( fara patch-urile specifice tfm ) ( inca se compileaza )

Bon . Eroare . neon 0.26 nu e suportat direct de rpm 4.4.2 . Prin urmare am de ales: upgrade la rpm ( dar asta inseamna sa imi refac toata partea de autofetch ) sau downgrade la neon pina obtin un rpm functional.

Am sa incerc sa merg pe varianta 2. Probabil ca ma voi lovi de probleme la compilarea de apache si subversion ( am asa un feeling ) .

Continuam compilarea …. Stay tuned

• sqlite (il vrea rpm-ul )
• python ( ln -s python-2.4 pythonauto in usr/include)

Uitasem in /usr/local/lib o librarie veche de libbz2 . Mai mult bzip2 era compilat fara -fPIC ceea ce impiedica rpm-ul sa se compileze corect.

Dupa toate aceste lupte … Avem rpm functional ( fara pachurile de autofetch ). DAR .. se cheama ca sistemul este fuctional . Acuma urmeaza partea complicata . Trecerea incet incet a pachetelor TFM uzuale in noul tree si rezolvarea problemelor care apar.

Booteaza in vmware in 30 secunde.

Cam atit pentru dimineata asta.

06 – 06 – 2007

• sqlite depinde de: ncurses , readline , tcl (optional pentru docs)
• iar rpm-ul are niste faza apropo de x64 …. 3 patchuri pe ziua de azi … se cheama ca sint productiv. Problema cea mai mare a fost la flagurile de compilare.

Si apropo de flaguri de compilare . Petnru tfm64 flagurile default de compilare sint: “-mtune=k8 -m64 -O3 -pipe -fomit-frame-pointer -fPIC”

Benchmark 1:

compresarea unui ISO de 670065475 cu bzip2

La un bzip2 compilat cu -mtune=k8 -m64 -O2

root@tfm64: 2# time /bin/bzip2 6.2-RELEASE-i386-disc2.iso
real 4m27.183s
user 4m4.919s
sys 0m2.772s

Acelasi fisier compresat cu bzip2 ce a fost compilat cu: -mtune=k8 -m64 -O3 -pipe -fomit-frame-pointer -fPIC

root@tfm64: 2# time /usr/bin/bzip2 t1
real 4m23.154s
user 4m2.083s
sys 0m2.468s

Diferenta de 4 secunde doar din flagurile de compilare.

Ca termen de comparatie , desi e un pic fortat, tfm 3.1 pe un dual xeon acelasi benchmark a dat urmatoarele rezultate:

root@compile: /Tfm# time /usr/bin/bzip2 t1
real 9m51.190s
user 9m42.640s
sys 0m2.930s

Sistemul de instalare va trebui sa permita instalarea din retea . Ce inseamna asta: in retea se pune un server dhcp / bootp si serverul ce urmeaza a fi instalat va boota din retea. Sistemul de boot va trebui sa monteze nfs sistemul pe care exista rpm-urile de instalat dupa care instalarea va continua ca si cum ar instala de pe cdrom.

De ce e necesar ? In momentul in apare necesitatea de a instala multe servere repede in loc sa faci x cd-uri de instalare se pune un singur server si restul se instaleaza via network din el.

16-06:

Inca n-am terminat cu packetele de baza. O gramada de lucruri se schimba la trecerea 32/64 . Initial parea destul de simplu.

Au mai ramas: perl, udev-rules, kernel si de facut bootscripts-ul rpm. Cele mai grele. De ce ? Cu perl-ul am tot avut show-uri ( Ei da … nu-mi place perl-ul DELOC ). udev rules trebuie adaptat la noua versiune de udev. Kernelul. Aici e o parte complicata. Pentru ca trebuie gindit cum fac sa pastrez cit mai mult din structura de tfm32 … initrd …etc

Mai vedem. Intre timp am pus in heavy testing un mysql . Se comporta excelent so far. Zburda.