function urandompass()
{
	cat /dev/urandom | tr -dc '[\41-\176\241-\254\256-\376]' | fold -w $1 | head -n 1
}

Apelul este cretin de simplu: urandompass 12 va genera o parolă de 12 caractere. Sau cheie, am zis-o și pe asta. Funcția poate fi folosită pentru a genera chei pentru un “block cipher”.

Cu toate acestea, pentru cei cu terminalul setat pe UTF-8, caracterele dincolo de range-ul celui de-al 7-lea bit (aka cele ce intră în extended ASCII) nu vor fi printate corect. Teoria spune faptul că UTF-8 este compatibil doar cu setul ASCII, ăla standard. În prealabil este nevoie să se seteze terminalul pe un char encoding single-byte ce implementează vreo formă de extended ASCII gen ISO-8859-x, unde x = 1 este Western, x = 2 = Central European, etc. Personal prefer Western. Pentru cei cu Gnome Terminal, “Terminal » Set Character Encoding » Add or Remove …” dacă e pentru prima dată, dacă nu, atunci ar trebui să poată fi ales din meniu un encoding diferit de cel implicit. Buba este faptul că Gnome Terminal are memorie destul de proastă deci va da reset la UTF-8 dacă terminalul este închis sau se execută reset, deci operația trebuie repetată înainte de a genera orice parolă / cheie.

Acum urmează partea pentru obsedații de detalii aka cei după chipul și asemănarea subsemnatului. “Limitarea” la extended ASCII, ce oricum oferă o complexitate mai bună decât majoritatea generatoarelor, provine de fapt din tr. Un info coreutils ‘tr invocation’ în shell specifică destul de clar: “Currently `tr’ fully supports only single-byte characters.”, deci suportă multi-byte din jumătatea lui cinci. Pentru amatorii de detalii, acele range-uri din funcția mea au fost documentate, oarecum, în prealabil.

În DEC:

33-126
161-172
174-254

În OCT:

41-176
241-254
256-376

Evident, cu ochiul liber se poate vedea că tr primește octal, precum zice manualul. Pentru a le determina am încercat cu encoding ISO-8859-1 și ISO-8859-2 o aplicație ce printează tot range-ul single-byte (mă rog, fără ultimul caracter).

Pentru PHP-iști:

for ($i = 0; $i < 256; $i++)
{
	echo $i.': '.chr($i)."\n";
}

Iar pentru snobii cu C, avem alternativă :

#include 
 
int main()
{
        for (int i = 0; i < 256; i++)
        {
                printf("%d: %c\n", i, i);
        }
        return 0;
}

gcc -std=c99 -o chars chars.c

Inițial m-am inspirtat dintr-o versiune *sh de pe linuxquestions.org, dar arată cretin, nu dau paste la așa ceva. Mă cam strânge octalul de dinți. O versiune rescrisă pentru DEC junkies:

#!/bin/bash
 
chr()
{
	printf \\$(printf '%03o' $1)
}
 
i=0
while [ $i -lt 256 ]; do
	echo "$i: `chr $i`"
	let "i++"
done

Pentru cei ce preferă alte encoding-uri single-byte, dacă range-urile de mai sus nu sunt potrivite, atunci se poate rula oricând vreo aplicație de mai sus pentru a face un test de char printing.

Pentru cei ce nu s-au născut cu "DEC to OCT converter" în cap, așa ca subsemnatul, Calculator din Gnome (gcalctool) are și un mod Programming (Ctrl+P).

Acum poate cei ce mă cunosc suficient de bine ar remarca faptul că eu nu mă mai uit la televizor de ani de zile, iar acest interes pentru sop nu este unul menit să rupă acest șir magic. Singura excepție sunt cursele de Formula 1. Aș prefera transmisiunea BBC, dar în lipsa lor, merge și TVR 1, cu toate că Miki și gașca mă chinuie de opt ani și ceva cu comentariul imbecil. Din moment ce obligat – forțat trebuie să le plătesc abonament ăstora de la Televizunea Națională, măcar de atâta să mă bucur.

Ceea ce incompetenții de mai sus cu site-urile lor au transformat în “Rocket Science” prin soluții tehnice legate de o platformă, transform eu acum într-o chestie cretin de simplă, dar pentru care a trebuit să dau din taste vreo 30 minute până să găsesc această rezolvare. Adresa stream-ului TVR 1 este:

sop://broker.sopcast.com:3912/60707

Aceasta se ia frumos și se pune în SopCast player. Chestie ce prezintă și versiune de Linux. Sub Ubuntu este chiar simplu de instalat din moment ce prezintă repository PPA, ceea ce reduce problema la:

sudo apt-add-repository ppa:jason-scheunemann/ppa

Se instalează pachetul sopcast-player și voila, gata de F1.

Din câte am observat, cară după el și ceva dependințe VLC (plus VLC cu totul). TVR 1 nu este de găsit în “Channel Guide”, dar cu adresa de mai sus este posibilă vizionarea stream-ului TVR 1. Dacă se înregistrează protocolul sop în browser, link-ul de mai sus poate fi deschis direct cu sopcast-player din moment ce aplicația primește link de stream ca argument. Are funcție de bookmark pentru cei ce preferă să nu facă muncă repetitivă, recte subsemnatul.

PS: în general, durează câteva secunde până stream-ul devine “văzubil”, până se curăță artefactele.

Deci ce este acest G-WAN? Pe scurt, în cele aproximativ 120 kile de binar se găsește un web server brutal de rapid și un început de application server, practic suport pentru servlet-uri scrise în ANSI C, compilate dinamic, după metoda edit & play folosită de PHP-iști. Și evident, caching, acea sperietoare de “web developers”, altfel nu ar fi fost chiar atât de rapide.

Am urmărit îndeaproape proiectul de pe la v1.0.3 deoarece mi s-a părut interesantă prezentarea, dar fără aplicabilitate momentană “in real life”. Între timp aplicatia a mai crescut în valoare, iar platforma s-a modificat din Windows (la acea dată) în Linux. Autorul se săturase de limitările din kernelul Windows, limitări ce se găsesc și în kernelul Linux, dar sunt mai sus.

Nu vorbesc din citatele autorului G-WAN despre aceste limitări. Le-am testat pe propria piele. Fie că am executat fractalul lui Mandelbrot (servletul fractal.c disponibil în arhiva de distribuție), fie că am executat problema despre care vorbeam aici, atât implementarea brută cât și cea eficientă, pe un quad-core (C2Q Q9400) și Apache Bench pe localhost am stat în jurul valorii de 69000 req/s. Da, vorbesc de o aplicație, unde fractalul este cu ordin de complexitate mare comparat cu problema numerelor. Dar cu toate acestea, throughput-ul servlet-urilor a fost apropiat ca valoare. Deci există o limitare, dincolo de eficiența algoritmului și a puterii de procesare necesare.

Printre altele, nu a fost nici o limitare de lățime de bandă. Rulând teste de conținut static, am obținut aproximativ 1.2 GiB/s la o concurență suficient de mare, înainte ca ab să înceapă să dea timeout-uri și erori de conectare. Da, 1.2 GiB/s prin interfața de loopback. Aici se adaugă doar efortul de encapsulare, decapsulare și fragmentare a pachetelor din moment ce MTU este mare comparat cu o “rețea normală”, dar totuși cu o valoare implicită de 16436 pe care nu am încercat să o mânăresc și nici nu știu să fi mânărit vreodată prin setările de la lo. Testele dinamice nu se apropiau de această lățime de bandă, de altfel, conținutul static la 1.2 GiB/s abia urca pe la 20000 req/s, deci o limitare de bandă era mult mai evidentă în cazul acestui tip de conținut, față de un servlet.

Singura problemă ce am observat-o a fost una de scalabilitate pe mai mult de două nuclee de procesor. G-WAN lansează un număr de thread-uri egal cu numărul de nuclee, dar din cele 4 pe care le-a lansat, doar primul și ultimul încărcau procesorul în timp ce 2 și 3 frecau menta în idle. Cel puțin așa raportează htop pus în modul threaded la listarea proceselor din sistem.

De altfel, la capitolul conținut static nu am observat o viteză mărită cu ordine de magnitudine față de nginx, ci doar o viteză de ordinul procentelor mai mare, dar totuși vizibilă. La capitolul aplicații dinamice este zona unde strălucește, deși încă mai are puțin până în zona “production ready”, în sensul că momentan lipsesc două chestii mari și late. Prima chestie este renunțarea la privilegiile elevate dacă rulează ca network daemon, unde pentru a folosi portul 80 este nevoie de privilegii de superuser – sau să se apeleze la hack-uri precum NAT prerouting în iptables ori *inetd – nerecomandate. A doua chestie este suportul pentru reverse proxy. Din moment ce codul existent nu se transformă peste noapte în ANSI C, eventual ANSI C optimizat la sânge, G-WAN va putea fi folosit, cândva, pe post de frontent web server într-o arhitectură multi-tier.

Configurația este … ce configurație? De fapt până și pentru virtual hosting se folosește un sistem de “convention over configuration” ce simplifică la maxim treaba, ceea ce face web serverul foarte sysadmin friendly. Singurele chestii mai sofisticate sunt maitenance script-ul și acele handlers, chestii ce necesită cunoștinte de ANSI C înainte de a te apuca să le folosești. Cam toate chestiile minime în accepțiunea unui web server modern sunt acolo inclusiv gzip, activat automat în funcție de tipul de conținut. Restul … sunt specificații, mai mult sau mai puțin interesante.

Update: săpând puțin prin web, am dat de CTPP ce se laudă că are interfață pentru C, chestie ce ar putea satisface nevoile de template engine. Încă nu am renunțat la gândul de a încerca o chestie implementată sub formă de bibliotecă/biblioteci compilate din moment ce acea compilare dinamică nu are suport de optimizare de aia șmecheră cum are gcc, MongoDB sau ceva asemănător pentru persistență și un servlet pe post de front controller.

Bun. Mi-am mai vărsat încă o dată anii de frustrare acumulați cu Apache, deci trebuie să pun și partea productivă în schemă. Sub Debian & friends se rezolvă simplu cu un:

apt-get -y install libapache2-mod-fcgid
a2dismod php5
a2enmod fcgid
/etc/init.d/apache2 force-reload
apt-get -y install php5-cgi

Cam atât pe partea de instalare. Cei ce suferă cu RHEL/CentOS, pot apela cu încredere la EPEL. Sau să compileze din surse. Nu o să îmi vărs în acest articol frustrările acumulate cu tandemul de mai sus.

Pe partea de configurare, integrarea dintre Apache + mod_fcgid + php-cgi lipsește cu desăvârșire ceea ce poate să dezamăgească mulțimea “kewl, I just installd Lenux and PHP”. Dar nu e nici “rocket science”. Ca idee: nano /etc/apache2/mods-enabled/fcgid.conf iar pe post de conținut:

<IfModule mod_fcgid.c>
    AddHandler fcgid-script .fcgi .php
    DefaultInitEnv PHPRC /etc/php5/cgi
    DefaultInitEnv PHP_FCGI_MAX_REQUESTS 10000
    MaxRequestsPerProcess 10000
    MaxProcessCount 10
    IPCCommTimeout 240
    IdleTimeout 240
    FCGIWrapper /usr/bin/php-cgi .php
    AddType application/x-httpd-php .php
</IfModule>

Aceasta este sintaxa “sigură”, deși ultimele versiuni ale mod_fcgid includ o sintaxă nouă iar cea veche este marcată ca “deprecated”. Pentru cei cu Ubuntu 10.04 LTS sau o altă distribuție relativ nouă, sintaxa actualizată este următoarea:

<IfModule mod_fcgid.c>
    AddHandler fcgid-script .fcgi .php
    FcgidInitialEnv PHPRC /etc/php5/cgi
    FcgidInitialEnv PHP_FCGI_MAX_REQUESTS 10000
    FcgidMaxRequestsPerProcess 10000
    FcgidMaxProcesses 10
    FcgidIOTimeout 240
    FcgidIdleTimeout 240
    FcgidWrapper /usr/bin/php-cgi .php
    AddType application/x-httpd-php .php
</IfModule>

Atenție: nu va funcționa pe versiunile vechi de mod_fcgid!

Încă puțin și setup-ul este gata de bătaie. Mai trebuie adăugat un flag în Options pentru a permite execuția PHP-ului sub FastCGI, sau serverul va returna 403. Fie se adaugă pentru fiecare definiție <Directory> din virtual host (nu e nevoie pentru <Directory /> în anumite cazuri) sau din .htaccess. Teoretic Options, conform documentației, poate fi setat în context <VirtualHost>, dar practic existența unui <Directory> cu Options o invalidează. Se poate seta doar pentru <Directory /> dacă toate celelalte definiții <Directory> nu au directiva Options. Pe scurt: Options funcționează pe ideea de arbore, dacă un fiu folosește Options, nu se mai moștenește părintele. Alternativa simplă și fără bătaie de cap, repet, pentru test/dezvoltare, este .htaccess cu Options +ExecCGI. Sub Ubuntu Hardy Options ExecCGI a refuzat să funcționeze din .htaccess, deci e mai sigur să fie prefixat cu +. Am repetat ce am zis în titlu pentru simplul fapt că .htaccess în producție se pretează doar unui mediu partajat ce este vândut de către companiile de hosting. În rest e risc potențial de securitate, în special pentru cele auto-generate (+ implicații la nivel de permisiuni), și supra-încărcare inutilă a serverului din moment ce Apache este mai țăran din fire și nu este notificat de schimbarea fișierului ci îl citește la fiecare cerere. În plus, un setup de producție făcut după “manualul de securitate” presupune configurare per virtual host și suEXEC versus rularea sub userul web serverului și un singur Dumnezeu pentru toate fișierele.

Din punctul de vedere al eficienței, în idle (după restartul serviciului) cu setup-ul implicit sub Ubuntu Hardy:

<IfModule mpm_worker_module>
    StartServers          2
    MaxClients          150
    MinSpareThreads      25
    MaxSpareThreads      75
    ThreadsPerChild      25
    MaxRequestsPerChild   0
</IfModule>

și un singur PHP upstream, am obținut un record de memory footprint pentru Apache 2: 18MiB.

Din fericire nu sunt singurul nemulțumit de problemele inerente ale părții de network management din Gnome deci a apărut alternativa: wicd. wicd este acel network manager ce mi-a lipsit multă vreme și m-a forțat să dau cu shell-ul prin /etc/network/interfaces. Pentru rețeaua fixă pe lângă interfața intuitivă, oferă și posibilitatea de a salva profile de conectare, chestie ce m-ar ajuta foarte mult spre exemplu dacă m-aș plimba cu notebook-ul prin varii rețele fixe, fiecare cu particularități în configurare. Lucru acesta era realitate acum vreo 2 ani, momente în care era pacoste să-mi reconfigurez rețeaua fără un mic ajutor de la zeul shell script. Sub Windows foloseam (și încă mai este instalat) NetSetMan.

Pe partea de wireless oferă posibilitatea de a seta interfața de rețea în funcție de access point-urile găsite, inclusiv pentru cele ce folosesc SSID ascuns, recte cel al subsemnatului pe care wicd îl detectează. Iar această “posibilitate” se traduce printr-un buton lângă fiecare AP detectat, nu săpat prin meniuri cretine ce oricum nu oferă nici un rezultat. Singura lipsă ce i-am găsit-o a fost imposibilitatea de a putea opri interfața wireless (turn off radio). Din câte am înțeles această funcție nu face parte din obiectivul unui network manager sau acestui network manager în particular. Sunt unul dintre ghinioniștii căruia Ubuntu îi recunoaște toate combinațiile de taste, mai puțin Fn+F2 pentru a putea opri wireless-ul. Nu sunt nici unul dintre fericiții cu hardware switch pentru radio, gen noteook-ul lui frate-meo.

Încă o chestie ce mi-a plăcut extrem de mult a fost posibilitatea de a defini un profil de global DNS ce poate fi folosit de către orice conexiune. Acesta poate fi suprascris prin setările particulare ale unei conexiuni. Oricum, sunt utilizator de OpenDNS și Google Public DNS ca fallback, deci profilul global este un real ajutor. Singura limitare este posibilitatea de a defini (din GUI?) doar 3 servere DNS, iar explicația vine de la un comentariu lăsat de defunctul Gnome Network Manager ce menționa în /etc/resolv.conf faptul că anumite biblioteci de resolving nu suportă mai mult de 3 servere, deci ultima intrare s-ar putea să fie ignorată.

Pe total, s-a dovedit a fi o adiție foarte utilă notebook-ului meu, ceea ce înseamnă faptul că Windows XP va coexsita acolo doar din motive istorice.

Probabil buba cea mai mare pe care o are (momentan?) Ubuntu 10.04 în ceea ce privește suportul pentru OpenVZ nu este faptul că (momentan?) nu poate fi folosit pe post de HN (Hardware Node), ci faptul că are probleme destul de mari în rularea ca guest. Abia acum am înțeles de ce DAB (Debian Appliance Builder) nu a venit cu suport pentru Ubuntu 9.10, iar acum pentru 10.04. Noul sistem de init, upstart, ce practic înlocuiește vechiul SysV init, nu se prea pupă cu OpenVZ, cel puțin nu implicit în unele pachete de servicii incluse în distribuție. Nu o să mai aduc aminte de clasica deja incompatibilitate între udev și OpenVZ.

Există mai sus vreo două întrebări din categoria “momentan”. Prima cel mai probabil va rămâne la stadiul de permanent. Din moment ce echipa din spatele Ubuntu adoptă LXC, eventualele bug-uri legate de OpenVZ vor intra în caregoria “won’t fix / invalid”, deci feedback-ul din partea comunității să se piardă. Sau să se ajungă la “by popular demand” – sper, deși slabe șanse. Cea de-a doua chestie în schimb se poate să fie rezolvabilă printr-un kernel comunitar ce să includă suport pentru OpenVZ (sper și pentru KVM). Între timp, Proxmox rulează și va adopta 2.6.32 și pentru OpenVZ. Momentan știe doar de KVM.

Ca regulă, cel mai probabil anumite servicii nu vor porni automat, la boot, fără a modifica scripturile de init, ce se găsesc în /etc/init nu în /etc/init.d (un upstart job din init.d este practic un symlink). Suport pentru SysV Init script încă mai este posibil dacă init-ul nu a fost convertit în upstart job din moment ce upstart a fost conceput cu gândul la “backward compatibility”. În ceea ce mă privește, cele mai problematice până acum au fost networking, ssh și mysql. Morala este: pentru a folosi Ubuntu 10.04 ca OpenVZ guest, este nevoie de pregătiri pentru doi termeni de bază: “hack” și “patch”. Cu toate acestea, consider că merită efortul. Lucid Lynx include suficiente soluții actualizate pentru a renunța la vechiul LTS, Ubuntu Hardy. Sau, de ce nu, la Debian Lenny.

Pentru că nu dețin toate informațiile, dau următoarele link-uri de unde mă inspir și eu:
Ubuntu 10.04 OpenVZ Templates
Download Ubuntu 10.04 OpenVZ Templates

Pentru că nu îmi place lucrul manual atâta timp cât există lucruri precreate:
http://bodhizazen.fivebean.net/openvz/

Printre altele, a trebuit să downloadez template-ul lamp pentru a mă inspira din scripturile de init pentru minimal. Sunt adeptul stilului minimal peste care să fac lego instalând direct din repo atunci când plasez o soluție. Less is more!

a) S.M.A.R.T.

S.M.A.R.T.-ul (Self-Monitoring, Analysis, and Reporting Technology) acesta deştept, pe lângă faptul de a furniza o târlă “geeky parameters” ştie să ruleze şi nişte teste automate la nivel de disk, a căror rezultate se salvează în log-ul propriu, fapt ce duce această tehnologie dincolo de graniţele sistemului de operare.

O să presupun că disk-ul în cauză este /dev/sda, eventual faptul că scanarea se face dintr-un live edition pentru a elimina anumite probleme potenţiale. Instalarea sub Debian & Friends se face prin pachetul smartmontools. Utilitarul interesant este smartctl.

smartctl -i /dev/sda

Comanda va returna informaţiile de bază despre disk, dintre care cele mai importante pentru a continua sunt ultimele două:

SMART support is: Available – device has SMART capability.
SMART support is: Enabled

Dacă e “Available” şi e “Disabled”, atunci se poate activa şi fără reboot pentru a meşteri prin BIOS. Dacă e “Unavailable”, atunci poţi să arunci rabla de HDD de pe bloc sau intru într-o zonă a disk-urilor ce mă depăşeşte.

smartctl -s on /dev/sda

Această comandă va activa S.M.A.R.T. dacă există. Dacă nu, citeşte paragraful anterior. Dacă da, lectură plăcută în continuare.

smartctl -a /dev/sda

Va da lista aceea de “geeky parameters” despre starea HDD-ului.

SMART overall-health self-assessment test result: PASSED

Ar fi bine să indice acel PASSED. Dacă nu, ar fi cazul să îţi salvezi datele şi să înlocuieşti echipamentul. De regulă ar trebui să fie acompaniate erorile şi de ceva descrieri. In principiu informaţiile cu flag-ul “Pre-fail” ar trebui să fie OK.

Dacă totul este OK, atunci se poate trece fără grijă la auto-teste. Ca idee există vreo 3, două rapide şi unul lent. Le recomand pe cele rapide să fie primele:

smartctl -t short /dev/sda

După ce trece timpul alocat testului se va rula:

smartctl -t conveyance /dev/sda

Atenţie, testele nu pot fi rulate în paralel sau puse în coadă. Execuţia unui nou test o va anula pe cea anterioară.

Se poate trage cu ochiul la progres prin:

smartctl -c /dev/sda

Cu toate acestea, nu are vreo formă de “progress bar”, doar un procent rămas pâna la terminare, actualizat din 10% în 10%.

Lista rezultatelor stocate în log-ul HDD-ului se poate afla prin:

smartctl -l selftest /dev/sda

Ca regulă generală, log-ul stochează ultimele 20 teste. Nu îţi pierde vremea (precum subsemnatul) căutând o metodă de resetare a log-ului. O fi existând vreo soluţie, nu am dat de ea în smartctl.

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed without error 00% 19368 -
# 2 Conveyance offline Completed without error 00% 19366 -
# 3 Short offline Completed without error 00% 19366 -

Cam aşa arată la mine după cele 3 teste, iar acestea sunt rezultatele “ochei”. Nu am zis de ultimul, acesta durează cât căderea turnului din Pisa şi a doua venire a lui Hristos la un loc. Este direct proporţional cu dimensiunea disk-ului şi bănuiesc faptul că ţine şi de viteza acestuia. Ultimul test se rulează prin:

smartctl -t long /dev/sda

Este un moment bun să îţi faci cafeaua, dacă bei cafea, să scoţi câinele la plimbare, dacă ai vreunul, etc. O să dureze suficient de mult, în special la dimensiunile disk-urilor din zilele de astăzi.

Parametrul -c al smartctl pe lângă starea execuţiei unui test anume furnizează şi durata lor:

Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 147) minutes.
Conveyance self-test routine
recommended polling time: ( 5) minutes.

În concluzie îţi poţi programa din timp ceva ce să umple acel gol. Din păcate numerele nu sunt precum progress bar-ul din Windows 98 unde arăta sute de ani şi termina în 5 minute sau un progress bar ce avansează dar timpul rămas creşte. Cam atâta durează testele pe bune şi pe rele. Datele de mai sus sunt de la un WD5000AAJS, adică un HDD de 500GB, 8MiB cache şi peste 19300 de ore de funcţionare. Da, are peste 2 ani de uptime, e normal din moment ce rulează în propriul server. Fratele geamăn, camarad de mirror, a murit răpus de Buleptrica, fie-i platanele uşoare. Cu această ocazie am făcut şi comemorarea soldatului căzut la datorie.

b) badblocks

badblocks este un utilitar, potenţial agresiv, menit să scormonească platanele şi să indice existenţa sau inexistenţa sectoarelor defecte. Spre exemplu eu am o mândreţe de HDD Fujitsu-Siemenes cules din notebook (ce a primit la scurt timp după achiziţionare un binemeritat upgrade la 7200 RPM). Junghiul acesta de disk corupe datele, n-are S.M.A.R.T. şi nici bad-uri. L-am scanat de câteva ori, cu mai multe utilitare, de unde concluzia că suferă de alte genuri de defecţiuni, recte electronice. Concluzia scurtă a poveştii de mai sus este faptul că badblocks nu este panaceu, identifică problemele pentru care a fost creat. Disk-urile nu trebuie să fie montate pentru a evita orice problemă, dacă au partiții. Deasemenea se recomandă prezența unei distribuții live, eventual în cazul în care aceasta nu este disponibilă, single user mode cu root montat ca read only.

badblocks -sv /dev/sda

Va rula un read only test şi arată progresul operaţiei. Durează ceva vreme, cam o oră şi ceva în cazul meu.

root@ubuntu:~# badblocks -sv /dev/sda
Checking blocks 0 to 488386583
Checking for bad blocks (read-only test): done
Pass completed, 0 bad blocks found.

Dacă vrei un test mai agresiv pentru disk, există și moduri read-write. Există doi parametri mari și lați: -n pentru read-write non-distructiv, recomandat pentru disk-uri ce au date pe ele, sau -w pentru read-write distructiv și îți poți lua gândul de la date cu -w, deci atenție. Parametrii -n și -w sunt disjuncți deci nu se vor utiliza împreună în aceeași comandă.

EOF

Dar să revenim la builder. Practic dab este un utilitar menit să subțieze destul de mult procesul de creare al unui template Debian. De fapt procesul în sine nu e mare filosofie, dar este stufos și necesită cel puțin un shell script pentru a reduce repetitivitatea. Cei de la Proxmox au reușit prin automatizarea etapelor de creare să reducă timpul și complexitatea necesară creării unui template OpenVZ pentru Debian. Având în vedere că Ubuntu este compatibil din punct de vedere binar cu upstream-ul (cel puțin la nivel declarativ), dab suportă printre altele și crearea de template-uri pentru câteva versiuni ale acestei distribuții.

Distribuții suportate de către Debian Appliance Builder:

• Debian Etch (4.0) (Legacy Stable)
• Debian Lenny (5.0) (Stable)
• Ubuntu Hardy (8.04) (LTS)
• Ubuntu Intrepid (8.10)
• Ubuntu Jaunty (9.04)

Remarcabilă este absență lui Karmic, deși nu este esențială având în vedere că următorul LTS, Ubuntu Lucid Lynx (10.04), stă să apară. Momentan a poposit la Beta 1.

Practic pașii necesari creării unui template au fost reduși la:

1. crearea unui fișier de configurare (dab.conf) cu o sintaxă “key: value” relativ simplă, explicată în documentație. Joacă rol de “metadata”.
2. init – moment în care se citește lista de pachete din repo-urile distribuției alese
3. bootstrap cu opțiuni, unde subsemnatul preferă “–minimal”. Prefer să am un setup minimal și să instalez din repo pachetele în funcție de context în momentul în care ajung la deploy. Less is more. La bootstrap se face downloadul efectiv al pachetelor în directorul cache al structurii pe care se construiește template-ul.
4. [opțional] instalare de pachete suplimentare. Minimalul lor nu corespunde minimalului meu, ce presupune și: htop, sysv-rc-conf, sysvconfig, bzip2.
5. configurare. Minimal în terminologia mea nu înseamnă o chestie redusă la dimensiune până la absurd, gen template-urile minimale de pe openvz.org ce funcționează cu o târlă de erori ce trebuie reparate de mână înainte de deploy. Plus faptul că sunt actualizate din an în Paște din moment ce sunt în secțiunea contrib iar maintainerii sunt de Duminică (one time only?). Printre altele, le optimizez pentru consum de memorie redus, și anume oprirea serviciilor ce nu sunt necesare cel puțin pe moment: cron, postfix, syslog (cu variații în funcție de distro), ceea ce se traduce prin: într-un container chel o să fie un memory footprint inițial de 1-2MiB necesar serviciului OpenSSH, după cum se lăudau și cei de la IntoVPS. Recordul personal e de 1MiB pe un template Debian Lenny i386 și aș merge pe varianta cu Dropbear în loc de OpenSSH doar de dragul virtualizării și a testării scenariului de “VPS small”. Timp pentru teste să găsesc. Ca dimensiune, ies în jur de 95MiB în urma arhivării gzip, în jur de 275MiB dezarhivat.
6. finalizare – ceea ce presupune curățarea automată a template-ului din containerul temporar urmată de arhivare. Având în vedere faptul că Proxmox VE necesită o sintaxă rigidă în ceea ce privește numele unui template ce trebuie să se regăsească în /var/lib/vz/template/cache (de pe la v1.2 dacă nu mă înșeală memoria), partea de finalize este un real ajutor pentru că se ocupă automat de numele buclucaș.

Singura bubă ce i-am găsit-o până acum este lipsa unui suport bun pentru edit & deploy. Cel puțin mie de îndată ce am rulat dab finalize – nu am mai putut reveni la reconfigurare, rearhivare, retestare. Din fericire dab clean nu șterge lista de pachete. Doar dab dist-clean face curățenie pe acolo, lăsând doar fișierul dab.conf și directorul cache ce e gol (WTF?).

Printre altele suportă crearea de template-uri folosind make și un Makefile. Nu îmi manifest interes deosebit pentru sintaxa Makefile cu care nu sunt familiarizat, iar shell scripting-ul e mai distractiv dacă tot e să automatizăm automatizarea. Suportă anumite scenarii gen bază de date sau PHP, dar cel puțin subsemnatul preferă să facă de mână instalarea de servicii esențiale în funcție de tipul de mașină, fie din repo, fie din surse dacă versiunea din repo e de pe vremea lui Nae.

Per total e un utilitar ce te poate scăpa de stufoșenia creării template-urilor de Debian/Ubuntu folosind debootstrap și un shell, utilitar ce îl Recomand™.

Atâta timp cât trebuie testată doar compatibilitatea userland-ului, o soluție de virtualizare bazată pe OS level virtualization este suficientă, adică se folosesc containere, nu instanțe virtualizare complet. Spre exemplu un setup testat local în container va putea rula pe un VPS, pe un VDS sau pe o mașină dedicată fără probleme. Nu o să fac referire la FreeBSD Jails și Solaris Containers pentru că am puțină experiență cu Jails și zero experiență cu Containers. În plus, destul de mulți se orientează în prezent spre Linux.

Dacă ești vreun guru în a rula vzctl în shell sau masochist, poți să te oprești din citit. Dacă nu, atunci voi vorbi în continuare despre OpenVZ plus metode civilizate și productive de a reproduce un setup. Bariera de intrare printre membrii ce folosesc tehnologia este destul de sus, motiv pentru care au apărut soluții integrate. Dintre acestea, recomand Proxmox VE (Virtual Environment). Băieții aceștia faini de la Proxmox au luat mai multe tehnologii de virtualizare și le-au pus sub același pachet: KVM (Kernel-based Virtual Machine) și OpenVZ, plus o interfață web pentru administrare. Practic Proxmox VE este un Debian Lenny împachetat cu tehnologiile despre care spuneam mai sus.

Setup-up este cretin de simplu, durează vreo 5 minute, se face pe o mașină ce nu are un alt OS. Își alocă tot disk-ul și își face partiții LVM. Este recomandat minim 2GB de RAM disponibil dacă se folosesc mai multe containere, minim 1GB RAM pentru un container folosind pentru ‘package maintenance’ ce are suport SMP și se folosește parallel build. Spre exemplu la un build de PHP cu make -j 3 am rămas fără memorie în container de 512MB RAM. Da, nu recomand instalarea unui compilator în producție sau build pe live servers. Alternativa ar fi DIY, adică o distribuție de Linux ce folosește kernel cu patch pentru OpenVZ, preferabil din repo, plus o interfață web precum WebVZ sau HyperVM.

Proxmox VE se poate instala fie direct pe fier (bare-metal hypervisor), fie într-o mașină virtuală creată cu VirtualBox ce este soluția pentru “desktop” ce o recomand. Am pus desktop între ghilimele pentru faptul că VirtualBox are o arhitectură complexă expusă prin CLI. În GUI se găsește doar un set limitat de funcții. În cazul în care se instalează într-o mașină virtuală creată cu VirtualBox (sau echivalent), nu se vor putea crea mașini virtuale folosind KVM pentru că este nevoie de extensiile de virtualizare din procesor (VT-x sau AMD-V) pentru aceasta. Oricum, scopul principal al acestui articol este OpenVZ datorită flexibilității ce o oferă. Acesta este motivul pentru care merită chiar și soluția de hypervisor sub hypervisor dacă nu îți permiți luxul unei mașini dedicate. În principiu pe o stație de lucru suficient de puternică nu ar trebui să fie probleme în ceea ce privește rularea unui Proxmox VE sub VirtualBox. Îmi permit aroganță de a menționa faptul că nu am mai lucrat de mult pe o mașină sub quad și 8GB RAM.

Având în vedere faptul că pentru OpenVZ se pot crea relativ ușor template-uri, iar virtualizarea constă în crearea unui container nou, operațiunea prin care se obține un nou setup durează destul de puțin. Iar în cazul în care un container nu mai este necesar, distrugerea acestuia este o operațiune rapidă. Practic se obține propriul mini-cloud, ușor de administrat, ce va scădea timpul în care se creează diferite scenarii ce vor ajunge în producție.

În cazul în care nu am fost suficient de clar la început, repet: setup pentru testarea userland-ului. OpenVZ oferă acces limitat la kernel din moment ce nu folosește virtualizare completă a sistemului de operare, doar rețeaua este virtualizată. Spre exemplu folosind kernel-ul livrat cu Proxmox VE se pot folosi FS-uri virtuale bazate pe FUSE dacă se sapă puțin prin vzctl, ceea ce deschide anumite posibilități în producție gen s3fs (netestat sub OpenVZ de subsemnatul, am testat alte module FUSE) prin intermediul căruia se poate monta un bucket de Amazon S3 ca FS local. De altfel, am reprodus și un sistem desktop într-un container OpenVZ, Ubuntu Hardy, accesat prin FreeNX, deci limitările sunt destul de puține gen lipsa unui suport civilizat pentru loop device.

Soluția de moment: downgrade la Firebug 1.4: http://getfirebug.com/releases/firebug/1.4/

PS: Firefox 3.6 sub Hardy amd64 este probabil cea mai instabilă versiune lansată vreodată. Am avut versiuni de Firefox Alpha sau Beta ce erau mai stabile de atât.

Bun. La partea cu instalarea îmi doream să ajung. Mai bine zis la partea cu actualizarea. De regulă pe un Ubuntu Server ce mai rulează servicii mici/medii VirtualBox are bunul simț să ruleze în background ca daemon printr-un simplu init script. În concluzie actualizările le fac atunci când îmi mai aduc aminte să deschid interfața grafică. Sub Windows în schimb este o jucărie unde mai testez ultimele apariții în domeniul OS. Dar aici mă lovesc suficient de des de acea fereastră ce mă anunță faptul că a apărut o nouă versiune. Click – download  – next, next, next … gata. În teorie era gata. În practică 3.0.12, adică ultima versiune, refuză să adauge orice fel de HDD virtual nou și am o mică bănuială despre imposibilitatea de a adăuga noi mașini virtuale.

Mă apuc să lucrez în calculator să văd ce se întâmplă (doctore). Cretinătatea aceea de installer nu a închis VBoxSVC înainte de instalare. Adică acel serviciu ad-hoc din arhitectura VirtualBox ce se ocupă de mașinile virtuale atâta timp cât rulează cel puțin una. În mod normal stă închis acel proces. Ridicolul merge mai departe. Acel proces, VBoxSVC dă un ‘lock’ exclusiv pe fișierele de configurare astfel încât să nu apară chestia aceea numită ‘race condition’ în geek language. Iar acel proces nu mai vrea să moară. Task Manager-ul e inutil ca de obicei la omorât procese încăpățânate. Am scos artileria grea: Advanced Process Termination (APT). Pe lângă o duzină de metode de kill, știe două metode de kernel kill și încă două de crash kill. Kernel kill pe Windows 7 x64 nu are suport. Nu mi-am spart capul cu hack-ul de OS. Din păcate metodele din user mode au dat greș. Windows încă e copil mic și udă patul atunci când vine vorba de procese încăpățânate. Sistemele UNIX-like (ex: Linux, FreeBSD) rămân în situația penibilă de mai sus atunci când un proces rămâne blocat în ‘IO wait state & friends’. Soluția este evidentă: reboot. Dar m-am cam săturat să rămân cu procese blocate pentru ca Windows e rebut la management-ul lor din ‘user mode’. Iar VirtualBox e rebut la actualizare și nu își știe închide serviciul înainte de un nou ‘deploy’. În mod curios, procesul blocat nu apare în APT. Dar APT are o jucărie numită ‘Custom PID’ pentru a da kill după kill.

Din păcate, ocazional, dezvolt și aplicații ce au nevoie de acces la funcția mail(), funcție ce altceva înafară de FALSE aka FAIL nu știa să returneze. Verific Postfix-ul – rula de zor. Deci nu era bubă de MTA. NU, nu suport Sendmail. Iau o porție de copypasta de pe php.net, pun totul întrun fișier php, rulez în shell – surpriză:

sh: -t: not found

Mă scarpin cu o mână în cap și cu cealaltă în dos. Ceva îmi pute – și nu era de la a doua mână. Încep să sap pentru a afla ce pește prăjt au făcut cei de la Zend cu php.ini de încearcă să ruleze aplicația ‘-t’. Crăp un output de phpinfo() in Firefox și mă luminez:

sendmail_path Local Value: -t -i Master Value: -t -i

Erm, WTF Zend? Casc vinovatul (/usr/local/zend/etc/php.ini) și caut linia cu pricina ce bine mersi era comentată. Cică în mod implicit ar trebui să fie ‘sendmail -t -i’, dar se pare că opțiunea nu este hardcodată ca atare. Soluția e la mintea cocoșului:

sendmail_path = sendmail -t -i

Restart la Apache2. Merge? Merge. Shell-ul este fericit deasemenea.

M-am trezit inca de dimineata cu gand rau impotriva Gnome History. Din pacate gandul meu a fost mai slab decat implementarea incapatanata a celor ce au gandit Gnome-ul din acest punct de vedere si n-au pus pe undeva o optiune pentru dezactivarea acestei functii, optiune ce sa fie demna de ‘Captain Obvious’, altfel spus, la mintea cocosului. Daca in trecut istoricul se tinea in fisierul ~/.recently-used iar un simplu:

chmod -c 400 ~/.recently-used

era suficient pentru a opri atrocitatea, in prezent (de la Gutsy si pana in prezent daca nu ma insel) lucrurile sunt sensibil mai diferite. Numele fisierului s-a schimbat intre timp in .recently-used.xbel. Nu aceasta ar fi problema esentiala daca metodele clasice ar functiona. Am incercat schimbarea ACL-urilor precum am pus mai sus: ceva le restaureaza. Am pus symlink catre /dev/null … ceva sterge link-ul si restaureaza fisierul. L-am creat de sub root si l-am lasat asa … ceva ii restaureaza ACL-urile si le pune iarasi pe contul meu. Parca era un film de acela prost cu Greuceanu ce omoara balauri alimentati cu baterii Duracell ce tot primesc resurect. Din fericire acesta a fost balaur pe 2 biti (4 capete). Cine stie bancul cu balaurul pe 8 biti, pricepe.

Metode exista, si sunt doua la numar. Prima desi functioneaza, este trista pentru ca are prostul obicei de a genera erori GTK in shell:

rm ~/.recently-used.xbel ; mkdir ~/.recently-used.xbel

Se pare ca e o piatra prea tare de rumegat pentru implementarea incapatanata prezentata mai sus.

Dar are dezavantajul erorilor din shell. Fericitii (ca mine) ce folosesc ext3 pe post de filesystem (nu cunosc utilitare echivalente pentru reiser, xfs, jfs – nu dati cu pietre) pot apela la o smecherie ce marcheaza fisierul ca immutable iar la incercarea de a face ceva, o sa se loveasca de un raspuns mai incapatanat de la Sfantul Kernel:

sudo chattr +i ~/.recently-used.xbel

Chestia asta il va opri pe mucos sa mai salveze istoricul, ba mai mult, scuteste shell-ul de erori neinteresante.

Introducere

Determinarea MIME Type-ului corect pentru un fisier este o problema esentiala. Nu o sa explic si de ce … daca nu stii de ce, atunci tutorialul acesta iti depaseste nivelul cunostintelor. Atunci cand se face upload la un fisier printr-un form, sau se doreste import-ul unui fisier, se poate intampla ca extensia fisierului sa nu reflecte realitatea sau ca aceasta sa lipseasca cu desavarsire, fapt ce va duce la varii probleme. Array-ul $_FILES ce ia valori in functie de continutul unui form ce are specificat in mod explicit enctype=”multipart/form-data” se prea poate sa nu contina valoarea corecta a mime type-ului pentru $_FILES['file_input_name']['type'] deoarece detectia mime-ului cade pe spinarea browserului iar in majoritatea cazurilor acesta se foloseste de extensia fisierului deci va esua in cazurile descrise mai sus. Este nevoie ca informatia sa fie interpretata citind headerele fisierului si folosindu-ne de mime magic.

PECL si fileinfo

Nu o sa imi pierd timpul sa explic ce e PECL. Google este de mare ajutor. Din pacate in repository-urile Ubuntu/Debian, extensia fileinfo nu este disponibila in mod implicit. Din fericire este disponibila prin intermediul PECL. Acum incepe treaba sa fie paroasa.

In primul rand, este nevoie de una bucata compilator. Exista un pachet ce le face pe toate, deci:

sudo apt-get install build-essential

Bun. Avem compilator, avem PECL (presupun, daca n-ai HTTP server si PHP – citesti degeaba). Pentru build-ul fileinfo mai este nevoie de pachete de development, deci:

sudo apt-get install libmagic-dev php5-dev

ce va instala headerele de development pentru libmagic, phpize si alte chestii. Faceti acum, sau regretati mai tarziu. Acum este timpul sa compilam extensia fileinfo folosind pecl:

sudo pecl install fileinfo

Daca maraie vreo eroare la configure, instalati pachetul de development aferent (pentru cei somnorosi, are sufixul -dev). Daca maraie vreo eroare la compile, imi pare rau, nu va pot ajuta. Pe masina de devel a functionat fara probleme. Daca nu maraie nici o eroare, ar trebui sa indice faptul ca extensia a fost instalata cu succes. Ar trebui sa fie ceva de genul:

Build process completed successfully
Installing ‘/usr/lib/php5/20060613+lfs/fileinfo.so’
install ok: channel://pear.php.net/Fileinfo-1.0.4

Daca ati ajuns pana aici, mai este putin si usor. Extensiile instalate prin intermediul PECL nu sunt incarcate in mod automat, spre deosebire de cele instalate din repository-urile Ubuntu/Debian folosind apt-get sau alternativa (cu mici exceptii, spre exemplu mcrypt.so trebuie incarcat in mod explicit – nenea maintainer a fost cascat). Pentru a mentine ideea si spiritul Debian, incarcarea modulului se va face folosind directorul de fisiere alternative de configurare pentru PHP. Tastati urmatoarele chestii intr-un terminal (da stiu, copy-paste e mai comod):

cd /etc/php5/conf.d/; sudo touch fileinfo.ini; sudo nano fileinfo.ini

Bagati urmatoarea linie in acel fisier:

extension=fileinfo.so

dupa care salvati cu Ctrl+O. Inchideti editorul text folosind Ctrl+X. Nu, nu sunt vim maniac, sa nu aud de el. Acum este timpul sa se dea restart la HTTP server pentru a incarca noua configuratie. Ar trebui sa fie valabil si pentru cei cu GCI/FastCGI (eventual alt HTTP server gen lighttpd), desi subsemnatul e de ala cu Apache 2+PHP5 handler, deci in cazul meu (si al majoritatii):

sudo /etc/init.d/apache2  reload

ce va duce la un graceful restart (aka restart fara downtime) urmat de incarcarea noilor fisiere de configurare. Daca totul e ok, noul modul de PHP ar trebui sa fie incarcat. phpinfo(); ar trebui sa indice acest fapt, atat in lista de fisiere de configurare alternative (cele din /etc/php5/conf.d) cat si prin faptul ca ar trebui sa indice pe undeva in mod explicit faptul ca fileinfo este incarcata.

Utilizarea fileinfo pentru a afla MIME Type

Acum sa trecem la lucruri grele. fileinfo contine niste functii smechere asemanatoare cu fopen. Pentru ubergeeks exista modul orientat obiect de lucru cu ele (php.net/finfo_open explica), dar subsemnatul se multumeste cu trei apeluri procedurale din moment ce nu exista nici un avantaj real in cazul de fata pentru a defini un obiect si a-l distruge dupa ce se afla mime-ul. Pentru cei dornici sa isi implementeze o clasa proprie … este alta poveste. Eu mi-am facut o functie custom ce am inclus-o in API-ul central ce primeste ca parametru calea fisierului si imi returneaza mime-ul in caz de succes sau un cod de eroare pentru debug in caz de esuare. Miezul problemei sta in:

$finfo=finfo_open(FILEINFO_MIME, "/usr/share/misc/magic");
if(!$finfo)
	die("Can't open the fileinfo database.");
$mime=finfo_file($finfo, $fileName);
finfo_close($finfo);

Si cam atat. Succes si spor la treaba.

echo “blacklist mod_name” >> /etc/modprobe.d/blacklist
sudo update-initramfs -u

Voila … sintaxa pentru blacklisting …

http://www.thewebsiteisdown.com/

Pozele spun totul … mai mult decat 1000 de cuvinte …

In fine, nu ma apuc sa detaliez chestii. Important este ca din punctul de vedere al resurselor ocupate sta foarte bine (si zic asta de bine, nu de rau), este rapid, n-am avut probleme nici cu stabilitatea. Mi-am pus si Compiz-Fusion (evident, dooh) pentru ca am mai declarat pe undeva urmatoarele: dupa perioada OS X nu am mai putut sa privesc un desktop non-3D cu aceeasi ochi. Desi este cel mai bun sistem pentru servere (daca maine ar fi sa imi trec file serverul de pe Ubuntu Server pe FreeBSD – as face-o, dar imi trebuie niste timp pe care nu il am) sa zicem ca face o figura frumoasa si pe desktop. Ce-i drept, are lipsurile lui, despre care cred ca o sa ma apuc sa scriu la un moment dat.

Din punctul de vedere al hardware-ului, singura chestie care imi lipseste enorm este un driver care sa imi suporte placa de sunet care o am ca add-on, si anume o Audigy 2 ZS Notebook. Ce-i drept, n-am incercat Open Sound System care vine cu propriile module. Este o idee. Driverul snd_emu10kx care suporta Audigy si Audigy 2 nu vrea sa stie de placa mea, ba mai mult, cand l-am instalat si am uitat sa il scot din lista de boot (s-a pus automat acolo), FreeBSD a refuzat sa mai boot-eze pana nu am eliminat fizic placa din sistem. Acu pe partea de multumiri din punctul de vedere al hardware-ului este faptul ca se pupa bine cu el, ba mai mult, a rezolvat o problema pe care nu au reusit sa o rezolve nici driverele de sub Windows si nici cele de sub Linux: placa de retea – pe care o suspectez de o oarecare defectiune care se manifesta la 100Mbps. Chiar am facut teste de transfer prin SFTP, MikeS este martor. I-a picat si lui fata la testul de doua fisiere peste 1GB – nu a cazut nici unul sub 5MB/s, media a fost undeva de 11MB/s. Culmea, la 1Gbps prin conexiune directa cu serverul merge “flawless” sub Windows si Linux. Am umplut vreo 3 threaduri pe varii forumuri de specialitate in cautarea unei solutii. N-am gasit nici in prezent. Sub Windows/Linux tot ca un cur imi merge reteaua daca nu o pun pe 10Mbps – iar la 10Mbps ma apuca Sfantul Asteapta pana iau ceva de pe severul propriu care este in acelasi LAN – limitat la 100Mbps de router, un ASUS WL500g Premium. Cica in ultimele lui ore de viata, Linuxul in linie de comanda cu Midnight Commander si serverul montat prin SSHFS nu a mai cazut la trasfer (si am facut un backup masiv, vreo 30j de gigi de date). Dar este singura situatie in care a functionat corect … in rest a fost praf.

Oricum, articolul care mi-a dat multe idei si m-a facut sa imi pun FreeBSD in defavoarea Linux a fost acesta:

http://www.over-yonder.net/%7Efullermd/rants/bsd4linux/bsd4linux1.php

Iar daca ar fi sa apreciez ceva la FreeBSD este faptul ca fisierele de configurate tipice sunt foarte logice ca denumite, ca pozitionare in file system, precum si inca alte cateva chestii. Deasemenea ma bucur ca nu exista haosul din lipsa de organizare a Linuxului in ceea ce priveste anumite chestii dat fiind faptul ca un standard este greu de impus cand fiecare incearca sa traga foc la oala lui. Inchei …

Sursa: http://wonder.rodp.net/2008/02/pidgin.html

KDE 4, asa cum a fost promis, ruleaza nativ sub Linux, Windows, OS X, mai pe scurt, sub orice platforma sub care este suportat Qt-ul celor de la Trolltech. Inainte sa apara eram destul de entuziasmat de vestea aparitiei KDE 4. Tin minte ca din intamplare citisem despre planurile ce tin de KDE 4 inca de acum 2 ani. Eram entuziasmat pentru faptul ca la vremea cand asteptam KDE 4, inca eram user de KDE 3 sub Linux. Faptul ca a fost promis nativ sub Windows/OS X nu a facut decat sa imi creasca entuziasmul.

O mica notificare ar fi faptul ca sub OS X rula KDE 3 si o buna parte a aplicatiilor ce tin de acest desktop environment, dar modul de rulare nu era nativ ci rula sub implementarea Apple a XFree86. Chiar am fost curios sa vad cum arata o mana de aplicatii KDE sub OS X si au iesit momente horror … aratau ca nuca in perete si faptul ca nu rulau nativ era destul de nasol la consistenta. Acum cica s-a rezolvat problema … astept sa vad cum arata treaba in teren.

Sub Windows lucrurile stateau putin diferit datorita anumitor restrictii ce tin de licentierea Qt 3. Da, KDE 4 respecta numerotarea versiunii majore de Qt sub care au fost dezvoltate … KDE 3 a fost dezvoltat sub Qt 3, KDE 4 sub Qt4. Nimic nou sub Soare. Odata ce problemele s-au rezolvat incepand cu v4 a Qt, acest fapt a permis portarea aplicatiilor si sub Windows.

Alaltaseara mi-am pus KDE 4 sub Windows. Installer-ul desi e grafic, cel mai probabil va pune probleme celor nefamiliarizati cu lumea *nix. Mi-e mi-a adus a installer de cygwin, deci concluzia rapida a fost ca baietii de la KDE nu au dorit sa reinventeze roata. Setup-ul a inceput in mod “uzual” – downloadarea pachetelor necesare din repository (uzual – cum ziceam mai sus, precum cygwin). Instalarea nu a decurs fara probleme. La anumite pachete setupul (v0.8.5 – cea mai recenta) claca fara drept de apel. Spre exemplu am dat sa instaleze toate tool-urile de development. Desi rar am avut nevoie de CVS cand de regula gaseam sursele gata arhivate, am dat sa instaleze si TortoiseCVS. Asta a fost OK. A crapat la instalarea TortoiseSVN pe care il aveam instalat deja din moment ce sunt SVN user, ce-i drept aveam o versiune mai veche. Clacatul se traduce prin 100% load si apasarea butonului de ‘Cancel’ se traducea prin proces care continua sa ruleze in background, dar nu facea nimic. Multumesc cerului ca setup-ul nu stie multi-core, deci sistemul nu a fost afectat substantial la viteza, sistemul mutandu-si chestiile pe core-ul celalalt al procesorului. Ar mai fi si alte pachete la care am intampinat probleme, si culmea, pachetele respective nu erau instalate anterior precum TortoiseSVN.

Utilizarea este de-a dreptul seaca. In primul rand trebuie rulate in terminal doua comenzi de configurare … nu am nimic impotriva, dar in documentatie caile erau indicate complet aiurea. Le-am dibut si am rezolvat. A urmat rularea aplicatiilor propriu zise. Practic installer-ul pune executabilele si dll-urile in directorul bin care se gaseste in directorul de instalare al KDE 4. Cum ziceam la un moment dat, poate fi putin ciudat pentru un user nefamiliarizat cu *nix. Pentru mine a fost OK, atata ca in bin este un haos de nedescris. Am dibuit niste chestii cunoscute, le-am rulat, a fost relativ OK. Prima executie a fost mai dureroasa in sensul ca tre sa isi faca in prealabil o chestie care ruleaza in background, dupa care nu mai sunt probleme. Aplicatiile se integreaza bine ca aspect printre celelalte. Inafara de cateva butoane si alte chestii tipice KDE, aplicatiile arata bine. M-am jucat cateva jocuri ce vin in pachet, am editat niste fisiere text folosind Kate si Kwrite, m-am dat pe net cu Konqueror. Desi am fost incantat, inca nu am vreun gand de inlocuire a unor aplicatii ce le folosesc deja sub Windows, exemplu Windows Explorer-ul pimpuit sa il dau la o parte pentru Konqueror din motive de varii instabilitati, feature-uri care nu functioneaza sau nu functioneaza corect, etc. Poate cel putin nu pentru moment. Mai este de lucru … atat la stabilitate cat si la uzabilitate. Oricum, KDE 4 sub Windows inseamna o mana de aplicatii, si nicidecum un full desktop environment, ceea ce lasa un gust semi-amar in gura.

Sub Linux totul a fost destul de scurt … dupa aproximativ 15 secunde de gugălit am gasit un repository neoficial in care sa fie KDE 4 pentru ubuntu. L-am instalat usor pentru ca package managementul si-a facut treaba. Mici probleme au fost la anumite aplicatii specifice, desi in general treaba a mers OK. Desktopul plasma arata bine, pare o revolutie peste KDE 3, desi mie inca nu mi-a sters impresia ca Vista Sidebar cu ale lui gadgets s-au mutat si s-au intins pe tot desktop-ul. La un moment dat a inceput chiar sa ma enerveze acest aspect. Interfata este mult mai bine lucrata din punctul de vedere al consistentei fata de KDE 3, multe chestii seamana, dar la anumite optiuni de configurare nu s-au eliminat dialogurile interminabile si putin uzabile. Am incercat sa schimb stilul ferestrelor de pe Oxygen (cel implicit si fresh pentru KDE 4) pe alte stiluri tipice KDE 3, dar a dus la scaderea caliatii vizuale. Oricum, la nivel de interfata, vizual vorbind, KDE 4 este peste KDE 3, desi inca nu s-au reparat unele din pacatele trecutului. Ce am apreciat a fost faptul ca s-a implementat meniul tabular care are motor de cautare pe care il stiu de sub openSUSE.

Aplicatii nu am prea testat pentru ca sincer nu ma interesau aplicatiile in sine, ci desktop environment-ul. Oricum, aplicatiile tipice KDE le rulez cu succes si sub Gnome, si chiar daca arata putin ciudat, tot raman in sfera acceptabilului. Desi de aproximativ 4 luni am trecut de la KDE 3 la Gnome, sincer sa fiu, nu m-as mai intoarce nici pentru KDE 4. In plus, desi initial erau o mana de chestii care in KDE le gaseam imediat si sub Gnome sapam dupa ele, cu timpul situatia s-a inversat. Exact aceasta a fost senzatia cand am trecut acum din sesiunea de Gnome in cea de KDE 4. Au inceput imediat sa imi lipseasca chestii, sa ma enerveze alte chestii, sa imi lipseasca Compiz-Fusion (da, dupa un an si ceva de OS X – am ramas fan al desktop-urilor 3D).

Pe total KDE 4 a fost pentru mine o semi-dezamagire, sau poate ca asteptarile mi-au fost prea mari. Vom vedea ce vor aduce versiunile mai noi, pentru ca desi e release, mie inca nu imi sterge impresia de preview release.

Chiar si Google, YouTube, Yahoo sau Wikipedia, FaceBook, Nokia folosesc platforma MySQL. Este nu doar o platforma open source, ci si foarte buna, stabila, usor de instalat, administat sau upgradat ulterior. Sun Microsystems vrea sa transforme solutia MySQL intr-o plartforma pentru companii.

Serverul de baze de date MySQL produs de compania MySQL ocupa aproximativ 80% din piata serverelor Web, un fapt bine cunoscut de altfel. Sun se asteapta sa dea lovitura cumparand MySQL prin integrarea serverului de baze de date in solutiile oferite de acestia, marind in acelasi timp canalele de distributie MySQL.

Avand in vedere cota de piata MySQL, se poate spune cu usurinta faptul ca aceasta tranzactie va schimba fata Internetului prin prisma impactului pe care il va avea aceasta tranzactie.

“Cumparam astazi o solutie pentru baze de date care a fost aleasa de clientii din toata lumea cu o viteza extraordinara”, a spus Schwartz. “Titanii web-ului folosesc toti MySQL, banci, companii auto, toate firmele din Fortune 500 folosesc MySQL”, a adaugat el.

Chiar nu mai am nimic de adaugat … speechless …

Sursa 1 Sursa 2 – oficiale

Sursa 3 – neoficiala

Sursa

Stateam si ma gandeam zilele acestea la o metoda de a proteja anumite aplicatii de accesul neautorizat in ceea ce priveste accesul fizic la o masina. Problema sta cam asa: un sistem securizat priveste utilizatorul ca un potential risc … deci nu este o entitate in care se pune incredere (si bine face, dar despre asta in episodul urmator). Chiar daca utilizez deja sistemul sub un cont de user dupa cum va povesteam aici, browserul, clientul de mail au master password care cripteaza parolele stocate in managerele proprii … sistemul prezinta o vulnerabilitate asupra accesului direct …

Se intampla sa vina prieteni pe la mine (din care unii evident – impart ocupatii asemanatoare), si cum nu am o masina dedicata pentru fiecare chestie in parte, sa zicem ca muzica canta de pe aceeasi masina de pe care fac development, browsing, si alte chestii. Momentan mi s-a pus pata pe cookie-uri, desi exista si alte date confidentiale care ar trebui sa ramana pe disk-urile proprii si numai acolo. Daca eu, ca detinator al sistemului … folosesc un model de securitate prin care eu nu sunt crezut fara autentificare ca superuser … de ce ar fi altii crezuti? Simplu … ei nu ar trebui sa fie, dar sunt. Browserul isi stocheaza profilul in directorul de “user data”. Chestia asta e valabila si sub *nix … deci vorbesc la cazul general, indiferent ca e vorba de /home/{user_name} sau de %systemroot%\Documents and Settings\{user_name}\Application Data (pe scurt %appdata%). Din moment ce browserul ruleaza sub un anume user … drepturile din “user data” sunt drepturile complete ale aceluiasi user. Simplu ca buna ziua. De ce nu mi-as crede proprii prieteni? Hmm … nu stiu … cred ca de cand am inceput sa citesc documentatie despre securitate … am devenit paranoic. In fine, sa continuia asupra ideei lansate.

Morala este simpla … se creeaza un utilizator cu acces limitat. Sub Windows (prin modelul prezentat in articolul anterior dedicat acestui fapt) este obligatoriu ca acesta sa aiba parola diferita de o parola nula pentru a permite utilizarea runas. Sub *nix este necesara prezenta loginului daca nu exista sudo, in caz contrar un sudo su {user_name} – ar loga un utilizator fara drept de login. Smecheria asta cu sudo am descoperit-o cand ma chinuiam sa dau drepturi de acces unui server HTTP (Apache 2) la un director SSH montat ca local prin sshfs. Solutia a fost sa montez directorul ruland comanda de mount de sub userul serverului … dupa ce in prealabil am dar acces mai larg la montare.

Dupa ce utilizatorul este creat … se muta user data-ul in directorul userului nou, se interzic drepturile de acces (citire) in ceea ce priveste fisierele utilizatorului (in cazul in care grupul/others au acces de citire la fisiere), iar aplicatia care se doreste a fi rulata protejat, se ruleaza folosind noul utilizator … astfel in momentul in care aplicatia este inchisa … datele sunt in siguranta. Ideea este simpla … punerea in aplicatie cere niste consum de taste in plus.

Apropo de paranoia care o ziceam mai sus … nu e 100% absurda. Au existat cazuri (da, la plural) cand din vina prietenilor mei, primeam acces la datele lor fara sa fac efort … mi se oferea un authentication_id (o metoda stupida de a autentifica calculand un hash obosit pentru a scuti utilizatorii unui site de actiunea de a tasta user+pass – si care ramane constant daca se schimba parola – deci algoritmul de generare este prost pentru ca nu stie de modificari, securitatea este precara datorita faptului ca un URL de acest gen este trimis in mod plain text prin retea), sau o usa de acces la chestii din sistem – si evident – nu ratam ocazia unui prank de zile mari. Motivul pentru care mi s-a pus pata pe cookie-uri care ar putea fi folosite pentru un prank la adresa proprie … motivul pentru care am varsat literele de mai sus … cu un singur catch … aplicatia nu trebuie sa ruleze ca utilzatorul respectiv in momentul in care se primesc vizite dupa modelul celui de mai sus (si chiar in general).

Disclaimer