Sustitución de caracteres en nombres de ficheros:


find ./  -name '*:*' -execdir bash -c 'mv "$1" "${1//:/.}"' . {} \;

Visto aquí.

Spotify web player

Por motivos que no acierto a entender, el reproductor web de Spotify sigue basándose en flash para su funcionamiento. Por ello cuando intentamos abrir la aplicación nos indica en un bello mensaje:

"To enjoy Spotify please install Adobe Flash. It's free!" con un botón indicando "Get Flash"

Esto conlleva algunos fallos de seguridad y ha quedado obsoleto para múltiples sistemas. En cualquier caso incluso aceptando tales riesgos el navegador se empeña en no dejarlo funcionar.

Una alternativa es instalar la aplicación nativa. Por ahí hay alguna versión para debians (Ubuntu y sus variantes) e incluso algunos intentos para hacerlo funcional en opensuse. No obstante en muchos casos es deseable simplemente lanzar la aplicación web. El problema y una solución están bien descritos aquí. Pero en el caso presente, que me encuentro en una fase en la quiero depender cada vez menos de google-chrome y he regresado a firefox, me atañe el problema siguiente.

La solución la indican en el post:

NPAPI based Flash Player is required for Firefox. It isn't blocked as another user said. (The PPAPI version is for Chrome and Opera) Sometimes a flag isn't set right when Flash is installed or updated. With Flash installed, type "about:config" in the Firefox address bar and click the "I'll be careful" button. Search for "plugin.state.flash". You most likely will find the valure for this is "0". If you modify this to "1",(you can close that page now) you will find a refresh of the Spotify webplayer page will suddenly start working again.

Además de modificar esas claves, tuve que instalar flash-player-ppapi, que contiene el plugin de Flash para PPAPI (Pepper Plugin API, para navegadores como google-chrome) y freshplayerplugin, q traduce las capadidades de PPAPI para que funcione el firefox. Es un wrapper que implementa la adaptación para que el plugin PPAPI parezca un NPAPI (Netscape Plugin API). Ambos paquetes vienen de http://packman.links2linux.de.

Ahora funcionan maravillosamente. 

Tooltips ilegibles en KDE (afecta a Inkscape)

El problema es parecido a lo que se relata aquí. En mi caso afecta especialmente a Inkscape, que los menús de los tooltips se hacen ilegibles.

Después de googlear (cómo no), en el link de arriba se detalla la solución.

En configure desktop, elegir color:

En options deshabilitar Apply colors to non-Qt applications. Como la seda...

Instalar TauDEM en opensuse 42.1 leap

TERRAIN ANALYSIS USING DIGITAL ELEVATION MODELS (TAUDEM)

TauDEM (Terrain Analysis Using Digital Elevation Models) is un conjunto de herramientas para trabajar con DEMS y extraer y analizar información hidrológica a partir de la topografía, representada por el DEM. TauDEM permite, entre otras cosas:

- calcular paths de flujo (direcciones) y pendientes

- áreas o cuencas hidrológicas

- múltiples métodos para la delineación de redes de corrientes

Para una descripción detallada, visitar el sitio web de TauDEM en Utah State University.

- Emplea GDAL

- Puede realizar cálculos en coordendas geográficas y proyectadas

- Puede dividir el procesao en bandas gracias a la paralelización del código (MPI)

- Funciona el Windows PCs, laptops y clústers UNIX

- Funciona desde la línea de comandos y a partir de una GUI en ArcGIS

TauDEM se distribuye con makefiles para compilar en UNIX/Linux.

Existe una extensión para integrar TauDEM en Qgis. Es sencillo, hay que activar algunas configuraciones en el menú de processing:

Configuración de TauDEM en qgis (2.18.0 Las Palmas) en opensuse Leap 42.1

Es importante aumentar el número de cores para beneficiarse de la paralelización del código.

Es preciso compilar los binarios localmente. En el repositorio de TauDEM en github están las fuentes para compilar. Las dependencias son las siguientes (gracias a GIS-LAB):

The official TauDEM page says that to build the programs and their proper operation must be necessarily installed MPICH2 library. Experimentally, it was found that the other, more common in the Linux environment, a free implementation of the MPI, - OpenMPI - well suited for this task. In this case, it will be used OpenMPI, although the major Linux distributions include in their repositories and MPICH2.
So, to successfully compile a program, we need:
make - traditional for Linux build system;
cmake - more "advanced" assembly system;
gcc - a set of compilers, including, for C ++;
openmpi - OpenMPI executable files and a set of developer files.

