Presentació del servidor Apache

Más manuales en: http://www.exabyteinformatica.com/manuales-y-apuntes-freeware

© Roger Casadejús Pérez | http://www.exabyteinformatica.com/tienda/

Presentació del servidor Apache

Descripció de l'arquitectura en mòduls de l'Apache. Explicació i enumeració de les

funcionalitats associades a cada mòdul:

El servidor Apache és un programari que està estructurat en mòduls. La configuració de cada

mòdul es fa mitjançant la configuració de les directives que estan contingudes dins del mòdul.

Els mòduls de l'Apache es poden classificar en tres categories:

· Mòduls base: Mòdul amb les funcions bàsiques de l'Apache.

· Mòduls multi procés: són els responsables de la unió amb els ports de la màquina, acceptant

les peticions i enviant als fills a atendre a les peticions.

· Mòduls addicionals: Qualsevol altre mòdul que li afegeixi una funcionalitat al servidor.

Les funcionalitats més elementals es troben en el mòdul base, sent necessari un mòdul multi

procés per gestionar les peticions. S'han dissenyat diversos mòduls multi procés per a

cadascun dels sistemes operatius sobre els quals s'executa l'Apache, optimitzant el rendiment i

rapidesa del codi.

La resta de funcionalitats del servidor s'aconsegueixen per mitjà de mòduls addicionals que es

poden carregar. Per afegir un conjunt d'utilitats al servidor, simplement cal afegir-li un mòdul,

de manera que no és necessari tornar a instal·lar el programari.

Mòduls base i mòduls multi procés

core: Funcions bàsiques de l'Apache que estan sempre disponibles.

mpm_common: Col·lecció de directives que s'implementen en més d'un mòdul multi procés.

beos: Mòdul de multi procés optimitzat per BeOS.

leader: Variable experimental de MPM.

mpm_netware: Mòdul de multi procés que implementa un servidor web optimitzat per Novell

NetWare.

mpmt_us2: MPM híbrid, multi procés i multi fil para OS/2 .

perchild: Mòdul multi procés que permet als processos dimoni servir les peticions que

s'assignen a diferents usuaris.

prefork: Implementa un servidor sense fils.

threadpool: Variant experimental del mòdul estàndard de MPM .



mpm_winnt: Mòdul multi procés optimitzat per Windows NT.

worker: Mòdul multi procés que implementa un híbrid multi fils i multi processos de servidor

Web.

Mòduls addicionals

mod_access: proporciona control d'accés basant-se en el nom del host del client, la seva

adreça IP o altres característiques de la petició del client.

mod_actions: aquest mòdul s'utilitza per executar scripts CGI, basant-se en el tipus de mitjà o

el mètode de petició.

mod_àlies: proporcionat per mapejar diferents parts del sistema de fitxers del servidor en

l'arbre de documents del servidor, i per a redirecció d'URL's.

mod_asis: enviament de fitxers que tenen les seves pròpies capçaleres http.

mod_auth: autenticació d'usuari utilitzant fitxers de text.

mod_auth_anon: permet a usuaris anònims accedir a àrees autenticades.

mod_auth_dbm: proporciona autenticació utilitzant fitxers DBM.

mod_auth_digest: autenticació d'usuari utilitzant MD5.

mod_auth_ldap: permet la utilització un directori LDAP per emmagatzemar la base de dades

d'autenticació.

mod_autoindex: mostra els continguts d'un directori automàticament, semblant a la instrucció

ls d'Unix.

mod_cache: Cache de continguts indexats per URI's.

mod_cern_meta: Semàntica d'etiquetes del CERN.

mod_cgi: Execució de scritps CGI.

mod_cgid: execució de scripts CGI utilitzant un dimoni CGI extern.

mod_charset_lite: per a l'especificació del joc de caràcters de les traduccions.

mod_deflate: comprimeix el contingut abans de ser enviat al client.

mod_dir: Proporcionat per a redireccionaments i per servir els fitxers del llistat de directoris.

mod_disk_cache: Cache per emmagatzemar continguts identificats per URI.

mod_tiro: Un servidor simple per il·lustrar els mòduls del protocol.

mod_env: modificació de l'entorn que es envia als scripts CGI i les pàgines SSL.



mod_expire: Generació de les capçaleres http expire, d'acord amb els criteris especificats per

l'usuari.

mod_ext_filter: passa el cos de la resposta a través d'un programa abans d'enviar-la-hi al

client.

mod_file_cache: escorcolla una llista estàtica de fitxers en memòria.

mod_headers: personalització de les peticions HTTP i les capçaleres de les respostes.

mod_imap: procés d'imatges en el costat del servidor (Server Side).

mod_include: Documents HTML generats pel servidor (Server Side Includes).

mod_info: proporciona una visió comprensiva de la configuració del servidor.

mod_isapi: Extensions ISAPI en Apache per Windows.

mod_ldap: pool de connexions LDAP i escorcoll de resultats per a la utilització d'altres mòduls

LDAP.

mod_log_config: registre de les peticions fetes al servidor.

mod_logio: registre del nombre de bytes rebuts i enviats en cada resposta.

mod_mem_cache: Cache de continguts identificats per URI.

mod_mime: associa les extensions de peticions dels fitxers amb el comportament del fitxer

(gestionadores i filtres) i contingut (tipus mime, idioma, joc de caràcters i codificació).

mod_mime_magic: determina el tipus mime d'un fitxer mirant uns pocs bytes del contingut.

mod_negotiation: es fa servir per a la negociació del contingut.

mod_proxy: servidor HTTP/1.1 proxy/gateway.

mod_proxy_connect: extensió de mod_proxy per a la gestió de les peticions connect.

mod_proxy_ftp: suport FTP per mod_proxy.

mod_proxy_http: suporta HTTP per al mòdul mod_proxy.

mod_rewrite: proporciona un motor de reescriptura basat en regles que torna a escriure les

peticions d'URL's al vol.

mod_setenvif: permet la configuració de les variables d'entorn basant-se en les

característiques de la petició.

mod_speling: intenta corregir les URL mal posades pels usuaris, ignorant les majúscules i

permetent fins a una falta.

mod_ssl: criptografia avançada utilitzant els protocols Secure Sockets Layer i Transport Layer

Security.



mod_status: proporciona informació en l'activitat i rendiment del servidor.

mod_suexec: permet als scripts CGI ser executats amb un nom i grup específic.

mod_unique_id: proporciona variables d'entorn i un identificador únic per a cada petició.

mod_userdir: directoris específics per a usuaris.

mod_usertrack: registre d'activitat d'un usuari en el lloc.

mod_vhost_alias: Proporcionat per configurar molts servidors virtuals dinàmicament.

Explicarem el procés de descàrrega i instal·lació del servidor Apache en sistemes Windows.

El procés per instal·lar Apache en Windows és molt senzill. D'ara endavant, és possible que la

configuració del servidor pugui complicar-se una mica, no obstant això, si desitgem utilitzar-ho

amb les funcions habituals, no hem de tenir majors problemes en cap moment.

Descàrrega d'Apache

El servidor web Apache es pot descarregar a la pàgina de la Fundació Apache, a apache.org.

En la URL http://httpd.apache.org/ teniu una secció en particular per al servidor HTTP

(Protocol de transmissió utilitzat en la web), en la qual haurem de buscar l'enllaç per a la

descàrrega.

Una vegada a la pàgina de descàrrega hem de buscar l'última versió estable o la versió que

recomanen. El servidor està disponible per a sistemes Unix o Windows, per la qual cosa ens

oferiran diverses opcions de descàrrega, fins i tot per obtenir el codi font del programa. Si

desitgem instal·lar-ho en un sistema Windows, necessitem obtenir l'arxiu Win-32 binari, que és

un instal·lador Windows.

Instal·lació

Una vegada descarregat, hem d'instal·lar-ho en el nostre sistema, executant l'arxiu obtingut.

Donarem pas a un assistent que ens guiarà en el procés d'instal·lació del servidor. Durant el

procés ens preguntarà el nom del domini i del servidor, que podem emplenar amb localhost.

Ens demanarà també una adreça de correu, que podem emplenar amb qualsevol que

desitgem. També ens pregunta si desitgem que el servidor respongui en el port 80 per a tots

els usuaris o si desitgem que només s'activi per a l'usuari actual en el port 8080, quan s'iniciï

manualment. El normal és que ho activem per a tots els usuaris.

Amb aquestes dades queda configurat l'Apache inicialment. En qualsevol moment podem

editar-lo al nostre gust o necessitats. Per a això haurem d'editar el fitxer httpd.conf, que es



troba en el directori d'instal·lació d'Apache, que hem indicat durant el procés d'instal·lació,

més concretament, en el subdirectori conf. D'ara endavant en aquest manual podrem

aprendre les configuracions més habituals.

Nota: Hem d'anar amb compte de no tenir un altre servidor configurat per treballar en el port

80 (per exemple el servidor IIS que ve en les versions professionals o servidor de Windows). En

