martes, 2 de septiembre de 2014

TP-Link WA901ND v3 OpenWRT

 
Qué es OpenWRT

OpenWrt es una distribución de Linux basada en firmware usada para dispositivos empotrados tales como routers personales.
El soporte fue limitado originalmente al modelo Linksys WRT54G, pero desde su rápida expansión se ha incluido soporte para otros fabricantes y dispositivos, incluidos el Netgear, D-Link, ASUS y algunos otros. El router más popular sigue siendo el Linksys WRT54G y el ASUS WL500G. OpenWrt utiliza principalmente una interfaz de línea de comando, pero también dispone de una interfaz WEB en constante mejora. El soporte técnico es provisto como en la mayoría de los proyectos de Software Libre, a través de foros y su canal IRC.

Motivación

Después de usar durante algún tiempo el firmware DDWRT en un Linksys WRT54G, decidí probar OpenWRT.

Tengo 2 WRT54G, con versión 1.0 y 5.1. Lamentablemente no es posible correr DDWRT en la versión 5.1, así que, o bien tocaba comprar otro punto de acceso o me quedaba como estaba. Finalmente adquirí un TP-Link WA901ND v3 y la verdad, es que con OpenWRT estoy encantado.

Por vía oficial, si observáis la tabla de hardware soportado por OpenWRT , comprobaréis que no hay ni rastro de la versión 3 del firmware. Pero, rasterando los foros me encontrado esta maravilla, que es sin duda, la motivación principal para escribir este post. La segunda es dejarle la chuleta a mi amiguete @probatto , que últimamente es muy "TP-Linkero", y estoy seguro que le servirá de ayuda!

Pasos para instalar el firmware OpenWRT en un TP-Link WA901ND

Lo primero es descargar el fichero openwrt-ar71xx-generic-tl-wa901nd-v3-squashfs-factory.bin. He subido una copia del mismo aquí



La suma MD5 es:

0542e4e23567263f2d64169e9245e03b 

Importante: este fichero(*****v3-squashfs-factory.bin) es que usaremos si no hemos modificado el firmware original.

El segundo paso acceder a la interfaz web de administración del punto de acceso. En mi caso tengo un servidor DHCP autoritativo en la red, así que el WA901ND recibió sin problemas la configuración IPv4.

¿Cómo puedo saber la IPv4 del dispositivo? Con nmap es muy sencillo:

