PHP code to manage errors un PostgreSQL

A few eeks ago, an old customer came back to me asking for a way to manage PostgreSQL errors in PHP, this is because he has a PHP web based system with access to a PostgreSQL database.
Now, as many other PHP web-based systems out there, the error exposure is enabled, thus, every time a query returns an error, it was printed in web page, which as you can think, is not a good thing.

Now, in order to avoid this you can easily go to the php.ini file and change the display_errors directive from On to Off and enable the error logging. But, how to catch the errors and display them in a friendly manner to customer? With this workaround, nothing will be displayed and customer won't have a clue of what's going on, oh well, yes, because its data may not be displayed.

So a little solution has been implemented with the following code:


INSERT CODE HERE


Ok, let's explain: as you should know there is a set of common error codes in SQL, and specifically, for PostgreSQL there is a well explained section of its docummentation.

As you may infer, the SQL error code 23505 (UNIQUE VIOLATION) may appear whenever a violation of a unique constrain occurs, no matter in what table it happens so, in order to create a customized message, system must be aware of who (what page) requested that operation.Is not the same thing a UNIQUE VIOLATION from the add page than from the modify page, neither if it happens in the users module or the customers module.

In order to customize errors the sqlErrorCodes.php file has been created, it contains, as an array, all the possible errors that can be

Los PANaderos no sabe de historia natural.

¿Han escuchado por ahí ese spot radial que comienza en un ambiente así como selvático? De pronto se escucha in crecendo un ruido como de pisadas y un avoz que dice algo como: "Durante más de 70 años los dinosaurios dominaron la tierra..... ", lo curioso de este spot es que en algún momento se escuchan los gritos de alguna especie de mono, yo lo asocio con un chimpancé.

Ahora, se sabe que los dinosaurios vivieron del Triásico superior (que se extiende desde 228.0 ± 2 hasta 199.6 ± 0,6 millones de años), hasta el Cretácico superior (que se extiende desde hace 99 hasta 65 millones de años atrás). Por otro lado, los primates superiores, como el chimpancé aparecieron en la tierra hace 7-8 millones de años. Ver artículo.

Por lo tanto, la publicidad de este ppartido político está MAL! Y lo trágico es que no les importó ni los que hicieron el spot, ni los que lo solicitaron.. y al parecer tampoco a los que lo transmiten.. qué tristeza..

La falacia de las propuestas del Verde

Querido lector (a veces pienso que sólo yo leo mi blog), saliendo de mi costumbre escribiré un poco sobre el tema de moda, que es el de la política, y en específico hablaré un poco de las propuestas que hace el PVEM. Estas propuestas están bastante bien publicitadas y a veces hasta me voy con la finta, pero bueno, les expondré mis comentarios, a ver qué opinan:

1. Si el gobierno no te puede dar las medicinas, que te las pague.

Bueno, suena interesante esta propuesta, pero me lleva a hacerme al menos dos preguntas.
La primera: ¿De dónde va a salir el dinero para que el gobierno pague esas medicinas? De los impuestos me imagino, o bien, de alguna deuda interna o externa. Y la segunda: ¿Y si mejor adelgazamos a los institutos de salud pública para que los recursos rindan?, u otra variante: ¿Qué tal si eliminamos burocracia / corrupción en el instituto?. Válga esta anéctota como ejemplo:

Una maiga mía está embarazada, por lo tanto debe acudir al IMSS a su seguimiento mensual, ahora, resulta que el médico general le indica que debe llevar para la siguiente consulta, que será
el 24 de julio, un ultrasonido. Va con la gente que hace ese estudio (dentro del propio IMSS), y la espuesta es que la citamás cercana para que se realice el estudio es a partir del 29 de julio, por lo tanto, la nueva indicación fue la de regresar con el médico para re agendar la cita. ¡Ah! Pero la ironía viene en que, si se "va el sistema", entónces no la gente no puede agendar sus citas, no se pueden imprimir recetas ni otras cosas. ¿Y luego? ¿No podría desde el principio nuestro amigo doctor, por medio de sus prodigioso sistema, establecer la cita de la paciente en cuestión para evitar la pérdida de tiempo y ánimos?

Pienso que si comenamos por eliminar tanto trámite y tanta burocracia dentro del instituto, quizás se logre reducir algunos costos para así tener el recurso económico suficiente como para tener más medicamento en las farmacias.

Según mi muy personalísimo punto de vista, esta propuesta es sólo una aspirina para eliminar el dolor causado por la cáries de una muela, es decir, no pienso que sea una medida que vaya a servir para arreglar los problemas de fondo.

