La nueva versión viene con un instalador mejorado, la instalación gráfica recuerda a las primeras instalaciones de RedHat, tiene un buen acabado y es bastante rápida, además de configurable. Destacar que esta versión está disponible en soporte Blu-Ray (además de DVD y CD-ROM, como siempre), y USB.

Como novedad, se puede elegir, en la instalación, el sistema de ficheros ext4 (aunque por defecto nos da la opción de ext3), además del uso de LVM, que también estaba disponible en Lenny.

Otra de las novedades es la posiblidad de poder usar el kernel de FreeBSD en lugar del kernel de Linux. Realmente no son, aún, intercambiables 100%, puesto que no hay soporte completo desde la interfaz de usuario a todas las opciones que puede brindar FreeBSD, pero poco a poco todo llegará.

El software que trae, y que destaca la noticia de su liberación es el siguiente:

• KDE 4.4.5, el cual no termino de verlo con tan buenos ojos porque sigo siendo de los que prefieren la versión 3.5, pero he de admitir que esta es menos buggy que la distribución de Ubuntu en la que probé esta versión de KDE.
• Gnome 2.30, que tiene muy buen acabado y del cual no puedo decir gran cosa porque no soy usuario aférrimo de este escritorio, pero lo que he visto me ha gustado.
• OpenOffice 3.2.1
• Gimp 2.6.11
• Iceweasel 3.5.16
• Icedove 3.0.11
• PostgreSQL 8.4.6
• MySQL 5.1.49
• Linux 2.6.32
• Apache 2.2.16
• Samba 3.5.6
• Python 2.6.6, 2.5.5 y 3.1.3
• Perl 5.10.1
• PHP 5.3.3
• Asterisk 1.6.2.9
• Nagios 3.2.3
• Xen 4.0.1
• OpenJDK 6b18
• Tomcat 6.0.18
• …

Mucho por ver… ya iremos catándolo a través del tiempo, de momento, desde la versión Sarge de Debian no hay ninguna que me haya dejado con mal sabor de boca, y van: Sarge, Etch, Lenny y ahora Squeeze

Por ello, voy a explicar lo que son los procesos de este tipo de sistemas operativos (sobre todo orientándome en GNU/Linux).

¿Qué es un proceso?

Un proceso es un programa software que se carga en memoria y comienza a ejecutarse de forma secuencial. Un proceso puede, a su vez, según el sistema operativo, contener elementos paralelos de ejecución, como pueden ser hilos (threads). La ejecución de los procesos se puede ver con el comando:

ps xa

En GNU/Linux, cada proceso puede a su vez, lanzar otros procesos hijos. Estos dependerán del padre, de modo que cuando el proceso padre muera, los procesos hijos recibirán la señal de que deben de finalizar su ejecución.

La dependencia de procesos puede verse con el comando:

pstree

Procesos y recepción de Señales

Cada proceso que se ejecuta en el sistema operativo está preparado para recibir una serie de señales y actuar en consecuencia. El comando kill es el empleado de forma cotidiana para enviar de forma manual estas señales.

Las señales que se pueden enviar, en resumen, son:

Si queremos enviar a un proceso una señal específica, por ejemplo, que debe de terminar de inmediato, solo habrá que escribir:

kill -9 12123

Esto le dice al sistema operativo que debe de eliminar forzosamente el proceso 12123.

Estados de los procesos

Un proceso puede tener estados básicos de:

Un proceso que está en ejecución en primer plano, es decir, en la consola, puede ser detenido mediante la pulsación de ^C (Ctrl+C). Esta comando, envía al proceso activo la señal de SIGTERM.

Si se presiona la combinación de teclas ^Z (Ctrl+Z), se enviará la señal de SIGSTOP. Para volver a retomar el proceso ejecutar el comando fg.

Entorno de ejecución

Cuando estamos en una consola (un tty, pts o similar), tenemos a nuestra disposición un intérprete de comandos en el que podemos lanzar procesos en cualquier momento.

Estos procesos pueden detenerse mediante la pulsación de ^C, como habíamos dicho antes, pero también pueden detenerse (con ^Z).

¿Qué sucede cuando se detienen?, básicamente, se genera en un entorno de ejecución un identificador (que es informado entre corchetes, justo antes de la palabra Stopped, en el texto que sale nada más pulsar la combinación de teclas).

Este entorno se puede consultar con el comando jobs. Por ejemplo, si ejecutamos el vim y presionamos ^Z, volvemos a la consola con este mensaje:

[1]+  Stopped                 vim