Starting Nmap 6.40 ( http://nmap.org ) at 2014-09-02 20:14 CEST
Nmap scan report for 192.168.20.13
Host is up (-0.087s latency).
MAC Address: E8:94:F6:BB:D4:1E (Tp-link Technologies Co.)
 
Nmap done: 256 IP addresses (6 hosts up) scanned in 3.97 seconds

Ahora, usando nuestro navegador favorito ya podemos acceder a la interfaz web de administración con el usuario: admin y contraseña: admin vía:

http://192.168.20.13 


En el menú System Tools, link "Firmware upgrade" podemos iniciar el proceso de actualización del firmware. Muy importante no apagar el dispositivo. Una vez finalizado observaremos una pantalla similar a :


Transcurrido un par de minutos, el dispositivo se reiniciará y arrancará con la dirección IPv4 192.168.1.1 y máscara de subred de 24 bits 255.255.255.0. En GNU/Linux no necesitamos modificar la configuración de nuestra tarjeta ethernet, basta con crear una subinterfaz en la misma subred que el TP-Link

ifconfig eth0:1 192.168.1.200 netmask 255.255.255.0 up

Por defecto, no arranca con SSH sino con telnet, así que para acceder al terminal del flamante OpenWRT

telnet 192.168.1.1



Ahora debemos establecer una contraseña de "root" para poder acceder vía SSH.


passwd root

El tercer paso es actualizar el firmware descargando este fichero:


http://ooxion.com/openwrt/wax50re/openwrt-ar71xx-generic-tl-wa901nd-v3-squashfs-sysupgrade.bin

He subido también una copia a :

https://dl.dropboxusercontent.com/u/6108202/openwrt-ar71xx-generic-tl-wa901nd-v3-squashfs-sysupgrade.bin

La suma MD5 del fichero es:

e1543c33b8901b3e8f4b76d67889f000

Ahora debemos copiar el fichero vía scp:

scp openwrt-ar71xx-generic-tl-wa901nd-v3-squashfs-sysupgrade.bin root@192.168.1.1:/tmp

y actualizar el firmware:

cd /tmp

mtd write openwrt-ar71xx-generic-tl-wa901nd-v3-squashfs-sysupgrade.bin firmware

Una vez finalizado el proceso, debemos conectarnos vía telnet y activar SSH, y establecer password de "root"

telnet 192.168.1.1

y es conectar el dispositivo a Internet. Muy sencillo estableciendo una subinterfaz sobre la existente br-lan :

ifconfig br-lan:1 192.168.20.90 netmask 255.255.255.0 
route add default gw 192.168.20.1
echo "nameserver 8.8.8.8" > /etc/resolv.conf

 En este ejemplo:

192.168.20.90 => IPv4 para la subinterfaz br-lan:1 
192.168.20.1 => IPv4 del router con acceso a Internet
8.8.8.8 => DNS de Google. Puedes indicar el de tu proveedor de Internet.

El último paso es iniciar el servidor web para poder acceder al GUI y configurar el proceso para que se inicie al arrancar el dispositivo. Si accedemos vía http a la dirección IPv4 del punto de acceso ya podemos configurar el TP-Link WA901ND con el flamante firmware OpenWRT.

[ Detalle pantalla "Status" ]



 [ Detalle pantalla "Interfaces" ]
 


martes, 29 de julio de 2014

Bridge con Raspberry Pi



Llevaba tiempo dándole vueltas a configurar la Raspberry Pi en modo bridge para extender la red "casera" y poder usar un tercer punto de acceso sin necesidad de adquirir un nuevo switch.

El pasado mes de mayo @biokeko me regaló una tarjeta 10/100/1000 USB 3.0 y con esta, más el "Pi" y un poco de tiempo robado al fin de semana he conseguido configurar la Raspberry como "puente".

¿Qué es un "bridge"?

Un bridge ethernet es el análogo a un switch ethernet físico. Trabaja a nivel de capa 2 en el modelo OSI y podríamos definirlo como un switch por software que se utiliza para conectar múltiples interfaces ethernet (físicas o virtuales).

¿Cómo instalo el software necesario?

He usado y uso exclusivamente Raspbian. Desde consola y como root:

  • apt-get update
  • apt-get -y install bridge-utils
¿Qué ficheros necesito modificar?

En mi caso particular, tengo 2 interfaces de red : eth0 es la nativa de RaspberryPi y eth1 es la interfaz USB.

Basta con modificar /etc/network/interfaces :

auto lo

iface lo inet loopback

iface eth0 inet manual

iface eth1 inet manual

#Configuración bridge
auto br0
iface br0 inet static
        bridge_ports eth0 eth1
        address 192.168.20.251
        broadcast 192.168.20.255
        netmask 255.255.255.0
        gateway 192.168.20.1



Si reinicias(no es necesario) tu dispositivo tendrás el "puente" activo.

Algunos comandos interesantes:

Mostrar estado del bridge
root@raspberrypi:/home/pi# brctl show
bridge name    bridge id                       STP enabled    interfaces
br0                   8000.0023554c4039    no                     eth0

                                                                                   eth1


Mostrar las "macs" que "ha aprendido" nuestro "bridge"
root@raspberrypi:/home/pi# brctl showmacs br0
port no    mac addr        is local?    ageing timer
  1    00:1a:a0:a3:89:4b    no           6.86
  1    00:1e:c2:16:4c:cf    no           0.01
  2    00:23:55:4c:40:39    yes           0.00
  2    78:d6:f0:26:a8:35    no          37.36
  1    ac:3c:0b:1e:59:86    no           6.25
  1    b8:27:eb:b0:52:bb    yes           0.00
  1    bc:14:01:bb:ae:85    no          15.03
  2    e8:94:f6:93:93:ef    no          15.06




...y el clásico "brctl help"os ayudará con temas como STP o añadir manualmente interfaces al "puente".

Para este ejemplo, el comando ifconfig devuelve

root@raspberrypi:/home/pi# ifconfig
br0     Link encap:Ethernet  HWaddr 00:23:55:4c:40:39 
          inet addr:192.168.20.251  Bcast:192.168.20.255  Mask:255.255.255.0
          inet6 addr: fe80::223:55ff:fe4c:4039/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:16922 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4210 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:14341787 (13.6 MiB)  TX bytes:361541 (353.0 KiB)

eth0      Link encap:Ethernet  HWaddr b8:27:eb:b0:52:bb 
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:25168 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11978 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:19662264 (18.7 MiB)  TX bytes:2478027 (2.3 MiB)

eth1      Link encap:Ethernet  HWaddr 00:23:55:4c:40:39 
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:7773 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12210 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1917220 (1.8 MiB)  TX bytes:5398632 (5.1 MiB)

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:17 errors:0 dropped:0 overruns:0 frame:0
          TX packets:17 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:3626 (3.5 KiB)  TX bytes:3626 (3.5 KiB)

BONUS

lunes, 5 de mayo de 2014

Cliente bittorrent en modo CLI e interfaz web: Transmission

http://www.transmissionbt.com/
Seguro que muchos de vosotros conocéis Transmission, desde hace años, desde mi punto de vista unos de los mejores clientes de protocolo bittorrent que existen.

Estoy reestructurando el servidor Debian GNU/Linux que tenemos en casa, actualizando servicios e incluyendo otros que, bien por desconocimiento o por falta de tiempo, no estaban hasta ahora configurados.

Buscando un cliente bittorrent en modo CLI me he topado con infinidad de paquetes muy interesantes, pero carentes, en su gran mayoría de una interfaz web sencilla e intuitiva.

Conocía la interfaz web de de Transmission, pero desconocía que se podía instalar sin entorno gráfico y gestionarlo vía http.

En Debian GNU/Linux Wheezy lo he configurado del siguiente modo:

  1. apt-get update
  2. apt-get install transmission-cli transmission-common transmission-daemon
Con estos dos pasos ya hemos instalado la versión CLI de Transmission. El fichero de configuración podemos encontrarlo en el directorio /etc/transmission-daemon/settings.json . En mi caso particular he modificado los siguientes parámetros:

"blocklist-enabled": false,  

Para permitir el acceso desde cualquier IP. Ojo a los riesgos de seguridad. En mi caso, esta dentro de una LAN sin acceso externo.

"download-dir": "/storage/Descargas",
"incomplete-dir": "/storage/Descargas/incompletas",

Para indicar el directorio de descargas completas e incompletas.

Para realizar una prueba podemos ejecutar desde CLI:

transmission-daemon -f -t -u user -v pass -w /storage/Descargas -g /etc/transmission-daemon/

Donde:
-f : Indica que se ejecutará en primer plano escribiendo errores en stdout
-t : Indica que los clientes necesitan autenticarse
-u: Indica el nombre de usuario
-v: Indica el password del usuario 
-w: Indica el directorio de descargas
-g : Indica el fichero de configuración

Más información con el comando :
man transmission-daemon

 [ Ejemplo de acceso vía web desde Mozilla Firefox ]

Por último, para iniciar transmission-daemon al arrancar el equipo basta con añadir :

transmission-daemon -f -t -u user -v pass -w /storage/Descargas -g /etc/transmission-daemon/

al fichero /etc/rc.local antes del "exit 0". No he probado a eliminar el parámetro -f. Como último comentario señalar que lo suyo sería crear un script en init.d o insserv. Ahora no tengo tiempo, pero si os interesa este tema tenéis más información en este link.




domingo, 4 de mayo de 2014

minidlna: servidor DLNA para Debian Wheezy


Si no sabéis que es DLNA os recomiendo leer en primer lugar la entrada de la entrada de Wikipedia , y en segundo lugar este breve artículo en Xataka: ¿Qué es DLNA y para que lo puedo usar en casa?.

Instalar un servidor DLNA en Debian Wheezy es muy sencillo pues incluye el paquete "minidlna". Sin embargo en la versión 1.0.X incluida en Debian, he observado que tanto en rendimiento con el servicio de descubrimiento desde VLC es bastante pobre, por lo que decidido compilar el paquete desde los fuentes.

Los pasos para la compilación e instalación son los siguientes:
  1. Descargar el paquete desde el sitio web oficial del proyecto. http://sourceforge.net/projects/minidlna/
  2. Descomprimir el paquete : tar zxvf minidlna-1.1.2.tar.gz
  3. cd minidlna
  4. Instalar dependencias : apt-get  build-dep minidlna
  5. ./configure && make && make install
  6. cp linux/minidlna.init.d.script /etc/init.d/minidlna 
  7. update-rc.d minidlna defaults
  8. cp minidlna.conf /etc 
Ahora podemos editar el fichero /etc/minidlna.conf a nuestro gusto e iniciar "minidlna" con el comando /etc/init.d/minidlna start o service minidlna restart 

Para OSX o Linux  VLC es una buena opción para reproducir los contenidos de nuestro servidor. Para Android estoy utilizando la aplicación Skifta.


viernes, 14 de marzo de 2014

Glances: échale un ojo a tu sistema Linux

https://github.com/nicolargo/glances

Tengo la suerte de poder administrar un montón de máquinas Linux, corriendo desde RHEL, Debian GNU/Linux, Ubuntu e incluso algún OpenSuSE, y es evidente que todas y cada de estas máquinas deben y están monitorizadas.

En Codery usamos un montón de herramientas muy conocidas para monitorizar procesos y sistemas entre ellas: monit, htop, iptraf, munin e incluso jenkins.

Esta semana he estado pendiente más de lo habitual de una máquina Debian 5.0 que soporta bastante tráfico(100.00 visitas mensuales) con sólo 2GB de RAM. Cansado de usar htop, buscaba una alternativa y me he topado con Glances.

Me ha esta herramienta básicamente por su "todo en uno": tráfico de red, operaciones I/O, procesos, carga del sistema, memoria... Y lo mejor, puede ejecutarse en modo standalone o en modo cliente/servidor :)


