Jornada de Calidad y fiabilidad en los servicios de telefonía de hoy

Esta tarde he asistido, en el Col·legi d'Enginyers Industrials de Catalunya (Colegio de Ingenieros Industriales de Cataluña), a un jornada titulada "Calidad y fiabilidad en los servicios de  telefonía de hoy" con el objetivo de ver que podía substraer de todo esto y ver si me servirá para una ponencia que es posiblemente daré en mayo, en el mismo colegio, sobre calidad en las TI, aunque el objetivo es que vaya más bien centrada en ISO 27000.

Al margen de si me va ser útil o no para preparar mi posible ponencia, la jornada ha sido amena y entretenida, además de haberme provocada la reflexión sobre algunos puntos que no me había planteado.

Los temas tratados sobre la calidad y fiabilidad se han centrado desde el punto de vista técnico (al nivel alto), y de los retos que se plantean para mejorar en estos dos factores, que han ido desde la saturación de estas redes debido a todos los servicios que se están ejecutando hoy en día y que han evolucionado más rápido que el despliegue de la tecnología necesaria para soportarlos hasta como hacer que estas infraestructuras de comunicación sean capaces de continuar funcionando después de ciertos desastres naturales, poniendo como ejemplo del desastre natura que ocurrió en Japón el año pasado.

La mesa de debate que ha estado compuesta por:

1. Ferran Amago i Jordi López, Col·legis Enginyers de Telecomunicacions.
2. Antoni Elias, ETSETB-UPC.
3. Josep Mª Rabés, Orange.
4. Xavier Casajoana, VozTelecom.
5. Javier Ruiz, Alcatel-Lucent.
6. Gabriel Treiban, Qualcomm

Desde mi perfil profesional (Ingeniero Informático) puedo decir que la mesa se ha animado mucho cuando Antoni Elias ha empezado a decir que "los informáticos están causando el CAOS en estás redes" desarrollando aplicaciones que se han desarrollado para funcionar sobre estas redes (podríamos centrarlo en las famosas Apps para smartphones) al no garantizar ninguna calidad, añadiendo que "la informática es así que no existe un proceso ingenieril como tal y que por lo tanto no se garantiza la calidad de lo que se hace"; en esos momentos, yo que debía ser uno de los pocos (no sé si el único) ingenieros informáticos del público he empezado a sacar humo por la nariz (desde el respeto de la opinión de cada uno).

Es molesto que como muchos ingenieros informáticos luchamos, y con consecuencias, por hacer la cosas bien hechas y con calidad y como otros tiran eso por el suelo optando por descartar tus propuestas por otras mucho más económicas, pero con la consecuencia que no deja de ser una autentica basura porque no se ha pensado en nada y lo único que se ha hecho es poner los ladrillos como se ha podido. Algo que si quiero indicar sobre estas últimas palabras, es que no quiero que se interprete, aunque yo sea ingeniero, que solo un ingeniero informático puede hacer las cosas bien, porque conozco gente muy hábil y con un nivel de inteligencia elevado a base de su esfuerzo ha aprendido de manera autodidacta lo que muchos no han aprendido estudiando la Ingeniería Informática, pero realmente esto no es una cosa intrínseca de la informática, es algo que se da en todo, el hecho de tener un título no es una garantía del 100% segura que esa persona sea competente en esa área, al final el más competente es quien hace algo porque realmente le gusta y lo lleva en el interior, haciendo que el fruto de su trabajo sea catalogada con un nivel alto de profesionalidad.

Luego Antoni, también se ha metido con los financieros, alegando que están a la cabeza de empresas tecnológicas, y que como solo miran la pasta, así de bien van la calidad de los servicios, porque se prescinde de las buenas soluciones frente a las de bastante peor calidad por simples aspectos económicos; en fin aquí no voy a salir en defensa de los financieros, pero en gran parte creo en lo que dice, pero no creo que el problema sean ellos sino que se les cede el control total cuando lo que tendría que ser es un equipo multidisciplinar, que es lo que muchos se jactan de predicar y muchos de ellos directivos de este tipo.