sudo zypper install gcc gcc-c++ make cmake openmpi openmpi-devel

Al compilar me daba muchos errores con relación a los tipos de las variables. Tuve que editar el makefile e indicarle al compilador las directivas relativas a:

INCDIRS=`gdal-config --cflags`
LIBDIRS=-lgdal

Y ya. Luego podemos pasar a iniciar un análisis hodrológico con TauDEM en Qgis.

Otra herramienta para esto es TopoToolBox, escrita enteramente en MatLab, pero eso será tratado en otro post.

Salud!

Problemas con SOZI y otras extensiones en Inkscape 0.48.x para svgs con imágenes embebidas

Problemas con SOZI y otras extensiones en Inkscape 0.48.x para svgs con imágenes embebidas.

Para hacer una presentación con SOZI (extensión de Inkscape, http://sozi.baierouge.fr/) hay que tener cuidado con los links relativos a las imágenes. En un fichero normal, creado con Inkscape, los links son absolutos, de la siguiente manera:

xlink:href="file:///home/rleal/congresos/201404EGU/science/LogoIEO.png"

La forma de hacerlo relativo sería la siguiente (si el fichero svg está en /home/rleal/congresos/201404EGU:

xlink:href="./science/LogoIEO.png"

Y ya lo tenemos relativo.

Pero, por algún motivo puede ser interesante tener las imágenes embebidas. Por ejemplo, si vamos a distribuir el fichero y no queremos tener un montón de ficheros dependientes, o vamos a hacer una presentación y no nos interesa dejar un chorro de ficheros por ahí. En esos casos es bastante probable que el fichero generado (svg) tenga un tamaño bastante superior a 9.5 MB. Esto da errores en el XMLParser. Se ve en el sistema linux, que da más mensajes de debug, no así en Mac.

El error es algo parecido a:

Exception Type: XMLSyntaxError

Exception Value: internal error: Huge input lookup

El problema está documentado aquí libxml2-lxml-Parsing-large-9-5mb-XML-Documents. La solución está en using-python-lxml-etree-for-huge-xml-files. Se trata de

Try to create a custom XMLParser instance:

from lxml.etree import XMLParser, parse
p = XMLParser(huge_tree=True)
tree = parse('file.xml', parser=p)

En el caso particular de Inkscape 0.48.x, el fichero a retocar es /usr/share/inkscape/extensions/inkex.py.

En introducir la línea 66:

try:
    from lxml import etree
    p = etree.XMLParser(huge_tree=True)    <======

Luego, en la línea 131:

    def parse(self,file=None, parser=p):         <=======

Así ya puede parsear ficheros grandes. Y Sozi o cualquier extensión que quiera trabajar con ficheros grandes debería funcionar.

Que aproveche!

rleal

Acceder a IOMEGA NAS (Iomega StorCenter ix2) (II)

Actualización del post anterior. Con la vuelta a la normalidad de los servicios de informática locales hemos podido acceder al firewall y abrirle los puertos necesarios para que el NAS funcione como es debido. Primero le asignamos una IP fija local en el dominio del cd.ieo.es (a través de la MAC) para luego darle salida a través de los puertos correspondientes (21 para ftp y 22 para ssh). De momento lo tengo redireccionado también en TZO pero en breve le daremos un nombre propio.

El cliente de linux de StorCenter no va demasiado fino. De momento no lo usamos para nada. Igual en el futuro cuando mejoren las cosas lo podamos implementar, pero por ahora no es práctico. Sí que va bien el cliente para android, cosa extraña.

AFAIK, estos son los puertos involucrados:

• 443 (TCP) El manual dice que es necesario pero no está abierto.
• 50500-50510 (TCP/UDP). Es necesario para el PersonalCloud, pero lo tenemos cerrado de momento.
• 20-21 (TCP/UCP) para el ftp. Aunque he leído por ahí que no es seguro y que es mejor cerrarlo si no se va a usar ftp. De momento lo tenemos abierto (el 21).
• 445 (TCP) para acceder a shares de SMB / CIFS (se trata de windows file sharing en protocols). Por lo visto es un coladero y el informático nos lo ha dejado cerrado. Sólo podremos usar este protocolo en local, no para las conexiones que pasen a través del firewall.
• 22 (TCP/UCP) para acceder a shares de SFTP y SSH. Este método es seguro. Para esto hay que activar en http://fisicaieo.iomegalink.com/protocols.html?cat=network SFTP. 
• 22 (TCP/UCP) para acceder a la unidad a través de SSH. Para ello en https://fisicaieo.iomegalink.com/diagnostics.html tenemos que activar remote access support (SSH y SFTP). Como SSH va también por el puerto SSH 22 esto implica que hay que desactivar antes SFTP. Ambas opciones son mutuamente exclusivas. Si el 22 se dedica a ssh no podemos montar la unidad por sshfs (va por sftp) por eso vamos a tener que ir cambiando alternativamente a no ser que podamos asignarle otro puerto. Antiguamente y o usaba otro puerto (el 23) para SST pero Javi nos nos deja ese puerto porque es el que está inicialmente asignado para TELNET. Por eso, si queremos entrar por ssh, además de activar este remote access suport, en http://fisicaieo.iomegalink.com/protocols.html?cat=network es IMPRESCINDIBLE desactivar SFTP. Doble checkear para verificar que están ambos bien. Si no lo hacemos, aunque podamos montar el share a través de sshfs, no podremos acceder a la unidad desde ssh.

Para acceder por ssh:
rleal@poseidon:~$ ssh root@fisicaieo.iomegalink.com

The authenticity of host 'fisicaieo.iomegalink.com (193.146.150.135)' can't be established.

RSA key fingerprint is 1d:cf:0f:4b:e0:96:cd:46:d9:06:13:65:eb:28:e2:25.

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added 'fisicaieo.iomegalink.com' (RSA) to the list of known hosts.

root@fisicaieo.iomegalink.com's password: 

La contraseña es soho seguido de la contraseña de administrador de la unidad. Entramos como root.

root@UNDINE:/# whoami
root

Otro problema es que no puedo crear symlinks cuando monto como sshfs. No sé cuál es el motivo. Parece una cuestión de permisos pero a lo mejor es que FUSE no permite su creación. No sé, me pierdo ahí. He abierto un hilo en LQ, a ver si me dan una solución (http://www.linuxquestions.org/questions/linux-general-1/cannot-create-symlinks-in-a-nas-share-mounted-over-sshfs-4175422283/). De momento lo que queda es hacer el rsync (que es para lo que yo quiero el disco) desde el dominio (montado como CIFS).

Acceder a IOMEGA NAS (Iomega StorCenter ix2)

Hace unos meses compramos un Iomega StorCenter ix2 como éste. En principio no teníamos forma de colocarlo en red. En el dominio del cd.ieo.es había que asignarle una IP fija (a través de la MAC, porque el servidor DHCP lógicamente la variaba cada poco), y luego darle salida a través de los puertos correspondientes, con una IP fija externa. El caso es que después de batallar con los servicios de informática, nada. Conseguimos sacarlo y abrir algunos puertos, pero desde luego que no fue posible hacerlo andar fuera del dominio. Es decir, podíamos verlo pero éramos incapaces de montarlo como una unidad local (o directorio) ni tan siquiera hacer uso del tan pomposo IOmegaPersonalCloud de los güevos. El problema radica según el informático local en que él no tiene acceso al router ni el firewall. No puede asignar ni redireccionar puertos ni nada de eso. Eso dice. Todo lo gestionan desde Siemens (puede ser...).

Se hicieron multitud de pruebas. Finalmente decidí llevármelo a casa, porque allí tengo acceso total al router. Otra cosa es el bloqueo de puertos que me pudiera hacer mi ISP (en este caso ONO). Pero aparentemente todo bien.

Pues no sé si vale la pena redactar todas las peripecias. Quizá no. Avanzo para decir un par de cosas.

• En windows parece que funciona bien lo del IomegaPersonalCloud. Ahora bien, lo he estado probando desde casa. Por más que me intentaba conectar al dominio de tzo (fisicaieo.iomegalink.com) el hijoputa lo reconoce como unidad local. Cuánto sabe!! Habría que ver cómo va desde fuera.
• El cliente de linux de StorCenter no va demasiado fino. No sé cuál puede ser el problema. Reconoce la unidad si le apuntamos la dirección. Después de una instalación "fresh" es capaz de configurar la cloud. Pero si reiniciamos nada, hay que reinstalar. Aún así no fui capaz de conectarlo desde la calle. Sólo cuando abrí el 445, como digo un poco más adelante. EL problema puede ser que sólo funciona bien para máquinas de 32 bits. Me costó encontrar ésto!

Lo primero que hice es asignar una IP fija a la MAC del disco. Le asigné la 192.168.1.250.

Luego tuve que abrir manualmente un par de puertos por cojones, porque si no no funciona nada de nada.

Los puertos que abrí (redirigí al 192.168.1.250) son los siguientes:

443 (TCP) No sé si es necesario, el manual dice que sí. Pos nada.

50500-50510 (TCP/UDP). Es necesario para el PersonalCloud.

20-21 (TCP/UCP) para el ftp. Aunque he leído por ahí que no es seguro y que es mejor cerrarlo si no se va a usar ftp

445 (TCP) para acceder a shares de SMB / CIFS desde la calle. Esta fue la que me dio la pista de porqué los problemas. Aunque en internet dicen que es un coladero y quizá lo deje cerrado. Se trata de windows file sharing en protocols

22 (TCP) para acceder a shares de SFTP. Este método parece bastante seguro. Para esto hay que activar en

23 (TCP/UCP) para acceder a SSH. Hay que decirle en https://192.168.1.250/diagnostics.html que active remote access support (SSH y SFTP) por el puerto SSH 23. No le damos el 22 para evitar conflictos con el SFTP.

Para conectarse en local...

#//192.168.1.250/Backups /home/rleal/backups cifs username=myusername,password=mypassword,_netdev,uid=myusername,gid=users 0 0

Para conectarse en remoto o desde otro sitio...

#//fisicaieo.iomegalink.com/Backups /home/rleal/backups cifs username=myusername,password=mypassword,_netdev,uid=myusername,gid=users 0 0

Dando un paso más valiente intenté conectarme desde sftp o ssh. Bueno, tengo que reconocer que instalé la última versión del firmware para el aparatejo 3.2.xxx, que tiene soporte para sftp y ssh. Aunque IOmega invalida la garantía si toqueteamos en ssh!!

Para conectarse en local...

sshfs#myusername@f192.168.1.250:/pools/A/A0/Backups /home/rleal/backups fuse defaults,idmap=user 0 0

Para conectarse en remoto o desde otro sitio...

sshfs#myusername@fisicaieo.iomegalink.com:/pools/A/A0/Backups /home/rleal/backups fuse defaults,idmap=user 0 0

Por cierto, para que esto funcione hay que activar tanto en protocols/ftp el sftp y en diagnostics.html el ssh ysftp.

Cosa fea: las conexiones por ssh o sftp te llevan a un sitio (pools) donde lo único que hay es /pools/A/A0 y ahí están las carpetas a las que tienes acceso.

Se pueden montar desde la línea de comandos o desde fstab. El problema con sshfs es que de momento pasan dos cosas: me pide la contraseña del usuario y no me da permisos ni de lectura. Lo primero se puede arreglar con la generación de claves de ssh. Lo segundo, estoy en ello. A ver si soy capaz de arreglarlo.

De momento una opción es montarlo por sshfs de la siguiente manera:

sshfs -o idmap=user rleal@fisicaieo.iomegalink.com:/pools/A/A0/Backups backups

y ya tengo acceso.

El tercer problema es que es un rollo que me lleve a pools, en lugar de que te lleve al raiz de los directorios a los que tiene permiso. A ver si soy capaz de tunear esto. Aquí se la juega uno porque cualquier cosa que se toquetee aquí tiene que ser por ssh, y así se invalida la garantía.

Otra cosa, en https://192.168.1.250/diagnostics.html o en https://fisicaieo.iomegalink.com/diagnostics.html se puede apañar el acceso a través de ssh o sftp. Por cierto, no se puede activar sftp y ssh a la vez; por defecto ambos van por el puerto 22. Una opción es que el ssh vaya por el 23, que es lo que he hecho, como se dice un poco más arriba.

En principio así todo bien.

Ahora a ver porqué no funciona el NFS. Aunque de momento da igual.