La instalación en un sistema basado en Debian GNU/Linux es muy sencilla. En mi caso:

apt-get -y install python-pip python-psutil
pip install Glances


Tenéis toda la información del proyecto en : https://github.com/nicolargo/glances


 ¿Te ha gustado este post? Quizá te interese:

 * Señoras y señores:  jubilen top

 * Mailgraph Postfix


martes, 4 de febrero de 2014

Añadir y actualizar idioma Drupal vía Drush


Con Drush la vida en el planeta Drupal es mucho más sencilla...Instalar, activar y actualizar idiomas vía Drush no podía ser más sencillo. Los pasos

Descargar y activar los módulos.

drush dl drush_language
drush dl l10n_update && drush en -y $_


Añadir idioma "Spanish", actualizar traducciones del core de Drupal y actualizar los módulos contribuídos.

drush language-add es && drush language-enable $_
drush l10n-update-refresh
drush l10n-update



lunes, 27 de enero de 2014

Charset UTF-8 para Debian Wheezy, Apache2 , PHP5 y MySQL

 
 
 
Apache 2
vim /etc/apache2/conf.d/charset
AddDefaultCharset UTF-8 
 
MySQL 
 
$ vim /etc/mysql/conf.d/character.cnf
[client]
default-character-set = utf8
[mysqld]
default-character-set = utf8
character-set-server = utf8
collation-server= utf8_general_ci
init_connect = ‘SET collation_connection = utf8_general_ci’
init_connect = ‘SET NAMES utf8′
[mysqldump]
default-character-set = utf8
[mysqlimport]
default-character-set = utf8
[mysql]
default-character-set = utf8
 
PHP5 
$ vim /etc/php5/apache2/conf.d/charset.ini
[PHP]
default_charset = "utf-8"
[mbstring]
mbstring.language = utf-8
mbstring.internal_encoding = utf-8
mbstring.http_input = utf-8
mbstring.http_output = utf-8 

Debian 
$ dpkg-reconfigure locales

sábado, 25 de enero de 2014

Obradoiro Git en Vigo - Sabádos Libres en Altamar

Git mola, así que si mis amiguetes de GALPon organizan un taller de Git en Vigo, poco más tengo que pensar: vaaaaamos!

En esta ocasión mi compañero de viaje fue Rafael Gaioso (@rrgaioso) , al que además de agradecer su compañía, tengo que agradecer que fuese mi chófer. Pero vamos al grano.

Llegamos alrededor de las 10:15 de la mañana, y tras unos problemas inciales relacionados con el proyector comenzó el "taller" impartido por Jesús Amieiro (@jesusamieiro).

Lo primero que llamó la atención fue la preparación del taller por parte de Jesús. Se nota mucho en este tipo de eventos, cuando el ponente prepara las charlas, ejercicios y ejemplos; y este caso no es una excepción. "Mola" mucho que el ponente distribuya ya los contenidos y los difunda nada más comenzar. La URL de referencia fue:

http://www.jesusamieiro.com/taller-de-introduccion-a-git/

Os recomiendo descargar el PDF de la presentación, nada más y nada menos que 76 hojas! #OMG

Para ser sincero he pasado algún tiempo de la jornada trabajando(y giteando :P ) en un módulo de Drupal que "me tiene loco", pero aún así, mi opinión del taller es muy buena. Breve resumen de "lo bueno" del taller:
  • Los conocimientos del ponente. Usa Git y eso se nota a leguas.
  • La documentación y las referencias.
  • 100% consola con ejemplos constantes "en vivo" proyectados.
  • Los asistentes: consultando continuamente e interactuando a buen ritmo.

[ Jesus Amieiro trabajando con GIT ]

