Ir al contenido principal

Hora de aventuras

En esta ocasión, mi post es un cuento. Alguno se sentirá identificado.

Érase una vez un imbécil que compró unos equipos Wifi 5GHz (2 AP y 2 antenas) para montar un bridge entre un edificio y otro. Se montó todo en un despacho, con antenas internas, por parte de BuenChicoNervioso (del vendedor) y funcionó a la primera, pero no se podía montar en su ubicación final porque faltaban unos cablecitos de nada que el fabricante había olvidado incluir o el vendedor había olvidado pedir, da igual. Hay que hacer cierto cambios en la configuración, orientados por el fabricante, para que los AP acepten esas antenas en España.

Pasada más de una semana, llegaron los cablecitos y a nuestro protagonista le enviaron a Zopenco1 a instalarle los dispositivos en sus lugares finales. Una vez puestos con las antenas outdoor, no había forma de que el enlace bridge se levantara. Le dijo Zopenco1 que las antenas estaban mal ubicadas, que llegaba poca potencia, y Zopenco1 se negaba a cambiar nada, así que nuestro amigo llamó al jefe de ya citado Zopenco. Al dia siguiente, ese jefe vino y reorientó las antenas, pero surgió una duda: ¿cómo se debían conectar las antenas a los AP?

Tras buscar en Internet infructuosamente, nuestro amigo lo preguntó al fabricante, y Zopenco2 y Zopenca3, empleados de soporte del fabricante, no fueron capaces de explicarlo.Así que elevaron el caso, y un amable TipoQueSabe1 le explicó a nuestro ya bastante afectado protagonista que daba igual a qué toma conectar las antenas Outdoor, cerrando a continuación el caso. Ese mismo dia, BuenChicoNervioso y el jefe de Zopenco1 tuvieron que dejar sin montar el sistema porque parecía que las antenas externas habían averiado los APs. Nuestro amigo detectó que, efectivamente, uno iba mal y solicito un cambio al fabricante. Por otro lado, abrió otro caso para ver porqué el AP que iba bien tardaba 10 minutos en activar la antena y emitir. El encargado de este caso, Zopenco4, del fabricante, indicó a nuestro amigo que esperase a tener el AP de repuesto para seguir intentando hacerlo funcionar.

Recibido el AP de repuesto, nuestro amigo contactó con Zopenco4, que estuvo operando sobre el hardware de control del sistema wifi corporativo, desconfigurando puertos y demontando el cluster de control del wifi, consiguiendo el enorme éxito de que el segundo AP respondiese al comando ping conectado via Ethernet. Tras varias horas de espera y con los nervios a flor de piel, nuestro amigo le dijo a Zopenco4 que se dejase de rollos y que mañana sería otro día.

Al día siguiente, a media mañana, cuando ZOpenco 4 se incorporó a su puesto, repitió las mismas tonterías del dia anterior, hasta que se dió por vencido y le pasó el caso a TipoQueSabe2. Este repitió, de nuevo, varias de las actividades de Zopenco4, redujo el ancho de banda a la mitad, y poco más consiguió, salvo hacer perder los nervios a nuestro protagonista y a BuenChicoNervioso. Tras un rato de idas y venidas, TipoQuesabe2 descubre que con la versión de firmware de las controladoras wifi hay un bug que impide que, con la configuración que el fabricante recomendó al principio, se pueda formar el enlace wifi del bridge. A resultas, TipoQueSabe2 propone actualizar el firmware un viernes a las 14 horas, y el pringado de nuestro protagonista le dice que vale, porque total, son 15 minutos por controladora.

Asi que se ponen a descargar la nueva version de firmware donde está solucionado el problema (ya lo podían haber dicho hace varios dias, piensa nuestro amigo), y el TipoQueSabe2 dice que se necesita un FTP o TFTP para que las controladoras cojan de alli el ficherito del firmware. Nuestro amigo tiene un FTP Server, pero no recuerda las contraseñas. Cuando averigua una, se ponen a descargar el firmware a una particion de cada controladora, y una se queda colgada. El TipoQueSabe2 pide que se reinicie dicha controladora manualmente, tirando del cable de alimentación. Nuestro amigo, pasadas las 15h. de un viernes y después de dos semanas de auténtico horror en el trabajo, se encuentra con un fallo eléctrico en un switch ethernet stackado. Este inocente evento tumba todo el cluster de computación (supone nuestro amigo que por los timeouts excesivamente pequeños para detección de nodos caidos, y porque los nodos se matan entre sí).

Así que nuestro amigo, conocedor del tiempo necesario para levantarlo todo, le dice a TipoQueSabe2 que contactarán el lunes a primera hora para finalizar la actualización del firmware y verificar que el bug esté solucionado. Y luego, se queda tranquilamente (es un decir) levantando todos los servicios de su organización hasta bien entradas las 17h y sin comer. Para acabar de redondear el tema, nuestro amigo tenia pensados unos cambios en volumenes de almacenamiento para el lunes, pero la 'parada no planificada' y el arranque de las máquinas virtuales le ejecuta los cambios y se ve obligado a reconfigurar ACLs y un servicio SAMBA.

Y colorín colorado, este cuento sigue el próximo lunes.

Comentarios

Entradas populares de este blog

Malas praxis en certificados del ENS

 ¡Ojo con los certificados de conformidad con el Esquema Nacional de Seguridad! Recientemente, he tenido acceso a un certificado de conformidad con el ENS emitido por la Empresa A a la Empresa B . La Empresa B se dedica a servicios de desarrollo de software, entre otras cosas, y la Empresa A es una consultora de certificación en diferentes normas. En determinadas circunstancias las AA.PP. han de exigir el cumplimiento del ENS a sus proveedores de servicios, para lo cual se han de obtener los correspondientes certificados de conformidad, que permiten utilizar los distintivos cuyo uso se describe en la Guia CCN-STIC 809 . El certificado al que tuve acceso tenía como título " Certificado de conformidad con el Esquema Nacional de Seguridad ", indicaba que se había emitido a nombre de Empresa B por parte de Empresa A, para una serie de servicios de TI, disponía del distintivo oficial de nivel Medio (en este caso), tenía su número de registro, su fecha de emisión y caducidad, y l

Entrevista para Computerworld University

El pasado 9 de enero se publicó el video de la entrevista que Marlon Molina me hizó unos días antes para Computerworld University, centrada en la temática de mis artículos para Tecnología y Sentido Común sobre la respuesta ante incidentes de ciberseguridad, y el impacto que la improvisación en esta materia puede tener para nuestras organizaciones. Espero que les guste.

Entrando al trapo con BlockChain

Desde que escribí mi anterior entrada , una breve reflexión sobre Blockchain, he seguido 'dándole vueltas' al tema, leyendo, asistiendo a eventos, etc.. Y creo que ya puedo plantear cuestiones que no son ni evidentes ni nimias, y a las que habrá que dar solución en breve. No tocaré aspectos técnicos, tranquilos . Blockchain se encuentra ahora en un estado similar a como se encontraba la Web en 1994. Esta reflexión ya la he leído y oído más de una vez (a William Mougayar y a Pep Lluis de la Rosa ), en el sentido de que aún no sabemos todo lo que la tecnología Blockchain va a permitirnos hacer, igual que casi nadie imaginaba en 1993 en el CERN hasta dónde iba a llegar la tecnología web que regalaron al mundo entero. Es evidente que su primera aplicación han sido las criptomonedas, pero no será la única. La trazabilidad , la seguridad y la transparencia que aporta Blockchain son unos activos muy útiles para muchas de las actividades actuales, como la fe pública, ahora en mano