Salta el contingut

UD5. El servei HTTP

Introducció

Amb l'evolució i l'accés lliure a Internet, un dels principals al·licients que han sorgit és la publicació de pàgines web on es poden emmagatzemar uns continguts molt atractius per a nosaltres i que, alhora, poden ser consultats des d'arreu del món per tothom.

Val a dir que, amb la popularització d'Internet, tant empreses com usuaris han vist la necessitat d'establir un punt des d'on anunciar els seus productes, o bé, a títol particular, donar publicitat a les aficions o capacitats personals mitjançant la publicació de pàgines web.

Les pàgines web, en la seva majoria en format HTML, requereixen ser allotjades en màquines que disposen d’espai en disc per emmagatzemar arxius HTML, imatges, blocs de codi o arxius de vídeo en directoris específics i, alhora, han de ser capaces d'entendre tot tipus d'extensió dels arxius que són enviats en tots dos sentits de la comunicació.

Paral·lelament, no podem deixar de banda la importància de les mesures de seguretat davant dels perills existents a Internet. Per aconseguir-ho, les pàgines hauran d'estar dissenyades considerant la incorporació de protocols de comunicació segurs com, per exemple, els desenvolupats amb el protocol segur de transferència d'hipertext (HTTPS, hypertext transfer protocol secure) que utilitzen claus i estratègies de xifrat pròpies de les eines del protocol de capa de connexió segura (SSL, secure sockets layer).

Les màquines que allotgen les pàgines web reben la categoria de servidors web. Des del punt de vista dels servidors, els requeriments més rellevants són l'espai de disc necessari per poder emmagatzemar l'estructura de la pàgina web i una bona connexió de xarxa perquè el consum de la unitat de processament central (CPU, central processing unit) siga prou baix.

El funcionament dels servidors web és especial ja que, com si es tractés d'una dent de serra, tenen consums de recursos puntuals perquè podem estar un temps sense peticions i, de cop i volta, tenir una allau de peticions. Això fa que els servidors web acostumen a tindre un nombre baix de processos en espera. A mesura que esdevenen necessaris, se'n van arrencant de nous.

Val a dir que no totes les peticions consumeixen el mateix, i, per exemple, aquelles pàgines web que executen programes d’interacció amb l’usuari o requereixen xifrat (HTTPS) consumeixen més recursos que altres pàgines web amb menys interacció.

Finalment, pel que fa al software, segons estadístiques de W3Techs actualitzades al novembre de 2024, Nginx és utilitzat pel 33,8% de tots els llocs web, mentre que Apache és emprat pel 28,5%:

Percentatge d'ús de servidors web

Exercici 1. Com està el mercat?

Busca informació sobre el software servidor web i els seus usos vistos al gràfic anterior.

El protocol HTTP

Un poc d'història

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

Des d’un punt de vista històric, la web fou creada l'any 1989 al Consell Europeu per la Recerca Nuclear (CERN, Centre Europeene pour la Recherche Nucleaire), amb seu a Ginebra, just a la frontera entre Suïssa i França. Aquest organisme disposava (i disposa) d’una àmplia plantilla de científics de diferents països d’Europa que treballen en els seus acceleradors de partícules. En conseqüència, molts equips de treballadors estan integrats per membres de nacionalitats diferents. A més, molts dels experiments que s’hi fan destaquen per la seva complexitat i requereixen anys i anys de planificació i de construcció d’equipaments.

Fou arran de la necessitat de disposar de múltiples grups de científics repartits pel món i col·laborant entre ells (enviant-se informes, dibuixos, esquemes, fotos i tot tipus de documents) que va néixer la 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, HyperText 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.

Carcaterístiques d'HTTP

El protocol de transferència d’hipertext (HTTP) és un protocol client-servidor molt 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 especificava la versió 1.1

RFC

Els Request for Comments, més coneguts per les seves sigles RFC, són una sèrie de publicacions del grup de treball d'enginyeria d'internet que descriuen diversos aspectes del funcionament d'Internet i altres xarxes de computadores, com protocols, procediments, etc. i comentaris i idees sobre estos.

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 servidor 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 aplicació 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üentment 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 “sessió”, i, alhora, permet rastrejar usuaris, ja que les galetes es poden emmagatzemar en el client durant un temps indeterminat.

