Error al ejecutar GSEC

5 comentarios

Como seguramente sabes, el programa GSEC.EXE se utiliza para agregar usuarios, cambiar datos de los usuarios, eliminar usuarios y ver cuales son los usuarios admitidos.

Pero si tienes más de una instancia del Firebird instalada entonces a veces podrías ver una pantalla de error similar a la siguiente:

GSEC1

Captura 1. Si haces clic en la imagen la verás más grande

¿Qué significa ese error número 335545106?

Que no puede abrir la Base de Datos en la cual se guardan los nombres y las contraseñas de los usuarios.

En Firebird 2.x el nombre de esa Base de Datos es SECURITY2.FDB y la encontrarás en la misma carpeta donde instalaste al Firebird.

¿Cómo se soluciona ese error?

Si tienes más de una instancia del Firebird instalada entonces cada instancia usa su propio puerto (o así debería ser si se instaló correctamente). Por lo tanto la solución es indicarle que abra el archivo SECURITY2.FDB que corresponde a la instancia que estemos usando en ese momento.

GSEC2

Captura 2. Si haces clic en la imagen la verás más grande

Como puedes ver en la Captura 2. se indico la IP de la computadora y el puerto 3050. Como ese es el puerto que le corresponde a la instancia del Firebird que nos interesa, funcionó perfectamente.

Después de la opción -database se escribió la ruta completa entre comillas porque hay un espacio en blanco en el medio, y en esos casos el Windows exige que se usen comillas.

Artículos relacionados:

El índice del blog Firebird21

El foro del blog Firebird21

Anuncios

Firebird 3: usando bases de datos anteriores

6 comentarios

Ok, ya hemos instalado a Firebird 3, ahora queremos empezar a utilizarlo. ¿Cómo lo hacemos?

Lo más probable es que tengamos bases de datos creadas con versiones anteriores de Firebird. Entonces hay que convertir esas bases de datos al formato que usa Firebird 3.

El Firebird utiliza un número interno llamado ODS (On Disk Structure) para saber con cual versión de Firebird fue creada una Base de Datos. Cada versión del Firebird tiene un número único de ODS. Esos números son:

FIREBIRD3_15

Captura 1. Si haces clic en la imagen la verás más grande

Si no coincide la ODS de una Base de Datos con la versión del Servidor del Firebird entonces no podremos conectarnos a esa Base de Datos.

¿Cómo cambiamos la ODS de una Base de Datos?

Mediante un ciclo backup/restore. Hacemos el backup con la versión actual y el restore con la nueva versión.

IMPORTANTE: Esto solamente funciona en una dirección: de una ODS menor a una ODS mayor.

Ejemplo: Usar una Base de Datos creada con Firebird 2.5 en Firebird 3

firebird3_16

Captura 2. Si haces clic en la imagen la verás más grande

Como podemos ver en la Captura 2. la conexión falló porque la ODS de la Base de Datos es 11.2 y la ODS que reconoce el Servidor del Firebird es 12.0

Entonces lo que debemos hacer es convertir la ODS de esa Base de Datos a 12.0, para que pueda ser reconocida. Para ello necesitaremos realizar un ciclo backup/restore.

FIREBIRD3_17

Captura 3. Si haces clic en la imagen la verás más grande

En la Captura 3. hicimos el backup con la versión 2.5 del Firebird ¿cómo sabemos eso? Por dos pistas: a) la carpeta donde se encuentra el programa GBAK.EXE y b) el puerto que usamos para conectarnos a la Base de Datos. En nuestros ejemplos usamos el puerto 3050 para Firebird 2.5 y el puerto 3053 para Firebird 3.

Ahora que ya tenemos el backup realizado el siguiente paso es restaurarlo. Para ello, nos ubicamos en la carpeta donde instalamos al Firebird 3 y escribimos:

FIREBIRD3_18

Captura 4. Si haces clic en la imagen la verás más grande

