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

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (12)

Similar to Presentació del servidor Apache

Similar to Presentació del servidor Apache (20)

More from Roger Casadejús Pérez

More from Roger Casadejús Pérez (20)

Presentació del servidor Apache