Localitzador uniforme de recursos (URL)

Generalment, la via de què disposa un usuari per accedir a una pàgina web o un objecte (arxiu) és mitjançant el seu localitzador uniforme de recursos (URL), que és una mena d’adreça que indica la localització exacta d’un document a Internet.

L’adreça que indica la localització exacta del document es compon del nom o l’adreça d’Internet (IP, Internet protocol) del servidor i el camí relatiu del document dins del servidor. També pot incloure altres aspectes com el port pel qual se sol·licita el servei (per defecte, s’assumeix que el 80 és per al protocol HTTP, el 21 per al protocol FTP, etc.) i un nom d’usuari i una contrasenya per a aquells documents que requereixin autenticació per accedir-hi.

Etapes d'una transacció HTTP

Amb la intenció de conèixer amb més profunditat el protocol HTTP podem avaluar en què consisteix una transacció HTTP.

Cada vegada que un client fa una petició a un servidor, s’executen un seguit d'accions:

  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. 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, el node expressat amb el nom de domini o la seua adreça IP, el possible port opcional (el valor per defecte és el 80) i l'objecte del servidor requerit.
  2. 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.
  3. El servidor localitza el recurs sol·licitat i torna la resposta al client.
  4. 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. El client formata i mostra el recurs rebut.
  6. Es tanca la connexió TCP.

Aquest procés es repeteix en cada accés que es faça 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.

sequenceDiagram
    autonumber
    participant Usuari
    participant Client
    participant Servidor

    Usuari->>Client: Introducció de l'URL
    Client->>Servidor: Connexió TCP i petició HTTP
    Servidor->>Servidor: Localització del recurs
    Servidor-->>Client: Resposta amb codi d'estat i contingut
    Client->>Usuari: Mostra el recurs
    Client->>Servidor: Tanca la connexió TCP

Extensió MIME

El protocol HTML fou dissenyat per transportar per la xarxa arxius en format ASCII. Amb el progrés de les tecnologies i la inclusió de diferents tipus d’arxius en un format diferent a l’ASCII (imatges, vídeos, sons, etc.) en les aplicacions per Internet, va sorgir la necessitat de transformar aquests format a ASCII per la seva correcta recepció en el navegador web.

El 1992, es van crear els tipus MIME, que eren especificacions per donar format a missatges en un format diferent a l’ASCII perquè poguessin ser enviats i interpretats per Internet. Més endavant es van aplicar també als documents web.

Nomenclatura de tipus

MIME assigna un nom a cada tipus de dades. Els noms segueixen el següent format:

tipus / subtipus (tipus com a subtipus són cadenes de caràcters)

El tipus defineix la categoria general de les dades i el subtipus defineix un tipus més específic d'aquestes dades. El tipus ha de tenir els següents valors:

  • text: Indica que el contingut és text pla. Exemples de subtipus: html, xml
  • multipart: Indica que té múltiples parts de dades independents. Exemples de subtipus: form-data, enviat a diari
  • message: Per encapsular un missatge existent. Per exemple quan volem respondre a un missatge de correu incorporant el missatge origen. Exemples de subtipus: partial, RFC822
  • image: Indica que és una imatge. Ex de subtipus: png, gif
  • audio: Indica que és un àudio. Exemples de subtipus: mpeg, avi
  • video: Indica que és un vídeo. Exemples de subtipus: mp4, 32kadpcm
  • application: Indica que es tracta de dades d'aplicació dels quals poden ser binaris. Exemples de subtipus: json, pdf

L'estandard HTTP/1.0

