Apache HTTP Server 2.4, il primo aggiornamento del progetto negli ultimi sei anni, è stato rilasciato ieri — nel giorno del diciassettesimo anniversario. Creato come un fork per il web server di Rob McCool del National Center for Supercomputing Applications (NCSA), Apache HTTP Server opera su oltre quattrocento milioni di siti web.

L’aggiornamento segue il rilascio di Apache HTTP Server 2.2 avvenuto nel dicembre del 2005. Le novità riguardano soprattutto l’infrastruttura dei Multi-Processing Modules (MPM), uscita dalla fase sperimentale. Più in generale, sono state migliorate tutte le prestazioni del web server: il progetto è davvero pronto al cloud computing.

Nello specifico, Apache HTTP Server 2.4 prevede un ridotto utilizzo della memoria e un’ottimizzazione della cache con particolare attenzione al traffico sui proxy. I dettagli dei nuovi moduli sono elencati in una lista completa delle novità: non resta che aspettare l’aggiornamento sul proprio hosting, se non si dispone d’un server.

Via | Apache

Apache HTTP Server 2.4, il rilascio del diciassettesimo anniversario é stato pubblicato su Ossblog.it alle 12:00 di mercoledì 22 febbraio 2012.

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

Con questo how to vedremo come installare apache in modalità reverse proxy su sistemi operativi OpenBSD.

Scenario

Configurazione

Internet -> Bilanciatore e reverse proxy -> Server LAN

La cosa migliore da fare in questo caso è affidarsi ad apache sia per la gestione del traffico verso i siti web sia per il bilanciamento dello stesso. La modalità di cui faremo uso si chiama per l’appunto reverse proxy, proprio perchè apache sulla macchina firewall non gestirà i virtualhost (non nel vero senso della parola almeno) ma farà da ponte (proxy) tra internet e la lan dei server, l’aggettivo reverse serve proprio ad indicare che il funzionamento del proxy non è normale (dalla lan verso l’esterno, come di solito un qualsiasi proxy viene usato) ma effettivamente inverso.

Installazione di Apache2 ed abilitazione del Reverse Proxy

Andiamo quindi ad installare Apache2 ed ad attivare i moduli che ci servono.

# pkg_add -v ftp://ftp.openbsd.org/pub/OpenBSD/X.X/packages/$ARCH/apache-httpd-2.X.X.tgz

Sostituite alle X rispettivamente la versione che state usando di OpenBSD e i numeri di versione del pacchetto apache che trovate sull’ftp pubblico. $ARCH con molta fantasia, va sostituito con il tipo di architettura che state usando (amd64 o i386).

Installazo apache dobbiamo modificare il file di configurazione per inserire i moduli da caricare.

LoadModule authz_host_module /usr/local/lib/apache2/mod_authz_host.so
LoadModule auth_basic_module /usr/local/lib/apache2/mod_auth_basic.so
LoadModule auth_digest_module /usr/local/lib/apache2/mod_auth_digest.so
LoadModule dumpio_module /usr/local/lib/apache2/mod_dumpio.so
LoadModule log_config_module /usr/local/lib/apache2/mod_log_config.so
LoadModule logio_module /usr/local/lib/apache2/mod_logio.so
LoadModule env_module /usr/local/lib/apache2/mod_env.so
LoadModule proxy_module /usr/local/lib/apache2/mod_proxy.so
LoadModule proxy_connect_module /usr/local/lib/apache2/mod_proxy_connect.so
LoadModule proxy_http_module /usr/local/lib/apache2/mod_proxy_http.so
LoadModule proxy_balancer_module /usr/local/lib/apache2/mod_proxy_balancer.so
LoadModule ssl_module /usr/local/lib/apache2/mod_ssl.so
LoadModule autoindex_module /usr/local/lib/apache2/mod_autoindex.so
LoadModule vhost_alias_module /usr/local/lib/apache2/mod_vhost_alias.so
LoadModule negotiation_module /usr/local/lib/apache2/mod_negotiation.so
LoadModule dir_module /usr/local/lib/apache2/mod_dir.so
LoadModule alias_module /usr/local/lib/apache2/mod_alias.so
LoadModule rewrite_module /usr/local/lib/apache2/mod_rewrite.so