2. Vales para que los estudiantes de secundaria estudien lenguas extranjeras y computación.

Sin ánimos de tocar temas ya trillados, nuevamente me asalta la duda, ¿Y de dónde va a salir el recurso para los ichosos vales? Por otro lado, ¿cuál piensa usted que es la causa o causas por las cuales el nivel de educación en "computación" y "lenguas extranjeras" es tan bajo?
De entrada pienso que tiene que ver con las propias instituciones educativas, siguiendo por los maestros y terminando por los alumnos, en general, por un sistema educativo que no enseña a pensar a los niños y que anima la mediocridad.

Ahora, por el lado de la enseñanza de cómputo, esta es mi área y creo que tengo algo que decir, primero ¿a qué se refiere Manual Araiza cuando se refiere a la enseñanza de cómputo?, ¿A enseñar a los niños las técnicas avanzadas de Microsoft X, Microsoft Y y Microsoft Z?, ¿Acaso la idea es enseñar a los niños a depender de la tecnología "que viene de afuera" (algo así como la crisis)?

3. La pena de muerte a secuestradores y asesinos.

Ya por ahí había escuchado que esto de la implantación de la pena de muerte en México no se podía llevar a cabo puesto que había tratados internacionales a los que el país se ha suscrito que no lo permiten y por fin me di tiempo de buscar un par de ejemplos: [la] "Convención Americana Sobre Derechos Humanos y el Pacto Interamericano de Derechos Civiles prohíben restablecer la pena capital en los países donde haya sido abolida, como es el caso de México. "

Pueden encontrar una referencia de esto en la siguiente nota de El Universal.
CONVENCION AMERICANA SOBRE DERECHOS HUMANOS
Pacto Internacional de Derechos Civiles y Políticos

Por lo tanto, cualquier tipo de debate está condenado al fracaco para los impulsores de la pena caital, en pocas palabras, nos andan bacilando con esto. Por otro lado, en el remotísimo caso de que México quisiera hacer caso omiso de los tratados, nos encontramos con el problema de la aplicación de la ley! Se imaginan nadamás el estado de caos que tendríamos?

No quisiera ni pensar en ello.

En fin, brevemente quise exponerles algunas ideas de porqué pienso que la publicidad del PVEM es básicamente la exposición de que los planes de gobierno de ellos y de los demás también, no son más que medidas para paliar los efectos de males que tienen un raíz más profunda.

Con todo y esto, el que tiene la decisión al final es usted mi querido lector.

Saludos!

Fortalecimiento básico de Linux: nologin (8/8)

El archivo nologin sirve para negar el acceso de los usuarios al sistema.

Página manual: man 8 nologin

Si existe el archivo /etc/nologin, este comando despliega el contenido al usuario en lugar del mensaje por defecto del sistema y terminará su intento por conectarse. El único usuario que podrá tener acceso al sistema es root.

Fortalecimiento básico de Linux: limits (7/8)

El archivo limits define las cotas superiores del uso de los recursos del sistema. En pocas palabras, cuánto y de qué pueden usar los usuarios.

Página manual: man 5 limits

Aquí describimos los límites que deseamos imponer a los usuarios en cuanto al uso de los recursos del sistema. Por defecto, el usuario root no tiene ningún tipo de cotas de hecho no exíste una manera de imponer límites a cuentas de usuario de tipo administrador (aquellas cuyo UID sea igual a cero).

Cada línea describe un límite para usuario de la forma:

usuario LIMITES

La cadena LIMITES se construye mediante la concatenación de límites de recursos. Cada límite consiste en una letra identificadora seguida de un límite numérico.

Los identificadores válidos son:

A: Máximo espacio de direcciones en Kb
C: Tamaño máximo de los archivos de volcado de memoria (core), en Kb.
D: Tamaño máximo de datos, en Kb.
F: Tamaño máximo de archivo, en Kb.
M: Tamaño máximo de direcciones bloqueadas en memoria (locked-in-memory), en Kb.
N: Tamaño máximo de archivos abiertos
R: Tamaño máximo de conjunto residente, en Kb.
S: Tamaño máximo del stack, en Kb.
T: Tiempo máximo del CPU (mins)
U: Número máximo de procesos
K: Máscara de creación de archivos, ver man 2 umask
L: Número máximo de logins en el sistema para el usuario.
P: Prioridad de los procesos, véase man 2 setpriority