L’estàndard HTTP/1.0 recull, únicament, tres ordres que representen les operacions de recepció, enviament de la informació i revisió de l’estat.

  • Mètode de petició GET. S’utilitza per sol·licitar un recurs del servidor. Sempre que premem sobre un enllaç o escrivim una adreça d’Internet a la barra de navegació d’un navegador web, estem utilitzant aquest mètode de petició. Com a resultat, el servidor HTTP envia el document corresponent a l’adreça d’Internet seleccionada.
  • Mètode de petició HEAD. Sol·licita informació sobre un recurs com, per exemple, la seva grandària, el tipus, la data de modificació, etc. Acostuma a ser utilitzat pels gestors de memòries cau de pàgines o pels servidors intermediaris (proxy server) per conèixer quan cal actualitzar la còpia que es manté d’un arxiu determinat.
  • Mètode de petició POST. S’utilitza per enviar informació al servidor, com per exemple, les dades contingudes en un formulari. El servidor passarà aquesta informació a un procés encarregat del seu tractament (acostuma a ser una aplicació del servidor). L’operació que es durà a terme amb la informació proporcionada dependrà de l’adreça d’Internet (URL) utilitzada, principalment, en els formularis.

Val a dir que un client web selecciona automàticament les ordres HTTP necessàries per recollir la informació per a l’usuari. Per tant, davant l’activació d’un enllaç, sempre s’executa una operació GET amb la finalitat de recollir el document corresponent.

Tal com mostra la imatge següent, la comunicació entre el navegador i el servidor es duu a terme en dues etapes. D’una banda, el navegador fa una sol·licitud HTTP que, posteriorment, és processada pel servidor que, en conseqüència, envia una resposta HTTP.

Comunicació navegador - servidor
IOC. Comunicació navegador - servidor (CC BY-SA)

Si avaluarem amb deteniment la sol·licitud HTTP ens trobaríem amb un conjunt de línies de text que el navegador envia al servidor. D’una banda, trobaríem una línia de sol·licitud, és a dir, una línia que especifica el tipus de document sol·licitat, el mètode que s’aplicarà i la versió del protocol utilitzat. Aquesta línia estarà integrada per tres elements separats per un espai, és a dir, el mètode, l’adreça web i el protocol HTTP utilitzat pel client.

A continuació, trobaríem els camps de l’encapçalament de sol·licitud, és a dir, un conjunt de línies opcionals que permeten aportar informació addicional sobre la sol·licitud i/o el client (navegador, sistema operatiu, etc.). Cadascuna d’aquestes línies estarà formada per un nom que descriu el tipus d’encapçalament, seguit per dos punts (:) i pel valor de l’encapçalament.

Finalment, el cos de la sol·licitud és un conjunt de línies opcionals separades de les línies anteriors amb una línia en blanc. La seva finalitat és permetre que s’enviïn dades al servidor utilitzant un formulari durant la transmissió.

En conseqüència, la sol·licitud HTTP rebria una resposta HTTP, és a dir, un conjunt de línies que el servidor enviarà al navegador web. Com en el cas de la sol·licitud, la resposta HTTP conté alguns elements definitoris com, per exemple, una línia d’estat. Aquesta línia especifica la versió del protocol utilitzada i l’estat de la sol·licitud en procés mitjançant un text explicatiu i un codi.

En el cas dels camps de l'encapçalament de resposta, aquest és un conjunt de línies opcionals que permeten aportar informació addicional sobre la resposta i/o el servidor. Cadascuna d'aquestes línies es compon d'un nom que defineix el tipus d'encapçalament, seguit per dos punts (:) i pel valor de l'encapçalament.

Pel que fa als codis de resposta, aquests són els codis que es veuen quan el navegador no pot mostrar la pàgina web sol·licitada. La sintaxi d'una resposta HTTP és una línia d'estat i té una estructura fixa on s'indica la versió, el codi de l'error i un text explicatiu.

Els possibles codis d'estat s'identifiquen amb números de tres xifres i es classifiquen en cinc grups segons si són informatius (1xx), d'èxit en la sol·licitud (2xx), per tornar a adreçar la sol·licitud (3xx), per un error generat en el client (4xx) o bé per errors generats en el servidor (5xx).

Les respostes més típiques són els codis 200 per indicar la confirmació de la petició i el 404 per indicar que l'objecte sol·licitat no es troba disponible.

Codis d'estat més habituals