Si ejecutamos el comando jobs, obtenemos:

$ jobs
[1]+  Stopped                 vim

A estos comandos podemos acceder directamente por su número, de modo que el comando kill, por ejemplo, se puede emplear de la siguiente forma:

$ kill -18 %1

[1]+  Stopped                 vim

¿Por qué nos responde eso y no volvemos a vim?, esto es debido a que el entorno vim requiere de una interacción con el usuario, por lo que no puede ser llevado a segundo plano. Si escribimos el comando bg (background) obtendremos el mismo resultado, debido a que el comando bg es para llevar un proceso detenido a segundo plano.

Si escribimos fg (foreground), recuperamos la interfaz de vim. ¿Qué pasa cuando tenemos varios vim parados?, en ese caso, podemos usar como parámetro el número de identificador del vim que queremos reactivar.

Prioridades

Hay muchas veces, que queremos que un proceso se ejecute con mayor prioridad que otro proceso que esté en el sistema. Que un proceso tenga prioridad para su ejecución, quiere decir que no tendrá que esperar sobre otro que tenga menos prioridad cuando requiera de la CPU para realizar su ejecución, por lo que, debe de ejecutarse más rápido.

Con esto, no obstante, hay que tener mucho cuidado, ya que otorgarle a un proceso pesado una prioridad muy alta, puede acarrear que el sistema se quede bloqueado, hasta que el proceso libere un poco al programador de tareas.

Las prioridades se otorgan con el comando nice. Por ejemplo, si queremos realizar un find con prioridad sobre los demás procesos normales, sabiendo que el número de prioridad por defecto es 10, y que los valores oscilan entre -20 y 19, siendo -20 la prioridad más alta y 19 la más baja, podemos ejecutar:

nice -n 5 find -iname mifichero

Cuando ejecutamos el comando ps, junto al estado del proceso, que ya se vió antes, aparece un segundo caracter, que se refiere a la prioridad siendo:

Conclusiones

La importancia de saber cómo manejar los procesos, los estados que pueden tener, cómo se organizan y las prioridades que pueden tener es crucial para un administrador de sistemas, y cualquiera que desee saber, en un momento dado, si la CPU de su equipo comienza a sobre-utilizarse, o incluso de que haya muchos procesos que ocupen la memoria y permanezcan de forma fija en modo parado.

El sistema GNU/Linux, al igual que su inspiración Minix, y la raíz de estos sistemas, Unix, se basan en ficheros. Todo es un fichero. Por ello, la seguridad de acceso a este tipo de información es muy importante.

Usuarios y Grupos

Los sistemas *nix, se basan en una estructura basada en grupos y usuarios. Un usuario puede ser una persona que tiene acceso al sistema mediante una contraseña y usa una consola, o puede ser un programa, un sistema servidor o un concepto abstracto (por ejemplo cdrom) en el que se agrupan una serie de ficheros, ejecución de servicios o servidores, etc.

Los grupos son como los usuarios, es decir, pueden tener propiedad sobre un fichero. Esto se hace para limitar o facilitar el acceso a los ficheros a un grupo de usuarios. Cada usuario puede estar en uno o varios grupos, así como cada grupo puede tener uno o varios usuarios.

… ¿y como se enlaza todo esto?

Los permisos en los sistemas *nix se basan en tres partes. Cada fichero y directorio tiene permisos específicos para: usuario, grupo y otros. Esto quiere decir que, si el fichero pertenece a un usuario y a un grupo determinado, podemos limitar los permisos para este usuario en particular, para ese grupo y para los demás.

Al realizar ls -lh en la consola es cuando se ve esta información en consola:

-rwxr-xr-x     1 bombadil  users      2K 12 nov  2009 marubio.jpg
-rw-r--r--     1 bombadil  users     50B  2 nov  2009 marubio.txt
-rwxr-xr-x     1 bombadil  users      5K 12 nov  2009 marubio2.jpg

Como se puede ver, la primera columna de la izquierda, hay un guión inicial que indica si es directorio (d) o fichero (-), después, se indican tres letras por tipo de permisos, en este caso sería:

• rwx, para el usuario, se dan los permisos de lectura (r), escritura (w) y ejecución (x).
• r-x, para los usuarios que no sean bombadil y pertenezcan al grupo users, se dan los permisos de lectura (r) y ejecución (x).
• r-x, y para los usuarios que no sean bombadil, ni pertenezcan al grupo users, se le dan los permisos de lectura (r) y ejecución (x).

¿Qué es eso de ejecución?

