AP administrado via web (II)

Volvemos a la carga. En el post anterior  AP administrado via web (I), terminamos configurando mínimamente un servidor FreeRADIUS,  conectado a una MySQL, y un servidor HTTP (Apache2 en nuestro caso) con la aplicación daloRADIUS para administrar nuestro servidor RADIUS. Ahora partimos de dicho punto para terminar de configurar nuestro punto de acceso, para el que necesitaremos:

  • Configurar las interfaces de red
  • Instalar y configurar un servidor DHCP
  • Configurar un NAS en  FreeRADIUS
  • Instalar y configurar hostapd

En nuestro caso disponemos de una interfaz de wlan y otra ethernet. Dejaremos la interfaz ethernet configurada por dhcp y en la interfaz plan estableceremos una ip fija. Hay que tener en cuenta que algunas distribuciones linux disponen de herramientas que gestionan las interfaces de red para facilitar la conexión a la red, en nuestro cómo utilizaremos la interfaz wifi a modo de AP, nos interesará detener este tipo de herramientas/servicios:

root@dalo:~# service network-manager stop
root@dalo:~# ifdown wlan0
root@dalo:~# ifdown eth0

Ahora con la interfaz bajada y el network-manager detenido, configuraremos la interfaz  de red editando el fichero /etc/network/interfaces:

auto eth0
iface eth0 inet dhcp

auto wlan0
iface wlan0 inet static
address 192.168.2.1
netmask 255.255.255.0

Para que nuestro punto acceso haga routing entre las dos redes tendremos que activar el reenvío entre interfaces:

echo 1 > /proc/sys/net/ipv4/ip_forward

La linea anterior activaría puntualmente el ip fowarding, para persistir dicho cambio tendríamos que añadir al fichero /etc/sysctl.conf, la siguiente linea:

net.ipv4.ip_forward = 1

Por último volvemos a levantar las interfaces de red

root@dalo:~# ifup wlan0
root@dalo:~# ifup eth0

Ya tenemos las interfaces configuradas y operativas, así que empezaremos a con la instalación y configuración del servidor DHCP. Instalamos el servidor idc-dhcp:

root@dalo:~# apt-get update && apt-get install isc-dhpc-server

Tras instalarlo configuraremos un pool de conexiones sobre la red 192.168.2.0/24 en el fichero /etc/dhcp/dhcpd.conf:

subnet 192.168.2.0 netmask 255.255.255.0 {
 range 192.168.2.10 192.168.2.50;
 option subnet-mask 255.255.255.0;
 option broadcast-address 192.168.2.255;
 option routers 192.168.2.1;
}

Por último, arrancamos el servidor:

root@dalo:~# service isc-dhcp-server restart

Ya tenemos DHCP, así que para realizar la autenticación entre hostapd y FreeRADIUS, tendremos que configurar en FreeRADIUS un NAS (Network Access Server, será la labor de hostapd) que se encargará de recibir y tratar las tramas EAPOL (Más información sobre EAP) para delegar en FreeRADIUS la autenticación y autorización:

dalo3

Ya tenemos hostapd configurado en FreeRADIUS, así que ya sólo nos queda instalarlo y configurarlo. Hostapd es un demonio que permite crear puntos de acceso tanto wifi como cableados. En nuestro caso, tal y como hemos comentado anteriormente lo utilizaremos para configurar un punto de acceso wifi con autenticación WPA-EAP que haga uso de un servidor RADIUS. Para instalar el software, utilizaremos apt-get como en casos anteriores:

root@dalo:~# apt-get update && apt-get install hostapd

Después tendremos que configurar el servicio, para lo que tendremos que crear el fichero /etc/hostapd/hostapd.conf con el siguiente contenido:

# Configuracion punto de acceso
ssid=test
channel=12
auth_algs=3
wpa=3
wpa_key_mgmt=WPA-EAP
wpa_pairwise=TKIP CCMP
nai_realm=0,test.com,1
rsn_preauth=1

# Configuracion de hardware y control
hw_mode=b
interface=wlan0
driver=nl80211
ctrl_interface=/var/run/hostapd
ctrl_interface_group=0

# Activacion 802.1x
ieee8021x=1
auth_server_addr=127.0.0.1
auth_server_port=1812
auth_server_shared_secret=Secret.1617
# Activamos también el accounting
acct_server_addr=127.0.0.1
acct_server_port=1813
acct_server_shared_secret=Secret.1617

