Apache

De Jose Castillo Aliaga
Ir a la navegación Ir a la búsqueda

El protocol HTTP (HyperText Transfer Protocol) és un protocol de capa d'aplicació per a la comunicació fonamentalment de la World Wide Web. Encara que hui en dia el seu ús és més divers. S'ha convertit en un estàndard per a la comunicació entre el model i la vista en alguns projectes en moltes tecnologies actuals. El seus usos principals són:

  • Pàgines web
  • Publicació senzilla de fitxers per a descarregar.
  • Comunicació entre client-servidor en aplicacions web, mòbils o altres. (XML, Json)

El protocol HTTP, si es combina amb una capa segura SSL, s'anomena HTTPS i permet una comunicació segura.

Un servidor http necessita:

  • Connexió a Internet
  • Espai en disc
  • Suficient potència per servir simultàniament a molts usuaris en moments puntuals.
  • Un servidor web/http generalment crea un procés nou per cada petició.

Conceptes

  • URL: Uniform Resource Locator

Una URL informa de:

  • El nom DNS de la màquina en la que està el recurs.
  • El protocol en el que es demana (http, https, ftp...)
  • La direcció del recurs en la màquina o la manera d'accedir a aquest recurs.

Una URL per a HTTP completa pot ser:

  http://www.exemple.com:80/~jose/privada/login.php
   ^      ^    ^          ^   ^     ^        ^
   |      |    |          |   |     |        |
Protocol  |  Domini     Port  |  Directori  Document php (retornarà un html)
          |                   |     
          |       Alias de directori personal
   (World Wide Web)

HTTP

El protocol de transferència d’hipertext (HTTP, hyperText transfer pro-tocol) és el motor que dóna vida a Internet, ja que és la base per a la web (www,world wide web).

És en els inicis del protocol HTTP, a mitjans de l’any 1990, quan trobem la versió 0.9. Aquesta versió tenia com a única finalitat transferir dades per Internet en forma de pàgines web escrites en llenguatge de marcatge d’hipertext (HTML, Hyper Text Markup Language). A partir de la versió 1.0 del protocol va sorgir la possibilitat de transferir missatges amb encap- çalaments que descrivien el contingut dels missatges.

El protocol de transferència d’hipertext (HTTP) és un protocol client-ser- vidor força senzill que articula els intercanvis d’informació entre els clients web i els servidors HTTP. HTTP va ser desenvolupat pel consorci W3C i la IETF. Aquesta col·laboració va culminar l’any 1999 amb la publicació d’una sèrie de RFC, el més important dels quals va ser el RFC 2616, que especi- ficava la versió 1.1. Des del punt de vista de les comunicacions, està suportat en els serveis de connexió TCP/IP i funciona de la mateixa manera que la resta de serveis propis dels entorns UNIX.

Tècnicament, un procés servidor escolta en un port de comunicacions TCP (per defecte, el 80) i espera les sol·licituds de connexió dels clients web. Una vegada establerta la connexió, el protocol TCP s’encarrega de mantenir la comunicació i garantir un intercanvi de dades lliure d’errors.

El protocol de transferència d’hipertext es basa en operacions senzilles de sol·licitud/resposta. Quan un client estableix una connexió amb un servi- dor i envia un missatge amb les dades de la sol·licitud, el servidor respon amb un missatge similar, que conté l’estat de l’operació i el seu resultat possible. Totes les operacions poden adjuntar un objecte o recurs sobre el qual actuen; cada objecte web (document HTML, arxiu multimèdia o apli- cació CGI) és conegut pel seu localitzador uniforme de recursos (URL, uniform resource locator). Els recursos poden ser arxius, el resultat de l’execució d’un programa, una consulta a una base de dades, la traducció automàtica d’un document, etc.

