Este blog está dedicado a la recolección de información relacionada con las nuevas tecnologías ( tecnoloxía xa), especialmente, con las vinculadas a la informática. La idea es centralizar y compartir la información y cada manual o tutorial que voy recolectando para las clases tanto de administración de sistemas como de explotación de sistemas informáticos de modo que estén disponibles para alumnos y resto de interesados. (IES A Carballeira, Ourense)
sábado, 22 de mayo de 2010
VirtualBox 3.2.0 disponible
viernes, 21 de mayo de 2010
Servidor LDAP en Ubuntu
Instalación y Configuración de OpenLDAP
El servido OpenLDAP nos provee de un modo sencillo de centralizar la autenticación de usuarios y servicios en una única base de datos de rápida lectura, de modo que podamos hacer que cualquier servicio ( ftp, web, correo,...) autoricen o no el acceso dependiendo de los datos, por ejemplo, de usuario y contraseña que hayamos configurado en el mismo.
1.- Instalación de OpenLDAP
En primer lugar instalamos el demonio servidor slapd, ldap-utils -paquete que contiene utilidades para el manejo de LDAP y db4.2-util – que proporciona herramientas para realizar algunas operaciones con bases de datos como pueden ser cargas, modificaciones o actualizaciones del formato de las mismas-:
sudo apt-get install slapd ldap-utils db4.2-util
Durante la instalación nos pedirá que introduzcamos una contraseña para identificar al administrador de ldap.
Por defecto, además, el sufijo del directorio coincidirá con el nombre de dominio del servidor. Por ejemplo si el FQDN (Fully Qualified Domain) es ldap.ejemplo.com, el sufijo por defecto será dc=example,dc=com. Si queremos cambiarlo lo podremos hacer usando dpkg-reconfigure dónde podremos configurar varias opciones de slapd (en nuestro caso no sería necesario ya que el dominio de nuestro equipo ya era el deseado: mczones.es).
sudo dpkg-reconfigure slapd
Nos aparecerá un asistente que nos pedirá los siguientes datos:
-
Si deseamos omitir la configuración del servidor LDAP. Obviamente responderemos que no, ya que precisamente lo que queremos es configurar el servidor LDAP.
-
Nuestro directorio LDAP base , habitualmente se utiliza el nombre del dominio. Ejemplo, si nuestro dominio es mczones.es, lo normal es que la base para nuestrodirectorio LDAP sea: dc=mczones,dc=es.
-
Nombre de nuestro dominio. Éste nombre lo utilizará para crear el nombre distinguido (DN) o dicho más claramente, nombre identificativo de la base de nuestrodirectorio LDAP: mczones.es.
-
Posteriormente nos preguntará por el nombre de nuestra organización: mczones.
-
Contraseña que deseamos poner al usuario admin (administrador) del servidor LDAP. La solicitará dos veces para evitar errores de tecleo. Podemos poner cualquier contraseña, por ejemplo 'root'.
-
Acto seguido nos informará sobre los posibles gestores de datos para almacenar el directorio y nos preguntará qué sistema utilizar. Lo recomendable es utilizar el sistema HDB.
-
Si queremos que se elimine la base de datos cuando quitemos slapd. Por si acaso, lo mejor es responder que no.
-
En el caso de que exista una base de datos LDAP previa, nos preguntará si deseamos moverla. Lo mejor es responder Sí, para evitar que interfiera en la nueva base de datos:
-
Luego nos preguntará si deseamos utilizar LDAP versión 2, respondemos que no ya que apenas se utiliza.
-
Finalmente nos da la oportunidad de omitir la configuración. Si respondemos que sí, será como que no hemos ejecutado el asistente, por lo tanto si nuestra intención es configurar el servidor LDAP responderemos no.
2.- Configuración del servidor OpenLDAP
En versiones anteriores openldap se configuraba el comportamiento del servidor empleando únicamente el fichero slapd.conf, actualmente podemos hacer modificaciones dinámicamente -con lo que no es necesario parar y reiniciar el demonio slapd para realizar cada cambio- desde la base cn=config; se puede acceder a ella desde phpldapadmin con el usuario cn=admin,cn=config y la contraseña del admin, para luego buscar como está configurado, también podremos emplear las herramientas de línea de comandos que hemos instalado. Por ejemplo para comprobar el árbol de directorio creado durante la instalación o tras la reconfiguración (nos pedirá la contraseña de administrador del sistema LDAP):
ldapsearch -xLLL -b cn=config -D cn=admin,cn=config -W olcDatabase={1}hdb
2.1 Instalación y configuración de phpLDAPadmin
PhpLDAPadmin es una aplicación web que nos permitirá acceder al directorio LDAP para poder crear y modificar elementos. Otros posibles exploradores LDAP libres podrían ser gq y Jxexplorer.
Para instalar phpldap admin:
sudo apt-get install phpldapadmin
Esto nos instalará también apache -el servidor web-. Si estamos en el servidor, simplemente teclearemos en la barra de direcciones de nuestro explorador web: http://localhost/phpldapadmin/. Si se produce el error : “Memory Limit Low. Your php memory limit is low -currently 16 M” deberemos aumentar la memoria, por ejemplo a 64M, en el fichero /etc/php5/apache2/php.ini
(editamos el fichero /etc/php5/apache2/php.ini y ponemos: memory_limit = 64M ; ) y reiniciamos el servidor apache: /etc/init.d/apache2 restart.
En la versión de phpLDAPadmin que he instalado (1.1.05-6) cuando entramos por primera vez, en el panel izquierdo nos aparece el dominio de ejemplo (example.com) en lugar del que hemos configurado; para solucionarlo editamos el fichero /etc/phpldapadmin/config.php y cambiamos las líneas:
$ldapservers->SetValue($i,'server','base',array('dc=example,dc=com')); por
$ldapservers->SetValue($i,'server','base',array('dc=mczones,dc=es'));
si además queremos que cuando nos solicite el login, también aparezca el dominio correcto en el campo nombre de usuario, deberemos sustituir también:
$ldapservers->SetValue($i,'login','dn','cn=admin,dc=example,dc=com'); por
$ldapservers->SetValue($i,'login','dn','cn=admin,dc=example,dc=com');
Tras realizar estos dos cambios deberemos reiniciar el servidor apache: /etc/init.d/apache2 restart.
En la versión de phpLDAPadmin que he instalado (1.1.05-6) cuando entramos por primera vez, en el panel izquierdo nos aparece el dominio de ejemplo (example.com) en lugar del que hemos configurado; para solucionarlo editamos el fichero /etc/phpldapadmin/config.php y cambiamos las líneas:
$ldapservers->SetValue($i,'server','base',array('dc=example,dc=com')); por
$ldapservers->SetValue($i,'server','base',array('dc=mczones,dc=es'));
si además queremos que cuando nos solicite el login, también aparezca el dominio correcto en el campo nombre de usuario, deberemos sustituir también:
$ldapservers->SetValue($i,'login','dn','cn=admin,dc=example,dc=com'); por
$ldapservers->SetValue($i,'login','dn','cn=admin,dc=example,dc=com');
Tras realizar estos dos cambios deberemos reiniciar el servidor apache: /etc/init.d/apache2 restart.
2.2 Creación de Unidades organizativas, grupos y usuarios con phpLDAPadmin
Una vez hemos entrado en el sistema como cn=admin,dc=mczones,dc=es y password -en mi caso- ldapadmin, podemos crear la estructura del dominio. Para ello pulsamos en crear nuevo objeto y seleccionamos “Organisational Unit” para crear las unidades organizativas, en mi caso:
- Grupos: Dentro de ella crearé los “Posix Groups” “contabilidad” , “desarrollo” y “otros” a los que pertenecerán todos los usuarios.
-
-
Usuarios: en ella crearé directamente los usuarios que pertenezcan al grupo “otros”. Igualmente para mantener el orden crearé dos unidades organizativas:
-
Contabilidad: En ella iré añadiendo los User Account de este departamento: c1 y c2 pertenecientes al posix group “contabilidad” con contraseña “1234”.
-
Desarrollo: en ella he añadido los “User Account” d1 y d2 pertenecientes al Posix Group Desarrollo con contraseña “1234”.
-
En la unidad organizativa Usuarios he creado el usuario juan.
-
3.- Configuración de los clientes: Autenticación con OpenLDAP
Una de las principales razones para usar LDAP es centralizar la autenticación de los usuarios en un único sistema servidor (ya sea para iniciar sesión, ftp, web, correo,...), en lugar de utilizar los clásicos archivos /etc/passwd, /etc/group y /etc/shadow. Para ello veremos las modificaciones que hay que realizar en un sistema Linux para que autentifique a los usuarios en un servidor LDAP, en primer lugar, será necesario instalar y configurar los paquetes libpam-ldap y libnss-ldap.
La librería pam-ldap permite que las aplicaciones que utilizan PAM para autentificarse, puedan hacerlo mediante un servidor LDAP. Para que el sistema linux se autentifique mediante un servidor LDAP es necesario instalar esta librería ya que utiliza PAM. El archivo de configuración de ésta librería es /etc/ldap.conf. Hay otras aplicaciones o servicios que utilizan PAM para la autentificación y por tanto podrían, gracias a la librería pam-ldap, autentificarse ante un servidor LDAP. Para especificar el modo de autentificación de cada servicio es necesario configurar los archivos que se encuentran en la carpeta /etc/pam.d/.
La librería nss-ldap permite que un servidor LDAP suplante a los archivos /etc/passwd, /etc/group y /etc/shadow como bases de datos del sistema. Su archivo de configuración se encuentra en /etc/libnss-ldap.conf (o /etc/ldap.conf en versiones recientes como la que he usado yo, la 2.4.2). Posteriormente deberemos configurar el arhivo /etc/nsswitch.conf para que se utilice LDAP como base de datos del sistema en lugar de los archivos passwd, group y shadow
3.1 Instalación y configuración de libpam-ldap
La instalación de la librería libpam-ldap se puede realizar ejecutando el comando (instalará ya todas librerías necesarias como libnss-ldap):
# apt-get install libpam-ldap
Nos lanzará un asistente que nos pedirá los siguientes datos, que se almacenarán en el fichero /etc/lapd.conf desde dónde podremos modificarlos en cualquier momento a posteriori (basado en la versión 2.4.2 de openldap):
-
Quién es el servidor LDAP (nombre o IP) *en el caso de emplear la ip deberemos escribir ldap no ldapi, ya que sino resolverá el finger pero no nos permitirá autenticarnos: ldap://192.168.2.3/
-
Cuál es la base de nuestro directorio LDAP (base DN): dc=mczones,dc=es
-
Cuál es la versión de LDAP a utilizar: 3
-
Hacer que las utiliadades password que usen ldap se comporte como si cambiaramos las locales:si
-
Necesitamos conectarnos a la base de datos LDAP para recibir las entradas: NO
-
Cuenta LDAP para el usuario root: cn=admin,dc=mczones,dc=es
-
Contraseña del administrador.
Finalmente tendremos, por lo tanto, las siguientes líneas en el fichero /etc/ldap.conf
// Configurar en /etc/ldap.conf host 192.168.2.3 //nombre o IP del servidor LDAP base dc=mczones,dc=es uri ldap://192.168.2.3 ldap_version 3 rootbinddn cn=admin,dc=mczones,dc=es pam_password md5 nss_base_passwd ou=usuarios,dc=mczones,dc=es?sub nss_base_shadow ou=usuarios,dc=mczones,dc=es?sub nss_base_group ou=grupos,dc=mczones,dc=es?sub Tras el carácter “?”, se puede poner one (por defecto), base o sub; yo he empleado sub para que también compruebe los usuarios y contraseñas creados colgando de la unidad organizativa “usuarios” -es decir en las unidades organizativas contabilidad y desarrollo-.
3.1 Configuración de NSS
Para que el servidor LDAP actúe como si se tratara de los archivos passwd, group y shadow, además de instalar las dos librerías anteriores, debemos indicar que se utilice LDAP como alternativa para autentificar usuarios. Para ello hay que añadir en las líneas que hacen referencia a passwd, group y shadow en el archivo /etc/nsswitch.conf, la palabra 'ldap' tras la palabra 'compat' quedando el archivo /etc/nsswitch.conf así:
// Archivo /etc/nsswitch.conf # /etc/nsswitch.conf passwd: compat ldap group: compat ldap shadow: compat ldap hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 networks: files protocols: db files services: db files ethers: db files rpc: db files netgroup: nis
3.2 Configuración de servicios PAM
Nuestro sistema ya estaría preparado para autentificarse por LDAP. Editando los archivos que hay en la carpeta /etc/pam.d, podemos configurar la forma en la que se autentifica cada uno de los servicios que requieren autentificación. Para no tener que configurar de cada uno de los servicios, existen unos archivos comunes cuyo nombre empieza por common que afectan a la mayoría de ellos y sus archivos de configuración los referencian mediante una línea @include a los archivos comunes causando el mismo el efecto que si el contenido de los archivos comunes estuviera copiado en el lugar de la línea @include. Los archivos comunes son:
/etc/pam.d/common-auth (para autentificarse)
/etc/pam.d/common-account (para disponer de una cuenta)
/etc/pam.d/common-session (para poder iniciar sesion)
/etc/pam.d/common-password (para poder cambiar password)
La configuración de los archivos comunes para emplear LDAP se puede hacer de modo automático tecleando en consola pam-auth-update que nos permite seleccionar el perfil a emplear. Si queremos que cada vez que entremos en una sesión se verifique si el usuario ya tiene un directorio personal (home) en el equipo para que si no es así sea creado (la primera vez me advertirá como se ve en la imagen que va a crear el directorio personal), deberíamos añadir la siguiente línea al final del fichero /etc/common-session:
session required pam_mkhomedir.so skel=/etc/skel/ umask=0022
Si deseamos que algún servicio se autentifique de forma diferente, podemos editar el archivo del servicio (ej: /etc/pam.d/su, /etc/pam.d/ssh, /etc/pam.d/ftp, etc...), eliminar la línea que comienza por @include e introducir la configuración particular que deseemos.
3.3 Probar la autentificación
Ahora mismo ya deberíamos poder autentificarnos de modo correcto. Para probarlo podemos emplear el comando pamtest que está en el paquete libpam-dotfile:
sudo apt-get isntall libpam-dotfile
Podemos probar si funciona el cambo de contraseña sobre cualquier usuario sobre c2, por ejemplo.
También podemos usar el comando finger sobre usuarios que sólo estén en LDAP y en sistema local.
Incluso podemos emplear, directamente el comando su desde la consola para cambiarnos a los usuarios que sólo estén dados de alta en el sistema LDAP.
Tras ello ya podremos cerrar sesión y entrar en los equipos como los usuarios dados de alta en LDAP:
4. Otros ficheros y directorios
Además de los citados ficheros se deberían tener presentes los siguientes:
Para logs: /var/log/syslog y /var/log/auth.log
Almacenar la Base de datos y los backups: /var/lib/ldap y /var/backups respectivamente
Fichero de configuración del demonio slapd en el servidor: /etc/default/slapd
para continuar viendo el resto de manuales Linux siga el enlace:administración de servidores con Linux
5. Enlaces
Samba PDC en Debian :: Improvisa :: Magazine Digital :: Informatica ...
Ubuntu Server PDC - Página 5 | jorge.herskovic | Jorge Herskovic
OpenLDAP-SambaPDC-OrgInfo-Posix - Community Ubuntu Documentation
Installing custom ldap schema 6.0 - Zimbra :: Wiki
OpenLDAPServer - Community Ubuntu Documentation
Linux Tutorial - Apache Web Login Authentication:
Configurar un servidor Controlador de Dominio con Samba y OpenLDAP en Ubuntu Server Hardy 8.04
En busca de la solución definitiva para la autenticación | CRySoL
How-To set up a LDAP server and its clients -- page 2 | Debian/Ubuntu ...
martes, 18 de mayo de 2010
O nivel de aplicación
Artículo copiado da páxina do IES S. Clemente de Santiago.
Neste tema descríbese toda unha serie de aplicacións ou programas que utilizan a rede como medio de comunicación, así como os protocolos de comunicacións que teñen asociados. Devanditas aplicacións coñécense como aplicacións distribuídas, posto que están formadas por diferentes partes e cada unha se atopa en máquinas diferentes. Por norma xeral, hai unha parte chamada servidor que se executa nun computador, á que se conectan os diferentes clientes (que se atopan noutros computadores remotos) para requirir os seus servizos (polo xeral, solicitan a execución dalgún tipo de operación). Existe unha gran cantidade de aplicacións que seguen este modelo e que, nalgúns casos, usamos diariamente, entre elas: o correo electrónico, a navegación Web, a mensaxería instantánea, a telefonía IP, o acceso remoto a outros computadores, a vídeoconferencia, a computación paralela masiva, a compartición de ficheiros, os xogos en rede multiusuario, a descarga de vídeo e audio e un longo etc. Estas aplicacións empregan protocolos concretos para poder entenderse. Este protocolos atópanse no nivel de aplicación. As aplicacións execútanse en diferentes computadores no que se coñece como sistemas finais, e comunícanse mediante a rede. Por exemplo: un programa que fai de servidor Web comunícase cun programa navegador. Xa que logo, a comunicación para unha aplicación en rede ten lugar entre sistemas finais no nivel de aplicación. Hai tres tipos de arquitecturas para as aplicacións en rede: O modelo ou arquitectura cliente/servidor está formado por dúas partes. Moitas das aplicacións de uso frecuente de Internet, como a navegación Web ou o correo electrónico, usan este modelo. Este modelo ten unhas características diferenciadas respecto á cliente/servidor pura. Estas diferenzas son as seguintes: A principal vantaxe desta arquitectura fronte a anterior é que é moi escalable. Como contrapartida é máis difícil de xestionar. Son unha mistura das anteriores. De tal xeito que para algunhas funcións usan un servidor central e para outras fan unha comunicación directa con outro peer. Vexámolo con dúas aplicacións de exemplo: Un proceso é un programa que se executa nun computador. Un proceso cliente é o que inicia a comunicación. Un proceso servidor é o que espera a ser contactado. Por exemplo: O programa As aplicacións están formadas por varios procesos. No caso das arquitecturas P2P as aplicacións teñen procesos clientes e procesos servidores ao mesmo tempo. Os procesos pertencen a un usuario que, normalmente, os lanza ou provoca que se lancen. Para ver os procesos dun usuario que se están executando nun computador para podes teclear: Nun computador pode haber varios procesos executándose polo que se identifican mediante un número de porto. Os procesos comunícanse uns cos outros a través dos sockets. Un socket especifica a dirección, o porto e o protocolo de transporte que se usa na comunicación. Por exemplo: (192.168.100.10, 80, TCP). Os procesos comunícanse enviándose mensaxes. As características destas mensaxes están determinadas no protocolo, o cal define: Os protocolos do nivel de aplicación poden ser de dominio público ou propietarios. No primeiro caso, están definidos nos RFC (Request For Comments). Ao estar publicamente accesibles permiten a interoperabilidade entre aplicacións de distintos fabricantes. Exemplos deste tipo de protcolos son HTTP (HyperText Transfer Protocol) ou o SMTP (Single Mail Transfer Protocol). No segundo caso é o fabricante dun determinado software quen o define e a interoperabilidade non está garantida. Un exemplo deste tipo de protocolos é o que usa a aplicación Skype. O HTTP naceu no 1989 no CERN (Centro Europeo de Investigación Nuclear). A Web xurdiu pola necesidade de lograr que os equipos de investigadores dispersos internacionalmente colaborasen, usando un conxunto sempre cambiante de informes, planos, debuxos, fotos e outros documentos. A proposta inicial dunha rede (web) de documentos vinculados xurdiu do físico do CERN Tim Berners-Le. O primeiro prototipo estaba baseado só en texto. En decembro de 1991 fíxose unha demostración pública e o desenvolvemento continuou durante o seguinte ano, culminando coa liberación da primeira interface gráfica, Mosaic, no ano 1993. Mosaic tivo tanto éxito que, un ano despois, o seu autor, Marc Andreeseen formou a compañía, Netscape Communications Corp. En 1994, o CERN e o M.I.T. asinaron un acordo para establecer o World Wide Web Consortium, unha organización adicada ao desenvolvemento da Web, a estandarización de protocolos e o fomento da interoperabilidade entre as instalacións. Berners-Le converteuse no director. As páxinas Web están formadas por obxectos. Os obxectos poden ser ficheiros HTML, imaxes, ficheiros de audio, vídeo, etc. Unha páxina web é un ficheiro HTML base que inclúe varias referencias aos obxectos. A cada obxecto accédese mediante unURL (Uniform Resource Locator) que ten a seguinte forma: O HTTP é un protocolo do nivel de aplicación para a Web. Segue o modelo ouarquitectura cliente/servidor, tal e como se ve na figura. O cliente é un navegador (browser) que solicita, recibe, e mostra obxectos Web. O servidor Web envía obxectos como resposta ás peticións do cliente. Hai dúas versións do protocolo, o HTTP 1.0, especificada no RFC 1945, e o HTTP 1.1, especificado no RFC 2068. HTTP utiliza TCP como protocolo de transporte. Os clientes inician conexións TCP (crean un socket) co servidor, no porto 80. Os servidores aceptan conexións TCP dos clientes. Unha vez establecida a conexión intercámbianse mensaxes HTTP (mensaxes do protocolo do nivel de aplicación) entre o cliente (cliente HTTP) e o servidor Web (servidor HTTP). Finalmente, péchase a conexión TCP. HTTP non ten “estados” (stateless). Isto quere dicir que o servidor non mantén información sobre solicitudes anteriores dos clientes. Deseñouse así porque os protocolos que manteñen o estado son complexos, xa que hai que manter un histórico do que acontece (estado). Se o cliente ou o servidor fallan pode haber inconsistencias e deberán volver ao estado anterior, co correspondente consumo de recursos. As conexións HTTP poden ser de dous tipos: En HTTP hai mensaxes de solicitude e mensaxes resposta. Ambas as dúas mensaxes están en formato ASCII, polo que poden verse e lerse se capturamos unha sesión HTTP cun analizador de rede como, por exemplo, o Wireshark. Unha mensaxe HTTP de solicitude ten o seguinte formato: Se queremos facer unha solicitude de envío de datos (por exemplo, cando facemos unha consulta nun buscador enviámoslle ao servidor a palabra a buscar, ou cando enviamos un formulario) podemos usar dous métodos: Dependendo da versión do protocolo que se use están soportadas distintas mensaxes HTTP (tamén coñecidas como métodos): As mensaxes HTTP de resposta teñen un formato similar ás de solicitude: As mensaxes de resposta inclúen un código dependendo do significado da mesma. Dito código vai na primeira liña da mensaxe (liña de estado). Algúns exemplos son os seguintes: Dixemos que HTTP é un protocolo sen estado. Isto, ás veces, pode non ser o desexado. Por exemplo, supoñamos que temos unha web na que as súas páxinas están restrinxidas a determinados usuarios. Se non mantemos o estado do cliente teremos que estar solicitándolle para cada páxina que queira ver o seu nome de usuario e clave. HTTP resolve este escenario coas cookies. As cookies están definidas no RFC 2109 e permiten monitorizar a navegación do usuario. Moitos sites usan cookies. Son útiles, por exemplo, para validar un usuario, escoller opcións personalizadas (idioma, etc.), rexistrar hábitos de navegación, etc. Están formadas por catro compoñentes: Un exemplo de funcionamento das cookies podémolo ver na figura. Dun modo xenérico, pódese definir un proxy como un software que fai de intermediario entre un cliente e un servidor. Os proxies en HTTP úsanse, entre outras cousas, para facer de caché das páxinas visitadas. É o que se coñece como un Web cache e o seu obxectivo é respostar aos clientes sen interactuar co servidor, gañando en velocidade, xa que o proxy está normalmente na mesma rede ou máis cercano que o servidor Web que contén a páxina orixinal. O proxy configúrase no navegador. É o navegador quen envía as solicitudes HTTP ao proxy. Se o obxecto está na cache o proxy é quen o devolve. Se non, o proxy solicita o obxecto ao servidor orixinal que á súa vez é enviado ao cliente. O proxy ten, xa que logo, unha parte cliente e outra servidor. Normalmente instálanse en universidades, compañías, ISP, etc., para axilizar o tráfico. Entre as vantaxes de usar un servidor proxy están as seguintes: Un exemplo de software de servidor proxy é o Squid. Instalación e configuración do servidor Web Apache
Contenido
Introdución
Arquitecturas de aplicacións en rede
Arquitectura cliente/servidor
Arquitectura P2P pura
Un exemplo de programa que usa unha arquitectura P2P pura é o software de intercambio de ficheiros Gnutella, que usa protocolo de distribución de ficheiros entre pares, sen un servidor central.
Arquitecturas híbridas C/S e P2P
Comunicación de procesos
dhclient
lanza un proceso cliente que solicita unha dirección IP. O programa dhcpd
espera a recibir peticións para respostar con direccións IP dinámicas aos clientes.ps -u nome_usuario
Protocolos do nivel de aplicación
O HTTP
Un pouco de historia
Conceptos previos
Características
Tipos de conexións
Mensaxes
Solicitudes
www.unsite.com/buscaAnimal?mono&banana
Respostas
200 OK
Solicitude correcta, envíarase o obxecto solicitado nesta mensaxe 301 Moved Permanently
Obxecto solicitado noutro URL, especifícase a nova localización nesta mensaxe (Location:) 400 Bad Request
Mensaxe non entendida polo servidor 404 Not Found
Obxecto solicitado non atopado no servidor 505 HTTP Version Not Supported
As cookies
Servidores Proxy
Instalación e configuración do Apache
O File Transfer Protocol
O DNS
O correo electrónico