Arquitectura de base de datos

Existen dos grandes tipos de arquitecturas en lo que refiere a un sistema de gestión de base de datos. Por un lado tenemos las arquitecturas centralizadas y por el otro las arquitecturas cliente-servidor. Este es un compendio con las características de cada una de ellas.

Arquitecturas centralizadas

El avance de las arquitecturas de sistemas de computadoras supuso también una revisión de otro tipo de arquitecturas, entre ellos la de los sistemas de gestión de base de datos (de ahora en más y por razones obvias SGBD o DBMS).

Las primeras arquitecturas eran llamadas Arquitecturas centralizadas y contaban con un macrocomputador o mainframe que proporcionaban el procesamiento principal a todas las funciones del sistema. Esto incluía programas de aplicación, interfaces de usuario, sumado a toda la funcionalidad de un SGBD.

Los usuarios accedían al sistema mediante terminales, que solamente mostraban en pantalla información. Se llamaban terminales tontas, dado que su única función era la de visualización. Todo el procesamiento se hacía de manera remota en el mainframe, que cuando concluía de procesar y se proponía desplegarle algo al usuario, debía comunicarse con ese terminal enviándole la información y los controles de pantalla. Dicha comunicación entre el computador central y los terminales “tontos” se hacía mediante algún tipo de red de computadores.

Los precios de Hardware habían descendido notoriamente, surgen las PC’s y la mayoría de los usuarios cambia los terminales que tenían por los nuevos PC’s dado que eran relativamente baratos, y generalmente se rompían poco. En un primer momento, la arquitectura de los sistemas no varió, se seguía usando un SGBD centralizado con PC’s remotas que se conectaban a una determinada máquina que era la encargada de realizar todas las funciones del SGBD.

Poco a poco los SGBD fueron evolucionando y la arquitectura centralizada comenzaba a ser una limitante en cuanto al procesamiento que el usuario exigía, lo cual llevó a las arquitecturas SGBD Cliente-Servidor.

Arquitecturas cliente-servidor

Las arquitecturas cliente-servidor se diseñan para manejar los nuevos entornos de cómputo, en los que hay muchos PC’s y estaciones de trabajo, servidores de ficheros, etc interconectados por medio de una red. Existen factores ajenos al desarrollo propio de la arquitectura, que son inherentes a la evolución de la tecnología en sí misma y que potencian el crecimiento de las arquitecturas cliente-servidor, como por ejemplo el bajo costo del hardware y las nuevas PC’s, o el desarrollo importante que tuvieron las redes de computadoras en ese último tiempo. Dado que las tareas se dividen en una arquitectura cliente-servidor, los requerimientos de los servidores bajan notoriamente respecto a lo que eran los mainframes.

La idea principal es definir servidores especializados con funciones específicas. Es decir, conectar un cierto número de estaciones de trabajo o PC’s como clientes de un servidor de ficheros que se encarga de mantener los ficheros de la máquina cliente. Por ejemplo supongamos un servidor de impresoras, que posee un conjunto n de impresoras que debe gestionar. Pone a disposición de los clientes la impresora y cuando llega una petición de impresión el servidor es quién la recibe y la despacha a la impresora que considere más adecuada. Esto es extensible a todo tipo de servidores especializados dado que los recursos del servidor están a disposición de los clientes.

Por otra parte el cliente, le proporciona al usuario las interfaces adecuadas para poder usar los servidores, así como también la potencia para el procesamiento para las aplicaciones locales.

La misma idea puede también aplicarse al software, donde puede almacenarse un determinado software en una máquina y ponerlo a disposición de los clientes.

La arquitectura cliente-servidor tiene una estructura con varios PC’s y menos mainframes, todos interconectados entre sí mediante algún tipo de red de computadoras. El cliente, provee capacidades de interfaz de usuario y procesamiento local. Si alguno de los clientes solicita cierta funcionalidad adicional, entonces la máquina cliente le conecta con un servidor que proporcione dicha funcionalidad. Un servidor es una máquina que puede proporcionar servicios ya sea de impresión, de ficheros, de acceso a una base de datos, etc.

Arquitectura cliente-servidor en un SGBD

En un comienzo las bases de datos relacionales eran arquitecturas centralizadas. Con el paso del tiempo poco a poco esa arquitectura fue transformándose en una cliente-servidor. Los primeros aspectos que pasaron del lado del cliente fueron los programas de aplicación y la interfaz de usuario. De esta manera, y debido a que SQL estableció un lenguaje estándar que dividía lógicamente el cliente del servidor, las funcionalidades de transacción y consulta permanecen del lado del servidor, a menudo llamado servidor SQL o de consulta.

