lunes, 26 de abril de 2010

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.
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.

martes, 20 de abril de 2010

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:


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¡

miércoles, 7 de abril de 2010



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

sábado, 3 de abril de 2010

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.