En el anterior post expliqué NFS y como se como se configura el servidor, ahora nos toca ver la configuración de lado cliente. Vale la pena mencionar que para usar una máquina como cliente NFS, necesitamos que el portmapper esté corriendo en el cliente, también es necesario iniciar los "demonios" que iniciamos en el servidor e iniciarlos en el boot.
/etc/init.d/portmap start
/etc/init.d/nfs start
/etc/init.d/nfslock start
Y para que estos demonios inicien cada vez que reinicie el servidor, los activamos al boot con chkconfig:
/sbin/chkconfig --level 345 portmap on
/sbin/chkconfig --level 345 nfs on
/sbin/chkconfig --level 345 nfslock on
Montando el volumen remoto
Con los servicios iniciados, podemos montar un file system remoto de la misma forma que montamos un disco local, con el comando mount.
Continuando con el post anterior, supongamos que tenemos dos clientes que tienen las direcciones IP 10.87.175.154 y 10.87.175.164 y deseamos compartir la partición /data02 del servidor 10.87.175.168. Todo lo que tenemos que hacer en uno de los clientes es (como root) crear el directorio donde vamos a montar el file system remoto y... montarlo:
# mkdir /data02
# mount 10.87.175.168:/data02 /data02
Posteriormente podemos desmontar el volumen:
# umount /data02
Tal como lo hacemos con file systems locales.
Montando el volumen remoto al arranque
Los sistemas de archivos NFS pueden ser agregados al archivo local /etc/fstab. Al igual que agregamos disco locales, la diferencia es que el tipo de file system será nfs. Por ejemplo:
dispositivo punto de montaje tipo opciones dump fskorder
...
10.87.175.168:/data02 /data02 nfs rw 0 0
...
Opciones para el montaje en fstab
Existe algunas opciones a considerar que definen el comportamiento del cliente cuando el servidor no responde:
soft. Con esta opción, cuando una petición no tiene respuesta del servidor el cliente devuelve un código de error al proceso que realizó la petición. El problema es que muy pocas aplicaciones esperan este comportamiento y ello puede provocar situaciones en las que se pierda información. Por tanto, no es aconsejable.
hard. Mediante esta opción, cuando el servidor no responde el proceso que realizó la petición en el cliente se queda suspendido indefinidamente. Esta es la opción que se recomienda normalmente, por ser la que esperan las aplicaciones, y por tanto más segura desde el punto de vista de los datos. Esta opción se puede combinar con la opción intr, que permite matar el proceso mediante el envío de una señal (de la forma tradicional en Linux).
Con lo anterior, el archivo fstab quedaría:
dispositivo punto de montaje tipo opciones dump fskorder
...
10.87.175.168:/data02 /data02 nfs rw,hard,intr 0 0
...
Ya para terminar montamos:
# mount /data02
DONE.
Tweet
miércoles, 30 de marzo de 2011
Configuración de un servidor NFS
Hoy me solicitaron exportar por NFS (Network File System) una partición de un servidor y montarla en dos servidores. Lectura recomendada: http://es.wikipedia.org/wiki/Network_File_System
Bien, el protocolo NFS tiene múltiples usos prácticos. Los más típicos se enumeran a continuación:
Esta configuración se hace desde dos lados: el servidor y los clientes.
SERVIDOR
Primero verificar que el paquete nfs-utils esté instalado (yum install nfs-utils).
Esto se logra en dos sencillos pasos: los archivos de configuración (/etc/exports, /etc/hosts.allow y /etc/hosts.deny) e iniciar los servicios NFS.
Archivo /etc/exports
Este archivo contiene una lista de entradas que indican el volumen que está compartido y cómo está compartido. Una entrada en este archivo se verá así:
directorio máquina1(opción1, opción2) máquina2(opción1,opción2)
donde:
directorio es el directorio que se quiere compartir. Puede ser un volumen completa (partición) o no. Si se comparte un directorio, entonces todos los directorios y archivos también serán compartidos.
máquina1 y máquina2 son los equipos cliente que tendrán acceso al directorio. Los clientes pueden ser listados por IP o nombre, pero se recomienda usar direcciones IP. También pueden ser redes completas, por ejemplo: 10.87.175.0/255.255.255.0.
opción1 y opción2 Estas opciones describen el tipo de acceso: Las opciones son:
Entonces, supongamos que tenemos dos clientes que tienen las direcciones IP 10.87.175.154 y 10.87.175.164 y deseamos compartir la partición /data02. El archivo /etc/exports podría ser:
/data02 10.87.175.154(ro) 10.87.175.164(ro)
Ya mencionamos arriba que se puede compartir un volumen a una red completa, con lo que el archivo de configuración sería:
Tweet
Bien, el protocolo NFS tiene múltiples usos prácticos. Los más típicos se enumeran a continuación:
- Compartir la unidad de CDROM entre varias máquinas. Esto resulta ser más barato y una forma más conveniente para instalar software en varias máquinas.
- En grandes redes puede ser más adecuado configurar un servidor central de NFS en el cual se almacenen todos los “homes” de los distintos usuarios. Estos directorios se pueden exportar a través de la red de tal forma que los usuarios pueden trabajar con el mismo directorio independientemente de la máquina que utilicen.
- Varias máquinas pueden poseer un directorio /apps. De este modo cuando necesitemos instalar un paquete en varias máquinas, se puede acceder rápidamente a las fuentes sin necesidad de bajarlas una vez para cada máquina.
Esta configuración se hace desde dos lados: el servidor y los clientes.
SERVIDOR
Primero verificar que el paquete nfs-utils esté instalado (yum install nfs-utils).
Esto se logra en dos sencillos pasos: los archivos de configuración (/etc/exports, /etc/hosts.allow y /etc/hosts.deny) e iniciar los servicios NFS.
Archivo /etc/exports
Este archivo contiene una lista de entradas que indican el volumen que está compartido y cómo está compartido. Una entrada en este archivo se verá así:
directorio máquina1(opción1, opción2) máquina2(opción1,opción2)
donde:
directorio es el directorio que se quiere compartir. Puede ser un volumen completa (partición) o no. Si se comparte un directorio, entonces todos los directorios y archivos también serán compartidos.
máquina1 y máquina2 son los equipos cliente que tendrán acceso al directorio. Los clientes pueden ser listados por IP o nombre, pero se recomienda usar direcciones IP. También pueden ser redes completas, por ejemplo: 10.87.175.0/255.255.255.0.
opción1 y opción2 Estas opciones describen el tipo de acceso: Las opciones son:
- ro — Se montan los sistemas de archivos como sólo lectura. Los host remotos no pueden hacer cambios a los datos compartidos en el sistema de archivos. Para permitir que los hosts puedan hacer cambios, debe especificar la opción rw.
- wdelay — Provoca que el servidor NFS retrase el escribir a disco si sospecha que otra petición de escritura es inminente. Esto puede mejorar el rendimiento reduciendo las veces que se debe acceder al disco por comandos de escritura separados. Use no_wdelay para desactivar esta opción, la cual sólo funciona si está usando la opción sync.
- sync — Permite al servidor escribir los datos en el disco cuando lo crea conveniente. Mientras que esto no tiene importancia en un sistema de sólo lectura, si una máquina hace cambios en un sistema de archivos de lectura-escritura y el servidor se cae o se apaga, se pueden perder datos. Especificando la opción sync, todas las escrituras en el disco deben hacerse antes de devolver el control al cliente. Esto puede que disminuya el rendimiento.
- root_squash — Previene a los usuarios root conectados remotamente de tener privilegios como root asignándoles el id del usuario de nobody. Esto reconvierte el poder del usuario root remoto al de usuario local más bajo, previniendo la alteración no autorizada de archivos en el servidor remoto. Alternativamente, la opción no_root_squash lo desactiva. Para reconvertir a todos los usuarios, incluyendo a root, use la opción all_squash. Para especificar los ID de usuario y grupo para usar con usuarios remotos desde un host particular, utilice las opciones anonuid y anongid, respectivamente. De esta manera, puede crear una cuenta de usuario especial para que los usuarios NFS remotos compartan y especificar (anonuid=<uid-value>,anongid=<gid-value>), donde <uid-value> es el número de ID del usuario y <gid-value> es el número de ID del grupo.
Entonces, supongamos que tenemos dos clientes que tienen las direcciones IP 10.87.175.154 y 10.87.175.164 y deseamos compartir la partición /data02. El archivo /etc/exports podría ser:
/data02 10.87.175.154(ro) 10.87.175.164(ro)
Ya mencionamos arriba que se puede compartir un volumen a una red completa, con lo que el archivo de configuración sería:
/data02 10.87.175.0/255.255.255.0(ro)
Archivos /etc/hosts.allow y /etc/hosts.deny
Estos archivos especifican las máquinas que pueden usar servicios en nuestro equipo. Cada línea del archivo contiene una entrada sencilla listando un servicio y un conjunto de máquinas. Cuando el servidor recibe un request de una máquina sucede lo siguiente:
- Primero checa el hosts.allow. Si la máquina se encuentra en la lista se le concede el acceso.
- Segundo checa el hosts.deny. Si la máquina se encuentra en la lista se le deniega el acceso.
- Si la máquina no se encuentra listada en algún archivo, se concede el acceso.
En general, es una buena idea conceder acceso de forma explícita a los servicios del servidor. Entonces, agregamos las siguientes línea al hosts.deny:
portmap:ALL
lockd:ALL
mountd:ALL
rquotad:ALL
statd:ALL
Una vez hecho esto concedemos acceso al servidor NFS, en el hosts.allow:
portmap:10.87.175.154 , 10.87.175.154
lockd:10.87.175.154 , 10.87.175.154
lockd:10.87.175.154 , 10.87.175.154
mountd:10.87.175.154 , 10.87.175.154
rquotad:10.87.175.154 , 10.87.175.154
statd:10.87.175.154 , 10.87.175.154
Iniciando los servicios
NFS depende del "demonio" portmapper, también llamado portmap. El cual podemos iniciar de dos modos:
/etc/init.d/portmap start ó /sbin/service portmap start
Y luego iniciar otros demonios en el siguiente orden:
/usr/sbin/rpc.mountd
/etc/init.d/nfs start
/sbin/rpc.statd
/etc/init.d/nfslock start
Y para que estos demonios inicien cada vez que reinicie el servidor, los activamos al boot con chkconfig:
/sbin/chkconfig --level 345 portmap on
/sbin/chkconfig --level 345 nfs on
/sbin/chkconfig --level 345 nfslock on
Ya por último, verificamos que todo esté correcto:
/usr/sbin/rpcinfo -p
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 636 status
100024 1 tcp 639 status
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100021 1 udp 56845 nlockmgr
100021 3 udp 56845 nlockmgr
100021 4 udp 56845 nlockmgr
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100021 1 tcp 57152 nlockmgr
100021 3 tcp 57152 nlockmgr
100021 4 tcp 57152 nlockmgr
100005 1 udp 1015 mountd
100005 1 tcp 1018 mountd
100005 2 udp 1015 mountd
100005 2 tcp 1018 mountd
100005 3 udp 1015 mountd
100005 3 tcp 1018 mountd
DONE, ahora estamos listos para configurar los clientes!
Update: Si agregaron nuevos exports, la forma correcta para publicarlos es la siguiente:
# /usr/sbin/exportfs -ra && /etc/init.d/nfs reload
Update: Si agregaron nuevos exports, la forma correcta para publicarlos es la siguiente:
# /usr/sbin/exportfs -ra && /etc/init.d/nfs reload
martes, 15 de marzo de 2011
Instalación de Apache en RHEL 5 de Utter Ramblings
Quiero pensar que por facilidad, los usuarios de CEntOS y RHEL, decidimos instalar el servidor Apache HTTPD del repo de Jason Litka (http://www.jasonlitka.com), que al momento de redactar estas líneas nos ofrece la versión 2.2.17 para i386 y x86_64. Cabe señalar que la última actualización es del 17 de diciembre de 2010. Otra opción sería que no exista RPM oficial, problemas con RHN, y si saben alguna otra no estaría de más que la comentaran...
Aquí pueden ver la lista de paquetes para RHEL 5 http://www.jasonlitka.com/media/EL5/
A trabajar, para verificar que los paquetes sean válidos debemos instalar la llave GPG. Esto lo hacemos con el comando:
rpm --import http://www.jasonlitka.com/media/RPM-GPG-KEY-jlitka
Posteriormente, agregamos el repo a yum. Para lo cual creamos el archivo utterramblings.repo en /etc/yum.repos.d/ (con su editor favorito vi o nano)
vi /etc/yum.repos.d/utterramblings.repo ó
nano -w /etc/yum.repos.d/utterramblings.repo
Luego, peguen las siguientes líneas en el archivo:
[utterramblings]
name=Jason's Utter Ramblings Repo
baseurl=http://www.jasonlitka.com/media/EL$releasever/$basearch/
enabled=1
gpgcheck=1
gpgkey=http://www.jasonlitka.com/media/RPM-GPG-KEY-jlitka
Ahora ya podemos instalar el servidor Apache httpd.
yum install --enablerepo=utterramblings httpd
Iniciamos el apache y verificamos que todo esté correcto.
/etc/init.d/httpd start
Por último, deshabilitamos el repo agregado para evitar conflictos con los existentes, editamos el archivo utterramblings.repo (creado al inicio) y cambiamos el valor de enabled de 1 a 0.
Listo, tenemos el servidor Apache HTTPD funcionando.
Tweet
Aquí pueden ver la lista de paquetes para RHEL 5 http://www.jasonlitka.com/media/EL5/
A trabajar, para verificar que los paquetes sean válidos debemos instalar la llave GPG. Esto lo hacemos con el comando:
rpm --import http://www.jasonlitka.com/media/RPM-GPG-KEY-jlitka
Posteriormente, agregamos el repo a yum. Para lo cual creamos el archivo utterramblings.repo en /etc/yum.repos.d/ (con su editor favorito vi o nano)
vi /etc/yum.repos.d/utterramblings.repo ó
nano -w /etc/yum.repos.d/utterramblings.repo
Luego, peguen las siguientes líneas en el archivo:
[utterramblings]
name=Jason's Utter Ramblings Repo
baseurl=http://www.jasonlitka.com/media/EL$releasever/$basearch/
enabled=1
gpgcheck=1
gpgkey=http://www.jasonlitka.com/media/RPM-GPG-KEY-jlitka
Ahora ya podemos instalar el servidor Apache httpd.
yum install --enablerepo=utterramblings httpd
Iniciamos el apache y verificamos que todo esté correcto.
/etc/init.d/httpd start
Por último, deshabilitamos el repo agregado para evitar conflictos con los existentes, editamos el archivo utterramblings.repo (creado al inicio) y cambiamos el valor de enabled de 1 a 0.
Listo, tenemos el servidor Apache HTTPD funcionando.
Tweet
Suscribirse a:
Entradas (Atom)