Empezamos un nuevo curso en la Escuela Politécnica y, como siempre (aquí tenéis las entradas de otros cursos: I, II, III,IV y V), os queremos recordar los datos importantes y necesarios para el uso y utilización de los eServices y, en especial, de las prácticas que realizáis en los laboratorios de la EPS.

    Sobre los laboratorios que gestionamos tenéis información en esta página: dónde está, su horario y ocupación, características hardware tienen, normas de uso, software instalado,…

    Durante esta primera semana de septiembre hemos renovado los iMacs del laboratorio L03 y los PCs de los laboratorios L23, L25, L28, L027I, L028I, L029I, L030I, LS13I, LS14I y Laboratorio Acceso Libre. Estos nuevos PCs tienen instalado la versión de 64bits tanto de Ubuntu 16.04 (hemos actualizado la 12.04 usada el anterior curso) como Windows 10 (tendremos 2 versiones de Windows en nuestros laboratorios: en todos estará W10, excepto en los laboratorios L13, L14, L15, L16 y L18 que tendremos W7). Ambas versiones estarán “congeladas”. ¿Qué significa esto y en qué te puede afectar? Aquí la respuesta.

    Para utilizar los eServices así como para acceder a los PCs de prácticas de los laboratorios (al principio no será necesario en los Windows, pero lo iremos instalando a lo largo del curso) necesitáis vuestro usuario y contraseña de la EPS, y  éste NO ES el que habéis utilizado en el Campus Virtual para la matriculación en la UA. Si necesitáis ayuda, esta página os proporcionará más información sobre los usuarios de la EPS. Un detalle que queremos remarcar es que si usáis otro correo distinto al que os proporciona la UA (gmail, hotmail,…) tenéis la opción de redirigir el de la UA al que uséis ya que toda las comunicaciones institucionales se os enviarán a vuestro correo UA.

    Por último, queremos recordaros que tenéis disponible:

    Si tenéis dudas o consultas, podéis encontrar información para resolverlas y de contacto con los técnicos de la EPS aquí, además de poder usas nuestros canales en  Facebook,  Google +,  nuestro canal YoutubeTwitter  y, por supuesto, este blog.

    ¡Que tengáis buen curso!

    Comments No Hay Comentarios »

    En una entrada anterior ya explicamos brevemente el funcionamiento de Nagios para monitorizar el estado de nuestros servidores y servicios, y recibir alertas ante cualquier problema detectado.

    También hablamos del software NRPE (Nagios Remote Plugin Executor) que complementaba el uso de Nagios para poder realizar los chequeos internamente. Es decir, Nagios no sólo comprueba el servicio desde fuera (conectándose al servicio), sino que puede conectarse al software NRPE del servidor chequeado, y una vez dentro realiza comprobaciones internas utilizando cualquier lenguaje de programación o scripting.

    Utilizando estas dos herramientas tenemos un completo sistema de monitorización que nos avisa casi inmediatamente de cualquier error que se produzca. De esta manera reducimos los tiempos de caída de nuestros servicios, al detectar los problemas con mayor rapidez.

    Además, con Nagios, podemos ir un poco más allá y configurarlo de tal manera que sea el propio Nagios (con ayuda de NRPE) el que responda automáticamente ante un problema de un servicio, y esté programado para resolverlo inmediatamente de manera desatendida.

    Lee el resto de esta entrada »

    Comments No Hay Comentarios »

    En un post anterior de este blog, Programas básicos para el curso 2016-2017, se enumeraban los programas básicos de cara al próximo curso 2016/17 y también anteriormente se envió un correo electrónico de aviso al profesorado de la UA indicando el plazo para realizar las peticiones de instalación de programas para la docencia en las asignaturas del curso 2016/17. Lo reproducimos a continuación:

    “INSTALACION DE SOFTWARE DOCENTE EN AULAS/LABORATORIOS DE INFORMÁTICA DE LA UNIVERSIDAD DE ALICANTE

    Desde el Vicerrectorado de Tecnologías de la Información queremos recordaros la importancia de planificar con tiempo la instalación de los programas docentes en los ordenadores de las aulas de informática.

    El plazo para realizar las peticiones de instalación de software docente en asignaturas que se desarrollen en el primer cuatrimestre del curso 2016-2017, concluye el 1 de julio de 2016.

    Os informamos que existe un protocolo establecido para la solicitud de instalación del software docente en estas páginas web:

    http://si.ua.es/es/servicios/aulas/solicitud-para-la-instalacion-de-software.html, para las aulas gestionadas por el Servicio de Informática.

    http://www.eps.ua.es/softwarelabs, para los laboratorios gestionados por la Escuela Politécnica Superior.

    Os recordamos que solamente se instalará el software que haya sido solicitado explícitamente y del cual se disponga de la licencia necesaria. En la dirección http://si.ua.es/es/programas/programas-para-docencia-en-aulas-de-informatica.html puede encontrarse la relación de software docente con actualización de licencias por parte de la Universidad de Alicante y, por tanto, que puede ser instalado en las aulas de informática para su uso docente.

    De igual forma solicito vuestra colaboración en este proceso, dado que tener instalado en las aulas programas que no vayan a ser utilizados perjudica a todos los usuarios, ya que se ralentiza considerablemente el funcionamiento de los ordenadores.

    Un cordial saludo,

    Francisco Maciá Pérez

    Vicerrector de Tecnologías de la Información”

    Comments No Hay Comentarios »

    Ya estamos preparando el software que se va a instalar en los laboratorios de la Escuela Politécnica Superior para la docencia del próximo curso 2016/17. En la aplicación web de petición de software para el curso 2016/17 aparecen una serie de programas básicos para el curso 2016/17 que han sido consensuados con el Servicio de Informática de la UA y que reproducimos a continuación:

    Compatibilidad software

    Comments No Hay Comentarios »

    Uno de los principales problemas que se encuentran nuestros estudiantes a la hora de matricularse en alguno de los grados o másteres que ofrece la EPS (a excepción de los alumnos de primer curso) son los solapes en su horario. Esto se debe a que, en ocasiones, el alumno tiene asignaturas de varios cursos diferentes, cada una de ellas con varias actividades. Para que os hagáis una idea, en el curso 2015-16 hay 3851 alumnos matriculados en algún grado o máster; de estos alumnos, 1235 estudiantes tuvieron algún solape en su horario, con un total de 4237 solapes (sale una media de 3,4 solapes por alumno).

    Con el objetivo de ayudar al alumno a resolver sus solapes, en el curso 2014-15 pusimos en marcha una aplicación para detectar y solucionar los solapes en su horario. Aquí tienes un enlace al procedimiento completo de la Gestión de solapes.

    Lee el resto de esta entrada »

    Comments No Hay Comentarios »

    Como ya comentábamos en una entrada anterior sobre Munin, podemos personalizar las gráficas de Munin creándolas según nuestras necesidades; es realmente sencillo, pudiendo utilizar cualquier lenguaje de scripting o programación para generarlas.

    Como ejemplo usaremos un script hecho en bash para la generación de una gráfica que nos muestre la cantidad de procesos stunnel (software para el cifrado de comunicaciones) en un momento dado, y la cantidad de conexiones que tenemos al puerto 636 (utilizamos stunnel para cifrar las comunicaciones mediante este puerto) en un servidor con GNU/Linux.

    La programación de las gráficas se componen de dos partes bien diferenciadas: una primera que genera el formato de la gráfica, y una segunda para la obtención de los valores a mostrar.

    (1) Formato de la gráfica

    Sirve para definir cómo vamos a mostrar los datos, tipos de gráfica, medidas, etc

    Una posible configuración podría ser:

    if [ “$1” = “config” ]; then

            echo ‘graph_title Stunnel4’
            echo ‘graph_args –base 1000 -l 0’
            echo ‘graph_vlabel procesos y conexiones Stunnel4’
            echo ‘graph_category Stunnel’
            echo ‘procesos.label Procesos stunnel’
            echo ‘procesos.draw LINE2’
            echo ‘procesos.min 0’
            echo ‘procesos.warning 100’
            echo ‘procesos.critical 200’
            echo ‘conexiones.label Conexiones stunnel’
            echo ‘conexiones.min 0’
            echo ‘conexiones.draw LINE2’
            echo ‘conexiones.warning 150’
            echo ‘conexiones.critical 250’
            exit 0

    fi

    La primera parte define el formato general de la gráfica:

    • graph_title define el título de la gráfica como ‘Stunnel4’
    • graph_args define la escala en base 1000 y configura el límite menor en 0 (si no se especifican los límites, estos serán configurados dinámicamente por munin según los valores a mostrar)
    • graph_vlabel define la etiqueta vertical (situada a la izquierda de la gráfica) como ‘procesos y conexiones Stunnel4’
    • graph_category define la categoría (las gráficas se agrupan en categorías a las que se puede acceder directamente desde un enlace en la página general)

    La parte final configura el formato con el que se mostrarán cada uno de los conjuntos de valores, en este caso el que corresponde a los procesos y las conexiones:

    • procesos.label define la etiqueta que tendrá la leyenda bajo la gráfica para los datos de procesos
    • procesos.draw define el formato de representación (líneas, áreas, etc.) de los datos de procesos como ‘LINE2’ (se corresponde a una línea de un grosor medio)
    • procesos.min define el valor mínimo de los datos recogidos de los procesos
    • procesos.warning define el umbral de warning de los datos recogidos de los procesos (una vez superado éste, el enlace a la gráfica desde la página general se mostrará en color amarillo)
    • procesos.critical define el umbral de error de los datos recogidos de los procesos (una vez superado éste, el enlace a la gráfica desde la página general se mostrará en color rojo)

    Estas características se definen para cada uno de los conjuntos de datos recogidos (en este caso se realizará también para los datos de conexiones).

    (2) Obtención de valores de procesos y conexiones

    Hasta ahora hemos definido la gráfica y la representación de los datos recogidos pero todavía no hemos indicado cómo vamos a obtener los datos de procesos y conexiones.

    Para obtener el número de procesos stunnel, añadiremos a nuestro script:

    echo -n “procesos.value “
    ps xau|grep “/usr/bin/stunnel”|grep -v “grep”|wc -l

    De la misma manera, para obtener el número de conexiones establecidas al puerto 636, añadiremos al script:

    echo -n “conexiones.value “
    netstat -an|grep “ESTABLISHED”|grep ESTABLISHED|tr -s ‘ ‘|cut -d’ ‘ -f4|cut -d’:’ -f2|grep ‘^636$’|wc -l

    Una vez terminado el script, lo copiaremos al directorio de los plugins ‘/usr/share/munin/plugins’ con permiso de ejecución, creamos el enlace desde ‘/etc/munin/plugins’ al fichero creado, y reiniciamos el cliente de munin: munin-node.

    La gráfica no estará disponible hasta unos minutos después (cuando el servidor Munin se conecte al equipo para recoger los datos). La gráfica que obtendremos tendrá un aspecto similar a esta:
    munin-stunnel
    Sin embargo, si queremos probarlo antes (o si hay algún problema y queremos verificar el correcto funcionamiento del plugin), realizaremos los siguientes pasos:

    (1) Primero probaremos la ejecución desde el mismo equipo para comprobar que no hay errores en la programación del plugin

    • Para probar la información de configuración de la gráfica teclearemos munin-run stunnel config
    • Para probar la obtención de valores teclearemos munin-run stunnel

    (2) Finalmente probaremos la ejecución desde el servidor Munin, ya que puede haber algún problema de falta de permisos o comunicación con el equipo

    • Dentro del servidor Munin abriremos una sesión telnet al puerto 4949 del equipo: telnet equipo 4949
    • Podemos ver la lista de plugins (nombres de los enlaces creado en ‘/etc/munin/plugins’) tecleando list
    • Obtendremos el formato de la gráfica tecleando config stunnel
    • Obtendremos los datos del plugins tecleando fetch stunnel
    • Cerraremos la conexión tecleando quit

     

    Más información sobre la personalización de los plugins en la web oficial de Munin

    Comments No Hay Comentarios »

    En ocasiones puede ocurrir que necesitemos acceder a ciertas tablas de nuestra base de datos desde una red poco segura. Por supuesto, siempre podemos crear una base de datos con las tablas replicadas que necesitemos. De esta manera podremos leer toda la información de esas tablas sin necesidad de acceder a la base de datos central.

    ¿Pero qué ocurre si además de poder leer esas tablas necesitamos insertar o actualizar datos?

    Siempre podríamos hacer una doble replicación, pero el sistema se vuelve demasiado complicado, además de de no tener toda la información ‘de primera mano’ en la base de datos central, ya que parte de la información viene ‘replicada’, con lo que no podremos replicar toda la base de datos a otro lugar (por ejemplo para tener una copia como espejo, o simplemente para balancear las lecturas entre varias bases de datos).
    No es muy aconsejable realizar una doble replicación a no ser que sea absolutamente necesario y no haya otra posibilidad.

    Pero hay otra posibilidad mucho más sencilla y elegante. Se trata de las tablas federadas, un tipo de motor de Mysql ‘FEDERATED’ en las que se crea un enlace entre la tabla ‘federada’ y la tabla principal de la base de datos central. Es por ello que esta tabla no contiene datos, sólo el enlace mencionado.

    Por ejemplo si tenemos en la base de datos central (de un servidor principal) una tabla:

    CREATE TABLE prueba (
    idTabla INT(5) NOT NULL AUTO_INCREMENT,
    dato VARCHAR(20) NOT NULL DEFAULT ”,
    PRIMARY KEY (idTabla)
    )
    ENGINE=MyISAM

    En la base de datos secundaria (de otro servidor) la tabla federada sería:

    CREATE TABLE prueba (
    idTabla INT(5) NOT NULL,
    dato VARCHAR(20) NOT NULL DEFAULT ”
    )
    ENGINE=FEDERATED
    CONNECTION=’mysql://usuario_de_conexión@IP_del_servidor:3306/base_de_datos/prueba’;

    Evidentemente, la tabla principal y la tabla federada tendrán la misma estructura, aunque la tabla federada no necesita AUTO_INCREMENT ni índices, ya que no almacena datos, sólo funciona como una interfaz.

    ¿Cómo funciona exactamente una tabla federada?

    se-federated-structure

    Imaginemos que tenemos una base de datos central en un servidor principal, y otra base de datos secundaria en otro servidor donde crearemos nuestra tabla federada. En este caso, la cadena ‘CONNECTION’ de la tabla federada apuntará a la tabla real de la base de datos central (necesitaremos un usuario de conexión que se creará en la base de datos central para tal menester).

    Cuando se lleva a cabo una operación de escritura en la tabla federada, ésta se conectará a la base de datos central, y le enviará la operación a realizar sobre la tabla real. La base de datos central realizará la operación y devolverá el resultado a la base de datos secundaria que informará al usuario.

    El uso de tablas federadas es totalmente transparente para el usuario (el funcionamiento es igual que si fuese real), y de esta manera nos permite crear bases de datos secundarias sólo con las tablas necesarias y con posibilidad de escritura.

    Más información en la web de Mysql

    Comments No Hay Comentarios »

    Un septiembre más empezamos un nuevo curso en la Escuela Politécnica y, como siempre (aquí tenéis las entradas de otros cursos: I, II, III y IV), os queremos recordar los datos importantes y necesarios para el uso y utilización de los eServices y, en especial, de las prácticas que realizáis en los laboratorios de la EPS.

    En la EPS tenemos 25 laboratorios de informática, uno de electrónica y otro de televisión y vídeo. En esta página tenéis información sobre ellos: dónde está, su horario y ocupación, características hardware tienen, normas de uso, software instalado,… Sobre los laboratorios tenemos cambios importantes:

    • Hemos  “congelado” los Windows 7. ¿Qué significa esto y en qué te puede afectar? Aquí la respuesta.
    • Tenemos problemas con el generador que nos hace de “backup” eléctrico y puede afectaros en vuestras prácticas. En cuanto esté resuelto, os avisaremos (mediante nuestras redes sociales), pero que no se os olvide guardar, periódicamente, vuestro trabajo (esta es una buena práctica que, en general, deberíais cumplir siempre, independientemente del estado de nuestra infraestructura)

    Para utilizar los eServices así como para acceder a los PCs de prácticas de los laboratorios (por ahora, en GNU/Linux), necesitáis vuestro usuario y contraseña de la EPS, y  éste NO ES el que habéis utilizado en el Campus Virtual para la matriculación en la UA. Si necesitáis ayuda, esta página os proporcionará más información sobre los usuarios de la EPS. Un detalle que queremos remarcar es que si usáis otro correo distinto al que os proporciona la UA (gmail, hotmail,…) tenéis la opción de redirigir el de la UA al que uséis ya que toda las comunicaciones institucionales se os enviarán a vuestro correo UA.

    Para quien necesite realizar sus prácticas en su PCs, tenemos:

    •  Convenio con Microsoft que permite la descarga y uso del software de Microsoft que se utiliza en prácticas (excepto Office) y que podéis instalar en vuestro PC. Este convenio se complementa con otro que hemos firmado recientemente mediante el cual nuestros alumnos y profesores tendrán acceso a la aplicaciones de trabajo de la plataforma Office 365
    •  DVD Ubuntu Live EPS donde podéis encontrar el software de GNU/Linux que se ha instalado en los laboratorios para las prácticas.

    Además, otras herramientas que, quizás, os puedan interesar son:

    Si tenéis dudas o consultas, podéis encontrar información para resolverlas y de contacto con los técnicos de la EPS aquí, además de poder usas nuestros canales en  Facebook,  Google +,  nuestro canal YoutubeTwitter  y, por supuesto, este blog.

    ¡Que tengáis buen curso!

    Comments No Hay Comentarios »

    A partir del curso académico 2015/16 en todos los ordenadores de los laboratorios de la EPS, los sistemas operativos Windows 7 de 64 bits de Microsoft y Mac OS X Yosemite de Apple estarán “congelados” por lo que al reiniciar/apagar el equipo se borrarán todos los cambios que se hayan hecho en la sesión de trabajo.

    Existe una partición en el disco duro que no estará “congelada” que se puede utilizar (¡OJO!, teniendo en cuenta que no se borrará nada de allí) aunque nuestra recomendación es utilizar medios externos para guardar las prácticas y documentos que se estén utilizando para evitar posibles pérdidas de los mismos:

    Esta “congelación” de un sistema operativo se ha estado utilizando con éxito desde 2012 en los armarios de portátiles del edificio Politécnica IV (en Windows XP), desde 2013 en los laboratorios L03 y L04 (en equipos iMac) y desde el curso pasado 2014/15 en los laboratorios L01+L02+L17+L22+L24+L26+L27+Electrónica+TV y Vídeo.

    ordenador nuevo 2cartel

    Comments No Hay Comentarios »

    Como comentamos en esta entrada, establecimos un protocolo según el cual, los cambios de distribución de GNU/Linux en los laboratorios docentes  los realizaríamos cada 3 años. Ya llevamos TRES cursos con Ubuntu 12.04; es el momento de dar el salto a una nueva versión mayor de Ubuntu que estaría disponible para el próximo curso académico 2015/16, pero no va a ser así 🙁

    Lee el resto de esta entrada »

    Comments No Hay Comentarios »