Lo malo del taller:
  • No he encontrado nada malo, en serio. Lo único que podría citar es que al ser un tema tan denso, el espacio entre las sesiones(la próxima es en Marzo), podría ser menor.
 De GALPon y la organización poco más tengo que decir que lo que imagináis: la conexión wifi(teníamos 3 AP a nuestra disposición), a pesar de no ser una T1, funcionó realmente bien, el espacio confortable a pesar de no ser muy grande...

Comentar que en la comida en Xantares Enxebres lo pasamos(eso creo) de cine: risas y frikadas del tipo "eso se compila en una GPU con CUDA..." y....cerveza!!!!

 Así que Miguel, Isaac, Carlos, Guillermo,Jesús y demás GitTroopers : enhorabuena, en Marzo regreso sin duda.





jueves, 16 de enero de 2014

Profiling Drupal 7 con XHProf y Apache2


¿Problemas de rendimiento en Drupal?¿Qué sucede y dónde sucede? Para responder a la segunda pregunta existen las herramientas de "profiling", que nos ayudarán a identificar las funciones que más recursos están consumiendo, el número de llamadas a cada función e infinidad de información a mayores. Si desarrollas con Drupal no puedes prescindir de XHProf.

XHProf es una extensión PECL desarrollada por el equipo de ingeniería de Facebook como alternativa a XDebug que sirve para hacer profiling de aplicaciones PHP.

Su instalación en un entorno Linux + Drupal es muy sencilla.

Instalamos la extensión vía PECL

    pear channel-update pear.php.net
    sudo apt-get install php5-common graphviz
    sudo pecl config-set preferred_state beta
    sudo pecl install xhprof

Creamos el directorio temporal para almacenar los datos. En mi caso :


mkdir /var/tmp/xhprof
chmod 777 /var/tmp/xhprof

Habilitamos la extensión creando el fichero /etc/php5/apache2/conf.d/xhprof.ini con el contenido

[xhprof]
extension=xhprof.so
xhprof.output_dir="/var/tmp/xhprof.conf"

Creamos un "alias" para construir la url de acceso al output de XHProf.

alias /xhprof_html "/usr/share/php/xhprof_html"

Reiniciamos Apache2

apache2ctl -t
service apache2 restart

La integración con Drupal es muy sencilla y se puede realizar directamente desde Drush seguiendo estos pasos:

drush dl devel
drush en devel
drush vset devel_xhprof_enabled 1
drush vset devel_xhprof_directory "/usr/share/php"
drush vset devel_xhprof_url "/xprof_html"

Si pedimos en nuestro navegador la url http://tu.sitio.local/xhprof_html obtendremos todos los datos del profiling.



Bonus:



miércoles, 4 de diciembre de 2013

OCS Inventory configuración Ubuntu Server 12.04

¿Qué es OCS Inventory? [Fuente: Wikipedia]


http://www.ocsinventory-ng.org/en/
Open Computer and Software Inventory Next Generation (OCS) es un software libre que permite a los usuarios administrar el inventario de sus activos de TI. OCS-NG recopila información sobre el hardware y software de equipos que hay en la red que ejecutan el programa de cliente OCS ("agente OCS de inventario"). OCS puede utilizarse para visualizar el inventario a través de una interfaz web. Además, OCS comprende la posibilidad de implementación de aplicaciones en los equipos de acuerdo a criterios de búsqueda. Además, tiene muchas opciones más como escanear la red por medio del IPDiscovery, o instalar aplicaciones remotamente creando Builds.

Motivación


Después pelear unos días con la instalación y configuración de OCS Inventory, he decidido publicar este post para detallar la instalación en un servidor Ubuntu Server 12.04. Ya tengo mis notas de instalación, pero me apetecía mucho escribir este post y compartir con todos vosotros la experiencia.

Si bien es cierto que para Debian GNU/Linux y Ubuntu hay paquetes disponibles, tanto para la versión "servidor" como "agente", mi experiencia no es muy satisfactoria instalando OCS desde un repositorio.

Consejos

 

  • aptitude update && aptitude upgrade antes de nada. 
  • Un mysqldump y un tar cf apache2.tar /etc/apache2 tampoco están de más.
  • No intentéis la instalación en un servidor en producción directamente, en teoría nunca pasa nada, pero en la práctica siempre "pasa algo.
  • Usad si o si SSL .
  • Cerrar acceso al /ocsreports con directivas Allow en Apache2.

Instalación servidor


Instalación de paquetes necesarios. Partimos de la base de que ya disponemos de un servidor LAMP correctamente configurado y operativo.

apt-get install libapache2-mod-perl2 libapache-dbi-perl libxml-simple-perl libio-compress-perl libdbi-perl libdbd-mysql-perl libnet-ip-perl php5-gd php5-mysql nmap snmp make

Si queremos habilitar el acceso vía webservice, debemos instalar los módulos Perl necesarios

perl -MCPAN -e 'install SOAP::Lite'

Para Apache2::SOAP

cd /usr/src
wget http://www.cpan.org/authors/id/R/RK/RKOBES/Apache2-SOAP-0.73.tar.gz
tar zxf Apache2-SOAP-0.73.tar.gz 
mkdir /usr/include/apache2
perl Makefile.pl && make && make install


Descargamos en el directorio /usr/src la última versión de OCS Inventory NG Management Server desde la URL http://www.ocsinventory-ng.org/en/download/download-server.html

cd /usr/src
wget https://launchpad.net/ocsinventory-server/stable-2.1/2.1rc1/+download/OCSNG_UNIX_SERVER-2.1rc1.tar.gz
tar zxf OCSNG_UNIX_SERVER-2.1rc1.tar.gz
rm -rf OCSNG_UNIX_SERVER-2.1rc1.tar.gz

Ejecutamos el script de instalación dentro del directorio OCSNG_UNIX_SERVER-2.1rc1

cd OCSNG_UNIX_SERVER-2.1rc1 
/setup.sh