Por ejemplo, L2D2048N5 es una cadena de límites válida. Para propósitos de facilitar la lectura, las siguientes entradas son equivalentes:

usuario L2D2048N5
usuario L2 D2048 N5

Debe tener en cuenta que cualquier cosa después del nombre del usuario se tomará como una cadena de límites y que no se permiten los comentarios. Así mismo, cualquier cadena con límites inválidos no será considerada.

La entrada por defecto se denota por el nombre de usuario ‘*’. Si se tienen varias reglas por defecto entonces se toma la última.

Por favor, note que estos limites son por login, no son globales ni permanentes.

Fortalecimiento básico de Linux: porttime (6/8)

Este archive contiene una lista de los tty’s, los nombres de usuario y sus respectivas horas a las que tienen permitido entrar al sistema.

Página manual: man 5 porttime

Cada entrada del archivo consiste en tres campos separados por dos puntos (:) en donde el primer campo es una lista de terminales virtuales (separadas por coma), el segundo campo es una lista de nombres de usuario (separados por coma). En ambos casos puede utilizarse el comodín asterisco (*), que significa “todos”. Todos los nombres de usuario o bien, todas las terminales virtuales.
El tercer campo es una lista separada por coma de las horas y días en los cuales se permite el acceso.

Cada una de estas entradas se constuye a partir de cero o más días de la semana. Su, Mo, Tu, We, Th, Fr y Sa, seguidos de un par de horas separadas por un guión. También podemos usar la abreviación Wk (weekdays, o bien, entre semana), para representar los días de lunes a viernes; lo mismo Al que significa “todos los días”. Si no se especifica ningún día de la semana, se asume que se trata de Al.

Una entrada de la forma:

*:curso01:Wk0900-1700

Significa que el usuario curso01 puede acceder al sistema por medio de cualquier Terminal virtual, en cualquier día entre semana (de lunes a viernes), de las 9:00 AM a las 5:00 PM.

En el siguiente ejemplo se permite el acceso a los usuarios root y oper desde /dev/console en cualquier momento:

console:root,oper:Al0000-2400
console:*:

En cambio, la segunda línea especifica que el resto de los usuarios no tendrán acceso al sistema en ningún momento.

Como ejemplo final:

*:curso01:Wk1700-0900,SaSu0000-2400

Se describe una entrada que especifica que el usuario curso01 puede entrar al sistema desde cualquier terminal virtual fuera de horas de oficina (en este caso desde las 5:00 PM a las 9:00AM), así como los fines de semana durante todo el día.

Fortalecimiento básico de Linux: securetty (5/8)

El archive securetty contiene una lista con las terminales virtuales desde las cuales el administrador o root, puede entrar al sistema.

Página manual: man 5 securetty

En este archivo se definen todas aquellas terminales virtuales, tanto locales como remotas a través de las cuales un administrator del sistema puede acceder al mismo.

Por ejemplo, en le caso de las terminales locales se listan de la tty1 a la tty6, es decir, el administrator puede alejar cualquiera de las 6 terminales virtuales locales para poder acceder al servidor. Supóngase que queremos que el administrador solamente se conecte por medio de la tercera terminal local virtual (tty3).

Recordemos que para acceder a alguna de las terminales virtuales locales basta teclear la combinación Alt_FX, donde X es el número de la terminal a la que queremos entrar. Para el ejemplo, a fin de acceder a la tercera terminal local virtual deberemos teclear: Alt_F3 en donde veremos un prompt parecido a este:

Welcome to Linux 2.4.33.3 (tty3)
nunki login:

Ahora, para que esto tenga efecto es necesario dejar sin comentar en el archivo la línea referente al tty3. De tal manera, el usuario administrador del sistema no se podrá firmar en el sistema más que por la terminal local mencionada.

Fortalecimiento básico de Linux: login.defs (4/8)

Este archivo define la configuración para la suite de programas que manejan los passwords del sistema, en este caso hablamos de la suite de shadow.

Página manual: man 5 login.defs

Este archivo típicamente trae entradas como las siguientes:

CHFN_AUTH yes | no Si está puesto a yes, chfn y chsh solicitarán autenticación del usuario
antes de ejeutar cualquier cambio, a menos que se ejecute como super usuario.

CHFN_RESTRICT

CREATE_HOME yes | no . Define si es que el programa useradd deberá crear el directorio hogar del usuario.

GID_MAX int / GID_MIN int. Rango de ID's para escoger para los grupos.