En una arquitectura de este tipo, los programas de aplicación y la interfaz de usuario pueden ejecutarse en el cliente. Cuando un usuario solicita acceso al SGBD, se establece una conexión con el servidor mediante el protocolo ODBC (Open Data Base Connectivity) el cuál proporciona interfaces API para que las aplicaciones del lado del cliente puedan llamar al SGBD y comunicarse correctamente. La mayoría de los proveedores de SGBD proporcionan drivers ODBC. Java tiene otro estándar llamado JDBC, que cumple una función similar.

En los sistemas de base de datos orientados a objetos se dividen los módulos del SGBD entre cliente y servidor. De esta manera el servidor se encarga de los módulos de manejo de almacenamiento de los datos en páginas de disco, recuperación, control de concurrencia, movimiento de páginas a disco y funcionalidades similares. Por otra parte, el cliente cuenta con funciones que corresponden a los módulos de gestión de interfaz de usuario, funciones de diccionario de datos, interacción entre el compilador de un determinado lenguaje y el SGBD.

Nota final:

Si se quiere puede investigarse más sobre lo referente a las arquitecturas cliente – servidor existen más tipos que requieren conceptos adicionales como por ejemplo las arquitecturas C-S de tres niveles, o incluso las base de datos distribuídas.

*Fundamentos de sistemas de base de datos, 3a edición, R. Elmasri – S. Navathe

*Sistemas de base de datos, 5a edición, Volúmen 1, C.J.Date

Catálogo de un sistema de base de datos

Acá va un material teórico que escribí hace un tiempo en el viejo blog.
Es un breve resumen que puede servir para la facultad en materias como Base de datos.
Espero les sirva!

El catálogo de un sistema de base de datos no es más que una base de datos en sí misma a veces llamada metabase. Los contenidos de dicha base de datos son llamados metadatos. La función principal del catálogo es almacenar los esquemas de las bases de datos que el sistema mantiene. Mantiene una descripción de todos los niveles (véase arquitectura de tres esquemas o niveles) tanto del esquema interno como del externo y el conceptual.

Esencialmente se guardan objetos que puedan resultar de interés para el sistema, como por ejemplo tablas, vistas, índices, usuarios, planes de aplicación, privilegios de acceso, etc. La información contenida en el catálogo es indispensable para que el sistema se comporte de manera adecuada. El conocer los índices que existen por ejemplo, facilitaría o influiría sin dudas en la planificación de la estrategia en una determinada consulta. El subsistema de autorización, chequeará por ejemplo que cada operación que intente realizar el usuario esté permitida. De manera que también vemos que el catálogo sirve para chequear la validez de una sentencia y mantener la integridad y la coherencia de los datos.

Las consultas al catálogo pueden realizarse con las mismas sentencias que se consulta cualquier base de datos o tabla. Sin embargo las actualizaciones al catálogo (INSERT, DELETE, UPDATE) no son posibles. Pensemos un segundo que pasaría si permitiéramos aplicar estas sentencias en el catálogo. Podríamos por ejemplo, borrar una línea de la tabla syscolumns (tabla que contiene una fila por cada columna en alguna tabla del sistema). Si esto sucediera estaríamos eliminando una columna del catálogo y para el sistema esa columna no existiría más. De manera que cualquier intento por recuperar datos de esa columna fracasaría.

En contraposición a estas sentencias existen otras proposiciones de definición de datos, como son CREATE TABLE, CREATE INDEX, DROP y ALTER. Cuando hacemos un CREATE TABLE, solamente se hace un ingreso en la tabla systables(tabla que contiene todas las tablas del sistema) del catálogo, sino que también se dan ingresos en la tabla syscolumns a todas las columnas que contiene la nueva tabla a crear.

De manera similar el DROP equivale al DELETE y el ALTER al UPDATE.

*Fundamentos de sistemas de base de datos, 3a edición, R. Elmasri – S. Navathe

*Sistemas de base de datos, 5a edición, Volúmen 1, C.J.Date

Fail2Ban

Como trabajo de la materia Linux, elegimos el estudio y configuración de algún software de la vuelta. Además si éste no tenía artículo en Wikipedia español debíamos hacerlo. Así fue como dimos con fail2ban, un framework escrito en Python, que básicamente se encarga de escanear logs. El usuario puede especificarle expresiones regulares, y cuando el programa encuentra dichas expresiones regulares en los logs, toma una determinada acción. La acción puede tratarse de "bloquear" una IP, un puerto, un protocolo, etc. Puede ser extremadamente útil para evitar ataques de fuerza bruta por ejemplo. En el proyecto puntualmente levantamos un servidor web (lighttpd) y cuando un usuario se logueaba mal mas de 2 veces, bloqueaba la IP desde la cuál se estaba tratando de loguear por 60 segundos.
Es todo ajustable, de manera que si queremos bloquear una IP por más tiempo, basta con cambiar 60 por la cantidad de segundos que querramos y listo!