La primera preguntas que debemos responder corresponden con la localización del ejecutable, usuario y ficheros de configuración de Apache. Si has instalado Apache2 desde los repositorios oficiales de Ubuntu, acepta todas las propuestas. Idem para la configuración de MySQL Server/MariaDB.

El siguiente paso en la instalación es la ubicación del fichero de configuración de OCS, por defecto el script de instalación lo ubicará en /etc/apache2/conf.d . Es muy importante que recuerdes la localización de este fichero para futuros cambios.
Avanzamos confirmando el PATH para intérprete de Perl(/usr/bin/perl en mi caso). Imprecindible instalar "make", de lo contario la instalación no podrá continuar. Llegados a este punto confirmamos el directorio dónde OCS guardará los logs (/var/log/ocsinventory-server), importante tomar nota para un futuro por si tenemos "problemas". El asistente comprobará si están instalados en el sistema los módulos necesarios para el correcto funcionamiento de OCS.

+----------------------------------------------------------+
| Checking for required Perl Modules...                    |
+----------------------------------------------------------+

Checking for DBI PERL module...
Found that PERL module DBI is available.
Checking for Apache::DBI PERL module...
Found that PERL module Apache::DBI is available.
Checking for DBD::mysql PERL module...
Found that PERL module DBD::mysql is available.
Checking for Compress::Zlib PERL module...
Found that PERL module Compress::Zlib is available.
Checking for XML::Simple PERL module...
Found that PERL module XML::Simple is available.
Checking for Net::IP PERL module...
Found that PERL module Net::IP is available.

Es probable que recibamos un "warning" del tipo

*** Warning: PERL module Apache2::SOAP is not installed ! o *** Warning: PERL module XML::Entities is not installed !


La instalación de este módulo sólo es necesaria(lo indica el instalador) si queremos utilizar SOAP WebService, no es el caso. Continuamos la instalación.


Do you wish to continue ([y]/n] ?y

Después de realizar las comprobaciones necesarias(módulos Perl instalados), en script de instalación pregunta si queremos permitir al instalador que modifique el fichero de configuración 'ocsinventory-server.conf', renonbrándolo a 'z-ocsinventory-server.conf'. Respondemos si(Y)



+----------------------------------------------------------+
| OK, Communication server setup sucessfully finished ;-)  |
|                                                          |
| Please, review /etc/apache2/conf.d/z-ocsinventory-server.conf
| to ensure all is good. Then restart Apache daemon.       |
+----------------------------------------------------------+


Momento de configurar el acceso web OCS. En esta parte de la instalación he modificado la propuesta de directorios basada en FHS :

/var/lib/ocsinventory-reports => "download directory" para almacenar datos de los equipos, datos SNMP e IPDiscover
/var/www/ocsreports => ficheros PHP para Web Console



Momento de configurar el acceso web OCS. En esta parte de la instalación he modificado la propuesta de directorios basada en FHS :

/var/lib/ocsinventory-reports = "download directory" para almacenar datos de los equipos, datos SNMP e IPDiscover
/var/www/ocsreports = ficheros PHP para Web Console


Configuración del servidor web OCSReports


La configuración por defecto permite acceder al directorio /ocsreports desde cualquier virtualhost configurado en el máquina. En el escenario que he utilizado para documentar la instalación, usamos un subdomonio con SSL activado e incluímos la configuración dentro del propio fichero de configuración de Apache y eliminamos el fichero /etc/apache2/conf.d/ocsinventory-server.conf para evitar el acceso a /ocsreports. Muy importante en este punto, a la hora de generar el certificado, que el FQDN coincida con el nombre DNS de la máquina, de lo contrario, no los "agentes" no se podrán comunicar con el servidor pues recibirán un error de validación del certificado.

Generamos el certificado para el servidor:

cd /etc/apache2/ssl && mkdir ocs-certs 
cd ocs-certs
openssl req -new -x509 -days 3650 -nodes -out ocs.crt -keyout ocs.key

Country Name (2 letter code) [AU]:ES
State or Province Name (full name) [Some-State]:ACoruna
Locality Name (eg, city) []:Ames
Organization Name (eg, company) [Internet Widgits Pty Ltd]:CannibalCorpse
Organizational Unit Name (eg, section) []:IT
Common Name (e.g. server FQDN or YOUR name) []:ocs.cannibalcorpse.net
Email Address []:

NOTA : Common Name (e.g. server FQDN or YOUR name) []:ocs.cannibalcorpse.net , debe coincidir con el valor de la directiva ServerName de virtualhost de Apache2

NOTA II: Copiamos el fichero ocs.crt al fichero cacert.pem y lo incluimos dentro de la carpeta del instalador del agente Windows(en mi caso). Luego veremos en qué paso lo usuaremos.

Continuamos. Voy a incluir el fichero configuración del virtualhost de Apache2, pero antes de nada, movemos el fichero ocsinventory-server.conf a un lugar seguro

mv /etc/apache2/conf.d/ocsinventory-server.conf /root/stuff

El contenido del fichero lo podéis descargar desde esta URL:


https://dl.dropboxusercontent.com/u/6108202/vhost_ocs.txt

Descargamos el fichero y comprobamos la sintaxis

alex@cannibalcorpse.net:/etc/apache2/sites-available# apachectl -t
Syntax OK


Si no hay ningún error, activamos el módulo SSL, habilitamos el sitio y recargamos la configuración.

a2enmod ssl &&2ensite oscannibalcorpsenet
service apache2 restart



En teoría ya podemos acceder a https://ocs.cannibalcorpse.net/ocsreports y finalizar la configuración del cliente web. El primer paso es crear una base de datos(MySQL/MariaDB) y un usuario con privilegios. Es muy sencillo.

mysql>; CREATE DATABASE ocs;
mysql>; GRANT ALL PRIVILEGES ON ocs.* TO 'ocs'@'localhost' IDENTIFIED BY 'UNPASSWORDQUETECAGASDECOMPLEJO' WITH GRANT OPTION;

NOTA III: Muy importante actualizar el fichero /etc/apache2/conf.d/z-ocsinventory-server.conf con las credenciales de acceso correctas a la base de datos que hemos creado.