MAIL_DIR string. El directorio en el que se guarda la cola de correos electrónicos de salida

PASS_MAX_DAYS int. El número máximo de días en el que un password puede usarse. Una ves que esta contraseña ha expirado, se forzará a que el usuario lo cambie.

PASS_MIN_DAYS int. El número mínimo de días permitidos entre cambios de contraseña. Cualquier intento de cambiar el password antes de este número de días será rechazado.

PASS_WARN_AGE int. El número de días antes de que el password expire, el sistema mostrará un mensaje de advertencia.

Debe hacerse notar que PASS_MIN_DAYS, PASS_MAX_DAYS y PASS_WARN_AGE sólo tendrán efecto durante la creación de cuentas de usuario. Cualquier cambio posterior no afectará a los usuarios previamente creados.

UID_MAX int / UID_MIN int. Rango de ID's para escoger para los usuarios.

UMASK int. La máscara de permisos. Si no se especifica, el permiso será 077.

FAIL_DELAY int. El retardo en aparecer el prompt de login después de algún fallo.

DIAPLUS_CHECK_ENAB yes|no. Permitir contraseñas adicionales sobre las líneas de dialup.

FAILLOG_ENAB yes|no. Permitir que las fallas al accesar al sistemase guarden en la bitácora /var/log/faillog

LOCK_UNFAIL_ENAB yes|no. Permitir que se guarden en la bitácora los nombres de usuarios no conocidos cuando se genere un fallo .

LOG_OK_LOGINS yes|no. Permitir que se guarde en las biácoras los nombres de usuarios cuando no hay error.

LASTLOG_ENAB yes|no. Permite que se guarde la hora de entrada al sistema en la bitácora /var/log/lastlog

MAIL_CHECK_ENAB yes|no. Permite que se revise el malbox del usuario cuando éste, entre al sistema

OBSCURE_CHECKS_ENAB yes|no. Permite que se realicen otros chequeos sobre cambios de la contraseña

PORTTIME_CHECKS_ENAB yes|no. Permite que se revisen restricciones establecidas en /etc/porttime

QUOTAS_ENAB yes|no. Permite que se programen ulimit, umask y niceness en el campo gecos del archivo /etc/passwd.

SYSLOG_SU_ENAB yes|no. Habilita el monitoreo y registro en bitácoras de la actividad de su.

SYSLOG_SG_ENAB yes|no. Permite el monitoreo de los comandos newgrp y sg.

CONSOLE string. Define desde qué terminales se puede logear el usuario root. Puede ser la ruta de un archivo que contenga la lista de estos dispositivos o bien, los dispositivos separados por dos puntos (:).

SULOG_FILE string. Toda la actividad del comando su será guardada en este archivo de bitácora.

MOTD_FILE string. Si se define, se mostrará el o los archivos de message of the day. Se usan do spuntos (:) como separador de archivos.

ISSUE_FILE string. Si se define, este archivo será impreso en la pantalla, justo antes de cada intento de acceso al sistema.

TTYPE_FILE string. Si se define, en este archivo se hará el mapeo de cada línea tty hacia un tipo de terminal. Cada línea de este archivo puede tener un formato como "vt100 tty01"

FTMP_FILE /var/log/btmp Si se define, todos los accesos al sistema fallidos serán registrados aquí en un formato utmp.

NOLOGINS_FILE /etc/nologin

SU_NAME su

Fortalecimiento básico de Linux: /etc/fstab (3/8)

El fstab o tabla de sistemas de archivos (file systems table), controla la manera en la que son tratados los sistemas de archivos, las opciones con las que se montan, el orden y la frecuencia con la que se revisan.

Página manual: man 5 fstab

Un archivo fstab se compone típicamente de 6 columnas de datos, mediante las cuales se definen los sistemas de archivos de una máquina Linux.
En una máquina personal, este archivo suele tener entradas como estas:

/dev/sda2    swap        swap    defaults        0    0
/dev/sda3    /           ext3    defaults        1    1
/dev/sda1    /root       ext3    defaults        1    2
/dev/cdrom   /mnt/cdrom  auto    noauto,owner,ro 0    0
/dev/fd0     /mnt/floppy auto    noaout,owner    0    0
devpts       /dev/pts    devpts  gid=5,mode=620  0    0
proc         /proc       proc    defaults        0    0

La primera columna indica la partición, la segunda es el punto de montaje, la tercera es el sistema de archivos, la cuarta son las opciones con las que se monta (véase también man 8 mount para una lista completa de las opciones de montaje), la quinta columna indica si el sistema de archivos debe ser revisado por el fsck y la última indica el orden en que debe hacerse esta revisión.

