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).

Să revin la problema inițială. Practic se pot identifica două probleme: a) validarea unei căi inexistente – deci apelăm la regex; b) validarea directorului – deși fișierul poate să nu existe în timpul execuției de validare, directorul e musai să fie acolo. De regulă aplicațiile care creează câte un UNIX socket nu verifică aceasta și vor eșua să pornească.

Rezumat, codul arată cam așa:

$validate = preg_match('/^(\/[^\0]*?\/?)[^\0\/]+$/', $path, $matches);
if (empty($validate) === TRUE OR is_dir($matches[1]) !== TRUE OR is_dir($matches[0]) !== FALSE)
{
	// handle error here
}

Acum, discuție pe marginea textului. Acest regex satisface direct ambele probleme. Prima, este fix problema de validare. Se ține cont doar de căi absolute – acesta fiind contextul în care operez. Cu toate acestea, soluția se poate adapta ușor pentru căi relative.

Singurul capturing group din expresie preia întreaga cale, mai puțin numele fișierului. A fost făcută să funcționeze inclusiv pentru root (/). Calea capturată trebuie să fie către un director, pe când calea întreagă trebuie să nu fie un director.

Teoria căilor este simplă. O cale UNIX poate să conțină orice caracter, mai puțin nul, iar / este folosit pe post de separator de directoare, deci este rezervat acestui scop. Căile de tip //var///www//// sunt valide. Exemplul anterior va duce în //var/www unde // în general (Linux, BSD) este tot una cu /. Nu am lucrat pe sisteme unde // să fie distinct față de /, deci nu am considerat că este nevoie să tratez cazul prin expresia de mai sus.

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!

AB + CD + AC + BD = 100

Ca orice “nerd” ce se respectă, am pus mâna pe Eclipse pentru a rezolva problema, nu pe o foaie de hârtie, din moment ce prin natura ei există 10⁴ ( da, 10.000) soluții posibile, dar doar 25 sunt corecte, considerând faptul că A, B, C pot lua valoarea 0. De fapt, am scris soluția ca pe una configurabilă pentru a-i servi și alt input dacă nu am nimerit-o și A, B, C încep de la 1. Oricum, muncă de 5 minute, dar i-am dat un refactor, să moară dușmanii de ciudă, fără număr la bandă.

Din moment ce propria pacoste de motan mi-a servit drept inspirație, codul e scris lolstyle (dar totuși câtuși de cât profesionist). Ca idee, I_can_has_numbers este clasa ce se ocupă de toate chestiile, iar fișierul I_can_has_everything.php este cel apelabil, fie din browser, pentru cei cu o stivă PHP instalată, fie folosind PHP CLI.

Cod: PHP5/OOP

Download: I_can_has_Makavelis_numbers.zip

Pentru cei născuți cu lene de a mai rula cod, acestea sunt soluțiile:

Number of solutions: 25

A = 0; B = 0; C = 8; D = 6; 0 + 86 + 8 + 6 = 100
A = 0; B = 1; C = 7; D = 6; 1 + 76 + 7 + 16 = 100
A = 0; B = 2; C = 6; D = 6; 2 + 66 + 6 + 26 = 100
A = 0; B = 3; C = 5; D = 6; 3 + 56 + 5 + 36 = 100
A = 0; B = 4; C = 4; D = 6; 4 + 46 + 4 + 46 = 100
A = 0; B = 5; C = 3; D = 6; 5 + 36 + 3 + 56 = 100
A = 0; B = 6; C = 2; D = 6; 6 + 26 + 2 + 66 = 100
A = 0; B = 7; C = 1; D = 6; 7 + 16 + 1 + 76 = 100
A = 0; B = 8; C = 0; D = 6; 8 + 6 + 0 + 86 = 100
A = 1; B = 0; C = 6; D = 7; 10 + 67 + 16 + 7 = 100
A = 1; B = 1; C = 5; D = 7; 11 + 57 + 15 + 17 = 100
A = 1; B = 2; C = 4; D = 7; 12 + 47 + 14 + 27 = 100
A = 1; B = 3; C = 3; D = 7; 13 + 37 + 13 + 37 = 100
A = 1; B = 4; C = 2; D = 7; 14 + 27 + 12 + 47 = 100
A = 1; B = 5; C = 1; D = 7; 15 + 17 + 11 + 57 = 100
A = 1; B = 6; C = 0; D = 7; 16 + 7 + 10 + 67 = 100
A = 2; B = 0; C = 4; D = 8; 20 + 48 + 24 + 8 = 100
A = 2; B = 1; C = 3; D = 8; 21 + 38 + 23 + 18 = 100
A = 2; B = 2; C = 2; D = 8; 22 + 28 + 22 + 28 = 100
A = 2; B = 3; C = 1; D = 8; 23 + 18 + 21 + 38 = 100
A = 2; B = 4; C = 0; D = 8; 24 + 8 + 20 + 48 = 100
A = 3; B = 0; C = 2; D = 9; 30 + 29 + 32 + 9 = 100
A = 3; B = 1; C = 1; D = 9; 31 + 19 + 31 + 19 = 100
A = 3; B = 2; C = 0; D = 9; 32 + 9 + 30 + 29 = 100
A = 5; B = 0; C = 0; D = 0; 50 + 0 + 50 + 0 = 100

