26 noviembre 2016

udiskctl - Cómo montar discos usb cuando estamos en linea de comando y los habíamos montado en el escritorio

Actualmente estoy utilizando (probando) Ubuntu 16.04. No me parece una mala distribución, teniendo en cuenta que yo era una persona que lo hacía casi todo a mano y me estoy adaptando a que Ubuntu lo haga casi todo por mi automáticmaente

Una de las cosas que hace por mi es montar los discos usb externos. No hace falta que le de ninguna indicación, y él sólo coge el nombre del volumen y lo monta en la ruta /media/usuario/Nombre del Volumen. No necesito editar fstab ni estar haciendo cosas extrañas (entiendo que las últimas versiones de Fedora y de OpenSuse también lo hacen, pero mi experiencia actual es con Ubuntu)

Cuando estás en el escritorio, está muy bien, pero hay veces, que estoy utilizando mi ordenador del trabajo (que tiene Windows) y me quiero conectar a mi ordenador personal y acceder a un disco USB que está conectado.

Pues bien, una de estas veces me encontré a mi mujer logueada, y el disco que tenía montado con propiedad de mi usuario, en una ruta para mí, estaba montado con el propietario del usuario de mi mujer, y la ruta había cambiado para su usuario.

Directamente lo desmonté con el usuario root, pero no tenía ni idea de cómo podía replicar el comportamiento del escritorio en línea de comando sin tener que volver a editar fstab y opciones de montaje, etc ,etc...

Buscando un poco encontré udisks , que provee interfaces para acceso a dispositivos de almacenamiento y discos. Cualquier aplicación puede acceder al demonio udisksd a través de udisks.

Todo esto está muy bien, pero seguía sin saber cómo acceder. Buscando un poco más encontré udisksctl , que es un comando que permite interactuar con udisks en línea de comando.

Su uso es muy fácil:

jose@r2d2:~$ udisksctl mount -b /dev/sdb1
==== AUTHENTICATING FOR org.freedesktop.udisks2.filesystem-mount-other-seat ===
Para montar TOSHIBA MQ01UBD100 (/dev/sdb1) necesita autenticarse
Multiple identities can be used for authentication:
 1.  Jose ,,, (jose)
 2.  Vanesa ,,, (vanesa)
Choose identity to authenticate as (1-2): 1
Password:
==== AUTHENTICATION COMPLETE ===
Mounted /dev/sdb1 at /media/jose/virtualizacion.
jose@r2d2:~$ l

Simplemente hay que saber el dispositivo de bloque que se corresponde a nuestro disco USB y lo podremos montar con nuestro usuario como si estuviéramos en el escritorio.

10 junio 2016

Cómo utilizar ansible con Vagrant

Desde que conocí Vagrant, me ha parecido un software muy útil para preparar pequeñas maquetas con máquinas virtuales que tengan que "vivir" y "morir" rápidamente.

Además si en nuestra máquina disponemos de ansible, podemos aprovechar para provisionar lo que queramos en nuestra/s máquinas virtuales.

Por supuesto, lo mismo lo podemos hacer con scripts de bash, pero lo interesante de utilizar ansible es que podemos reutilizar playbooks que tengamos para otros despliegues.

Todo se ve mejor con un ejemplo.

El primer paso es crear la carpeta vagrant-ansible. La podemos llamar así, o la podemos llamar como queramos, pero poniendo un nombre descriptivo sabremos por dónde nos estamos moviendo...

 # mkdir vagrant-ansible  



Una vez hecho esto, debemos situarnos en el directorio recientemente creado y crear un vagrant file:

 # vagrant init centos/7  



Con esto creamos el vagrantfile básico para instalar un box con centos 7.

Personalizamos el fichero tanto como queramos, pero la parte más importante, viene al final donde indicamos que vamos  a provisionar con ansible:

 config.vm.provision "ansible" do |ansible|  
  ansible.playbook="playbook.yml"  
  end  
 end  


Con estas últimas líneas (el último end es el propio del fichero), estamos indicando en el fichero de configuración que vamos a utilizar ansible y que vamos autilizar el playbook llamado (imaginativamente)  playbook.yml. Este playbook estará en el mismo sitio donde esté el Vagrantfile, y contendrá la información que queramos de despliegue de la o las máquinas.


15 octubre 2013

Consideraciones nginx con soporte php y mysql en Fedora 19

Hace tiempo que escribí varios posts sobre la instalación de nginx con soporte de php. Eran otros tiempos y nginx era mucho menos popular, conseguir soporte de php mediante fastcgi era un poco más complicado, aunque finalmente el resultado era satisfactorio.

Últimamente trabajo más con apache y quería darle un repaso a cómo está en la actualidad nginx y aprovechando un par de máquinas virtuales que tengo montadas con kvm, me he puesto manos a la obra.

En primer lugar ha sido una grata sorpresa el ver que tengo todos los paquetes necesarios en los repositorios de Fedora. Lo sospechaba, por algún artículo que había leído sobre ello y el utilizar el yum para instalar simplmemente lo constató-

Una vez superado el paso de la instalación, procedo a instalar php-fpm, que es la "nueva" manera "enganchar" con php nginx.

Aquí comienzan a suceder cosas extrañas. Intento acceder a un "index.php" con un "phpinfo()", y muestra una página en blanco. Analizo los logs y veo que tengo código 200, pero no me muestra nada. Me sumerjo en los foros, y al final encuentro el error.

En la línea de php correspondiente a la ejecución del script, en el fichero de configuración trae esta línea:

fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;

Esta línea hay que cambiarla por ésta:

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;


Una pequeña tontería, pero que me tenía un poco parado, porque no sabía por dónde seguir

