PHPRecentemente mi sono trovato a dovere simulare il comportamendo di un browser interagendo con un web server in PHP. L’obiettivo dello script PHP che si stava facendo era quello di simulare il caricamento in POST di un documento. L’obiettivo è facilmente raggiungibile in PHP tramite le librerie CURL. Cercando su internet si trovano numerosi esempi da cui se ne deduce che l’uso-tipo è il seguente:


/* L'url a cui inviare il POST */
$request_url = "http://www.ciccio.com/upload.php";

/* Indico a CURL quale sia il file da inviare:
 * nel form c'è un <input type="file" name="FileUP" /> */
$post_params['FileUP'] = "@/home/io/TestPdf2.pdf";

/* Nel Form ho un qualsivoglia altro parametro da passare
 * in post */
$post_params['AltroParametro'] = "Ezekiel";

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $request_url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, $post_params);
curl_setopt($ch, CURLOPT_VERBOSE, TRUE);
$result = curl_exec($ch);
curl_close($ch);

Il trucco sta nello specificare con la @ davanti il nome del file da inviare: in questo modo CURL capisce che parliamo di un file e si regola di conseguenza. Tutto ha funzionato bene fino a che non ho provato ad eseguire lo stesso codice da dietro SQUID in modalità trasparente, che ha iniziato a rispondermi “Invalid request”. Dopo ore ed ore di tentativi (inutili), ho scoperto che il punto è molto semplice: CURL utilizza un’intestazione HTTP non supportata da Squid, la “Expect: 100-continue”. Per impedire questo comportamento è sufficiente aggiungere un’opzione:

curl_setopt($ch, CURLOPT_HTTPHEADER, array('Expect:'));

E tutto magicamente funzionerà.

 

Al fine di superare eventuali blocchi topologici, o semplicemente per ottimizzare l’utilizzo della connessione ad internet è possibile specificare le impostazioni relative ad un server Proxy HTTP ed FTP da usarsi durante le operazioni di compilazione dei Ports.

La cosa è piuttosto semplice: i ports scaricano ogni pacchetto utilizzando l’utility di sistema fetch la quale referenzia due variabili di ambiente per leggere le impostazioni relative ai proxy:

  • HTTP_PROXY
  • FTP_PROXY

Per far si, quindi, che i ports utilizzino il proxy in fase di installazione del software basterà modificare il file RC del proprio profilo (ad esempio .cshrc per l’utente root) aggiungendo le seguenti righe:

setenv HTTP_PROXY http://192.168.1.200:3128/
setenv FTP_PROXY http://192.168.1.200:3128/

Al fine di risolvere alcuni problemi di compatibilità con alcuni software di scuola linux (ad esempio wget) può essere utile specificare le stesse variabili anche in lower-case:

setenv http_proxy http://192.168.1.200:3128/
setenv ftp_proxy http://192.168.1.200:3128/

Da notare, inoltre, che è molto importante specificare le impostazioni del proxy con la sintassi http://utente:password@host:porta/ al fine di specificare che il proxy che si sta utilizzando è di tipo HTTP (ad esempio nel caso di SQUID). Discorso diverso invece qualora si stia utilizzando un ftp-gateway, in tal caso l’impostazione del FTP_PROXY dovrà seguire l’apposita sintassi.

 

Al fine di ottimizzare al massimo i tempi di installazione dei pacchetti scaricati tramite ports e minimizzare i trasferimenti da web, è possibile realizzare una struttura condivisa di gestione della directory distfiles dei ports di FreeBSD.

La directory, normalmente situata in /usr/ports/distfiles, contiene infatti tutti i pacchetti scaricati da internet per effettuare l’installazione dei ports.

La logica alla base dell’ottimizzazione è quella di creare una singola macchina repository che condivida a tutte le altre macchine la directory distfiles. La tecnologia “nativa” per la condivisione delle directory via rete sotto FreeBSD/Unix è l’NFS. La sua configurazione è piuttosto semplice, ed essendo parte del base-system, non richiede alcuna installazione di software aggiuntivo.

Condivisione lato Repository

Per condividere la cartella sulla macchina di Repository sarà sufficiente attivare il servizio nfsserver ed esportare la directory.

