printf(" SaltwaterC ");

Kernel upgrade sub Amazon EC2 / Ubuntu

2011-06-10T06:45:37Z

Nu o să descriu o metodă generală de kernel upgrade pentru că nu cunosc una ce să meargă pe restul distribuțiilor. Canonical este un susținător activ al virtualizării, iar în cazul Amazon EC2 au pus umărul și oferă suport oficial pentru Ubuntu. Deci o să mă limitez la Ubuntu Server 10.04 LTS.

Dacă ar fi să mă iau după trendul celor de la RightScale de a merge “doar înainte în cloud”, atunci ar trebui să complic problema mai mult decât trebuie să se complice. Din nefericire nu toate aplicațiile au fost create ca să se muleze acestui model: “creez instanțe noi, pe cele vechi le arunc la gunoi”. Iar faptul că au dezactivat butonul de stop instance nu înseamnă că oricine trebuie să se muleze acestui model.

Tipul de management de mai sus presupune:

- apt-get update && apt-get dist-upgrade pentru a avea noul kernel pe disk
- snapshot la EBS (dacă există)
- creat AMI nou cu kernel ID nou
- adăugat instanță nouă in spate la load balancer
- oprit instanță veche

Tipul de management în viziunea subsemnatului:

- apt-get update && apt-get dist-upgrade pentru a avea noul kernel pe disk
- oprire instanță EBS backed
- schimbat atributul kernel (ec2-modify-instance-attribute –kernel $kernel_id $instance_id)
- pornire instanță

TADA!

Load balancerul și aplicația nu o să tușească la acest model. Pe cuvântul meu de cercetaș. Și se poate automatiza la fel de bine ca și modelul pe care-l propun alții.

Bila neagră către Amazon este faptul că nu o să câștige vreodată vreun concurs de uzabilitate. Modul în care și-au gândit anumite chestii sună mai mult a box împotriva unui API și mai puțin simpla utilizare a lui. Din fericire, cum ziceam mai sus, Canonical oferă suport oficial. Deci gasirea acelui $kernel_id magic nu este tocmai căutare în acul cu fân, dacă rogi frumos EC2 API Tools:

Update: Canonical se dovedesc a fi parte a conceptului “world-class pain-in-the-ass”. Noile imagini de kernel, se găsesc folosind:

ec2-describe-images -o 099720109477 --filter name=ubuntu-images/ubuntu-lucid-\*

Ce am zis mai jos rămâne valabil până la kernel 2.6.32.312-ec2. Mai nou, imaginile sunt în /ubuntu-images/.

# pentru mașini 64-bit
ec2-describe-images -o 099720109477 --filter name=ubuntu-kernels/ubuntu-lucid-amd64\*
# sau, pentru mașini 32-bit
ec2-describe-images -o 099720109477 --filter name=ubuntu-kernels/ubuntu-lucid-i386\*

Notabil este faptul că în /ubuntu-kernels/ se găsesc versiunile considerate stabile. Mai există și chestii ceva “bleeding edge”, dar vorbim de mediu de producție, nu de joaca de-a virtualizarea.

Update: la 2.6.32.316 (1 Iunie 2011) au revenit la schema de publicare explicată inițial. Doar 2.6.32.314 nu apare în listă, fiind nevoie să fie pescuit de prin lista de imagini oficiale.

MySQL Backup peste SSH

2011-03-01T10:10:26Z

Update (1 Martie 2011):

Suport pentru a specifica un MySQL host. E musai să fie definit minim cu “localhost” pentru o conexiune locală. Va folosi UNIX socket. Pentru TCP socket, se folosește 127.0.0.1 ca adresă.
Suport pentru compresie la nivel de protocol SSH. Mă gândeam la asta, dar am activat-o doar pentru MySQL – chestie destul de inutilă pentru o conexiune locală prin UNIX socket. Acum, cu suport pentru host extern, își are rostul.
Schimbat criptarea în blowfish-cbc ce este semnificativ mai rapidă pentru SSH.

Backup-ul – un rău necesar. Existența unui server cu skip-networking complică problema. Dar nu o face imposibilă. SSH știe să returneze chestii peste STDOUT. Iar un script pus în cron face ca această pacoste să intre în categoria “set it and forget it”.

Iar dacă tot am vorbit de un script, acesta este:

#!/bin/bash
 
# EDIT
MY_USER=""
MY_PASS=""
MY_HOST="localhost"
SSH_USER=""
SSH_HOST=""
SSH_PORT=""
# END EDIT
 
CDIR=$(dirname $0)
PKEY=$CDIR/private-key.pem
DUMP=$CDIR/dump
DATE=$(date +%F+%H-%M-%S)
 
if [ ! -f $PKEY ]
then
        echo "Error: The SSH private key file is missing!"
        exit 1
fi
 
if [ ! -d $DUMP ]
then
        mkdir $DUMP
fi
 