Después continué con php y también pude ver un par de cosas "raras".

Como no tenía soporte de mysql decidí instalar el módulo necesario para tener soporte. Cuando lo hice pude observar, que en la configuración de php me indica que no tiene soporte de php, sin embargo, si bajamos en la página del phpinfo, podemos ver que sí tengo soporte php.


En esta captura podemos ver todo lo que me indica que está deshabilitado, incluído el soporte gd:



A continuación se puede ver cómo si tengo soporte de gd y de mysql, por ejemplo:





Son pequeñas tonterías, que no molestan demasiado, pero cuando llevas un tiempo alejado de esta manera de tener soporte de php, te sorprenden un poc.

Supongo que profundizando en la documentación se podrá encontrar la respuesta a este comportamiento, así que en cuanto tenga un ratillo investigo un poco más a ver que sacamos en claro.

23 abril 2013

Cómo se puede emular la perdida de un disco externo en Linux

Una de las pruebas de certificación de los Clusters de Oracle es observar el comportamiento ante la pérdida de uno de los voting disk.

Estos discos normalmente se presentan a los servidores desde cabinas de almacenamiento externo y suelen tener varios caminos (dependiendo de las tarjetas HBA que dispongamos en el sistema).

Para emular la caída de un disco simplemente tenemos que enviar comandos scsi al dispositivo de bloque, indicándole que cambie su estado a offline.

Vamos a ver un ejemplo:


Primero buscamos nuestro disco objetivo. En un entorno Red Hat ejecutaríamos el comando "multipath -ll"

CRS1 (20017380050d10023) dm-2 IBM,2810XIV
size=16G features='0' hwhandler='0' wp=rw
|-+- policy='round-robin 0' prio=1 status=enabled
| `- 7:0:0:1 sdb 8:16  active ready running
|-+- policy='round-robin 0' prio=1 status=enabled
| `- 8:0:0:1 sdf 8:80  active ready running
|-+- policy='round-robin 0' prio=1 status=enabled
| `- 7:0:1:1 sdj 8:144 active ready running
`-+- policy='round-robin 0' prio=1 status=active
  `- 8:0:1:1 sdn 8:208 active ready running

Podemos ver que los distintos caminos se corresponden a los dispositivos de bloque "sdb, sdf, sdj, sdn".

Ahora tenemos que poner offline cada uno de los caminos, para ello haríamos esto con cada uno (sólo mostramos el último):

# echo offline > /sys/class/block/sdn/device/state

Si hacemos un cat al fichero "state" de cada uno de los dispositivos, podremos ver que están "offline".

En "messages" veríamos estos mensajes:

Apr 23 15:54:00 server kernel: sd 7:0:0:1: rejecting I/O to offline device
Apr 23 15:54:00 server kernel: device-mapper: multipath: Failing path 8:16.
Apr 23 15:54:00 server multipathd: 8:16: mark as failed
Apr 23 15:54:00 server multipathd: CRS1: remaining active paths: 3
Apr 23 15:54:10 server kernel: sd 8:0:0:1: rejecting I/O to offline device
Apr 23 15:54:10 server kernel: device-mapper: multipath: Failing path 8:80.
Apr 23 15:54:10 server multipathd: 8:80: mark as failed
Apr 23 15:54:10 server multipathd: CRS1: remaining active paths: 2
Apr 23 15:54:18 server kernel: sd 7:0:1:1: rejecting I/O to offline device
Apr 23 15:54:18 server kernel: device-mapper: multipath: Failing path 8:144.
Apr 23 15:54:18 server multipathd: 8:144: mark as failed
Apr 23 15:54:18 server multipathd: CRS1: remaining active paths: 1
Apr 23 15:54:32 server kernel: sd 8:0:1:1: rejecting I/O to offline device
Apr 23 15:54:32 server kernel: device-mapper: multipath: Failing path 8:208.
Apr 23 15:54:32 server kernel: end_request: I/O error, dev dm-2, sector 524368
Apr 23 15:54:32 server multipathd: 8:208: mark as failed
Apr 23 15:54:32 server multipathd: CRS1: remaining active paths: 0
Apr 23 15:54:33 server kernel: end_request: I/O error, dev dm-2, sector 0
Apr 23 15:54:33 server kernel: end_request: I/O error, dev dm-2, sector 4151

Para ponerlos en en el estado normal ejecutaríamos en cada dispositivo:


# echo running > /sys/class/block/sdn/device/state


Y veríamos en "messages" la recuperación:

Apr 23 16:05:01 server multipathd: CRS1: sdn - directio checker reports path is up
Apr 23 16:05:01 server multipathd: 8:208: reinstated
Apr 23 16:05:01 server multipathd: CRS1: remaining active paths: 1
Apr 23 16:05:14 server multipathd: CRS1: sdj - directio checker reports path is up
Apr 23 16:05:14 server multipathd: 8:144: reinstated
Apr 23 16:05:14 server multipathd: CRS1: remaining active paths: 2
Apr 23 16:05:25 server multipathd: CRS1: sdf - directio checker reports path is up
Apr 23 16:05:25 server multipathd: 8:80: reinstated
Apr 23 16:05:25 server multipathd: CRS1: remaining active paths: 3
Apr 23 16:05:40 server multipathd: CRS1: sdb - directio checker reports path is up
Apr 23 16:05:40 server multipathd: 8:16: reinstated
Apr 23 16:05:40 server multipathd: CRS1: remaining active paths: 4


04 octubre 2012

¿Qué es lo invisible?

Gracias al TED encontré un vídeo muy interesante de dibujos animados explicando cómo hay muchas cosas invisibles para nosotros y tratando de hacer que las comprendamos aunque sea un poquito.