Creación y aplicación de parches con diff y patch

Patch es una herramienta Linux que permite aplicar un parche a un determinado fichero o directorio.

Un claro ejemplo de la necesidad de emplear esta herramienta puede ser el siguiente: imaginemos que anualmente actualizamos la versión de una determinada aplicación a través del código fuente. El fichero de configuración puede cambiar ligeramente de una versión a otra, pero puede haber ciertos parámetros de configuración que siempre sean los mismos para nosotros y no nos interese modificarlos.

Lo que podemos hacer ante esta situación es generar un parche el cual posteriormente podremos utilizar para parchear las futuras actualizaciones de dicho fichero de configuración.

Vamos a ver todo esto con un sencillo ejemplo. Tenemos dos ficheros, file1 (archivo original) y file2 (archivo modificado) con el siguiente contenido:

[root@centos ~]# cat file1
Hoy es Lunes

[root@centos ~]# cat file2
Hoy es Martes

Para generar el parche ejecutaríamos el comando diff con la opción -u:

[root@centos ~]# diff -u file1 file2 > file.patch

[root@centos ~]# cat file.patch
--- file1    2010-01-21 15:14:08.000000000 +0100
+++ file2    2010-01-21 15:14:42.000000000 +0100
@@ -1 +1 @@
-Hoy es Lunes
+Hoy es Martes

Ahora vamos a suponer que tenemos un tercer fichero con el siguiente contenido:

[root@centos ~]# cat file3
Hoy es Lunes

No me gustan los Lunes

Y queremos parchearlo con el archivo que hemos creado previamente. El resultado sería el siguiente:

[root@centos ~]# patch file3 < file.patch
patching file file3

[root@centos ~]# cat file3
Hoy es Martes

No me gustan los Lunes

Por último, decir que si queremos anular un parche previamente aplicado emplearemos la opción -R.

[root@centos ~]# patch -R file3 < file.patch
patching file file3

[root@centos ~]# cat file3
Hoy es Lunes

No me gustan los Lunes

Utilizando el man pueden verse las múltiples opciones de los comandos diff y patch.

Subsistemas de seguridad en Linux

Muchas veces cuando a un administrador de sistemas le dicen que debe securizar una determinada máquina Linux, se limita a habilitar el control por aplicación (Application control), o como mucho, a levantar el firewall a través de iptables.

Los sistemas operativos pertenecientes a la familia GNU/Linux permiten configurar distintos subsistemas de protección a parte de los dos que se acaban de mencionar.


En la figura anterior se reflejan todas las capas de protección (a nivel de arquitectura operativa) que pueden llegar a atravesar los datos una vez que llegan a la máquina.

• Netfilter: framework de desarrollo disponible en el kernel de Linux el cual permite interceptar y manipular paquetes a nivel de red. Iptables emplea las funciones de Netfilter para realizar las tareas de firewall.


• SELinux context: arquitectura de seguridad integrada en el propio núcleo de Linux que controla los contextos, entornos o directorios sobre los que se ejecutan las aplicaciones.


• TCP wrappers: filtra el acceso a determinados servicios en base a distintas reglas.


• Application control: medidas de seguridad integradas y tomadas desde las propias aplicaciones que operan a nivel de usuario.


• SELinux boolean: arquitectura de seguridad integrada en el propio núcleo de Linux que controla la mayoría de las funciones permitidas en el sistema y que conllevan ciertos riesgos de seguridad.

Backups en VMware ESXi

VMware ESXi 4.0 sólo nos permite hacer un backup de la configuración del servidor (usuarios, servidores NTP, parámetros del sistema, etc.) y no de las máquinas virtuales. Esta tarea se puede realizar a través del VMware vSphere CLI:

VMware vSphere CLI> vicfg-cfgbackup --server 192.168.1.11 --username root --password xxxxxx -s ESXi20091211.backup

Únicamente tendremos que indicar la dirección IP del ESXi, la password para el usuario root y un nombre para el fichero de backup.

Para restaurar el backup de configuración, ejecutaremos la siguiente orden:

VMware vSphere CLI> vicfg-cfgbackup --server 192.168.1.11 --username root --password xxxxxx -l ESXi20091211.backup