HTTP és un protocol sense estat, és a dir, no guarda cap informació sobre connexions anteriors. El desenvolupament d’aplicacions web freqüent- ment necessita mantenir estat. Per això s’utilitzen les galetes ( cookies), és a dir, la informació que un servidor pot emmagatzemar en el sistema client. Això permet que les aplicacions web institueixin la noció de “ses- sió”, i, alhora, permet rastrejar usuaris, ja que les galetes es poden emma- gatzemar en el client durant un temps indeterminat

Versions

  • 0.9: Transferir html
  • 1.0: Transferir imatges i comunicació Client -> Servidor amb POST
  • 1.1: Múltiples peticions per connexió i connexions persistents
  • 2.0: (2015) Millores de rendiment i compresió. Sols funciona en https.

Etapes d'una comunicació en HTTP

  1. Un usuari accedeix a una adreça d’Internet (URL) seleccionant un enllaç d’un document HTML o introduint-la directament a la barra de navegació d’un navegador web des de la perspectiva del client web.
  2. El client web descodifica l’adreça d’Internet (URL) separant-ne les diferents parts. És així com s’identifiquen el protocol d’accés, l’adreça del servidor de noms de domini (DNS, Domain Name Server) o d’Internet (IP) del servidor, el possible port opcional (el valor per defecte és el 80) i l’objecte del servidor requerit.
  3. S’obre una connexió TCP/IP amb el servidor cridant el port TCP corresponent. Es fa la petició. En conseqüència, s’envien l’ordre necessària (GET, POST, HEAD, etc.), l’adreça de l’objecte requerit (el contingut de l’adreça d’Internet del servidor), la versió del protocol HTTP utilitzada (en la major part de les ocasions és HTTP/1.0) i un conjunt variable d’informació que inclou dades sobre les capacitats del navegador web, dades opcionals per al servidor, etc.
  4. El servidor retorna la resposta al client. Aquesta resposta consisteix en un codi d’estat i el tipus de dada amb extensions multipropòsit de correu d’Internet (MIME, Multipurpose Internet Mail Extension) de la informació de tornada, seguit de la mateixa informació.
  5. Es tanca la connexió TCP. Aquest procés es repeteix en cada accés que es faci al servidor HTTP. Per exemple, si es recull un document HTML que conté quatre imatges, el procés de transició mostrat amb anterioritat es repeteix cinc vegades, és a dir, una pel document HTML i quatre per les imatges.

Missatge de petició

El missatge de petició està format per:

  • Línia de petició, com GET /images/logo.gif HTTP/1.1, que sol·licita un recurs anomenat /images/logo.gif al servidor
  • Capçaleres, com ara Accept-Language: ca (En el cas de HTTP/1.1 cal dir el HOST)
  • Una línia en blanc
  • El cos del missatge (opcional)

Exemple:

 GET / HTTP/1.1 
 host: web.simarro

La línia de petició i les capçaleres han d'acabar totes amb <CR><LF> (és a dir, Carriage Return (retorn de carro) seguit per un Line Feed). La línia en blanc només ha de ser <CR><LF>, sense cap espai. En el protocol HTTP/1.1 totes les capçaleres, excepte Host, són opcionals.

Una línia de petició que només contingui la ruta del fitxer és acceptada pels servidors per tal de mantenir la compatibilitat amb els clients HTTP anteriors a l'especificació HTTP/1.0 .

Missatge de resposta

El servidor retorna un missatge com aquest:

 HTTP/1.1 200 OK
 Date: Wed, 28 Feb 2018 08:58:01 GMT
 Server: Apache/2.4.18 (Ubuntu)
 Last-Modified: Fri, 04 Nov 2016 06:56:32 GMT
 ETag: "2c39-540742c975b1d"
 Accept-Ranges: bytes
 Content-Length: 11321
 Vary: Accept-Encoding
 Connection: close
 Content-Type: text/html
  
 
 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
 ...

La primera línia indica que tot ha anat bé. Si va mal, podem trobar missatges d'error com el 404, 403, 500... Podem saber què siginifquem mirant l'estandard RFC 2616 sec 6 https://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html

Mètodes de petició

Mètodes segons l'especificació RFC 2616 que correspon a HTTP/1.1 .