Básicamente, los permisos varían si se trata de un fichero o de un directorio, ya que la lectura (r) indica que se pueda leer el fichero o ver los ficheros que hay dentro de un directorio, así la escritura (w) indica que se pueda cambiar un fichero o crear ficheros en un directorio.

El permiso más extraño, el de ejecución (x), en caso de un fichero indica que se pueda ejecutar. Es decir, si se trata de un shell script, un programa compilado, o un script de consola de tipo python, etc., que se pueda ejecutar directamente (sino habría que lanzarlo desde algún intérprete.

En el caso de un directorio, indica si se puede acceder al directorio o no. Es curioso porque es casi como el atributo de lectura, solo que si tienes lectura y no escritura, se permite listar el directorio, pero no acceder con el comando chdir (o cd).

Equivalencia numérica

Hay mucha gente que esto de rwx le sonará un poco a chino y pensará… los permisos de tipo rwxr-xr-x son los 755 de toda la vida

Pues sí, los permisos se pueden dar de forma numérica también, teniendo en cuenta de que son valores octales, se puede dar un valor desde 000 a 777, siendo el primer dígito para el usuario, el segundo para el grupo y el último para los otros. Por tanto:

0 -> ---
1 -> --x
2 -> -w-
3 -> -wx
4 -> r--
5 -> r-x
6 -> rw-
7 -> rwx

Permisos especiales

Además de todo esto, hay dos permisos especiales que tienen unas propiedades bastante curiosas. El primero de ellos es el superuser grant. Este permiso se puede otorgar a programas que se deban de ejecutar como superusuario, pero solo se pueda dar a binarios, los programas de tipo scripting no tienen esta propiedad, ya que, realmente, se ejecutan desde un intérprete que no tendrá este bit de permiso activo.

Como ejemplo, podemos ver el programa passwd. Este programa ejecutado desde consola necesita acceder a ficheros como shadow y passwd para poder cambiar la clave del usuario:

-rwsr-xr-x 1 root root 39K dic  6  2009 /usr/bin/passwd

El segundo permiso especial es el sticky. Este permiso se otorga en especial a los directorios. Cuando un directorio tiene este permiso, quiere decir que cualquier usuario podrá tener acceso al directorio y crear incluso ficheros, pero no podrá modificar y ver nada más que los que sean de su propiedad.

Este atributo es el que se suele usar para el directorio tmp de los sistemas *nix, de servidores multiusuario. Cuando un programa necesita volcar información en este directorio, con este atributo, nos aseguramos que ningún otro usuario puede modificar o ver esta información temporal:

drwxrwxrwt 5 root root 12K ago  5 18:32 /tmp

Conclusiones

Los sistemas *nix tienen sistemas de permisos y usuarios muy simples, comparados con los sistemas de permisos de sistemas con Windows. Esto no quiere decir que sean peores ni mejores, son simples, y por ello flexibles y potentes. Así mismo, en los sistemas GNU/Linux se han implementado unas políticas añadidas de seguridad que no solo permiten el acceso o no a un recurso, sino a nivel de aplicación, el uso de una forma u otra de ese recurso.

No obstante, y sinceramente, el uso llano de estos permisos suele ser suficiente para la mayoría de los casos, no necesitando ninguna capa más que afine el nivel de privilegios, cuyo uso suele ser más complejo.

La idea es jugar, como si de una pistola se tratase, con el comando rm -rf / (lo cual elimina TODOS los ficheros del disco duro y unidades montadas que se tengan -si son accesibles-). El comando toma un número aleatorio y prueba si es divisible por seis. Si es así… ¡bang!, estás muerto, sino, puede volver a tirar

[ $[ $RANDOM % 6 ] == 0 ] && sudo rm -rf / || sudo echo “You live”

Curioso, ¿no?

NOTA: este blog no se hace responsable de los malos usos de los comandos expuestos, de si se elimina toda la información de su disco por un uso irresponsable del mismo, etc. Mi consejo… no lo uséis… o al menos, crear una jaula para jugar.

En este caso, voy a explicar como instalar y usar SQL Server vía ODBC desde cualquier aplicación en GNU/Linux, como pueden ser programas Java, Perl, PHP, Ruby…

En principio, vamos a tirar de apt-get para instalar algunos programas:

apt-get install tdsodbc unixodbc libct3 libltdl3 odbcinst1debian1

Lo siguiente es crear el fichero /etc/odbcinst.ini, que debe de contener lo siguiente:

[FreeTDS]
Description     = TDS driver (Sybase/MS SQL)
Driver          = /usr/lib/odbc/libtdsodbc.so
Setup           = /usr/lib/odbc/libtdsS.so
CPTimeout       =
CPReuse         =

Ahora, para cada base de datos a la que queramos conectarnos, habrá que agregar un bloque de este tipo en el fichero /etc/odbc.ini:

[contactos]
Driver      = FreeTDS
Server      = 192.168.1.5
Database    = contactos
TDS_Version = 8.0
Port        = 1433

El nombre de la conexión es el que se situa entre los corchetes, y el que se usará para referenciar a esa conexión.

Para comprobar, podemos ejecutar el comando isql con los siguientes parámetros:

isql contactos usuario clave

Con esto, desde interfaces como DBI (Perl y Ruby), podemos usar DSN del tipo DBI:ODBC:contactos para acceder a esta conexión, siempre pensando que el usuario y la clave debe de insertarse en el comando de conexión.

La sincronización horaria es completamente posible de llevar, simplemente, instalando un servidor de hora NTP dentro de nuestra red, para que nos haga de servidor de sincronización.

En España, generalmente, se suele usar hora.rediris.es como servidor de hora, puesto que es un sistema formado por varios servidores, algunos de ellos con el uso de relojes GPS.

Muchos sistemas ya tienen el servidor ntpd instalado. En otros habrá que hacer la instalación, ya sea del paquete con nombre: ntp, ntp-server, ntpd…

El archivo de configuración, normalmente: /etc/ntp.conf; debería de tener un contenido parecido a este:

driftfile /var/lib/ntp/ntp.drift
statsdir /var/log/ntpstats/
 
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
 
server hora.rediris.es
 
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
 
restrict 127.0.0.1
restrict ::1
 
restrict 192.168.123.0  mask  255.255.255.0 notrust
 
broadcast 192.168.123.255
disable auth
broadcastclient

Con esto, el servidor de hora recién instalado, servirá como repetidor para los equipos de la red interna. En caso de tener un solo equipo, en ese caso es mejor tomar el archivo de /etc/ntp.conf y modificarlo levemente para hacer que el sistema fucnione, y nada más.

Espero que os sirva de ayuda.

Los paquetes de GNU/Linux tienen que cumplir la especificación de ordenación de ficheros que establece la distribución en concreto donde se va a instalar la aplicación, así pues, nos encontramos a este respecto con dos grandes variantes: RPM y DEB.

Los RPM, obra de RedHat, son paquetes que se guardan comprimidos y contienen una serie de scripts para la instalación, actualización, eliminación y otras actividades similares. Además de esto, los paquetes contienen información de dependencia, es decir, que antes de instalarse en el sistema, deben de estar instalados otros paquetes para que el binario que contiene el paquete funcione correctamente. Es su garantía de funcionalidad y lo que lo diferencia de los paquetes binarios que se generan para Windows.

Los DEB son paquetes obra de Debian, que tienen las mismas características que los RPM, pero agregando algunas características más como sugerencias y recomendaciones. Las sugerencias son paquetes similares o que pueden trabajar en conjunto con el que se va a instalar. Las recomendaciones son paquetes que añaden funcionalidades al paquete que se está instalando, como por ejemplo la internacionalización, algún plugin, o algo por el estilo.

El uso de los paquetes RPM se lleva a cabo por el programa rpm, el cual es instalable en cualquier distribución (incluso Debian) y permite manipular los paquetes de tipo RPM para su instalación, listado e incluso creación. En los paquetes DEB tenemos dpkg, el cual se usa de forma idéntica a rpm (en concepto).

La facilidad de estos paquetes no es en sí la encapsulación, puesto que agregan muy pocas características en comparación con los famosos InstallShield de Windows y otros similares. La gran ventaja de estos sistemas son los repositorios. Un repositorio es un sitio accesible por HTTP, FTP o similar que permite la descarga de un paquete RPM y/o DEB para su instalación en el sistema.

Cada distribución ha ido creando su herramienta específica y podemos ver, entre otras, para RPM en Fedora yum, en SuSE es yast, en Mandriva es urpmi e incluso en todas las distribuciones basadas en RPM, se puede usar apt; para DEB tan solo tenemos apt. No obstante, hay otras distribuciones como Slackware y Gentoo, que no usan paquetes ni RPM ni DEB, los cuales también tienen herramientas para descarga de sus paquetes específicos desde Internet.

La configuración de APT la podemos ver en detalle en el siguiente enlace.

La configuración de YUM la podemos ver en detalle en el siguiente enlace.

La configuración de URPMI la podemos ver en el siguiente enlace.