Para hacer un backup de una máquina virtual, tenemos la opción de exportarla a través de la herramienta VMware vSphere Client. Para ello tendremos que apagarla en primer lugar y a continuación pulsar sobre File, Export, Export OVF Template. Esta opción nos permitirá guardar en nuestro disco duro local una imagen en formato OVF de la máquina virtual.

El formato OVF (Open Virtualization Format) es un estándar abierto para empaquetar y distribuir máquinas virtuales. Su principal ventaja es que el tamaño de las exportaciones suele ser bastante más pequeño que el original, ya que no empaqueta las secciones del disco duro virtual que están sin utilizar. Por contra, este proceso tiene la principal desventaja de que hay que hacerlo con la máquina virtual apagada y de forma manual.

Si tenemos acceso a la service console del ESXi, vamos a tener la posibilidad de poder realizar backups de las máquinas virtuales de manera automática y en caliente, es decir, sin apagar el sistema operativo de la máquina virtual.

La idea es la siguiente: en primer lugar habría que hacer una copia del fichero VMK de la máquina virtual. A continuación habría que hacer un snapshot, de esta forma y a partir de este momento, cualquier cambio no se escribiría en el disco virtual, sino en el snapshot. Después ya podríamos copiar el disco virtual VMDK, y por último, eliminaríamos el snapshot.

Para hacer todo esto existe un script llamado ghettoVCB.sh, el cual sigue una metodología similar a la herramienta de pago de VMware para tal fin: VCB (VMware Consolidated Backup). Este script lo depositaremos en el datastore local del ESXi y le asignaremos permisos de ejecución.

~ # chmod +x /vmfs/volumes/datastore1/ghettoVCB.sh

La razón por la que se guarda en el datastore local es debido a que cualquier fichero o directorio que creemos fuera de este espacio, será automáticamente eliminado al volver a arrancar el ESXi.

El backup que creemos a partir de la máquina virtual lo podremos almacenar en el propio datastore local o montar una unidad de almacenamiento por NFS o iSCSI. Para el presente caso de estudio vamos a emplear un datastore remoto accedido por NFS y ubicado en la máquina con dirección IP 192.168.1.100.

Para dicho datastore se tiene la opción de dejarlo montado de forma permanente a través del cliente vSphere, o bien configurar las variables del script para que monte y desmonte la unidad remota cuando la vaya a emplear. Utilizaremos la segunda opción.

A continuación vamos a editar el script y modificar el valor de alguna de sus variables.

~ # cat /vmfs/volumes/datastore1/ghettoVCB.sh
...
# Formato del backup de la VM
DISK_BACKUP_FORMAT=zeroedthick

# Número de backups que serán rotados
VM_BACKUP_ROTATION_COUNT=1

# Habilitar el backup a través de NFS
ENABLE_NON_PERSISTENT_NFS=1

# Desmontar la unidad remota cuando el backup se haya completado
UNMOUNT_NFS=1

# Dirección IP del servidor NFS
NFS_SERVER=192.168.1.100

# Directorio que exportará el servidor NFS
NFS_MOUNT=/export

# Nombre con el que se mostrará el datastore importado
NFS_LOCAL_NAME=nfs_storage_backup

# Nombre del directorio donde se almacenarán los backups
NFS_VM_BACKUP_DIR=backups
...

Si en lugar de almacenar el backup en la máquina remota a través de NFS hubiéramos empleado el propio datastore local del ESXi, tendríamos que haber definido a través de la variable VM_BACKUP_VOLUME el path donde depositar el backup.

Los distintos formatos que soporta el backup (variable DISK_BACKUP_FORMAT) son los siguientes:

• zeroedthick: éste es el tipo de disco utilizado por defecto al crear una VM en un ESXi y todo el espacio de almacenamiento es reservado previamente. Además, sus bloques son borrados (puestos a cero) la primera vez que se escribe sobre ellos.

• eagerzeroedthick: durante el momento de su creación, todo el espacio es reservado y puesto a cero. Este tipo de discos son los más seguros, ya que los bloques han sido previamente borrados de cualquier dato previo, ofreciendo además un rendimiento ligeramente superior durante la primera operación de escritura.


• thin: este tipo de disco tiene la peculiaridad de que crece bajo demanda, es decir, se puede definir un disco thin con un tamaño máximo de 100 GB, y nada más instalar el sistema operativo ocupar sólo 4 GB. Esos 4 GB serán el tamaño real del disco y podrá crecer hasta los 100 GB. El rendimiento ofrecido por este tipo de formato es muy pobre y no se recomienda para entornos de producción.