Codi Categoria Descripció
200 OK Successful (2xx) La petició s'ha completat amb èxit. Depenent del mètode: GET (recurs enviat), HEAD (només capçalera), POST (resultat de l'acció).
301 Moved Permanently Redirection (3xx) El recurs sol·licitat ha estat mogut permanentment a una altra URL.
302 Moved Temporarily Redirection (3xx) El recurs s'ha mogut temporalment. El client ha d'utilitzar l'URL proporcionada de forma temporal.
304 Not Modified Redirection (3xx) El recurs no ha canviat des de la darrera petició i es pot utilitzar la memòria cau.
400 Bad Request Client Error (4xx) La petició és invàlida (p. ex., error de sintaxi).
401 Unauthorized Client Error (4xx) La petició requereix autenticació. L'usuari no està autoritzat.
403 Forbidden Client Error (4xx) El servidor entén la petició però es nega a complir-la (manca de permisos).
404 Not Found Client Error (4xx) El recurs sol·licitat no existeix.
500 Internal Server Error Server Error (5xx) Error genèric del servidor. Es va produir una condició inesperada.
502 Bad Gateway Server Error (5xx) El servidor actua com a passarel·la o proxy i ha rebut una resposta no vàlida d'un altre servidor.
503 Service Unavailable Server Error (5xx) El servidor no pot processar la petició temporalment (manteniment o saturació).

Instal·lació i configuració bàsica d'Apache2

Informació oficial Ubuntu Informació oficial Apache

Pràctica 1A. Instal·lació d'Apache2
  1. Instal·la el servidor web Apache2 amb la informació proporcionada pel professorat.
  2. Comprova que pots accedir des de la xarxa interna com exetrna.
  3. On està guardada la configuració del servidor virtual per defecte? I la configuració general d'Apache?
  4. On es troba el fitxer httpd.conf?
  5. Quina diferència hi ha entre el directori conf-available i conf-enabled?
  6. Puja una web al servidor (senzilla) i comprova que és accessible.

Directives importants

Directiva <Directory>