Detalle del fichero z-ocsinventory-server.conf con las credenciales modificadas
  # Name of database
  PerlSetEnv OCS_DB_NAME ocs
  PerlSetEnv OCS_DB_LOCAL ocs
  # User allowed to connect to database
  PerlSetEnv OCS_DB_USER ocs
  # Password for user
  PerlSetVar OCS_DB_PWD UNPASSWORDQUETECAGASDECOMPLEJO

Recargamos la configuración de Apache2

service apache2 reload

Eliminamos el fichero install.php

cd /var/www/ocsreports/ocsreports && rm -rf install.php

echo "Instalación finalizada. Salud"

jueves, 31 de octubre de 2013

Resumen DrupalCampSpain 2013 Cáceres

DrupalCampSpain 2013 Cáceres



El pasado fin de semana @jcartelle , @erosante y el que suscribe acudimos a Cáceres a la DrupalCampSpain 2013. Si tengo que resumir el evento, podría hacerlo usando sólo una única palabra: impresionante!

Salimos de Bertamiráns el viernes 25 a las 12:00 de la mañana, y tras una parada en Puebla de Sanabria, llegamos a Cáceres a las 19:00. Checkin rápido en el hotel y a recorrer la zona vieja de la ciudad. No conocía Cáceres de nada, pero estoy seguro que después de esta visita, no tardaré mucho en regresar.

Sábado 26. Llega el día más esperado: comienza el evento. DrupalCampSpain 2013 se celebró en el Complejo Cultural San Francisco, un antiguo convento reclicado y adaptado para celebrar todo tipo de eventos. Es un lugar increíble, bien equipo tanto a nivel técnico(wifi, rampas de acceso..) como a nivel de espacio y distribución de salas.
[Complejo Cultural San Francisco - Cáceres ]


Intentaré resumir todas las sesiones en las que estuve presente:

Sábado 26

Sesión: El programador moderno:
Speaker: David Bonilla
Nota: Buena
Interés técnico : 0
Notas: David me parece un crack, aunque no hablase sobre Drupal

 [ @david_bonilla a punto de comenzar su sesión]

Sesión: Anantomía de una petición de formulario Drupal
Speaker: Ricardo Sanz
Nota: Regular:
Interés técnico: 8
Notas: Muy aburrida, transparencias demasiado densas, speaker poco comunicativo.

Sesión: Migrate, una herramienta de trabajo y desarrollo
Speaker: Ramón Vilar
Nota: Muy buena
Interés técnico: 9,5
Notas: Impresionante. Transparencias claras y al grano. Muy buenos ejemplos. Ramón es un tipo que sabe lo que dice y cómo lo dice, otro #crack.

Sesión: Flujo de desarrollo en Drupal
Speaker: ISHolgueras:
Nota: Muy buena
Interés técnico:7
Notas: Muy completa, con sus dosis ágiles y ejemplo reales. Buena comunicación.

Sesión: Otra de views, plugins y handlers
Speaker: Luigi Guevara
Nota: Regular
Interés técnico: 8
Notas: Aburrida, demasiado código en las transparencias, poco ordenada.

Sesión: Twig y otros temas en Drupal 8
Speaker : Cristina Chumillas y Pako García
Nota: Buena
Interés técnico: 8
Notas: Nada que destacar. Es la clásica sesión "que te cunde".

Sesión : Front-end automated testing
Speaker: Rubén Teijeiro
Nota: Buena
Interés técnico: 9
Notas: Quizá demasiado técnica, pero es no es malo, verdad?

Sesión: Responsive web design en Drupal, presente y futuro
Speaker : Cristina Chumillas y Pako García
Nota: Buena
Interés técnico:7
Notas: Nada que destacar.

Domingo 27

Sesión: Automate Drupal deployments with Linux containers, Docker and Vagrant
Speaker : Ricardo Amaro
Nota:Muy buena
Interés técnico:9,5
Notas:Se nota mucho cuando tienes un crack delante. Sesión muy preparada, con ejemplos y al grano. Genial!


Sesión: Gestión semántica de contenidos en Drupal
Speaker : Rafa Haro y Sergio Fernández
Nota:Muy buena
Interés técnico: 9,5
Notas: Lo único que se podría mejorar sería la comunicación con el público; la mayor parte del tiempo el ponente fijaba su vista en un punto imaginario y a correr. Por lo demas, caviar del bueno.


Sesión: Analítica web sobre Drupal
Speaker : Alvaro Hurtado
Nota:Muy buena
Interés técnico: 7
Notas:Otro crack. Sesión con destape incluído.

[Alvaro a punto de comenzar su sesión]
Sesión: Arquitectura de información en Drupal
Speaker : Samuel Solís
Nota:Regular
Interés técnico: 7
Notas:Demasiado aburrida, con contenido muy trillado.

En resumen. Un 11 sobre 10 a la organización. Los que ya sabemos lo mucho que cuesta(no sólo hablo de €, sino de esfuerzo y dedicación) organizar un evento de este tipo, sabemos que los organizadores se lo han currado y mucho: enhorabuena! . Otro 10 a la comunidad Drupal. Hoy en día no es nada fácil juntar a 276 en Cáceres para hablar sobre un CMS.

Mi tercera DrupalCamp ha sido una experiencia inolvidable. Estoy deseando desde ya, acudir a la del próximo ano 2014.

Saludos.























lunes, 30 de septiembre de 2013

Multiples versiones de PHP corriendo en la misma máquina

El pasado viernes migramos de Ubuntu Server 12.04 a Debian 7 Wheezy en el servidor de la oficina. El motivo es muy sencillo: rendimiento. A pesar de no tener a mano los datos los benchmarks realizados, el rendimiento del sistema era paupérrimo, hasta el punto de tener que esperar unos 30 segundos por una petición http. 


