Archivo de la Categoría “utilidades”

    Como en cada inicio de curso, desde la EPS os queremos recordar una serie de datos importantes para el uso y utilización de los eServices y, en especial, de los laboratorios en los que realizaréis las prácticas. En dichas páginas podréis ver los servicios disponibles, y la información sobre el hardware y software de los laboratorios, así como las normas de uso de los mismos que se deben cumplir.

    Los laboratorios de la EPS tienen instalada la versión de 64bits tanto de Ubuntu 16.04 como de Windows 10 (excepto en la L03, cuyos equipos son iMac). Tanto los Windows como los Mac OS estarán “congelados”. ¿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 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, nuestro canal Youtube, Twitter, Telegram y, por supuesto, este blog.

    ¡Que tengáis buen curso!

    Comments No Hay Comentarios »

    Con el comienzo del nuevo curso académico 2018/19, las nuevas peticiones de software de los laboratorios (con nuevas aplicaciones y/o nuevas versiones de programas del curso pasado), procede actualizar el fichero VDI asociado a la máquina virtual del curso anterior:

    Virtual Ubuntu EPS 2017 (VDI)

    Al nuevo virtual le llamaremos Virtual Ubuntu EPS 2018.

    Para la obtención del mismo, tendremos que realizar su descarga accediendo a esta URL (nos pedirá previamente, aceptar el certificado y luego introducir el usuario y contraseña de la EPS):

    https://maktub.eps.ua.es/ubuntuepsvirtual/Ubuntu-VDI-EPS-16_04-2018.vdi

    Desde ella, pincharemos en el enlace que aparece para proceder a la descarga del fichero Ubuntu-VDI-EPS-16_04-2018.vdi

    El archivo ocupa alrededor de 36 GB. Es decir, donde descarguemos el mismo, hemos de estar seguros de disponer de algo más de ese tamaño (preferiblemente unos 40 GB). La duración de la descarga dependerá de la conexión a Internet que tengamos. Con una conexión relativamente modesta, en menos de 2 horas debería estar descargado.

    Sigue estando basado en Ubuntu 16.04 LTS x86_64 (64 bits) pero con las actualizaciones pertinentes y añadiendo los nuevos programas y versiones del nuevo curso.

    Al arrancar, en esta ocasión ofrece: bien en modo ventana o bien en pantalla completa (recomendado este último pues, de otra forma, muchos iconos del Escritorio, no se verán bien).

    La nueva imagen del Escritorio es ésta:

     

    Cambios realizados y listado de SW nuevo

    El SW que aparece en esta máquina virtual es, en un 95%, el que hay para GNU/Linux en los laboratorios de la EPS (entre los de Politécnica I, Politécnica IV, laboratorio LTV, laboratorio LELEC y laboratorio LROB1).

    El que no sea el 100% atiende a razones de no generar problemas entre ciertas librerías y programas muy particulares pero, sobre todo, a que hay aplicaciones que tienen sentido en los laboratorios pero que en un uso en casa (o fuera de los laboratorios de la EPS), no tienen mucha utilidad, por ejemplo iTalc o máquinas virtuales que sí existen en los laboratorios pero que ponerlas, a su vez, dentro de otro virtual, además de cargar demasiado éste, se ejecutarían muy ralentizadas, y tampoco tiene mucho sentido (pues pueden funcionar, de manera independiente, en cualquier arquitectura nativa de GNU/Linux, Windows y Macintosh que tenga instalada la plataforma VirtualBox).

    La lista de programas y librerías nuevos (añadidos a otros del curso pasado), sería la siguiente:

    • adobe-air
    • appinventor2-setup-2.3
    • blender-2.76
    • cryptsetup-bin
    • Eclipse Java 4.7 Oxygen (versión no JEE)
    • Eclipse JEE 4.8 Photon
    • exfat, fuse-utils-1.2.3-1
    • firefox-63.0.1
    • gcc-5.4.0, g++-5.4.0
    • gcc-msp430
    • gitkraken
    • go 1.7.4
    • google-chrome-stable-69.0.3497.100
    • ipython-2.4.1-1
    • kernel 4.4.0-98-generic-x86_64 (vmlinuz-4.4.0-98-generic , initrd-4.4.0-98-generic)
    • libsqlite3-dev-3.11.0
    • meson-0.29
    • memtester-4.3.0-3
    • monodevelop, nunit-5.10.0.871-2
    • ninja-1.5.1
    • node-8.11.1
    • nodemon-1.18.4
    • npm-5.8.0, angular_cli-6.0.0
    • npm-6.4.1
    • obs-studio-20.1.0
    • opencv-3.4.3 (+ dependencias asociadas)
    • octave-4.0.0 (icono de Escritorio)
    • qemu-2.5.0
    • qtcreator
    • qt5-default
    • scratch-2-offline-i386
    • smartmontools-6.4
    • swift-3.1
    • sysbench-0.4.12
    • vim-gtk
    • vlc-2.2.2-5
    • xmpi-2.2.3b8-13.2

    Otros programas que por razones de insuficiente soporte gráfico (memoria y capacidad de procesamiento) y la falta de aceleración 3D de la máquina virtual, NO se incluyen son:

    • nvidia-cuda-toolkit
    • ROS Kinetic

    Particularidades de algunos programas:

    • google-chrome-stable-69.0.3497.100:  Al arrancar, nos pedirá con un cuadro un usuario y contraseña en un asunto relacionado con el almacén de claves de sesión. Pasa también en los laboratorios de la EPS. Dándole 3 veces a cancelar (pues saldrá hasta 3 veces), se soluciona y se puede continuar funcionando normalmente con el navegador.

    Aspectos a tener en cuenta para la puesta en marcha de la máquina virtual

    Básicamente, son los mismos que para el VDI del curso anterior:

    • Habilitar el bit de virtualización en la BIOS del equipo anfitrión
    • Configuración HW similar con estas particularidades:
      • Arranque sólo disco duro (ni red ni CD).
      • (2048 MB de RAM o, si se añade más, mejor)
      • Si utilizamos la versión 5.0 (o superior)  de VirtualBox , podremos habilitar soporte para USB 3.0 (xHCI) creando, en el apartado USB, un filtro vacío para admitir dispositivos USB 3.0.
    • Instalar Oracle VM VirtualBox Extension Pack (si no lo teníamos ya instalado en nuestra versión instalada de VirtualBox).
    • Instalar las Guest Additions en la máquina virtual para nuestra misma versión de VirtualBox que tengamos instalada (es decir, si el año pasado teníamos la 5.1.26 y este año tenemos la 5.1.38, deberíamos de instalar la de la 5.1.38). Esto ya se explicaba en este mismo apartado para el Virtual Ubuntu EPS 2017.

     

    Comments No Hay Comentarios »

    Empezamos un nuevo curso en la Escuela Politécnica y, como siempre (aquí tenéis las entradas de otros cursos: I, II, III,IV, V y VI), 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 la primera semana de septiembre hemos renovado los PCs de los laboratorios L13, L14, L15, L16 y L18. Estos nuevos PCs, como en el resto de laboratorios de la EPS, tienen instalado la versión de 64bits tanto de Ubuntu 16.04 como Windows 10, (excepto en la L03, cuyos equipos son iMac). Tanto los Windows como los Mac OS estarán “congelados”. ¿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 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 Youtube, Twitter y, por supuesto, este blog.

    ¡Que tengáis buen curso!

    Comments No Hay Comentarios »

    Continuando con nuestros playbooks de gestión de sistermas y servicios y, en concreto, con la monitorización de ellos con Nagios, vamos a ver cómo configuramos nrpe. Este es un demonio al que se conectará el servidor de Nagios para obtener el estado del servicio a comprobar.

    El playbook nrpe.yml  es el que nos permite configurar los chequeos NRPE para todos los servidores (excepto los que aparezcan en el grupo nonrpe) de manera centralizada. Como hemos indicado en todas las entradas dedicadas a Ansible, el gestionar de esta forma este servicio, nos permite realizar los cambios una sóla vez ,en lugar de realizarlo para cada servidor y con comprobación de errores sintácticos. También, además, es posible modificar sólo un servidor o un grupo, con el parámetro –limit nombreServidor o nombreGrupo.

    Lee el resto de esta entrada »

    Comments No Hay Comentarios »

    Como comentábamos en la entrada anterior, utilizamos varias herramientas de monitorización cuya configuración hemos automatizado con Ansible. Además de Munin, también monitorizamos nuestros servicios con Nagios (aquí y aquí explicamos un poco de este software de monitorización) para el que hemos desarrollado dos playbooks: nagios.yml y nrpe.yml, con los que realizamos la configuración de este servicio de monitorización en todos los servidores donde se ejecuta dicho software de monitorización y para los monitorizar los servidores que lo consideremos (normalmente, todos).

    Como en todos los playbooks de AnsibleEPS para nuestra infraestructura, este nos permite realizar de manera centralizada, para todos los servidores que realizan el servicio, las tareas de configuración asociadas a él,  realizándose los cambios una sola vez (en lugar de realizarlo para cada servidor) y, antes de ejecutarlo en cada servidor, comprueba la sintaxis, avisando de errores producidos si es el caso (aunque para estos playbooks no se vuelve a la versión anterior).

    En esta entrada vamos a ver el primero de los playbooks:nagios.yml, el encargado de configurar el/los servidor(es) Nagios que tengamos en nuestra infraestructura.

    Lee el resto de esta entrada »

    Comments No Hay Comentarios »

    En nuestra unidad, utilizamos varias herramientas de monitorización libres cuya configuración automatizamos con Ansible. Uno de ellos es Munin (para quien quiera conocer más sobre Munin, aquí tiene una guía de inicio). En esta entrada, vamos a ver cómo funciona y cómo podemos configurar el playbook de AnsibleEPS para Munin.

    Como en todos los playbooks de AnsibleEPS para nuestra infraestructura, este nos permite realizar de manera centralizada, para todos los servidores que realizan el servicio, las tareas de configuración asociadas a él. En el caso de Munin: la configuración de la lista de clientes munin.

    Lo primero que debemos tener en cuenta es que el playbook common.yml se encarga (entre otras muchas tareas: más información sobre este playbook aquí) de instalar y configurar el software de los clientes (munin-node). Además permitirá el acceso desde los servidores del grupo munin.

    ¿Cómo se realizan los cambios para Munin? Mediante  el fichero situado en roles/munin/templates/etc/munin/conf.d/hosts.j2  Dicho template no es mas que el fichero de configuración hosts del servidor Munin con la lista de clientes munin. El template obtiene todos los equipos del inventario excepto los del grupo nomunin y los introduce en la lista. Si queremos tener otros clientes munin que no se encuentren en el inventario, se creará a mano un fichero con la lista dentro del mismo directorio (ya existe un fichero así llamado hosts-outsiders).

    La ejecución del playbook se realiza con la orden:  ansible-playbook munin.yml que afectará a todos los servidores incluidos en el grupo munin. Tras la ejecución de esta orden, tendríamos configurado en los servidores del grupo munin la recolección de datos de todos nuestros servidores excepto de aquellos que hayamos incluido en el grupo nomunin.

    Si queremos que todo sea automático (hasta la inclusión de los servidores) disponemos de una aplicación de monitorización genérica que llamamos EPS-MS (el software está en Github) que descubre todos los servidores de la red que le indiquemos. Así, la diferencia entre ambos es que, mientras con EPS-MS los servidores se localizan automáticamente por la aplicación, en  AnsibleEPS los servidores los introduce el administrador en el inventario pero el resultado es que tendremos nuestro servidor/servidores de Munin monitorizando los servidores de nuestra infraestructura de los que necesitemos tener información (para nosotros, todos 😉 ).

    ¡Esperamos que os sea útil!

    Comments 2 Comentarios »

    En esta entrada vamos a ver cómo automatizar con Ansible información básica de servidores como la gestión de usuarios, grupos, etc (ver tabla 1). Todas estas tareas, en nuestro ejemplo, se realiza con el playbook common. common.yml se encarga de realizar la configuración básica de todos los servidores (excepto los que aparezcan en el grupo nocommon) de manera centralizada y, además, de poder realizar estos cambios de una sóla vez (en lugar de realizarlo para cada servidor, aunque también es posible modificar sólo un servidor o un grupo, con el parámetro –limit nombreServidor o nombreGrupo). De las tareas a realizar se encargan los ficheros de la tabla 1.

    Tarea Descripción
    manager.yml Gestión del usuario manager. Comprueba su existencia y lo crea y añade a grupos específicos (variable managerGroups), si es necesario.
    group.yml Gestión de grupos. Añade grupos de trabajo y los configura con los usuarios de la variable groupRoot
    repos.yml Gestión de los repositorios Con reposUpdate=y añadirá los repos necesarios para el sistema
    dselect.yml Instalación de dselect (en debian)
    concurrency.yml Asignación de concurrency=NONE (en debian)
    services.yml  Parada de servicios no requeridos indicados por la variable stopServices
    resolv.yml Gestión del cliente DNS /etc/resolv.conf para añadir el valor de domain, search y nameserver, usando respectivamente, las variables domain, search y nameservers.
    nscd.yml Instalación y configuración del servicio NSCD
    securetty.yml Gestión de los permisos de acceso /etc/securetty a partir del fichero estático files/etc/securetty
    locales.yml Gestión de las locales. Configura el fichero apropiado a cada distribución a partir de ficheros estáticos situados dentro de files/etc
    profile.yml Gestión del profile general /etc/profile según la variable profileEtc
    nvi.yml Instalación de nvi y configuración por defecto como vi
    utils.yml Instalación de software adicional
    pam-ldap.yml Instalación y configuración de las PAM con LDAP a partir de templates situados en el directorio templates/etc/ y las variables ldapA, ldapB y ldapC que indican 3 servidores LDAP diferentes
    syslog.yml Configuración del envío de logs a servidores remotos utilizando la variable syslog
    sshd.yml Configuración del servicio sshd usando la variable sshdConfig y sus atributos: permitRootLogin, clienteAliveInterval, clientAliveCountMax, matchGroup, logLvel y subsystemSftp.
    ntp.yml Instalación y configuración del servicio NTP
    muni-node.yml Instalación y configuración del cliente Munin-Node utilizando la variable muninMaster para indicar la lista de IPs de los servidores maestros de Munin.
    nrpe.yml  Instalación y configuración del cliente Nagios-NRPE, configurando /etc/hosts.allow a partir de la variable nagiosMaster
    bacula-df.yml  Instalación y configuración del cliente Bacula-FD a partir del template templates/etc/bacula/bacula.conf.XX.j2 y /etc/hosts.allow a partir de la variable baculaMaster
    ossec.yml  Instalación y configuración del cliente Ossec utilizando la variable ossecMaster y el template templates/var/ossec/etc/ossec.conf.XX.j2

    Tabla 1.- Lista de tareas del playbook common

    Los cambios se realizan modificando las variables apropiadas que, a través de las tareas correspondientes, terminarán realizando las operaciones necesarias para cumplir su función. Las variables para todas las tareas se declaran principalmente en el fichero general group_vars/all, aunque se pueden sobreescribir los valores en los ficheros de grupo o de host, según las necesidades específicas de cada servidor. Así mismo, si las variables dependen de la distribución, pueden estar declaradas en los ficheros específicos de cada distribución y versión.

    ¡Esperamos que os sea útil!

    Comments 1 Comentario »

    Con el comienzo del nuevo curso académico 2017/18, las nuevas peticiones de software de los laboratorios (con nuevas aplicaciones y/o nuevas versiones de programas del curso pasado), procede actualizar el fichero VDI asociado a la máquina virtual del curso anterior:

    Virtual Ubuntu EPS 2016 (VDI) (y 2)

    Al nuevo virtual le llamaremos Virtual Ubuntu EPS 2017.

    Para la obtención del mismo, tendremos que realizar su descarga accediendo a esta URL (nos pedirá previamente, aceptar el certificado y luego introducir el usuario y contraseña de la EPS):

    https://maktub.eps.ua.es/ubuntuepsvirtual/Ubuntu-VDI-EPS-16_04-2017.vdi

    Desde ella, pincharemos en el enlace que aparece para proceder a la descarga del fichero Ubuntu-VDI-EPS-16_04-2017.vdi

    El archivo ocupa 25.8 GB. Es decir, donde descarguemos el mismo, hemos de estar seguros de disponer de algo más de esos casi 26 GB. La duración de la descarga dependerá de la conexión a Internet que tengamos. Con una conexión relativamente modesta, en poco más de 1 hora debería estar descargado.

    Sigue estando basado en Ubuntu 16.04 LTS x86_64 (64 bits) pero con las actualizaciones pertinentes (en él hemos eliminado programas que ya no se han solicitado, versiones obsoletas y añadido programas y versiones nuevas acorde con el nuevo curso que comienza).

    La nueva imagen del Escritorio es ésta:

    Escritorio de VDI Ubuntu EPS 2017 (Ubuntu 16.04 LTS x86_64)

     

    Cambios realizados y listado de SW

    El SW que aparece en esta máquina virtual es, en un 90%, el que hay para GNU/Linux en los laboratorios de la EPS (entre los de Politécnica I, Politécnica IV, laboratorio LTV, laboratorio LELEC y laboratorio LROB1).

    El que sea un 90% atiende a razones de no generar problemas entre ciertas librerías y programas muy particulares pero, sobre todo, a que hay aplicaciones que tienen sentido en los laboratorios pero que en un uso en casa (o fuera de los laboratorios de la EPS), no tienen mucho sentido, por ejemplo iTalc o máquinas virtuales que sí existen en los laboratorios pero que ponerlas, a su vez, dentro de otro virtual, además de cargar demasiado éste, se ejecutarían muy ralentizadas, y tampoco tiene mucho sentido (pues pueden funcionar, de manera independiente, en cualquier arquitectura nativa de GNU/Linux, Windows y Macintosh que tenga instalada la plataforma VirtualBox).

    La lista (resumida) de programas y librerías, sería la siguiente:

    • ansible-2.0.0.2
    • atom-1.18.0-1
    • bison++-1.21.11-3.1
    • bower-1.8.0
    • caffe-master (1.0.0)
    • cmake-3.5-1
    • composer
    • docker-ce-17.06.0
    • docker-compose-1.15.0
    • Eclipse C++ 4.6 Neon, Eclipse C++ 4.7 Oxygen
    • Eclipse JEE 4.6 Neon, Eclipse JEE 4.7 Oxygen
    • firefox-47.0
    • flex-2.6.0
    • freeglut3 (2.8.1-2), freeglut3-dev (2.8.1-2)
    • gawk-4.1.3
    • gcc-5.3.1, g++-5.3.1
    • gulp-cli
    • g++-arm-linux-gnueabihf, gcc-arm-linux-gnueabihf, gdb-multiarch, pip matplotlib
    • heroku-6.13.1
    • JDK-1.8.0 Update 131, JDK-1.8.0 Update 131 APIDocs
    • jhipster-4.6.2
    • joe-4.1-2
    • laravel-5.4
    • libasound2-dev-doc-1.1.0
    • libsfml-dev-2.3.2
    • libsvm-3.22
    • make-4.1-6
    • MySQL-Server-5.7.11, MySQL-Common-5.7.11, MySQL-Connector-Java-CPP-Python
    • Netbeans-8.2
    • nlwrap-0.41
    • nodejs-4.8.4, nodejs-6.9.4, nodejs-legacy-4.2.6
    • npm-2.15.11, npm-3.10.10
    • opencv-3.3 (+ dependencias asociadas)
    • php7.0, php7.0-mysql
    • postman (5.2.1)
    • robo3t-1.1.1
    • python-2.7.11+, python-3.5.2, python-3.6
    • qemu, qemu-system-arm, qemu-user, qemu-user-static
    • ruby-dev (2.3)
    • valgrind-3.11.0
    • VirtualBox-5.1.24-117012
    • vscode-1.15.1
    • sqlitebrowser-3.7.0-1
    • sts-3.9.0
    • sublime-text-3126-prolog
    • swi-prolog-7.2.3
    • yarn-0.27.5
    • yo (yeoman) 2.0.0

     

    Aspectos a tener en cuenta para la puesta en marcha de la máquina virtual

    Se crea de forma similar a la descrita para el VDI del curso anterior (que, de momento, mantendremos también descargable durante un tiempo). Más que sustituir la máquina del curso pasado, es recomendable mantener aquélla y, para la de este curso, crear una máquina virtual totalmente nueva.

    – Habilitar bit de Virtualización en la BIOS:

    Muchos portátiles y PCs, tienen deshabilitado, por defecto, en la BIOS, el bit de Virtualización (VTx). Es fundamental que esté HABILITADO (Enabled) pues, de lo contrario, aunque podamos instalar la plataforma VirtualBox en nuestro equipo, al intentar lanzar cualquier máquina virtual, nos dará un error.

     

    – Configuración al crear la máquina virtual  (a tener muy en cuenta):

    • Memoria RAM: mínimo 2048MB.
    • Memoria de vídeo: 128 MB.
    • NO habilitar la aceleración 3D (ya que ello provocaría que los paquetes de OpenGL instalados no funcionaran bien y que programas como Postman no funcionaran correctamente).
    • NO habilitar la aceleración 2D.

     

    – Instalar Oracle VM VirtualBox Extension Pack:

    Cuando instalemos la plataforma VirtualBox (actualmente en su versión 5.1.28 y descargable desde la página https://www.virtualbox.org/wiki/Downloads), no debemos olvidar, una vez instalado, descargar el paquete de extensiones Oracle VM VirtualBox Extension Pack. Una vez descargado, abriremos la plataforma VirtualBox, iremos al menú Archivo -> Preferencias -> Extensiones y añadiremos a la plataforma el fichero con extensión vbox-extpack.

    Sin estas extensiones, no podremos conectar ni hacer attach de dispositivos USB a mayor velocidad que marca el estándar 1.1 (muy poco actualmente, donde lo normal son dispositivos estándar 2.0 y, sobre todo, 3.0).

    Instalación de Oracle VM VirtualBox Extension Pack

     

    – Instalar las Guest Additions en la máquina virtual:

    Una vez lancemos el virtual y éste esté funcionando, si la versión de VirtualBox nuestra no coincide con la de las Guest Additions del VDI, tendremos que instalar las Guest Additions de nuestra versión de VirtualBox (en dicho VDI).

    Para ello, ya con el virtual arrancado y viendo el escritorio de Ubuntu, iremos al menú Dispositivos de la ventana de VirtualBox y seleccionaremos la opción de más abajo donde pone “Imagen CD Guest Additions“. Con esto, haremos attach de dicha imagen al VDI (como si metiéramos un CD físico en la unidad de CD de la máquina virtual) y podremos proceder a instalar las citadas Additions en el virtual.

    Podremos funcionar sin las Additions, pero el funcionamiento del virtual no será tan bueno y la fluidez de paso del foco de ratón y el teclado entre el virtual y el anfitrión y viceversa, será bastante menos eficiente.

    Dicha instalación puede realizarse de forma gráfica desde el citado menú, para lo cual se nos solicitará la contraseña de root (que es “alu” sin las comillas) y seguiremos los pasos pertinentes:

    Añadir Guest Additions método GUI

    O bien, también es posible realizarlo desde una terminal de root (accesible con el comando sudo su y poniendo la contraseña alu) siempre que antes hayamos hecho attach del CD desde el menú Dispositivos del virtual.

    Una vez alcanzada la terminal de root ejecutaremos estos comandos:

    # cd /media/alu/VBOXADDITIONS_5.1.26_117224

    # ./VBoxLinuxAdditions.run

    Ejecutar VBoxLinuxAdditions.run desde terminal de texto

    Ejecución de VBoxLinuxAdditions.run desde terminal de texto

    Ejecutada la instalación de las Guest Additions desde terminal de texto

     

    Comments No Hay Comentarios »

    En la administración de sistemas y servicios existen muchas tareas repetitivas y periódicas cuya ejecución programamos haciendo uso del crontab. Muchas de estas, como las copias de seguridad, debemos hacerla en todos y cada uno de los servidores que administramos. Dentro de la gestión automatizada de la infraestructura IT de la EPS hemos automatizado esta tarea (la de programar tareas del cron) con el playbook crontab.yml (no se debe confundir con programar las tareas de Ansible que vimos en esta entrada)

    Este playbook permite realizar la configuración de las tareas de cualquier usuario para cualquiera de los servidores (excepto los que aparezcan en el grupo nocrontab) de manera centralizada y, además de poder realizar los cambios una sola vez (en lugar de realizarlo para cada servidor) también es posible modificar solo un servidor o un grupo (utilizando el parámetro –limit nombreServidor o nombreGrupo).

    La información de este playbook reside en el fichero crontab.yml y tiene la siguiente estructura:

    Lee el resto de esta entrada »

    Comments 1 Comentario »

    Como vimos en el primer post dedicado a la gestión automatizada de infraestructua IT de la EPS disponemos de una colección de playbooks de Ansible que se encargan, cada uno de ellos, de realizar una serie de tareas concretas (sobre 1, todos o cualquier subconjunto de servidores). La ejecución de estos playbooks se realiza periódicamente para lo cual necesitaremos añadir las tareas al cron del servidor Ansible que gestiona la infraestructura (ver este ejemplo de infraestructura).
    En este post vamos explicar cómo realizamos esta tarea con Ansible y que, para nuestro ejemplo, será el playbook cron.

    Lee el resto de esta entrada »

    Comments 1 Comentario »