• 2gbsparse: divide un disco en varios discos de un tamaño máximo de 2 GB. Este tipo de formato no se puede utilizar directamente en un ESX/ESXi, por lo que hay que transformarlo previamente a un formato thin o thick.

Decir también que el formato seleccionado (zeroedthick) crea una imagen idéntica (bit a bit) a la de la máquina virtual. Después ya por último, crearemos un fichero con la lista de las máquinas virtuales sobre las que queramos aplicar el backup (por ejemplo y para el presente caso de estudio, dos máquinas virtuales denominadas centos01.local y centos02.local).

~ # cat /vmfs/volumes/datastore1/vms_to_backup
centos01.local
centos02.local

Para ejecutar el script lanzaremos la siguiente orden:

/vmfs/volumes/4a65032c-09446b90-9d40-00237d337b62 # ./ghettoVCB.sh -f vms_to_backup -l log_backup

Para automatizar este proceso de backups podemos añadir una tarea al cron del sistema operativo. En el siguiente ejemplo se va a configurar un backup automático que se ejecute todos los Sábados por la noche a las 02:30h.

En primer lugar vamos a definir esta tarea en el cron del usuario root:

~ # cat /var/spool/cron/crontabs/root
...
30 02 * * 6 /vmfs/volumes/datastore1/ghettoVCB.sh -f /vmfs/volumes/datastore1/vms_to_backup -l /vmfs/volumes/datastore1/log_backup

Para que los cambios tomen efecto, vamos a reiniciar el proceso crond. Para ello primero lo mataremos y luego lo volveremos a arrancar a través de busybox (binario que contiene pequeñas versiones de los comandos más básicos de Linux).

~ # kill $(cat /var/run/crond.pid)

~ # busybox crond

El problema de este método es que si en un momento dado hay que reiniciar el ESXi, el sistema operativo restaurará el cron de root por su original. Por lo tanto lo que habrá que hacer será editar el fichero /etc/rc.local y definir este proceso dentro de dicho archivo.

~ # cat /etc/rc.local
...
/bin/kill $(cat /var/run/crond.pid)
/bin/echo "30 02 * * 6 /vmfs/volumes/datastore1/ghettoVCB.sh -f /vmfs/volumes/datastore1/vms_to_backup -l /vmfs/volumes/datastore1/log_backup" >> /var/spool/cron/crontabs/root
/bin/busybox crond

Y por último, para asegurarnos que los cambios en el fichero /etc/rc.local serán guardados para futuros reinicios, ejecutaremos el siguiente comando:

~ # /sbin/auto-backup.sh

Para restaurar un backup de una VM, primero copiaremos el directorio que contiene el backup al datastore local de la máquina, bien a través de una conexión iSCSI o NFS hacia la máquina que contiene los backups, o por ejemplo subiendo dicho directorio al datastore desde el ordenador con el que nos conectemos al ESXi a través del cliente vSphere.

A continuación, ejecutaremos un Browse sobre el datastore, accederemos al directorio que contiene todos los ficheros de la VM y pincharemos con el botón derecho del ratón sobre el archivo con extensión VMK. Para restaurar la máquina ejecutaremos la orden Add to Inventory.

VMware ESXi: Acceso a la shell de root por SSH

Una de las limitaciones que trae la versión gratuita de VMware ESX (vSphere), más conocido como ESXi, es que no tiene la Service Console (acceso SSH a la shell del sistema).

Para activar este servicio hay que acceder físicamente a la máquina donde se encuentre instalado el ESXi (conectada previamente a un teclado y un monitor) y abrir un terminal pulsando la combinación de reclas Alt+F1.

Una vez tengamos abierto el terminal, escribiremos la palabra unsupported. A continuación nos saldrá la palabra "Password :", con lo que tendremos que teclear la contraseña del usuario root del ESXi. A partir de este momento tendremos una shell con la que podremos ejecutar bastantes comandos Linux (otros muchos han sido quitados), con lo que sólo nos quedará que activar el servicio SSH.

Para ello editaremos con vi el fichero /etc/inetd.conf y descomentaremos la línea "#ssh stream tcp...". Reiniciaremos a continuación el administrador de servicios, eliminaremos todos los procesos inetd y por último, volveremos a lanzar el demonio inetd.