Supongo que sabréis que Debian 7 incluye PHP 5.4 en los repositorios oficiales. Nada nuevo si trabajas con aplicaciones realtivamente recientes. El caso es que mantengo un Drupal 6.x corriendo PHP 5.3. Al actualizar el ssoo del servidor, os podéis imaginar : crash! La primera opción es intentar actualizar los módulos de Drupal, a versiones actuales o dev: error. Una pérdida de tiempo. La segunda opción es mantener la calma. La versiones de pre-producción y producción corren sobre una RHEL y php 5.3.15 creo recordar, y conociendo al cliente, seguirán así muchos años. La solución: instalar dos versiones PHP en el mismo servidor. El artículo en el que se basan estos apuntes es un clásico en How To Forge : How To Use Multiple PHP Versions (PHP-FPM & FastCGI) With ISPConfig 3 (Debian Wheezy) , pero claro, en Codery no usamos ISP Config, ni falta que hace. He adaptado el links anterior a nuestras necesidades. Comentaré que he modificado, donde cada punto coincide con el post de How To Forge:

1) La idea es servir con PHP5.4.X con libapache2-mod-php5 y los sitios que nos interesen con PHP5.3.27 vía FPM(última versión en el momento de escribir este post).

2) En este paso nada que añadir, salvo algún paquete extra, por lo tanto los pre-requisitos quedarían así
apt-get build-dep php5 && apt-get install libfcgi-dev libfcgi0ldbl libjpeg62-dbg libmcrypt-dev libssl-dev libc-client2007e libc-client2007e-dev libapache2-mod-fastcgi apache2-suexec

Entre el "make" y el "make install", en mi caso, y por curiosidad también he ejecutado un "make test", todo en orden salvo un warning con ftp_ssl; nada que me/nos preocupase por el momento. De este punto sólo hemos instalado a mayores APC y hemos cambiado en modo de ejecución del FPM a modo socket. La modificación es muy sencilla. En el fichero /opt/php-5.3.27/etc/php-fpm.conf cambiamos el valor de la directiva "listen". Revisad también el uusario y el grupo bajo el que se ejecutará el proceso.

; Unix user/group of processes
; Note: The user is mandatory. If the group is not set, the default user's group
;       will be used.
user = www-data
group = www-data

; The address on which to accept FastCGI requests.
; Valid syntaxes are:
;   'ip.add.re.ss:port'    - to listen on a TCP socket to a specific address on
;                            a specific port;
;   'port'                 - to listen on a TCP socket to all addresses on a
;                            specific port;
;   '/path/to/unix/socket' - to listen on a unix socket.
; Note: This value is mandatory.
;listen = 127.0.0.1:8889
listen = /var/run/php-fpm.sock 
 