Una vez configurado hostapd, pasamos a configurar el demonio para poderlo arrancar como servicio. Esto se podrá realizar editando el fichero /etc/default/hostapd y dejando la siguiente configuración:

# Defaults for hostapd initscript
#
# See /usr/share/doc/hostapd/README.Debian for information #about alternative
# methods of managing hostapd.
#
# Uncomment and set DAEMON_CONF to the absolute path of a hostapd configuration
# file and hostapd will be started during system boot. An example #configuration
# file can be found at #/usr/share/doc/hostapd/examples/hostapd.conf.gz
#
DAEMON_CONF="/etc/hostapd/hostapd.conf"

# Additional daemon options to be appended to hostapd command:-
# -d show more debug messages (-dd for even more)
# -K include key data in debug messages
# -t include timestamps in some debug messages
#
# Note that -B (daemon mode) and -P (pidfile) options are automatically
# configured by the init.d script and must not be added to #DAEMON_OPTS.
# Acitivamos debug
DAEMON_OPTS="-d"

Por último arrancamos el servicio:

root@dalo:~# service hostapd start

Pues con esto, ya casi hemos terminado, sólo nos quedaría dar de alta un usuario, al que llamaremos cliente1, y probar el acceso:

dalo4

Para probar el acceso y al haber activado el accounting tanto en FreeRADIUS como en hostapd, podremos consultar que los accesos son correctos directamente en daloRADIUS > Accounting > User Accounting:

dalo5

Y con esto podemos dar por concluido este how-to sobre cómo configurar un punto de acceso wifi WPA-EAP con FreeRADIUS y administración web.

AP administrado via web (I)

Por azares del destino, hace unos días descubrí daloRADIUS, un proyecto open source para crear unas interfaz web de administración para FreeRADIUS. Este proyecto a día de hoy se encuentra un poco abandonado, pero poco a poco un grupo de desarrolladores lo está intentando reflotar para adaptarlo a la últimas versiones de PHP y FreeRADIUS.

Hé aquí mi pequeña contribución al proyecto, una pequeña guía sobre cómo montarnos un punto de acceso wifi con autenticación WPA-EAP y administrado vía web. Para ello necesitaremos MySQL, FreeRADIUS, Apache2 + PHP, hostapd y por supuesto un poquito de daloRADIUS.

Primero instalaremos todo el software necesario:

apt-get install mysql-server freeradius freeradius-mysql freeradius- utils apache2 libapache2-mod-php php php-db php-gd php-pear php-mail php- mysql hosted

daloRADIUS está desarrollado para funcionar con FreeRADIUS 2 y PHP 4/5, el comando anterior en la mayoría de sistemas actuales, terminará instalando FreeRADIUS 3 y PHP 7, pero no os preocupéis, las funcionalidades básicas siguen funcionando, aunque hay que tener en cuenta algunos detalles que iremos comentando.

Una vez instalado los servidores MySQL y FreeRADIUS, lo que haremos será preparar la base de datos para su correcto funcionamiento. Para ello crearemos un usuario y un base de datos para radius y le aplicaremos el esquema incluido en /etc/freeradius/3.0/mods-config/sql/main/mysql/schema.sql:

root@dalo:~# service mysql start
root@dalo:~# mysql –u root –p
mysql> create database radius;
mysql> grant super on *.* to radius@localhost identified by “Radius.1617”; mysql> quit;
root@dalo:~# mysql –u radius –p radius < /etc/freeradius/3.0/mods- config/sql/main/mysql/schema.sql