~ # /sbin/services.sh restart

~ # kill `ps | grep inetd | cut -f2 -d" "‘

~ # inetd

Instalación de VMware ESXi

VMware ESXi es la versión gratuita del producto vSphere. Podemos descargar esta aplicación desde la web de VMware (ESXi), con el paso previo de un registro en línea.

Una vez registrados podremos descargar la ISO del ESXi, el cliente gráfico para administrarlo (VMware vSphere Client) y toda la documentación correspondiente. VMware nos proporcionará un número de serie que posteriormente utilizaremos para licenciar el producto.

Antes de realizar cualquier tipo de instalación o descarga, hay que comprobar si el hardware que vamos a utilizar es compatible con el ESXi. Para ello tendremos que consultar la guía de compatibilidades que VMware tiene para tal fin.

El proceso de instalación es muy sencillo. Únicamente habrá que aceptar el contrato con VMware. Durante la instalación se creará un sistema de archivos utilizando todo el espacio de almacenamiento de la máquina, reservándose una pequeña parte para el propio sistema operativo (ESXi).

En el espacio restante se creará una partición que será conocida como datastore1 y será éste el espacio que podrá utilizar el administrador del ESXi para construir las distintas máquinas virtuales. Posteriormente podremos añadir múltiples datastores al sistema. Decir también que el sistema de ficheros utilizado por VMware se denomina VMFS (Virtual Machine File System), el cual permite el acceso concurrente de múltiples máquinas virtuales a un mismo espacio de almacenamiento.

Una vez instalado el ESXi sobre la máquina física, nos saldrá una pantalla como la mostrada en la imagen siguiente.


Pulsando la tecla F12 podremos configurar alguna de las características básicas del ESXi, como por ejemplo el password de root, nombre de la máquina, parámetros de red, teclado, etc. Por defecto, ESXi viene configurado para recibir sus parámetros de red por DHCP. Y con la tecla F2 tendremos la posibilidad de reiniciar o apagar el sistema.

Accediendo por HTTPS a la dirección IP que tenga configurado nuestro ESXi, aparecerá una página web a través de la cual el usuario tendrá la posibilidad de descargarse el cliente vSphere (cliente gráfico para gestionar el ESXi), el vSphere Remote Command Line (línea de órdenes que permite utilizar comandos remotos para administrar el ESXi) y la documentación del producto.

Y a través del link Browse datastores in this host's inventory que se mostrará también en esta pantalla, el usuario podrá navegar por el datastore del ESXi.

Para conectarnos al ESXi con el objetivo de administrarlo, podremos emplear el cliente vSphere, accediendo la primera vez con las credenciales del usuario root. Posteriormente podremos crear más usuarios. Una vez estemos conectados al sistema, aparecerá una pantalla como la siguiente.


En la pestaña Summary pueden verse los recursos físicos (memoria, CPUs, espacio, etc.) de los que dispone el ESXi. Ésta será la pantalla principal del ESXi. La otra pestaña importante es la de Configuration, a través de la cual podremos gestionar de una forma más detallada los distintos elementos hardware y software del sistema.

Dentro de esta pestaña pulsaremos sobre la opción Licensed Features, Edit y accederemos a la pantalla de licencias del ESXi. En esta ventana introduciremos el número de serie proporcionado por VMware. Si todavía no queremos licenciar el producto, dispondremos de un total de 60 días durante los cuales tendremos a nuestra disposición todas las características del ESX (vSphere, versión de pago).

Y una vez llegados a este punto, ya estaremos en disposición de crear todas las máquinas virtuales que queramos. Para asegurarnos de que el sistema operativo que queremos virtualizar está soportado por VMware, conviene consultar el documento que VMware proporciona para tal fin.

VMware ESXi y vSphere

VMware ESXi ha sido personalmente para mí, uno de los descubrimientos del año. Este producto provee las funcionalidades necesarias para construir y administrar infraestructuras virtualizadas de una forma rápida, cómoda y sencilla, optimizando los recursos hardware y con unas penalizaciones de rendimiento mínimas.