Nella definizione di <Directory “/var/apache2/htdocs”>, togliete le opzioni di index e di followsymlinks, per questioni di sicurezza:

 Options -Indexes -FollowSymLinks

Configurazione del reverse proxy

NameVirtualHost *:80

 <VirtualHost *:80>
   ServerName www.ilportalinux.it
   ProxyRequests Off
   ProxyPreserveHost On
   ProxyPass / http://www.ilportalinux.it/
   ProxyPassReverse / http://www.ilportalinux.it/
</VirtualHost>
<VirtualHost *:80>
   ServerName www.androidworld.it
   ProxyRequests Off
   ProxyPreserveHost On
   ProxyPass / http://www.androidworld.it/
   ProxyPassReverse / http://www.androidworld.it/
</VirtualHost>

Fatto questo non ci resta che editare il file hosts associando gli ip in lan dei webserver sottostanti che hanno servono effettivamente i due siti web.

www.ilportalinux.it 192.168.1.1

www.androidworld.it 192.168.1.2

Finito! Riavviate apache e testatene il funzionamento.

Balanced Reverse proxy con supporto SSL

Sempre su apache2.conf aggiungere¹:

NameVirtualHost *:443

<VirtualHost *:443>
    ServerName www.ilportalinux.it
    ProxyRequests Off
    ProxyPreserveHost On
    SSLEngine On
    SSLProxyEngine On
    SSLCertificateFile /etc/apache2/ssl/ilportalinux.crt
    SSLCertificateKeyFile /etc/apache2/ssl/ilportalinux.key'''
    ProxyPass / balancer://portalinux/ stickysession=WL nofailover=On
    ProxyPassReverse / balancer://portalinux/
   <Proxy balancer://portalinux>
        Header add Set-Cookie "WL=WL.%{BALANCER_WORKER_ROUTE}e; path=/"
        env=BALANCER_ROUTE_CHANGED
        BalancerMember https://192.168.1.4:443 route=wl1
        BalancerMember https://192.168.1.5:443 route=wl2
        BalancerMember https://192.168.1.6:443 route=wl3
        BalancerMember https://192.168.1.7:443 route=wl4
    </Proxy>

   <Location /balancer-manager>
       SetHandler balancer-manager
       Order Deny,Allow
       Deny from all
       Allow from 123.456.789.123
   </Location>
</VirtualHost>

Come avrete notato il certificato ssl e la chiave di decrittazione sono installati sul bilanciatore non sulle macchine webserver sotto, questo perchè il client (il browser) stabilisce la connessione con il bilanciatore non con i webserver.

Questa configurazione inoltre è pure più complessa proprio perchè abbiamo dovuto anche bilanciare il traffico su più macchine, ma un bilanciamento normale non sarebbe stato efficiente, in quanto di default le sessioni autenticate non vengono considerate quindi se non si setta l’header http (prima istruzione in grassetto, che va scritta tutta sulla stessa riga, io l’ho spezzata perchè altrimenti non si leggeva bene) per inviare un cookie al client con un id sessione, i nostri utenti al primo refresh di pagina sarebbero stati dirottati su una qualsiasi altra delle 4 macchine webserver perdendo quindi l’autenticazione. In questo modo invece apache manda il traffico di una sessione sempre sulla stessa macchina.

La seconda parte invece, quella che ho posto in grassetto è nuova, non l’abbiamo usata infatti nella configurazione precedente. Questa configurazione ci serve per poter gestire il bilanciamento delle macchine direttamente da remoto via interfaccia web.

Mi spiego meglio, poniamo che una macchina sia da escludere temporaneamente dal cluster dei webserver per una manutenzione straordinaria, senza quel pezzo di configurazione saremmo dovuti andare sul bilanciatore, editare apache, commentare la riga relativa alla macchina interessata e riavviare apache. Cosi invece possiamo semplicemente puntare il browser su http://ip.pubblico.esposto/balancer-manager ed avere in un solo colpo:

1. Stato delle macchine e quindi del bilanciamento
2. Quantità di dati trasmessi da e verso ogni singola macchine
3. Gestione dinamica del cluster di webserver

Ovviamente l’accesso a questa funzione va ristretto il più possibile con la direttiva Allow from.

Logging sugli apache proxaty

Cosi com’è impostato infatti l’indirizzo ip della chiamata sui log dei webserver sarà sempre lo stesso, e sarà quello del bilanciatore, proprio perchè è il bilanciatore stesso che si fa carico di tutte le richieste da girare poi sotto. Ma con la variabile “{X-Forwarded-For}” possiamo far comparire anche l’indirizzo del client che ha aperto la chiamata sul bilanciatore. Andiamo quindi ad impostare i singoli apache sui webserver sostituendo…

 LogFormat "%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i"" combined

a:

 LogFormat "%{X-Forwarded-For}i %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i"" combined

1. Ovviamente la configurazione va copiata due volte una per il traffico http ed una per il traffico https

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

Tutti conosciamo wordpress, forse la più famosa piattaforma CMS per il blogging.

Anche io lo uso per questo e per il mio nuovo blog personale, ed è proprio installando questo nuovo blog che ho riscontrato un annoso problema.

WordPress è strutturato molto bene per la SEO, una feature built-in è ad esempio l’uso dei permalink, vale a dire la riscrittura degli url degli articoli con una sintassi molto più SEO-friendly.

Le impostazioni di default infatti registrano gli url dei vari articoli con l’id dello stesso, /?p=N, ad esempio dove N è l’id del post; noi possiamo cambiare queste impostazioni per far si che al posto di questa sintassi gli url siano richiamabili tramite un url che viene registrato in base al titolo dell’articolo. Maggiori informazioni si trovano nel codex di wordpress.

Questa funzione fa uso delle cosiddette Rewrite Rules, questo significa che il server che ospita il blog deve soddisfare dei requisiti minimi per far funzionare i permalinks, questi requisiti sono:

1. Il modulo mod_rewrite installato e caricato in apache
2. Opzione Followsymlinks dentro il file del virtualhost
3. Opzione Allowoverride settata a FileInfo nel file del virtualhost

Oltre al modulo mod_rewrite la regola più importante è la terza, con la direttiva di apache AllowOverride infatti diciamo ad apache se escludere od inlcudere i file nascosti nella doc root del sito, questi files sono ad esempio .htaccess, .etc, ecc…

É importante perchè wordpress installa le regole di rewrite proprio nel file .htaccess dentro la root directory del nostro sito e se apache le esclude quando cliccheremo sugli articoli otterremo un bell’errore 404.

Nel mio caso però nonostante il virtualhost fosse a posto con tutte le regole, il modulo caricato ed il sito correttamente visibile, i permalinks non ne volevano sapere di funzionare.

Mi sono reso conto che il problema era nella configurazione del demone di apache perchè non appena oscuravo il nuovo blog mi partiva l’allarme di nagios che mi controlla sostanzialmente che apache risponda con codice 200, non appena lo rimettevo online l’allarme scompariva, inoltre sembrava proprio che apache stesse ignorando le regole settate nel file del virtualhost.

Questo perchè, se non diversamente settato, apache prende il primo virtualhost in ordine alfabetico ed inizia a rispondere su quello sia se si usa l’url completo sia se si usa l’ip.

Mi spiego meglio: nel mio caso ci sono due virtualhost uno per ilportalinux.it ed un altro per alexanghelone.it. Per com’era settato prima apache se si chiamava http://alexanghelone.it oppure http://188.72.199.31 si vedeva in ogni caso la home page del blog, ignorando però la configurazione del virtualhost stesso, non considerando proprio la direttiva AllowOverride.

La soluzione è stata quella di aggiungere dentro il file apache2.conf questo:

?

<VirtualHost *:80>

ServerName 188.72.199.31

<DirectoryMatch />

Order Deny,Allow

Deny from all

Options None

AllowOverride None

</DirectoryMatch>

</VirtualHost>

Questa è una configurazione base, che andrebbe fatta sempre quando si installa apache, in questo caso sono stato coglione io a dimenticarmelo

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

Dopo tanto tempo ecco a voi un “tutorial per sysadmin“, oggi vediamo come bloccare dei potenziali attacchi di tipo indiretto.

Cosa significa attacco indiretto? Significa che non c’è un attacco che parte da un punto preciso e finisce sul nostro server, in un attacco spam via referral link chi ti attacca fisicamente, ed inconsapevolmente, sono gli stessi utenti che visitano il tuo sito.

Vi porto l’esempio di un attacco che ho dovuto gestire fino a ieri sera. 3 giorni fa poco dopo l’ora di pranzo mi chiamano segnalando che il sito istituzionale di $cliente non si vede più.

Questo è un sito grosso, piazzato su un cluster altrettanto grosso, solo le macchine del front end sono 4 e non sono macchine comprate da mediaworld, sono dei mini carro armati.

Quindi quando mi si dice “il sito è giù” rimango alquanto basito, collegandomi sui bilanciatori vedo che in maniera abbastanza randomica l’apache che fa da reverse proxy non riesce più a contattare la porta 80 di alcune macchine del front end, ed in effetti con un semplice telnet finisco con un timeout.

Per tagliarla corta, dopo ore ed ore di analisi abbiamo visto che molti errori venivano generati da chiamate GET che avevano come referral link un motore di ricerca di inserzioni online.

Consultandomi con gli sviluppatori vengo a sapere che l’url verso cui sono dirette le GET è una landing page di una campagna di affiliazione via banner, lanciata da $cliente, ne consegue quindi che questo motore di ricerca deve essersi iscritto a questa campagna; peccato che visitandolo del banner in questione non ve n’è traccia.

Il sospetto è quindi che i furbacchioni abbiano prelevato il codice del banner e l’abbiano nascosto in qualche maniera nel codice delle pagine, in modo che ad ogni pagina visitata sul motore parta un click “fasullo” sul banner. Basta avere un motore di ricerca che fa tante visite ed ecco che automaticamente la truffa si tramuta in attacco.

Il sito istituzionale di $cliente è gestito da application server java [sigh] i quali dovendo gestire un throughput di GET mastodontico entro breve tempo saturavano la memoria messa a disposizione dalla JVM (Java Virtual Machine) facendo si che le GET si accodassero, mandando successivamente in blocco la porta 80, e quindi rendendo il sito inaccessibile.

Qui non si può filtrare semplicemente via firewall, perchè come detto prima l’attacco è indiretto, non parte dai server del motore di ricerca ma sono gli utenti che vengono dirottati sul sito che attaccano il sito stesso.

L’unica soluzione è quindi adottare il mod_security di apache2 e filtrare le GET in entrata basandosi sul referral link, in modo che le chiamate “dirottate” dal motore di ricerca non vengano processate dal web service java e vengano direttamente rimbalzate con errore di tipo 500.

Una volta su debian bastava installare libapache2_mod-security via apt-get, ma su lenny sembra che questi pacchetti non siano più presenti, e quindi bisogna prelevarli tramite il sito ufficiale di mod security [mirror per i pacchetti debian] ed installarli via “dpkg -i“

Installati i pacchetti è sufficiente creare un file chiamato mod_security dentro /etc/apache2/conf.d e scriverci dentro:

<IfModule mod_security.c>

# mod_security configuration directives

# …

# Turn the filtering engine On or Off

SecFilterEngine On

# Some sane defaults

#Check if URL characters where encoded

SecFilterCheckURLEncoding On

#Check UTF-8 encoding

SecFilterCheckUnicodeEncoding Off

#Allow 1 byte characters

# Accept almost all byte values

SecFilterForceByteRange 0 255

# Server masking is optional

# SecServerSignature “Microsoft-IIS/0.0?

SecAuditEngine RelevantOnly

# The name of the audit log file

SecAuditLog /var/log/apache2/audit_log

# You normally won’t need debug logging

# Debug level set to a minimum

SecFilterDebugLog /var/log/apache2/modsec_debug_log

SecFilterDebugLevel 0

# Should mod_security inspect POST payloads

SecFilterScanPOST On

# By default log and deny suspicious requests

# with HTTP status 500

SecFilterDefaultAction “deny,log,status:500?

# Blocco il referral nasone.it

SecFilterSelective “HTTP_REFERER” “domain.tld”

</IfModule>

Compilato il file salviamolo e riavviamo apache, e da questo momento le chiamate in questione verranno filtrate, potete vedere se il filtro funziona tramite il file di log impostato nella configurazione sopra o più semplicemente vedendo le chiamate che arrivano nei file di accesso al virtual host di apache, vedrete che le GET da questo momento in poi non otterranno più un codice 200 ma 500.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Meteor è un web server realizzato per offrire agli sviluppatori la possibilità di integrare stream di dati all’interno delle proprie pagine senza richiedere l’aggiornamento dell’intera pagina.

Il sistema, in realtà, è composto dal server e da una libreria javascript che si occupa di astrarre la gestione della ricezione dei dati. Le caratteristiche principali di Meteor sono la capacità di gestire un alto numero di connessioni longeve e concorrenti. È presente, inoltre, un sistema di cache in memoria per gestire l’invio di un determinato evento a migliaia di client in tempo reale.

Sul sito potete approfondire le modalità di integrazione o le tecniche per utilizzarlo nei browser. Meteor è scritto in Perl e rilasciato sotto licenza GPLv2.

Via | Meteor

Meteor é stato pubblicato su ossblog alle 13:00 di martedì 20 luglio 2010.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Cherokee un web server molto veloce, flessibile e facile da gestire.

Supporta tutte le tecnologie che potrebbero servirvi in un web server come FastCGI, SCGI, PHP, CGI, uWSGI, SSI, TLS/SSL, virtual host, autenticazione, on the fly encoding, load balancing, file di log compatibili con Apache, data base balancing, reverse HTTP proxy, traffic shaper, video streaming e molto altro.

Dal punto di vista delle prestazioni non ha niente da invidiare a Lighttpd o Nginx, non parliamo di Apache. Gli utenti meno smaliziati potranno apprezzare la chiara e semplice interfaccia web di configurazione inclusa all’interno del web server. Sul sito potete trovare una buona quantità di documentazione ed alcune guide per gli usi più comuni.

Cherokee è scritto in C e rilasciato sotto licenza GPLv2.

Via | Cherokee

Cherokee, un web server veloce é stato pubblicato su ossblog alle 09:00 di domenica 18 luglio 2010.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Nginx (Engine X) è un Web Server utilizzabile anche come reverse proxy che ultimamente ha fatto molto parlare di sé per la sua semplicità di configurazione, le sue alte performance e la sua leggerezza.
A fine di novembre, stando alle statistiche di NetCraft, i server che utilizzano Nginx sono aumentati di oltre 3.5 milioni in 3 mesi, portando questo prodotto alla 4a posizione dei Web Server più utilizzati.

Installazione:

Attualmente sono disponibili pacchetti precompilati per quasi la totalità delle distribuzioni Gnu/Linux , tuttavia molti di essi non sono aggiornati e non contengono tutte le feature aggiunte con l’ultima versione.
Procederemo quindi con la compilazione diretta dei sorgenti scaricabili direttamente dal sito di nginx: http://wiki.nginx.org/NginxInstall .

$ wget http://sysoev.ru/nginx/nginx-0.7.64.tar.gz

$ tar -zxvf nginx-0.7.64.tar.gz
$ cd nginx-0.7.64

Per sistemi Debian i corrispondenti pacchetti per risolvere le dipendenze basilari di nginx sono i seguenti:

libc6 libpcre3 libpcre3-dev libpcrecpp0 libssl0.9.8 libssl-dev

zlib1g zlib1g-dev lsb-base

Le diverse opzioni di configurazione di NginX sono disponibili nel readme o http://wiki.nginx.org/NginxInstallOptions.

$ ./configure –conf-path=/etc/nginx/nginx.conf –error-log-path=/var/log/nginx/error.log –http-log-path=/var/log/nginx/access.log –with-http_ssl_module

(N.d.R: il comando precedente va in realtà tutto su una riga)

$ make

$ su

# make install

Attenzione, di default configure abilita l’http rewrite ma ha bisogno della libreria PCRE (ultima versione: ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-7.7.tar.gz ) , se non necessitate di questa funzione basta aggiungere l’opzione –without-http_rewrite_module a configure.

Configurazione:

Scriviamo da 0 un file di configurazione basilare, e salviamolo in /etc/nginx/nginx.conf:

——————-

user  nginx nginx;    # Assegna un utente ed un gruppo ai processi di nginx

worker_processes  2;            # Numero di processi massimi attivabili

error_log          logs/error.log;    # Dove salvare gli error log

pid                logs/nginx.pid;    # Dove salvare il file PID per nginx

worker_rlimit_nofile 8192;        # Il numero massimo di FD che può aprire un processo

events {

worker_connections  4096;        # Massimo numero di connessioni per processo

}

http {

include    conf/mime.types;

default_type application/octet-stream;

log_format   main ‘$remote_addr – $remote_user [$time_local]  $status ‘

‘”$request” $body_bytes_sent “$http_referer” ‘

‘”$http_user_agent” “$http_x_forwarded_for”‘;    #formato in cui verranno salvati i log

access_log   logs/access.log  main;        #Dove salvare gli access log

sendfile     on;
tcp_nopush   on;

server_names_hash_bucket_size 128;

server {                             # Definisce automaticamente un vhost

listen       80;                    # Porta in cui nginx si metterà in ascolto

server_name  pippo.it www.pippo.it;        # DomainName del virtual host

access_log   logs/pippo.it.access.log  main;    #Dove salvare gli access log

root         html;

location / {                        #Directory di Root

index    index.html index.htm index.php;    # File utilizzati come Index

}

}

———–

Lanciare il comando:

	# /usr/local/nginx/sbin/nginx

In questo modo Nginx si metterà in ascolto sulla porta 80 per il dominio pippo.it .

L’esempio è facilmente adattabile ad altri contesti, cambiando pippo.it col proprio nome di dominio.

Nei prossimi articoli introdurremo ulteriori concetti e configurazioni più elaborate.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Post originale su Linux e dintorni

Il server che sorregge il web come lo conosciamo oggi installato in locale sul vostro pc

Per chi, tra di voi, sviluppa per il web non è certamente necessaria questa guida composta da poche righe di codice ma indubbiamente ci sono moltissimi utenti che avvicinandosi a GNU/Linux vorrebbero rendere il loro computer una macchina dove provare le varie piattaforme CMS le quali annoverano due tra le più importanti espressioni del blogging ovvero Joomla e WordPress.

Senza un server Apache pronto a sostenere le piattaforme non è possibile procedere allo sviluppo di portali web o di più semplici blog personali.

Ecco quindi il motivo della guida ovvero fornire un ambiente di facile installazione e gestione configurabile in pochi passi ma perfettamente in grado di rispondere alle esigenze di chi vuole tentare la via dello sviluppo per il web.

Per prima cosa iniziamo con l’acquisizione dei diritti di amministrazione, per far ciò apriamo il classico terminale e digitiamo:

sudo -s

premiamo invio ed inseriamo la password quando richiesta.

Installazione MySQL

Il mysql è un database open fondamentale per il funzionamento di un server web sul quale andranno poi installate piattaforme come wordpress, joomla o altri gestori di contenuti.

Nel terminale che avete precedentemente aperto digitate:

sudo apt-get install mysql-server mysql-client

una volta scaricati i pacchetti il terminale chiederà di inserire una password che andrà inserita anche nella fase successiva, è molto importante inserire una credenziale sicura ma nello stesso tempo facile da ricordare visto che essa sarà la password di root per il vostro database.

Finita la sua installazione potete semplicemente verificare il suo corretto funzionamento digitando dal terminale:

mysql -p

alla richiesta della password inserita quella precedentemente scelta, se myqsl sarà correttamente installato e funzionante avrete come risposta:

myqsl>

questo, in semplici termini, significa che il database ha permesso il vostro accesso ed attende i vostri ordini, digitate:

quit

per ritornare alla console.

Installazione Apche2

Se non avete avuto avuto particolare problemi con il database ne incontrerete sicuramente ancora meno con il web server Apache2.

Sempre dal terminale digitate:

apt-get install apache2

in pochissimo tempo il sistema scaricherà i pacchetti necessari e provvederà alla loro installazione.

Anche in questo caso verificare il corretto funzionamento del server è questione di pochissimi passaggi, dopo aver aperto il vostro browser digitate nella barra degli indirizzi “http://localhost/”.

Il corretto funzionamento del server sarà garantito dalla dicitura “It Works!” che apparirà all’interno della finestra del software di navigazione.

Molte sono le cartelle che coinvolgono le attività del server ma per brevità citerò solo le più importanti sicuro che, per una prima necessità, siano sufficienti:

/var/www: è la vostra cartella che conterrà il vostro sito o progetto, in parole povere la cartella al quale il browser punta quando nella barra degli indirizzi inserite http://localhost

/etc/apache2/apache2.conf: è il file di configurazione del server dove sarete in grado di regolare le vostre impostazioni preferite come ad esempio la server root, il tempo di timeout ed altre utili impostazioni; non vi preoccupare della difficoltà di impostazione dello stesso, il file presenta al suo interno dei commenti descrittivi di tutte le voci che potrete modificare.

/etc/apache2/mods-enabled: cartella che contiene i mods del server ed i loro file di configurazione

/etc/apache2/sites-enabled: cartella nella quale potete configurare degli hosts virtuali

Certamente queste non sono tutte le cartelle nelle quali trovare tutti i file di configurazione possibili ma ritengo che, per un utente alle prima armi con molta voglia di sperimentare e documentarsi, siano una buona base di partenza.

Installazione PHP5

Parafrasando una nota pubblicità potremmo dire “che web server sarebbe senza PHP?”, il php è un linguaggio di programmazione lato server molto utilizzato nei moderni servizi ma per funzionare esso deve essere interpretato quindi è necessario installare il componente che si prende in carico questa operazione.

Sempre dal terminale:

apt-get install php5 libapache2-mod-php5

completate le operazione di installazione dovere riavviare Apache2 al fine di permettere allo stesso la rilevazione del rinnovato supporto al linguaggio, quindi inserite nel terminale:

/etc/init.d/apache2 restart

è finalmente arrivato il momento di testare il supporto al PHP e per far questo inserite all’interno della cartella /var/www un file di testo dove all’interno avrete copiato il seguente testo:

<?php
phpinfo();
?>

il file fa rinominato come info.php.

Una volta copiato nella vostra cartella www digitate localhost all’interno della barra degli indirizzi del vostro browser, la corretta esecuzioni delle operazioni sarà presto evidente.

Supporto MySql per il PHP5

Php è in grado di operare in modo completo ed ottimale con il vostro database Mysql fa il supporto a questa funzione va installato, per far questo sempre dal terminale:

apt-get install install php5-mysql php5-curl php5-gd php5-idn php-pear php5-imagick php5-imap php5-mcrypt php5-memcache php5-mhash php5-ming php5-ps php5-pspell php5-recode php5-snmp php5-sqlite php5-tidy php5-xmlrpc php5-xsl php5-json

una volta terminata l’installazione dovete riavviare il server Apache con il classico comando da terminale:

/etc/init.d/apache2 restart

se ora ricaricate la pagina localhost del vostro browser sarte in grado di vedere tutti i nuovi moduli installati compreso quello per il supporto al database MySql.

Installazione phpMyAdmin

Per coloro che hanno qualche periodo di esperienza alla spalle governare un database attraverso un terminale non sarà sicuramente un problema, si tratta in fin dei conti di riuscire a memorizzare la sintassi con la quale si opera all’interno delle varie tabelle.

Per tutti quelli che invece desiderano un supporto visivo semplice che sia in grado di mostrare in modo semplice ed organico il proprio database e contemporaneamente permetta all’utente di operare su di esso con facilità senza una conoscenza approfondita dei comandi è consigliabile l’installazione di un tool che permetta queste operazioni.

Esistono molti software in grado di svolgere tale compito ma uno dei più completi è sicuramente phpMyAdmin, per la sua installazione, sempre dal terminale, digitate:

apt-get install install phpmyadmin

durante l’installazione vi verrà quale server riconfigurare per l’uso di phpmyadmin ovviamente scegliete Apache2, successivamente vi verrà chiesto se configurare il database con dbconfig-common, rispondete no.

Finalmente avete terminato la vostra installazione e potrete divertirvi con il successivo setup di CMS o con la realizzazione di progetti in php.

P.S.: dimenticavo occhio ai permessi……..

P.S.: amate la vita comoda o non riuscite a cavare un ragno dal buco? Osservate qui: http://www.apachefriends.org/en/xampp-linux.html#377

Ciao a tutti.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

OpenVZ è una buona soluzione per la virtualizzazione a livello di sistema operativo. Quando ci si fida degli applicativi che girano in un sistema, OpenVZ è decisamente un prodotto da considerare.

Viceversa affidando un vps ad un estraneo magari senza capacità in ambito sistemistico, può risultare un problema; poiché l’isolamento non è così robusto come quello fornito da VMware ESX oppure Xen.

La prima cosa da fare è installare OpenVZ sul proprio server fisico, le istruzioni per farlo si possono trovare qui: OpenVZ installazione rapida.

Scaricare dalla pagina http://wiki.openvz.org/Download/template/precreated il template già pronto di Debian 5.0 (quello x86 per sistemi a 32 bit oppure x86_64 per la versione a 64 bit).

Collocare l’archivio scaricato, senza scompattarlo, nella cartella /vz/template/cache del proprio computer.

Per creare un container (un vps) a partire dal modello scaricato, basta eseguire il comando, avendo cura di mettere debian-5.0-x86_64 se sis è scelto un template a 64 bit:

# /usr/sbin/vzctl create 101 –ostemplate debian-5.0-x86

Dopo qualche secondo viene creato un nuovo container, ma per poterlo usare bisogna avviarlo:

# /usr/sbin/vzctl start 101

Per poter utilizzare una connessione di rete e quindi rendere il vps contattabile almeno dalla LAN assegnare un indirizzo ip facente parte della rete (anche mentre l’ambiente è in esecuzione):

# /usr/sbin/vzctl set 101 –ipadd 192.168.1.101

Per potersi collegare al vps basta usare il comando:

# /usr/sbin/vzctl enter 101

Digitando “ps aux” si vedono che solo pochi processi sono in esecuzione. Invece adoperando “free –m” si nota che (nel mio caso) solo 11 megabyte sono adoperati.

Prima di tutto controllare che la rete sia effettivamente funzionante provando con un ping ad un indirizzo della subnet.

Se il ping non mostra alcun pacchetto di risposta può essere necessario disattivare l’interfaccia virtuale nel container creata già con un indirizzo non adeguato alle caratteristiche della propria rete: col comando “ipconfig” vengono mostrate l’interfaccia di loopback, l’interfaccia creata con l’ip personalizzato (come spiegato precedentemente) e una scheda di rete con ip 10.1.1.1 che va eliminata col comando:

vps:/# ifdown venet0:0

Ora è possibile fare un upgrade del sistema con le ultime patch di sicurezza:

vps:/# apt-get update

vps:/# apt-get upgrade

Se ci sono ancora problemi con le connessioni ad Internet, adoperare strumenti come WireShark per capire cosa sta accadendo.

Può darsi che abbia problemi con la risoluzione dei nomi (cioè che sia in grado di raggiungere l’esterno usando un indirizzo ip pubblico ma non sia capace di risolvere ad esempio google.it), in questo caso vedere le regole usate per iptables sul server fisico (disabilitarle temporaneamente).

Per approfondire vedere gli articoli della categoria OpenVZ.

Non c’è sinceramente molto da fare perché Apache è già installato all’interno del container.

Se si vuole usare Apache per creare un VirtualHost si può adoperare questo modello:

<VirtualHost *:80>
ServerAdmin admin@adminsite.com
ServerName www.adminsite.com
ServerAlias adminsite.com
DocumentRoot /var/www/adminsite
<Directory /var/www/adminsite>
Options FollowSymLinks -Indexes
AllowOverride All
</Directory>

ErrorLog /var/log/apache2/adminsite_error.log
CustomLog /var/log/apache2/adminsite_custom.log combined
</VirtualHost>

Se si preferisce sostituire Apache con un web server più leggero come lighttpd o nginx si può disinstallare Apache con:

vps:/# /etc/init.d/apache2 stop

vps:/# apt-get remove apache2

Per installare Nginx dai pacchetti inclusi nei repository Debian:

vps:/# apt-get install nginx

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.