Creación de un ramdisk.

Un ramdisk consiste en utilizar la memoria RAM como si se tratase de un disco de almacenamiento secundario. Tenemos que tener en cuenta, que el espacio utilizado como ramdisk no podra ser utilizado para albergar procesos, por lo que reducimos la cantidad de memoria para el funcionamiento normal del equipo, lo que puede reducir considerablemente el rendimiento de nuestro equipo. Pero si estamos "sobrados" de RAM, y queremos que cierta información sea muy rapidamente accesible (por ejemplo la cache de un programa webcache, un fichero de base de datos... etc) podemos ubicarla directamente en en memoria RAM. Para realizar esto, tenemos que saber que la memoria ram esta montada directamente en /dev/shm, de tal manera que todo lo que guardemos en dicha carpeta se almacena directamente en memoria RAM. Además, dicho directorio puede ser escrito por cualquier usuario, ya que es un directorio para archivos temporales con el stickybit activo. Esto en cierto modo es peligroso, ya que un usuario malintencionado se podria dedicar a llenar dicha carpeta hasta dejar al equipo sin memoria RAM disponible. Para evitarlo podemos modificar el fstab modificando los permisos de escritura en dicha carpeta, o directamente, que no lo monte. 

También, debemos saber que el contenido de dicha carpeta se borrara al apagar el equipo, ya que la memoria RAM es volatil.

Veamos como podemos crear un ramdisk de un determinado tamaño. Por ejemplo, para crear un ramdisk de 512MB, introduciremos el siguiente comando:

Podemos observar en el resultado de df, que hemos creado un ramdisk de 512MB, y esta ubicado en /mnt/memory. Si queremos modificar los permisos por defecto para tmpfs podemos incluir la opción mode=0700 (todos los permisos para root). Podemos comprobar con el comando free como al copiar ficheros a la carpeta del ramdisk disminuye la cantidad de RAM libre.

NAT en Linux y Windows 7

NAT (Network Address Translation) es un protocolo de nivel de red que sirve para comunicar equipos entre dos redes diferentes (y que no se conocen entre si) sin necesidad de modificar ninguna tabla de rutas. en los hosts. El truco esta en enmascarar las direcciones ip, función que realiza el enrutador que comunica las dos redes. Veamos un ejemplo para entenderlo mejor.

Supongamos que tenemos un enrutador E con dos interfaces de red, uno de ellos se encuentra en la red A ( 192.168.0.0/24 ) y tiene la ip 192.168.0.2 y el otro en la red B (192.168.1.0/24) y el interfce de red tiene la ip 192.168.1.1. En la primera red tenemos otro enrutador I que nos da salida a internet, con la ip 192.168.0.1. El gateway por defecto de todos los equipos de la red A y del enrutador E es 192.168.0.1, y en la red B es 192.168.1.1. Con esta situación, imaginemos que queremos comunicar el equipo 192.168.1.10 con el equipo 192.168.0.10. El paquete llega a nuestro enrutador (ya que es el gateway por defecto de todos los host de la red B), el cual tiene conocimiento de las dos redes y envía el paquete al destinatario. El problema esta en el camino de vuelta. El host 192.168.0.10 (HOST1) tiene que enviar un paquete a 192.168.1.10 (HOST2), como el destino no esta en su red lo envía por su gateway por defecto (I) y ya nos podemos despedir del paquete. La primera opción seria añadir en la tabla de rutas del host 192.168.0.10 una linea que indique que el gateway para los paquetes cuyo destino es la red 192.168.1.0/24 es 192.168.0.2 (E). La otra opción es configurar el enrutador para que haga NAT. Describamos el ejemplo anterior con NAT. El paquete a enviar desde el HOST1 va directamente a su gateway por defecto, este, antes de mandarlo a su destinatario, aplica el protocolo NAT y lo enmascara, de forma que el remitente del paquete ahora ya no es el HOST1, sino que es la ip 192.168.0.2 (el enrutador E). El paquete llega al destinatario y este ahora devuelve una respuesta al remitente del paquete que es 192.168.0.2. Al analizar el paquete, el enrutador E observa mediante NAT que el destinatario no es el, sino el HOST1, de tal manera que se lo envia y la comunicación termina.

Bueno, después de este enrevesado ejemplo vamos a pasar a ver como se configura en Windows y en Linux. Comencemos por Windows 7:

En Windows 7 ( también en XP y Vista) el servicio NAT se llama ICS, que es en realidad una mezcla de servidor DHCP y NAT. Para activarlo abrimos el panel de conexiones de red.

A continaución, en el interface de red que tiene salida a internet, pulsamos el botón derecho del ratón y hacemos click en propiedades. En el cuadro de dialogo que aparece seleccionamos la pestaña de uso compartido.

Activamos el checkbox para compartir la conexión a internet y le damos a aceptar. Nos aparecera el siguiente cuadro de dialogo indicandonos que la red privada (a la que se encuentra conectado el otro interface de red) tendra configuración dinámica obligatoriamente, ya que en nuestro equipo se activara un servidor DHCP. La red será 192.168.137.0/24

.

Observamos que en el icono de la conexión de area local se índica que la red esta compartida.