Cuando la restauración finalice tendremos una nueva Base de Datos, de nombre PRUEBA1-3.FDB y cuya ODS será 12.0 y por lo tanto nos podremos conectar a ella usando Firebird 3.

FIREBIRD3_19

Captura 5. Si haces clic en la imagen la verás más grande

Como podemos ver en la Captura 5. no fue necesario especificar el puerto 3053 ¿por qué no? porque para la conexión usamos el programa ISQL.EXE que se instala junto con el Firebird 3. Sin embargo, en otros casos sí necesitaremos especificar dicho puerto:

FIREBIRD3_20

Captura 6. Si haces clic en la imagen la verás más grande

En el string de conexión que vemos en la Captura 6. indicamos la dirección IP de la computadora donde se encuentra la Base de Datos y también el puerto de esa computadora que usa el Servidor del Firebird 3.

Como siempre, hay que indicar además el path completo a la Base de Datos (ese path es desde el punto de vista del Servidor), el nombre de un usuario, y la contraseña de ese usuario.

Conclusión:

Para que en Firebird 3 podamos usar una Base de Datos creada con una versión anterior del Firebird debemos hacer un ciclo backup/restore. El backup lo hacemos con la versión anterior del Firebird y el restore lo hacemos con Firebird 3.

Para conectarnos a la Base de Datos restaurada a veces será necesario especificar el puerto que utiliza el Firebird 3.

Artículos relacionados:

Instalando Firebird 3 (1)

Instalando Firebird 3 (2)

El índice del blog Firebird21

El foro del blog Firebird21

Agregando el usuario SYSDBA en Firebird 3

8 comentarios

En las versiones anteriores de Firebird, ya por defecto en el archivo de seguridad (SECURITY.FDB en 1.x y SECURITY2.FDB en 2.x) existía un usuario llamado SYSDBA y con la contraseña masterkey.

Bien, ese ya no es el caso con Firebird 3, ahora ningún usuario predeterminado existe, ni siquiera SYSDBA. Por lo tanto, nosotros debemos crearlos.

Siempre el usuario SYSDBA tendrá acceso al 100% de las bases de datos, pero como no existe un usuario SYSDBA nosotros lo crearemos. ¿Cuál es la ventaja de esto? Que SYSDBA ya no tendrá por defecto la contraseña masterkey sino la contraseña que a nosotros se nos ocurra asignarle.

Con las versiones 1.x y 2.x si un intruso quería conocer el contenido de una Base de Datos lo tenía muy fácil:

  1. Copiaba o hacía un backup de la Base de Datos
  2. Copiaba o restauraba esa Base de Datos en otra computadora, en una donde conociera la contraseña del usuario SYSDBA.
  3. Listo

Ahora, con Firebird 3 algo así ya no le será posible. ¿Por qué no? Porque si copia o restaura la Base de Datos en otra computadora tendrá un gran problema ¿cuál es la contraseña del usuario SYSDBA que se necesita para conectarse a la Base de Datos? Desde luego que no será masterkey (salvo que el Administrador sea un verdadero bobo) y si no conoce esa contraseña no conseguirá el acceso. Claro, puede copiar también el archivo de seguridad (SECURITY3.FDB por defecto) pero estará en la misma: si no conoce la contraseña no conseguirá la conexión. Y además, en un entorno donde la seguridad sea muy importante el archivo de seguridad no será SECURITY3.FDB sino otro archivo con totalmente otra estructura y ubicado donde se haya especificado en DATABASES.CONF (quizás en otra carpeta de otro disco duro de otra computadora).

En síntesis, la tarea del intruso ahora será mucho más dificultosa. No imposible, porque en Informática la seguridad al 100% es imposible de conseguir, pero sí muchísimo más dificultosa que en las versiones anteriores del Firebird.

¿Cómo agrego al usuario SYSDBA?

Recuerda que al instalar Firebird 3 ningún usuario existe, ni siquiera SYSDBA, entonces ¿cómo hacemos para agregar al usuario SYSDBA y con la contraseña que se nos ocurra asignarle?

Mediante el siguiente comando:


GSEC -add SYSDBA -pw Secreto -user SYSDBA

El programa GSEC.EXE lo encontrarás en la misma carpeta donde instalaste el Firebird 3.

Y la contraseña que elijas no será Secreto, ese es solamente un ejemplo.

Conclusión:

Para hacerle la vida muchísimo más difícil a los intrusos ahora en Firebird 3 el usuario SYSDBA no existe por defecto sino que debemos crearlo nosotros. Así mismo tampoco tiene una contraseña por defecto, su contraseña inicial será la que le asignemos al crearlo, la muy famosa masterkey ya no existe (salvo que alguien sea muy bobo como para asignársela al usuario SYSDBA).

Para agregar al usuario SYSDBA y asignarle su contraseña inicial (la cual no debería ser masterkey) usamos el programa GSEC.EXE que se encuentra en la misma carpeta donde instalamos al Firebird 3.

Artículos relacionados:

¿Por qué Firebird 3?

Los archivos de configuración del Firebird 3

Entendiendo a los plug-in del Firebird 3

Parametrizando el archivo DATABASES.CONF

El índice del blog Firebird21

El foro del blog Firebird21

Evitando que un usuario se conecte más de una vez (método mejorado)

10 comentarios

En este artículo ya habíamos visto un método para evitar que los usuarios se conecten más de una vez a la Base de Datos:

Evitando que un usuario se conecte más de una vez a la Base de Datos

pero allí podríamos tener un pequeño problema si la computadora donde se encuentra el Servidor del Firebird se apaga incorrectamente, dejando por lo tanto nombres de usuarios en la tabla CONECTADOS. Esos usuarios evidentemente cuando se reinicia el Servidor no estarán conectados pero en la tabla CONECTADOS dirá que sí lo están. Una solución sería que un usuario quien no estaba conectado borre todas las filas de esos usuarios en la tabla CONECTADOS. Funcionará bien, pero, hmmmmmmm, no es profesional, ¿verdad?

Aquí hay otro método para borrar a esos usuarios “fantasmas”. Son “fantasmas” porque la tabla CONECTADOS nos indica que están conectados a la Base de Datos pero la realidad es que no lo están.

Lo que haremos será agregarle una columna a la tabla CONECTADOS y en esa columna guardaremos el identificador de la conexión. Luego, en nuestro trigger antes de intentar la inserción borraremos a todos los usuarios cuyos identificadores de conexión no se encuentren en la tabla CONECTADOS y también en la tabla MON$ATTACHMENTS.

En la tabla del sistema MON$ATTACHMENTS se guardan los datos de todas y cada una de las conexiones actuales. Uno de esos datos es el identificador de la conexión.

Entonces, la estructura de nuestra tabla CONECTADOS ahora sería la siguiente:

CONECTADOS1

Captura 1. Si haces clic en la imagen la verás más grande

Como puedes ver en la Captura 1. a la tabla CONECTADOS se le agregó la columna CON_IDECON, para guardar en esa columna el identificador de la conexión (ese identificador lo encontraremos en la tabla MON$ATTACHMENTS y para la conexión actual siempre será igual a CURRENT_CONNECTION).

El trigger para insertar un usuario a la tabla CONECTADOS

Nuestro trigger ahora cambiará un poco, quedará así:

Listado 1.

CREATE TRIGGER INSERTAR_CONECTADO
   ACTIVE ON CONNECT
   POSITION 2