Il primo step da effettuare è quello di configurare il file export indicando quali directory si voglia esportare ed a quali server. Il file è situato in /etc/export e la sua sintassi è piuttosto basilare: ogni riga contiene il path da esportare e l’indirizzo IP (o gli indirizzi IP) che potranno accederci. Sarà possibile inoltre specificare alcuni parametri aggiuntivi quali -ro per indicare che l’export debba essere effettuato “read-only”. Nel nostro caso, però, non è così:

/usr/ports/distfiles 192.168.1.10 192.168.1.24 192.168.1.45

A questo punto per attivare il servizio nfsserver bisogna modificare il file /etc/rc.conf aggiungendo le seguenti righe:

rpcbind_enable="YES"
nfs_server_enable="YES"
mountd_flags="-r"

A questo punto per avviare manualmente il server (che comunque si avvierà al reboot della macchina) è sufficiente eseguire:

/etc/rc.d/rpcbind start
/etc/rc.d/nfsserver start
/etc/rc.d/nfsd start

Per verificare di aver effettuato tutto correttamente a questo punto si può eseguire il comando showmount -e che elencherà tutti i filesystem condivisi sull’attuale macchina (nonché chi possa accedere alle condivisioni).

Accesso al Repository

L’accesso al Repository lato client è ancora più semplice: sarà infatti sufficiente attivare il client NFS e provvedere al mount del volume remoto. Per attivare il client NFS bisogna modificare il file /etc/rc.conf aggiungendo le seguenti righe:

nfs_client_enable="YES"

A questo punto per avviare manualmente il client (che comunque si avvierà al reboot della macchina) è sufficiente eseguire:

/etc/rc.d/nfsclient start

Bene, a questo punto è possibile effettuare il mount del volume remoto. Per far ciò la cosa migliore è rinominare l’eventuale vecchia distfiles già presente sul client ed effettuare il mount.

mv /usr/ports/distfiles /usr/ports/distfiles.old
mount <server>:/usr/ports/distfiles /usr/ports/distfiles

Per essere sicuri che il volume remoto venga automaticamente rimontato al boot sarà sufficiente modificare il file /etc/fstab aggiungendo una riga relativa al mount remoto:

<server>:/usr/ports/distfiles /usr/ports/distfiles nfs rw 0 0
 

Ricevuta via mail, me ne sono impunemente e immoralmente appropiato ed ora la ripropongo qui:

L\'home page per la fine del mondo ;)

 

Ho trovato un bug nel novello figlio di Google, Chrome. C’è un problema con la gestione dei buffer di ricezione dei dati quando si utilizza l’autenticazione http con il PHP (e suppongo non solo quello). Se non si abilita l’implicit flush che invia i dati al browser ogni appena disponibili e invece si tenta di bufferizzare un po’ di dati in una volta sola, il browser di Google va in pappa e mostra solo parte dell’output!

Ecco uno script di test che riproduce il problema:

<?

ob_implicit_flush(FALSE);

if (! isset($_SERVER["PHP_AUTH_USER"]))
{
$realm = "Test authentication";
header ('HTTP/1.0 401 Unauthorized');
header ('WWW-Authenticate: Basic realm="'.$realm.'"');

echo “Inserisci qualsiasi cosa”;

die();
}
else
{

for ($x = 0; $x < 10; $x++)
{
echo
“Line ”.$x.“ - Got username: ”.$_SERVER["PHP_AUTH_USER"].“ and password ”.$_SERVER["PHP_AUTH_PW"].“…………..<br>\n”;
}

echo “<BR><BR>Example code<BR><BR>”;

}

?>

Per vederlo in funzione (o in “malfunzione” se preferite) cliccate qui.

 

Buongiorno e grazie per l’acquisto.

Oggi configureremo un cluster di server WEB affinchè sinao in grado di bilanciare le richieste tra i componenti del cluster e garantire un certo livello di alta affidabilità.

Partiamo con gli ingredienti. Servono 3 dicasi tre server: due (presumibilmente potenti) in cluster per erogare il sito web vero e proprio ed un server (presumibilmente più piccolo) per effettuare il balancing delle richieste. Per dirla tutta sui due web server può girarci un qualsiasi server web a partire da Apache 2.0 in poi mentre sul server di balancing avremo bisogno di Apache 2.2 compilato con il supporto per il mod_proxy e mod_proxy_balancer.