Al final mis humos se han evadido cuando en el turno de Xavier Casajoana (Ingeniero Informática) ha salido a la defensa con argumentos muy buenos sobre la existencia de estos "servicios gratuitos" y que no solo se les puede atribuir a éstas el colapso de estas infraestructuras.

También me gustaría resaltar la intervención de Gabriel Treiban por exponer términos como OTT (Over The Top) para referirse a las aplicaciones, con el significado de que son realizado por terceros y que funciona encima de todo lo que hace funcionar esto y que desde el punto de vista de chip que es lo que hace Qualcomm, es complicado llegar a controlar el comportamiento de éstas, si lo vemos desde el punto de vista de quien ejecuta las instrucciones, que son los chips. Gabriel también ha puesto sobre la mesa el compromiso Coste-Tiempo-Calidad y como de estos tres factores siempre tienes que escoger dos, aspecto que realmente es para que cada uno haga su reflexión.

Después de terminar las intervenciones de los interventores ha habido rueda de preguntas y entre varias de estas se ha preguntado sobre que la calidad que el cliente percibe muchas veces es por otro aspecto, que es la atención al cliente que ofrecen los operadores; de esto no comento nada ya que muchas ya sabéis por donde van los tiros.

Para terminar solo quiero comentar un aspecto que me ha hecho gracia, porque hasta hace bien poco tenía que dar argumentos muy similares debido al sector de la empresa donde trabajaba y de lo mucho que se rajaba de la informática; lo que se ha dicho es que estas infraestructuras que dependen de servidores se dimensionan en función de un resultado estadístico y que es normal que cuando haya un demanda superior a lo que ha indicado la estadística el servicio no da la calidad que se esperaba pero que esto sucede igual, por ejemplo, con las autopistas.

Hasta la próxima enfermos.

Profundizando en PAM: Passwd sobre PAM (2/2)

conjuntoEntradas() {

 Profundizando en PAM: Passwd sobre PAM (1/2)
 Profundizando en PAM: Passwd sobre PAM (2/2)
}

La luz del final del túnel

Hace unas tres semanas tuve que cambiar el password porque estaba a punto de caducarse y como no el diablo que me perseguía apareció; harto de él y con ganas de enfrentarme a él, nos metimos en el lío.

Preguntando al Sr. Google, encontré un post de un tal Jason Howk, que habla de aplicar una política fuerte de contraseñas bajo Linux donde se explica cosas que ya sabía y otras no, concretamente lo del PAM; así que en el post encontré la madre del cordero.

PAM (Pluggable authentication module), permite definir un proceso de autenticación asociado a un ejecutable/proceso a modo de plugin, es decir que se integra sin la necesidad de alterar el binario o código fuente que lo requiere.

Así que una vez tener a partir de la definición como actúa y después de haber leído el post del tal Jason Howk entendí que con un fichero de configuración se puede definir el modo de autorización totalmente externa, llamando al servicio PAM, evitando que tengas que implementarlo, y encima puedes amoldarlo a tus necesidades, siempre y cuando haya un módulo PAM que haga lo que quieres, y sino lo hay, ya sabes que te toca implementarte uno.

Tirando del hilo

Cuando ya me había enterado que con un fichero de configuración de PAM se puede definir como se comporta el cambio del password de acceso al sistema a través comando passwd, concretamente el fichero /etc/pam.d/passwd, me fui a ver que había ahí dentro para ver porque sucedía lo de solicitar el cambio de password por duplicado y encontré esto

#%PAM-1.0
auth       sufficient   pam_rootok.so
auth       include system-auth
account    include system-auth
password   include system-auth

Como podemos ver en el fichero no se define nada, se delega cada grupo (auth, account, password), al fichero /etc/pam.d/system-auth, el cual tiene el siguiente contenido

auth  required pam_env.so 
auth  required pam_unix.so try_first_pass likeauth nullok 
auth  optional pam_permit.so
 
account  required pam_unix.so 
account  optional pam_permit.so
 
password required pam_cracklib.so difok=2 minlen=8 lcredit=1 ucredit=1 dcredit=2 ocredit=2 retry=3
password required pam_passwdqc.so min=8,8,8,8,8 retry=3
password required pam_unix.so try_first_pass use_authtok nullok sha512 shadow 
password optional pam_permit.so
 
session  required pam_limits.so 
session  required pam_env.so 
session  optional pam_mktemp.so
session  required pam_unix.so 
session  optional pam_permit.so

El fichero llama a varios modulos PAM en cada fase, y como no tenía ni idea que hacía cada uno de ellos me fui a buscar la documentación para tener una idea de lo que hace cada uno, bueno solo de los que he encontré de manera rápida, y poder definir el flujo de del servicio PAM que deseaba sobre el comando passwd.

Después de tener más o menos claro lo que hace cada módulo que aparecía en el fichero /etc/pam.d/system-auth, me puse a definir el flujo que deseaba sobre el comando passwd. No obstante, no alteré el fichero /etc/pam.d/system-auth, que es el que se referenciaba en todos los ficheros de configuración de los procesos/comandos que usan PAM, es decir como hacía el fichero /etc/pam.d/passwd, que delegaba la definición del flujo al fichero /etc/pam.d/system-auth, sino que modifque directamente el fichero /etc/pam.d/passwd.

El juicio final: definiendo el flujo PAM sobre passwd

Con la documentación y viendo el contenido del fichero /etc/pam.d/system-auth, me puse definir el contenido de /etc/pam.d/passwd, desde 0.

1. Quité todos los modules pam_permit porque solo con ver en la documentación la siguiente frase “PAM module that always permit access” a uno ya le queda bastante claro que no puede ser muy bueno, no obstante, por sino queda claro, la propia documentación te le deja más claro con la siguiente frase “This module is very dangerous. It should be used with extreme caution”.
2. Mantuve los módulos pam_env aunque actualmente en el fichero /etc/security/pam_env.conf está todo comentado, pero para un posible futuro puede ser útil que al meter configuraciones en él, se apliquen a las configuraciones existentes.
3. De los dos módulos de verificación de complejidad de contraseña, pam_passwdqc y pam_cracklib, para esta situación, opté por utilizar el pam_passwdqc.
4. Mantuve el módulo pam_unix, para sincronizarlo con el sistema tradicional de autenticación de los sistemas Unix, pero me cargué el parámetro nullok para dejar de permitir el acceso a usuarios sin password.
5. Al igual que pensé con lo que hacer con el módulo pam_env, pensé lo mismo con pam_limits, es decir lo mantuve a pesar de que el directorio /etc/security/limits.d/ esté vacío, para si establezco configuraciones futuras dentro de éste.
6. Mantuve pam_mktemp, a pesar de que en mi caso no se vaya a dar el caso de tener directorio home en sistemas de ficheros compartidos por la red, pero creí que no estaba de más mantenerlo.

El resultado de todo esto fue este

#%PAM-1.0

auth  required pam_env.so 
auth  required pam_unix.so try_first_pass nullok
 
account  required pam_unix.so 
 
password required pam_passwdqc.so min=disabled,disabled,15,10,8 passphrase=3 retry=3 ask_oldauthtok check_oldauthtok
password required pam_unix.so try_first_pass use_authtok sha512 shadow 
 
session  required pam_limits.so 
session  required pam_env.so 
session  optional pam_mktemp.so
session  required pam_unix.so

Final de la pesadilla

Y a aquí termino todo, una vez definido esto, comprobé que el comando passwd funcionaba correctamente y que solo me pedía el password (y claro está, su verificación) una sola vez.

Aunque seguro que está muy claro, menciono explicitamente el porque ahora no se pide el password más de una vez; básicamente es porque si nos fijamos en el fichero /etc/pam.d/system-auth, se realiza dos llamadas al proceso de verificación de complejidad, una sobre al módulo pam_cracklib y otra pam_passwdqc.

Para finalizar solo quiero decir que para realizar las distintas pruebas antes de definir por completo el flujo PAM sobre passwd cree un nuevo usuario en el sistema, para evitar que probando no me vaya a cargar el acceso de mi usuario habitual, y cuando todo funcionó, me lo cargué.


Hasta la próxima enfermos.

Profundizando en PAM: Passwd sobre PAM (1/2)

conjuntoEntradas() {

 Profundizando en PAM: Passwd sobre PAM (1/2)
 Profundizando en PAM: Passwd sobre PAM (2/2)
}

Introducción

En varias ocasiones leo o oigo hablar de algo que en un primer momento no conozco, en algunas de ellas tengo la oportunidad de preguntarle a la persona que está hablando que me explique lo que es, otras no tengo esa oportunidad y es cuando entonces decido preguntarle a Mr. Google, si puedo en ese mismo momento y sino en otro momento, es lo que tiene que siempre esté a tu disposición.
Una vez que he tenido una breve descripción de lo que es, entonces ya estoy en contexto, y normalmente (hablando de temas focalizados en el mundo de la informática) puedo comprender, lamentablemente no siempre al 100%, lo que estoy leyendo o lo que me están contando, si es el caso la problemática y la posible solución o mitigación.

Una de estas situaciones, aunque no recuerdo ni cuando ni donde, fue lo que me pasó con PAM; en ese momento me enteré de lo que era y luego cuando me hablado en otras ocasiones de algo donde PAM se siente involucrado no tengo problema en entender lo que me están contando.
Dejando de banda de como voy dando mis primeros pasos en este mundo tan amplio, me centro un poco en lo que es la entrada en sí.

Los inicios

Cuando decidí meter Gentoo en la mi máquina de casa, lo hice, intentando enterarme, de para que sirve y porque se hace todo lo que el handbook explica paso a paso, así consideré que era una manera de aprender aspectos que hasta el momento desconocía y añadir algún granito más al monto de conocimientos que voy almacenando sobre este enorme mundo; además, como el handbook en ciertos puntos deja abiertas indicaciones que se puede hacer esto y esto otro, en algunas de ellas me fui informando para hacerlo en un futuro o directamente me informé y me puse a configurarlo como me gustaría tenerlo, por eso que dicen de “no dejes para mañana lo que puedes hacer hoy”.

Una de esas cosas, fue securizar la configuración de acceso de las cuentas de usuarios del SO (/etc/login.defs), es decir meter un mínimo de valores en los parámetros necesarios para garantizar un password con longitud mínima y con una caducidad para, básicamente, auto-obligarme a cambiarlo de vez en cuando.

Con esto yo ya creía que todo estaba, de hecho en parte no porque no había puesto la mínima complejidad requerida, algo que me preocupaba poco porque by default me complico la vida en el momento de asignar passwords de acceso a cualquier sistema.

El día a día

Después de tener el sistema listo, el empacho me duró un tiempo, además empecé a liarme con otras cosas, demasiadas, que me ocuparon y me ocupan el tiempo para dedicarme, de nuevo, con mente y cuerpo a trabajar para el SO, eso sí, sin tener en cuenta las incidencias de actualizaciones, de despliegue de nuevos servicios/aplicaciones, etc., que me han ido surgiendo y algunas de ellas ya he ido comentando en alguna que otra entada de este blog.

Una de las cosas que me ha ido persiguiendo desde entonces es que cada vez que cambio el password, el SO me solicitaba dos veces, más bien dos pares de veces, el nuevo password.

Ejecución de passwd para cambiar el password de acceso al SO; se ve como se pregunta el password dos veces

¿El motivo? Ni idea, sino lo hubiese solucionado desde un primer momento; el hecho es que no me importaba mucho, ya que metiendo las dos veces el mismo se cambiaba y como estaba perezoso en googlear para buscar un poco para saber que puñetas pasaba, la cosa se ha quedado así hasta hace un par o tres de semanas.


Hasta la próxima enfermos.