Los puntos 3,4 y 5 no nos interesan para estas notas.  Vamos a la configuración del "vhost". Habilitamos los módulos necesarios en Apache2:
[apermuy@dorogo#] a2enmod fastcgi actions suexec && apache2ctl -t

Si todo está en orden

[apermuy@dorogo#] service apache2 restart


Esta en la configuración que he añadido en el fichero /etc/apache2/sites-available/misitio
  
                       
                                SetHandler php-script
                       

                        SuexecUserGroup www-data www-data
                        Alias /php5.fastcgi /var/www/fastcgi/php5.fastcgi
                        AddHandler php-script .php
                        FastCGIExternalServer /var/www/fastcgi/php5.fastcgi -socket /var/run/php-fpm.sock
                        Action php-script /php5.fastcgi virtual
 
Si todo está en orden

[apermuy@dorogo#] service apache2 restart

Nota: El directorio indicado en Alias /php5.fastcgi debe existir. Creando un fichero con phpinfo(); deberíais tener observar:


Salud!




viernes, 5 de julio de 2013

Configurar drush Drupal en hosting compartido



Sin aire no hay vida y sin drush no hay Drupal, así de claro. 
Desplegar cambios desde desarrollo, preproducción y producción con drush es una auténtica gozada. Entendiendo por gozada que tú o tu equipo de desarrollo tiene el control sobre el/los servidores del proyecto. ¿Qué sucede cuando el servidor de producción es un hosting compartido o una máquina corporativa en la que no puedes instalar drush?

En Codery solucionamos esta papeleta del siguiente modo.

Servidor no administrado:

1.- Descargamos el paquete "drush" a un directorio, p.e nuestro $HOME.

wget http://ftp.drupal.org/files/projects/drush-7.x-5.9.tar.gz
tar zxf drush-7.x-5.9.tar.gz

2.- La ejecución de drush desde $HOME es tan sencillo como:

php drush/drush.php -r www drush cc all

En ocasiones incluimos un 'alias' en .bashrc para 'agilizar'.

Servidor origen:

1.- Aquí es dónde está el 'truco'. En el fichero sitio.aliases.drushrc.php incluímos la ruta a drush en el servidor remoto

 $aliases['www.c'] = array(
  'root' => '/home/c/www',
  'uri' => 'http://www.ces',
  'remote-host' => 'www.c.es',
  'remote-user' => 'c',
  'db_url' => 'mysql://c:c@h.c.es/www',
  'path-aliases' => array(
    '%drush-script' => '/home/c/drush/drush',
    '%dump' => '/home/c/drush-backups/c-www.sql',
    '%files' => '/home/c/www',
  ),
);







Qué fácil es la vida con drush! :P

lunes, 1 de julio de 2013

Postfix masquerading


Dejo unas notas sobre cómo modificar el email del remitente de la cuenta root en una máquina corriendo Postfix.

Problema:

El destinatario recibe el email de la cuenta root@nombremáquina en lugar de una FQDN.

La solución es muy sencilla. Antes de ponerse a trastear, recomiendo encarecidamente leer el "Postfix Address Rewriting" . Al grano.

1.- Crear el fichero smtp_generic_maps con el contenido
root@nombredemimaquina  info@midominiomolon.org
2.- Hashear el fichero:

postmap hash:/etc/postfix/smtp_generic_maps

3.- Incluir la directiva smtp_generic_maps en el fichero main.cf

smtp_generic_maps = hash:/etc/postfix/smtp_generic_maps

4.- Reiniciar postfix

service postfix restart

Configuración testeada en :

SSOO: Ubuntu Server 12.04.1 64 bits
Postfix: 2.9.6-1~12.04.1




domingo, 30 de junio de 2013

"Sábados libres na Altamar" - Vigo - Junio 2013

Ayer tuve la oportunidad de asistir a la jornada "Sábados libres na Altamar" organizados por los amigos/as de GALPon en Vigo.

A las 08:00 salí de Ames y en menos de una hora ya estaba en Vigo. El evento tuvo lugar en la residencia Altamar, un lugar bastante céntrico y accesible(vamos, que es fácil llegar).

Antes de comenzar de manera oficial jornada,ya estábamos por allí unos cuantos con ganas de conocer más detalles sobre RaspberryPI. El evento de dividió en dos sesiones de mañana, de 10:00 a 13:30 y tarde, de 16:30 a 19:00 horas.


La primera charla introductoria a RaspberryPI a cargo de Miguel Bouzada(GALPon) se extendió de 10:00 a 12:00. Lo primero que me llamó la atención es la calidad de la documentación aportada en el wiki de GALPon en general, y en particular el apartado "Argallando cunha RaspberryPI". Otro tema que me llamó la atención fue el número de asistentes: 30 de 30 plazas posibles. 

A continuación turno para Xavier Villar, miembro de Inestable, que nos deleitó con unha charla super-hardcore de clustering con RaspeberryPI.  Para un ser tema muy técnico, la explicación e introducción inicial fueron muy amenas. A pesar de las dificultades técnicas de la instalación y configuración, al final de la charla pudimos comprobar las bondades de la ejecución de procesos en paralelo.


14:00, turno para comer en buena compañía con miembros de Melide, GALPon, OZulo y público en general. Por cuestiones personales no pude asistir a toda la jornada de tarde, pero me quedo con un muy buen sabor de boca y con ganas de asistir a próximas ediciones. Enhorabuena a GALPon!

Cosillas interesantes sobre RaspberryPI
  • Openmediavault
  • Moebius
  • Uso de tarjetas SDHC clase 10 y montaje de /var /home /tmp en disco o llave USB para mejorar el rendimiento.

Puntos positivos:
  • La temática.
  • La calidad de las charlas.
  • Los conocimientos de los ponentes.
  • Los asistentes.Sin conocernos prácticamente de nada, el compañerismo y el espíritu de enseñar / compartir fue excepcional.
  •  
Puntos no tan positivos:
  • La conexión a Internet.
  • Desde mi punto de vista, y a pesar de que las tres charlas me han parecido muy buenas, pienso que el nivel fue demasiado alto.

domingo, 17 de febrero de 2013

#LAV013 , de nuevo en Vedra!

Pues sí que pasa pronto el tiempo! Ya ha pasado un año desde el último post relacionado y... es tiempo de #LAV013,  un evento centrado en temática audiovisual organizado por la Asociación Cultural Senunpeso en Vedra. @probatto y es que suscribe( @apermuy ) hemos tenido la suerte de que la organización confiase en el trabajo que llevamos desarrollando desde hace una década en la Asociación Comunidade O Zulo para el montaje de la red wifi del #LAV013.


Como el año pasado usamos Zentyal, y los resultados fueron más que satifactorios. Usamos un PC con procesador Intel Celeron 1,8Ghz y 2GB de RAM para 80 clientes repartidos en dos puntos de acceso( WRT54G y Ovislink 8000 AP). En menos de 1 hora instalamos el SSOO y configuramos la reglas del firewall y proxy transparente, y como por arte de Tux la ya teníamos cobertura wireless en la mayor parte del edificio.


[ Detalle de la tabla de clientes DHCP]

Os recomiendo encarecidamente el uso de Zentyal para este tipo de despliegues. Es una distribución estable, robusta y sobre todo pensada para el usuario y para facilitar su administración.

Por lo demás, qué voy a decir, encantado de coincidir de nuevo con Mon,Xurxo, Fer,Aberlardo y todos los miembros de SenUnPeso. Encantado también de recibir a @probatto en Casa Permu y que ya estoy deseando que llegue el #LAV014.

Ah! Casi lo olvido, el próximo sábado 23 aburriré de nuevo al personal en Vedra con mi charla "Redes libres: internet sen un peso".

Salud!




jueves, 14 de febrero de 2013

Molom Error :Invalid API keys. Error 401: Invalid authentication.

No hay sitio, portal o proyecto web que se precie que no use un CAPTCHA para evitar spam, bien sea en formularios de registros de usuarios, comentarios..etc.¿He dicho CAPTCHA? Eso es historia. Si todavía sigues usando CAPTCHA sigue leyendo, te interesa.

Yo(nosotros) uso Mollom, un software desarrollado para cumplir un único objetivo: evitar spam en tu sitios web. Y lo hace muy bien! Su creador es Dries Buytaert, os suena de algo? Si queréis saber más acerca del proyecto visitad su web, está todo muy claro.

[ Detalle de las estadísticas de Mollom para el dominio www.comunidadeozulo.org ]

Al grano. El caso es que este módulo para Drupal 6.X cada X tiempo devolvía errores de validación OAuth contra el servicio de autenticación REST de Mollom.com. Y tras muchas vueltas, y bueno, por qué no decirlo, la inestimable ayuda de los fotos de Drupal.org, he encontrado la solución al error:


"Invalid API keys.Error 401: Invalid authentication."


y la he adaptado para un servidor corriendo Debian GNU/Linux y Drupal.

El error es muy simple.¡La zona horaria del servidor está mal configurada!¡Por eso "casca" el proceso de autenticación de Mollom!. La solución, muy sencilla:

1.- ntp. Sincroniza tu servidor/máquina con ntpdate. Puedes añadir una tarea "cron" para el que servidor sincronize el reloj cada día, por ejemplo:


30 * * * *    root     ntpdate.hora.rediris.es > /dev/null 2>&1

2.- Configura la zona horaria del servidor

dpkg-reconfigure tzdata


Ahora Mollom debería funcionar sin problemas!