Per chi non lo sapesse l’unico sistema operativo degno di essere usato è Freebsd, per cui questo how-to si appoggerà ad esso.

Per il nostro esempio definiamo i due web server come www1 (www1.site.com) e www2 (www2.site.com) mentre la macchina balancer è identificata come www (www-fw.site.com).

Innanzitutto andiamo su www, dentro /usr/ports/www/apache22 e spariamoci un bellissimo make options, all’interno del quale attiveremo tutti i mod_proxy, seguito da un make install che frullerà per parecchi minuti.

cd /usr/ports/www/apache22
make options
make install

A questo punto modifichiamo l’httpd.conf dentro /usr/local/etc/apache22 aggiungendo le seguenti righe:

<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyPass /balancer-manager !
ProxyPass / balancer://mycluster/ stickysession=BALANCEID nofailover=On
ProxyPassReverse / http://www1.site.com/
ProxyPassReverse / http://www2.site.com/
<Proxy balancer://mycluster>
BalancerMember http://www1.site.com route=www1
BalancerMember http://www2.site.com route=www2
ProxySet lbmethod=byrequests
</Proxy>
<Location /balancer-manager>
SetHandler balancer-manager
Order deny,allow
Allow from all
</Location>

A questo punto dentro /etc/rc.conf io suggerisco di attivare lo startup di apache22 al boot e di htcacheclean che fa la pulizia della directory di cache del proxy:

apache22_enable=”YES”
htcacheclean_enable=”YES”

Ok, il balancer è pronto, ora dobbiamo semplicemente istruire i web server affinché in fase di erogazione dei contenuti venga specificato il COOKIE che permette al balancer di riassociare un client al suo server. Dentro l’httpd.conf di ognuno dei due server web incolliamo (nel virtual host che ci interessa o nella location) il seguente codice:

RewriteEngine On
RewriteRule .* – [CO=BALANCEID:balancer.www1:site.com:1440:/]

Attenzione ad impostare correttamente il domain del cookie, il lifetime ed il path. E soprattutto attenti ad aver attivato il mod_rewrite prima di attivare la rewriteengine. E soprattutto sul secondo server cambiate www1 in www2

Ok, restartate tutti e tre gli apache… dovrebbe funzionare.

Buon divertimento.

p.s.:
poi amplio il concetto…

Discover credit card offers
A credit reporting
Georgia loans automobile
Mortgage refinance information site map
Texas home equity loans
Card company credit report
Low credit score loans
Compare credit card offers
Online debt consolidation
Florida renters insurance
Credit immediately online report
Insurance home owner policy
Health insurance ca
Secured debt consolidation
Applications for credit cards
Disability insurance company
Uk lottery national consolidation debt
Insurance life rates
Increasing credit scores
Sub prime auto loan
Home equity loan best rate
Mortgage refinance online
Card credit debt letter settlement
Liberty mutual homeowners insurance
Insurance clinic for sexual health
Credit card debt settlements
Faxless online payday loan
California home mortgage refinance bad credit loan pay
New credit score
Credit card application form
Business credit card offer
Life insurance quotes for adult children
Debt consolidation bad credit
Visa credit card offer
Compare auto insurance
600 credit score
Torn up credit card application
Sears credit card application
American income life insurance
The best credit score
Credit cards online application
Credit card machine paper
Credit repair lawyers
Low cost life insurance
Auto insurance companies
Free credit card machine
New york life insurance
Debt consolidation loan
Illinois free credit report
Automobile insurance ratings of cars
Health insurance after cancer
Credit card offers
Ohio debt consolidation loan
Credit reporting bureau
Hartford life insurance
Student loans apply online
Auto insurance texas
Debt consolidation lender
Unsecured debt consolidation loan
Consolidation loans debt loan
Oregon home equity loan
Card credit debt pay
Bank credit card offers
American modern home insurance company
Disability insurance cost
America card credit debt
Student loan consolidation center
Consolidate student loans
Credit report.com
Transunion credit reporting agency
Bad credit student loans
California home loan mortgage rate refinance
Lower payment debt consolidation ma
Debt settlement program
Idaho home mortgage refinance
Auto insurance
Instant auto loan

 