Update: F (nu o să îi dezvălui numele din moment ce a decis să se semneze doar cu F ) a atras antețina asupra faptului că am făcut brute-force în soluția mea sofisticată, deci vin în întâmpinare cu un algoritm bazat pe modelarea matematică a soluției. Algoritmul rezolvă problema în numărul minim de pași (24), plus adăugarea soluției iregulate (unde trișez, este hardcoded). Numărul de bucle s-a redus la două cu număr minim de pași (4 pentru A, inițial 9 pentru B, după care scade, C și D sunt deduse).

Download: I_can_has_Makavelis_numbers_v0.2.zip

Update: din moment ce primii doi algoritmi sunt de cacao (fără o), primul e pur brute-force iar al doilea nu reprezintă o modelare matematică ce să includă toate soluțiile, revin pe scenă cu ultima soluție (finală) a problemei de mai sus.

Sursa algoritmului propriu zis:

for ($a = 0; $a < = 5; $a++)
{
	$double_a = 2 * $a;
	$end_b = 8 - $double_a;
	$d = $a + 6;
	for ($b = 0; $b <= $end_b; $b++)
	{
		$c = (8 - $double_a) - $b;

		if ($d % 10 === 0)
		{
			$a++;
			$d = 0;
		}

		$this->solutions[] = array
		(
			'a' => $a,
			'b' => $b,
			'c' => $c,
			'd' => $d,
		);
	}
}

Download: I_can_has_Makavelis_numbers_v0.3.zip

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

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU]
"NoAutoRebootWithLoggedOnUsers"=dword:00000001

Ca idee, târla de mai sus se salvează într-un fișier text cu extensie .reg, se execută și voila, bug killed.

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.

Era destul de evident faptul că va urma o replică de-a subsemnatului la adresa nesimțirii celor de la Adobe legată de lipsa Flash Player pe iPad. De altfel, ideea a mai fost discutată și de către Cătălin Nicolescu, dar eu iau o abordare diferită a problemei. Doar nu o să mă apuc să fac ‘rant’ pe aceeași temă.

Replica mea către Adobe ar fi: păi bine mă ipocriților, de ce nu plăngeți de faptul că eu pe Windows Mobile n-am Flash Player? Știu că există Flash Lite, dar eu nu l-am văzut rulând pe HTC-ul meu, ce apropo, Ș.T.I.E. multitasking, ca să fac referire și la produsul Apple ce nu mă interesează, dar care a generat discuția. Dacă vă doare atât de mult experiența utilizatorilor a unui X-produs pe web datorita produsului vostru proprietar, de ce nu văd un CAB pus la download ca să pot vedea și eu cum merge fleșul în PocketIE sau Opera Mobile? Sau să mă joc jocuri în fleș?

Nu e nici o diferență între ceea ce face Apple și ceea ce face Adobe. Adobe sunt totuși mai ipocriți. Ca să mă citez: același căcat împachetat altfel. Îi urez Flash-ului ce i-am urat acum câțiva ani: o deschidere mai mare spre platforme diferite, sau o moarte rapidă și foarte dureroasă.

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.

Pe alocuri plângerile mele au avut succes. Acum două zile colegii de echipă mă ascultau în timp ce modificam niște chestii, iar involuntar am zis: iar de aici copiez dincolo … touche: “Ce-ai zis mă? Să copiezi?”. Exact ce ziceam mai sus … câteodată și mie îmi vine greu să nu scriu cod prost. Dar eforturile susținute = evoluție. În concluzie am luat linia aceea lungă (un apel înlănțuit de proceduri) și am pus-o într-o nouă metodă.

În concluzie vreo câteva idei, departe de a oferi o imagine completă:

