[opensuse-es] particionamiento, buenas practicas
Hola, que recomendación o que tenéis en cuenta a la hora de particionar un servidor? A parte del tamaño en si de cada partición también es interesante saber tipo de FS, si usais LVM o no, particiones primarias o extendidas, y en el caso de ser virtual con vmware si asignais pocos discos grandes... muchos pequeños... tamaño de cada disco etc. Pensando siempre en la seguridad y en el caso de que haya problemas en algún disco afecte al menor numero de usuarios, sin olvidar herramientas de recuperación ante desastres gracias -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) On Tuesday 01 December 2009 15:06:43 aux wrote:
Hola, que recomendaci�n o que ten�is en cuenta a la hora de particionar un servidor? A parte del tama�o en si de cada partici�n tambi�n es interesante saber tipo de FS, si usais LVM o no, particiones primarias o extendidas, y en el caso de ser virtual con vmware si asignais pocos discos grandes... muchos peque�os... tama�o de cada disco etc. Pensando siempre en la seguridad y en el caso de que haya problemas en alg�n disco afecte al menor numero de usuarios, sin olvidar herramientas de recuperaci�n ante desastres
Lo que preguntas no es fácil de responder y te tendríamos que responder con muchas más preguntas: - ¿Para qué vas a usar el servidor? ¿BBDD? ¿Correo? ¿NAS? ... - ¿Cuánto almacenamiento necesitas? - ¿IOPS? ¿Ancho de banda? - ¿Cuántos usuarios conectados simultáneamente? - ¿Crecimiento de datos? - ¿Almacenamiento interno o externo? - ¿Alta disponibilidad? - ... De buenas a primeras unos consejos: - si usas VMWare _tienes_ que usar _su_ sistema de ficheros o te quedas sin soporte - yo particionaría de la siguiente manera: / ext3 5 GB swap swap depende de RAM y tareas /tmp reiserfs depende de tareas /var depende depende de servicios /home depende depende de tareas - en cuanto a si primaria o lógica, da igual - LVM: importante tener en cuenta que NO tiene protección de datos, es decir, debajo deberías poner un RAID sea por hardware o por software. Muy útil si piensas crecer en volumen de datos - RAID: depende de lo que vayas a hacer: RAID 1 y 0 son rápidos (IOPS y ancho de banda respectivamente), pero 0 no tiene protección de datos. RAID 6 mejor que RAID 5 para protección de datos - FS: cada uno tiene sus ventajas e inconvenientes, reiserfs es muy bueno con ficheros pequeños, XFS es muy bueno si tienes 2+ cores y RAID y pretendes escalar mucho, ... - tamaño del disco depende de lo que estés haciendo, si es una tarea/proceso IOPS intensiva, mejor discos pequeños y rápidos y muchos de ellos. - con respecto a la virtualización, tienes un problema doble: un sistema de ficheros sobre otro y un dispositivo de bloques sobre otro, conseguir alinear todas las lecturas/escrituras es imposible por lo que vas a tener un rendimiento malo (de ahí que VMWare haya sacado el suyo) si a eso sumas RAID y/o LVM ... peor aún tanto para la seguridad de los datos como para el rendimiento del almacenamiento - recuperación ante desastres: XFS tiene herramientas muy potentes (no conozco los demás filesystems). En cuanto a otras técnicas: RAID, backups (doble copia o más si fuera necesario y en diferentes medios: disco y cinta, por ejemplo), disaster recovery y business continuance HTH Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org Happily using KDE 4.3.3 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Saludos.
Como dice el colistero Rafa Griman en su post, son muchos los factores
a tener en cuenta al momento de definir la forma en que se van a usar
los discos en el servidor. Cuales son relevantes y cuales no, dependen
de las circunstancias y la disponibilidad de recursos. Es decir, no
puedes hablar de un raid 50 o un raid 60, para un servidor que cuesta
USD$1000 para una empresa que requiere un servidor simple de correo o
un gateway/proxy externo y que no dispone de muchos recursos para
invertir.
En terminos generales usar RAID por hardware es lo mas recomendado en
arreglos 1, 5, 10, 50, 60
(http://en.wikipedia.org/wiki/Nested_RAID_levels). Como minimo usar
raid 1. Si no hay forma de hacer un raid (no hay discos o el espacio
es reducido), toca trabajar como me han dicho en varias ocasiones "con
lo que da la tierrita". En ese caso se hacen los descargos de
responsabilidades y advertencias formales pertinentes.
A titulo personal no me gusta para nada el LVM, y mas en los
servidores. A otros les parece una solucion excelente sobre todo para
cuando el espacio se empieza a quedar pequeño. Yo pienso que con un
cuidadoso diseño pre-montaje, dificilmente el espacio en disco
definido sera superado. Me parece un desproposito (a titulo personal),
porner LVM para un proxy, un firewall, un servidor de voz, un servidor
web o un servidor de bases datos, pero me parece digno de analizar
(sobre todo cuando no hay mucho dinero), para un servidor de correo
para el cual se desconoce cuantos buzones va a soportar (algo que muy
rara vez ocurre) y sobre todo para un servidor de archivos
compartidos. De nuevo esto depende de los gustos y de las experiencias
de quien monta el servidor. Mi objetivo siempre es el KIS (Keep It
Simple) y el LVM en mi opinion agrega una capa mas de complejidad al
asunto y por ende debe evitarse.
En cuanto a particiones y tipos de FS, es importante tener en cuenta
en cuenta lo siguiente:
a) En la mayoria de las ocasiones la eficiencia del fs en cuanto al
I/O rara vez representa un valor significativo en el desempeño del
servidor. En entornos especificos como la virtualizacion, las BD de
alto volumen de transaciones o los servidores que manejan cientos de
miles de archivos o se dedican a la multimedia, esto es realmente
relevante. Se busca en este caso fs optimos para estos entornos con
tunings muy especificos y ante todo se busca tener hardware de alto
rendimiento. En otras palabras los servidores para estos casos no
cuestan US$1000.
b) Crear multiples particiones tiene un doble objetivo: robustecer la
seguridad del servidor por medio de opciones de montaje especificas
para distintas ubicaciones en la jerarquia de archivos (no esta de mas
leerse el FHS), y de otro lado reducir el impacto que el daño fisico
de los discos produce sobre la informacion o la misma corrupcion del
FS. En esto ultimo cabe decir que es mas facil recuperar la
informacion de una particion de 20GB que de una particion de 200GB y
ni hablar de recuperar la info en un servidor despues de una falla
electrica.
Con todo esto en mente, recomendaria lo siguiente:
1) FS para servidores linux de proposito general de uso bajo a medio:
ext3 o reiserfs (este ultimo en caso de tener que manejar cientos de
miles de archivos pequeños)
2) Distribucion de las particiones:
------- particiones de 'proposito general' --------------------
/ 2-4GB
/tmp 1-2 GB (mas si es un servidor de correo)
swap segun se recomiende para la ram disponible
/usr 5 GB
/var 15GB minimo
/var/log 10GB minimo
/var/tmp 1GB
/var/lock 256MB
-------- a partir de aqui todo depende del uso del servidor ------
/var/lib depende del uso del servidor
/var/spool depende del uso del servidor
/srv ó /var/www depende del uso del servidor
/home depende del uso del servidor
[...] y la cosa sigue
en /var/lib se guardan los archivos de mysql y postgresql asi que si
el servidor es un servidor de BD de uno o dos de estos motores se debe
asignar el espacio necesario
/srv es la nueva ubicacion de los achivos de ftp y http (antes era
/var/ftp [creo] y /var/www) asi que si el servidor va a ser de este
tipo ...
/var/spool es usado bastante en servidores correo y voz.
En cuanto a las opciones de montaje:
/ defaults
/tmp defaults,nodev,nosuid,noexec
/usr defaults,nodev
/usr/local defaults,nodev
/var defaults,nodev
/var/lib defaults,nodev
/var/lock defaults,nodev,nosuid,noexec
/var/log defaults,nodev,nosuid,noexec
/var/tmp defaults,nodev,nosuid,noexec
/backup defaults,nodev,nosuid,noexec
/dev/shm defaults,nodev,nosuid,noexec
Para finalizar y no extendrer mucho el asunto cabe anotar que algunos
FS son mas resistentes que otros a los apagados incorrectos o muerte
subita del servidor. Aun asi, por mas resistente que sea el fs, nunca
esta de mas tener los backups del caso, preferiblemente fuera del
servidor. Sobre las opciones de montaje puedes dar una leida al
"Securing Debian Manual".
Hasta la proxima.
Carlos A. Martinez
2009/12/1 aux
Hola, que recomendación o que tenéis en cuenta a la hora de particionar un servidor? A parte del tamaño en si de cada partición también es interesante saber tipo de FS, si usais LVM o no, particiones primarias o extendidas, y en el caso de ser virtual con vmware si asignais pocos discos grandes... muchos pequeños... tamaño de cada disco etc. Pensando siempre en la seguridad y en el caso de que haya problemas en algún disco afecte al menor numero de usuarios, sin olvidar herramientas de recuperación ante desastres
gracias -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-12-01 a las 15:49 +0100, Rafa Grimán escribió: ...
- con respecto a la virtualización, tienes un problema doble: un sistema de ficheros sobre otro y un dispositivo de bloques sobre otro, conseguir alinear todas las lecturas/escrituras es imposible por lo que vas a tener un rendimiento malo (de ahí que VMWare haya sacado el suyo)
De eso no me he enterado, a mi el vmware se me instala sobre lo que tenga puesto en el anfitrión y pone lo que necesite el huesped. ¿Tienes más info sobre eso que dices? - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAksVeCwACgkQtTMYHG2NR9XvZwCffHC6GCkxsiVce7kbd8XnLvAC 3REAn0y+ze+J5IY7DJdHMcWFXGoWP72v =3fq9 -----END PGP SIGNATURE-----
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2009-12-01 a las 15:49 +0100, Rafa Grimán escribió:
...
- con respecto a la virtualización, tienes un problema doble: un sistema de ficheros sobre otro y un dispositivo de bloques sobre otro, conseguir alinear todas las lecturas/escrituras es imposible por lo que vas a tener un rendimiento malo (de ahí que VMWare haya sacado el suyo)
De eso no me he enterado, a mi el vmware se me instala sobre lo que tenga puesto en el anfitrión y pone lo que necesite el huesped. ¿Tienes más info sobre eso que dices?
Creo que Rafa se está refiriendo aquí a las versiones VMWare ESX/ESXi (versiones servidoras o barebone), no se está refiriendo a VMWare Server o Workstation. De todas formas con ESX/ESXi el sistema guest no tiene porque estar alojado en un filesystem. Puede ser instalado en raw disks o particiones e incluso en luns de una SAN ... Saludos.
- -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAksVeCwACgkQtTMYHG2NR9XvZwCffHC6GCkxsiVce7kbd8XnLvAC 3REAn0y+ze+J5IY7DJdHMcWFXGoWP72v =3fq9 -----END PGP SIGNATURE-----
-- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
carlopmart wrote:
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2009-12-01 a las 15:49 +0100, Rafa Grimán escribió:
...
- con respecto a la virtualización, tienes un problema doble: un sistema de ficheros sobre otro y un dispositivo de bloques sobre otro, conseguir alinear todas las lecturas/escrituras es imposible por lo que vas a tener un rendimiento malo (de ahí que VMWare haya sacado el suyo)
De eso no me he enterado, a mi el vmware se me instala sobre lo que tenga puesto en el anfitrión y pone lo que necesite el huesped. ¿Tienes más info sobre eso que dices?
Creo que Rafa se está refiriendo aquí a las versiones VMWare ESX/ESXi (versiones servidoras o barebone), no se está refiriendo a VMWare Server o Workstation.
De todas formas con ESX/ESXi el sistema guest no tiene porque estar alojado en un filesystem. Puede ser instalado en raw disks o particiones e incluso en luns de una SAN ...
Saludos.
Rectifico: la frase de "un sistema de ficheros sobre otro y un dispositivo de bloques sobre otro, conseguir alinear todas las lecturas/escrituras es imposible por lo que vas a tener un rendimiento malo" sí es aplicable a VMWare Server y Workstation y virtualbox y xen (si se utilizan image files) y kvm (por lo mismo que xen). Yo me referia a la parte de la frase de: "de ahí que VMWare haya sacado el suyo", ese filesystem solo está presente en ESX/ESXi. Saludos.
- -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAksVeCwACgkQtTMYHG2NR9XvZwCffHC6GCkxsiVce7kbd8XnLvAC 3REAn0y+ze+J5IY7DJdHMcWFXGoWP72v =3fq9 -----END PGP SIGNATURE-----
-- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) On Tuesday 01 December 2009 22:04:48 carlopmart wrote:
carlopmart wrote:
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2009-12-01 a las 15:49 +0100, Rafa Grimán escribió:
...
- con respecto a la virtualización, tienes un problema doble: un sistema de ficheros sobre otro y un dispositivo de bloques sobre otro, conseguir alinear todas las lecturas/escrituras es imposible por lo que vas a tener un rendimiento malo (de ahí que VMWare haya sacado el suyo)
De eso no me he enterado, a mi el vmware se me instala sobre lo que tenga puesto en el anfitrión y pone lo que necesite el huesped. ¿Tienes más info sobre eso que dices?
Creo que Rafa se está refiriendo aquí a las versiones VMWare ESX/ESXi (versiones servidoras o barebone), no se está refiriendo a VMWare Server o Workstation.
De todas formas con ESX/ESXi el sistema guest no tiene porque estar alojado en un filesystem. Puede ser instalado en raw disks o particiones e incluso en luns de una SAN ...
Saludos.
Rectifico: la frase de "un sistema de ficheros sobre otro y un dispositivo de bloques sobre otro, conseguir alinear todas las lecturas/escrituras es imposible por lo que vas a tener un rendimiento malo" sí es aplicable a VMWare Server y Workstation y virtualbox y xen (si se utilizan image files) y kvm (por lo mismo que xen).
Yo me referia a la parte de la frase de: "de ahí que VMWare haya sacado el suyo", ese filesystem solo está presente en ESX/ESXi.
0:) Eso es, me refería al ESX/ESXi. El otro se te instala en tu PC y trabaja sobre ficheros (que son el disco virtual) Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org Happily using KDE 4.3.3 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) On Tuesday 01 December 2009 19:14:30 Carlos Martinez wrote:
Saludos.
Como dice el colistero Rafa Griman en su post, son muchos los factores a tener en cuenta al momento de definir la forma en que se van a usar los discos en el servidor. Cuales son relevantes y cuales no, dependen de las circunstancias y la disponibilidad de recursos. Es decir, no puedes hablar de un raid 50 o un raid 60, para un servidor que cuesta USD$1000 para una empresa que requiere un servidor simple de correo o un gateway/proxy externo y que no dispone de muchos recursos para invertir.
En terminos generales usar RAID por hardware es lo mas recomendado en arreglos 1, 5, 10, 50, 60
Me alegra saber que hay otro que piensa como yo ;)
(http://en.wikipedia.org/wiki/Nested_RAID_levels). Como minimo usar raid 1. Si no hay forma de hacer un raid (no hay discos o el espacio es reducido), toca trabajar como me han dicho en varias ocasiones "con lo que da la tierrita". En ese caso se hacen los descargos de responsabilidades y advertencias formales pertinentes.
A titulo personal no me gusta para nada el LVM, y mas en los servidores. A otros les parece una solucion excelente sobre todo para cuando el espacio se empieza a quedar peque�o. Yo pienso que con un cuidadoso dise�o pre-montaje, dificilmente el espacio en disco definido sera superado. Me parece un desproposito (a titulo personal), porner LVM para un proxy, un firewall, un servidor de voz, un servidor web o un servidor de bases datos, pero me parece digno de analizar
100% de acuerdo :)
(sobre todo cuando no hay mucho dinero), para un servidor de correo para el cual se desconoce cuantos buzones va a soportar (algo que muy rara vez ocurre) y sobre todo para un servidor de archivos compartidos. De nuevo esto depende de los gustos y de las experiencias de quien monta el servidor. Mi objetivo siempre es el KIS (Keep It Simple) y el LVM en mi opinion agrega una capa mas de complejidad al asunto y por ende debe evitarse.
En nuestros clientes, no hay más remedio que usar gestores de volúmenes debido al tamaño de los filesystems que usan. Es imposible y poco recomendable crear LUNs excesivamente grandes y no hay más remedio que echar mano de un gestor de volúmenes.
En cuanto a particiones y tipos de FS, es importante tener en cuenta en cuenta lo siguiente:
a) En la mayoria de las ocasiones la eficiencia del fs en cuanto al I/O rara vez representa un valor significativo en el desempe�o del servidor. En entornos especificos como la virtualizacion, las BD de alto volumen de transaciones o los servidores que manejan cientos de miles de archivos o se dedican a la multimedia, esto es realmente relevante. Se busca en este caso fs optimos para estos entornos con tunings muy especificos y ante todo se busca tener hardware de alto rendimiento. En otras palabras los servidores para estos casos no cuestan US$1000.
b) Crear multiples particiones tiene un doble objetivo: robustecer la seguridad del servidor por medio de opciones de montaje especificas para distintas ubicaciones en la jerarquia de archivos (no esta de mas leerse el FHS), y de otro lado reducir el impacto que el da�o fisico de los discos produce sobre la informacion o la misma corrupcion del FS. En esto ultimo cabe decir que es mas facil recuperar la informacion de una particion de 20GB que de una particion de 200GB y ni hablar de recuperar la info en un servidor despues de una falla electrica.
Con todo esto en mente, recomendaria lo siguiente:
1) FS para servidores linux de proposito general de uso bajo a medio: ext3 o reiserfs (este ultimo en caso de tener que manejar cientos de miles de archivos peque�os)
2) Distribucion de las particiones:
------- particiones de 'proposito general' -------------------- / 2-4GB /tmp 1-2 GB (mas si es un servidor de correo) swap segun se recomiende para la ram disponible /usr 5 GB /var 15GB minimo /var/log 10GB minimo /var/tmp 1GB /var/lock 256MB -------- a partir de aqui todo depende del uso del servidor ------ /var/lib depende del uso del servidor /var/spool depende del uso del servidor /srv � /var/www depende del uso del servidor /home depende del uso del servidor [...] y la cosa sigue
en /var/lib se guardan los archivos de mysql y postgresql asi que si el servidor es un servidor de BD de uno o dos de estos motores se debe asignar el espacio necesario
/srv es la nueva ubicacion de los achivos de ftp y http (antes era /var/ftp [creo] y /var/www) asi que si el servidor va a ser de este tipo ...
/var/spool es usado bastante en servidores correo y voz.
En cuanto a las opciones de montaje:
/ defaults /tmp defaults,nodev,nosuid,noexec /usr defaults,nodev /usr/local defaults,nodev /var defaults,nodev /var/lib defaults,nodev /var/lock defaults,nodev,nosuid,noexec /var/log defaults,nodev,nosuid,noexec /var/tmp defaults,nodev,nosuid,noexec /backup defaults,nodev,nosuid,noexec /dev/shm defaults,nodev,nosuid,noexec
Para finalizar y no extendrer mucho el asunto cabe anotar que algunos FS son mas resistentes que otros a los apagados incorrectos o muerte subita del servidor. Aun asi, por mas resistente que sea el fs, nunca esta de mas tener los backups del caso, preferiblemente fuera del servidor. Sobre las opciones de montaje puedes dar una leida al "Securing Debian Manual".
Hasta la proxima.
Carlos A. Martinez
Sólo añadir un detalle, ya que Carlos ha comentado la variedad de particiones. Si dispones de dinero y montas un almacenamiento externo (cabina de discos), es recomendable que las diversas particiones tengan su propio LUN, por ejemplo, imagínate que tienes (entre otros): /home /var/lib Yo pondría /home en su propio LUN RAID 5/6/10/50/60 y /var/lib en su LUN RAID 10, por ejemplo. Esto evita que dos tipos de acceso diferentes interfieran el uno con el otro. En el caso de /home, lo más seguro es que sean acceso secuenciales y busques ancho de banda. En el segundo caso, tienes muchos accesos aleatorios y mucho IOPS. Si tienes ambas particiones en el mismo disco o LUN, el comportamiento de uno interferírá en el otro y el rendimiento caerá. HTH Rafa
2009/12/1 aux
: Hola, que recomendaci�n o que ten�is en cuenta a la hora de particionar un servidor? A parte del tama�o en si de cada partici�n tambi�n es interesante saber tipo de FS, si usais LVM o no, particiones primarias o extendidas, y en el caso de ser virtual con vmware si asignais pocos discos grandes... muchos peque�os... tama�o de cada disco etc. Pensando siempre en la seguridad y en el caso de que haya problemas en alg�n disco afecte al menor numero de usuarios, sin olvidar herramientas de recuperaci�n ante desastres
gracias -- Para dar de baja la suscripción, mande un mensaje a: � opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: � opensuse-es+help@opensuse.org
-- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org Happily using KDE 4.3.3 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-12-02 a las 09:12 +0100, Rafa Grimán escribió:
On Tuesday 01 December 2009 19:14:30 Carlos Martinez wrote:
En terminos generales usar RAID por hardware es lo mas recomendado en arreglos 1, 5, 10, 50, 60
Me alegra saber que hay otro que piensa como yo ;)
Nada que objetar, siempre que sea verdadero hardware raid, no ese engendro que traen las placas. Para eso, mucho mejor el software raid. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAksW2dIACgkQtTMYHG2NR9UpnwCfa7X5tt7UTs1PyN+MfdubaVgu DVkAoJSNGHnwoxpypxMfi014mLWk1DS1 =dxD1 -----END PGP SIGNATURE-----
participants (5)
-
aux
-
carlopmart
-
Carlos E. R.
-
Carlos Martinez
-
Rafa Grimán