AS
BEGIN

   -- Primero, se borran las filas de los usuarios que no están conectados
   -- pero aparecen como conectados

   DELETE FROM
      CONECTADOS
   WHERE
      CON_IDECON NOT IN (SELECT MON$ATTACHMENT_ID FROM MON$ATTACHMENTS);

   -- Segundo, se trata de insertar una fila a la tabla CONECTADOS.
   -- Como la tabla CONECTADOS tiene una restricción UNIQUE KEY, un usuario
   -- no se podrá conectar más de una vez al mismo tiempo

   INSERT INTO CONECTADOS
              (CON_IDENTI, CON_IDECON , CON_NOMBRE , CON_TIMEST)
       VALUES (0 , CURRENT_CONNECTION, CURRENT_USER, CURRENT_TIMESTAMP);

END;

¿Qué hace este trigger?

Primero, borrará todas las filas de la tabla CONECTADOS cuyo valor de CON_IDECON no coincida con algún valor de ATTACHMENT_ID de la tabla ATTACHMENTS. En otras palabras, en la tabla CONECTADOS quedarán solamente los nombres de los usuarios que efectivamente están conectados a la Base de Datos, no tendrá filas “fantasmas”.

Segundo, intentará insertar una fila a la tabla CONECTADOS. Si el nombre del usuario que intenta la conexión no existe en esa tabla entonces podrá continuar pero si existe entonces ocurrirá una excepción y se evitará la conexión.

El trigger para borrar un usuario de la tabla CONECTADOS

Este trigger quedará exactamente igual al que habíamos visto en el artículo anterior, no tiene por qué cambiar.

Listado 2.

CREATE TRIGGER BORRAR_CONECTADO
   ACTIVE ON DISCONNECT
   POSITION 3
AS
BEGIN

   DELETE FROM
      CONECTADOS
   WHERE
      CON_NOMBRE = CURRENT_USER;

END;

Conclusión:

Para evitar que un apagado anormal del Servidor del Firebird deje usuarios “fantasmas” en la tabla CONECTADOS podemos tener en esa tabla una columna que nos indique cual es el identificador de cada conexión. Así, antes de intentar insertar los datos de un usuario en la tabla CONECTADOS borramos las filas de esa tabla que no tengan una conexión activa. Lo que conseguiremos será que la tabla CONECTADOS siempre nos muestre los nombres de los usuarios que efectivamente se encuentran conectados.

Artículos relacionados:

Limitando la cantidad de usuarios conectados

Evitando que un usuario se conecte más de una vez a la Base de Datos

El índice del blog Firebird21

El foro del blog Firebird21

Evitando que un usuario se conecte más de una vez a la Base de Datos

14 comentarios

A veces quieres que un usuario no pueda conectarse desde más de una computadora al mismo tiempo, o desde la misma computadora más de una vez. Eso es especialmente importante en las aplicaciones de seguridad o donde se maneja dinero. Entonces, ¿cómo evitamos que lo haga?

En nuestra ayuda vienen los triggers de las bases de datos. Estos se disparan cuando alguien se conecta o se desconecta de la Base de Datos. Lo que podemos hacer es crear una tabla, la llamamos por ejemplo CONECTADOS y cada vez que alguien se conecta insertamos una fila a esta tabla, y cada vez que se desconecta borramos la fila que le corresponde.

CONECTADOS1

Captura 1. Si haces clic en la imagen la verás más grande

La columna CON_NOMBRE se encuentra en una restricción Unique Key, como podemos ver en su DDL:

ALTER TABLE CONECTADOS ADD CONSTRAINT UQ_CONECTADOS UNIQUE (CON_NOMBRE);

¿Por qué?

Porque de esa manera no tendremos que verificar nosotros que un usuario no se conecte más de una vez, el Firebird hará esa tarea por nosotros.

Si no tuviéramos esa restricción Unique Key entonces tendríamos que buscar el nombre del usuario en la tabla CONECTADOS y si existe allí entonces lanzar una excepción para evitar que se conecte. Pero al tener la restricción no es necesario que hagamos eso, ya que el mismo Firebird lanzará automáticamente la excepción. O sea, nos ahorramos trabajo.