• dacă îți vine să faci copy-paste, fie ele și 3 linii de cod sau una lungă, înseamnă ca ai nevoie de un mic refactor.
• o arhitectură bună, modulară, a aplicației, DRY (și preferabil KISS) compliant, duce la o mentenanță mai ușoară. Pentru a modifica ceva nu este nevoie să cauți toate instanțele aceleiași bucăți de cod.
• dacă acea parte de ‘unknown’ umbrește puterea de a-ți crea arhitectura înainte de a o implementa, atunci orice model repetitiv din cod stă bine într-o metodă separată.
• caută să înțelegi framework-ul pe care îl folosești. De exemplu în dezvoltarea web folosind MVC, nu prea are ce căuta într-un controller o chestie ce ar sta bine într-un helper/bibliotecă, pentru că atunci când este nevoie să fie apelată bucata respectivă din alt controller, fără refactor, o să fie trist. Desigur, excepție fac acele controllere moștenite, dar și acolo este o linie fină între ce se poate moșteni și ce ar trebui să fie apelabil global.
• refactor, OOP, clase, interfețe, ‘design pattern’ (exemplu: singleton) ar trebui să nu fie doar cuvinte într-un vocabular de specialitate.

Știu, nu vreau să fac “carieră” din astfel de post-uri pe blog și nu prea cred că o să mă vedeți vreodată să trimit chestii către http://hackersblog.org/. Sunt preocupat de a proteja, de a-i învăța pe alții cum să se protejeze, și mai puțin de a demonstra vulernabilități. Sunt orientat către ce nu ar trebui să facă aplicația și mai puțin înspre a demonstra cum ajungi acolo. De altel aș prefera ca lumea să nu se ia de ‘junk’-ul de WordPress ce rulează pe blog, sunt prea ocupat pentru a scrie un engine sigur cu un număr echivalent de facilități. Mă rog, va urma un contra-exemplu pentru a susține cele din paragraful anterior.

Povestea începe de la faptul că am avut o mică discuție cu necenzurat despre importanța folosirii unui framework, dar el o susținea pe a lui cu alea 10 kile de cod. Doar pentru ce îți trebuie un framework de 1.25 megi (dimensiunea minimă, maxim 1.49) pentru o aplicație banală? Pai în primul rând bune sunt cele de PHP5 folosind OOP și clase cu auto-load. Poți face multiple instalări folosind aceleași surse ale framework-ului exceptând aplicația în sine. Folosești ce încarci. A da, și ai filtrare implicită. De ce? Pentru că nimeni nu este perfect. Greșeli apar și în codul programatorilor ce au trecut de fazele tatonării. Vorbesc din experiența lucrului și mai mult din experiența lucrului în echipă. Dacă tu ca programator nu o dai de gard, se prea poate să dea altul.

Acu recunosc, am trișat puțin. M-am uitat puțin prin cele 10 kile de cod astfel încât buba a fost oarecum imediată. Dar nu imposibil de descoperit cu puțină răbdare și stil având în vedere regulile simple de URL rewrite, destul de evidente, și faptul că era vorba de un singur parametru vulnerabil. De fapt am reușit 3 in 1: XSS, blind SQLi și disclosure în același input.

A da, a folosi mysql_error() în producție este una dintre cele mai proaste idei. XSS-ul și disclosure-ul au fost posibile prin intermediul acestei funcții magice ce ar trebui folosite doar pentru dezvoltare, nu și pentru producție.

Momentan nu dăm poze, așteptăm să aplice patch-ul trimis .

Paragraful anterior rezumă problema, dacă citim printre rânduri. Problema sub Windows este rularea mai multor procese FastCGI ce să servească pe același port, practic un cluster local cu ’round robin load balance’. Tehnic vorbind – se poate. Dincolo de un simplu FastCGI wrapper cum este spawn-fcgi, proiect de casă al lighttpd, a apărut o versiune nativă de Windows pe forurile respective. De curiozitate am luat sursa, am compilat-o cu MinGW (gcc -O2 -lws2_32 -o spawn-fcgi-win32.exe spawn-fcgi-win32.c) și am început să mă joc. Într-un mod așteptat, suportul pentru PHP FastCGI childs nu funcționează sub Windows, din motive tehnice. De fapt cercetând sursele PHP pentru cgi SAPI (php-src/sapi/cgi/cgi_main.c) partea cu child process este pusă între niște blocuri de preprocesare pentru compilator: #ifndef PHP_WIN32 … #endif ceea ce practic anulează FastCGI Process Manager-ul rudimentar implementat de către echipa de dezvoltare a PHP. Motivele sunt simple: spre deosebire de *NIX, sub Windows nu există conceptul de fork() al proceselor. Ba mai mult, sub *NIX există PHP-FPM(FastCGI Process Manager) ceea ce dă apă la moară și mai mult unei platforme non-Windows pentru PHP. Fanii nginx știu despre ce este vorba.

Vestea bună este faptul că acel spawn-fcgi-win32.exe știe să lanseze mai multe procese ce să servească pe același port TCP. Dă și idei despre cum ar trebui implementat un FastCGI Process Manager sub Windows pentru PHP. Ba mai mult, cum ziceam și în paragraful anterior,  acestea vor servi prin round robin load balance. Această arhitectură multiproces, deși nu se pretează stilului Windows ce este preponderent multithread, rezolvă problemele cu extensiile de PHP ce nu au implementat acel ‘thread safety’, iar clusterul poate să facă uz de o arhitectură SMP, fără a apela la threading.