cas de tenir en marxa un altre servidor web durant la instal·lació, pot fallar i mostrar-nos un

missatge d'error que indiqui això precisament, és a dir, que no podem tenir dos servidors

alhora escoltant en el port 80.

Per solucionar el problema n'hi ha prou que parem el IIS o l'altre servidor que estigui

funcionant. El IIS el podem parar accedint a Panell de control - Eines administratives - Serveis

d'Internet Information Server. La pantalla que surt és la consola d'administració del sistema.

Aquí hem de desplegar l'arbre de l'esquerra, prement sobre el signe +, fins que trobem el "Lloc

web predeterminat". Ens posem damunt de ell i premem el botó de STOP que està situat en la

barra d'eines de la consola d'administració. També podem trobar una opció per parar el servei

prement amb el botó dret en el "Lloc web predeterminat".

Una vegada instal·lat, l'Apache es posa en funcionament. Per controlar l'Apache podem trobar

en el botó d'inici, secció programes, un nou grup anomenat "Apache HTTP Server", amb icones

per detenir el servidor, engegar-ho, editar l'arxiu de configuració httpd.conf o per veure els

logs d'accés. També podem veure en la barra de tasques una nova icona que indica que

l'Apache està funcionant i que ofereix opcions per controlar-ho si premem sobre ell.

Veure si està funcionant

Per comprovar que el servidor està actiu i funciona correctament podem obrir un explorador i

provar d’accedir a la URL http://localhost, que és el nostre propi servidor. Si tot ha anat bé

observarem el missatge de benvinguda del servidor amb alguna cosa com "Funciona! El

servidor Apache ha estat instal·lat en aquest equip!".

Per seguir aprenent a configurar Apache és interessant llegir-se el manual d'instal·lació i

configuració d'Apache, que explica on hem de canviar les opcions més comuns del servidor.

Explicació de l'estructura de directoris que obtenim una vegada instal·lat el servidor Apache

Una vegada instal·lat l'Apache, en el directori arrel de la instal·lació, es trobaran els següents

directoris:

bin: fitxers executables de l'Apache.

conf: fitxers de configuració del servidor.

error: fitxers amb els missatges d'error del servidor, en diversos llenguatges.

htdocs: directori arrel per defecte del servidor (Es guarden les pàgines Web).



icons: directori on es troben les icones que utilitza el servidor (entre altres coses per mostrar

estructures de directoris).

logs: directori on s'emmagatzemen els registres d'accés i errors del servidor.

manual: directori on es troba el manual de l'Apache.

proxy: Directori amb els fitxers de la cache del servidor.

Bàsicament les configuracions del servidor resideixen dins de dos fitxers, el de configuració

principal que es troba dins de la carpeta conf, amb el nom httpd.conf, o dins d'un fitxer amb el

nom .htaccess que es pot trobar dins de qualsevol directori que es trobi mapejat dins del

servidor. Dins de cadascun d'aquests fitxers se situen les directives de configuració. Moltes

d'aquestes directives de configuració es poden trobar tant dins del fitxer de configuració

principal com dins d'un fitxer .htaccess. Els valors de les directives que es troben dins d'un

fitxer .htaccess, prevalen enfront dels valors de configuració especificats dins del fitxer

httpd.conf.

Estructura del fitxer principal de configuració de l'Apache

El fitxer httpd.conf és el fitxer principal de configuració de l'Apache, es troba dins del directori

conf, en el directori d'instal·lació de l'Apache.

En primer lloc cal destacar que el fitxer està dividit en tres seccions, que són:

· Paràmetres globals.

· Directives de funcionament.

· Host virtuals.

En el fitxer es troben tots els paràmetres de funcionament de l'Apache. Alguns paràmetres són

generals per a la instal·lació i funcionament de l'Apache. Molts d’altres dels paràmetres es

poden configurar independents per a un conjunt de directoris i/o fitxers . En aquests casos els

paràmetres es troben situats dins de seccions on s'indica l'àmbit d'aplicació del paràmetre.

Les seccions més importants són:

: Els paràmetres que es troben dins d'aquesta secció, només s'aplicaran al directori especificat i

als seus subdirectoris: Igual que Directory, però accepta en el nom del directori expressions

regulars. Els paràmetres de configuració proporcionen control d'accés dels fitxers pel seu nom.

Igual que Files, però accepta expressions regulars en el nom del fitxer. Proporciona un control

d'accés dels fitxers per mitjà de la URL. Igual que Location, però accepta expressions regulars

en el nom del fitxer.



Algunes vegades les directives de funcionament de les seccions anteriors es poden creuar.

També cal destacar, que el fitxer conté un munt de comentaris per a la seva correcta

utilització, les línies comentades apareixen amb el símbol #.

Enumeració i descripció dels paràmetres de la secció paràmetres globals del fitxer httpd.conf

Tots els paràmetres que s'estableixen dins d'aquesta secció són globals per al funcionament

del servidor, per la qual cosa no admeten estar dins de cap directiva.

ServerRoot: especifica la ubicació del directori arrel on es troba instal·lat l'Apache, a partir del

com es crea l'arbre de directoris comentat anteriorment. Aquesta directiva no hauria de

canviar tret que es mogui la carpeta d'instal·lació d'Apache a un altre directori. Es troba

disponible a través del mòdul core.

PidFile: ubicació del fitxer que contindrà el nombre d'identificació del procés quan s'encengui

el servidor. Es troba disponible a través de diversos mòduls beos, leader, mpm_winnt,

mpmt_us2, perchild, prefork, threadpool o worker.

TimeOut: el valor s'utilitza per configurar mesurat en segons, tres paràmetres:

- El temps tal que pot trigar una petició a ser rebuda.

- La quantitat de temps d’espera entre recepció de paquets TCP.

- La quantitat de temps entre ACK's en transmissions TCP.

Passat aquest temps es produeix un missatge d'error en el qual s'indica que s'ha consumit el

temps màxim d'espera. Establir un valor molt petit pot donar lloc al fet que els usuaris rebin

aquest missatge d'error, i establir un valor molt petit donarà lloc a una sobrecàrrega de la

màquina. Es troba disponible a través del mòdul core.

KeepAlive: especifica si s'utilitzaran connexions persistents, és a dir, que totes les peticions

d'un usuari s'atendran amb la mateixa connexió. Es troba disponible a través del mòdul core.

MaxKeepAliveRequests: nombre màxim de connexions persistents. (nombre màxim d'usuaris

concurrents si KeepAlive està a ON). Per establir aquest paràmetre, cal tenir en compte l'ample

de banda de sortida del nostre servidor, pel qual haurà de ser enviada tota la informació, si

s'estableix un valor molt gran respecte a l'ample de banda, el temps de resposta es veurà

incrementat per a cada usuari. Es troba disponible a través del mòdul core.

KeepAliveTimeout: temps que espera en segons entre peticions d'un usuari, abans de

considerar que aquest ha acabat, i tancar la seva connexió.

Si el valor és molt petit provocarà que alguns usuaris no puguin visualitzar la pàgina a causa

que el nombre màxim de connexions persistents s'ha superat, mentre que si s'estableix un

valor molt gran s'estaran utilitzant molts recursos de la màquina. Es troba disponible a través

del mòdul core.



Listen: aquesta directiva permet especificar quins port s'utilitzaran per atendre les peticions.

Per defecte s'utilitza el port 80 (www), també permet especificar quines adreces IP atendrà,

per defecte totes. Per atendre dos adreces IP diferents, amb diferents port, s'utilitzaria:

Listen 192.168.0.10:80

Listen 192.168.0.9:8080

Es troba disponible a través de diversos mòduls beos, leader, mpm_winnt, mpmt_us2,

perchild, prefork, threadpool o worker.

LoadModule: Directiva que serveix per carregar mòduls que inclouen diferents funcionalitats.

La sintaxi és:

LoadModule nom_del_mòdul ubicació_Arxiu

Descripció de les directives de funcionament que es troben dins del fitxer httpd.conf

Aquesta és la secció principal de configuració del servidor, en ella podem trobar les següents

opcions:

ServerAdmin: especifica l'adreça de correu electrònic de l'administrador, aquesta adreça

apareix en els missatges d'error, per permetre a l'usuari notificar un error a l'administrador. No

pot estar dins de cap secció. Es troba disponible a través del mòdul core.

ServerName: especifica el nom i el port que el servidor utilitza per identificar-se, normalment

es determina automàticament, però és recomanable especificar-ho explícitament perquè no hi

hagi problemes en iniciar el servidor. Si el servidor no té un nom registrat en les DNS, es

recomana posar el seu número IP. No pot estar dins de cap secció.

La sintaxi és:

ServerName direccióIP:Port p.ex:. ServerName localhost:80

Es troba disponible a través del mòdul core.

DocumentRoot: la carpeta arrel que se situa en el servidor, des de la qual se serviran els

documents. Per defecte, totes les peticions, tindran com a arrel aquesta carpeta, tret que

s'utilitzin àlies (directoris virtuals en IIS).