WMware ESXi está basado en una arquitectura bare-metal (primer nivel) de 64 bits (sólo puede instalarse en máquinas de 64 bits). Esto significa que el ESXi es directamente un sistema operativo (basado en RHEL) que se instala directamente sobre el hardware, sin necesidad de instalar ningún otro sistema operativo por debajo (como ocurría con VMware Server), y permite la gestión directa de las máquinas virtuales.


Yo siempre he sido partidario de la virtualización, porque las ventajas que se obtienen son prácticamente innumerables. Destacaría las siguientes:

• Balanceo y ampliación de los recursos hardware (CPUs, memoria, espacio de disco, etc.) de las distintas máquinas virtuales según las necesidades del momento, incluso en caliente.


• Optimización de los recursos hardware: dedicar una máquina física actual (con su enorme potencia en cuanto a cómputo y memoria se refiere) a un único servicio, como por ejemplo un servidor web, es un desperdicio. Es preferible aprovechar ese hardware para crear diferentes máquinas virtuales.


• Portabilidad: se pueden mover las máquinas virtuales entre distintos equipos físicos.


• Seguridad: podemos emplear una única máquina física para montar por ejemplo un servidor web, un servidor de aplicaciones y una base de datos, o bien podemos crear dentro de esa máquina física tres máquinas virtuales en donde cada una de ellas albergue cada uno de esos servicios. Con esta última arquitectura tenemos tres servidores independientes que en caso de que alguno de ellos se vea comprometido, no tendrá por qué afectar al resto de servicios.


• Migración: de cara a la actualización del sistema operativo de una máquina virtual o de alguno de sus componentes software, siempre vamos a tener la posibilidad de hacer un snapshot previo, el cual podremos restaurar en caso de problemas.

VMware ESXi viene a ser una versión muy recortada del ESX, ahora conocido como VMware vSphere, aunque más que suficiente para muchos entornos de producción: nos permite crear y gestionar máquinas virtuales, exportarlas e importarlas, conocer su rendimiento, tomar snapshots, etc.

A continuación se describen las principales características de VMware ESXi 4.0:

• Soporte para máquinas físicas con hasta 64 CPUs (físicas), 256 CPUs virtuales y 1 TB de RAM. Cada máquina virtual puede disponer de hasta un máximo de 255 GB RAM.


• Optimización para aplicaciones críticas de negocio: bases de datos Oracle o Microsoft SQL Server, Microsoft Exchange, etc.


• Mejoras de rendimiento para el almacenamiento iSCSI.


• Soporte para multiprocesamiento simétrico (SMP, Symmetric Multi-Processing): una máquina virtual podrá utilizar múltiples procesadores físicos simultáneamente (hasta un máximo de ocho).


• VMware VMsafe: tecnología de seguridad que ayuda a proteger las cargas de trabajo virtualizadas, proporcionando para ello un conjunto de APIs de seguridad.


• VMDirectPath: mejora la eficiencia de la CPU permitiendo la posibilidad de acceder directamente al hardware para aquellos accesos frecuentes a dispositivos de I/O.


• Sistema de archivos clusterizado VMFS (Virtual Machine File System): permite el acceso concurrente de múltiples máquinas virtuales a un mismo espacio de almacenamiento.


• Redes virtuales (Virtual networking): VMware permite la creación de redes complejas entre las distintas máquinas virtuales, empleando para ellos dispositivos virtuales tales como tarjetas y switches.


• Balanceo automático de recursos en función de las necesidades de las máquinas virtuales.

En el siguiente cuadro se muestran las diferencias entre las distintas licencias de ESX/ESXi:


VMware Distributed Resource Scheduler (DRS) se encarga de agrupar todos los recursos computacionales de las distintas máquinas físicas, y a continuación asignarlos dinámicamente a las distintas máquinas virtuales. A su vez, VMware Distributed Power Management (DPM) automatiza el consumo eficiente de la energía en los clusters DRS.

Storage vMotion permite la migración en caliente de los discos de las distintas máquinas virtuales, y vMotion permite mover en caliente las máquinas virtuales entre servidores físicos (ambas técnicas sin interrupciones para los usuarios ni pérdidas de servicio).

High Availability permite levantar una máquina virtual en otra máquina física en caso de que ocurriera algún fallo hardware en la máquina física que originalmente la albergaba.

Consolidated Backup ofrece funciones de backup y restauraciones sencillas, sin necesidad de emplear agentes en las máquinas virtuales.