Acum poate apare întrebarea: de ce mai multe procese FastCGI pentru a procesa scripturile PHP? În primul rând practica ne invață că un ‘segmentation fault’ poate să apară oricând, iar în producție nu este faptul cel mai de dorit. Arhitecturile multiproces s-au dovedit a fi cele mai potrivite. Vezi cazul Google Chrome cu 1 proces per tab. În al doilea rând, un proces PHP ce servește cereri FastCGI are o limită de 500 de cereri după care acel proces se închide. Acea limită este codată în sursele PHP (tot în cgi_main.c). Acea limită se poate altera prin ‘environment variables’, și anume prin: PHP_FCGI_MAX_REQUESTS. Problema care se ivește: o limită mare poate duce la probleme de memorie ocupată abuziv (memory leaks). În concluzie, această limită este necesară. Prin design-ul serverului FastCGI al PHP, limita este obligatorie și finită deci este nevoie de un PHP FastCGI Process Manager. Apache are ceva extensii (mod_fastcgi si mod_fcgid, doar mod_fastcgi știe să folosească TCP binding) sau soluția Zend Server: Zend Enabler for Apache, IIS are propriul manager. Piața de web servere de Windows ce întâmplător știu de FastCGI nu se termină aici. Spre exemplu eu folosesc versiunea nativă a nginx sub Windows pentru simplul fapt că folosesc nginx și sub alte platforme. Am o târlă de motive pentru care nginx este trecut în preferințele subsemnatului ca web server excelent. Dar, în același timp, nu pot să mă iau după toate ‘tutorialele’ de PHP FastCGI sub Windows unde ‘php-cgi.exe -b 127.0.0.1:9000′ este suficient pentru a rula. Este suficient până la primul crash sau până la 500 de cereri. În plus, eu ca web developer poate că îmi doresc o soluție complet separată de web server.

Bun, acum am pus bazele ideei despre cum ar trebui făcut un Process Manager. Una dintre probleme este acel ‘race condition’: dacă toate procesele au aceeași viață, spre exemplu un cluster local de 4 cu limită implicită de 500, atunci acestea se vor termina în modul următor: la cererea 1997 – primul, la cererea 1998 – al doilea, la cererea 1999 – al treilea, la cererea 2000 – ultimul. Dacă process managerul nu se prinde de faptul că nu mai exista cineva care să proceseze ceva.php, atunci web serverul va servi clasica eroare 504 (Gateway Timeout) iar clienții conectați la webserver vor fi nemulțumiți. Acel php-cgi.exe nu oferă o metodă de identificare a faptului că rămâne fără cereri. Nu există în cod suport pentru IPC (Inter Process Communication) cu un manager. În concluzie, după bootstrap, un manager poate doar să monitorizeze clusterul. Nu susțin faptul că nu s-ar putea implementa. Ori, această monitorizare poate avea întârzieri, și pe un server încărcat aceasta nu este de dorit. În concluzie, printr-un algoritm, managerul ar putea mări artificial și temporar viața proceselor 2, 3 și 4 pentru a pune un interval de întârziere și a fi cineva acolo care să servească până monitorul se prinde de faptul că lipsește cineva. Altă idee ar mai fi modificarea pentru Windows a serverului FastCGI ca să suporte respawn (autospawn), înainte de a se închide, deși încă nu am investigat dacă această posibilitate este realizabilă din punct de vedere tehnic. Teoretic ar fi OK, cel puțin din câte mă prind citind despre varii funcții din Windows API. Ar rezolva problema existenței unui child care să servească, in concluzie managerul s-ar transforma în simplu monitor de procese după secvența de bootstrap unde lansează clusterul. Idei am, din păcate n-am mai pus mâna pe C decât ocazional în ultimii 5 ani. Din fericire mai pricep ce e prin codul altora . Ziceam și pe Twitter: De ce nu există un PHP – FastCGI Process Manager sub Windows? Pentru că nimeni nu și-a dat interesul să scrie unul. Posibilităti există!