Per defecte, la carpeta arrel és la carpeta htdocs, que es troba en la carpeta d'instal·lació de

l'Apache. No pot estar dins de cap secció.

Si es canvia aquest directori per un altre, és molt important que es posi el nou valor, no només

en aquesta línia, sinó també en la secció de la qual s'estableixen els paràmetres de

configuració d'aquest directori.

Aquesta línia comença per "




DirectoryIndex: especifica el fitxer per defecte que buscarà en cada directori, en cas que no

s'especifiqui cap. Per defecte és index.html. És a dir, que si per exemple es posa en el

navegador: www.exabyteinformatica.com el servidor per defecte servirà

www.exabyteinformatica.com/index.html

En aquesta directiva es poden especificar més d'un fitxer, la sintaxi és la següent:

DirectoryIndex fitxer1 fitxer2 fitxer3

L'ordre amb el qual s'especifica el nom de fitxer determinarà la prioritat a l'hora de decidir

quin fitxer és el que es mostra.

La directiva es pot trobar fora de qualsevol secció, dins d'una secció o dins d'un fitxer

.htaccess.

Es troba disponible a través del mòdul mod_dir.

AccessFileName: és el nom del fitxer de configuració que es buscarà en cadascun dels

directoris del servidor per conèixer la configuració del mateix. Aquest fitxer permet configurar

el comportament de cadascun dels directoris individualment. Perquè aquesta configuració

funcioni, la directiva AllowOverride ha de tenir un valor que ho permeti. No pot estar dins de

cap secció.

El nom de fitxer que s'especifica per defecte és el del fitxer ".htaccess".

Com a mesura de seguretat, la configuració de l'Apache estableix que no es mostri l'existència

d'aquest fitxer a cap usuari, encara que sí establir l'opció de llistat de directoris. Si es decideix

canviar al nom, caldrà redefinir la seguretat perquè no es mostri el contingut del nou fitxer.

Això es fa en el fitxer httpd.conf en una secció File com la qual es presenta a continuació en la

qual s'estableix que tots els fitxers que comencin per .ht no es mostraran.

Order allow,deny

Deny from all



TypesConfig: especifica el nom del fitxer que conté la llista de tipus mime que coneix el

servidor, i que determinarà depenent de les extensions per generar les capçaleres http. No pot

estar dins de cap secció.



Es troba disponible a través del mòdul mod_mime.

DefaultType: tipus mime que se servirà per defecte en cas de no conèixer l'extensió del fitxer

que s'està servint. Per defecte, s'indicarà que se serveix text pla, amb el valor text/plain. La

directiva es pot trobar fora de qualsevol secció, dins d'una secció o dins d'un fitxer .htaccess.

Sintaxi: DefaultType tipusMime

Es troba disponible a través del mòdul Core.

HostnameLookups: s'utilitza en els fitxers de registre. Per defecte quan es produeix un accés,

es guarda simplement el seu nombre IP, si aquesta directiva es troba en On, el servidor

buscarà la correspondència d'aquest nombre IP amb el seu nom, i emmagatzemarà el nom.

Establir aquesta configuració en ON provocarà que almenys s'hagi de fer una petició al servidor

de noms per cadascuna de les peticions d'usuari, per la qual cosa el rendiment de la màquina

es pot veure reduït. Aquesta directiva es pot trobar dins d'una secció o fora de qualsevol altra.


ErrorLog: especifica la ubicació del fitxer que conté el registre d'errors, per defecte en la

carpeta logs. Aquesta directiva només es pot trobar fora de qualsevol secció.


LogLevel: especifica el tipus de missatges que es guardessin en el fitxer de registre d'errors,

depenent dels valors especificats, es guardaran mes o menys. Aquesta directiva només es pot

trobar fora de qualsevol secció.

Valor de més a menys són: debug, info, notice, warn, error, crit, alert, emerg


LogFormat: la directiva permet definir el format que s'utilitzarà per emmagatzemar els

registres. A cada format se li pot assignar un nom, utilitzant-ho després per crear diferents

tipus de fitxers de registre. Poden existir diversos logFormat diferents.

Sintaxi:

LogFormat "configuracióError" nom

Aquesta directiva es troba fora de qualsevol secció.

Es troba disponible a través del mòdul mod_log_config.

CustomLog: la directiva s'utilitza per especificar la ubicació i el tipus de format que s'utilitzarà

en un fitxer de registre. Poden existir diversos fitxers de registre diferents amb configuracions

diferents. Per fer això, simplement cal posar diverses línies customlog

Sintaxi: CustomLog fitxer format




Es troba disponible a través del mòdul mod_log_config.

ServerTokens: Aquesta directiva estableix la informació que es retorna dins de la capçalera

http que envia el servidor.



IndexOptions: Aquesta directiva controla l'aparença de la pàgina que es mostrarà a un usuari

quan es demana la llista de fitxers d'un directori.

Sintaxi:

IndexOptions [+|-]opció [[+|-]opció]

Entre les opcions que es poden posar, destaca:

FancyIndexing: que mostra els noms dels fitxers, amb icones etc..

Es troba disponible a través del mòdul mod_autoindex.

FoldersFirst: Fa que primer es mostrin els directoris. Aquesta opció només es pot establir en el

cas que FancyIndexing estigui activa.

Aquesta directiva es pot trobar dins del fitxer .htaccess, dins d'una secció i fora de qualsevol

altre.



AddIconByEncoding: Aquesta directiva permet associar una icona a un tipus mime, de manera

que quan la directiva fancyIndexing estigui activada, es mostrarà al costat del fitxer la icona

corresponent.

Sintaxi:

AddIconByEncoding icon MIME-encoding

Exemple:

AddIconByEncoding/icons/icona_PC.gif x-compress

Aquesta directiva es pot trobar dins del fitxer .htaccess, dins d'una secció i fora de qualsevol

altra.




AddIconByType: Aquesta directiva associa una icona a un fitxer depenent de l'un tipus mime,

de manera que quan la directiva fancyIndexing està activada, es mostrarà al costat del fitxer la

icona corresponent.

Sintaxi:

AddIconByType icon MIME-encoding

Exemple:

AddIconByType /icons/Icona_Llapis.gif text/*

La diferència entre AddIconByType i AddIconByEncoding resideix en que mentre que en la

primera es determina el tipus mime mitjançant la codificació del fitxer, en la segona es

determina el tipus mime basant-se en el nom del fitxer.

Ambdues directives es poden trobar dins del fitxer .htaccess, dins d'una secció o fora de

qualsevol altra.


AddDescription: Aquesta directiva permet associar una descripció a un tipus de fitxer, que es

mostrarà en llistar un directori. Aquesta directiva es pot trobar dins del fitxer .htaccess, dins

d'una secció o fora de qualsevol altra.

Sintaxi:

AddDescripcion cadena , fitxer


AddDefaultCharset: Aquesta directiva defineix la codificació de caràcters que s'utilitzarà de

forma predeterminada per als documents. Per defecte ve establert el valor ISO-8859-1.

Aquesta directiva es pot trobar dins de qualsevol secció i en els fitxers .htaccess.


ErrorDocument: Aquesta directiva estableix el la configuració del servidor per quan es

produeix un error. Es poden establir quatre configuracions diferents:

Mostrar un text d'error.

Redirigir a un fitxer en el mateix directori.

Redirigir a un fitxer en el nostre servidor.

Redirigir a un fitxer fora del nostre servidor.

Cal tenir en compte que si el text d'error s’envia a Internet Explorer, aquest haurà de tenir

almenys 512 Bytes, perquè sinó Internet Explorer mostrarà la seva pròpia pàgina d'error.



Sintaxi:

ErrorDocument NúmeroError Acció

Aquesta directiva es pot trobar tant dins del fitxer .htaccess, dins de la secció o fora de

qualsevol altra secció.

Exemple:

ErrorDocument 404 /error_404.html.

En cas de no trobar-se un fitxer, es mostrarà el fitxer error_404.html


CacheRoot: estableix el directori on es trobaran els fitxers de la cache de l'Apache.

Es troba disponible a través del mòdul mod_disk_cache

CacheSize: Grandària de la cache en Kilobytes.


CacheGcInterval: Estableix cada quantes hores es verificarà la grandària dels fitxers de la cache

per comprovar si es corresponen amb la grandària establerta dins de CacheSize. El valor

accepta nombres flotants, per la qual cosa es poden establir els intervals en minuts. Com més

gran sigui el valor d'aquesta directiva, més possibilitats existiran que se sobrepassi el valor

establert en CacheSize.


CacheMaxExpire: màxim nombre d'hores que els fitxers romandran dins de la cache.

Es troba disponible a través del mòdul mod_cache

CacheLastModifiedFactor: Serveix per calcular la caducitat d'un fitxer en la cache, que serà el

de l'hora de l'última modificació, multiplicat per aquest valor.

Es troba disponible a través del mòdul mod_cache

CacheDefaultExpire: Nombre d'hores per defecte a partir de les quals un fitxer caduca. S'aplica

en aquells casos en els quals no es pot determinar l'hora de creació del fitxer.

Totes les directives de la caché, han de trobar-se fora de qualsevol secció. Aquesta directiva no

es pot trobar dins de cap secció.

Es troba disponible a través del mòdul mod_cache directori virtual. Un directori que es troba

en un directori diferent del que es mapeja en la URL.



Com crear-los en Apache

Aquesta directiva només es troba dins del fitxer de configuració httpd.conf, i es tracta aparti

en aquest capítol a causa de la seva importància.

Àlies:

Permet la definició de directoris virtuals, un directori virtual és un directori que es troba en un

directori diferent del que es mapeja en la URL. El directori virtual no es té perquè trobar dins

de l’arbre de directoris que es crea a partir de DocumentRoot, sinó que es pot trobar en

qualsevol altra ubicació, fins i tot es podria trobar en un altre servidor diferent.

Per exemple, quan s'escriu www.exabyteinformatica.com/manual/php la carpeta php no s'ha

de trobar necessàriament dins de la carpeta manual, que al seu torn està dins de la carpeta

arrel exabyteinformatica, sinó que pot estar en una ubicació diferent, i fora de l'arbre de

subdirectoris de la directiva DocumentRoot

Sintaxi:

Alias nomFictici ubicacióReal

Exemple:

Alias /manual/Wordpress "c:\Wordpress"

El directori Wordpress no es troba dins del directori manual dins de la carpeta documentRoot,

sinó en la carpeta o directori c:\Wordpress.

Per defecte vénen creats dos redireccionaments amb Àlies.

- Icons: per establir la carpeta on es troben les icones que utilitzarà l'Apache per mostrar el

contingut dels directoris.

- Manual: que apunta a la carpeta on està instal·lat el manual de l'Apache en cas que s'hagués

triat l'opció durant la instal·lació.

AliasMatch:

La utilitat d'aquesta directiva és idèntica a la de la directiva Alias, l'única diferència és que

Àlies utilitza expressions estàndard regulars per especificar la URL que es va mapejar.

Aspectes importants a tenir en compte en la seguretat d'Apache:

Autenticació i autorització d'usuaris amb Apache

Quan un servidor Apache rep una petició d'una pàgina web, abans de retornar el resultat, duu

a terme diverses accions per verificar que la petició està autoritzada.

Les diferents accions que duu a terme per verificar la validesa de l'aplicació, es poden agrupar

en tres tipus: autenticació, autorització i control d'accés.



L'autenticació és el procés pel qual es verifica la identitat d'una persona. D'una forma simple,

aquest procés es pot dur a terme mitjançant un nom d'usuari i una contrasenya, però es poden

arribar a utilitzar altres mètodes per validar la identitat d'una persona, com mitjançant l'ús de

certificats, targetes etc…

En Apache l'autenticació pot estar gestionada per diferents mòduls, depenent de la forma

d'implementació. Si decideix dur-la a terme gestionant fitxers amb llistes d'usuaris i

contrasenyes (xifrades), haurà d'utilitzar el mòdul mod_auth. No obstant això, si decideix dur-

la a terme mitjançant la base de dades, haurà d'utilitzar els mòduls mod_auth_dbm.

L'autorització és el procés pel qual es verifica que un usuari amb una identitat coneguda, té

accés al recurs sol·licitat. Per dur a terme aquesta acció, se solen utilitzar llistes de permisos en

les quals s'enumeren cadascuna de les accions que pot realitzar un usuari, o les que no pot fer.

Normalment, per simplificar la gestió d'aquests fitxers, els usuaris se solen unir en grups

proporcionant els permisos al grup.

En Apache l'autorització a recursos és gestionada o bé mitjançant la directiva en el fitxer

principal de configuració, o bé mitjançant la configuració de la carpeta a través de fitxers

.htaccess.

El control d'accés és el procés pel qual es verifica que la màquina des de la qual s'ha fet la

petició, té accés al recurs. Els controls d'accés s'utilitzen per limitar i controlar les màquines

que tenen accés a un recurs independentment de l'usuari que accedeix, ja que aquests

controls es duen a terme abans que es realitzi el procés d'autenticació.

En Apache, el control d'accés es pot dur a terme mitjançant les directives i , o a través del fitxer

de configuració .htaccess per controlar una carpeta especifica.

En tot cas i per poder dur a terme la configuració de les tres característiques aquí enumerades,

autenticació, autorització i control d'accés, és necessari tenir la directiva AllowOverride amb el

valor AuthConfig, per així permetre l'ús de les diferents directives d'autenticació.

Autenticació i autorització d'usuaris en Apache. Mod_auth

Per configurar el servidor Apache perquè sigui capaç d'autenticar als usuaris i verificar

l'autorització del mateix al recurs sol·licitat, és necessari realitzar les següents accions:

Crear un fitxer amb usuaris.

Crear un fitxer amb grups (si és necessari).

Definir les directives en el fitxer de configuració o mitjançant un fitxer .htaccess



En els fitxers d'usuaris d'Apache, en cada línia s'especifica un usuari, escrivint el nom d'usuari

separat de dos punts, seguit de la contrasenya xifrada amb MD5.

En els fitxers de grups d'Apache, en cada línia s'especifica un grup escrivint el nom del grup

seguit de dos punts, i a continuació separat per espais, els noms dels usuaris.

És recomanable que tant els fitxers d'usuaris com els de grups, es trobin emmagatzemats fora

dels directoris publicats, perquè d'aquesta forma ningú pugui descarregar-los. Així mateix,

només l'usuari root hauria d'estar autoritzat a escriure en ell, mentre que només l'usuari que

executa el servei web, hauria d'estar autoritzat per llegir-ho.

El fitxer de grups es pot crear manualment, però el fitxer amb els usuaris és recomanable

crear-ho mitjançant la utilitat htpasswd, que es troba en la carpeta amb els binaris d'Apache.

Per crear un fitxer d'usuari s'utilitzarà la següent sintaxi:

htpasswd -c ruta/passwords usuari

El paràmetre -c s'utilitza per crear un fitxer nou, per la qual cosa només s'haurà de posar la

primera vegada que es crea el fitxer, sinó ho esborrarà.

Els mòduls que intervenen en l'autenticació i autorització són els de core i mod_auth.

Les directives de mod_auth necessàries per configurar l'autenticació i autorització són les

següents:

AuthUserFile: serveix per especificar la ruta on s'emmagatzemarà el fitxer d'usuaris.

AuthGroupFile: serveix per especificar la ruta on s'emmagatzemarà el fitxer de grups.

Les directives de core necessàries per complementar la configuració del mòdul són:

AuthType: selecciona el tipus d'autenticació d'usuaris que s'utilitzarà per autenticar a un

usuari. Pot variar per directori. Els valors possibles són Basic i Digest. Amb Basic, la

transferència de les claus es farà sense xifrar, i amb digest es faran xifrades.

AuthName: especifica un nom del domini pel qual se sol·licita l'accés, aquest nom figurarà en

la pantalla on es demana la clau, i al seu torn servirà perquè el client identifiqui la contrasenya

que ha d'utilitzar en enviar una petició a un àrea determinada.

Require: selecciona els usuaris que poden accedir a un àrea determinada, els usuaris es poden

determinar a través de noms o grups.



Com protegir una carpeta i Autenticació i autorització d'usuaris amb MySQL i Apache

mod_auth_MySQL.

· Crear un fitxer de claus fora de la part pública:

-htpasswd -c /ruta/passwords Joan

En fer-ho, demanarà que s'introdueixi la clau, i aquesta serà codificada, escrivint el fitxer.

· Crear un nou fitxer, en la mateixa ubicació que "ruta", que es dirà "grups" en la qual

s'emmagatzemaran els grups, ara com ara un, per a això escriure la següent línia i guardar el

fitxer:

usuarisAutenticats: Joan

D'aquesta forma, hauria de tenir un fitxer que s’anomeni passwords, i que contingui una línia

amb les dades de l'usuari Joan, i un fitxer, amb el nom de grups, que conté una línia definint un

grup anomenat usuarisAutenticats, del que només l'usuari Joan forma part.

· Crear un fitxer amb el nom .htaccess en la carpeta que es vol protegir, escriure les següents

línies i guardar el fitxer:

AuthType Basic

AuthName "Nom_del_Servidor"

AuthUserFile /ruta/passwords

AuthGroupFile /ruta/grups

Require group usuarisAutenticats

L'explicació del contingut del fitxer és la següent:

Amb "AuthType Basic" s'estarà protegint la carpeta amb autenticació bàsica, és a dir que la

clau que l'usuari introdueixi, es transmetrà sense xifrar per la web.

Amb "AuthName "Nom_del_Servidor" s'associarà aquesta carpeta amb el domini "

Nom_del_Servidor ", nom amb el qual ho identificarà el client.

Amb "AuthUserFile /ruta/passwords" i "AuthGroupFile /ruta/grups" Es definirà la ubicació tant

dels fitxers d'usuaris com els fitxers de grups i s'emmagatzemaran en la carpeta /ruta, amb

noms passwords i grups respectivament.



Amb "Require group usuarisAutenticats" s'autoritzarà l'accés al contingut d'aquesta carpeta a

tots els usuaris que formen part del grup de "usuarisAutenticats", per la qual cosa en la

pràctica s'autoritzarà l'accés al contingut a l'usuari Joan.

En comptes de realitzar les autoritzacions a grups complets, es pot autoritzar a un usuari

determinat canviant l'última línia per "Require user Joan", d'aquesta forma només

s'autoritzarà a l'usuari Joan.

Es pot permetre l'accés a tots els usuaris identificats mitjançant la introducció de la següent

directiva "Require valid-user". El fet que aquesta directiva està inclosa en el fitxer, fa que les

altres no tinguin efecte.

Autenticació i autorització d'usuaris amb MySQL i Apache. mod_auth_MySQL

Anteriorment hem explicat com controlar l'autenticació i l'autorització d'usuaris amb el

mod_auth. Aquest mòdul té com a característica el que emmagatzema els noms d'usuari, les

contrasenyes i els grups en fitxers de text que han de ser escrits i gestionats per

l'administrador del sistema. Aquesta solució és òbviament poc escalable, ja que quan el

nombre d'usuaris i de grups és elevat, el gestionar-los i controlar-los pot ser un problema.

Per aquest motiu existeix el mod_auth_MySQL, aquest mòdul permet gestionar l'autenticació i

autorització, emmagatzemant els usuaris i els grups en taules de MySQL, de manera que fins i

tot es poden gestionar mitjançant un panell de control escrit en php.

Per configurar el mòdul en Linux, serà necessari extreure-ho i executar:

./configure --with-MySQL=/usr/local/MySQL --with-Apache=/usr/local/Apache

Substituint el lloc on es troba la instal·lació de MySQL i d'Apache.

Per utilitzar el mòdul és necessari disposar de com a mínim una taula on s'emmagatzemin els

usuaris i una altra on s'emmagatzemin els grups. Per a això es pot crear una taula usuaris amb

els camps, nom i password, i una altra taula anomenada grups amb els camps grup, usuari,

emmagatzemant una entrada per cada usuari que tingui un grup.

La configuració és la següent:

En primer lloc serà necessari establir el servidor, l'usuari i la contrasenya de la connexió amb la

base de dades, això es farà escrivint la següent línia en el fitxer httpd.conf, i reemplaçant els

valors pels correctes:

Auth_MySQL_Info

Per configurar el mòdul serà necessari establir els valors de les següents directives del mòdul:

Auth_MySQL_DB: nom de la base de dades.



Auth_MySQL_Password_Table: nom de la base de dades que conté els noms d'usuari i les

contrasenyes.

Auth_MySQL_Username_Field: nom del camp de la taula que conté a l'usuari.

Auth_MySQL_Password_Field: nom del camp de la taula que conté la contrasenya de l'usuari.

Auth_MySQL_Group_Table: nom de la taula que conté els usuaris i els grups als quals

pertanyen.

Auth_MySQL_Group_Field: nom del camp de la taula que conté el nom del grup.

Auth_MySQL_Empty_Passwords on/off per determinar si s'accepten usuaris amb contrasenyes

buides.

Auth_MySQL_Encryption_Types per especificar el tipus de xifrat que s'utilitzarà per

emmagatzemar la clau de l'usuari dins de la base de dades.

Auth_MySQL_Senar_Persistent on/off per especificar si es desitgen utilitzar connexions

persistents.

A més serà necessari establir les següent directives de core per al seu correcte funcionament:

AuthName: amb el nom del domini.

AuthType: establert a Basic.

Una vegada engegat, el funcionament és anàleg al mòdul mod_auth.

El mòdul de control d'accés d'Apache permet controlar l'accés als diferents directoris i fitxers

del servidor depenent del nom de la màquina o adreça IP del client.

Les directives que proporciona aquest mòdul es poden utilitzar dins dels elements , i del fitxer

de configuració httpd.conf, o bé dins de fitxers .htaccess situats dins de les carpetes.

Les directives amb les quals explica el mòdul per permetre o denegar l'accés són:

Allow: controla els servidors que tindran accés al contingut, per exemple:

Allow from exabyteinformatica.com Permet l'accés des de exabyteinformatica.com

Allow from 192.168.0.10 Permet l'accés des de 192.168.0.10

Allow from 192.168 Permet l'accés des de totes les adreces Ip que comencen per 192.168

Allow from all Permet tots els accessos.



Deny: controla els servidors als quals es denegarà l'accés, per exemple:

Deny from exabyteinformatica.com Denega l'accés des de exabyteinformatica.com

Deny from 192.168.0.10 Denega l'accés des de 192.168.0.10

Deny from 192.168 Denega l'accés des de totes les adreces IP que comencen per 192.168

Deny from all Denega totes les IP’s.

Order: determina l'ordre en el qual es llegiran els permisos, per exemple per llegir primer els

permesos i després els no permesos es posarà "Allow,Deny" en aquest cas si un servidor

aquesta en la llista de permesos, i en la de denegats, l'accés al mateix serà denegat, ja que

l'entrada dins de l'opció Deny sobreescriurà la de l'entrada Allow.

Cal tenir en compte que l'ús de order juntament amb Allow from all o Deny from all, permet

especificar configuracions com, permetre des d'una màquina qualsevol i denegar de la resta,

d'una forma molt senzilla.

Addicionalment, mitjançant la directiva SetEnvIf del mòdul mod_setenvif, es poden establir

variables d'entorn que determinin el funcionament de Allow o Deny de la mateixa forma que

s'utilitzen nombres IP o noms de màquines. Per exemple, utilitzant Allow from env=entrada

permetrà l'accés a totes les peticions que tinguin definida la variable d'entorn "entrada".

Controlar accés depenent del navegador amb Apache

Mitjançant l'ús conjunt de les directives Allow, Deny, Order i SetEnvIf es pot restringir l'accés a

un lloc depenent del tipus de navegador. Per realitzar-ho simplement n'hi ha prou amb crear

una variable d'entorn depenent del tipus del navegador, i permetre l'accés a les peticions que

comptin amb aquesta variable d'entorn denegant-li-ho a la resta.

Per a això la configuració necessària és la següent:

SetEnvId User-Agent googlebot entrar

Order Deny, Allow

Deny from all

Allow from env=entrar

En la primera línia s'especifica que es crearà una variable d'entorn anomenada entrar quan el

navegador sigui el motor d'indexació de Google.

En la segona línia s'especifica l'ordre en el qual s'utilitzarà la llista de servidors, primer els

denegats i després els permesos.



En la quarta línia s'especifica que es denega l'accés a qualsevol petició.

En la cinquena línia s'especifica que es permet l'accés a les peticions que tenen definida la

variable d'entorn entrar.

En el cas que entri el motor d'indexació de Google, primer es llegirà la línia en què es

deneguen totes les peticions, per a continuació llegir la línia en la línia en la qual es permet

l'accés des de les peticions que tenen definida la variable entrar, com el navegador que ho fa

és el googlebot, aquesta variable estarà definida i entrarà.

En el cas en què la petició sigui realitzada per qualsevol altre navegador, primer es llegirà la

línia en la qual es deneguen les peticions, i com no satisfà la línia en què ho permet, no

entrarà.

En aquest document anem a ensenyar a utilitzar una API d'Apache per gestionar les

configuracions de les vostres aplicacions de manera avançada.

Alguna vegada has implementat classes que gestionessin directament dades de configuració?

Si la resposta és afirmativa, segurament hagis reinventat la roda.

Existeixen diverses formes estàndard de gestionar les dades de configuració dels nostres

components i aplicacions:

Mitjançant la classe java.util.Properties

A través de les classes del paquet java.util.prefs. (API molt potent que permet gestionar dades

de configuració de manera jeràrquica a l'estil del "Registre de Windows" que recomano llegir si

la desconeixes).

Hi ha una API que és d'enorme utilitat i potència per a la gestió de dades de configuració. Es

tracta d'Apache Jakarta Commons Configuration.

Apache Jakarta Commons Configuration és un sub-projecte de la sèrie de projectes Apache

Jakarta Commons.

Commons Configuration és un conjunt de projectes que intenten estandarditzar les tasques

comunes que gairebé totes les aplicacions i components realitzen normalment.

Una tasca molt comuna en qualsevol aplicació és la gestió de dades de configuració. És aquí on

entra en joc Apache Jakarta Commons Configuration.

Podem obtenir tot el necessari des de la següent adreça:

http://jakarta.apache.org/commons/configuration/

Bàsicament Apache Commons Configuration ens permet:

Gestió de les dades de configuració independentment del lloc en el qual estiguin

emmagatzemades. (Fitxers de propietats, documents XML, base de dades, etc.).

Un potent motor de consultes per realitzar cerques del valor que tenen determinades

propietats de configuració.



Recarrega automàtica de les dades de configuració en cas de que siguin modificades en el seu

lloc físic d'origen (Fitxer de text pla, fitxer XML, etcètera...).

Possibilitat d'emmagatzemar les dades de configuració automàticament en el seu lloc físic

(fitxer de text pla, fitxer XML, etc).

Alguns exemples:

Abans de res, ressaltem que aquesta secció és només una introducció al API, i que ha de

documentar-se en la Web oficial del API per veure totes les possibilitats que ens proporciona..

Exemple:

Suposem que tenim el següent fitxer de propietats, en el qual es defineixen dades de

configuració relacionades amb l'interfície gràfica de l'aplicació.

app.windows.properties:

mainmdi.title=Títol de la meva aplicació de prova

mainmdi.width=1024

mainmdi.height=768

mainmdi.state=maximized

userform.title=Gestió d'usuaris

userform.width=640

userform.height=480

userform.state=normal

language=Català

language=English

language=French

Doncs a través de Commons Configuration, podríem accedir a les propietats de la següent

forma:

try {

// Llegim les dades de configuració. El fitxer ha d'estar en el mateix directori que l'aplicació.

PropertiesConfiguration config = new PropertiesConfiguration("app.windows.properties");



// La següent sentència imprimirà: 1024

System.out.println(config.getInt("main.mdi.width"));

// La següent sentència imprimirà: Títol de la meva aplicació de prova

System.out.println(config.getString("main.mdi.title"));

// La següent sentència imprimirà: Català

System.out.println(config.getStringArray("language")[0]);

// La següent sentència configura l'objecte perquè salvi les propietats

// automàticament a l'origen (En aquest cas un fitxer) quan s’actualitzen

// o quan s’afegeixen noves propietats

config.setAutoSave(true);

// Afegim un parell de propietats

config.addProperty("version", "1.0");

config.addProperty("author", "Nom_de_l’autor");

// No fa falta gràcies a que està establerta la propietat autoSave

// config.save();

} catch (ConfigurationException ex){

System.out.println(ex);

}

Altres Característiques interessants

Aquest API també ens dóna la possibilitat que es recarregin automàticament les dades de

configuració sobre l'objecte Configuration en cas que aquests hagin estat modificats.



Per habilitar aquesta característica haurà d'indicar-ho mitjançant la següent línia de codi:

config.setReloadingStrategy(new FileChangedReloadingStrategy());

Conclusions

Aquesta API és més completa, potent i flexible que la resta de APIS o mètodes per gestionar

dades de configuració.

Encara que java.util.prefs proporciona una funcionalitat i potència similar a Commons

Configurations, les dades de configuració en java.util.prefs només poden ser modificades des

d'aplicacions i no manualment, doncs entre altres coses no se sap on guarda realment aquest

API les dades de configuració.

Quan utilitzem objectes Properties per gestionar les propietats, hem de realitzar conversions

de tipus de dades, amb aquest API ens estalviem aquest treball.

Per comentar alguna cosa negativa, aquesta API depèn d'altres sub-projectes de Jakarta, per la

qual cosa hem d'incloure els seus JAR’s associats si volem usar-ho. Per exemple, per usar les

funcions bàsiques, el API depèn de:

Apache Jakarta Commons Lang

Apache Jakarta Commons Collections

Apache Jakarta Commons Loggin

Aquestes són 20 recomanacions per optimitzar la seguretat en el teu servidor Apache

De la mateixa manera has de tenir en compte que algunes d'aquestes recomanacions poden

disminuir el rendiment del teu servidor depenent de la teva configuració i de les

especificacions del sistema.

Primer, assegura’t de tenir instal·lat els últims pegats de seguretat.

No té sentit posar un pany mes resistent a la teva porta si deixes la finestra oberta. De la

mateixa manera si no tenim els últims pegats de seguretat instal·lats no tindria sentit

continuar amb l'optimització de seguretat.



Restringir l’accés per IP

Si tens un recurs al que hagi de només tenir accés alguna xarxa, o IP en concret pots

configurar-ho en Apache. Per exemple si desitges restringir l'accés a la teva Intranet per

permetre nomès la xarxa 192.168:

Order Deny,Allow

Deny from all

Allow from 192.168.0.0/255

o per IP:

Order Deny,Allow

Deny from all

Allow from 127.0.0.1

Ocultar la versió i una altra informació delicada

Per defecte moltes instal·lacions d'Apache mostren el nombre de versió que està funcionant, el

sistema operatiu i un informe de mòduls d'Apache estan instal·lats en el servidor. Els usuaris

maliciosos poden utilitzar aquesta informació per atacar el teu servidor.

Hi ha dues directives que necessites afegir o corregir en el teu arxiu de httpd.conf:

ServerSignature Off

ServerTokens Prod

El ServerSignature apareix en la part inferior de les pàgines generades per Apache tals com els

famosos errors 404.

La directiva ServerTokens s'utilitza per determinar-se el que posarà Apache en la capçalera de

la resposta HTTP del servidor.



Apache ha de funcionar sota el seu propi compte i grup d'usuari

Algunes versions d'Apache corren sota l'usuari nobody, això compromet molt la seva seguretat

per tant fes el següent:

User Apache

Group Apache

Utilitza el mod_security

El mod_security és un mòdul fantàstic d'Apache escrit per Ivan Ristic, l'autor d'Apache Security

d'O'Reilly.

Aquesta és una llista de coses que pots fer amb mod_security:

Filtració simple.

Filtració basada en expressions regulars.

Validació de codificació de la URL.

Validació de codificació Unicode.

Auditoria.

Prevenció de l'atac NULL Byte.

Limitar la memòria de pujada.

Emmascarar la identitat del servidor.

I més...

Deshabilitar qualsevol mòdul innecessari

Apache ve per defecte instal·lat amb un sèrie de mòduls. Has de fer-li un cop d'ull a la

documentació d'Apache i veure perquè serveix cadascun d'ells, i d'aquesta manera t'adonaràs

que hi ha alguns que no són útils en el teu servidor.

Cerca en httpd.conf les línies que continguin LoadModule. Per deshabilitar el mòdul has

d'afegir un # al principi de la línia, perquè d'aquesta forma passi a ser un comentari. Per

buscar els mòduls prova amb:



grep LoadModule httpd.conf

Aquí estan alguns mòduls que s'instal·len per defecte però sovint no són necessaris:

mod_imap, mod_include, mod_info, mod_userdir, mod_status, mod_cgi, mod_autoindex.

Assegura’t de que els arxius als quals s'accedeix són els desitjats.

No desitgem que es pugui accedir als directoris que no tinguin permisos per a això, suposem

que el directori arrel per les nostres webs és /web, la configuració òptima hauria de ser la

següent:

Order Deny,Allow

Deny from all

Options None

AllowOverride None

Order Allow,Deny

Allow from all

Desactiva les opcions per explorar directoris

Això ho pots fer amb les opcions de directiva dins de l'etiqueta directori té dos possibles

valors: none o index.

Options -Index

Desactiva els includes del costat del servidor.

Això també es fa amb les opcions de directiva dins de l'etiqueta directori té dos possibles

valors: none o include.

Options -Includes

Desactiva l'execució de CGI.

Si no necessites l'execució de CGI per algun motiu en concret desactiva’ls es fa amb les opcions

de directiva dins de l'etiqueta directori té dos possibles valors: none o ExecCGI.

Options –ExecCGI



No permetre que Apache segueixi enllaços simbòlics

De nou es configura amb les opcions de directiva dins de l'etiqueta directori té dos possibles

valors: none o FollowSymLinks.

Options -FollowSymLinks

Desactivar totes les opcions.

Si desitges desactivar l'ús de totes les opcions simplement:

Options None

Si solament desitges desactivar algunes en concret, separa-les amb un espai en les opcions de

directiva:

Options -ExecCGI -FollowSymLinks -Indexis

Desactivar l'ajuda per als arxius .htaccess

Això està fet ja però amb la directiva AllowOverride. Canvia-ho a none.

AllowOverride None

Una altra opció interessant seria bloquejar la descàrrega de tots els arxius que comencin amb

.ht per exemple, es faria de la següent manera:

AccessFileName .httpdoverride

Order allow,deny

Deny from all

Satisfy All

Disminueix el valor màxim de temps d'espera

Per defecte el temps d'espera és de 300 segons. Pots disminuir-ho per seguretat per prevenir

atacs d'aquesta manera:

Timeout 45



Limitar la grandària màxima de peticions

Apache té diverses directives que permeten que limitis la grandària d'una petició, això pot ser

molt útil.

Una bona manera de començar és amb la directiva LimitRequestBody. Aquesta directiva està

fixada a il·limitat per defecte. Si estàs permetent uploads d'arxius que no siguin majors a 1

Megabyte, podries fixar aquest ajust a alguna cosa semblat a això:

LimitRequestBody 105000

Si no estàs permetent uploads d'arxius pots fixar-ho fins i tot a una grandària més petita.

Alguns altres directives a mirar són LimitRequestFields, LimitRequestFieldSize i

LimitRequestLine.

Conclusió

Espero que aquestes recomanacions us hagin estat útils i recorda que l'ús que li has de donar

depèn en gran mesura dels recursos que necessites i de les característiques del teu servidor,

abans de fer qualsevol canvi si no estàs segur documenta't i utilitza aquest article únicament

com una referència perquè et porti a la solució més ideal.

Solució a un problema en dominis allotjats en servidors amb el panell de control Plesk

Relatiu a la directiva de PHP open_basedir.

Estem utilitzant un nou servidor que té suport per PHP 5. (Fins al moment estàvem treballant

amb PHP 4, però ja era hora de canviar). Com sempre, migrar a un nou servidor porta els seus

problemes, però afortunadament amb l'ajuda del suport tècnic i amb la documentació que es

troba per Internet, es van arreglant.

En aquest article us explicarem un error que hem trobat a l'hora de configurar el domini, que

després s’ha vist que és comú a moltes persones que tenen el panell de control Plesk com a

gestor dels recursos del servidor. Així doncs vaig a intentar expressar el problema i la solució

que hem trobat.

El problema amb open_basedir

Plesk té una configuració pròpia de la directiva de PHP open_basedir (que es defineix en el

php.ini). Per la configuració de Plesk de open_basedir, només es poden incloure arxius que

pengin del directori de publicació del domini, és a dir el directori httpdocs del domini.

L'estat de open_basedir configurat per Plesk de manera predeterminada és el següent:



open_basedir = "/var/www/vhosts/elteudomini.com/httpdocs:/tmp"

Per aquesta directiva no es poden incloure arxius (amb la funció include o require de PHP) que

estiguin en altres carpetes o sub-carpetes que pengin de les marcades en el open_basedir.

Nosaltres tenim algunes carpetes que contenen codis font i no s'estaven podent incloure. Per

això ens saltava sovint un error PHP com a aquest:

open_basedir restriction in effect. File(./../directori-fonts-httpdocs/arxiu.php) is not within the

allowed path(s): (/var/www/vhosts/elmeudomini.com/httpdocs:/tmp)

Després es va veure que aquest problema ho tenen també usuaris que tinguin codis inclosos

en frameworks per PHP com PEAR.

Solució al problema: configurar Plesk

La primera aproximació a la solució va ser, com es va pensar, modificar l'arxiu PHP.ini. De fet,

és el que pensava que ho arreglaria. Per canviar la directiva open_basedir del php.ini. Però els

canvis, no van fer efecte. També vaig provar canviant la directiva include_path, però tampoc es

va arreglar gens.

Una vegada consultat amb el servei tècnic del nostre proveïdor, ens van aconsellar moure

totes les carpetes al directori de publicació, però això no és possible, per diverses raons. Però

ens van donar la pista que el problema estava relacionat amb Plesk.

Finalment buscant per Pear i Plesk en Google va aparèixer un article molt interessant en una

pàgina en anglès: How to: Enable PEAR/Set open_basedir.

En aquest article s’expressa pas a pas el que s'ha de fer, que resumint seria:

Existeix un arxiu que Plesk utilitza per configurar cada domini, de manera que no convé tocar

el php.ini, perquè això afectaria a tot el servidor (i no sempre, perquè algunes directives, com

open_basedir, després les sobre-escriu Plesk en altres arxius apart i per molt que es toquin en

el php.ini no tindrà cap efecte).

Hi ha un lloc on s'han de configurar els canvis del php.ini, específics per a cada domini allotjat.

En el meu cas aquest arxiu de configuració no estava creat, per la qual cosa he hagut de crear-

ho. L'arxiu de configuració específic per a cada domini està en el directori

/var/www/vhosts/midominio.com/conf

I l'arxiu que cal crear allí, o modificar si és que ja existeix és:

vhost.conf

Perquè funcioni, el contingut de l'arxiu que he col·locat és el següent:



php_admin_value open_basedir

"/var/www/vhosts/elmeudomini.com/httpdocs:/tmp:/var/www/vhosts/elmeudomini.com/dir

ectori_includes

php_admin_value display_errors On

Es tracta simplement de definir el open_basedir marcant tots els directoris on hi ha arxius que

es pretenen incloure des de PHP. (Amb incloure un directori et permet incloure arxius de tots

els subdirectoris que hi hagi dins).

En el codi anterior pots veure que hem modificat un altre paràmetre del PHP:

display_errors On (Això és per poder veure els errors directament a la pàgina, en comptes del

log d'errors, que és més còmode almenys durant les proves i fins a migrar definitivament el

domini).

Ara bé, ja sabem on tocar per configurar directives PHP del php.ini específiques per a un

domini allotjat. Podrem definir totes les directives que es necessitin. Per exemple, una altra

cosa que es pot necessitar canviar és anul·lar el safe_mode per a un domini en concret i això es

pot fer des d'aquest mateix arxiu amb la línia:

php_admin_value safe_mode Off

Perquè els canvis tinguin efecte àdhuc hem de realitzar un parell de passos.

Es tracta primer de dir-li a Plesk que actualitzi la configuració d'un domini. Això es fa amb la

instrucció:

/usr/local/psa/admin/sbin/websrvmng --reconfigure-vhost --vhost-name=elmeudomini.com

Ara també haurem de reiniciar l'Apache, que es pot fer amb la instrucció:

/etc/init.d/httpd restart

O bé amb la instrucció:

service httpd restart

Això és tot, ara hauria de funcionar.



Què és la compressió per GZIP d'un lloc web, com funciona i de quina manera ajuda en

l'optimització de la descàrrega d'una pàgina

La compressió per GZIP és una de les possibilitats més importants per optimitzar un lloc web,

per buscar un millor acompliment en la càrrega de les pàgines. Consisteix a enviar els codis del

lloc en format comprimit, perquè ocupin molt menys espai i per tant es transfereixin per la

xarxa d'una manera més ràpida.

Tenim vàries formes de definir que s'enviïn comprimits els arxius de la pàgina. La manera més

normal és configurar el servidor web on estigui allotjada la pàgina, ja sigui Apache, IIS o

qualsevol altre sistema, per marcar que s'utilitzi algun dels mètodes de compressió per als

arxius. Encara que en ocasions espanta una mica això de configurar el servidor web, us podem

avançar que aquesta configuració és molt senzilla de realitzar i al llarg de l’article anem a

explicar detingudament com realitzar-la de diverses maneres.

Una altra manera d'enviar els arxius comprimits és programar nosaltres mateixos aquesta

funcionalitat amb algun mòdul a la teva pàgina realitzada en llenguatges del servidor com PHP.

Aquest mòdul que podries programar s'encarregaria de comprimir els arxius i enviar-los

comprimits al client web, però aquestes tècniques només serien recomanades si no tenim la

possibilitat de configurar directament el servidor web. D'ara endavant veurem de quines

maneres que es poden enviar els arxius comprimits amb algun llenguatge de programació.

En definitiva, veurem maneres diferents d'aconseguir aquesta configuració i així qualsevol

persona, en qualsevol àmbit de treball, pugui optimitzar la distribució dels continguts de la

seva pàgina amb GZIP.

Avantatges de comprimir amb GZIP

L'avantatge de comprimir amb GZIP el nostre lloc web és que serà menys pesat en KB, la qual

cosa derivarà al seu torn en altres avantatges importants:

Estalvi d'ample de banda / transferència: el nostre lloc web enviarà arxius comprimits i per

tant, la transferència que utilitzarà per enviar una mateixa pàgina, serà molt millor que si no

estigués comprimida. Al cap del mes, sobretot en llocs web amb bastant tràfic, s'obtindrà un

estalvi considerable en transferència.

Velocitat del lloc: els arxius comprimits trigaran menys a arribar als seus destinataris, per tant

el lloc carregarà amb major rapidesa. Si estem optimitzant el lloc a la recerca de millorar el

temps de càrrega, la compressió amb GZIP serà una de les més importants opcions que

tindrem a la nostra disposició i podrem configurar-la en pocs minuts.

Suport en tots els navegadors actuals: avui dia podem estar tranquils amb la compatibilitat de

la compressió amb GZIP, ja que tots els navegadors actuals la implementen.

En realitat, comprimir els arxius amb GZIP sempre ens porta avantatges interessants que faran

que nostre lloc web funcioni més de pressa, per la qual cosa resultarà positiu en qualsevol cas.



L'únic marc que podria donar problemes és que el navegador que està utilitzant el visitant no

accepti compressió a les pàgines, però realment en el panorama actual de navegadors això és

poc probable. Per tant, tret que el teu lloc web hagi de ser compatible amb, per exemple, la

versió 3 d'Internet Explorer, pots utilitzar-la sense problemes.

De qualsevol forma, el nostre servidor pot enviar els arxius comprimits només als navegadors

que suportin aquest format. Pel que no hauria de preocupar-nos ni tan sols aquesta possibilitat

d'un navegador no compatible.

Llocs web populars com Yahoo.com o Google comprimeixen les pàgines amb GZIP abans

d'enviar-les al client web, per la qual cosa resulta clar que nosaltres també hem d'aprofitar

aquesta possibilitat d'optimització de la web. De fet, no fer-ho, significa que estem perdent

una oportunitat molt bona per fer que el nostre lloc sigui més ràpid.

Per posar un parell d'exemples, la portada de Yahoo.com en aquest moment ocupa 149 Kb.,

però com s'envia comprimida, en realitat només es transfereixen 28 Kb..

exabyteinformatica.com, el lloc on estem publicant aquestes informacions, ocupa en la seva

home page 92 KB i en enviar-se comprimida la pàgina per GZIP en realitat només es

transfereixen 43 KB. Això vol dir que estem estalviant més d'un 40% de la transferència que en

principi seria necessària si no ho comprimíssim.

Com podem crear un arxiu .htaccess per configurar Apache i demanar-li que enviï tots els

arxius, menys les imatges, comprimides amb GZIP?

Després d'haver llegit el Manual de compressió amb GZIP d'un lloc web ja hem de tenir una

idea sobre els avantatges de comprimir les pàgines i altres recursos abans d'enviar-los al

navegador. A més, hem conegut ja diversos mètodes de fàcil configuració per aconseguir

aquesta compressió GZIP a les pàgines PHP i altres arxius externs com JS o CSS.

En aquest article anem a continuar explorant possibilitats de configuració del nostre servidor

web Apache, també per mitjà d'un arxiu .htaccess, que és la manera més senzilla i a l'abast

d'un major nombre de persones. En concret anem a mostrar com definir en una sola instrucció

que es comprimeixin tots els arxius menys les imatges.

Potser alguns de vosaltres es preguntin: Per què no comprimim les imatges? I és que realment,

com ja havíem assenyalat en aquest manual, les imatges ja estan comprimides, ja que els

arxius gràfics utilitzats en web tenen tots un nivell de compressió. Per tant, comprimir un GIF

amb GZIP no tindrà pràcticament millora alguna, doncs el pes de l'arxiu comprimit serà

pràcticament el mateix que el GIF original. A més, representarà un esforç per al processador

del servidor web, que haurà de comprimir aquests arxius abans d'enviar-los al client. Al final, el

rendiment del servidor pot veure's reduït, per haver de comprimir totes les imatges, i realment

no haurem avançat en gens, ja que les imatges ocuparan gairebé el mateix espai en KB. Això

passa amb qualsevol tipus d'arxiu gràfic, no només amb els GIF, sinó amb altres utilitzats per

fer webs, com JPG o PNG.



Instrucció htaccess per comprimir un tipus de mitjà

Existeix una instrucció que s'insereix en el codi dels htaccess que serveix per definir la

compressió GZIP / DEFLATE. La instrucció es diu AddOutputFilterByType i hem d'indicar-li

després el tipus de compressió i el tipus de mitjà que desitgem comprimir.

Per exemple, amb aquesta línia de codi comprimiríem tots els arxius de text pla:

AddOutputFilterByType DEFLATE text/plain

Si desitgem, podem comprimir tots els arxius HTML amb aquesta línia de codi en el htaccess.

AddOutputFilterByType DEFLATE text/html

A continuació podem veure una sèrie de línies amb diferents tipus de mitjans que s'estan

indicant per comprimir:

AddOutputFilterByType DEFLATE text/xml

AddOutputFilterByType DEFLATE text/css

AddOutputFilterByType DEFLATE application/javascript

AddOutputFilterByType DEFLATE application/x-javascript

AddOutputFilterByType DEFLATE application/xml

AddOutputFilterByType DEFLATE application/xhtml+xml

AddOutputFilterByType DEFLATE application/rss+xml

Amb aquest mètode, Apache serà prou intel·ligent per enviar els arxius comprimits només per

als navegadors que suporten aquesta optimització i nosaltres no hem de fer res perquè tot

funcioni correctament.

Entre els dos mètodes GZIP / DEFLATE podem triar qualsevol d'ells. Deflate és bastant ràpid i

compatible amb més versions de navegadors antics.

Com configurar i personalitzar la pàgina d'error 404, de pàgina no oposada, en el servidor

Apache amb la directiva ErrorDocument

Les pàgines d'error 404 són tan típiques que és possible que tots les coneguem sense parlar

més d'elles. Penso que és difícil trobar algú que navegui habitualment per la xarxa i no hagi



reparat en elles en alguna ocasió, però així i tot la persona que desitgi saber una mica més, pot

consultar què diuen els usuaris de la Wiki en l'entrada sobre l'error 404.

Apache, el servidor web més utilitzat mundialment, ofereix una senzilla manera de configurar

les pàgines d'error, accessible fins i tot per a les persones que menys experiència tenen quant

a desenvolupament de pàgines web. En aquest article veurem dues possibles maneres de dir-li

al nostre servidor web Apache la pàgina que desitgem es mostri en el cas que es produeixi un

error 404.

En principi, les dues possibilitats que veurem són independents una de l'altra, per la qual cosa

podrem triar la que més ens convingui, o la que suporti el nostre espai d'allotjament. Les dues

maneres passen per configurar la variable de sistema "ErrorDocument", que serveix per indicar

el document HTML que ha de lliurar-se quan sorgeixi un error de pàgina no oposada.

Nota: de manera predeterminada, en produir-se un error 404, Apache mostra una pàgina

d'error molt simple, que la veritat és que no ofereix a l'usuari molta informació útil que li

serveixi per detectar el motiu de l'error. Per això, pot merèixer la pena configurar la nostra

pròpia pàgina d'error 404 personalitzada.

Configuració de l'error 404 en el httpd.conf

La primera possibilitat per configurar la pàgina d'error 404 és editar l'arxiu principal de

configuració d'Apache, anomenat httpd.conf. Aquest arxiu és bastant llarg i conté centenars de

configuracions possibles per al servidor web. En el Manual d'Apache ja vam veure diversos

articles sobre els quals tractem aquest arxiu httpd.conf i les variables principals per a la seva

configuració. En concret, recomanem llegir l'article Directives de funcionament en httpd.conf.

L'única cosa que haurem d'afegir és una línia on indiquem la ruta de l'arxiu que envia en

produir-se un error de recurs no oposat, per mitjà de la variable "ErrorDocument".

ErrorDocument 404 /mipagina404.html

En aquest cas, s'indicaria que, sota un error 404, s'ha d'enviar el document que està en l'arxiu

"lamevapàgina404.html" (o qualsevol altre document que vulguem utilitzar com a pàgina

d'error). La ruta indicada cap a l'arxiu comença per "/", per la qual cosa Apache entendrà que

el mateix està en l'arrel del domini.

Nota: Abans d'afegir aquesta línia, hauríem de comprovar si existeix en alguna part de l'arxiu

httpd.conf una referència anterior a aquesta directiva, fent una cerca pel text

"ErrorDocument" dins de l'arxiu. Però tenir en compte que en l'arxiu httpd.conf totes les línies

que comencen per "#" són comentaris.

Recordar també que, perquè els canvis en el httpd.conf facin efecte, hem de guardar l'arxiu i

després reiniciar el servidor Apache.



Configuració de la pàgina d'error 404 per .htaccess

En la majoria dels casos que puguem trobar-nos, en els plans d'allotjament per a la nostra web,

no ens permetran editar el httpd.conf, ja que aquest arxiu conté moltes directives de

configuració crítiques, que mal editades podrien donar lloc a funcionaments erronis del

servidor. Per això, per configurar el nostre espai de hosting en Apache segurament ens vindrà

molt millor aquesta segona opció.

La segona possibilitat es tracta simplement de crear un arxiu que s’anomeni .htaccess (l'arxiu

comença per ".", com si no tingués nom i només s'indica aquesta extensió), on col·locarem la

directiva de configuració "ErrorDocument".

L'arxiu .htaccess es col·locarà en l'arrel del domini i tindrà el següent contingut.

ErrorDocument 404 /error404.html

Com es pot veure, s'indica també la ruta on estaria la pàgina d'error en el nostre sistema. En

aquest cas en un arxiu anomenat error404.html, que estaria en l'arrel del domini. Òbviament,

cada persona col·locarà el nom d'arxiu que vulgui utilitzar com a error 404 i la ruta on es trobi

aquest arxiu dins del domini.

Nota: Si disposem ja d'un arxiu .htaccess en la nostra arrel del domini, simplement haurem

d'editar-ho per incorporar aquesta línia.

Conclusió i altres referències sobre error 404

A partir de que hàgim realitzat aquesta configuració podrem accedir a qualsevol pàgina que no

existeixi, o qualsevol altre tipus de recurs, com una imatge, i veure que Apache ens mostra des

de llavors l'arxiu que hàgim configurat per expressar l'error 404.

Com dèiem, els errors 404 són bastant típics i gràcies a aquesta tècnica podem utilitzar-los per

redireccionar a l'usuari cap a altres continguts o explicar-li els motius de l'error, així com oferir-

li possibles accions per solucionar-los o trobar allò que buscava.

Presentació del servidor Apache

Documents

Transcript of Presentació del servidor Apache