L'HTTP defineix vuit maneres (a vegades anomenats "verbs") d'indicar l'acció destijada que s'ha de dur a terme sobre el recurs. El que el recurs representa depèn de la implementació de cada servidor. Normalment però, aquest recurs és el contingut d'un fitxer, o la sortida d'un executable resident al servidor.

HEAD
Sol·licita una resposta, idèntica a la que es generaria amb una consulta GET, però sense el cos de la resposta. Aquesta comanda és útil per aconseguir les meta-dades incloses en la capçalera de la resposta, sense haver-se d'enviar tot el contingut.
GET
Sol·licita una representació del recurs especificat. Noti's que GET no s'ha d'usar per operacions que tinguin efectes col·laterals, com ara accions sobre aplicacions web. La raó és que el GET escriu les dades en la URI. Exemple: /index.php?page=main&lang=es
POST
Envia dades per a ser processades (p. ex, en un formulari HTML) a un recurs específic. Les dades s'inclouen en el cos de la petició. Això pot implicar la creació d'un nou recurs o l'actualització d'aquest si ja existeix (o ambdós).
PUT
Apuja una representació del recurs especificat. Els hostings compartits no solen tindre habilitat PUT. Però en teoría és millor que POST per a penjar alguna cosa, ja que es crea un socket en el servidor i la càrrega és més directa.
DELETE
Esborra el recurs especificat.
TRACE
Retorna la consulta rebuda, perquè el client pugui veure quines coses estan afegint o canviant els servidors intermitjos.
OPTIONS
Retorna els mètodes HTTP que el servidor suporta per a una URL determinada. Es pot fer servir per esbrinar la funcionalitat del servidor web enlloc d'un recurs específic.
CONNECT
Converteix la connexió de petició en un túnel TCP/IP transparent, normalment per facilitar comunicacions xifrades amb SSL (HTTPS) a través d'un proxy HTTP no xifrat.

Els servidors han d'implementar com a mínim els mètodes GET i HEAD HTTP 1.1 Section 5.1.1 i, quan sigui possible, també el mètode OPTIONS.

Apache

El servidor Apache és un dels més recomanats per a utilitzar en qualsevol projecte de web. És flexible, ràpid i eficient, amés:

  • Multiplataforma
  • Estàndard
  • Modular: Sols cal activar el mòduls necessaris i disposa d'una API per programar els mòduls que necessitem.
  • Obert i lliure.
  • Extensible

Configuració

Nosaltres anem a centrar-nos en la versió 2.4 de Apache i la documentació és aquesta: [1]

Apache ha anat desplaçant coses del seu fitxer principal de configuració apache2.conf a altres fitxes i directoris. Aquests són els que anem a estudiar:

  • apache2.conf : Fitxer principal, delega configuracions a altres fitxers.
  • ports.conf: Fitxer per indicar els ports per els que escolta el servidor.
  • magic: Contè la base de dades de tipus de fitxers que pot enviar.
  • conf-avaliable: Directori amb fitxers de configuració que estan disponibles.
  • conf-enabled: Directori amb enllaços a conf-available per activar configuracions.
  • mods-available, mods-enabled: Mòduls disponibles i activats.
  • sites-available, sites-enables: Llocs web disponibles i activats.

Apache pot ser configurat seguint estratègies diverses. Per tant, podem trobar solucions molt diferents a la mateixa necessitat. Per començar a entendre cóm funciona, anem a distingir entre varis tipus de configuracions:

Configuració Global

És la que afecta al servidor com a tal. Són moltes les opcions entre les que podem destacar:

  • ServerRoot: Lloc on estan els fitxers de configuració
  • TimeOut: Temps d’espera màxim en enviar o rebre informació del client.
  • KeepAlive: on/off (http 1.0/1.1)
  • Listen: Adreça i port on escoltar les peticions.
  • User ${APACHE_RUN_USER}
  • Group ${APACHE_RUN_GROUP}: Usuari i grup d’execució del servidor.