Comprobamos desde un HOST de la red privada que todo funciona.

Ahora veamos como hacerlo desde Linux. Si ya tenemos configurados los dos interfaces de red, debemos hacer dos operaciones:

1) Activar el servicio ip_forward para que el equipo enrute el tráfico entre sus interfaces de red. Podemos hacerlo de dos maneras:

a) Dar permiso de ejecución a /etc/rc.d/rc.ip_forward. Al reiniciar el equipo se activar. Si queremos activarlo en el momento lo ejecutamos.

b)Añadir la siguiente linea al fichero /etc/rc.d/rc.local

echo "1" > /proc/sys/net/ipv4/ip_forward

2) Hacer NAT entre dos redes: Añadimos al fichero /etc/rc.d/rc.local la siguiente linea:

iptables -A POSTROUTING -t nat -s RED_PRIVADA ! -d RED_PRIVADA -j MASQUERADE

donde RED_PRIVADA es la red a enmascarar, por ejemplo 192.168.0.0/24. Dicha red puede ser de configuración estática o dinámica.

XFS debian vs. XFS slackware.

XFS en un sistema de ficheros que a priori tiene su mejor rendimiento manejando ficheros de gran tamaño. Por lo tanto parece el ideal para albergar discos de maquinas virtuales. Hasta aqui todo correcto, pero el problema surge cuando nos encontramos que el xfs de la herramienta de creación y clonación de imagenes clonezilla (basada en debian) no es compatible con el sistema xfs de slackware. Por culpa de esto me volvi loco un par de dias, ya que para el /home utilizaba un volumen lógico formateado en xfs extendido en dos volumenes físicos. Hace poco tiempo, comentandolo con un buen amigo, me comento que le pasaba lo mismo y que el culpable era el sistema de ficheros xfs. Yo no sabia si era por los volumenes o por el sistema de ficheros, por lo que lo resolvi cambiando a ext4 sobre particiones simples ya que no tenia tiempo material para hacer pruebas, pero el problema viene del sistema xfs. La cuestión es... ¿quien tiene la culpa? ¿debian o slackware?.
Espero poder escribir más frecuentemente, pero de momento, no puedo.

Vulnerabilidad italc.

¿Qué sucede con la anterior configuración de Xsetup para lanzar el ica en el arranque si lanzamos más de una sesión gráfica?. La mejor forma de averiguarlo es probandolo. Lo hacemos y comprobamos que sucede con el proceso ica.

Tenemos dos procesos ica, uno en espera (funcionando) y otro Zombie (a ver si se va a comer otro proceso....). Ahora el usuario tiene abiertas dos sesiones gráficas, cada una con su ica, de manera que cuando cerremos la nueva, volveremos a la antigua y el ica seguira funcionando. Pero mientras este funcionando con las dos sesiones, en el programa italc desde el ordenador del profesor solo podremos visualizar un ica (el que no esta zombie, es decir el de la nueva sesión), por lo que con la configuración actual, si un alumno lanza una nueva sesión gráfica, y vuelve para utilizar la antigua, nosotros visualizaremos desde nuestro equipo la nueva sesión gráfica, y el en la antigua podra hacer lo que quiera sin ser observado (igualito que en todas las pelis de ladrones de bancos para burlar la seguridad de las camaras). Para asegurarnos de que esto no pueda ocurrir, por el momento no he encontrado una solución "elegante". La solución que estoy utilizando son las siguientes lineas en el fichero XSetup:

De este modo lo que hacemos es apagar el equipo si un usuario intenta abrir una segunda sesión gráfica. 

Deshabilitar Ctrl + Alt + BackSpace ( matar servidor X) en Linux Slackware.

Esta opción es interesante para evitar que los alumnos puedan liberar facilmente al equipo del control del italc cuando estamos realizando una demo, o aplicando un candado. En estos casos, no tienen control sobre el equipo, pero si matan el servidor X lo recuperan. Para evitar esta situación podemos deshabilitar la combinación Ctrl + Alt + BackSpace que permite matar las X. Para ello, como es lógico, editaremos el fichero de configuración del servidor X : /etc/X11/xorg.conf. En el buscaremos la siguiente linea:

Descomentamos la opción DontZap eliminando el símbolo "#" que tenemos al comienzo de la linea, y en cuanto reiniciemos el servidor X, los cambios tendrán efecto. Si en nuestro fichero xorg.conf no tuviesemos la opción, la añadiriamos en la sección ServerFlags, de no contar con dicha sección, añadiriamos también la sección. Tras ellos, dicha combinación de teclas no funcionara.

Fin de las vacaciones.

No voy a decir que las vacaciones han sido cortas por que podria buscarme muchos enemigos, pero como todo lo bueno, ya se acabaron. Esta semana toca volver al aula y a escribir cosillas interesantes que vaya haciendo. Tengo muchas cosas nuevas por escribir, y estoy deseando ponerme al lio. Lo malo es que ahora tengo que compartir mi tiempo libre entre trastear con el ordenador y la fotografia.

Adios al CarPc.

