Source: https://enavas.blogspot.com.es/2014/
Timestamp: 2017-04-30 07:08:21+00:00

Document:
Algo de Linux: 2014
sed: Insertar una línea antes de un patrón determinado
En el post anterior mostrábamos un ejemplo en el que eliminábamos una línea del script /etc/rc.local para evitar la ejecución de un script en un momento determinado.
Ahora bien, puede que después de terminar la ejecución del procedimiento por el que necesitábamos cancelar la ejecución del script, nos interese volver a añadir la línea que habíamos eliminado.
En este caso, como sabemos que dicha línea debe ir justo antes del texto "exit 0", vamos a utilizar el comando sed para realice precisamente esta acción:
# sed -i '/exit 0 / i\/usr/sbin/sinc_puppet_inst &amp;\n' /etc/rc.local
sed: Borrar las líneas que contengan un patrón determinado
Una de las cosas para las que utilizo mucho el comando sed es borrar las líneas de un archivo que contienen un patrón determinado. Por ejemplo: En nuestras instalaciones tenemos un script sinc_puppet_inst que se ejecuta al final del proceso de arranque y no me interesa que este script se ejecute en una determinada situación. Podría utilizar el comando sed en un script que se inicie en uno de los runlevels para evitar la ejecución eliminando la línea y añadiéndola después cuando termine el proceso que quiero realizar.
Para eliminar la línea, podemos hacer lo siguiente:
# sed -i  '/sinc_puppet_inst/ d' /etc/rc.local
Si os dáis cuenta, lo que va entre las barras "/" es el patrón a buscar. Y "d" le indica a sed que borre las líneas que contengan el patrón.
Otro de las cosas que podemos querer borrar es bloques de texto que contengan una estructura determinada. Por ejemplo:
# sed -i '/BEGIN/,/END/ d' /boot/grub/grub.cfg
El comando anterior borraría el bloque de líneas del fichero /boot/grub/grub.cfg que comienza por la palabra BEGIN y termina con la palabra END.
Buscar un patrón con sed
Normalmente utilizamos grep para buscar patrones. Bueno, pues también podemos buscar un patrón utilizando sed. ¿Cómo? De la siguiente manera:
Con el comando anterior le estamos diciendo a sed que busque el patrón que le indicamos y lo imprima en pantalla. Y si queremos buscar todas las líneas que no contienen el patrón, tal y como haríamos con un "grep -v", lo haríamos de la siguiente manera:
sed -n '/patron/ !p'
Reparticionar el almacenamiento interno de Smartphones MTK65xx
Una cosa que no acabo de enterder de los Smartphones Chinos es por qué les montan un almacenamiento interno de 8GB, 16GB, 32GB, etc... y luego sólo dedican 1GB a la partición primaria donde se instalan las aplicaciones, dejando el resto para lo demás. Y cuando te das cuenta, estás continuamente viendo mensajes del sistema en los que te dice que el espacio de almacenamiento se ha llenado.
Una forma de solucionar este problema es utilizar la aplicación de flasheo Mediatek SP Flash Tool, que encontraréis en la siguiente página: http://mtk2000.ucoz.ru/load/soft/soft_mtk/sp_flash_tool/5-1-0-14 para modificar el tamaño de las dos particiones en las que está dividido el almacenamiento interno. Eso sí: No olvidéis hacer copia de seguridad de todo lo que tenéis almacenado antes de reparticionar.
Antes de utilizar la aplicación Mediatek SP Flash Tool, no olvidéis instalar los drivers del Preloader, que podéis descargar por ejemplo, desde aquí:
https://docs.google.com/file/d/0B1x1BQ2sB-9iR1VlcDk0TnJ0VEk/edit?pli=1
En la siguiente página (http://forum.zopomobileshop.com/thread-1412-1-1.html) encontraréis archivos para particionar diferentes dispositivos Mediatek con diferentes espacios de almacenamiento. Si queréis reparticionar el vuestro, no olvidéis seleccionar el archivo zip que corresponda.
Dentro de cada archivo zip, encontraréis tres ficheros:
El fichero scatter.
El fichero EBR1.
El fichero EBR2.
Lo primero que hay que hacer es descomprimir el archivo y, una vez descomprimido, desde la aplicación seleccionar el Scatter. Una observación: He modificado las particiones del Flying Mega, de manera que queden 7GB para la partición de aplicaciones y el resto para la de almacenamiento de archivos. En este caso, he tenido que utilizar el fichero scatter de la imagen original porque el que venía en el archivo, no funcionaba.
Una vez seleccionado el scatter, marcamos las casillas de los archivos EBR1, EBR2 y desde allí cargamos los archivos que venían dentro del zip.
Una vez hecho ésto, pulsamos el botón "Download" de la aplicación y ésta quedará esperando a que conectemos el teléfono.
A continuación, quitamos la batería del smartphone y lo conectamos mediante el cable USB al ordenador. Una vez conectado, volvemos a colocar la batería y comenzará el proceso de flasheo. Cuando termine, el dispositivo se reiniciará y nos informará de que la memoria interna no está formateada. Además, nos preguntará si queremos formatearla. Aceptamos y la formateará.
Flashear ClockworkMod Recovery (CWM) en cualquier dispositivo MT65xx
En un post anterior hemos visto cómo podemos rootear nuestro dispositivo Android. En este post, veremos cómo flashear CWM en él para disponer de un recovery más avanzado. Eso sí, como las herramientas a utilizar son para windows, tendremos que utilizar un sistema Windows, ya sea en una máquina virtual o en un equipo que disponga de este sistema operativo.
Primero.- Descargamos e instalamos las ADB tools. Podéis descargarlas desde el siguiente enlace, por ejemplo: http://d-h.st/IRd
Segundo.- Descargamos e instalamos MTK Droid Tools. Por ejemplo, desde el siguiente enlace: http://ge.tt/2P16x3G1/v/0
Tercero.- Activamos USB Debugging en el dispositivo.
Cuarto.- Abrimos MTK Droid Tools y esperamos a que detecte el dispositivo.
En la parte izquierda, nos muestra la información del dispositivo. Si os fijáis, en la parte inferior izquierda hay un cuadro de color verde. Eso es porque mi dispositivo ya está rooteado. Si no estuviera rooteado, el cuadro sería de color amarillo. Quinto.- El siguiente paso es hacer clic en la pestaña "Root, Backup, Recovery" donde veremos las siguientes opciones:
Sexto.- Marcamos la opción "boot para el teléfono" y pulsamos el botón "Recovery y Boot", que he resaltado en amarillo. Séptimo.- Nos aparecerá un mensaje que dice algo así como "Crear CWM Recovery automáticamente". Pulsamos Yes. Octavo.- Esperamos a que la herramienta cree el CWM Recovery. Cuando termine, nos preguntará si queremos instala el recovery creado en el teléfono. Pulsamos Yes.
Noveno.- Por último, nos preguntara si queremos reiniciar para arrancar en el modo Recovery. Hacemos clic en Yes para comprobar que se encuentra instalado y listo. Publicado por primera vez en http://enavas.blogspot.com.es
Flashear Flying Mega con stock rom
El Flying Mega es una réplica del Galaxy Mega, un smartphone de 6,3" con procesador MTK6592 de 8 núcleos que funciona de maravilla.
Procesador Octacore MTK6592
Pantalla HD de 6.3 pulgadas IPS
5 puntos simultáneos
Cámara principal trasera de 13mpx
Air gesture Si disponéis de este dispositivo y, por alguna razón, necesitáis restaurar el sistema operativo original, va a ser difícil que lo encontréis. Pero no os preocupéis porque la rom es exactamente la misma que la del Star W9296. Podéis descargar esta rom desde la web http://www.needrom.com, registrandoos previamente en la misma.
ROM Star W9206: http://www.needrom.com/wp-content/uploads/2014/07/Star-SPW9206.zip
SP Flash Tool: http://www.needrom.com/wp-content/uploads/2014/01/SP_Flash_Tool_v5.1348.00.zip
Si queremos controlar nuestro Smartphone Android desde Debian Wheezy para realizar en él tareas de administración, tenemos dos opciones:
Instalar el SDK de Android completo.
Instalar sólo las herramientas específicas que vamos a utilizar.
Si vamos a desarrollar, sería interesante instalar el Android SDK completo, pero si sólo vamos a realizar ciertas tareas básicas, será suficiente con las herramientas adb y fastboot.
En Wheezy es muy sencillo instalarlas porque se encuentran empaquetadas en los repositorios:
# apt-get install android-tools-adb android-tools-fastboot android-tools-fsutils
Una vez instaladas, activamos las opciones de desarrollo y el modo debug en nuestro smartphone y lo conectamos al ordenador mediante el cable usb. Una vez conectado, podemos abrir un shell y comprobar que adb detecta nuestro smartphone:
Si lo detecta, veréis una salida similar a la siguiente:
0160741711004023 device
A partir de ahí, ya podemos ejecutar comandos en nuestro smartphone, transferirle archivos, descargar archivos, etc desde la línea de comandos.
iRoot: Rootear nuestro dispositivo Android
iRoot es una de esas apps que permiten rootear diferentes dispositivos Android.
Personalmente la he probado en un dispositivo Mediatek MTK 6592 y me ha funcionado muy bien.
Permite rootear o desrootear con un solo click desde Android 2.2 hasta Android 4.4 y soporta una gran variedad de dispositivos.
Aquí tenéis el enlace a la app por si queréis descargarla:
Insertar un nombre de paquete en todos los ficheros musthave.ies de un directorio y sus subdirectorios
Para gestionar los paquetes que se instalan en las máquinas (servidores ltsp, portátiles y workstations) utilizamos pkgsync. Habitualmente distribuyo los ficheros de pkgsync mediante un módulo puppet que almacena los ficheros de pkgsync en diferentes directorios dentro del directorio de ficheros del módulo /etc/puppet/modules/pkgsync-ies/files
Cuando quiero añadir el nombre de un paquete a todos los ficheros musthave.ies, no tengo más que ejecutar una combinación de comandos como la siguiente:
# find /etc/puppet/modules/pkgsync-ies -name musthave.ies -exec sed -ie '$a flashplayer-mozilla' {} \; -exec sort -o {} -u {} \;
Si examináis detenidamente el comando anterior, comprobaréis lo que hace:
Busca en el directorio /etc/puppet/modules/pkgsync-ies/files y sus subdirectorios todos los ficheros con nombre musthave.ies.
Inserta al final del archivo el nombre del paquete que queremos añadir.
Y ordena el fichero eliminando repeticiones. Publicado por primera vez en http://enavas.blogspot.com.es
Gtk-WARNING **: Imposible encontrar el motor de temas en la ruta al _modulo: «murrine»
Al lanzar una aplicación desde el terminal, he visto que el sistema me mostraba muchos mensajes con el siguiente error:
Por lo que he podido comprobar, el problema estaba en que no se encontraba instalado el paquete gtk2-engines-murrine que instala el motor de temas correspondiente. Así que lo he instalado y problema resuelto.
apt-get install gtk2-engines-murrine
Error "406 Not Acceptable" al actualizar los índices de los repositorios
Este error que se produce al actualizar los índices de los repositorios es un bug no resuelto. No sé si se produce con apt-get, con aptitude o ambas herramientas. El caso es que se corrompen los archivos del directorio /var/lib/apt/lists/partial/. De momento, la solución es borrar el contenido de este directorio:
# rm -fr /var/lib/apt/lists/partial/*
No obstante, para tratar de determinar con qué herramienta sucede exactamente, voy a probar a utilizar solamente aptitude. Publicado por primera vez en http://enavas.blogspot.com.es
SSMTP: Enviar e-mails desde consola y scripts
ssmtp es una interesante herramienta que nos va a permitir enviar correos desde la línea de comandos utilizando como servidor smtp una cuenta externa, como por ejemplo Gmail.
En mi caso, como administrador de dominio de Google Apps, he creado una cuenta que uso específicamente para remitir mensajes que me informen acerca del estado del sistema.
Lo primero, como siempre, será instalar la herramienta:
Una vez instalada, guardamos el archivo de configuración original:
# mv /etc/ssmtp/ssmtp.conf /etc/ssmtp/ssmtp.conf.orig
Y creamos uno nuevo:
# touch /etc/ssmtp/ssmtp.conf
Al que añadimos un contenido similar al siguiente: # Cuenta de correo que va a recibir todos los correos
root=sysinfo@gmail.com
# Servidor SMTP al que reenviaremos los correos
# Datos de autenticación de la cuenta de correo
AuthUser=sysinfo@gmail.com
AuthPass=passwordDelUsuario
# Nombre de Dominio a mostrar como enviador del correo
rewriteDomain=iesvalledeljerteplasencia.es
hostname=recursos
En este fichero, debéis sustituir las direcciones de correo y la contraseña por vuestros propios datos. Una vez hecho ésto, cambiamos los permisos del fichero /etc/ssmtp/ssmtp.conf para que otros usuarios no puedan ver la contraseña de correo:
Y asignamos como propietario root y grupo mail:
# chown root:mail /etc/ssmtp/ssmtp.conf
Aunque principalmente usemos ssmtp con la cuenta de correo del administrador, de este modo, todos aquellos usuarios que añadamos al grupo mail también podrán enviar correos.
Para comprobar que funciona, podéis enviar un mensaje de prueba a una cuenta de correo externa:
# echo "esto es un mensaje de prueba" | mail -s Prueba algodelinux@gmail.com
Y si todo ha ido bien, recibiréis el mensaje en la cuenta especificada. Publicado por primera vez en http://enavas.blogspot.com.es
Cómo utilizar el recurso package de Puppet para instalar paquetes desde Debian Backports
Normalmente utilizamos el recurso package para instalar paquetes desde los repositorios y todo el mundo que trabaja con Puppet lo utiliza al menos de forma más o menos sencilla.
Por ejemplo, si queremos instalar los paquetes de Samba, haríamos lo siguiente:
package { ['samba','samba-common','smbclient']:
ensure =&gt; 'installed',
En el caso de que quisiéramos que estos paquetes se mantuvieran actualizados, cambiaríamos el "ensure":
ensure =&gt; 'latest',
Pero, ¿qué sucede si en nuestra máquina tenemos definidos los repositorios de Debian Backports y queremos instalar Samba desde allí?. En este caso, tendríamos que usar el metaparámetro install_options. Por ejemplo:
install_options =&gt; [ '-t','wheezy-backports' ],
Módulo puppet-apagado-terminales modificado para utilizar nmap
He modificado el módulo puppet que instala lo necesario para apagar los terminales de un aula cuando el profesor cierra sesión, de manera que ahora utiliza nmap en lugar de avahi para detectar los equipos encendidos. Podéis descargarlo desde aquí:
puppet-apagado-terminales.tar.gz
Y podéis ver el código fuente del script de apagado en github:
Configurar CUPS como servidor de impresión
Al hilo de una pregunta de un compañero sobre la configuración del servidor de impresión CUPS, he pensado que sería interesante comentar este tema.
El título de este post, en realidad, no es de lo más acertado porque CUPS siempre trabaja como servidor de impresión, aunque por defecto viene configurado para escuchar en localhost:631, y, por lo tanto tan sólo configura la impresora para la máquina local. ¿Cómo? Con una línea en el fichero de configuración /etc/cups/cupsd.conf como la siguiente:
Para cambiar este comportamiento, podemos modificar la línea anterior de tal manera que, en lugar de localhost, especifique la dirección IP de la máquina. Por ejemplo, si el equipo que comparte la impresora tiene la IP 172.19.144.240: Listen 172.19.144.240:631
De este modo, cualquier máquina de nuestra red, podrá imprimir en la/s impresora/s conectada/s a este servidor.
Ahora bien, supongamos que estamos utilizando una máquina que queremos usar como servidor de impresión en dos redes a las que tiene conexión mediante dos interfaces de red con direcciones IP 172.19.144.240 y 192.168.0.240. Para hacer que el servidor de impresión escuche en ambas interfaces, tan sólo tenemos que añadir una línea por cada interfaz:
Listen 172.19.144.240:631
Listen 192.168.0.240:631
Por supuesto, siempre que hagáis cambios en el fichero de configuración, deberéis reiniciar el servicio:
Instalar drivers de impresoras en Linux
Cuando instalo impresoras en Linux, siempre trato de descargar los drivers desde la web del fabricante. Y si el fabricante no proporciona un driver para Linux, suelo acudir a OPENPRINTING:
http://www.openprinting.org/printers Publicado por primera vez en http://enavas.blogspot.com.es
Añadir nuevos "drivers" de impresoras a CUPS
El servidor de impresión CUPS (Common Unix Printing System) utiliza archivos PPD (PostScript Printer Description), un estándar desarrollado por Adobe, para realizar la impresión. Cuando configuramos una impresora le asociamos un archivo PPD. Ese archivo PPD contiene el código PostScript necesario para usar las características de la impresora, de manera que funciona como un controlador de dispositivo.
Normalmente, cuando configuramos impresoras en Linux, utilizamos los archivos ppd que nos proporciona el sistema, pero, en ocasiones, necesitamos instalar un driver específico proporcionado por el fabricante o descargado por nosotros desde la web. En este caso, para que los archivos ppd que añadamos se encuentren disponibles en la lista de drivers a la hora de instalar una nueva impresora, los copiaremos al siguiente directorio de cups:
/usr/share/ppd/custom
Y si el driver que queremos añadir incorpora también algún filtro, lo colocaremos en el siguiente directorio de cups:
Sabiendo ésto, automatizar esta tarea con puppet es muy sencillo.
Para distribuir drivers de impresoras a los equipos de mi centro, tengo creado un módulo al que he llamado puppet-cups, que, entre otras cosas, añade todos los módulos que coloque en el directorio ppd del módulo.
Estaba tratando de configurar el forwarding en el servidor bind9 de la subred de los ciclos para que reenviara peticiones a los servidores DNS de la red del centro, y a pesar de que la configuración es sencilla, no funcionaba:
forwarders { 172.19.144.3; 172.19.144.2; };
Buscando un poco, he encontrado que si dejamos dnssec-validation auto, bind9 no realiza las peticiones a los servidores que le hayamos indicado, pero sí funciona cuando el valor es yes o no. Un bug?? Publicado por primera vez en http://enavas.blogspot.com.es
Configuración de PowerDNS en los IES utilizando pdns-recursor para resolver direcciones internas y externas
En un post de abril de este año (http://enavas.blogspot.com/2014/04/configurar-powerdns-en-los-centros-para.html) explicaba cómo configurar PowerDNS en los servidores de los centros para tener acceso a las aplicaciones de intranet del Gobierno de Extremadura.
Como estoy demasiado ocupado en el centro, casi no leo el correo de la lista o lo ojeo por encima. El caso es que esta mañana he visto que algún compañero comentaba en un mensaje de hace algunos días que la configuración que explicaba en el post mencionado anteriormente no le servía para que el DNS le resolviera una dirección de una web externa. Decir que es lógico porque con lo expuesto en el post no se trata de resolver direcciones externas, sino de configurar PowerDNS para que resuelva direcciones de la intranet. Para mejorar la configuración de la resolución externa, habría que tocar otras configuraciones adicionales.
Cuando escribí el artículo no quise incluir mi configuración completa para que la gente no se liara y copiara y pegara mis configuraciones en sus servidores sin entenderlas, algo que puede ser bastante problemático si no se sabe lo que se está haciendo. Como ya he comentado en alguna ocasión, en mi centro tengo montada una réplica del servicio ldap en el servidor nfs y un powerdns en cada uno de los servidores, de tal manera que ambos resuelvan nombres consultando la base de datos del ldap local. En el fichero de configuración de powerdns /etc/powerdns/pdns.d/pdns-debian-edu.conf tengo definido que use como recursor el propio servidor dns (127.0.0.1:1553):
recursor=127.0.0.1:1553
- See more at: http://enavas.blogspot.com.es/2014/04/configurar-powerdns-en-los-centros-para.html#sthash.kK0RGkaZ.dpuf
En el fichero de configuración de powerdns /etc/powerdns/pdns.d/pdns-debian-edu.conf tengo definido que use como recursor el propio servidor dns (127.0.0.1:1553):
También creo haber leído que alguien había desactivado el recursor porque al fin y al cabo en la configuración que aplicaba, no se estaba usando y realmente no sabía para qué servía.
No voy a entrar en demasiados detalles sobre PowerDNS, pero voy a tratar de aclarar un poco el tema para que se entienda, sobre todo porque a mí me gusta entender todo aquello con lo que trabajo y supongo que a otros también.
PowerDNS está formado por dos componentes:
El servidor "autoritativo": pdns.
Y el recursor: pdns-recursor. Otros servidores DNS combinan ambas funciones. Por decirlo de algún modo, un servidor DNS "autoritativo" es la fuente que proporciona información de resolución de nombres para un dominio en particular. Los servidores "autoritativos" pueden ser de dos tipos: primarios o secundarios. En cuanto al recursor, simplemente nos proporciona un sistema de almacenamiento en caché para acelerar la resolución de nombres y un dispositivo de resolución recursiva de nombres para que nuestros clientes accedan a nuestra red o a internet utilizando DNS.
Teniendo en cuenta todo ésto, estaréis de acuerdo conmigo en que, aunque el recursor no es imprescindible, sí es de gran utilidad.
Cuando en el fichero /etc/powerdns/pdns.d/pdns-debian-edu.conf tenemos la siguiente línea:
Le estamos diciendo a nuestro servidor DNS "autoritativo" que utilice como recursor el servidor que escucha en la dirección IP 127.0.0.1 y en el puerto 1553.
Si en lugar de eso, en el fichero /etc/powerdns/pdns.d/pdns-debian-edu.conf ponemos la siguiente línea:
estamos diciendo a nuestro servidor DNS "autoritativo" que utilice como recursor el servidor de Google cuya IP es 8.8.8.8
En mi caso, utilizo el recursor que corre en mi servidor (recursor=127.0.0.1:1553), sencillamente porque mi recursor cacheará información de dns localmente y eso hará que esa información se proporcione más rápidamente a los clientes.
Alguien me preguntaba cómo es posible que el servidor autoritativo y el recursor se encuentren corriendo en la misma máquina. La respuesta es muy sencilla: El servidor autoritativo escucha en el puerto 53 y el recursor escucha en el puerto 1553.
Una vez aclarado un poco el tema, os muestro mi configuración para el recursor, que se entiende bastante bien con sólo ver el fichero:
/etc/powerdns/recursor.conf dont-query=
forward-zones=valledeljerte3=172.19.144.3;172.19.144.2,gobex.pri=172.20.5.4;172.20.5.3,juntaextremadura.pri=172.16.1.28
forward-zones-recurse=.=8.8.8.8;8.8.4.4
local-port=1553
Con ésto, garantizo la resolución de nombres de mi dominio, la resolución de nombres de dominio de la intranet y la resolución de nombres de internet.
Hace unos días, tratamos de instalar un sistema operativo de 64 bits en una máquina virtual creada en VirtualBox en un portátil ttl y no terminaba de completarse. Lo repetimos una vez más y volvió a suceder lo mismo.
Me pareció un poco extraño, pero se me ocurrió una sencilla explicación: El Debian instalado en los portátiles ttl es de 32 bits. Pensando en solucionar este problema y teniendo en cuenta que sería mucho más óptimo instalar un sistema de 64 bits en una máquina de 64 bits me decidí a mirgrar el Debian de 32 bits instalado a 64 bits, algo viable puesto que Debian Wheezy es multiarch. Para ello, tomé como referencia el siguiente tutorial de migración: http://www.ewan.cc/?q=node/90
No me sirvió al pie de la letra, pero sí como orientación y con algunos pequeños retoques dado que mi caso no era exactamente el mismo.
A grandes rasgos, la idea es sencilla:
Instalar un kernel de 64 bits.
Obtener la lista de paquetes instalados en el sistema.
Reducir los paquetes instalados al sistema base.
Actualizar el sistema base a 64 bits.
Actualizar las librerías a 64 bits.
Reinstalar el resto de paquetes que teníamos antes de reducir el sistema. Eso sí. El procedimiento lleva su tiempo, sobre todo si hay que hacer la instalación de paquetes desde internet. Para no tardar mucho, lo que hice fue utilizar el disco duro externo en el que guardo una copia de los mirrors del centro.
Ahora ya tengo un sistema como el de los miniportátiles para equipos de 64 bits. El siguiente paso será montar también este sistema de 64 bits en la imagen de los portátiles ttl.
Podemos reinstalar grub fácilmente desde un live cd mediante el siguiente procedimiento:
Arrancamos el live cd.
Montamos la partición que contiene el sistema raíz. Suponiendo que sea la partición /dev/sda5:
Montamos la partición que contiene /boot. Suponiendo que sea /dev/sda3:
Realizamos la instalación de grub:
# grub-install --boot-directory=/mnt/boot /dev/sda
Desmontamos la partición /boot:
Desmontamos la partición raíz del disco:
Por último, reiniciamos el equipo.
Instalar Virtualbox en Debian Wheezy desde la línea de comandos
En ocasiones me preguntan por qué cada vez que voy a hacer alguna configuración, instalación, etc, me voy a un terminal... Supongo que, en parte, porque me he acostumbrado y me resulta más cómodo y rápido que estar buscando entre los menús del entorno gráfico. Además eso es bueno, en el sentido de que si estás acostumbrado a trabajar en el terminal, cuando no tienes entorno gráfico, como por ejemplo, en el caso de servidores, no te molesta. Veamos a continuación cómo instalar VirtualBox en Debian Wheezy desde un terminal:
Para instalar VirtualBox en Debian Wheezy, lo más cómodo es hacerlo desde los repositorios oficiales. Así que, lo primero será añadir los repositorios a nuestra lista:
# echo "deb http://download.virtualbox.org/virtualbox/debian wheezy contrib non-free" &gt; /etc/apt/sources.list.d/virtualbox.list
Una vez añadido el repositorio, descargamos la clave pública y la añadimos al anillo de claves:
# wget -q http://download.virtualbox.org/virtualbox/debian/oracle_vbox.asc -O- | apt-key add -
A continuación, actualizamos los índices de los repositorios:
E instalamos el paquete VirtualBox. La última versión disponible a día de hoy es la 4.3:
Por último, descargamos el VirtualBox Extension Pack correspondiente a la versión que estamos instalando desde https://www.virtualbox.org/wiki/Downloads:
# wget http://download.virtualbox.org/virtualbox/4.3.18/Oracle_VM_VirtualBox_Extension_Pack-4.3.18-96516.vbox-extpack
Este paquete nos proporciona soporte para dispositivos USB 2.0, RDP y PXE para tarjetas de red intel.
Cuando lo hayamos descargado, no tenemos más que instalarlo:
# VBoxManage extpack install Oracle_VM_VirtualBox_Extension_Pack-4.3.18-96516.vbox-extpack --replace
Si todo ha ido bien, veréis el progreso de la instalación:
Script para borrar las credenciales de usuario cacheadas en portátiles
Para hacer algo más de limpieza desde el script /root/S99primer-arranque, es interesante borrar las credenciales de usuarios cacheadas en portátiles.
Para realizar dicha limpieza, tengo un script /usr/local/sbin/removecachedcredentials al que llamo desde el script S99primer-arranque. De este modo, puedo limpiar también las credenciales en cualquier momento, no sólo en el inicio:
# Instalamos libpam-ccreds si no estaba instalado
dpkg -l | grep ^"ii  libpam-ccreds" &gt; /dev/null || apt-get -y install libpam-ccreds
for usuario in `cc_dump |awk '{print $3}' | sed '1,2d'`; do
cc_test -update any $usuario -
Iso de Clonezilla + DRBL para montar en pendrive/disco duro USB
En el siguiente enlace dejo una ISO muy interesante, sobre todo para los administradores de centros, en la que he montado Clonezilla y DRBL:
https://copy.com/L2anoLH9DXGMkwIl
Si os preguntáis por qué monto ambas herramientas, la razón es muy sencilla: Habitualmente uso clonezilla para crear y restaurar imágenes, pero cuando tengo que clonar de forma masiva, utilizo DRBL para restaurar imágenes en modo multicast.
Ajustes que le he realizado:
El filesystem.squashfs de DRBL se aloja en el directorio live y el filesystem.squashfs de Clonezilla se encuentra ubicado en el directorio live-hd. De este modo, es posible tener ambas herramientas en el mismo dispositivo.
Se establece por defecto el idioma español tanto para la interfaz como para el teclado. Con ésto evitamos tener que seleccionar el idioma en el asistente de clonación cada vez que lo usemos.
Se fija como directorio de imágenes el /home/partimag del dispositivo para ambas herramientas y se monta en modo lectura/escritura con el fin de que se use tanto para salvar/restaurar imágenes en ambas herramientas.
Para montar la ISO en el pendrive podéis usar tuxboot, o hacer el dispositivo arrancable de forma manual y copiar el contenido.
Convertir en arrancable un pendrive/disco duro USB
Si tenemos un pendrive o disco duro usb con formato fat32 podemos convertirlo en un dispositivo de arranque sin formatearlo utilizando herramientas del sistema operativo. Veamos cómo:
Para empezar, instalamos las herramientas que vamos a necesitar, si no las tenemos instaladas ya:
# apt-get install syslinux parted
Supongamos que introducimos el pendrive/disco en nuestro ordenador y ejecutamos:
Con ello comprobamos que el pendrive/disco se encuentra identificado como /dev/sdb con una partición /dev/sdb1. Tomad nota del resultado del comando. Podría ser que tuviéramos más dispositivos conectados y la identificación sea diferente.
# syslinux -i /dev/sdb1
A continuación copiamos el mbr al dispositivo:
# dd conv=notrunc bs=440 count=1 if=/usr/lib/syslinux/mbr/mbr.bin of=/dev/sdb
Y definimos la partición 1 como arrancable:
Una vez hecho ésto, el dispositivo será iniciable y podemos copiarle el contenido de clonezilla, drbl, system rescue, etc... o la herramienta que queramos montar. Como ya he dicho, no es necesario formatear el dispositivo para hacerlo arrancable, pero si tuviérais que formatearlo, también podríais hacerlo mediante un comando: mkfs.vfat -F 32 /dev/sdb1
Por último, decir que si al arrancar el ordenador con el pendrive/disco os dá un error como el siguiente: "Failed to load COM32 file vesamenu.c32", probablemente sea porque la versión de los ficheros com32 no coincide con la de isolinux.sys. En cuyo caso, deberéis asegurar que coincida. Si habéis utilizado los comandos del sistema operativo, los ficheros com32 se encuentran almacenados en la siguiente ubicación: /usr/lib/syslinux/modules/bios/ Copiadlos desde allí a vuestro dispositivo.
Instalar Google Chrome desde los repositorios de Google en Debian Wheezy
Instalar Google Chrome desde los repositorios de Google es muy sencillo. Vamos a verlo paso a paso para que quede muy claro:
Primero.- Añadimos la dirección del repositorio a los archivos de fuentes:
# echo "deb http://dl.google.com/linux/chrome/deb/ stable main
" &gt; /etc/apt/sources.list.d/google-chrome.list
Segundo.- Descargamos la clave pública del repositorio:
# gpg --keyserver keys.gnupg.net --recv-key A040830F7FAC5991 Tercero.- Añadimos la clave pública del repositorio al anillo de claves:
# gpg --export --armor A040830F7FAC5991 | apt-key add -
El anillo de claves se guarda en el archivo /etc/apt/trusted.gpg
Cuarto.- Actualizamos los índices de los repositorios:
Quinto.- Instalamos Google Chrome:
# apt-get install google-chrome-stable
Abandoné Ubuntu ya hace algunos años y hace mucho tiempo que no lo usaba, pero ahora que lo estoy viendo en las máquinas de los ciclos y me he encontrado ya algunos bugs y unas cuantas cosas que no me gustan, decididamente me quedo con Debian.
Uno de los bugs de la versión 14.04 consiste en que Ubuntu "olvida" los ajustes multimonitor. Bueno, mejor dicho, no es que olvide los ajustes, porque en realidad sí los guarda en el archivo de configuración: ~/.config/monitors.xml. Lo que sucede es que no lee la configuración de este archivo en el inicio.
1.- Matar el proceso gnome-settings-daemon desde uno de los scripts de inicio del sistema. Por ejemplo desde /etc/rc.local:
pkill -9 -f gnome-settings-daemon
2.- Establecer la configuración multimonitor en cada arranque en /etc/rc.local mediante el comando xrandr.
Plank es un dock escrito en el lenguaje de programación Vala que me gusta mucho por ser ligero y sencillo, pero que además tiene un añadido muy interesante para mí: Se configura modificando el siguiente fichero en el home del usuario: ~/.config/plank/dock1/settings La ventaja de ésto es que puedo gestionar las configuraciones de los usuarios de una manera muy sencilla desde la línea de comandos o desde scripts.
Hoy he ido a compilar el dock Plank, para lo que se necesita el compilador Valac y al tratar de hacerlo, recibía un mensaje de que la versión de Valac instalada era demasiado antigüa. Así que, antes de nada, he tenido que descargar el código fuente y compilarlo. Primero.- Descargamos la versión de Vala que queramos desde la siguiente dirección: http://ftp.gnome.org/pub/GNOME/sources/vala/
Segundo.- El archivo a descargar está comprimido con xz, así que lo descomprimimos. Por ejemplo, suponiendo que he descargado la última versión disponible a día de hoy, la descomprimo:
$ xz --decompress vala-0.26.1.tar.xz
$ tar xfv vala-0.26.1.tar
Tercero.- Una vez descomprimido, se crea un directorio: vala-0.26.1. Por ser un poco organizado, tengo por costumbre copiar todo lo que compilo desde código fuente en /usr/src:
$ cp -r vala-0.26.1 /usr/src
Cuarto.- Entramos dentro del directorio:
$ cd vala-0.26.1
Quinto.- Configuramos y compilamos:
$ make Sexto.- Si el proceso de compilación no ha ido bien (make), prrobablemente sea porque nos falta alguna dependencia por instalar. Si es así, la instalamos y volvemos a ejecutar el comando make hasta que se produzca una compilación completa.
Séptimo.- Si el proceso de compilación ha finalizado correctamente, instalamos: $ make install
Octavo.- Por último, comprobamos que se ha realizado bien la instalación:
Como hemos instalado la versión 0.26.1, la salida del comando debería ser:
Vala 0.26.1
Method http has died unexpectedly! al hacer "apt-get update"
No sé por qué, aunque supongo que se deberá a la actualización de alguno de los paquetes del sistema, cada vez que trataba de hacer un "apt-get update" o un "aptitude update" obtenía el siguiente error:
E: El subproceso http recibió un fallo de segmentación.
Depués de muchas pruebas, buscar y rebuscar, me dí cuenta de que el error no sucedía si arrancaba en "recovery mode".
Al final, el error lo causaba el demonio de caché para el servicio de nombres nscd.
Ahora mismo no necesito este demonio, pero por si acaso lo me hiciera falta, lo he sustituido por unscd:
# apt-get remove nscd unscd+
El shell de linux: Abrir o cerrar el CDROM desde la línea de comandos
Si habéis leído el post en el que mostraba un script para expulsar el CD/DVD cuando el usuario cierra su sesión, os habréis dado cuenta de que para expulsar el disco uso el comando eject de la siguiente manera:
# eject /dev/cdrom
Si en lugar de expulsarlo, lo que queréis es cerrar la bandeja, tan sólo tenéis que ejecutar el comando anterior con el parámetro -t:
# eject -t /dev/cdrom
Por otra parte, insistir en que es un servicio que os recomiendo utilizar porque no sólo tendréis un único punto de entrada para todos vuestros servicios de almacenamiento, sino que también podréis copiar, mover, etc.. archivos entre ellos. Publicado por primera vez en http://enavas.blogspot.com.es
Compartir impresora en red usando un viejo router ARV4518PW
Para tener disponible nuestra impresora en red y evitar mantener encendido un ordenador para compartirla podemos usar un router wifi con puerto USB, que cosume bastante menos energía. Yo he aprovechado un viejo router ARV4518PW que tenía guardado en una caja ya que tiene puerto USB y además permite usarlo como servidor de impresión, servidor web, servidor ftp o servidor de archivos, pero podéis hacerlo con cualquier otro router con OpenWRT.
Como se puede ver en la siguiente imagen, le he conectado una impresora HP LaserJet 6L, he activado utilizar la funcionalidad USB y me la ha detectado perfectamente: Por si alguien me pregunta, os diré que esta impresora tan sólo tiene conexión de puerto paralelo, pero le tengo conectado un conversor de puerto paralelo <-> usb.
Para configurar esta impresora en mi equipo Debian, lo único que tengo que hacer es abrir el navegador, conectarme al localhost en el puerto 631, y agregar la impresora de red, configurando la conexión como puede verse en la siguiente imagen:
Script dvdject para evitar que el usuario olvide el disco
En ocasiones, algunos usuarios olvidan el disco en la unidad de DVD y cuando llega el siguiente usuario, no puede extraer el disco porque al no haberlo montado él, el sistema no se lo permite.
La solución por la que he optado para resolver el problema ha sido colocar un script en /usr/local/bin/ al que he llamado dvdeject que se inicia cuando el usuario cierra su sesión, comprueba si el CD/DVD está montado y si lo está, lo expulsa. Como podéis comprobar, el script es muy sencillo:
# Este script se pone en marcha desde /etc/gdm3/PostSession/Default
# Su función es expulsar el CD/DVD introducido por el usuario al cerrar la sesión
# Soluciona el problema de que un usuario se olvide el CD/DVD que ha usado
# 27/05/2014
montado=$(mount|grep "/dev/sr"|cut -f1 -d" ")
if [ $montado ]; then
eject $montado
Problemas con la wifi en portátiles ttl suministrados para la FP Básica
Por si no teníamos ya bastante trabajo, ahora nos está dando problemas la wifi de los portátiles ttl que nos enviaron para la FP Básica. Supongo que muchos compañeros no han detectado aún el problema porque no los han puesto en funcionamiento. Para colmo también nos han enviado estos mismos portátiles para el ciclo de Desarrollo de Aplicaciones Multiplataforma. La cuestión es que estos portátiles sufren continuas desconexiones de la red wifi y, en la mayor parte de las ocasiones es imposible volver a reconectar, a menos que reiniciemos el portátil. Hemos probado con Debian, Ubuntu y Windows y en todos ellos se producen dichas desconexiones.
Estos portátiles llevan una inalámbrica con chipset RTL8723BE. En algunos foros dicen que este problema está resuelto en kernels >= 3.15. Por lo tanto, la siguiente prueba que estoy realizando es instalar el kernel 3.15 que en wheezy se encuentra en los repositorios de backports y por lo que he podido ver, nuestros compañeros de la Sección de Administración de Sistemas lo han subido al repositorio interno.
Ver post más reciente: http://enavas.blogspot.com.es/2015/05/problemas-con-la-wifi-con-chipset.html
Clonezilla: Restaurar una imagen de un disco en otro más pequeño
Para no trabajar de forma innecesaria, tengo por costumbre aprovechar las imágenes de clonación que haya en un momento determinado para adaptarlas a otras máquinas. Por ejemplo: Siempre creo la imagen para los workstations de departamentos, sala de profesores, sala de visitas, etc... a partir de la imagen de portátiles.
El problema que hay es que la imagen se crea para un disco duro más grande y no es posible restaurarlo en equipos con disco más pequeño. Lo que hago en este caso es:
Restaurar la imagen en una máquina con un disco duro lo suficientemente grande para que clonezilla me permita realizar la clonación.
Una vez restaurada, reduzco el tamaño de las particiones para que quepan en el disco más pequeño con gparted.
Si no hay otra opción, elimino las particiones que no sean estrictamente necesarias, y retoco los ficheros de configuración, como por ejemplo: fstab.
Por último, vuelvo a crear la imagen.
Restauro la imagen creada en el disco más pequeño, utilizando la opción -icds que evita el chequeo del tamaño del disco de destino.
Una vez que tengo la imagen en el disco más pequeño, la inicio para comprobar que funciona sin ningún problema y, si todo ha ido bien, vuelvo a crear la imagen del disco más pequeño.
Limpiar las credenciales cacheadas de los usuarios de una máquina
En enero de 2012 escribí un post donde explicaba cómo gestionar las credenciales cacheadas de un usuario en un portátil.
Cuando hacemos limpieza en un momento dado, como por ejemplo, en el script de inicio primer-arranque, sería conveniente limpiar las credenciales de usuario cacheadas previamente.
El siguiente script obtiene un listado de todas las credenciales cacheadas y las elimina:
dpkg -l | grep ^"ii&nbsp; libpam-ccreds" &gt; /dev/null || apt-get -y install libpam-ccreds
&nbsp;&nbsp;&nbsp; cc_test -update any $usuario -
Utilizar autofs para montar un directorio compartido vía nfs
Ya que hace poco me han preguntado acerca del tema y aprovechando que acabo de hacer algo así para montar los directorios compartidos del NAS de los ciclos, voy a explicar cómo montar un directorio compartido vía nfs utilizando autofs.
Autofs nos permite montar sistemas de archivos locales y remotos bajo demanda y desmontarlos automáticamente cuando no se usen. ¿Qué quiero decir con bajo demanda? Pues simplemente que los sistemas de archivos se van a montar cuando el usuario acceda a ellos y se desmontarán después de un tiempo de inactividad.
Supongamos que tenemos un NAS en la máquina con IP 192.168.2.10 que exporta un directorio /mnt/Repo mediante nfs y queremos que éste directorio se encuentre disponible para las máquinas de nuestra red local. Lo que tendríamos que hacer sería configurar autofs en cada máquina para que acceda a dicho directorio.
Ésto es algo que podemos configurar de una manera muy sencilla mediante puppet, pero veamos cómo hacerlo manualmente para montar un sistema de archivos compartido vía nfs en una máquina:
Primero, instalamos autofs en el cliente:
Una vez instalado, editamos el archivo /etc/auto.master y le añadimos la siguiente línea:
/nfs /etc/auto.nas --timeout=60
Si no hemos configurado nada aún en autofs, el fichero os quedará más o menos así:
/nfs /etc/auto.nas &#8211;timeout=60
Con ésto, estamos especificando un punto de montaje en /nfs, que configuraremos en el archivo /etc/auto.nas. Por cierto, el directorio de montaje no es necesario crearlo. Lo crea autofs de forma automática.
A continuación creamos el archivo /etc/auto.nas con el siguiente contenido:
nas -fstype=nfs,rw,hard,intr,nodev,nosuid,nolock,rsize=8192 192.168.2.10:/mnt/Repo
nas es el punto de montaje.
-fstype=nfs,rw,hard,intr,nodev,nosuid,nolock,rsize=8192 son las opciones de montaje.
192.168.2.10:/mnt/Repo es el directorio nfs de la máquina remota que queremos montar.
De este modo, cuando el usuario acceda a /nfs/nas, se realizará automáticamente el montaje.
Para facilitar la tarea de montaje, es interesante crear un marcador en Nautilus, de tal manera que podamos acceder directamente al recurso compartido, haciendo clic directamente sobre él.
autofs,
Subir archivos a mediagoblin desde la línea de comandos
A veces necesitamos subir archivos a mediagoblin como administrador desde la línea de comandos. Veamos cómo con un ejemplo:
cd /srv/mediagoblin.valledeljerte3/mediagoblin
./bin/gmg addmedia usuario archivovideo.avi \
--title "Software Libre" \
--description "Documental sobre el concepto de Software Libre" \
--license "http://creativecommons.org/licenses/by-sa/3.0/" \
--tags "software,libre,linus"
nm-tool: Realizar determinadas tareas sólo cuando haya conexión de red
En ocasiones necesitamos realizar determinadas tareas tan sólo cuando haya una conexión de red establecida. Si tenemos NetworkManager, podemos aprovechar la herramienta nm-tool en un script para hacer la comprobación. Por ejemplo:
NETWORKONLINE=`nm-tool | grep State | cut -f2 -d" " | sed '/^$/d' `
if [ "$NETWORKONLINE" = 'connected' ]; then
# Realizar aquello que queramos hacer cuando haya conexión
Activar/desactivar conexiones inalámbricas con rfkill
No sé por qué pero he clonado portátiles HP con la imagen de los netbooks y en todos ellos me aparece desactivada la conexión wifi. La verdad es que no he tenido tiempo de estudiarlo detenidamente para ver cuál es el problema, pero lo cierto es que, cuando hago login, puedo volver a activar las conexiones inalámbricas desde Network Manager, pero no se guarda la configuración y cuando vuelvo a iniciar sesión, vuelven a estar desactivadas.
De momento, lo que he hecho ha sido añadir al fichero de configuración /etc/rc.local:
Con ésto, fuerzo a que se desbloquee la wifi al iniciar el sistema.
rfkill es una herramienta muy útil. Si no lo tenéis instalado, instaladlo porque en algún momento os vendrá muy bien:
# apt-get install rfkill
Veamos algunos ejemplos útiles de uso de esta herramienta:
Supongamos que queremos listar todos los dispositivos inalámbricos independientemente del tipo que sean:
Tipos de dispositivos que podemos especificar: "all", "wifi", "wlan", "bluetooth", "uwb", "ultrawide‐band", "wimax", "wwan", "gps" or "fm".
Supongamos que queremos activar la conexión wifi al arrancar el equipo. Podríamos añadir la siguiente línea al fichero /etc/rc.local:
Supongamos que queremos desactivar la conexión bluetooth al arrancar el equipo. Podríamos añadir la siguiente línea al fichero /etc/rc.local:
Supongamos que queremos desactivar todas las conexiones inalámbricas al arrancar el equipo. Podríamos añadir la siguiente línea al fichero /etc/rc.local:
Si os fijáis, estamos bloqueando conexiones por tipos de dispositivo. También podríamos bloquear un dispositivo concreto especificando su identificador.
El identificador es un número que aparece al lado de la conexión. Por ejemplo, si ejecuto:
# rfkill list wifi
mi portátil ahora mismo sólo tiene un dispositivo inalámbrico que es la
tarjeta wifi interna, me muestra el siguiente resultado:
&nbsp;&nbsp;&nbsp; Soft blocked: no
&nbsp;&nbsp;&nbsp; Hard blocked: no
Supongamos que tenemos dos dispositivos wifi y queremos bloquear solamente uno. Podríamos listar todos los dispositivos wifi para ver sus identificadores y luego bloquear el que nos interese:
# rfkill block 0 Por último, decir que también podemos monitorizar el estado de los dispositivos con:
# rfkill event
Almacenar las contraseñas de Network Manager en Wheezy
En Debian Squeeze, las contraseñas de Network Manager se almacenaban en claro en los ficheros de configuración. Observando los ficheros de configuración de Network Manager en Debian Wheezy, me he dado cuenta de que es posible seguir almacenando las contraseñas en claro, si:
Definimos el parámetro password-flags=0 en el fichero de configuración.
Especificamos la contraseña con el parámetro password=[contraseña].
Si no queremos almacenar la contraseña en claro, no tenemos más que especificar el parámetro password-flags=1 y la contraseña se almacenará en el anillo de claves del usuario. Publicado por primera vez en http://enavas.blogspot.com.es
Configurar el servidor nfs del centro para poder establecer quotas de disco
Aprovechando que tuve que cambiar el viejo servidor NFS del centro por el Primergy TX100 S3 que me enviaron, pensé que, ya que tenía una máquina de 64 bits, lo ideal sería montarle una Debian de 64 bits, en lugar de clonarlo con la imagen de 32 bits del antiguo servidor.
Al hacer una nueva instalación, tenía que configurarlo para poder establecer quotas de disco para los usuarios. Así que he aprovechado que mi amigo Chema me ha preguntado acerca del tema para hacer una pequeña chuleta que le sirva a otros compañeros:
Lo primero que tenemos que hacer es instalar los paquetes quota y quotatool:
# apt-get install quota quotatool
A continuación instalamos el paquete que añade el script setgroupquota para establecer quotas por grupos:
# dpkg -i setgroupquota_0.2_all.deb
Editamos el archivo /etc/fstab del servidor y modificamos la línea que monta la partición home para que admita quotas de disco:
/dev/mapper/servidor-home   /home   ext4    defaults    0    2
/dev/mapper/servidor-home   /home   ext4    defaults,usrquota,grpquota    0    2
Una vez modificado el /etc/fstab, "re-montamos" la partición home para no tener que reiniciar:
A continuación, ejecutamos el comando quotacheck para que se creen los ficheros de quotas:
# quotacheck -ugm /home Por último, activamos las quotas de disco:
# quotaon -ugv /home
Y listo. A partir de ahora ya podéis usar los scripts para asignar quotas de disco como el setgroupquota.
Actualizar HomeStation A4001N1 con firmware Openwrt Barrier Breaker 14.07-rc3
Me han preguntado en varias ocasiones si era posible actualizar el router HomeStation a una versión más reciente que la revisión r38342 de OpenWrt compilada por Noltari, supongo que sobre todo porque los enlaces ya no se encuentran disponibles.
Para los que me lo habéis preguntado, os recomiendo echar un vistazo al siguiente tema en el que Noltari publica la versión 14-07-rc3 del firmware Barrier Breaker:
http://foro.seguridadwireless.net/openwrt/%28repositorio%29-barrier-breaker-14-07-rc3/
Si queréis descargar un firmware compilado por él para nuestro dispositivo, podéis hacerlo desde aquí:
https://www.mediafire.com/folder/8mqa4ksm088do/bb-14.07-rc3#sbs9bm6hb2w1z
Aquí tenéis el enlace a la última versión del firmware compilado que publicó el día 13 de agosto:
http://www.mediafire.com/download/ac4aqbyb1lukx72/openwrt-A4001N1-squashfs-cfe.bin
Este firmware contiene los siguientes paquetes:
kmod-brcmsmac
kmod-brcmfmac
kmod-carl9170
kmod-libertas-usb
kmod-net-zd1201
kmod-p54-usb
kmod-rt2500-usb
kmod-rt73-usb
kmod-rtl8187
kmod-rtl8192ce
kmod-rtl8192cu
kmod-rtl8192de
kmod-rtl8192se
kmod-zd1211rw
kmod-fs-ntfs
kmod-fs-vfat
kmod-nls-cp437
kmod-nls-cp850
kmod-nls-cp852
kmod-nls-iso8859-15
luci-app-ddns
luci-app-upnp
luci-app-p910nd
luci-app-samba
luci-app-wol
luci-proto-relay
Instalar LibreOffice en Debian Wheezy desde Backports
Instalar Libreoffice en Debian Wheezy desde Backports para mantenerlo actualizado es muy sencillo:
Primero añadimos los repositorios de Wheezy Backports a nuestro sistema, si no los teníamos añadidos ya:
# echo "deb http://ftp.debian.org/debian/ wheezy-backports main contrib non-free" &gt; /etc/apt/sources.list.d/wheezy-backports.list
Una vez añadidos, actualizamos la base de datos de paquetes:
E instalamos los siguientes paquetes indicando que queremos hacerlo desde Backports con la opción -t:
# apt-get -t wheezy-backports install libreoffice libreoffice-gnome libreoffice-l10n-es libreoffice-help-es
Utilizar el mismo /home/partimag con Clonezilla y DRBL en un disco duro/pendrive usb
Como vimos en un post anterior, puede ser muy útil clonar con DRBL Live en modo multicast, sobre todo cuando el número de máquinas a restaurar es elevado. Además, como ya comenté, tengo montado DRBL y Clonezilla en el mismo disco duro externo de tal forma que suelo utilizar Clonezilla para crear imágenes y restaurarlas y DRBL cuando quiero clonar en modo multicast.
Un problema que nos ha surgido al tratar de utilizar versiones recientes de DRBL ha sido que ahora se monta el sistema en /lib/live/mount/medium, cuando antes se montaba en /live/image. Este problema ya está resuelto, pero sería interesante poder utilizar el mismo directorio /home/partimag de nuestro disco duro/pendrive usb tanto con Clonezilla como con DRBL, y, si fuera posible, que el montaje de /home/partimag se realizara automáticamente de forma totalmente transparente para el usuario.
Después de darle unas cuantas vueltas al tema, he pensado que la mejor forma de resolver ambos problemas sería modificando el filesystem.squashfs de DRBL.
Aquí os dejo un enlace al filesystem.squashfs modificado de tal manera que usa el directorio /home/partimag que haya almacenado en el disco duro/pendrive usb y lo monta automáticamente, por si queréis utilizarlo:
en versiones más recientes, como la 2.2.2.19-i686-pae, la antigua ubicación ha cambiado y el directorio /home/partimag ahora se encuentra en: /lib/live/mount/medium/home/partimag - See more at: http://enavas.blogspot.com.es/2012/07/clonacion-multicast-usando-drbl-live.html#sthash.jShIdgaY.dpuf
en versiones más recientes, como la 2.2.2.19-i686-pae, la antigua ubicación ha cambiado y el directorio /home/partimag ahora se encuentra en: /lib/live/mount/medium/home/partimag - See more at: http://enavas.blogspot.com.es/2012/07/clonacion-multicast-usando-drbl-live.html#sthash.jShIdgaY.dpuf Es D
https://copy.com/MYXL4TN7kMIp
Lo único que tenéis que hacer es cambiar el filesystem.squashfs de vuestro USB por el que podéis descargar del enlace anterior. Publicado por primera vez en http://enavas.blogspot.com.es
sed: Insertar una línea antes de un patrón determi...
sed: Borrar las líneas que contengan un patrón det...
Reparticionar el almacenamiento interno de Smartph...
Flashear ClockworkMod Recovery (CWM) en cualquier ...
Insertar un nombre de paquete en todos los fichero...
Gtk-WARNING **: Imposible encontrar el motor de te...
Error "406 Not Acceptable" al actualizar los índic...
Cómo utilizar el recurso package de Puppet para in...
Módulo puppet-apagado-terminales modificado para u...
Subir archivos a mediagoblin desde la línea de com...
nm-tool: Realizar determinadas tareas sólo cuando ...
Activar/desactivar conexiones inalámbricas con rfk...
Almacenar las contraseñas de Network Manager en Wh...
Configurar el servidor nfs del centro para poder e...
Actualizar HomeStation A4001N1 con firmware Openwr...
Instalar LibreOffice en Debian Wheezy desde Backpo...
Utilizar el mismo /home/partimag con Clonezilla y ...

References: resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución