martes, 22 de julio de 2014

configurar tp-link TL-WN725N v2 con wpa2 y dhcp en una raspberry pi con raspbian


Raspberry Pi es un ordenador de tamaño reducido (aproximadamente del tamaño de una tarjeta de crédito). Su consumo de 2.5W (modelo A) o 3.5W (modelo B) y sus características hacen de él un aparato muy versátil.


Cuando compré la raspberry, también compré el adaptador nano usb wifi TP-LINK TL-WN725N, con el objetivo de poder conectar la raspberry a una red inalámbrica cuando fuese necesario.

Actualmente, hay dos versiones de este adaptador: La v1 y la v2. Mientras que la v1 funciona directamente, para conseguir que funcione la v2 hay que instalar el driver. Para conectarnos con la raspberry pi a una red con DHCP protegida con WPA2-PSK utizando el adaptador nano usb wifi TP-LINK TL-WN725N bajo raspbian hay que realizar los siguientes pasos:

  1. Descargar e instalar el driver
    1. Averiguar la versión del kernel de raspbian

      Para concer la versión del kernel que está utilizando raspbian ejecutamos el comando:

      $ uname -r

    2. Descargar el driver

      La lista más completa de drivers la he encontrado en el blog de mendrugox, en la entrada: TP-LINK TL-WN725N v2 working on Raspberry Pi (Raspbian), donde se encuentran una lista con el driver para cada kernel y las instrucciones de instalación.

    3. Descomprimir el archivo

      Las últimas versiones del driver continen un fichero de módulo de kernel linux (.ko) y un fichero de firmware (.bin).

    4. Instalar el fichero de módulo de kernel linux

      # mv fichero.ko /lib/modules/version_del_kernel/kernel/drivers/net/wireless

    5. Instalar el fichero de firmware

      # mv fichero.bin /lib/firmware/rtlwifi/

    6. Añadir el módulo al kernel

      # depmod -a # modprobe 8188eu

      *Si al instalar el driver aparece el mensaje "Exec format error" es que la versión del driver no es la correcta para el kernel.

    7. Configurar la carga automática del módulo

      Editar el fichero /etc/modules (como root) y añadir la línea: 8188eu

    8. Reiniciar la raspberry

      # sudo reboot

  2. Configurar la red wifi
    1. Añadir la configuración al fichero /etc/network/interfaces

      Editar el fichero /etc/network/interfaces (como root) y añadir las siguientes líneas:

      allow-hotplug wlan0
      iface wlan0 inet manual
      wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
      iface default inet dhcp

      Consultar la información sobre la red

      # iwlist scan

      Este punto es muy importante. Con este comando se podemos consultar toda la información sobre una red wifi al alcance, por si tenemos alguna duda. Los puntos más importantes son los que nos ofrecen información sobre el tipo de cifrado utilizado:

      Group Cipher
      Pairwise Ciphers
      Authentication Suites

    2. Generar la clave WPA-PSK

      Vamos a generar una clave cifrada, para no dejar la clave de la red en plano en el fichero de configuración.

      # wpa_passphrase essid passphrase

      Anotamos la línea: psk=...

    3. Configurar wpa_supplicant

      Editar el fichero de configuración /etc/wpa_supplicant/wpa_supplicant.conf (O el que hayamos indicado en /etc/networking/interfaces) y añadir las siguientes líneas:

      network={
      ssid= nuestro_essid
      scan_ssid=1
      psk=clave_wpa_psk_generada_antes
      proto=RSN
      key_mgmt=WPA-PSK
      pairwise=CCMP TKIP
      group=CCMP TKIP
      }

      *En este apartado es dónde cobran importancia los datos sobre el cifrado de la red que hemos apuntado antes. Las configuraciones varían dependiendo del tipo de cifrado utilizado. Se puede encontrar más información en el man de wpa_supplicant

    4. Levantar la interfaz de red

      # ifup interfaz_de_red

Notas:

El driver USB utiliza memoria del kernel, y cuando el tráfico es muy alto, esta memoria se agota y causa cuelgues. Para solucionarlo hay dos alternativas:

  1. Adelantar la solicitud de memoria de página

    Para esto hay que editar el fichero /etc/sysctl.conf y modificar el valor de la línea

    vm.min_free_kbytes = 8192

    para dejarla:

    vm.min_free_kbytes = 16384

  2. Limitar el ancho de banda

    Esta opción es la menos apetecible. Pero cuando no hay otra alternativa... Podemos limitar cómodamente el ancho de banda de una tarjeta de red podemos utilizar wondershaper.

    # wondershaper wlan0 kbps_bajada kbps_subida

Enjoy!

Fuentes

sábado, 12 de julio de 2014

monitor dual en xfce4

En ocasiones, a algunos nos resulta útil y cómodo conectar un monitor externo a nuestro portátil. Para otros es la configuración habitual.

Los que utilizamos XFCE4 como entorno de escritorio, nos encontramos con un problema al conectar un monitor externo a nuestro portátil: Para XFCE4 el monitor principal siempre es el que se encuentra a la izquierda. Lo cual puede llegar a ser incómodo si queremos que nuestro monitor principal sea el de la derecha, como es mi caso.

Cuando conecto un monitor externo al portátil, utilizo la pantalla del portátil como monitor principal y el externo como secundario, para lo que surja. Mi idea es: Poder trabajar cómodamente en mi portátil, y, aprovechando que el monitor externo es más grande, poder utilizarlo para colocar en él el navegador, pdfs, vídeos...

Actualmente, mi monitor externo se encuentra situado a la izquierda de mi portátil. El problema es que, al tomar XFCE4 el monitor izquierdo como el principal, tenía que atravesar con el ratón los dos monitores para acceder a los paneles.

Una solución sería configurar el monitor externo como si se encontrase situado a la derecha del portátil. Pero es antiintiutivo, y he de decir, que para mi, demasiado incómodo. La idea de mover las aplicaciones y el ratón hacia la derecha para que aparezcan en el monitor de la izquierda, es algo que no me gusta. Prefiero mover las cosas que quiero visualizar en el monitor de la izquierda hacia la izquierda. Lógico, no? Para conseguir esto, basta con configurar un par de cosas, xrandr y los paneles de xfce:

  • xrandr
    xrandr --output VGA1 --auto --left-of LVDS1 *Siendo LVDS1 el monitor del portátil y VGA1 el monitor externo. *Este comando se pude guardar en un script para ejecutarlo cuando convenga o al inicio, si es la configuración habitual
  • Los paneles de XFCE y elegir la opción
    Ir a Menú>Configuración>Panel y elegir la opción: "Salida: LVDS1"

Enjoy!

sábado, 26 de abril de 2014

creando repositorios locales en git

Cuando desarrollamos código habitualmente, aunque no sea en equipo, una de las herramientas más útiles de las que disponemos es un sistema de control de versiones. Estas herramientas nos permiten controlar diferentes aspectos sobre nuestros proyectos: cambios, versiones, revisiones...

Aunque existen gran cantidad de sistemas de control de versiones, hoy en día uno de los más populares es git.


Cuando utlizamos una de estas herramientas, lo más habitual es subir y bajar el código del proyecto desde un servidor remoto, ya sea desde el espacio "en la nube" que nos ofrecen algunos servicios o desde otro equipo en el que se centralizan los desarrollos. Aunque el modelo cliente-servidor es la idea principal en la que se basan estos sistemas, en muchas ocasiones tendremos proyectos que no queramos añadir al servidor, o no dispondremos de un servidor o de una conexion a internet. En estos casos, para no perder la versatilidad que nos ofrecen los sistemas de control de versiones sobre el desarrollo, es muy útil disponer de un repositorio en la máquina local con el que poder trabajar.

Para crear un repositorio de git remoto en nuestra máquina ("en local"), primero deberemos crear un directorio que albergará todos los proyectos que queramos controlar: $ mkdir /ruta/.gitLocal *Yo lo dejo oculto para no verlo cada vez que entro en mi directorio de desarrollo

Después deberemos crear un repositorio para cada proyecto e inicializarlo: $ mkdir /ruta/.gitLocal/nombre_proyecto.git
$ cd /ruta/.gitLocal/nombre_proyecto.git
$ git init --bare --shared

Una vez creado e inicializado el repositorio remoto del proyecto, debemos ir al repositorio de trabajo del proyecto (es el directorio donde está el código -si ya existe alguno- o donde iremos desarrollando el proyecto) e inicializarlo $ cd /ruta_desarrollo/nombre_proyecto/
$ git init

En el caso de que ya exista código, deberemos añadir los ficheros y su primer commit: $ git add . *Con "." añadiremos todos los ficheros en el directorio actual.
*Si queremos ignorar ciertos archivos (por ejemplo ficheros de salida), tendremos que crear el fichero .gitignore y poner dentro que ficheros/directorios queremos ignorar. $ git commit -m "primer commit ;)"

Por último, deberemos "subir" los archivos del proyecto a nuestro repositorio remoto (en local): $ git remote add origin /ruta/.gitLocal/nombre_proyecto.git
$ git push origin master

Una vez que tenemos todo listo para empezar a trabajar con nuestro repositorio remoto en local, podemos comprobar que todo funciona correctamente yendo a un directorio cualquiera (por ejemplo /tmp) y clonando uno de los repositorios de nuestros proyectos: $ git clone /ruta/.gitLocal/nombre_proyecto.git

Enjoy!

domingo, 16 de febrero de 2014

compartiendo archivos en red con NFSv4 en debian

NFS (Network File System) es un protocolo utilizado para compartir archivos en red. Posibilita que sistemas distintos, conectados a la misma red, puedan acceder a ficheros remotos como si fuesen locales. Este protocolo está incluido por defecto en los sistemas operativos UNIX y en la mayoría de distribuciones GNU/Linux.

NFS es un protocolo cliente-servidor. El servidor comparte los recursos y el cliente (o clientes) puede acceder a los recursos. El acceso a los recursos es totalmente transparente para el cliente y todas las operaciones son síncronas. Es decir, una operación sólo retorna cuando el servidor ha completado todo el trabajo asociado.

La versión 4 de NFS (NFSv4) fue publicada en abril de 2003 y *no* es compatible con las versiones anteriores.

El uso de NFS, presenta una serie de ventajas e inconvenientes que tendremos que tener presentes antes de decidirnos a implementar esta tecnología:

Ventajas

  • Fácil de instalar y configurar
    Respecto a la instalación: Todos los archivos necesarios deberían estar disponibles en los repositorios de la distribución, llegando a estar instalado por defecto en muchas de ellas.
    Respecto a la configuración: En el lado del servidor, editando un único fichero se definen los recursos a compartir, las direcciones IP que pueden acceder a dicho recurso y los permisos que los clientes tendrán sobre éste. En la parte del cliente (si queremos que los recursos remotos se monten automáticamente, por ejemplo durante el arranque) sólo tendremos que editar el fichero /etc/fstab.
  • Más rápido que SSH
    NFS llega a ser un 30% más rápido que SSH
    *Aunque en las pruebas que yo he realizado se aproximaba más al 25% (sin optimizaciones).
    *Después de configurar correctamente los usuarios, en mis pruebas, sí que resulta un 30% más rápido. Además consume la mitad de CPU que SSH.
  • Fácil de utlizar
    Si nos encontramos en un escenario donde la persona que utiliza la máquina cliente es un usuario normal, al poder montar el recurso compartido como si fuese un recurso local más, su acceso será trivial y el usuario no tendrá la necesidad de complicarse aprendiendo a utilizar tecnologías como SSH, FTP, rsync o similares.

Desventajas

  • NFSv4 no es compatible con las versiones anteriores
    En la realidad nos encontramos con que, en algunos casos, se siguen utilizando NFSv2 y NFSv3.
  • Transmisión en plano
    NFS no va cifrado. En caso de encontrarnos en una red no fiable, o sobre la que pueda llegar a ser objetivo de ataques, sería más conveniente utilizar SSH, que al ir cifrado añade una capa de seguridad a las transmisiones.
  • Restricciones de acceso en base a la IP El servidor restringe el acceso a los recursos en base a la dirección IP de los clientes, pero estas direcciones pueden ser falsificadas con relativa facilidad. Una buena alternativa a esto sería utilizar SSH con claves RSA y/o un firewall bloqueando las falsificaciones de IP (ip spoofing).
  • El acceso de root
    Si el servidor NFS está mal configurado, un cliente que utilice el usuario root para acceder al recurso podrá acceder a todos los archivos, ya que el servidor confía en el nombre de usuario que le da el cliente.

Configurando NFSv4

El servidor

  1. Instalar nfs-kernel-server
    $ sudo aptitude install nfs-kernel-server *NFS se basa en RPC. Si no disponemos de un gestor de paquetes o éste no instala RPC, deberemos instalarlo manualmente.
  2. Editar los ficheros /etc/default/nfs-kernel-server y /etc/default/nfs-common
    Editar estos ficheros sólo debería ser necesario en caso de disponer (en el servidor) de un firewall basado en puertos (port-based firewall), del protocolo de autenticación Kerberos o de querer securizar NFS. Estos ficheros son auto explicativos, por lo que no voy a detallar su configuración. En https://wiki.debian.org/SecuringNFS podremos consultar más información sobre cómo securizar el servidor NFS.
  3. Configurar el fichero /etc/exports
    En este fichero se configurarán los directorios compartidos (exportados). La sintaxis es simple:
    /foo/bar maquina1(opcion1,opcion2,...) maquina2(...) ... Como podermos ver en los ejemplos de /etc/exports: /srv/nfs4 gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check) Para conocer en detalle las opciones disponibles, y su funcionamiento, podemos consultar el man, donde también podremos encontrar opciones para mejorar el rendimiento. $ man exports
  4. Reiniciar el servidor
    Una vez que los cambios están hehos, deberemos aplicarlos, bien reiniciando el servidor:
    $ sudo /etc/init.d/nfs-kernel-server start O bien, mefiante el comando exportfs:
    $ sudo exportfs -r

El cliente

  1. Instalar el paquete nfs-common $ sudo aptitude install nfs-common
  2. Montar el recurso remoto
    Podemos montar el recurso remoto manualmente, mediante el comando mount: $ sudo mount -t nfs servidor:/ /foo/bar * A mount le podremos pasar todas las opciones que consideremos oportunas.

    O, también, podremos añadir el recurso remoto en el fichero /etc/fstab para montarlo más cómodamente o durante el arranque: servidor:/ /foo/bar/ nfs opciones 0 0 * servidor: El nombre del servidor (si lo tenemos añadido en hosts), la URI o la dirección IP del servidor.
    * /foo/bar: El punto de montaje local.
    * opciones: Opciones de montaje.

Enjoy!

lunes, 10 de febrero de 2014

reparando errores del disco duro (gnu/linux)


¿Quién no ha sufrido algún error de disco duro alguna vez? Muchos optan por rendirse ante esta situación, aunque, en realidad, en muchos casos la información puede llegar a recuperarse totalmente, o podemos llegar a ganar algo de tiempo extra de utilización para ese disco. ¿Y quien no quiso en esa situación más tiempo para poder realizar una copia de seguridad o para poder seguir utilizando el equipo mientras no tiene otro disco?


Cuando hablamos de erroes en discos duros, lo primero que tenemos que hacer es distinguir entre errores lógicos y físicos. Los errores lógicos son los producidos a nivel de software (un superbloque corrupto, una partición eliminada, etc), mientras que los errores físicos son aquellos que se producen a nivel de hardware, daños directos en el disco (sectores, platos o mecanismos dañados).

Errores lógicos

Los errores lógicos suelen ser los más fácilmente recuperables, mientras no se haya formateado la partición. En este último caso ya tendríamos que utilizar herramientas específicas de recuperación de datos y ver qué información se puede salvar.
Dentro de los errores más comunes que nos encontramos en este apartado se encuentran tablas FAT o superbloques corruptos, particiones eliminadas, o sectores de arranque dañados o eliminados. Para reparar este tipo de errores mi herramienta preferida es testdisk. Testdisk es capaz de solucionar todos estos problemas (y algunos más) en un tiempo espectacularmente breve y, todo ello, siendo multiplataforma. Incluso dando soporte a sistemas RAID. En alguna ocasión, para estas tareas, también he utilizado gparted (que además dispone de una distribución en modo live). Y, aunque ha funcionado correctamente, he de confesar que me sentí un poco como Indiana Jones cuando cambiaba la estatuilla de oro por un saco de arena ;)

Errores físicos

Dentro de los errores físicos, principalmente nos podemos encontrar dos escenarios: Un disco duro con errores graves o un disco duro con algunos sectores dañados.

Si nos encontramos en el primer caso (un disco duro con el motor quemado o con platos rallados), lo único que podríamos hacer es sustituir estas piezas. Para ello habría que recurrir a empresas especializadas y sería sustancialmente caro. Por lo que deberíamos evaluar si el coste compensa la recuperación de la información perdida.

Cuando nos encontramos en el segundo caso (un disco con sectores dañados), es obvio que el disco empieza a fallar, lo más probable es que el fallo total sea sólo cuestión de tiempo. Lo primero que deberemos hacer es una copia de seguridad (o backup). Lo segundo, intentar reparar los errores.

Para reparar este tipo de errores yo utilizo e2fsck en combinación con badblocks. Badblocks (incluido en el proyecto e2fsprogs) genera una lista de los sectores dañados de un disco. Su principal ventaja es que esta lista puede ser leída por otras herramientas y que puede trabajar conjuntamente con e2fsck. Utilizando e2fsck conjuntamente con badblocks mediante el comando: # e2fsck -c /foo/bar/ podremos localizar y aislar los sectores defectuosos del disco, añadiéndolos automáticamente al inodo bad block para que no puedan ser utilizados por ningún fichero. Con esto habremos ganado algo de tiempo y podremos seguir utilizando el disco, sin preocuparnos por la corrupción de datos hasta su próximo fallo o su fallo total.

Lo ideal es prevenir este tipo de fallos, y para ello es recomendable realizar tests periódicamente con smartctl y/o badblocks.
Smartctl (incluído en el paquete smartmontools) controla y monitoriza la información S.M.A.R.T. (Self-Monitoring Analysis and Reporting Technology), una tecnología incluida en la mayoría de los discos duros. En mi opinión, es recomendable complementar estos test con badblocks, ya que más de una vez S.M.A.R.T. me ha devuleto un estado correcto para un disco duro dañado.

Aunque los test realizados por smartctl, se pueden realizar "en caliente" y sobre particiones montadas, los tests basados en badblocks es recomendable realizarlos sobre particiones desmontadas. Aunque dependiendo del test y del caso en particular se podrían realizar sobre particiones montadas en modo sólo lectura ("read only" o "ro").

*La duración de estos test va a depender de diversos factores. Smartctl dispone de test rápidos y tests largos, mientras que la duración de los test realizados por badblocks va a depender de la cantidad de datos almaceados en el disco.

Happy recovering! ;)