Este verano toco cambio de vehiculo. Normalmente es motivo de alegria, pero en este caso me dio bastante lastima ya que el coche que cambiaba llevaba instalado un CarPC. Inverti muchas horas de trabajo en su instalación, y estaba muy orgulloso de los resultados. El sustituto ya viene con GPS original, por lo que no puedo instalar un nuevo CarPC. Fue una gran experiencia que no me importara volver a repetir en el futuro en otro vehiculo, pero siempre la primera vez es especial. Como pequeño homenaje al mi ex- bandidito (tanto me gustaba el coche que hasta le tenia puesto nombre) dejo el post que escribi en su dia en el foro de solocarputer.

Enrutando con salackware.

Es verano... llevo muuucho tiempo sin tocar el ordenador (lo necesitaba). Pero en una paradita de unos días por casa toca escribir algo en el blog... aunque sea poco. Hoy el tema va a ser como hacer que un equipo con varias tarjetas de red enrute el tráfico entre varias redes.
En linux, que el equipo enrute o no, depende del contenido del fichero /proc/sys/net/ipv4/ip_forward. El contenido puede ser:

• 0 : no se enruta.
• 1 : se enruta entre redes.

El contenido de dicho fichero solo puede ser cambiado por el superusuario, y si el equipo va a funcionar como enrutador, la forma correcta de configurarlo es activando el servicio de rc.ip_forward en la carpeta /etc/rc.d. Para ello simplemente damos permiso de ejecución a dicho fichero, y lo ejecutamos con el parámetro start.

1. chmod +x /etc/rc.d/rc.ip_forward
2. /etc/rc.d/rc.ip_forward start

Una vez hecho esto el equipo podra pasar tráfico de una red a otra, pero tendremos que tener bien configuradas las tarjetas de red, la tabla de rutas, el firewall,... etc para que todo funcione correctamente, pero lo bonito de todo esto es que con poner un 0 en un fichero podemos aislar dos redes.

Sandboxie

En este caso, hare una excepción, y hablare sobre una interesante herramienta para ejecutar aplicaciones "dudosas" en entornos windows. A la hora de utilizar este tipo de aplicaciones en entornos linux, podemos crear un root jail o directamente utilizar maquinas virtuales, de manera que aislemos la maquina estable de ejecuciones "dudosas". En windows, teniamos la opción de maquinas virtuales, pero encontre esta interesante herramienta que permite virtualizar un entorno para una aplicación, sin tener que virtualizar una maquina completa con su propio sistema operativo, de modo que es más ligero. En el siguiente enlace se puede encontrar más información.

sandboxie

Instalación en RAID1 + LVM.

Se que llevo mucho tiempo sin escribir, pero el último mes ha sido de mucho lio en el trabajo, y como siempre la parte de documentar las cosas queda para el final (si se hace...). De momento, pondre esta pequeña guia sobre como instalar linux slackware sobre un RAID1+ LVM. Como ya esta hecha una guia sobre la instalación de linux slackware, aqui solo trataremos los apartados que son diferentes por el tipo de dispositivo lógico que utilizaremos para la instalación. Como es bastante larga, he preferido crearla en un documento pdf en lugar de en un macropost.
Espero poder ir añadiendo contenidos más regularmente... pero de momento hago lo que puedo.

Documentacion raid

View more documents from Alfonso.

Lanzando ica en el arranque.

Una vez que tenemos instalado el italc en un equipo, tenemos que asegurarnos de lanzar el proceso ica en el arranque del sistema como proceso de un usuario diferente al usuario del alumno, para evitar que este pueda matar el proceso y librarse del sistema de control del aula. Hay que tener en cuenta, que el proceso ica necesita que esten las X lanzadas, por lo que no podemos añadirlo en /etc/rc.d/rc.local.  Lo lanzaremos desde el gestor de login gráfico kdm. Para ello editamos el siguiente fichero con vi:

En dicho fichero se indica que su contenido se ejecutara como root antes de cargar la pantalla de login, pero ya con las X en funcionamiento. Vamos a añadir una linea:

 ica &

Ahora hay que ver como actua el ica ante las siguientes situaciones:

• Reiniciamos las X: al realizar dicha operación, también matamos el proceso ica. Al relanzarse se vuelve a lanzar el proceso de manera que todo queda como estaba. Solo puede servir para que un alumno se salte un bloqueo, pero también pierde todo el trabajo de todas las aplicaciones lanzadas que dependan del entorno gráfico, luego seria una opción estupida para eludir un bloqueo impuesto por el ica, y en esa situación tocaria aplicar un "usermod -L alumno" para bloquer el acceso del usuario al sistema, de manera que se quedara en la pantalla de login sin poder hacer nada hasta que le desbloqueemos con "usermod -U alumno" y listo.
• Cerramos la sesión del usuario: al igual que en el caso anterior, el proceso ica muere, y se lanza uno nuevo. 

En resumen, con privilegios de usuario y con la configuración anterior, o  se desenchufa el cable de red, o saltarse el control del aula no sera tarea sencilla.

Configurando italc.

Una vez instalado debemos configurarlo antes de poder utilizarlo. Lo primero que debemos hacer es crear una clave publica y otra privada, con la que se protegera el acceso al servidor vnc, de manera que un alumno no puede acceder a controlar el equipo de otro alumno con un cliente VNC sin conocer la clave privada. Para ello ejecutamos el siguiente comando:

Vemos que se han creado dos carpetas con claves, una publica y otra privada. La clave publica es necesaria para que se lance el servidor ica, y la clave privada es necesaria para lanzar el cliente italc, el cual nos permitira manejar todos los equipos que esten ejecutando el servidor ica. Por ello, es necesario que en los equipos de los alumnos, ni su usario ni su grupo tengán ningún permiso sobre la clave privada, y que tengan permisos de lectura sobre la clave publica. Por defecto, se dan permisos de lectura para la privada al usuario root, y al grupo root; y para la clave publica, tienen permisos de lectura todos los usuarios.

Podemos cambiar los permisos, pero teniendo en cuanda que el usuario utilizado por los alumnos solo debe tener permiso de lectura de la clave publica, aunque como el proceso ica lo lanzara el usuario root, si queremos no es necesario ni tan siquiera dar dicho permiso.

Tras la creación de los ficheros anteriores, podemos lanzar el servidor ica, y el cliente italc, ejecutando los comandos en una terminal. Tras ejecutar el comando ica, aparecera un icono verde en el area de notificación, que indica que dicho servicio esta corriendo. Una vez lanzado el programa ica, escribiremos italc en una terminal para lanzar el programa cliente, y veremos el siguiente interface (aparece un aviso indicando que no hay ningún aula creado, ya la crearemos después).

 

Ya tenemos el programa funcionando. Ahora tenemos que crear un nuevo aula, añadir los equipos de los alumnos, y listo. Es necesario que en todos los equipos que queramos controlar este instalada la aplicación italc, cuente con los mismos ficheros de clave que el equipo del profesor, y este corriendo el proceso ica.

Comencemos creando un aula y añadiendo un equipo. Para ello, en la barra vertical izquierda seleccionamos el icono que aparece con una pantalla y una lupa (classroom manager). Para añadir un aula, hacemos click con el botón derecho del ratón, seleccionamos add classroom, la ponemos un nombre y listo, ya aparece en el listado de aulas.

Para añadir equipos a un aula, hacemos click con el botón derecho del ratón sobre el nombre del aula, y seleccionamos add computer.

A continuación nos aparece el siguiente formulario para rellenar los datos del equipo.

Tendremos que dar un nombre el equipo, establecer su dirección IP, decir a que clase queremos añadirlo, y opcionalmente, poner su MAC para permitir arrancar el equipo del alumno mediante wake up lan. Para esta ultima opción, es necesario que la placa del equipo del alumno soporte wake up lan (si el equipo tiene menos de 5 años seguro que lo soporta), y que lo tenga habilitado en la BIOS, además de no poder haber ningún enrutador por medio. Adicionalmente, podemos modificar el rol de dicho equipo, por defecto, es student computer. En otra pestaña podemos configurar conexiones VPN, por lo que este programa también resulta muy util para educación a distancia.

Una vez creado el alumno, en cuanto se conecte, podremos ver la imagen de su pantalla, y realizar las diferentes acciones que permite la aplicación cliente sobre el servidor. En este caso no hay en la red local ningún equipo con esa IP con el servidor ica escuchando por lo que no se muestra nada.

En el siguiente articulo configuraremos el italc en el equipo del alumno, y probaremos las diferentes opciones del interface.

Italc. Controlando el aula.

Contar con herramientas para el control de equipos en el aula,  puede resultarnos de gran ayuda en multiples situaciones. De esta manera, podremos realizar demos, bloquear equipos si no se utilizan adecuadamente, apagar equipos, controlarlos remotamente.... etc. En windows, existe una herramienta que cumple con estos fines, llamada netopscholl. La pega, es que es software de pago. En linux, contamos con la herramienta de codigo libre italc, cuyo principal inconveniente frente a netopschool, es que esta última permite hacer examenes a través de la propia herramienta, e italc no. Como principal ventaja, es que italc sirve tanto para sistemas linux como para sistemas microsoft.

Vamos a ver como instalarla compilando los archivos con el codigo fuente. Lo primero que debemos hacer es descargar el paquete con las fuentes de su página web. Una vez que lo tengamos en nuestro equipo, el siguiente paso es descomprimir el fichero con bzip2 y tar.

A continuación entramos a la carpeta italc-1.0.9 con el comando cd, listamos su contenido, 

y como es habitual vemos los ficheros README e INSTALL, en los cuales suele estar la información necesaria para compilar las aplicaciones (dependencias, opciones de compilación... etc). Como es habitual, para compilar e instalar la aplicaciones debemos ejecutar los comandos:

• ./configure
• make
• make install

El archivo configure, es un script que comprobara el entorno de compilación, para verificar que se encuentren todas las librerias necesarias para la compilación. Este paso es el más delicado, y el que más problemas nos puede dar en función de las dependencias de la aplicación. En este caso cabe destacar la dependencia a las librerias QT 4. Si lo instalamos en Slackware 12.2, tendremos una versión de QT inferior, por lo que tendremos que compilar dichas librerias (2 horitas de compilación en un core 2 duo). Con la versión 13 no hay dicho problema. 