echo "Fetching the databases ..."
database=($(ssh -C -c blowfish-cbc -i $PKEY -p $SSH_PORT $SSH_USER@$SSH_HOST mysql -C -h$MY_HOST -u$MY_USER -p$MY_PASS -e '"SHOW DATABASES;"'))
count=${#database[@]}
for ((i=1; i<count ; i++))
do
        if [ "${database[$i]}" != "mysql" -a "${database[$i]}" != "information_schema"  ]
        then
                echo "Dumping ${database[$i]} ..."
                ssh -C -c blowfish-cbc -i $PKEY -p $SSH_PORT $SSH_USER@$SSH_HOST mysqldump -v -C -h$MY_HOST -u$MY_USER -p$MY_PASS -x -B ${database[$i]} | nice -n 19 pbzip2 -c > $DUMP/${database[$i]}-$DATE.sql.bz2
        fi
done
 
</count>

Are 5 opțiuni de configurare, destul de evidente. Caută private-key.pem în directorul în care se află – unde private-key.pem este cheia ce face posibilă comunicarea peste SSH fără a folosi autentificare cu parolă. Iar din moment ce se folosește rețeaua, atât mysql cât și mysqldump folosesc protocol compression (flag-ul -C). Dependințele sunt evidente la o primă citire. Nu este cel mai eficient mod de a face backup (rețea, spațiu), dar este simplu de implementat iar câteodată aceasta contează. Ignoră bazele de date mysql și information_schema. A se ignora ultimul tag a-la HTML din blocul de cod de mai sus. GeSHi face fițe.

Amazon EC2 Micro pentru un cluster memcached

2011-03-03T08:41:29Z

Am stat și am rumegat puțin problema unui cluster memcached ce s-ar putea face peste Amazon EC2. Patru instanțe t1.micro costă mai puțin decât o instanță m1.small ($0.02/h vs $0.085/h, la preț on-demand). În plus, pentru a avea o oarecare disponibilitate a unui cluster de caching, este nevoie de minim două instanțe din moment ce în mod cert în producție vor exista momente în care există mentenanță planificată. Iar la capitolul capacitate, patru instanțe t1.micro depășesc o instanță m1.small. t1.micro are 613MiB RAM dintre care se pot utiliza să zicem vreo 512MiB pentru memcached, pe când dintre cei 1.7GiB RAM disponibili pe o m1.small, sunt utilizabili vreo 1.6GiB. Patru instanțe t1.micro oferă așadar o capacitate mai mare unui cluster memcached decât o singură instanță m1.small. Iar rezervarea pe 3 ani pentru t1.micro costă $84. Deci nu e gaură în cer sau la buzunar.

Cu toate acestea, pentru început, dacă aplicația nu are cerințe mari (iar în general nu sunt pentru multe aplicații), două instanțe t1.micro pentru un cluster minimal sunt suficiente. Iar dacă este nevoie de mai multă capacitate, se poate adăuga oricând o nouă instanță, deci un “building block” poate fi prestabilit.

Acum nu vreau ca lumea să privească memcached ca pe un panaceu. Au pornit mulți de la ideea că a face caching în memcached este eficient în orice mod de utilizare. Nu este. Pentru o singură instanță, un “file based caching” este mult mai eficient. Da, se stochează pe disk, da disk-ul este mai lent decât memoria, dar acel kernel cache nu doarme degeaba. Acolo se duce memoria pe care bobocii cred că le-o mănâncă Linux-ul. Până și acele API-uri de caching din extensiile de PHP ce fac opcode caching sunt mai eficiente decât memcached, deși mai puțin eficiente decât acel PHP API cu condiția ca mașina care rulează aplicația să aibă suficientă memorie disponibilă pentru a face și kernel cache. Da, memcached pe local e mai ineficient pentru că IPC-ul presupune overhead. Au fost concluziile simple pe care le-am tras cu un benchmark simplu scris folosind Codebench. Nu mai am sursele, dar cred că o să-l reproduc curând și o să public rezultatele, pentru a încheia cu mitul memcached = panaceu.

Este totuși util pentru instanțe ce sunt puse în spatele unui ELB, Auto Scaling are grijă de instanțele EC2 ce rulează în spatele acestui ELB, și este nevoie de un cache consistent, distribuit. Un cache local pentru un cluster de mașini ce rulează o aplicație poate pune probleme de coerență și complică mult situația dacă aceasta rulează pe un cluster. Deși e mai lent ca o soluție locală, lentoarea unui RDBMS este în general mai mare, deci aici intervine modul potrivit de utilizare al memcached. S-ar putea utiliza și instanțele pe care rulează efectiv aplicația, dar în acest caz, adăugarea de capacitate devine dificilă. Auto Scaling (folosind strict uneltele Amazon EC2) devine imposibil. Deci, are sens un cluster extern mașinilor ce rulează aplicația. Și nu, nu vreau să aud de cluster file system. Introduce mai multe probleme decât rezolvă și spun asta pe cuvând de cercetaș. Iar Auto Scaling nu este musai să fie acel nume pompos de marketing ce îi face pe unii să creadă că au scăpat de “capacity planning” sau că e o soluție auto-magică la problemele de scalabilitate. Cel mai civilizat mod de utilizare este acela de a menține un număr minim de instanțe de un anume tip să fie “up and running”.

Să dau și o listă de cerințe.

OS cu suport îndelungat
32-bit
Configurație minimală
Mod de adresare fix

Să le iau pe rând.

Ubuntu 10.04 LTS este potrivit obiectivului stabilit. Canonical oferă 5 ani de actualizări pentru versiunile de server LTS . În plus, Canonical oferă AMI oficiale pe care le menține, deci pe lângă base system și userland, sunt asigurate și actualizările pentru kernel.
Pentru că 64-bit nu aduce un plus de performanță, doar mai mult “overhead” pentru memorie. Deci nu merită efortul de a construi o imagine pentru 64-bit. De la t1.micro pe 64-bit se poate face upgrade doar la instanță m1.large, deci costurile cresc pe măsură iar aplicația trebuie să fie una destul de mare ca să necesite asemenea capacități de memorie pentru un cluster de caching. În același timp, dacă management-ul unui cluster t1.small pe 32-bit devine prea complicat (deși nu ar trebui să fie cu uneltele potrivite), se poate trece la m1.small, deși se primește mai puțin “bang for the buck”.
Deși imaginile Canonical sunt destul de subțiri (ideea de JeOS), au totuși prea multe servicii ce rulează în mod implicit și rulează degeaba. În plus, deși în prezent nu mai vin cu un root EBS de 15GiB (de când s-a introdus acel “free tier”), au totuși un root EBS de 8GiB. La exemplul meu inițial cu 4 instanțe, să zicem că 6GiB sunt aproximativ degeaba. 2GiB pentru o instanță memcached sunt suficienți. Într-un an, acei 24GiB de EBS storage nefolosiți practic, se traduc într-un cost suplimentar de $28.8. Nu este mult ținând cont de prețul altor servicii, dar se adună acolo iar cum Amazon au obiceiul să pună taxă pe absolut cel mai mic detaliu, optimizez în această direcție. Pentru că pot.
Amazon EC2 în mod implicit are un mod de adresare a mașinilor folosind adrese ce se pot schimba. Pentru a elimina reconfigurarea aplicației, Elastic IP vine în ajutor, dar nu în modul intuit de oricine. Modul implicit presupune costuri suplimentare ce se pot rezolva.

1+2. Ubuntu 10.04 LTS 32-bit

Pe alestic se găsesc multe resurse legate de Ubuntu pe EC2. Partea interesantă este acel tabel de pe prima pagină ce listează imaginile oficiale ale Canonical în funcție de zonă, arhitectură și root device. Restul e can-can. O instanță poate fi adusă sus în maxim câteva minute, deci nu o să insist cu partea ușoară a lucrurilor.

3. Configurație minimală

Din moment ce nu insist asupra lucrurilor ușoare, este evident că o să insist asupra celor mai puțin evidente la o primă vedere. Pentru început, subțierea numărului de servicii. Se ia scriptul de mai jos, se trântește într-un *.sh și se execută.

#!/bin/bash
 
if [ $(id -u) -ne 0 ]
then
	echo "Please run me as root."
	exit 1
fi
 
apt-get -y remove --purge consolekit
rm -rf /var/log/ConsoleKit
apt-get -y autoremove --purge
 
function disable_service
{
	if [ -f /etc/init/$1.conf ]
	then
		echo "Disabling $1"
		stop $1
		mv /etc/init/$1.conf /etc/init/$1.conf.noexec
	else
		echo "$1 is already disabled"
	fi
}
 
function map
{
	if [ $# -le 1 ]
	then
		return
	else
		local f=$1
		local x=$2
		shift 2
		local xs=$@
		$f $x
		map "$f" $xs
	fi
}
 
map disable_service atd cron dbus rsyslog tty2 tty3 tty4 tty5 tty6
 
cpucount=$(grep -c 'model name' /proc/cpuinfo)
if [ $cpucount -ne 1 ]
then
	echo "You have a multicore system, irqbalance is fine"
else
	disable_service irqbalance
fi

Maniacii ar putea stoarce mai mult cu mingetty vs getty, busybox vs Core Utils și Dropbear în loc de OpenSSH, dar personal nu-mi complic viața atât de mult pentru câțiva megi de RAM. Acestea fiind spuse, se poate trece la faza următoare.

Memoria swap nu există pe t1.micro, dar se poate pune într-un fișier. Personal am optat pentru 256MiB. În mod normal nu ar trebui să se atingă pentru un memcached de 512MiB, dar e mai sigur așa decât un crash de sistem pe spinarea unui OOM error.

dd if=/dev/zero of=/swap bs=1M count=256
mkswap /swap
swapon /swap

Pentru a-l pune la boot, trebuie adăugată următoarea linie în coada lui /etc/fstab:

/swap none swap sw 0 0

Se poate șterge linia aia ce ar trebui să monteze “ceva” în /mnt. t1.micro nu are “ephemeral storage” spre deosebire de instanțele mai mari. Pentru mai multe detalii legate de swap, se poate apela cu încredere la documentație, deși înafară de vm.swappiness nu prea văd ce s-ar putea mânări prin configurare.

Instalarea memcached care în zona ușoară: apt-get install memcached. Configurarea presupune editarea lui /etc/memcached.conf și anume -m 64 modificat în -m 512, comentată linia cu -l 127.0.0.1 și restart la serviciu cu /etc/init.d/memcached restart. Cei îngrijorați de faptul că se ascultă pe interfața “externă” pot să stea liniștiți atâta timp cât n-au un Security Group configurat cu picioarele iar 11211 nu e port public.

Recomand instalarea lui ntp pentru a minimiza problemele legate de timp în sistem. apt-get install ntp și se poate uita de faptul că a fost instalat.

Opțional se poate instala și monit pentru a avea un polițai ce să țină un ochi pe celelalte servicii. Personal îl folosesc cu următoarea configurare:

set daemon 60 with start delay 120
set eventqueue basedir /var/monit slots 256
set logfile /var/log/monit.log
include /etc/monit/conf.d/*

Nu mi-am bătut capul cu email reporting aka să instalez și un MTA (sendmail sau echivalent). De fapt totul e minimal. În conf.d am următoarele:

 # fișierul memcached
check process memcached with pidfile /var/run/memcached.pid
start = "/etc/init.d/memcached start"
stop = "/etc/init.d/memcached stop"
if failed host 127.0.0.1 port 11211 type TCP then restart
if 5 restarts within 5 cycles then timeout
 
# fișierul ntp
check process ntpd with pidfile /var/run/ntpd.pid
start program = "/etc/init.d/ntp start"
stop  program = "/etc/init.d/ntp stop"
if failed host 127.0.0.1 port 123 type UDP then restart
if 5 restarts within 5 cycles then timeout
 
# fișierul ssh
check process sshd with pidfile /var/run/sshd.pid
start program "/etc/init.d/ssh start"
stop program "/etc/init.d/ssh stop"
if failed port 22 protocol SSH then restart
if 5 restarts within 5 cycles then timeout

Acum ajung la partea cu disk space-ul minimal pentru root EBS. Amazon cere bani pentru spațiul rezervat, nu pentru spațiul utilizat. Un sistem complet instalat, cu swap de 256MiB și cache apt gol (apt-get clean) ocupă în jur de 894MiB. Am zis 2GiB pentru siguranță și eventualele upgrade-uri mai mari. Deși nu e “rocket science”, este totuși o procedură puțin mai dificilă față de majoritatea operațiilor. Recomand salvarea setup-ului de până acum ca AMI pentru a avea un backup în caz de erori și a nu fi nevoit să repeți toți pașii de mai sus. Personal, folosesc următoarea metodă:

aminame="image-name"
volumeid="vol-volume-id"
snapshotid=$(ec2-create-snapshot "$volumeid" | cut -f2)
kernel="aki-kernel-id" # Spre exemplu pentru 2.6.32-311 este aki-407d9529
 
while ec2-describe-snapshots "$snapshotid" | grep -q pending
do
	echo -n .
	sleep 5
done
 
ec2-register --architecture i386 --name "$aminame" --snapshot "$snapshotid" --kernel "$kernel"

Metoda de mai sus se va folosi și pentru a salva AMI-ul final. Deci nu o să o mai repet.

Partea de resize presupune o nouă instanță la care se va atașa root EBS-ul instanței folosite până în prezent din moment ce nu se poate edita un filesystem montat. Deci se oprește instanța pe care s-a lucrat până acum. EBS-ul se detașează tot din EC2 API Tools:

auxinstanceid='i-instance-id-aux'
ec2-stop-instances $instanceid
while ! ec2-detach-volume $volumeid; do sleep 5; done
ec2-attach-volume --instance $auxinstanceid --device /dev/sdf $volumeid

$auxinstance – așa am botezat noua instață auxiliară pe care se va face resize-ul. Se purcede la micșorarea filesystem-ului existent:

fsck -n /dev/sdf # device-ul montat pe $auxinstance, dacă e totul OK se merge mai departe
tune2fs -O ^has_journal /dev/sdf # se oprește jurnalul - practic partiția devine una ext2
e2fsck -f /dev/sdf
resize2fs /dev/sdf 1500M # aici nu are dimensiunea finală, dar am pus mai mic ca să nu am probleme mai încolo
fsck -n /dev/sdf
tune2fs -j /dev/sdf

După aceasta am creat noul disk de 2GiB pe care să-l atașez lui $auxinstance ca /dev/sdg. De îndată ce noul disk este montat, se poate copia de pe vechiul disk:

dd if=/dev/sdf ibs=16M of=/dev/sdg obs=16M count=128
resize2fs -p /dev/sdg
e2fsck -f /dev/sdg

Este nevoie de aceasta deoarece Amazon nu permite să se creeze un disk mai mic decât snapshot-ul de bază, deci metoda directă: snapshot – create new smaller disk – nu convine. Ambele volume se pot detașa de instanța auxiliară. Noul volum mai mic se va atașa la vechea instanță de bază. Dacă totul e OK, și ar trebui să fie dacă la acele (e2)fsck nu a dat erori, atunci o să pornească instanța pe disk-ul mai mic. Se poate verifica ușor cu df -h. După aceasta se poate creea un AMI pornind de la această instanță și folosind metoda descrisă anterior pentru salvarea unui AMI intermediar.

4. Adresare fixă prin rețeaua internă

Elastic IP-ul este prin definiție public. Adică cel puțin peste tot apare ca fiind un IP public. Din moment ce protocolul memcached nu are autentificare în mod implicit, complică problema și prin faptul că trebuie făcut un firewall pe fiecare instanță ce să țină cont de acest aspect, problemă ce poate pune bețe în roate unui auto-scaling (sau să-l complice foarte mult). În același timp, memcached folosește client side clustering, deci ordinea de adresare a serverelor și adresarea fixă este esențială.

Amazon ar putea oferi un subdomeniu fix ce ține de instanță nu de adresă. Chestia asta ar rezolva problema cel puțin parțial (depinde de context). Cu toate acestea (încă?) n-am văzut astfel de implementare. Ar reduce necesitățile de Elastic IP ce au un număr limitat de 5 per cont, după care trebuie cerută creșterea acestei limite. Cererea nu costă, dar este enervant atunci când se epuizează spațiul de adrese disponibil.

De ce am pomenit de DNS? Simplu. Adresele acelea de Amazon, spre exemplu 1.1.1.1 au atașate un subdomeniu: ec2-1-1-1-1.compute-1.amazonaws.com. Rezolvat din afara rețelei Amazon, acesta va returna 1.1.1.1. Magia se întâmplă în interiorul rețelei Amazon, unde rezolvarea lui ec2-1-1-1-1.compute-1.amazonaws.com se face către adresa internă a serverului, spre exemplu 10.0.0.1. Elastic IP se supune acestei reguli. Folosirea unui Security Group reduce pacostea de a configura dinamic un firewall deoarece mașinile parte a unui grup pot comunica nerestricționat între ele folosind rețeaua internă, cu condiția ca acel grup să conțină o referință către sine. Iar traficul intern, spre deosebire de cel extern, nu este contorizat și facturat. Deci, clientul memcached, dacă se conectează la două mașini, spre exemplu 1.1.1.1 și 1.1.1.2 va folosi adresele ec2-1-1-1-1.compute-1.amazonaws.com și ec2-1-1-1-2.compute-1.amazonaws.com ce vor rezolva adresa internă. Dacă o mașină este oprită, IP-ul intern alocat se va schimba. Deasemenea acest lucru se va întâmpla și dacă se înlocuiește instanța din spatele acelui Elastic IP. Ori, folosind strategia anterioară, aplicația client nu va trebui modificată cu nimic. Totul se face transparent, în spatele scenei.

Câteva referințe:

http://www.howtoforge.com/linux_resizing_ext3_partitions
http://alestic.com/2010/02/ec2-resize-running-ebs-root
http://serverfault.com/questions/183552/shrinking-amazon-ebs-volume-size

Instalarea phpUnit sub Windows 7 / Zend Server Community Edition

2011-03-03T13:02:35Z

Ca de obicei, PHP sub Windows reușește prin varii metode să dea cu mucii în fasole. Anumite chestii ar trebui să meargă OOTB în teorie. În practică apar dificultăți.

În primul rând am golit directorul C:\Program Files (x86)\Zend\ZendServer\bin\PEAR de toate mizeriile mai puțin go-pear.phar, din varii motive, oricum era un “fresh install” de Zend Server CE. C:\Program Files pentru cei ce încă trag cu dinții de 32-bit. După care am purces, folosind un shell rulat sub Administrator:

cd C:\Program Files (x86)\Zend\ZendServer\bin
php -dphar.require_hash=0 PEAR\go-pear.phar
pear channel-update pear.php.net
pear upgrade PEAR
pear channel-discover pear.phpunit.de
pear channel-discover components.ez.no
pear channel-discover pear.symfony-project.com
pear install --alldeps phpunit/PHPUnit

PEAR_ENV.reg se generează în C:\Program Files (x86)\Zend\ZendServer\bin. Se adaugă în registru la un simplu dublu click. Rulat sub un simplu user:

C:\Users\SaltwaterC>phpunit
PHPUnit 3.5.11 by Sebastian Bergmann.
 
Usage: phpunit [switches] UnitTest [UnitTest.php]
[...]

Restul e can-can.

Update / Disclaimer: în cazul în care n-am fost suficient de explicit, este vorba de Zend Server Community Edition ca distribuție pe post de purtător de vină. Nu este vorba de PHP / Windows. Dar cum Zend susțin faptul lor că distribuția lor de PHP este “certificată”, “production & development ready”, ca tot omul mă aștept ca anumită funcționalitate să funcționeze fără flotări logice.

Eroarea ține de faptul că o arhivă PHAR are o semnătură ce e fie invalidă, fie lipsește în cazul distribuției respective iar PHP dă un warning și refuză instalarea. Motiv pentru care se aplică la runtime flag-ul phar.require_hash=0. Nu știu dacă e lipsă sau e invalidă, puțin mă interesează. Faptul că installer-ul PEAR din distribuție este vechi a fost doar un bonus. 2008-05-17 – în changelog această dată apare alături de versiunea 1.7.2 pe care o dă Zend “de bună” în ultima versiune, 5.0.4. Scuza că e un pachet comunitar iar dacă nu-mi convine pot să dau $xxxx pentru versiunea comercială nu ține din moment ce Zend se laudă a fi “The PHP Company”. Da, mă deranjează teribil ipocrizia din industria software.

Personal am încetat să mai discut cu cei de la Zend probleme ce țin de anumite alegeri cretine pe care le fac în distribuția lor. Sunt grei de cap și încăpățânați. Singura “victorie” din partea mea a fost includerea unei valori predefinite pentru sendmail_path în distribuția standard. Vezi acest post de prin 2009. Aceasta după ce a trebuit să depun efoturi ca să le explic faptul că /usr/sbin/sendmail este standard pentru toate distribuțiile majore și să mă lupt cu astfel de răspunsuri, după ce ei susțineau sus și tare că nu e nici un bug de configurație faptul că sendmail_path e invalid, deși există n-implementări de MTA ce oferă compatibilitate cu sendmail (personal folosesc postfix, deși postfix pe lângă MTA are și un server SMTP). Ca după aceea să o rezolve până la urmă și să pună un articol pe KB. Îmi este greu să urmăresc logica de a rezolva o problemă pe care inițial susțineai că nu o ai în loc să te ridici de pe curul puturos și să verfici.

Singurul motiv pentru care încă tolerez această distribuție este faptul că oferă pachete binare decente precum update-uri la versiunea de PHP, spre deosebire de anumite distribuții Linux ce au version lock, partea de backports e aproximativ inexistentă, iar un 3rd party oferă mai puțină încredere. Iar ca sysadmin am și altceva de făcut înafară de presupunerea că aș sta să-mi compilez singur serviciile. O fac atunci când nu am alternativă. Chiar și versiunea de PHP din Ubuntu Lucid este jenant configurată, are bug-uri prin ini-uri, etc. Dar măcar ăia nu emit pretenții de distribuție “certificată”.

Având în vedere experiențele proaste cu Zend, slabe șanse să le cumpăr vreodată vreun produs sau să-mi iau “certificare” de la ei din moment ce distribuțiile lor “certificate” nu îndeplinesc un minim nivel al bunului simț.

phbench – PHP Benchmark Test

2011-02-19T16:01:41Z

Obișnuiam să testez varii implementări de stive PHP. Îmi doream un test ceva mai complex ce să vizeze strict PHP. Din nefericire majoritatea chestiilor pe care le-am găsit erau fie prea simple (testau doar operații matematice în bună parte), fie erau prea dificil de instalat. Iar chestiile dificil de instalat nu sunt de mine atunci când vine vorba de munci de astea simple.

La un moment dat am scris phbench, o astfel de soluție, dar rezultatele erau prezentate într-o formă destul de dificilă pentru teste ceva mai îndelungate. Din fericire, mi-a trecut lenea și am rescris complet aplicația, păstrând ideea inițială. Iar acum mi-a trecut lenea de a anunța faptul că de aproape o lună am pus sus noua versiune, de care nu știe nici naiba pentru că nu am mai vorbit de phbench de o vreme. Și am rescris-o folosind Kohana Framework. Iar de această dată este mult mai utilizabilă din moment ce are o interfață AJAX iar rezultatele sunt detaliate și centralizate de către aplicația în sine.

Spre deosebire de versiunea anterioară, lipsește interfața CLI, deși nu știu dacă o voi mai implementa vreodată. De cele mai multe ori am fost pus în situația să-mi pese de cum se mișcă PHP în server side și aproape deloc de cum se mișcă PHP pentru o aplicație CLI.

Printre altele, este și un mini-framework pentru a scrie alte teste. Un nou test este practic o clasă ce respectă niște reguli prestabilite, detaliate în README. Se integrează direct în suportul existent, fără a face configurări de interfațare. phbench folosește reflection pentru aceasta. Sunt deschis la sugestii pentru a include noi teste în distribuția oficială. Cu toate acestea, am evitat teste ce folosesc API-uri externe (gen MySQL, cURL) din moment ce sunt influențate de serverul la care se conectează. Eventual voi face o categorie de teste opționale ce se vor putea include în teste ce pot fi făcute relevante (exemplu: să se conecteze la același server MySQL în teste). Printre altele, deși proiectul nu este o prioritate a mea, voi implementa chestii minore (și mai am vreo 2-3 idei pe rol pentru interfață).

Download.

Și un screenshot:

VirtualBox ca serviciu de sistem

2011-01-26T19:50:32Z

M-am lovit în mod repetitiv de problema rulării VirtualBox ca serviciu, dar până acum niciodată nu am fost mulțumit de soluție. Majoritatea scripturilor de init pe care le găseam aiurea în tramvai pe Internet făceau parte din categoria acelor scripturi ce necesită un serviciu per mașină virtuală. Iar cum subsemnatul e comod din fire și n-are chef să facă clasicul:

cp vboxservice-template vboxservice-machine-name
nano vboxservice-machine-name
# write all that machine dependent junk, save
update-rc.d vboxservice-machine-name defaults

a inventat o soluție. Posibil nu cea mai bună, dar simplu de utilizat, implementat, extins. Stau și mă gândesc cum naiba geniile de pe “Teh Internets” n-au fost în stare să găsească o soluție mai rumegabilă până acum. Iar prin rumegabilă mă refer să abstractizeze un proces repetitiv iar ca parametru să fie un ID de mașină. Deci am luat o copie de /etc/init.d/skeleton și am purces la modificat. Ce-a ieșit, e downloadabil aici.

Acest articol folosește și pe post de manual, deși nu e mare scofală.

Pentru instalare se ia scriptul de mai sus, se trântește în /etc/init.d/ și se activează cu:

chmod +x /etc/init.d/vbox-machines
update-rc.d vbox-machines defaults

Metoda de mai sus este valabilă pentru Debian & friends. Cu toate că bâzâie ceva mizerii despre LSB, n-am încercat pe alte nații de distribuții, deci nu garantez că funcționează, chiar dacă nu mai este nici o referință la start-stop-daemon, tipic pentru Debian și gașca.

În mod implicit utilizatorul sub care rulează mașinile e root. Se poate modifica prin metoda standard de a edita parametrii din scripturile de Debian init:

nano /etc/default/vbox-machines

și se adaugă

CONTROL_USER=virtualbox

unde virtualbox este utilizatorul sub care se intenționează să se lanseze mașina virtuală. Evident, nu trebuie să fie acesta. Aceasta s-a implementat pentru a minimiza editările la nivel de script de init și pentru a avea bucuria sufletească a faptului de a fi câtuși de cât “standards compliant”.

Cam atât pe partea de instalare de serviciu. Dacă nu există directorul /etc/vbox.d/, o să aibă el grijă să zbiere. Pentru a-l face funcțional, se pun în directorul anterior fișiere cu nume identic cu cel al ID-urilor de mașină virtuală. Practic acel ID e un UUID ce se găsește în XML-ul de configurare al mașinii, fișier ce se găsește pe undeva pe aici:

/home/virtualbox/.VirtualBox/Machines/Machine Name/Machine Name.xml

în funcție de utilizatorul folosit și mașina creată (exemplul de aici: Machine Name).

Tehnic vorbind, în abstract s-ar putea folosi și numele mașinii în loc de UUID, dar dacă are spații în nume, gen “Retard OS RTM VM”, atunci este problematic, cu toate că sintaxa VBoxManage acceptă și numele mașinii în loc de UUID, iar serviciul subsemnatului pescuiește numele de pe disk și nu face mofturi la formă. Face mofturi la faptul că un spațiu primește escaping pe undeva pe acolo și la execuția lui VBoxManage for fi mizerii prin comandă. Mi-e mult prea lene să-l fac panaceu. Oricum acel UUID se găsește pe linia numărul 3 din fișier, iar un simplu:

touch /etc/vbox.d/uuid-of-the-machine

activează pornirea / oprirea automată. În plus, phpVirtualBox este un proiect genial, recomandat chiar de către Oracle pe pagina lui VirtualBox iar subsemnatul intenționează să creeze / șteargă acele fișiere ce se integrează cu serviciul meu direct din interfața acestuia. Mai bine fac scurtă la click decât scurtă la taste. Îmi mai trebuie doar chef să fac un patch pentru phpVirtualBox.

PS: ar mai fi de adăugat un mic detaliu elementar și anume faptul că mașina nu e oprită la stop, ci se folosește “savestate”, mai mult din motive ce țin de VirtualBox și mai puțin de opțiune personală. Pentru un shutdown, se recomandă metoda standard a sistemului de operare ce este găzduit.

Ca actualizare de ultimă oră: este nevoie ca un serviciu de VirtualBox să ruleze în prealabil. Datorită faptului că aveam un init script pentru VirtualBox web service, scriptul meu funcționa. În pachetul standard de la Oracle, vine un serviciu vboxdrv. Pentru funcționare corectă, serviciul meu trebuie să ruleze după acesta, deci fie scriptului din init.d i se dă un nume ce în ordinea lexicografică este după vboxdrv sau se mânărește prin update-rc.d sau scripturi de startup în funcție de runlevel / prioritate la pornire.

Filtru pentru mesaje necitite în Gmail

2010-11-11T16:10:00Z

De ceva vreme am depus eforturi substanțiale pentru a-mi muta tot emailul către Gmail, sătul fiind de varii clienți desktop și din dorința de a mă atașa acestui trend: de pe desktop pe web. Din nefericire, Gmail nu oferă o metodă de filtrare a mailurilor necitite. Așa ca pentru proști (a se citi un buton). Deci am purces către un mic research. Soluția este cretin de simplă, dar în sensul în care un UNIX shell este simplu pentru cei ce știu, nu pentru afoni.

În câmpul de căutare din Gmail se introduce: label:unread. Voila, apar doar mailurile necitite. Restul e can-can.

Pentru Internet Explorer

2010-11-11T16:16:00Z

Aplicaţia de plată este optimizată pentru Internet Explorer.
Vă recomandăm să nu utilizaţi alte browsere, deoarece tranzacţia de plată poate fi întreruptă înainte de finalizare.

Aceasta este metoda de a spune pe o limbă eufemistică: programatorii la care am apelat sunt niște incompetenți ce nu sunt în stare să implementeze un modul de plată și pe alte browsere. Iar cei de la Electrica Furnizare Transilvania Sud cu acel site jenant insistă pe această carte. De parcă toată lumea are Internet Explorer. Sau de parcă toată lumea care-l are chiar vrea să-l folosească.

Wikipedia ne anunță faptul că IE o cam ia la vale de ceva vreme.

Dar evident, niște dinozauri de la Electrica par să nu țină cont de acest aspect. Ba mai mult, tratează problema cu cel mai pur românism, pardon, indiferență, așa cum a fost tratat și mailul subsemnatului trimis prin formularul de contact, în legătură cu acest aspect.

Ultimul cui în grindă este faptul că aplicația de mai sus este scrisă-n PHP, ce între noi fie vorba rulează mai bine sub *nix. Dacă IIS 7.x (nu acel 6.0 folosit de către EFTS) e decent, PHP sub Windows nu mă convinge. Am mai zis-o și o mai zic. Atâta timp cât o să fie valabilă.

mysqldump cu rename

2010-10-12T11:53:00Z

O chestie ce lipsește de multicel în mysqldump este opțiunea de a putea da un “rename” la o bază de date în fișierul de dump. Din moment ce nu pot aștepta la infinit pentru ca acest lucru să apară în versiunea standard, rămân două alternative:

aplicații de dump ce știu deja să facă aceasta
un pic de lucru cu sed prin fișierul de dump

Din moment ce nu am găsit decât o chestie în Python ce nu știu exact ce face, am ales a doua variantă, ceva mai rumegabilă. Să zicem că am scriptul dbdump în directorul curent, cu privilegiu de execuție:

#!/bin/sh
mysqldump -u $1 -B $2 --skip-comments -xvnp > $3.sql
sed -i "s/USE \`$2\`;/USE \`$3\`;/g" $3.sql
pbzip2 -fv $3.sql

Invocarea este simplă: ./dbdump mysql_username database_to_dump new_name

Mai departe face totul de unul singur. Dă dump, modifică numele bazei de date și face o compresie cu pbzip2 (Parallel bzip2). Se poate modifica să funcționeze cu bzip2 standard, dar pe servere multi-core și / sau multi-procesor merită efortul de a instala pbzip2.

Opțional, pentru puturoși precum subsemnatul, se mai poate trânti o linie în script ce să mute arhiva pe noul server:

scp -i transfer.pem $3.sql.bz2 transfer@example.com:$3.sql.bz2

Am pus sintaxa pentru oameni plictisiți de parole de SSH, recte subsemnatul, folosind o cheie privată. Nu e musai, dar e mai comod, în special dacă sunt mai multe baze de date de transferat.

Lookup Table în PHP

2010-09-22T16:05:57Z

Problema implementării unui lookup table pare uneori simplă. În cazul în care se implementează ca un array indexat, iar obținerea unei valori se face prin metoda dă-mi valoarea Y de la cheia X, atunci problemele de performanță nu intervin.

M-am lovit de altă bubă, și anume implementarea unui lookup table simplu bazat pe căutare liniară construit pe baza unui pre-fetch. Ideea este simplu de implementat, și deși procesul respectiv nu rulează prea des, numărul valorilor distincte complică problema destul de mult. Într-un lookup table de 70.000 – 80.000 valori căutarea unui număr mai mare de valori durează peste jumătate de oră (nu știu exact, am oprit benchmark-ul după 30 minute) cu procesorul (sau un core) la ~100% load, pe când restul operațiilor se execută în secunde. Cam multicel pentru o căutare ce ar trebui să returneze TRUE / FALSE. Faptul că numărul de căutări este mai mare decât lookup table-ul în sine mai bate un cui în coșciugul metodei de mai sus. Se mai adaugă și faptul că deși în teorie valorie ar trebui să fie unice, datele din pre-fetch nu sunt neapărat validate în acest sens.

Pre-fetch – pseudo implementare

$haystack = array();
while($value = get_data())
{
	$haystack[] = $value;
}

Ideea este simplă. Stiva $haystack va conține toate valorile, inclusiv cele duplicat. Mă rog, pre-fetch-ul implementează ideea de “stivă” pentru că auto-indexarea cu [] are aceeași funcționalitate ca și array_push(), dar câștigă puțin la viteza de inserare a datelor. Durează câteva secunde, nu este o operație foarte complexă. De aici începe greul.

Căutare – implementare uzuală

Există tentația de a face căutarea pe baza lui in_array() sau array_search(). Ambele sunt aproximativ la fel de rapide (in_array() este cu maxim 1% mai lentă). Problema principală este căutarea liniară, fără indexare.

Dau chiar exemplele din codul meu de benchmark:

	public function bench_in_array($needle)
	{
		return in_array($needle, $this->haystack);
	}
 
	public function bench_array_search($needle)
	{
		if (array_search($needle, $this->haystack) === FALSE)
			return FALSE;
		return TRUE;
	}

Căutare – soluția optimă

Ambele soluții anterioare sunt aproximativ la fel de rapide, dar aproximativ la fel de lente. Interesul este dacă există o valoare. Duplicatele doar încurcă.

$haystack = array_flip($haystack);

Inversează valoarea cu cheile dintr-un array. Valorile duplicat dispar din moment ce un array (mă rog, devine ordered map) nu poate avea chei duplicat. Se pot aplica alte două metode distincte. Dau din nou exemplu din codul meu de benchmark:

	public function bench_array_flip_isset($needle)
	{
		return isset($this->flipped_haystack[$needle]);
	}
 
	public function bench_array_flip_array_key_exists($needle)
	{
		return array_key_exists($needle, $this->flipped_haystack);
	}

Pentru o listă de $needle scurtă (1% din $haystack, valori 100% valide), sunt aproximativ echivalente. Pentru un input 50% valid de dimensiunea $haystack, array_key_exists() este cu aproximativ 80% – 100% mai lent. Dar acum urmează partea frumoasă: căutarea se face indexat. Metoda este de cel puțin 2000 ori mai rapidă decât căutarea cu in_array() / array_search(). Adică în mod uzual căutarea de mai devreme de peste jumatate de oră durează aproximativ sub 3 secunde cu isset() și sub 5 secunde cu array_key_search(). Metodă testată pe un lookup table de 100.000 valori ce mi-a cam ucis browserul. Chrome a crăpat, Firefox a încărcat output-ul de la Codebench în vreo 3.5 GiB RAM. Atașez și imagini ce stau dovadă atrocității de mai devreme.

Parole aleatoare în Linux, “extended ASCII”

2010-08-09T15:47:33Z

Deși în teorie problema din titlu este una rezolvată, în practică de multe ori mi-am dorit o parolă de o complexitate mai mare față de ce-mi oferă majoritatea uneltelor ce nu ies din standard ASCII. Prin metoda subsemnatului, se ia următoarea funcție și se trântește în .bashrc:

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

Căi UNIX corecte în PHP

2010-06-05T16:17:21Z

Se dă următoarea problemă, aparent mai simplă decât zice titlul: să se determine dacă o cale de tip UNIX este corectă. Buba este faptul că această cale poate să fie către un fișier ce nu există, spre exemplu o cale de UNIX socket ce va fi creat într-un director ce va conține un pool de socket-uri. Deci funcțiile la nivel de filesystem nu vor ajuta, cel puțin nu în primă fază. În cazul în care există vreo încercare de intuiție a scopului, da, scriu server scripting și în PHP. *sh este prea limitat pentru anumite chestii mai avansate, sau are nevoie de prea mult “boilerplate code”, pe când în Perl nu sunt încă fluent. Pentru cei ce au pierdut știrile de la ora 5, PHP nu mai este de mult un limbaj strict “web oriented”, funcționează bine merci și pentru “general purpose”.

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.

SopCast sub Linux

2010-06-03T10:49:32Z

Probabil că te întrebi ce e ăla SopCast. Pe scurt, este un protocol de TV streaming, bazat pe un protocol de tip P2P, sop. Problema cea mai mare sub Linux sunt acei incompetenți proprietari de site-uri ce oferă suport pentru acest protocol doar folosind versiunea de Windows pentru SopCast, sau alte chestii plus WMP. Și doar IE, majoritatea cer exclusiv IE, deși s-a făcut și o extensie de Firefox pentru a putea viziona un stream sop și fără a folosi IE direct de pe web.

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.

G-WAN – acceleratorul de web

2010-11-11T16:16:31Z

Deși titlul pare forțat, proiectul pomenit acolo are un potențial mare atâta timp cât este utilizat cum trebuie. Singurele probleme sunt toate aceste primadone, așa zișii programatori auto-proclamați, ce maxim au idee despre despre ceva scripting într-un limbaj cu tipuri dinamice de date, dar în momentul în care vine vorba de muncă adevărată sau a proiecta un algoritm, dispar. Nu susțin faptul că sunt marele guru ce s-a născut cu tastatura în mână, nu sunt fluent în ANSI C, căci despre acesta este vorba, dar (pe testate) am putut observa potențialul unei astfel de soluții. Deci se adresează programatorilor. Programatorilor ce nu se ascund de pointeri (pe care, recunosc, încă nu-i stăpânesc), programatorilor ce au idee despre cum funcționează platforma pe care rulează aplicația și nu se ascund sub încă un nivel de abstractizare [insert smart-ass name here], etc. Din această categorie recomand “What every programmer should know about memory“, chestie pe care vreau să o parcurg pe îndelete pe când voi avea timp.

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.

Apache 2+mod_fcgid – setup rapid pentru test/dezvoltare

2010-05-25T10:14:08Z

Apache 2 + mod_php, ceea ce în majoritatea cazurilor implică prefork MPM, este un setup cretin. Am spus-o, o mai spun și o susțin, cu toate că acest setup este implicit sub *nix. Dacă memoria este oarecum un lux, sau nu ai trecut deja pe un web server cu o arhitectură asincronă, atunci agonia cu Apache se mai poate prelungi puțin, apelând la worker MPM + mod_fcgid + PHP rulat ca FastCGI. O să fac doar o scurtă mențiune despre faptul că arhitectura multiproces / multithread din punctul de vedere al scalabilității este moartă, oricât ai face “yet another Apache smart-ass tweak”. Problema nu este în viteza efectivă a soft-ului ci în arhitectura în sine. Să mai zic ceva de Slowloris?

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.

Ubuntu și network management-ul

2010-05-21T23:08:37Z

De când mă știu Ubuntu (și distribuțiile ce vin cu Gnome în general) au un management de rețea de-a dreptul cretin în interfața grafică, iar Ubuntu 10.04 nu face excepție. Problema mea cea mai mare este conectivitatea wireless dacă folosesc un access point ce nu are suport pentru DHCP. Configurarea este de-a dreptul imposibilă, sau are o metodă necunoscută mie, deși sub interfața aparent simplă, posibilitatea de a mă conecta cu o conexiune predefinită lipsește cu desăvârșire.

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.

Ubuntu 10.04 Lucid Lynx și OpenVZ

2010-05-13T06:37:35Z

Vestea bună este faptul că a apărut Ubuntu 10.04. Vestea proastă este faptul că suportul pentru OpenVZ în kernel 2.6.32 a apărut prea târziu pentru a fi inclus în distribuție. Sunt conștient de faptul că LXC (Linux Containers) va fi următoarea tehnologie de virtualizare la nivel de sistem de operare. De fapt a fost adoptată în mainline la nivel de kernel. Dar între timp OpenVZ a strâns o comunitate destul de mare și suficiente unelte de administrare pentru a nu îl face bun de aruncat la gunoi în secunda numărul doi. În plus, migrarea de la o tehnologie de virtualizare la alta nu se poate face imediat.

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!

I can has Makavelis numbers

2010-05-14T08:02:23Z

S-a găsit Google Reader să mă scoată cu nasul din shell cu următoarea problemă, dată pe undeva pe aici. Practic rezolvarea problemei:

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

Scanarea disk-urilor sub Linux

2010-04-16T08:49:14Z

O să intru puţin şi în acest subiect. Nu, nu mă refer la chestii de filesystem gen fsck plus familia de prieteni, LVM şi alte avioane, ci la chestii dincolo de date, mai apropiate de fier. Nu oricine deţine un motan idiot ce să folosească un minitower pe post de suprafaţă de frânare, şi să-l dărâme, dar problemele pot apărea şi în stare naturală, “fat free, batteries not included”. Chiar dacă maşina respectivă în timpul impactului era oprita (fapt ce a oferit oportunitatea de a fi dărâmată), cele două disk-uri aveau capetele parcate, conform specificaţiilor suportă acceleraţii de până la 300G dacă sunt staţionate, wonk, wonk, wonk. Ideea simplă este faptul ca pentru a fi sigur de stabilitatea soluţiei, sunt necesare nişte măsuri ulterioare producerii unui eveniment nedorit.

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 Automatic Updates și povestea reboot-ului automat

2010-04-14T17:27:35Z

Începând cu Windows XP SP2 Microsoft a început un trend ce mă scoate din sărite: reboot automat după un automatic update. Deși nu este instantaneu și îți lasă timp de “gândire”, uneori se întâmplă să nu fiu la tastatură pe când se gândește să îmi facă surpriza, sau să îl amân, să mă uit la film și să mă trezesc cu bucuria gata făcută. Sincer nu știu cine este autorul ideii mărețe, dar sper că într-o zi își va da seama de greșeală și se va căi. Între timp, furnizez și o soluție rapidă “bugului” de mai sus. O dau sub formă de registry patch din moment ce nu toate versiunile de Windows includ gpedit.msc (altă idee măreață marca Redmond).

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.

OpenVZ Debian Appliance Builder

2010-03-26T20:22:00Z

Băieții ăștia faini de la Proxmox ce se ocupă de Proxmox VE printre altele, soluția de virtualizare ce o recomandam în articolul anterior pentru testarea de configurații, au mai scos un hit: Debian Appliance Builder, pe scurt dab. Acum să nu se înțeleagă din fraza anterioară faptul că Proxmox VE nu ar fi bun în producție. Cel puțin OVH folosește în producție produsul menționat anterior.

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:

crearea unui fișier de configurare (dab.conf) cu o sintaxă “key: value” relativ simplă, explicată în documentație. Joacă rol de “metadata”.
init – moment în care se citește lista de pachete din repo-urile distribuției alese
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.
[opțional] instalare de pachete suplimentare. Minimalul lor nu corespunde minimalului meu, ce presupune și: htop, sysv-rc-conf, sysvconfig, bzip2.
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.
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™.

Cum să reproduci setup-din din producție – pe local

2010-03-16T10:56:30Z

Problema reproducerii unui setup compatibil din punct de vedere binar este mai simplă decât pare cu condiția să se apeleze la anumite ajutoare, ajutoare de natură virtuală. Este destul de contra-productiv să instalezi un OS de fiecare dată pe când este nevoie de o instanță curată, fie că dispui de o mașină dedicată, fie că folosești un hypervisor local. Știu că în aparență propoziția anterioară contrazice folosirea virtualizării, dar nu am menționat ce tip de hypervisor se recomandă pentru acest obiectiv specific.

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.

Flash-ul lui Adobe și Windows-ul meu Mobile

2010-11-11T16:27:02Z

Update: am corectat puțin articolul în urma dialogului avut mai jos prin comentarii. Pe scurt, am calmat tonul frustrat abordat inițial, făra a altera complet forma inițială. Nu mai există sentimentul inițial pe care l-am avut atunci când am scris rândurile de mai jos. Până la urmă cei ce se ocupă de partea de comunicare din partea companiei Adobe își iau salariul pe merit din moment ce își “pierd” timpul cu un blog de buzunar ca al meu. Cu toate acestea, aștept rezultatele. Momentan discuția de mai jos rămâne la stadiul de vorbărie, iar eu ca programator nu cred în vorbe ci în software funcțional. De altfel pot trăi fără jocuri Flash pe telefon. Nu intru în sevraj în absența lor. De fapt nu mă joc pe telefon. Afirmația dădea doar o notă de dramatism situației expuse. Experiența web folosind PocketIE, Opera Mobile plus versiunea mobilă a Firefox (codename: Fennec, momentan Alpha stage) lasă de dorit în continuare în unele situații bine determinate unde o mână de CSS + (X)HTML nu pot compensa absența Flash Player. Urarea de la sfârșit rămâne. Înafară de Windows, Flash (încă?) e jale sau nu este deloc.

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

Firebug 1.5 + Firefox 3.5.7 + Ubuntu Hardy amd64

2010-01-29T08:34:57Z

Firebug este o unealtă indispensabilă activităților de dezvoltare web pe care le execut. Din păcate, actualizările se lasă cu urmări câteodată. Precum zice în titlu, am încercat combinația nefericită de mai sus. Buba stă în Firebug: 64 bit Firefox on Linux crashes with Firebug 1.5.0. Am mers pe firul epic al poveștii de pe issue tracker și mi-am resetat preferințele. Crash-ul reapare atunci când se reactivează tab-ul Net sau Console. Din nefericire, echipa Firebug aruncă vina către Ubuntu, desi eu mi-am făcut propriul build personalizat de Firefox, deci problema cred că zace undeva prin ceva bibliotecă livrată cu Ubuntu din moment ce versiunea de Firefox îmi aparține.

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.

Dragă programatorule, dacă îți vine a copy-paste, fă refactor!

2010-01-22T11:41:45Z

M-am săturat de cod prost scris ca de mere pădurețe. Nu mă refer la cod nefuncțional sau cu bug-uri. Mă refer la metodologia copy-paste la care se apelează intensiv din când în când. După care apucă-te și modifică ceva pentru a adăuga chestii noi. M-am săturat de gândire non-DRY datorită căreia apuc să modific în 5 locuri și 3 fișiere pentru a pune o chestie amărâtă care să arate la fel peste tot. În concluzie, pe lângă defularea de mai sus, m-am hotărât să mai dau niște idei.

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.