Ceea ce ne aduce iarăși la WinCache. N-am început degeaba cu el. Unei platforme PHP îi stă bine și cu un opcode cache (PHP accelerator, whatever). Pe lângă PHP din Zend Server – ce vine cu multe jucării de la mama lui, Zend, cred că se poate pune un nginx. Problema acceleratorului și al Cache API-ului ar fi rezolvată. Ba ar fi compatibil codul cu un eventual APC folosit în producție, chiar dacă în teorie, având în vedere soluțiile multiple, se recomandă o bibliotecă abstractă cu drivere pentru varii extensii PHP. Bun, ar zice unii: dar APC ce are? Păi, ultima versiune pusă la dispoziție de unul dintre oamenii ce se ocupă de build-ul de PHP pentru Windows, precum și de dezvoltarea lui, a pus la dispoziție o chestie compatibilă PHP 5.3.x ce din păcate pusă în setup-ul multiproces expus mai devreme duce la crash. Practic din 4 procese, 3 crapă, unul rulează relativ stabil. Contravine ideii de multiproces. XCache deși este excelent, nu foloseste shared memory pentru data cache, deci practic acesta va fi împărțit într-un număr egal cu numărul de procese. Nu știu code cache-ul cum se comportă. WinCache știe doar code cache, dar face uz de shared memory și funcționează bine cu load balancer-ul. În concluzie, cel puțin pe termen scurt WinCache are un rol acolo. Mai mult, WinCache funcționează doar cu versiunile de PHP non-thread-safe, compilate cu Visual C++ 9, și teoretic cu IIS, practic Microsoft a mințit. Funcționează cu nginx fără probleme și de ce nu, cu alte servere.

Altă idee: un server web sub *NIX ar putea folosi un server FastCGI sub Windows. nginx poate să folosească backend-uri multiple, eventual cu load balance între mai multe mașini. Deși încă sunt de părere că PHP sub Windows cam suge datorită faptului că are multe lacune iar majoritatea bibliotecilor ce le integrează provin din *NIX, are un atu: suportul COM/.NET – ceea ce înseamnă că într-o arhitectură existentă se poate adăuga un server Windows cu PHP ce să poată beneficia de anumite SDK-uri comerciale ce se distribuie sub formă de COM.

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.

- Mihai Brehar

- Maria Diaconu

- Aici ar trebui să am un nume, dar am un lapsus în schimb

- Ovidiu Negrean

- Ciprian Stăvar

- Ștefan Rusu (adică subsemnatu’)

- Alex Bolboacă

- Paul Nagy

- Jurgen Appelo

În fine, timpul a fost scurt, au fost ceva probleme cu locația, s-au propus mai multe teme, s-a vorbit în mare parte despre estimări. Am trecut repede la fapte, cu berea în față (am specificat: cadru informal) dar cu atenția spre Agile. Paul în special și restul au oferit câteva informații valoroase:

- estimările se pot face pe task-uri ce nu depind de alte task-uri. Un dezvoltator pricepe mai bine care-i treaba cu dependința.

- este mai ușor să măsori în unități relative comparat cu unități bine stabilite. Exercițiul a constat în faptul că l-a pus pe Mihai Brehar să estimeze distanța dintre ei. Răspuns: 1,5m. Următoarea chestie a fost: pune degetul unde crezi tu că este jumătatea distanței dintre noi. Ochiometric a fost bine, iar dacă treceam la măsurători precise, a doua estimare ar fi mai bună – de unde și povestea cu velocity points. Pe de altă parte acele velocity points sunt valabile pentru o echipă. Schimbi oameni din echipă – ai altă echipă. Ajungem la filosofia Agile – oameni, nu unelte, dar despre asta era vorba în primul rând, nu?

- pentru cei ce vor să estimeze task-urile în timp, Paul a fost ferm: ‘am o veste proastă pentru dezvoltatori – nu puteți’. Se leagă de povestea de mai sus.

-  au fost prezentate mai multe metode de estimare, pe lângă clasicele numere incrementate sau luate ca valori din șirul lui Fibonacci, Alex a prezentat un tabel ceva mai complicat (nu îl pot reproduce, am reținut doar chestia cu numerele la tricouri ), iar Paul a vorbit despre metoda cărților de poker.

- ca idee, este nevoie de date suficiente pentru a face calcule. Ideea este luată oarecum din teoria numerelor mari din statistică. Numerele mici dau statisticile peste cap cu variații mari când ai date puține … dar când ai date multe, situația se schimbă.

- încă o reprezentare grafică a fost o chestie ce arăta partea de ‘known’ și partea de ‘unknown’ ce înconjoară acea zonă. Se leagă de chestiile de mai sus. Scopul este de a trece mai repede de la ‘unknown’ la ‘known’ prin învățare – cu cât înveți mai repede, cu atât mai repede se produce tranziția – și prin feedback.

Pentru că discuția a rămas începută, am schimbat locația datorită micilor probleme pomenite mai sus. Mai multă bere (beer is priceless!) și discuții mai aprinse. Ca niște concluzii: Agile este o filosofie (nimic nou sub Soare aici) ca răspuns celor ce debitează pe această temă. Paul (din nou) a venit cu o completare la idee prin ‘Scrum este un framework’. Ba mai mult, este un framework minimal – dacă scoți din el, se duce naibii totul, dar mai departe pe el se poate construi și personaliza metodologia de lucru. De altfel, cred că Jurgen a spus aceasta, sper să nu atribui greșit citatul/adaptarea, cei ce ‘fac Scrum’ au tot atâtea șanse de a ‘face Scrum’ câte șanse are un programator de a instanția o clasă abstractă. Lucru ce vine în completarea ideii despre Scrum ca framework.