Si todo sale bién, veremos el siguiente mensaje:

Ya podemos ejecutar make && make install. Cuando finalice, ya tenemos instalada la aplicación italc. La aplicación es de tipo cliente (italc) servidor (ica), por lo que en el fondo, no hemos instalado una aplicación, sino dos. Antes de poder utilizarla hay que configurarla, como veremos en el siguiente post.

Cambiar el idioma de Firefox.

Llevo un tiempecillo sin poder escribir, todo debido a que he estado liado de mudanza. Además he estado muy ocupado con mi nuevo equipo, montando raids, volumenes lógicos y demás historias que espero poder escribir en breve. De momento hoy voy a escribir algo cortito, aunque más largo de lo que deberia ser: como cambiar el idioma en firefox. Una operación que deberia ser tan sencilla (y seguro que no tardara mucho en ser así, aunque es inaudito que en la versión 3.6.3 continue siendo tan complicado) como ir al menú de preferencias, y en alguna de las pestañas seleccionar el idioma, se complica bastante, ya que hay que instalar un complemento de idioma, y modificar un parametro de configuración de la aplicación.

Lo primero que tenemos que hacer es bajar el complemento de idioma del ftp de mozilla:

http://releases.mozilla.org/pub/mozilla.org/firefox/releases/3.6.3/linux-i686/xpi/

Si nuestra versión de firefox es otra, bajamos hasta la carpeta releases para seleccionar la adecuada.

Bajamos e instalamos el complemento de idioma es-ES.xpi. Tras ello, si mostramos los complementos instalados veremos el paquete de idioma español, aunque el navegador seguira en inglés. (En la captura sale en español por que ya tengo cambiado el parámetro de configuración)

Una vez instalado el complemento de idioma, pondremos en la barra de navegación "about:config". Nos aparecera una "graciosa" advertencia, diciendo que no toquemos nada si no estamos seguros de lo que hace. Tras ello veremos una interminable lista de parámetros. Buscaremos general.useragent.locale y modificaremos su valor por es-ES. Salimos, reiniciamos el navegador y listo¡

Hdparm y smartctl, testeando y configurando el disco duro.

Cuando comence a utilizar linux slackware, y lo instale en una partición de mi portatil, tuve un pequeño problema con el funcionamiento del equipo, era tremendamente lento. Indagando sobre la posible causa, descubri dos comandos muy interesantes para el análisis y configuración de unidades de disco. Son smartctl y hdparm. El primero de ellos nos permite monitorear parámetros del disco (temperatura, fallos de lectura, horas de uso...etc), y el segundo, ver y modificar parámetros del disco (podemos modificar hasta el nivel de ruido del disco¡¡). Mi problema fue que no funcionaba correctamente el DMA del disco, cuestión que resolví modificando ciertos parametros del disco con hdparm.

Ese fue mi primer y único contacto con hdparm, que salvo en esa ocasión, y para hacer test de velocidad de lectura de disco, no habia utilizado para más.. hasta hoy. Por desgracia, tengo el oido muy fino, y de vez en cuando oigo un ruidito extraño proveniente del disco duro del portatil, como un clip!. Por pura coincidencia, leyendo árticulos por internet, vi uno cuyo titulo me resulto muy atractivo, y explicaba el origen de dicho ruidito.

Ubuntu podría acortar la vida del disco duro de los portátiles.

Podrían poner ese aviso en los discos de ubuntu de forma similar a las advertencias en los paquetes de tabaco. En dicho árticulo hablaban sobre una técnica llamada ramp load/ramp unload utilizada por varios fabricantes de discos duros para portatiles. La idea es muy buena, situan una rampa en la parte exterior de la cara del disco, donde puede reposar el cabezal cuando no esta en uso, con la finalidad de ahorrar energia y proteger el disco en caso de vibraciones.

Pero como todo lo bueno, tiene una pega, el número de cargas y descargas del cabezal en la rampa no son infinitas, de forma que los fabricantes garantizan el correcto funcionamiento del disco hasta unas 300K-600K operaciones de carga y descarga. Se puede configurar la tendencia del disco a utilizar esta técnica, llegando a deshabilitarla. Lo normal es que el acpi de un portatil modifique dicho parámetro en función de la configuración de energia. Por ejemplo, si estamos funcionando con batería, se realizaran gran cantidad de operaciones de load/unload para ahorrar energía, y protegiendo a su vez el disco duro (supongamos que siempre que funcionamos con bateria es que vamos en un todo terreno por un camino), sin embargo, en modo conectado, estas se minimizarán para maximizar la vida útil del disco duro. El problema de ubuntu (y muchas otras distribuciones) no es que maximizará el ahorro de energía, sino que el disco lleva configurado dicho parámetro de fabrica, y si no se le dice lo contrario, hará lo que tenga configurado, de manera que el problema lo generan los fabricantes de discos, no ubuntu.

Visto el problema probemos a analizarlo. Para ver toda la información realizamos los siguientes pasos:

1ª Ejecutando hdparm -I /dev/nombre de mi disco. Asi vemos como esta configurado el advanced power management. Dicho parámetro tiene un rango desde 0 (máximo ahorro de energia) hasta 255 ( desactivado). Cuando comprobe como estaba configurado mi disco inicialmente tenia un valor de 160. 

2ª Ejecutando smartctl -a /dev/nombre de mi disco. Se nos mostrara información muy útil para evaluar el estado del disco.

Nos interesa ver Power_on_hours y Load_Cycle_Count. Así, puedo comprobar como mi disco ha realizado 85982 ciclos de carga en 3558 horas de uso (que poquito uso el ordenador...). Ya tiene agotado alrededor de un 30% de sus ciclos, por lo que decido modificar el parámetro de configuarción con hdparm para alargar la vida del disco.

Para modificarlo ejecutamos hdpar -b valor disco, siendo el valor un número entre 1-255, y disco, el fichero que representa nuestro dispositivo. En mi caso quiero ser conservador, y pongo el valor 254:

La cuestión es que en algunas distribuciones de linux, el acpid va configurado de manera que modifica dicho en función del modo de funcionamiento (conectado o bateria). En slackware 13 64bits que tengo instalado no modifica dicho valor, aunque se puede modificar el script del acpid para que realice dicho cambio. Yo como siempre funciono en modo conectado (Es lo que tiene que al probre portatil le dure la bateria 5 minutos) no me he metido a realizar dichos cambios... quizas más adelante.

Ramp load

Cambio de runlevel.

Por defecto, en slackware, tras terminar de cargar el sistema operativo, se presenta el login en modo consola. Tras hacer login es posible iniciar el modo gráfico con el comando startx, y podemos configurar el gestor de ventanas a utilizar, como ya vimos en otro árticulo. El inicio en modo gráfico o en modo texto se debe al runlevel configurado, y es modificable para que podamos iniciar directamente el sistema en modo gráfico, presentandose el login en dicho modo. Para modificarlo, editaremos el fichero /etc/inittab.

A continuación, podemos ver el contenido del fichero con la información relativa a los runlevels.

Podemos observar los diferentes runlevels. Actualmente nuestro sistema se encuentra en el runlevel 3, si queremos iniciar directamente en modo gráfico lo cambiaremos por el runlevel 4. Dicho cambio lo realizamos en la línea siguiente a la que aparece con el comentario "Default runlevel", cambiamos el número 3 por el 4, y en el próximo arranque se iniciara en modo gráfico. Tras realizar los cambios, reiniciamos el equipo y comprobamos que funciona.

Aparece el gestor de login de kde (kdm). Introducimos usuario y contraseña y vemos como el gestor de ventanas que carga es kde, no haciendo caso del gestor de ventanas que tengamos configurado en el fichero .xinitrc, ya que dicha configuración solo sirve para el comando startx desde el runlevel 3.

Para analizar mejor lo que sucede vamos a ver el script que se ejecuta al configurar el runlevel 4. Nos situamos en la carpeta /etc/rc.d y vemos que contine multitud de ficheros, pero el que nos interesa es el fichero rc.4, que corresponde al script que se lanza en dicho runlevel.

Podemos observar como este script va buscando diferentes programas de login gráfico en un determinado orden (gdm,kdm y xdm), de manera que el primero que encuentre cuyo ejecutable exista, será lanzado por el sistema. Aqui podriamos modificar el gestor de login utilizado, pero lo que nos interesa es modificar el gestor de ventanas, por lo que no realizamos ningún cambio y nos vamos a por el script del kdm que lanza el gestor de ventanas, que es /usr/share/config/kde/session.

Al final del fichero encontramos una línea donde vemos que lanza el gestor de ventanas kde, modificamos startkde por startxfce4, y al reiniciar las X (ctrl+alt+bckspace) haremos login y veremos como ya si que carga el gestor de ventas xfce. Lo unico que hemos hecho es modificar el gestor por defecto (logicamente era kde), pero cada usuario desde la pantalla de login de kdm podría elegir su gestor de ventanas. Si observamos bién la estructura case, advertimos que podemos crear un fichero llamado .xsession con kdm , en el cual añadiremos una linea con el comando del gestor de ventanas personalizado (kde, xfce ...etc). En el momento de hacer login en kdm, podemos seleccionar como gestor de ventanas para la sesión el personalizado para el usuario, por lo que ejecutaria el configurado en .xsession.

También es posible realizar una configuración más avanzada del kdm a traves de modo texto editando el fichero /usr/share/config/kdm/kdmrc, el cuál esta ampliamente comentado para facilitar su configuración, o a través del entorno gráfico en preferencias del sistema, avanzado, gestor de acceso. Podemos encontrar más información aqui.

Selección del gestor de ventanas por defecto.

Cuando instalamos linux slackware, seleccionamos el gestor de ventanas kde como gestor predefinido. De este modo, tras arrancar, hacemos login en terminal modo texto, para, a continuación, iniciar el entorno gráfico escribiendo el comando startx. Dicho comando lanza las X y el gestor de ventanas KDE. Lo que vamos a ver en este artículo es como modificar el gestor de ventanas utilizado por defecto.