Configuració General

És la que afecta als llocs web que dona el servidor. Aquestes configuracions es poden aplicar en virtualhosts concrets o per a tots:

  • ServerAdmin: Correu de l’administrador
  • ServerName: Nom DNS i port del servidor http.
  • ServerAlias: Noms alternatius
  • DocumentRoot: Ruta dels arxius que publica el servidor.
  • DirectoryIndex: Document que actua cóm a pàgina per defecte del directori on estan els arxius.
  • Alias: Indica una ruta de la URL cap a un directori del servidor.
  • AccessFileName .htaccess: Indica el nom del fitxer que controla la seguretat d’un directori.
  • AllowOverride: Indica si un directori pot tindre opcions de seguretat que modifiquen les globals. Aquestes són les opcions:
    • 'All: Permet sobreescriure totes les directives.
    • None: No permet cap directiva
    • AuthConfig: Permet especificar directives d'autenticació dels usuaris.
    • FileInfo: Permet controlar els tipus de documents.
    • Indexes: Permet especificar l'indexat dels directoris.
    • Limit: Permet directives que controlen l'accés per la IP del client.
    • Options: Permet sobreescriure directives que controlens opcions dels directoris.

Control d'accés per directori

Documentació oficial

Per a controlar l'accés a un directori, es pot utilitzar els fitxers .htaccess amb una sintaxi similar a:

AuthType Basic
AuthName "Acces Restringit"
AuthUserFile /var/www/users
AuthGroupFile /var/www/groups
Require group grup1 grup2

Per suposat, els fitxers anteriors han d'existir. Per donar contrasenya a un usuari podem utilitzar el comandament:

htpasswd -c /var/www/users pepe

Un altre exemple amb usuaris:

AuthType Basic
AuthName "Acces Restringit"
AuthUserFile /var/www/html/solar/secret/users/users
Require user pepe 


Per a que funcione, cal declarar que es pot sobreescriure els permisos per .htaccess:

<Directory /privat/>
       Options Indexes FollowSymLinks
       AllowOverride AuthConfig
       Require all granted
</Directory>

.htaccess és el nom que tenen per defecte els fitxers de configuració per directori. Si volem utilitzar un altre nom, hem de modificar la directiva AccessFileName

.htaccess sols s'ha d'utilitzar quan no podem accedir a la configuració general del servidor. En qualsevol altre cas, és preferible controlar la seguretat des del fitxer de configuració del virtualhost o del servidor. Aquest sistema és ineficient i potencialment insegur. Per tant, tot el que pots posar en .htaccess pot ser que estiga millor dins d'un <directory>.

Servidors Virtuals

Apache permet oferir diferents webs en funció de cóm es demanen. Cada web diferent es diu un VirtualHost. Inclús el host real s’ha de fer com un host virtual. Si no hi ha coincidència va al lloc per defecte.

Es configuren bàsicament en 3 directives que detallarem més endavant:

  • <VirtualHost>: Etiqueta per clavar dins totes les opcions pròpies del servidor virtual.
  • ServerName: El nom del servidor per el que donarà resposta.
  • ServerAlias: Cadascun dels noms DNS alternatius que dona el mateix servidor virtual.

De vegades és complicat saber quants servidors virtuals tenim i cóm se comporten sense llegir tots els fitxers de configuració. Però hi ha un comandament que ens mostra cóm es comportarà el nostre servidor:

apachectl -S

Servidors virtuals basats en la IP

Si volem que la mateixa màquina en el mateix Apache done pàgines web distintes, una de les opcions és donar més direccions IP a l'ordinador i configurar servidors virtuals en funció de la IP.

Això es pot fer augmentant les NIC, amb adreces virtuals o les NIC virtuals si estem dins d'una màquina virtual o contenidor. Després fem que el DNS apunte cada URL a una IP distinta i ja està.

Com que no sobren les adreces IP, aquesta solució sols sembla interessant en xarxes privades o per a necessitats grans de rendiment.