Da ieri alle 17.00 sono ufficialmente un “VMWare Certified Professional on VI3″.
E buona camicia a tutti.

 

Da sempre sono stato un grande sostenitore di DBMail, un Mail server che ha la peculiarità di appoggiare tutti i suoi dati dentro un DB – mySql, PgSql, SQLite…)

Ultimamente ho avuto la necessità di aggiungere l’autenticazione SMTP al mio Sendmail di base… e mi sono accorto che far interoperare i vari pezzi che compongono la ricetta è più facile di quel che credessi. Eccovi un rapido prontuario.

Innanzitutto come reference sono partito dal FreeBSD Handbook che però faceva l’autenticazione sugli utenti di sistema di FreeBSD.

Comunque ho installato il port security/cyrus-sasl2 avendo cura di selezionare tra i possibili backend di autenticazione mySql.

A questo ho creato /usr/local/lib/sasl2/Sendmail.conf inserendoci dentro:

pwcheck_method: auxprop
auxprop_plugin: sql
sql_engine: mysql
sql_hostnames: localhost
sql_database: dbmail
sql_user: dbmail
sql_passwd: dbmail
sql_select: SELECT passwd FROM dbmail_users WHERE userid = ‘%u@%r’
sql_verbose: yes

Ovviamente al posto di sql_user e sql_password dovrete sostiture utenza e password del vostro dbmail.

A questo punto ho aggiunto ad /etc/make.conf le seguenti righe:

SENDMAIL_CFLAGS=-I/usr/local/include/sasl -DSASL
SENDMAIL_LDFLAGS=-L/usr/local/lib
SENDMAIL_LDADD=-lsasl2

che serviranno ad indicare a Sendmail di caricare le estensioni SASL per l’autenticazione. Di conseguenza dovremo ricompilare Sendmail con tre semplici passi:

cd /usr/src/lib/libsmutil
make cleandir && make obj && make
cd /usr/src/lib/libsm
make cleandir && make obj && make
cd /usr/src/usr.sbin/sendmail
make cleandir && make obj && make && make install

Per attivare le nuove funzionalità modifichiamo il file .cf di sendmail dentro /etc/mail aggiungendo le seguenti righe:

dnl The group needs to be mail in order to read the sasldb2 file
define(`confRUN_AS_USER’,`root:mail’)dnl

dnl set SASL options
TRUST_AUTH_MECH(`GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN’)dnl
define(`confAUTH_MECHANISMS’, `GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN’)dnl

define(`confDONT_BLAME_SENDMAIL’,`GroupReadableSASLDBFile’)dnl

Dovrebbe funzionare :-)

Oct 252007
 

impressionante:

Jun 192007
 

Mi sono ufficialmente innamorato di faucet (http://faucet.vcast.it/) anche se ho il forte timore che, come si suol dire, “durerà poco”.

Ma cos’è, praticamente, Faucet? E’ un videoregistratore virtuale che vi permette di programmare N videoregistrazioni (anche con ripetizione) da uno dei tanti canali satellitari che i signori di Faucet hanno ritenuto interessanti. Dopodiché ognuno ha un suo bel podcast personale da cui può automagicamente (ad esempio con iTunes) scaricarsi ogni giorno ciò che Faucet ha virtual-registrato per lui e vederlo quando più lo aggradi.

Inutile dire che ho già programmato il mio virtualregistratore per registrare ogni puntata di I Love Rock & Roll su All Music (che va in onda alle 23.00 di mercoledì quando difficilmente riesco ad essere davanti alla TV) e Superrock su MTV che va in onda dalle 01.00 alle 02.00 di notte (!!!impossibile da vedersi in diretta!!!). Ora sto scaricando i miei primi podcast… La prima registrazione di prova (una 15ina di minuti) ha funzionato alla perfezione… ora sta scaricando il primo mattoncione da un ora (230 mega di filmato), vedremo come va. Comunque per la cronaca si vede molto bene e si sente perfino stereo. Una pacchia.

Ok, lo ammetto, ho anche schedulato una registrazione su BOING (il canale dei cartoni animati)… ogni mattina registro Felix the cat. Ma posso sempre dire che lo faccio per Dario…. (ma che falso che sono…)

© 2011 extract the nectar, burn the tree Suffusion theme by Sayontan Sinha