Tras lanzar el servidor X, el sistema operativo lanzara el gestor de ventanas que se configurado en el fichero .xinitrc que encuentre en la carpeta $HOME del usuario que lanza el entorno gráfico. En caso de no encontrarlo utilizara el fichero /etc/X11/xinit/xinitrc. De esta manera podemos modificar el gestor por defecto que se asigna a los usuarios, o configurar individualmente un gestor para cada usuario. Vamos a ver el contenido del directorio /etc/X11/xinit.

Podemos observar como el fichero xinitrc no es más que un enlace al xinitrc concreto para cada gestor de ventanas que tenemos instalado en nuestro sistema. Para modificar el gestor por defecto (kde) por el gestor xfce4, debemos eliminar el enlace y crear otro nuevo enlazando al xinitrc de xfce4. De todos modos esto no nos sirve para modificar el gestor en los usuarios ya creados si estos ya tienen un fichero .xinitrc en su directorio $HOME. En nuestro caso tenemos creado el usuario root. Vamos a modificar su /root/.xinitrc para que su gestor de ventanas sea xfce4.

Al final del fichero vermos lo siguiente:

El comando startkde es el que inicia el gestor de ventanas kde una vez que estan corriendo las X. Comentamos la linea y añadimos el comando startxfce4 para iniciar dicho gestor de ventanas.

Una vez realizados dichos cambios ejecutamos el comanto startx y podemos observar como el gestor de ventanas utilizado es xfce4.

Si queremos ser lo más austeros posibles, y consumir pocos recursos en gráficos, podemos recurrir a blackbox. Para ello modificaremos el fichero .xinitrc poniendo al final el comando blackbox en lugar de startxfce4.

Ya sabemos configurar el gestor de ventanas, ahora solo es cuestión de escoger el que más nos guste en función de los recursos que queramos dedicar al entorno gráfico.

La batalla de compilar aplicaciones. Qtpfsgui.

Una de las grandes "pegas" que tiene linux, es la instalación de aplicaciones. El problema son las dependencias a librerias, problema que distribuciones como debian resuelve con apt-get, fedora con yum... etc. En slackware lo más parecido que hay son los slackbuilds, que no son más que scripts para compilar los ficheros fuente de la aplicación en cuestión. Desde luego, si compilamos un programa, siempre quedara más optimizado y adaptado a nuestro equipo que un precompilado, pero nos encontramos con el problema de las dependencias.  Desde hace tiempo, procuro compilar todas las aplicaciones que instalo, aunque a veces toca lidiar con problemas que puedes llegar a tardar un buen rato en resolver.

Hoy he instalado una aplicación para generar imágenes HDR. La apliación en cuestión se llama pfstools, su interface gráfico qtpfsgui, y dicho interface depende de una libreria llamada fftw. Comienzo instalando pfstools y todo ok, ya puedo crear los HDR desde consola. Después instalo fftw y perfecto. A continuación intento instalar qtpfsgui... error¡¡ no encuentra las librerías de ftw (el .configure dice que esta todo ok, pero en el make falla). Total, que buscando las librerias que necesitaba veo que no están. Tras muchas vueltas logre encontrar la solución, compilar tres versiones de las librerias en función de la precisión de coma flotante requerida (¡toma ya! el archivo INSTALL de fftw no decia nada al respecto). Menos mal que lo encontre en el script de instalación de slackbuilds para fftw. Dicha información también la podemos encontrar en el siguiente enlace:

Compilar fftw 

 

Cambio de idioma, y mapa del teclado en slackware.

Antes de comenzar, he de decir que estos cambios se pueden realizar desde el interface gráfico de forma similar a windows, pero la cuestión es cambiar el idioma por defecto del sistema. El problema que tenemos, es que aunque cambiemos el idioma del usuario administrador, cada nuevo usuario que creemos tendrá que configurar el idioma y el mapa de teclado.

Aclarado esto, vamos a castellanizar nuestro slackware (que para eso somos de Castilla x) ). Vamos a comenzar por el mapa de teclado. Para modificarlo para todos los usuarios debemos cambiarlo en el archivo de configuración del servidor X, en el que se pueden configurar, además del mapa de teclado, el tipo de ratón que utilizamos, resoluciones soportadas, tipo de monitor, etc... . Podemos utilizar el asistente xorgsetup, o editar el fichero /etc/X11/xorg.conf. Lo normal es tener siempre hecho un backup de dicho fichero por si la liamos. ¡Comenzamos!

No voy a contar como funciona el editor vi, ya que de este tema hay multitud de manuales por internet, pero con saber cambiar a modo de inserción con la "i", a modo comando con "esc", borrar con la "x", y guardar con ":wq", será suficiente para lo que necesitamos hacer en la mayoria de los ficheros de configuración. El fichero es bastante grande, buscamos el siguiente fragmento:

Son las opciones por defecto del teclado. Descomentamos (Eliminamos el caracter # del comienzo de linea) la linea que se refiere a XkdbLayout, y cambiamos "us" por "es". Tendremos lo siguiente:

Guardamos los cambios y salimos. Ya tenemos el mapa de teclado por defecto modificado para todos los usuarios. Ahora cambiemos el idioma.

Muchas aplicaciones, entre ellas algunos gestores de ventanas, consultan el valor de la variable de entorno LANG para mostrar el interface en el idioma configurado en el sistema. El valor de dicha variable se asigna en los fichero lang.csh y lang.sh contenidos en el directorio /etc/profile.d/

En ambos ficheros buscaremos la linea descomentada donde se asigna el valor y lo modificaremos por "es_ES".

Una vez hecho el cambio en ambos ficheros, la proxima vez que iniciemos el equipo, las variables tendrán el nuevo valor asignado. Si queremos efectuar los cambios, modificamos el valor de la variable asignandoselo desde el shell, poniendo "LANG=es_ES".

Con esto ya tenemos "castellanizado" el sistema.

Instalación de linux slackware.

A continuación dejo el manual de instalación de linux slackware. Este es el primer paso para realizar el esquema de aula docente descrito en un post anterior . Linux slackware será el sistema operativo base en todos los equipos, y la idea es preparar un equipo para dicho proposito y después clonarlo en todo el aula. El proceso de instalación es demasiado largo para exponerlo en un solo articulo, asi que he realizado una presentación bastante detallada. Poco a poco ire añadiendo más articulos con los pasos de configuración del sistema, e instalación de aplicaciones necesarias.

Instalacion slackware

View more presentations from Alfonso.

P.D.: al subirla a slidshare, hay varias cosas del formato de la presentación original que se han perdido. Esta visto que slideshare convierte peor los odp que los ppt.

Configuración de red.

Vamos a ver como configurar una conexión LAN de forma estática. Los datos que necesitamos saber para poder configurar la conexión son:
- Red en la que nos encontramos, y la dirección IP que corresponde a nuestro equipo.
- Dirección IP de la puerta de enlace predeterminada.
- Dirección IP de al menos un servidor DNS.

Una vez que tenemos estos datos tenemos tres maneras de poder configurar el equipo:
- Con la herramienta netconfig
- A mano. (La configuración dura hasta que el equipo se reinicie).
- Modificando los ficheros de configuración de conexiones de red.

La primera es muy sencilla, de modo que aqui solo trataremos la segunda y la tercera. Comencemos por la segunda realizando un ejemplo práctico.
Imaginemos el siguiente escenario: nos encontramos con nuestro ordenador portatil en un aula con conexión a internet y sin servidor dhcp, se nos indica que la red es la 192.168.0.0/24, la dirección para nuestro equipo es la 192.168.0.57, la puerta de enlace predeterminada y el servidor dns es 192.168.0.1. Esta conexión la vamos a usar solo de manera puntual, por lo que vamos a configurarla de forma manual para poder utilizarla en el momento.
Lo primero que debemos hacer es asignar la dirección ip y la mascara de red al interface de red local de nuestro equipo. Para ello lo primero que necesitamos saber es con que nombre esta identificado dicho interface, para ello ejecutamos el comando

ifconfig
Si solo muestra el interface de loopback, es posible que el sistema haya detectado la tarjeta de red pero esta se encuentre desactivada. En ese caso ejecutaremos el comando

ifconfig -a.




Vemos que el interface que queremos configurar se llama eth0. Lo primero que debemos hacer es activarlo, para ello ejecutamos el comando
ifconfig eth0 up
A continuación indicaremos al equipo su dirección IP y su mascara de subred con el siguiente comando:

ifconfig eth0 192.168.0.57 netmask 255.255.255.0




En este momento ya podriamos comprobar que estamos en la red local haciendo ping a cualquier equipo que se encuentre encendido en la misma red. Pero todavia no podemos acceder a internet, ya que nos falta una puerta de enlace predeterminada y la ip de un servidor dns.
La puerta de enlace predeterminada se configura en la tabla de rutas de nuestro equipo. Para mostrar la tabla de rutas ejecutamos el comanto

route -n

Observamos como no tenemos ninguna puerta de enlace predeterminada configurada. Para añadirla ejecutamos:

route add default gw 192.168.0.1



Ya tenemos terminada la configuración del equipo para poder salir a internet, solo necesitamos añadir un servidor de DNS. Para ello editamos el archivo /etc/resolv.conf y añadimos la siguiente linea:
nameserver ipservidordns

donde ipservidordns es la dirección ip de un servidor dns, como por ejemplo: 80.58.0.33.





Si queremos realizar una configuración de red permanente (tercera opción), editaremos el fichero /etc/rc.d/rc.inet1.conf. Parte de su contenido se mustra en la siguiente imagen.



A continuación, editaremos los campos correspondientes al interface de red que queremos configurar, en nuestro caso eth0. Asignaremos la dirección ip, la mascara de subred, y la puerta de enlace predeterminado. El fichero, según la configuración de nuestro ejemplo, quedara de la siguiente manera:




Tras modificar estos parametros en el fichero, salimos guardando los cambios.

A partir de ahora cuando arranquemos el equipo, el interface de red eth0 se configurara con los parámetros que hemos indicado en el fichero, pero para configurarlo en la sesión actual, ejecutaremos el siguiente comando:

/etc/rc.d/rc.inet1 restart

El servidor dns se sigue configurando en el mismo fichero que en el caso anterior.