Ací tenim un exemple d'un sol servidor Apache amb 2 IPs:

<VirtualHost 172.20.30.40:80>
   ServerAdmin webmaster@www1.example.com
   DocumentRoot "/www/vhosts/www1"
   ServerName www1.example.com
   ErrorLog "/www/logs/www1/error_log"
   CustomLog "/www/logs/www1/access_log" combined
</VirtualHost>

<VirtualHost 172.20.30.50:80>
   ServerAdmin webmaster@www2.example.org
   DocumentRoot "/www/vhosts/www2"
   ServerName www2.example.org
   ErrorLog "/www/logs/www2/error_log"
   CustomLog "/www/logs/www2/access_log" combined
</VirtualHost>

Servidors virtuals basats en el nom

Si sols tenim una IP i volem donar diferents web, podem basar els servidors virtuals en els noms DNS.

<VirtualHost *:80>
   # El primer virtualhost és també el per defecte quan entren per *:80
   ServerName www.example.com
   ServerAlias example.com *.example.com
   DocumentRoot "/www/domain"
</VirtualHost>

<VirtualHost *:80>
   ServerName other.example.com
   DocumentRoot "/www/otherdomain"
</VirtualHost>

Amb açò es poden fer moltes combinacions, recomane llegir en deteniment els exemples oficials


<Directory>

  • Permet configurar valors de seguretat i altres per a directoris en concret.
  • Es necessita un per a cada directori diferent que publique el servidor. No és precís per als subdirectoris.
<Directory /usr/local/httpd/htdocs>
  Options Indexes FollowSymLinks
  AllowOverride None
  Require all granted
</Directory> 

En aquest cas, permet mostrar els fitxers del directori i utilitzar enllaços simbòlics del sistema d'arxius. No permet sobreescriure res en .htaccess i amb Require deixa entrar a tots.

Require té moltes possibilitat per controlar l'accés. Recomanem llegir el manual oficial per torbar la més adequada.

<Files>

De forma pareguda als directoris, es poden fer limitacions en els fitxers. Per exemple:


<Files admin.php>
  deny from all
</Files>

<Files ~ "\.(gif|jpe?g|png)$">

HTTPS en Apache

HTTPS no sols implica qüestions tècniques, sinó també administratives, ja que per a fer-ho ben fet, necessitem una entitat certificadora per a signar les nostres claus.

Per a fer-ho bé, necessitem:

  • Contractar un certificat SSL
  • Instal·lar el certificat en el servidor.
  • Configurar el mòdul SSL d’Apache i activar-lo.
  • Configurar el lloc que s’accedirà per SSL i activar-lo.

Com que el SSL no sempre està al nostre abast, Apache pot aprofitar un certificat auto-signat que fa durant la seua instal·lació. Per tant, si volem que funcione sense signar el certificat sols tenim que:

  • Activar el mòdul: a2enmod ssl
  • Activar el lloc ssl per defecte: a2ensite default-ssl

Una vegada fer això, editem el fitxer default-ssl.conf per a que funcione en els nostres noms, directoris o controls d'accessos i ja està.

Si volem que quan entren per http (al port 80) els redireccione al https, posem al virtualhost:

Redirect / https://www.client2.com

Directoris personals

Si volem que els usuaris del sistema puguen tindre una web personal, podem activar els userdir:

 a2enmod userdir

Després, modificar el fitxer mods-enabled/userdir.conf per modificar la ruta del directori personal. [2]

Proves en curl

Per provar, de vegades és interessant i més ràpid utilitzar curl més que un navegador web. Així podem controlar tota la petició:

Curl sense passar per el DNS:

curl -H 'host:www.terra.solar.com' 10.1.3.200
curl -H 'host:<url>' <ip>

Curl per https ignorant el problema del certificat:

Per a https: curl -k https://<ip>

Per a permitir redireccions:

curl -L …

Per a indicar un usuari i contrasenya:

curl -u <usuari> <url>

Enllaços

Utilitats

curl sense hosts