Ahora, en el caso de un servidor generalmente se recomienda tener más particiones, por lo que un esquema recomendable podría ser:

/dev/sda2    swap         swap    defaults                 0    0
/dev/sda3    /            ext3    defaults                 1    1
/dev/sda1    /root        ext3    defaults                 1    2
/dev/sda4    /boot        ext3    ro,nosuid,noexec,nouser  1    3
/dev/sda5    /tmp         ext3    nosuid,noexec,nouser     1    4
/dev/sda6    /var/log     ext3    nosuid,noexec,nouser     1    5
/dev/sda7    /usr/local   ext3    defaults                 1    6
/dev/sda8    /home        ext3    defaults                 0    0
/dev/cdrom   /mnt/cdrom   auto    noauto,owner,ro          0    0
/dev/fd0     /mnt/floppy  auto    noaout,owner             0    0
devpts       /dev/pts     devpts  gid=5,mode=620           0    0
proc         /proc        proc    defaults                 0    0

Las razones para poner tantas particiones son varias:

1. Según la definición de la LFH, los directorios que se encuentran definidos aquí como particiones (o al menos la mayoría), no son necesarios para la inicialización de un sistema y por lo tanto pueden quedar como particiones independientes.

2. En un sentido más práctico, /root es en donde el administrador puede guardar todos sus archivos sin inundar el resto de la /. Lo mismo sucede con /home. /boot es en donde se guardan todos los archivos necesarios para el proceso de arranque del sistema, entre otras cosas, guarda la imagen del kernel, si bien aún existen dudas sobre si es sabio o no ponerlo como partición independiente, en este esquema se presenta así a fin de ponerle otorgar permisos de sólo lectura (ro), no ejecución de binairios suid (nosuid), no ejecución de programas (noexec), no manipulación de usuarios (nouser). Ya que nadie realmente más que el administrador debería modificar las imágenes del kernel.
Algo similar se aplica para /tmp, pues es esta partición en la que todos los usuarios pueden escribir, lo cual se torna potencialmente peligroso ya que aquí se pueden subir ciertos programas maliciosos mediante los cuales lanzar ataques internos al servidor. Por otro lado, se podría intentar una saturación del espacio libre desde esta partición.

En /var/log se guardan las bitácoras del sistema y no es buena idea que cualquiera puede ejecutar cosas en él. /usr/local es en donde generalmente (al menos en el caso de Slackware) se instalan los servidores de web /usr/local/apache, bases de datos (/usr/local/mysql y /usr/local/pgsql) y en general el software opcional.

En general, cada administrador puede crear el esquema de particionamiento que mejor le acomode, dependiendo sobre todo del propósito que va a tener el sistema que va a instalar.

Fortalecimiento básico de Linux: inittab (2/8)

En el post anterior, describía cómo hacer para evitar que se le pasaran parámetros no deseados a la imagen del kernel. Pero vamos, ¿para qué arriesgarnos siquiera a que nos reinicien la máquina?

2. El SO lo reinician sólo aquellos con privilegios suficientes.

El archivo /etc/inittab describe qué procesos se inician durante la inicialización del sistema y la operación normal. Es aquí en donde se distinguen múltiples run levels (niveles de ejecución), cada uno de los que pueden tener sus propios conjuntos de procesos para ser iniciados.
Otra de las cracterísticas de /etc/inittab, es que describe cómo ha de responder el sistema ante la llamada Ctrl+Alt+Del, que asociamos comunmente con la solicitud de reinicio del sistema.

Página manual: man 5 inittab

A fin de modificar este comportamiento, hay que buscar una línea parecida a:

ca:ctrlaltdel:/sbin/shutdown –t5 –r now

En la que se especifica cómo responderá el sistema al recibir la combinación de teclas Ctrl+Alt+Del.

Al final de esta línea se observa el comando que se ejecutará al recibir esta señal. La idea aquí es modificar las opciones del comando shutdown, el cual tiene un modificador (-a), que indica al sistema que deberá buscar en el archivo /etc/shutdown.allow la lista de usuarios con privilegios de reiniciar el sistema mediante esta combinación de teclas (véase man 8 shutdown).

Hay que modificar esta línea para que quede así:

ca:ctrlaltdel:/sbin/shutdown –t5 –a –r now

Después, es necesrio crear el archivo /etc/shutdown.allow, escribiendo el nombre de usuario de aquellos privilegiados, típicamente sólo se le permitirá al root. De tal forma, nadie más podrá reiniciar el sistema con este método.

Inclusive, al no estar logueados al sistema, es posible ejecutar Ctrl+Alt+Del y obtener la respuesta deseada. Esto queda deshabilitado al implementar la medida anterior.

Fortalecimiento básico de Linux: LILO (1/8)

Desde hace ya algún tiempo está demoda aquello de que hay que fortalecer los sistemas a fin de hacerlos inmunes a ataques que pudieran comprometer la seguridad del sistema. En la mayoría de las veces los aministradores de sistemas de preocupan por poner firewalls, honeypots, jaulas, IDSs y cuanta cosa encontramos, olvidando que un número muy alto de los ataques provienen del interior de los sistemas. Es decir, de los usuarios, ya sea que simplemente estén probando cosas, pasando por los que tiene una idea más clara de lo que hacen, hasta aquella cuenta que ha sido robada y es usada por un profesional.

Es por ello que se me ocurrió escribir una pequeña receta para aquellos administradores de Linux que que tienen usuarios que accesen al shell.

1. Que no te reinicien la máquina.

En muchos casos, se sigue utlizando LILO como gestor de arranque de los sistemas Linux, es por ello que es importante mantenerlo seguro. De lo contrario, alguien se puede introducir a la sala de servidores y hacer travesuras con el SO.

El archivo /etc/lilo.conf es el archivo de configuración del LInux Loader (Cargador de Linux), de ahí su nombre (LILO).

Página manual: man 5 lilo.conf

Para asegurar que se teclee un password cuando se quiera arrancar un kernel, es necesario usar el keyword:

password=


Si se agrega esta opción es necesario hacer que el archivo sea de lectura sólo por el root.

Esto se logra con un:

> chmod 600 /etc/lilo.conf

Por otro lado, la opción

restricted

indica que se requerirá de un password durante el proceso de inicio del sistema si es que se especifica algún parámetro del kernel en la línea de comandos, como single.

Para que los cambios tengan efecto es necesario re compilar el archivo de inicio con el comando

> lilo -v

Supongamos que /etc/lilo.conf contiene las siguientes entradas:

1: prompt
2: timeout = 50
3: image = /boot/vmlinuz1
4: root=/dev/hda1
5: label=L1
6: image=/boot/vmlinuz2
7: root=/dev/hda2
8: label=L2

Significa en pocas palabras que al arranque el sistema operativo presentará el prompt para seleccionar la imagen del kernel con la que queremos arrancar, o bien, para pasarle opciones a la imagen por defecto, el cual permanecerá visible por 5 segundos (según líneas 1 y 2), luego, tenemos dos imagenes de kernel instaladas: L1 y L2 (líneas 3 a 8).

Podemos insertar una línea nueva con la directiva password, justo después de la línea 2, e tal forma que el contenido se modifica así:

1: prompt
2: timeout = 50
3: password=S3cr3T0
4: image = /boot/vmlinuz1
5: root=/dev/hda1
6: label=L1
7: image=/boot/vmlinuz2
8: root=/dev/hda2
9: label=L2

Salvamos los cambios y ejecutamos lilo -v, de no haber errores reiniciamos la máquina y listo! En lugar de aparecer el prompt normal, aparece uno solicitando el password.

Esta opción por sí misma no es muy útil pues, si en algún momento el servidor se apagara, al regresar, forzosamente tendría que escribirse la contraseña. Si el administrador no está a la mano, pasaríamos al menos una media hora con el sisema abajo.

Por ello usamos restricted y password a la ves. De tal manera que ahora el lilo.conf quedara así:


1: prompt
2: timeout = 50
3: image = /boot/vmlinuz1
4: restricted
5: password=S3cr3t01
4: root=/dev/hda1
6: label=L1
7: image=/boot/vmlinuz2
8: restricted
9: password=S3cr3t02
10: root=/dev/hda2
11: label=L2

Con esta modificación el sistema operativo se levantará normalmente y mientras nadie intente pasarle opciones especiales a ninguna de las imagenes del kernel, entónces no aparecerá ningúna petición de password. En cambio, si durante la ventana de 5 segundos, se le indica al sistema que va a arrancar con la imagen L1 en runlevel 1 (L1 single), el usuario será interroado por el password específico para esa imagen (S3cr3t01).

De esta manera conseuimos que al menos, nadie que se siente en la consola pueda iniciar el sistema de manera diferente a la default.