INSTALACIÓN
Simplemente sudo apt-get install fail2ban
(Conviene tener instalado Python 2.5 previamente, sino sudo apt-get install python2.5)

CONFIGURACIÓN

Para la configuración se tienen básicamente 2 archivos importantes.
/etc/fail2ban/jail.conf
/etc/fail2ban/filter.d/archivoConReglas.conf

El primer archivo es el que contiene todas las configuraciones referentes al bloqueo que se desea realizar. Se indica que puertos se han de bloquear, el archivo conteniendo las expresiones regulares que se desean buscar, el nombre del log que se desean encajar las expresiones regulares, el tiempo de bloqueo, etc.




port = puertos que bloqueara o aplicará la penalización
protocol = protocolos que bloqueara o aplicará la penalización
filter = indica el nombre del archivo que contendrá las expresiones regulares
logpath = path al archivo de log que se quiere escanear
maxretries = máxima cantidad de reintentos de fallo
También existen otros parámetros como bantime que especifica la cantidad de tiempo en segundos que se deseará bloquear la pc atacante.

El segundo es un archivo que se crea con las expresiones regulares a buscar. En nuestro caso buscaríamos expresiones que fueran del tipo:
(http_auth.c.872).*: (Donde es un alias que contiene IP, protocolo, puerto, etc). El http_auth.c.872 es el código de error para simbolizar que hubo un intento fallido de logueo.

Es un software sumamente interesante, que acepta trabajar con la mayoría de los servidores o programas importantes (Apache,QMail, Lighttpd, SSH, entre otros).
Invito a probarlo, puede llegar a ser de gran utilidad.
Saludos!

Restaurando Grub segunda vuelta

Cambia, todo cambia... Hace unos meses tuve este problema y lo solucioné como está escrito en el post Restaurando Grub. Sin embargo ahora me sucedió de nuevo, y ya no está el Ubuntu 9.04 ni el Windows 7 Release Candidate. Ahora los actores son Ubuntu 9.10 (que trae el nuevo gestor Grub 2) y el Windows 7 definitivo.
Grub 2 es bastante diferente que Grub en varios aspectos, archivos de configuración diferentes, nombre de variables también diferentes, etc.
Para restarurar grub 2 y que vuelvan a aparecer Windows 7 con Ubuntu 9.10 Karmic Koala, hay que seguir los siguientes pasos:

1. Bootear con un live cd de Ubuntu que se tenga a mano

2. Escribir en consola "sudo fdisk -l" (para listar la tabla de particiones y saber en qué partición tenemos instalado Ubuntu 9.10)

3. sudo mount /dev/sda1 /mnt (dnd sda1 es la partición en la cuál tenemos Ubuntu 9.10, en mi caso sda1)

4. sudo mount --bind /dev /mnt/dev (con este comando montamos el resto de los dispositivos)

5. sudo chroot /mnt (ejecutamos chroot para poder acceder como root a nuestro sistema de archivos)

6. grub-install --recheck /dev/sda (con este comando cargamos Grub en el MBR del sda, disco indicado. OJO! DEBE SER EL DISCO Y NO EL NÚMERO DE PARTICIÓN, SI PONES EL NÚMERO DE PARTICIÓN PROBABLEMENTE PIERDAS WINDOWS).

7. Reiniciar y cuando arranca el Ubuntu 9.10 de nuestra pc hacemos:
sudo update-grub2

Espero les sea de utilidad. Son pocos pasos y rápidos y pronto tenemos nuestro Ubuntu/Windows andando de nuevo.
Saludos!

Cambiando usuario en un script

Los otros días se nos presentó un problema que parecía trivial pero que demandó un poco mas de tiempo que el esperado. El mismo consistía en levantar una serie de aplicaciones al inicio sin inconvenientes de que las mismas fueran levantadas como root, a excepción de una. De manera que lo que se nos ocurrió fue desde el arranque hacer un script que levantara todas las aplicaciones con root y al final cambiarse de usuario con el famoso su y ejecutar los comandos con el nuevo usuario. Sin embargo, esto no funcionó. :-( Por el contrario, y luego de un ratito explorando el man y algunos foros, encontramos lo siguiente:

#!/bin/bash

su - usuario1 -c "touch /home/usuario1/ejemplo.ok"

exit 0

Ejecuta un comando con el usuario especificado. Sin misterios :-D.
Gracias a Agustin con el que remamos esto!!!