Update Manager es una extensión que permite mantener actualizados los servidores ESX, las VMware Tools y los servidores virtuales de Microsoft Windows y Linux.

Y por último, el Virtual Center es una aplicación que permite una gestión centralizada de todos los ESX/ESXi, así como de todas sus máquinas virtuales.

En la siguiente figura puede observarse un esquema genérico de una infraestructura vSphere. Por una parte se dispone de un sistema de almacenamiento en donde residirán las máquinas virtuales. A ese espacio de almacenamiento se podrá acceder a través de distintas tecnologías: fibra, iSCSI, NFS, etc. A su vez, esas VMs utilizarán recursos (CPUs y memoria) procedentes de las granjas de servidores, en donde en cada uno de ellos irá instalada una versión del ESX/ESXi.


Y a su vez, toda esta arquitectura será administrada de una forma centralizada a través del Virtual Center, software que deberá estar instalado en una máquina física dedicada. El usuario podrá acceder al vCenter a través del vSphere Client. Este cliente también se podrá utilizar para gestionar individualmente un ESX/ESXi concreto.

¿Qué alternativas reales se tienen a VMware ESXi?

XenServer: este producto (basado en Xen), inicialmente opensource y posteriormente adquirido por Citrix, le ocurre lo mismo que a su homólogo de VMware: mantiene una versión gratuita llamada XenServer y una versión de pago denominada Essentials for XenServer, que viene a ser lo mismo que el vSphere de VMware.

XenServer tiene muchas más funcionalidades que el ESXi, destacando principalmente la posibilidad de mover máquinas virtuales en caliente entre distintas máquinas físicas. Por contra, VMware ESXi es un producto mucho más estable, más consolidado y con un mejor rendimiento que Citrix XenServer.

En la siguiente tabla se muestran las principales diferencias entre XenServer y ESXi.


Xen hypervisor: podemos instalar el kernel de Xen en cualquier distribución Linux, y a partir de este momento levantar sobre ella las distintas máquinas virtuales que queramos. Para los "puristas", ésta sea posiblemente la opción más idónea. Yo he utilizado Xen y funciona muy bien. Su rendimiento es sustancialmente menor al ofrecido por VMware y también tiene en contra que su administración es algo más complicada al no disponer de una herramienta como el vSphere Client de VMware, como ocurre en el caso del ESXi.

KVM (Kernel based Virtual Machine): solución de virtualización creada y mantenida por Qumranet, empresa que posteriormente fue adquirida por Red Hat. Por este motivo, Red Hat a partir de su sistema operativo RHEL 5.4 optó por esta opción, relegando a Xen a un segundo plano, al cual le seguirá dando soporte durante un tiempo determinado.

La principal ventaja de KVM es que a partir del kernel 2.6.20 está integrado directamente con éste mediante el módulo kvm.ko. KVM probablemente será una opción a tener muy en cuenta en un futuro no muy lejano, pero a día de hoy su rendimiento deja mucho que desear.

Hace poco pude analizar las pruebas de un benchmark desarrollado por Phoronix, donde comparaban el rendimiento de una Ubuntu 9.10 virtualizada con KVM y sin virtualizar: KVM Virtualization Performance With Linux 2.6.31. Los resultados hablan por sí solos.

Benchmark IOzone: Sistemas de almacenamiento compartido en red (III)

Y ya para terminar los resultados de la herramienta IOzone para las pruebas de benchmarking sobre sistemas de almacenamiento compartido, vamos a emplear esta aplicación para estudiar el comportamiento del sistema ante la lectura/escritura secuencial de varios ficheros de 512 MB por múltiples procesos.

Mediante los siguientes comandos, cada uno de los procesos lanzados (desde uno hasta doce) realizará la escritura y lectura secuencial de un fichero de 512 MB a través de registros de 1024 KB.

[root@centos02 shared02]# iozone –Rc –r 1024 –s 512M –l 1 –u 50 –i 0 –i 1 –b shared02.xls

[root@centos03 shared03]# iozone –Rc –r 1024 –s 512M –l 1 –u 12 –i 0 –i 1 –b shared03.xls

Escritura secuencial de múltiples procesos






Re-Escritura secuencial de múltiples procesos






Lectura secuencial de múltiples procesos






Re-Lectura secuencial de múltiples procesos