En un trigger de la Base de Datos que se dispara cuando alguien se conecta haríamos el intento de insertar una fila en la tabla CONECTADOS, algo como:

CREATE TRIGGER INSERTAR_CONECTADO
   ACTIVE ON CONNECT
   POSITION 2
AS
BEGIN

   INSERT INTO CONECTADOS
              (CON_IDENTI, CON_NOMBRE , CON_TIMEST)
       VALUES (0 , CURRENT_USER, CURRENT_TIMESTAMP);

END;

Si el nombre del usuario no existe en la tabla CONECTADOS entonces se conectará sin problemas, pero si existe entonces el Firebird lanzará una excepción “violation of PRIMAY or UNIQUE KEY constraint …”

Y como lanzó una excepción el usuario no podrá conectarse.

No debemos olvidarnos de crear otro trigger de la Base de Datos, el que se encargará de borrar la fila que le corresponde al usuario de la tabla CONECTADOS, sería algo como:

CREATE TRIGGER BORRAR_CONECTADO
   ACTIVE ON DISCONNECT
   POSITION 3
AS
BEGIN

   DELETE FROM
      CONECTADOS
   WHERE
      CON_NOMBRE = CURRENT_USER;

END;

Entonces, cuando el usuario se desconecta la fila con su nombre será borrada de la tabla CONECTADOS.

¿Y qué ocurre si se apagó anormalmente la computadora donde se encuentra el Servidor del Firebird?

Si las cosas se hacen bien y como corresponde entonces la computadora donde se encuentra el Servidor del Firebird jamás debería apagarse intempestivamente, debería tener sí o sí una UPS en buen estado y nunca se apagaría esa computadora si hay alguien conectado a la Base de Datos.

Pero sabemos que no siempre las cosas se hacen correctamente. En ese caso los usuarios que hubieran estado conectados a la Base de Datos no podrán volver a conectarse y se requerirá que otro usuario, alguien que no estaba conectado, borre los nombres de dichos usuarios de la tabla CONECTADOS.

Luego de eso ya podrán conectarse nuevamente.

Ventaja adicional:

Este método además de evitar que un usuario se conecte más de una vez también tiene la ventaja de que siempre podremos saber quienes son TODOS los usuarios conectados.

CONECTADOS2

Captura 2. Si haces clic en la imagen la verás más grande

Como podemos ver en la Captura 2. un simple SELECT nos dirá los nombres de cada usuario conectado y también la fecha y hora de su conexión.

Conclusión:

Si queremos evitar que un usuario se conecte más de una vez a la Base de Datos y al mismo tiempo entonces podemos crear una tabla y dos triggers: uno que se disparará cuando intenta conectarse y el otro que se disparará cuando se desconecta.

De esta manera solamente podrá conectarse una vez. Tendrá que desconectarse para luego volver a conectarse.

Adicionalmente este método tiene la ventaja de que en cualquier momento podremos saber quienes son los usuarios conectados y cuando se conectaron.

Artículos relacionados:

Como evitar que se conecten a una Base de Datos

Impidiendo la conexión a una Base de Datos

El índice del blog Firebird21

El foro del blog Firebird21

Capturando excepciones del usuario

10 comentarios

Así como podemos capturar las excepciones del Firebird, las cuales tienen un número en SQLCODE o un código en GDSCODE también podemos capturar nuestras propias excepciones.

Ejemplo:

Tenemos una tabla llamada PRODUCTOS en la cual (además de otros datos) guardamos el precio de costo y el precio de venta de cada producto. Es política de la empresa que nunca el precio de venta pueda ser menor que el precio de costo aumentado en un 5%. En otras palabras, que el porcentaje de ganancia siempre debe ser 5% o más.

Esta es nuestra tabla PRODUCTOS:

CAPTURA1

Captura 1. Si haces clic en la imagen la verás más grande

Y esta es la tabla ERRORES, donde registramos todos los errores que vamos encontrando:

CAPTURA2

Captura 2. Si haces clic en la imagen la verás más grande

Esta es una excepción, que será lanzada cuando el precio de venta sea menor que el precio de costo aumentado en un 5%

CREATE EXCEPTION E_PORCENTAJE_MENOR_5 'El porcentaje de ganancia es menos que el 5%.';

Y este es un trigger de la tabla PRODUCTOS donde validamos que los precios de venta siempre sean al menos un 5% superiores al precio de costo. Y cuando no ocurre eso, insertamos una fila en la tabla ERRORES.

CREATE TRIGGER PRODUCTOS_BIU FOR PRODUCTOS
       ACTIVE BEFORE INSERT OR UPDATE
       POSITION 1
AS
BEGIN

   IF (NEW.PRD_PREVTA * 100 / NEW.PRD_PRECTO - 100 < 5) THEN
      EXCEPTION E_PORCENTAJE_MENOR_5
      'El porcentaje de ganancia es menor que el 5%. Producto = ' || NEW.PRD_NOMBRE ;

   WHEN EXCEPTION E_PORCENTAJE_MENOR_5 DO
      IN AUTONOMOUS TRANSACTION DO
         INSERT INTO ERRORES
               (ERR_MODULO, ERR_COMENT)
        VALUES ('PRODUCTOS_BIU' , 'El % de ganancia del producto *' || TRIM(NEW.PRD_NOMBRE) || '* es menor que 5%') ;

END

Fíjate que se sobreescribe el mensaje de la excepción y usamos un nuevo mensaje, personalizado, para indicar el nombre del producto que tuvo el problema. Desde luego que no es obligatorio sobreescribir el mensaje de la excepción, podríamos haber usado el mensaje por defecto, pero al sobreescribirlo tenemos más información. También cuando atrapamos la excepción indicamos el nombre del producto problemático para que al revisar la tabla ERRORES sea fácil saber cual fue ese producto.

Si ahora escribimos:

INSERT INTO PRODUCTOS (PRD_IDENTI, PRD_NOMBRE, PRD_PRECTO, PRD_PREVTA)
VALUES (0, 'COCA COLA 1 LITRO', 45, 60)

estará todo bien, ningún problema porque el porcentaje de ganancia es mayor que el 5% (es del 33%)

Sin embargo, si escribimos:

INSERT INTO PRODUCTOS (PRD_IDENTI, PRD_NOMBRE, PRD_PRECTO, PRD_PREVTA)
VALUES (0, 'FANTA NARANJA 1 LITRO', 45, 46)

no se insertará el producto ‘FANTA NARANJA 1 LITRO’ en la tabla PRODUCTOS. ¿Por qué no? porque ocurrió una excepción, (el porcentaje de ganancia es menor que el 5%) y cuando ocurre una excepción todo lo que se había hecho hasta ese momento se desecha. Por lo tanto el INSERT a la tabla PRODUCTOS es desechado. Pero el INSERT a la tabla ERRORES sí funciona, porque ese INSERT estaba dentro de una IN AUTONOMOUS TRANSACTION y por lo tanto se guarda sí o sí.

Si ahora revisamos el contenido de la tabla ERRORES veremos esto:

CAPTURA3

Captura 3. Si haces clic en la imagen la verás más grande

Y hemos conseguido lo que buscábamos: que cuando ocurra una excepción del usuario la capturemos.

Conclusión:

Así como podemos capturar las excepciones del Firebird (las que usan SQLCODE y GDSCODE) también podemos capturar nuestras propias excepciones. Siempre es conveniente registrar en una tabla las excepciones ocurridas para más adelante poder revisar esa tabla y descubrir que fue lo que se hizo mal.

Artículos relacionados:

Capturando excepciones

Capturando excepciones. Códigos de error predeterminados

¿Cuáles errores no se pueden atrapar?

El índice del blog Firebird21

El foro del blog Firebird21