La directiva Directory permet configurar permisos en els diferents directoris del nostre espai web. Es tracta d'una directriu que es fa servir per definir característiques que només s'aplicaran al directori especificat i no a tot el servidor (per això s'ha de tancar).

Aquests permisos serien els següents:

  • Options
    • Indexes. Si dins de la carpeta no hi ha cap arxiu igual que el que hem definit al paràmetre DirectoryIndex al navegador es mostrarà un índex amb tots els arxius de la carpeta actual.
    • FollowSymLinks. El servidor seguirà els enllaços simbòlics (lògics), és a dir, els àlies.
  • Require all denied, Require not ip 192.168.1.50. Denega la petició a una carpeta, un arxiu o una adreça d’Internet.
  • Require all granted, Require ip 192.168.1.50. Permet la petició a una carpeta, un arxiu o una adreça d’Internet.

Directiva <Files>

La directiva Files permet configurar permisos en els diferents arxius del nostre espai web. Val a dir que el paràmetre Files ha d'estar inclòs dintre del paràmetre Directory.

Aquests permisos serien els següents:

  • require all denied, require not ip 192.168.1.50. Denega la petició a un arxiu o una adreça d’Internet.
  • require all granted, require ip 192.168.1.50. Permet la petició a un arxiu o una adreça de Internet.
  • A tall d'exemple, podríem trobar el següent:
    • Volem prohibir l'accés a arxius amb format JPG dintre de la carpeta /var/www/serveisenxarxa/public_html
ApacheConf
1
2
3
4
5
6
<directory "/var/www/serveisenxarxa/public_html">
  <files *.jpg>
     require all denied
  </files>
  require all granted
</directory>

Directiva <VirtualHost>

La directiva virtualhost permet configurar més d’un lloc web en un mateix servidor, és a dir, una mateixa adreça d’Internet per a diferents noms de domini. Val a dir que, si volem utilitzar aquest paràmetre, cal haver configurat el servidor de noms de domini (DNS) perquè adreci els noms de domini cap al nostre servidor web Apache.

Quan parlem de la creació de llocs virtuals ens estem referint a l’acció de fer treballar més d’un lloc web, per exemple, les pàgines web www.web1.es i www.web2.es en un únic ordinador.

Tal com mostra la figura següent tot i que tots dos dominis estiguen treballant en la mateixa màquina física, mai no ens n’adonarem quan visitem aquests llocs web.

Servidors Virtuals

Els llocs web virtuals es poden basar tant en adreces d'Internet (IP), on cada lloc web té una adreça d'Internet (IP) diferent, com en noms diferents, és a dir, diversos llocs web amb diferents noms de domini estaran treballant amb una única adreça d'Internet (IP). Val a dir que, tot i que estiguem treballant en la mateixa màquina física, com a usuaris observarem que l'usuari, quan visita aquests llocs web, no se n'adona.

Per explicar la tècnica de la creació de llocs web virtuals, treballarem amb dos exemples: www.aplicacionsweb.org i www.serveisenxarxa.org.

Els dos llocs webs virtuals seran servits pel mateix servidor web. El directori per defecte on es troben les pàgines web és /var/www, on crearem les diferents estructures de directori. Per tant, dins dels directoris /var/www/aplicacionsweb i /var/www/seveisenxarxa trobarem els arxius dels llocs web corresponents a les pàgines web anteriors.

Per a la configuració i posada en marxa dels llocs web virtuals hem de construir, en primer lloc, l'estructura de directoris on desarem els llocs. Utilitzarem dintre del directori reservat a cada lloc web la carpeta de public_html per allotjar els arxius del lloc web.

Un cop definits els directoris on desarem els llocs web virtuals, haurem d’adreçar-nos al directori /etc/apache2, on trobarem els arxius de configuració d’Apache. En aquest cas, l'arxiu principal de configuració és apache2.conf.

Considerant que per treballar amb els llocs virtuals haurem de fer alguns canvis en el contingut de l’arxiu, haurem de considerar, abans d'establir cap canvi, quina configuració de llocs web virtuals volem crear, és a dir, llocs virtuals basats en adreces d’Internet (IP) o bé basats en noms.

Servidors virtuals en Apache

Apache2 es lliura amb una configuració predeterminada virtual-host-friendly. És a dir, està configurat amb un únic host virtual predeterminat (utilitzant la directiva VirtualHost) que es pot modificar o utilitzar com si tingués un sol lloc o que s'utilitzés com a plantilla per a servidors virtuals addicionals si teniu diversos llocs. Si es deixa sol, l'amfitrió virtual predeterminat servirà com a lloc predeterminat o els usuaris del lloc veuran si l'URL que introduïu no coincideix amb la directiva ServerName de cap dels vostres llocs personalitzats. Per modificar el servidor virtual predeterminat, editeu el fitxer /etc/apache2/sites-available/000-default.conf.

Si voleu configurar un nou host virtual o lloc, copieu aquests fitxers en el mateix directori amb el nom que seleccioneu. Per exemple:

Bash
sudo cp /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-available/elmeullocweb.conf

La configuració bàsica és la següent:

ApacheConf
<VirtualHost *:80>
    # The ServerName directive sets the request scheme, hostname and port that
    # the server uses to identify itself. This is used when creating
    # redirection URLs. In the context of virtual hosts, the ServerName
    # specifies what hostname must appear in the request's Host: header to
    # match this virtual host. For the default virtual host (this file) this
    # value is not decisive as it is used as a last resort host regardless.
    # However, you must set it for any further virtual host explicitly.
    #ServerName www.example.com

    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html

    # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
    # error, crit, alert, emerg.
    # It is also possible to configure the loglevel for particular
    # modules, e.g.
    #LogLevel info ssl:warn

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    # For most configuration files from conf-available/, which are
    # enabled or disabled at a global level, it is possible to
    # include a line for only one particular virtual host. For example the
    # following line enables the CGI configuration for this host only
    # after it has been globally disabled with "a2disconf".
    #Include conf-available/serve-cgi-bin.conf
</VirtualHost>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

Una vegada realitzats els canvis activarem en lloc web amb el comandament a2ensite:

Bash
a2ensite elmeullocweb

Després carregarem de nou la configuració d'Apache2 amb el comandament:

Bash
service apache2 reload

Per a la depuració d'error en els arxius de configuració de llocs virtuals cal utilitzar:

Bash
apache2ctl -t
LLocs virtuals basats en l'adreça d'internet (IP)

En aquest cas, podrem allotjar múltiples dominis en una única màquina que disposarà de diferents adreces d’Internet (IP) i, en cadascuna d’elles, s’hi executarà un lloc virtual.

Haurem de canviar la directiva <VirtualHost *:80> de forma que s'especifique a quina adreça IP ha de respondre. Per exemple <VirtualHost 192.168.2.112:80> si ha de respondre a l'adreça IP 192.168.2.112.

ApacheConf
1
2
3
<VirtualHost 192.168.2.112:80>
    DocumentRoot "/var/www/serveisenxarxa/public_html"
</VirtualHost>
LLocs virtuals basats en el nom de domini

El problema dels llocs web virtuals basats en adreces d’Internet (IP) és que, considerant que s'allotgen molts dominis, necessitarem una adreça d’Internet (IP) per a cadascun dels dominis. Per tant, pot ser preferible treballar amb llocs virtuals basats en noms. En aquest cas, després de copiar l'arxiu de configuració per defecte, haurem d'afegir la directriu ServerName donat que, si bé els llocs virtuals es troben en la mateixa IP, s'ha de canviar el nom per a cadascun dels llocs. En el cas de treballar amb servidor DNS, aquest haurà d'estar configurat per resoldre aquests llocs en les zones corresponents. I la directiva DocumentRoot per a indicar des de quin directori es serviran les pàgines. Aquesta seria la configuració per a lloc www.serveisenxarxa.org:

ApacheConf
1
2
3
4
<VirtualHost *:80>
    ServerName www.serveisenxarxa.org
    DocumentRoot "/var/www/serveisenxarxa/public_html"
</VirtualHost>

Finalment, per verificar que tots els canvis aplicats han tingut èxit, tornarem a arrencar el servidor web.

Instal·lació i configuració bàsica d'nginx

Informació oficial Ubuntu Informació oficial nginx

Pràctica 1B (continuació). Instal·lació d'nginx
  1. Instal·la el servidor web nginx amb la informació proporcionada pel professorat.
  2. Comprova que pots accedir des de la xarxa interna com exetrna.
  3. On està guardada la configuració del servidor virtual per defecte? I la configuració general d'nginx?
  4. Puja una web al servidor (senzilla) i comprova que és accessible.
Pràctica 1C (continuació). Llocs virtuals en Apache
  1. Quins fitxers estan implicats en la gestió de Hosts Virtuals en Apache?
  2. Configura Apache perquè serveixca dues pàgines distintes en ports distints (8081 i 8082).
  3. Puja dues pàgines senzilles, i diferents, i comprova que son accessibles en els seu port corresponent.
  4. Ara, canvia la configuració perquè Apache servixca cadascuna de les pàgines sense necessitat d'indicar el port, sols per el nom (Recorda que hauràs de modificar el fitxer hosts del client).
Pràctica 1D (continuació). Llocs virtuals en nginx
  1. Quins fitxers estan implicats en la gestió de Hosts Virtuals en nginx?
  2. Configura nginx perquè serveixca dues pàgines distintes en ports distints (8081 i 8082).
  3. Puja dues pàgines senzilles, i diferents, i comprova que son accessibles en els seu port corresponent.
  4. Ara, canvia la configuració perquè nginx servixca cadascuna de les pàgines sense necessitat d'indicar el port, sols per el nom (Recorda que hauràs de modificar el fitxer hosts del client).
Pràctica 1E (continuació). Autenticació en Apache
  1. Documenta el procés de configuració per poder dur a terme les tasques següents:
    • Protegeix un lloc web per a 3 usuaris de l'aula assignant-los una contrassenya.
    • Realitza la protecció per a un grup d'usuaris.
    • Accedeix a la web protegida d'un company de classe. Pregunta-li per les credencials d'accés.

Presentació

Presentació