Altă discuție interesantă la bere ce merită menționată a fost motivul pentru care managerii nu trebuie să pună presiune pe dezvoltatori. Din nou Paul la balon – da a fost vedeta serii. Cercul vicios sună/arată cam așa: presiune de la manager catre dezvoltator -> grabă + hack -> cod prost -> maitenance -> mai puțini oameni activi. Ultimele 3 duc la frustrare, buguri care mai departe duc la și la mai multă presiune, iar frustrarea adaugă încă o doză de cod prost și bug-uri.

A doua zi a fost dedicată Code retreat-ului, deși a apărut prin zonă doar Mihai Brehar și mai târziu Ovidiu Negrean. Deși mă simțeam ca după o bătaie cu parul (motiv necunoscut), am luat parte la toate cele trei iterații ce s-au făcut pe problema jocului de poker, problemă pentru care am apelat la PHP ca limbaj și Kohana ca framework pentru simplitatea de a încărca automat clase și a face rapid un prototip. Primele două au fost alături de Mihai unde am exersat varii tehnici (TDD, pair programming), ultima a fost cu Alex. Ultimele două iterații au fost bazate pe TDD. Ca rezumat:

- prima iterație = FAIL. Cică era de așteptat. După 45 minute de pair programming, codul a fost rulat o singură dată și a returnat un simplu 0 – ceea ce nu rezolva prima mână. S-a văzut importanța testelor și ca o paranteză la implementare – folosirea limbajului de business cerut de client (black și white pentru jucători, nu hand1 și hand2).

- a doua iterație, TDD based, nu doar că a fost cu succes, dar am avut și timp de refactoring plus 5 minute de relaxare. Alex a fost prin zonă cu o mână de ajutor deoarece nimeni nu știa cum să facă TDD.

- a treia iterație a mers tot pe mâna TDD, am folosit o abordare diferită a problemei (altă echipă). Inițial ne-am propus să rezolvăm problema full house, iar în final am rezolvat și careul deoarece soluțiile erau înrudite în contextul respectiv. De data aceasta am fost creativ și am folosit o metodă matematică ce nu presupune parcurgerea mâinilor, ci calcule. Problema s-a redus la una de rezolvare a unui sistem de clasa a VI-a:

{ 2X + 3Y = 4X + Y

{ 2X + 3Y = X+ 4Y

ce rapid ajunge la X = Y  pe ambele ecuații (două drepte suprapuse, ca reprezentare în plan x0y) de unde și concluzia că soluția este funcțională pentru cele două cazuri (full + careu), deoarece X = Y presupune ‘five of a kind’ cum erau la acele jocuri obosite de poker ce se găseau prin varii baruri. E bună și matematica aceasta la ceva în programare și mi-am adus aminte de ce sunt bune unele modele: dacă sunt demonstrate corect și implementate corect, sunt ‘bug free’ din punct de vedere logic. Excludem erorile de limbaj/runtime.

Pentru că puțini pricep cum se face TDD, iau ca exemplu un feature ce trebuie să returneze -1, 0 sau 1 – folosit și în tratarea cazurilor la jocul de poker (black, tie, white).

- se scrie primul test (am folosit assert($obj->method() == -1);, nu am apelat la PHPUnit)

- se implementează un mock în method (return -1;)

- se rulează testul => OK

- se scriu celelalte teste (assert($obj->method() == 0); și assert($obj->method() == 1);), se rulează și evident, eșuează

- se implementează codul funcțional propriu zis

- se rulează iar testele, iar dacă totul e OK, refactor și teste

Chiar aveam într-o metodă o eroare de logică, TDD a arătat rapid sursa problemei, iar debug-ul a durat 10 secunde. Avantajele sunt clare. Ca idee: TDD se potrivește doar pentru core functionality, nu pentru interfețe. Nu poți testa un capcha sau un CSS pe IE 6 prin TDD. Pentru aplicații ce folosesc baze de date, este nevoie de un mock. În rest, metoda își arată utilitatea. Noapte bună!

Metode oficiale:

- Iei una bucată startup disk (floppy de ăla), pui imaginea ROM și aplicația de actualizate pe o partiție FAT, butezi în DOS și flash-uiești BIOS-ul. FAIL. N-am chef de floppy – nici n-am mai folosit vreunul de ani buni.

- Pentru cei fără partiții FAT (aka majoritatea în secolul 21), iei una bucată startup disk de Windows 98 sau Windows ME (WTF?!) plus una bucată floppy disk pe care se alfă aplicația de actualizare și imaginea ROM. Butezi de pe startup, actualizezi de pe al doilea disk. FAIL. Double FAIL.

Metode semi-oficiale (nesuportate de MSI):

- Îți faci cont pe forumurile MSI. Este trist pentru că nici măcar nu poți citi thread-urile de update făra cont. Trist și inutil. Există vreo două aplicații ce crează stick-uri USB pentru boot. Una dintre aplicațiile menționate știe chiar live update. Partea jenibilă: îți trebuie o placă MSI în sistem ca să poți face un stick boot-abil. WTF? FAIL.

Metoda subsemnatului:

- În primul rând n-am Windows pe mașina cu pricina și nici nu cred că o să am vreodată. Este strict pentru dezvoltare și altceva înafară de Ubuntu nu a văzut de la geneză și până în prezent. Floppy nu am de gând să îmi pun pentru un f%t%t de BIOS update. Și nici nu am de gând să caut două disk-uri. În plus sunt destul de fragile. Ca să fac un stick boot-abil trebuie să rulez pe o mașina cu placă de bază MSI ceea ce este inutil și enervant. N-o să pun Windows doar pentru că așa vrea dezvoltatorul aplicației respective. Da, actualizările MSI sunt Windows-centric. Aș fi dat multe pentru acel ASUS EZ Flash 2 cu inerfață grafică, accesibil din BIOS. Deși ASUS Update de Windows suge. Vineri a făcut praf un P5B Deluxe – a șters chip-ul, dar a ‘uitat’ să-l mai scrie. După care a refuzat orice interacțiune. Dar măcar suportul din hardware e impecabil. În concluzie a trebuit să fiu inventiv.

Pas 1 : Se ia una bucată UNetbootin. Are atât versiune de Windows cât și versiune de Linux. Pentru Ubuntu se găsește repository PPA, deci instalarea a fost după metoda standard după ce s-a adăugat noul repo în config.

Pas 2: Se ia una bucată stick USB formatat FAT32 și se infige în portul cu pricina. Se lansează UNetbootin. Pentru că pe net se găsesc doar tutoriale complicate despre cum se instalează FreeDOS pe USB, am ales UNetbootin. Are interfața cu dificultate apropiată de nivelul de percepție al unui retard.

Pas 3: se alege ca distribuție FreeDOS din primul drop down (da, nu știe doar Linux) – și versiunea 1.0 (singura disponibilă). Jos se alege drive-ul USB pe care să-l scrie (în cazul în care detectează mai multe) – OK. Ar trebui să downloadeze FreeDOS de pe Web și să-l pună pe stick.

Pas 4: Se desface arhiva în care se gasește imaginea ROM și aplicația de actualizare. Se pun pe stick-ul USB menționat anterior. Reboot.

Pas 5: Se scormonește prin BIOS pentru a putea face USB boot. Opțional se poate sări peste BIOS. F11 în timpul POST ar trebui să arate meniul în care se alege BOOT device-ul. Așa e la P35 Neo2 FR. La altele e Esc în timpul POST.

Pas 6: Se alege opțiunea 3 din meniul FreeDOS. Nu e un meniu standard (pentru cei familiarizați cu FreeDOS) precum cel din imaginea ISO. Opțiunea 3 e un live edition cu highmem suport, blah, blah, blah, yada, yada, yada. Se încarcă FreeDOS, după care se tastează în shell B:. Da, mi-a luat ceva să mă prind de faptul că B: este de fapt drive-ul USB propriu zis. În A: se montează live filesystem-ul FreeDOS.

Pas 7: Se rulează aplicația de actualizare ce primește ca argument fișierul de update. În cazul subsemnatului:

B:\> Afud408.exe A7345IMS.1A0

Se așteaptă până își termină toate mizeriile. Reboot. Ar fi bine ca sistemul să nu crape în timpul update-ului. Exclus OC și alte mizerii. Nu strică un UPS.

După reboot BIOS-ul o să dea un checksum bad la CMOS și e normal pentru că imaginea ROM e diferită. F1 pentru a intra în setup. Se va vedea faptul că s-a instalat ultima versiune și se pot pune vechile opțiuni. Succes.

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.

Sunt conștient de faptul că la nivel de WordPress problemele sunt minore sau inexistente datorită acelui sistem de token signature (wp_nonce), dar cumulat cu plug-in-uri defecte sau potențiale vulnerabilități pot duce la un efect de domino. Chiar descoperisem un plug-in vulnerabil la acest tip de atac, dar a fost patch-uit înainte să apuc să dau mail dezvoltatorului. Știu că unii pot atribui poveștii de mai sus valențe beletristice legate de droburi de sare, dar eu sunt dintre cei ce s-au mai fript cu WordPress – din fericire nu pe blogul personal. De fapt mulți dezvoltatori de plug-in-uri nu au o cultură a securității, și ca să nu fiu ipocrit, chiar și plug-in-ul subsemnatului are o problemă minoră ce ar putea fi exploatată printr-ul XSS+AJAX – deși e foarte dificil, dar nu mai este menținut din Ianuarie (va urma o rescriere completă). Iar o platformă atât de eterogenă are punctul cel mai slab localizat în codul cel mai slab – ce adesea va fi primul atacat având în vedere că acest aspect este o regulă în (in)securitate, iar caracterul deschis al platformei și plug-in-urile aferente elimină orice urmă de ‘security through obscurity’.

Pe de altă parte, la anumite probleme răspunsul a fost destul de prompt. În aceeași zi cu povestirea cu CSRF-ul de mai sus am dat un mail echipei de securitate cu niște XSS vectors localizați. S-a scris despre asta, deși detaliile sunt vagi. Problema raportată se manifestă doar pe IE 6, unele și pe IE 7, dar echipa WordPress nu s-a obosit să dea detalii. Atacurile se puteau lansa prin proprietăți CSS nefiltrate. Browserele decente nu suferă de această problema, dar judecând după cota de piață a IE 6 & 7 – lucrurile nu sunt roz. Din păcate vulnerabilitatea se regăsește în toate versiunile anterioare lui 2.8.2, deci în cazul în care un blog arbitrar are posibilitatea de user registration și contribuție – este recomandat minim WP 2.8.2. Problema e însăși acea kses, menținută de către dezvoltatorii WordPress. Oficial proiectul kses e mort – nu a mai avut suport de prin 2006. Iar kses nu a fost concepută ca o bibliotecă sigură până la paranoia. Spre exemplu HTML Purifier bifează cu succes toate test case-urile ce se găsesc in cheat sheet-ul celor de la ha.ckers.org dar nu observ nici un efort în adoptarea acestuia. Au fost făcute plug-in-uri în acest sens – dar această funcționalitate ar trebui să fie ‘core level’. Filtrul WordPress a fost testat parțial de către subsemnatul – iar rezultatul îl vedeți mai sus. Nu am testat event handlers pe JavaScript pentru ca sunt 90 si ceva, iar un test case corect ar fi preferabil sa il codez, nu sa il fac de mana din motive de dimensiuni.

Din păcate, etic ar fi fost să se menționeze și cine și-a pierdut timpul pentru a le testa aplicația și raporta vulnerabilitatea. Da, nu am fost creditat. Nu este prima oară când se întâmplă, dar în cazul WordPress este deranjant pentru că dialogul nu a mers fin precum în cazul altora. Am ales metoda mail – pentru că din nou, așa e etic, spre deosebire de acțiunea de a pune totul pe grok.org ca sa panichez lumea – ce oricum pune botul la F.U.D. mai mult decât trebuie.

Știu că a vorbi este ușor și in principiu este degeaba. Cum am spus în repetate rânduri, oricine poate să își dea cu părerea – dar nu orice părere conteaza. Cam din perioada amintită mai sus tot ameninț lumea cu un blog engine implementat pe un M.V.C. framework iar motivele sunt evidente. Nu contest cantitatea de timp investită in WordPress, numărul de plug-in-uri disponibile (ce în timp devin enervante pe partea de maintenance), dar prea multă entropie și mentalitate îmbâcsită s-a strâns acolo. Dar pentru a face ceva – evident, este nevoie de timp, motiv pentru care WordPress înca se bucură de acest status quo pe care îl are având în vedere că am facut un numar consistent de deploy-uri la viața mea (iar pe unele le mențin).

Window » Preferences » Team » SVN – iar Client se schimba din JavaHL în SVNKit. Voila – se rezolvă problemele.

Eroarea era ceva de genul:

RA layer request failed
svn: OPTIONS of ‘http://hostname/svn/repository_path/trunk’: Could not resolve hostname `hostname‘: No such host is known (http://hostname)

Acum totul este roz. Setup: Eclipse 3.4.1, Subclipse 1.6.2, Java 1.6.0_13.

Nu știu cum se face, dar în țărișoara noastră eCommerce + securitate sunt două concepte ce par a fi mutual exclusive, altfel spus sunt disjuncte. Cel puțin cam așa se întâmplă în ultima vreme. Dacă tot faceți update la site sau a dat tanti Tanța cu mătura pe tastatură, măcar puneți în puii mei o pagină de offline, sau băgați erorile în log, în loc să le băgați in browser.

Fatal error: require() [function.require]: Failed opening required ‘admin/encriptare.php’ (include_path=’.') in /[...]/index.php on line 13

Știu că este doar un simplu path disclosure, dar e un semn bun faptul că serverul acela nu prea e configurat pentru “producție”.