Ahora configuraremos FreeRADIUS para que utilice el módulo SQL. Para llevarlo a cabo tendremos que configurar la conexión a base de datos a través del fichero /etc/freeradius/3.0/mods-available/sql estableciendo el driver de conexión a base de datos y los datos de conexión (que en nuestro caso será la MySQL que acabamos de configurar)

 sql {

# The sub-module to use to execute queries. This should match
... ...
# the database you're attempting to connect to. #
# * rlm_sql_mysql
# * rlm_sql_mssql
# * rlm_sql_oracle
# * rlm_sql_postgresql
# * rlm_sql_sqlite
# * rlm_sql_null (log queries to disk) #
driver = "rlm_sql_mysql"
dialect = "mysql"
# Connection info:
#
server = "localhost" port = 3306
login = "radius" password = "Radius.1617"
# Database table configuration for everything... radius_db = "radius"

Tras editar el fichero de configuración del módulo SQL, lo activaremos para que se aplique durante el inicio de FreeRADIUS. Para ello bastará con crear un enlace simbólico en el directorio mods-enabled:

 root@dalo:/etc/freeradius/3.0/mods-enabled# ln -s ../mods-available/sql sql

Tras esto, nos situaremos en el directorio /var/www/html y descargaremos daloRADIUS

root@dalo:/var/www/html # wget http://downloads.sourceforge.net/project/daloradius/daloradius/daloradius0.9-9/daloradius-0.9-9.tar.gz 
root@dalo:/var/www/html # tar -xvzf daloradius-0.9-9.tar.gz 
root@dalo:/var/www/html # mv daloradius-0.9-9 daloradius root@dalo:/var/www/html # chown www-data:www-data -R daloradius

Aplicamos sobre la base de datos de radius las modificaciones necesarias para que daloRADIUS funciones correctamente:

 root@dalo:/var/www/html # mysql -u radius -p radius < daloradius/contrib/db

Creamos el fichero de log

root@dalo:~# mkdir /var/log/daloradius
root@dalo:~# touch /var/log/daloradius/daloradius.log
root@dalo:~# chown www-data:www-data /var/log/daloradius/daloradius.log

Ahora configuramos el acceso a base de datos para la aplicación. Esta configuración se realiza a través del fichero <daloradius_home>/library/daloradius.conf.php. Lo editamos y establecemos la siguiente configuración:

$configValues['DALORADIUS_VERSION'] = '0.9-9';
$configValues['FREERADIUS_VERSION'] = '2';
$configValues['CONFIG_DB_ENGINE'] = 'mysqli';
$configValues['CONFIG_DB_HOST'] = 'localhost';
$configValues['CONFIG_DB_PORT'] = '3306';
$configValues['CONFIG_DB_USER'] = 'radius';
$configValues['CONFIG_DB_PASS'] = 'Radius.1617';
$configValues['CONFIG_DB_NAME'] = 'radius';
…
$configValues['CONFIG_LOG_FILE'] = '/var/log/daloradius/daloradius.log'

Ya tenemos todo el sistema instalado, así que ahora procederemos a la comprobar el correcto funcionamiento del mismo. Para ello levantaremos los distintos servicios y crearemos un usuario de prueba para comprobar que podemos realizar la autenticación del mismo.

Arrancamos los servicios:

root@dalo:~# service mysql start && service freeradius start && service apache2 start

Accedemos a la interfaz web de daloRADIUS y nos autenticamos con el usuario administrator/radius. desde el apartado de administración de usuarios procederemos a la creación de un usuario de prueba:

dalo1

Una vez tengamos el usuario de prueba creado, realizaremos una prueba de autenticación con el comando radtest:

root@dalo:~# radtest testuser test.1617 localhost 1812 testing123

Sent Access-Request Id 144 from 0.0.0.0:38110 to 127.0.0.1:1812 length 78

     User-Name = "testuser"

     User-Password = "test.1617"

     NAS-IP-Address = 127.0.1.1

     NAS-Port = 1812

     Message-Authenticator = 0x00

     Cleartext-Password = "test.1617"

Received Access-Accept Id 144 from 127.0.0.1:1812 to 0.0.0.0:0 length 20

Podemos ver también los distintos intentos de autenticación desde la interfaz web a través del menú Reports > Last connection attemps:
dalo2

 

A continuación desglosaremos incidencias que pueden ocurrir durante proceso de instalación y cómo resolverlas:

  • El servidor Apache arranca pero al acceder a la página de daloRADIUS (http://locahost/daloradius) muestra que la página no se encuentra, error 404
  • Comprueba que la ruta que escrita en el navegador se corresponde con el nombre de la carpeta en la que hemos descargado daloRADIUS.
  • Revisa que la carpeta daloradius se encuentre en /var/www/html o en la ruta que tengamos como DocumentRoot en la configuración de apache (podemos consultar la configuración con apachectl -S)

 

  • El servidor Apache arranca pero al acceder a la página de daloRADIUS (http://locahost/daloradius) muestra que la página está prohibida, error 403
  • Chequea que el usuario que utiliza Apache (por defecto www-data, nobody o http, esta configuración se puede consultar con apachectl -S) tiene permisos para leer y ejecutar la carpeta daloradius y los archivos que se encuentran en ella.

 

  • El servidor Apache arranca pero al acceder a la página de daloRADIUS (http://locahost/daloradius) muestra una pagina vacía o un error de base de datos
  • Chequear que se han instalado correctamente todas las librería php necesarias: php, php-db, php-gd, php-mail, php-mysql, php-pear. Se puede consultar con dpkg –l | grep php
  • Revisar si se han aplicado los scripts de configuración de base de datos de daloRADIUS.
  • Comprobar que daloRADIUS está configurado para usar el motor de base de datos mysqli. Por defecto, está configurado para usar el driver/motor de base de datos “mysql”, API que ya no está disponible en PHP 7. Durante la realización de esta práctica se ha hecho uso de mysqli por ofrecer un conjunto de funcionalidades similar pero ampliado al de mysql. Más información: http://php.net/manual/en/mysqlinfo.api.choosing.php

 

  • La prueba de autenticación no es satisfactoria
  • Comprobar que en el fichero /etc/freeradius/3.0/clients.conf está dado de alta el cliente “localhost” con el secreto “testing123”
  • Comprobar que el servidor freeradius está haciendo uso del módulo SQL. Para cerciorarnos podemos parar el servidor freeradius y levantarlo con las opciones de depuración, freeradius –X

 

Y con esto lo dejamos por hoy. En próximas entregas veremos cómo configurar hostapd para obtener el caso de uso completo

Talend Open Studio y Log4j (II)

Tras un par desemanillas trabajando con Talend, he sufrido un par de problemas con respecto al logado de información que merece la pena compartir.

El primero, reside en que muchos componentes escriben directamente por la salida estándar o por la salida de error . ¿Qué problema ocasiona esto? pues que a la hora de trazar la ejecución de un job tienes que estar revisando tanto la salida estandar (el catalina.out en caso de estar corriendo los jobs como web services en tomcat) como los ficheros de logs que hayas configurado en el componente tInitLog4j. Para subsanar esto bastaría con un incluir un “proxy” en cada una de las salidas de modo que escriban la información que se envíen a ellas a los loggers pertinetes con su correspondiente nivel de log:

/**
* Con esta función pretendemos crear un objeto PrintStream que ademas de escribir en el flujo original deje registro en los ficheros de log
* @param originalStream Stream que estamso observando
* @param errorLog se trata de mensajes de error o estándares
* @return el nuevo PrintStream
*/
public static PrintStream logProxy(final PrintStream originalStream, final boolean errorLog) {
return new PrintStream(originalStream) {
public void print(final String message) {
// Seguimos enviando el texto al Stream original
originalStream.print(message);
if (errorLog) {
logger.error(message);
} else {
logger.info(message);
}
}
};
}

Para insertar el “proxy”:

System.setOut(logProxy(System.out, false));
System.setErr(logProxy(System.err, true));

Esta mejora se la he reportado en bcourtine para que la incluya en próximas versiones de tInitLog4j

El segundo problema al que me enfrenté fue el de sustituir todos los tLogRow que utilizábamos por tLog4j, dado que el componente tLogRow en la versión Open Studio no utiliza log4j para emitir los datos que por él pasan. El componente tLog4j no tiene el mismo “contrato” que tLogRow, básicamente no permite la utilización de esquemas complejos, y te obliga a escribir continuamente en el mensaje de log la concatenación de cada variable que quieras logar.

tLog4j

Para evitar esta ardua tarea decidí implementar mi propia versión de tLogRow de modo que pudiera sustituir todos los tLogRow por este nuevo componente sin necesidad de reescribir código. De ahí nació tLog4JRow, ya está disponible en Talend Exchange. Su uso es muy simple y tiene opciones muy similares a las de tLogRow, así que la transición de un componente a otro es inmediata

tLog4jRow

 

Y con esto y un bizcocho… doy por terminado este post

Talend Open Studio y Log4j

Disponer de un log detallado y ordenado es de vital importancia para el diagnostico y resolución de incidencias, sobre todo si hablamos de herramientas capaces de procesar datos de forma masiva como es el caso de un ETL. En este aspecto las versiones “Libres” de Talend dejan mucho de desear, dado que sólo dan soporte de manera oficial a herramientas como Log4j en las versiones empresariales o de suscripción [1]. Con respecto a esto, la comunidad [2] ha desarrollado algunos componentes para facilitar el uso de log4j, en su versión 1.2. Entre estos componentes destacan los desarrollados por Benoît Courtine [3], que permiten establecer el fichero de configuración de log4j, escribir mensajes, permitiendo elegir los distintos niveles de log, y añadir listeners para la captura de errores. En el proyecto-tutorial que proporciona [4], se pueden apreciar las distintas funcionalidades y casos de uso que ofrecen los componentes desarrollados.
Basándonos en las herramientas antes citadas y atendiendo un poco al sentido común, se detallan algunas buenas prácticas referidas a las políticas de logging en Talend:

  1. Utilizar sólo un tInitLog4j en el job principal y marcar la opción de bloqueo de configuración. La configuración de Log4j se realiza a nivel global del proceso Java y con esto evitaremos sobreescrituras por error de la configuración.
    init_log
  2. Incluir tLogCatcher y tStatCatcher en cada Job para capturar posibles excepciones y los tiempos de respuesta de cada componente. Es importante establecer los distintos niveles de log en cada uno de los componentes, por ejemplo, en tStatCatcher el nivel de log puede ser un debug o info, dado que esos datos son meramente informativos. Sin embargo en el caso del componente tLogCatcher interesa establecer un nivel de log más restrictivo como error o warning.
    log_catcher
  3. En el caso de utilizar Joblets, no será necesario establecer “catchers” dentro del joblet, si el job que lo invoca lo tiene ya definido. El código de los joblets es incrustado dentro de los Jobs que lo invocan y por tanto heredan determinados comportamientos. Cuando se utilizan invocaciones a subjobs, realmente se está invocando a otro job distinto y entre ambos no comparten código.
  4. Utilizar los componentes tWarn con los niveles de log correctos.  Los componentes tLog4j permiten una configuración bastante más “fina” de los mensajes de log , permitiendo incluso establecer los loggers a los que dirigir los mensajes

Enlaces de Interés
[1] https://www.talendforge.org/forum/viewtopic.php?id=44156
[2] https://www.talendforge.org/
[3] https://github.com/bcourtine/Composants-Talend-Open-Studio/tree/master/Logging
[4] https://exchange.talend.com/#marketplaceproductoverview:gallery=marketplace%252F1&pi=marketplace%252F1%252Fproducts%252F342%252Fitems%252F479

 

Diseñando Aplicaciones para BlackBerry

Después de haber abandonado el blog durante demasiado tiempo, volvemos abarcando nuevas inquietudes y objetivos. Este primer post tras el exilio, espero que sea el primero de una larga serie dedicada al desarrollo móvil, haciendo especial hincapié en el mundo BlackBerry.

Este primer post, intenta resumir los puntos más importantes a tener en cuenta a la hora de diseñar una aplicación en movilidad, a prioiri puntos bastante simples y lógicos, pero que desgraciadamente en muchas ocasiones se pasan por alto:

  1. Experiencia de usuario: Vital para el éxito o fracaso de nuestra aplicación. Aunque hagamos un desarrollo digno de la NASA, en cuanto a complejidad del desarrollo, podemos tener un estrepitoso fracaso, si hemos llegado a realizar una aplicación tan complicada, que hasta a nosotros mismos nos resulta difícil de utilizar. A continuación se desglosan algunos detalles a tener en cuenta:

    1. Debemos familiarizarnos con la plataforma: Los usuarios de un determinado tipo de terminal están habituados a las vistas, menús y acciones que ofrece de forma nativa dicha plataforma. Cosas tan simples como cambiar de sitio de un menú, o no permitir que al visualizar un número de teléfono se pueda realizar una llamada, tan solo sirven para empeorar la experiencia de usuario.
    2. Interfaz intuitiva y usable: Las pantallas deben invitar a usar la aplicación y facilitar su uso. Antes de empezar a “picar” una pantalla, debemos preguntarnos, qué podemos hacer para facilitarle el trabajo al usuario y trabajar en dicho aspecto.
    3. Control total para el usuario: El usuario debe tener el control de la aplicación el mayor tiempo posible y si no lo tiene, se le debe informar. Las acciones que invocan los usuarios se deben ejecutar, siempre que se pueda, en segundo plano sin bloquear el uso de la aplicación y si no hay más remedio, se deberá informar al usuario con un mensaje de cargando o similar.
    4. Control y notificación de errores: El usuario sólo debe ser consciente de aquellos errores que pueda subsanar o de aquellos que le impidan trabajar normalmente con la aplicación. Además si el usuario es capaz de subsanar un determinado error (por ejemplo un dato mal introducido en un formulario) se le debe facilitar dicha tarea en la medida de lo posible.
  2. Uso de APIs Nativas: Las APIs nativas de las distintas plataformas móviles suelen tener soluciones para los problemas más comunes que además van a estar mucho más testeados que cualquier desarrollo a medida. Por lo tanto que antes de empezar a desarrollar, siempre es bueno comprobar si las APIs ofrecen ya una solución a nuestro problema.
  3. Componentes nativos de interfaz: Debemos evitar en la medida de lo posible definir nuestros propios componentes. Los componentes por defectos ya suelen tener implementados los comportamientos nativos de la plataforma y son visualmente coherentes con el resto de aplicaciones.
  4. Dispositivos a soportar: De partida tenemos que tener claro los dispositivos y características sobre los que vamos a dar soporte. Las características más importantes a tener en cuenta son: versión de SO mínima compatible, resoluciones de pantalla, tipo de pantalla (táctil o no), teclado físico o virtual y tipo trackpad.
  5. I18N: La internacionalización siempre hay que tenerla en cuenta, sobre todo si queremos publicar nuestra aplicación en algún Market Place, por lo que cualquier usuario del planeta puede ser un cliente potencial.
  6. Patrones de diseño:Nunca hay que olvidarlos, siempre serán nuestros fieles compañeros en este mundillo. Los patrones más extendidos en movilidad suelen ser:
    • MVC: Patrón arquitectónico bastante extendido, que permite diferenciar cada parte de nuestra aplicación en función de su responsabilidad.
    • Command: Permite independizar el tiempo de petición y el de ejecución, y soluciona tareas muy comunes como los famosos Deshacer y Rehacer.
    • Observer: Permite implementar listeners de eventos, como por ejemplo capturar determinadas pulsaciones de teclado

Exitos y fracasos

No hace mucho, un compañero de trabajo hacía hincapié en la necesidad de analizar cada uno de nuestros éxitos o fracasos con el objetivo de comprender cómo se ha llegado a una determinada situación, para intentar reproducirla o evitarla en un futuro. Tiene toda la lógica del mundo ¿verdad? Pues resulta curioso ver cómo volvemos a equivocarnos, una y otra vez en los mismos problemas…

Os invito a analizar el porqué de las distintas situaciones y cómo habéis llegado hasta ellas, intentad verlas desde otra perspectiva y veréis mucho más de lo que inicialmente visteis, os daréis cuenta de detalles que despreciasteis, y sobre todo, ganaréis experiencia y no dejéis que esta sea sólo un número en vuestro currículum.

El gestor de proyectos. Parte 1

Muchos nos aventuraríamos a dar una definición basada en los objetivos propios de la gestión  de proyectos y las responsabilidades que recaerían sobre este rol, pero a mi parecer es bastante más didáctico comenzar diciendo que NO debería ser un gestor proyecto.

Pues eso, un gestor de proyectos NO debería:

  • Ser un despachador de correo (o un brown dispatcher) Alguien que se ocupa simplemente de reenviar las peticiones del cliente al equipo de trabajo sin ningún tipo de intervención.
  • Ser un generador de problemas. Una persona que no identifica las prioridades del proyecto o que no detecta los problemas o riesgos reales del proyecto o que aporta problemas de su propia cosecha.
  • Ser un filtro paso de baja. O alguien que oculta información, ya sea al cliente o al resto del equipo de proyecto.
  • Utilizar las herramientas como un fin en sí mismas. Dedicar su trabajo a generar informes, gráficas y documentos sin preocuparse del fin o el contenido de los mismos.
  • Acaparar todas las responsabilidades o funciones dentro del proyecto. ¿O a caso el arquitecto, diseña edificios, pone ladrillos, encofra, echa perlita, te pone la grifería y gestiona la calidad de sus propios trabajos?
  • Asentir las peticiones de los clientes sin cuestionarlas ni valorarlas.

Estos son sólo algunos ejemplos, seguramente podréis enumerar muchas más cualidades de un mal gestor, pero como no es mi objetivo hurgar más en la yaga, y  además resulta ser un buen momento para hacer un descanso. Próximamente la secuela…