viernes, 3 de julio de 2009

Feevy

lunes, 19 de enero de 2009

Renovar la versión de gentoo

Esto es una mini anotación para tener en cuenta en las actualizaciones del gentoo.Hay que sustituir el 2008.0 por la versión más reciente del repositorio. Así mismo, se puede sustituir desktop por otras versiones de repositorio disponibles
# cd /etc/
# rm make.profile
# ln -s /usr/portage/profiles/default/linux/x86/2008.0/desktop make.profile

martes, 13 de enero de 2009

Problemas de validación en dominio

Cada día los equipos informáticos son más rápidos y potentes, y ésto, aunque sorprenda, puede plantear algún problema.
Ya en su día me enfrenté a un problema de colapso de la red debido a que los enlaces troncales de la oficina eran de 100 Mbps y a medida que se cambiaban equipos y se instalaban impresoras compartidas, la red llegó a colapsar. La solución, aunque poco popular fue efectiva. Limitar en los conmutadores la velocidad de acceso a 10 Mbps.
El último problema y a mi entender más grave, es la velocidad con la cual se arrancan los equipos. Existe en las redes ethernet un protocolo imprescindible, el Spanning Tree, que evita que un cable mal puesto generando un bucle, provoque la caída de la red de datos. Por diseño, este protocolo tiene unos elevados tiempos de convergencia (tiempo que pasa desde que un puerto se levanta hasta que realmente admite datos). Este tiempo es necesario ya que se escucha la información de la red y del nuevo puerto para verificar que no se trata de un bucle.
Los más avispados ya sabréis por donde anda el problema. El tiempo de convergencia es de 30 segundos. Si el equipo intenta validarse en la red (u obtener la dirección por DHCP), antes de que transcurran estos 30 segundos, la red se "tragará" la información.
A continuación adjunto una receta de como tratar el problema. No la recomiendo en absoluto, ya que es mejor retrasar o hacer mayor el timeout de validación, que no arriesgarse a un bucle en la red, con la consecuente caída de la misma.
La solución pasa por eliminar el STP o reducir el tiempo de convergencia. Otros tiempos de espera son debidos a las negociaciones de configuración, pero son menos habituales y ya dependen mucho del tipo de equipo, marca, modelo, etc.

Es posible que los tiempos de negociación de los puertos de los conmutadores, retrase la disponibilidad de la red para:
* Obtener las direcciones del DHCP.
* Validarse correctamente en el dominio.

Estos tiempos de negociación se deben a los siguientes protocolos:
1.- STP.
2.- EtherChannel (No en todos los equipos).
3.- Velocidad / Modo.
4.- Puerto de enlace (DTP). (no en todos los equipos)

Procederemos de la siguiente manera para diagnosticar el posible fallo por el retardo:
Para averiguar el tiempo que se tarda en la negociación:

1.- Habilitar el modo de depuración sobre los puertos o sobre el spanning tree al maximo. Esto nos permitirá ver los cambios de estado del puerto y los tiempos (tiemstamps) en los cuales se producen.

2.- Deshabilitar el puerto de forma administrativa y volverlo a habilitar. Esto dejará en consola los tiempos de cambio entre cada estado del puerto. En teoría el protocolo STP tarda en converger 30 segundos, 15 segundos para la fase de listening y otros 15 segundos para la fase de learning. Los tiempos de negociación de la velocidad suelen rondar los 2 a 4 segundos.

3.- Es posible, aunque peligroso reducir el tiempo de convergencia del spanning tree, ya que ante un bucle, éste podría llegar a provocar una tormenta de broadcast, ya que los 30 segundos se usan para determinar si existen bucles. Para reducir el tiempo existe un comando denominado portfast

4.- Otros retardos en la negociación de la comunicación, para establecer la configuración final del puerto, podrían ser agravantes de la situación. Pero estos ya dependerán de características concretas de los equipos.

NOTA:
Adicionalmente hemos de tener en cuenta que es parametrizable el tiempo que espera el netlogon (servicio de inicio de sesion de Windows). Esto se establede por la variable ExpectedDialupDelay (de tipo Reg_Dword).
Esta variable se establece en el registro de windows (regedit), en la siguiente rama:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters.

lunes, 22 de diciembre de 2008

No tanta, Libertad para Telefónica

Hace algún tiempo comenté un artículo que me sorprendió sobre la permisividad de la CMT para con Telefónica. En este comentaba que se creaban dos zonas diferenciadas de regulación a las cuales se le aplicaban diferentes condiciones. Las dos zonas fundamentalmente se basaban en si era o no rentable el despliegue de la red de banda ancha de acceso a Internet.
Esto beneficiaba a Telefónica en tanto en cuanto, aceptaba las condiciones más exigentes del regulador en las zonas poco rentables, y como contrapartida se le permitía más libertad en las zonas donde el negocio resultaba más rentable. Esto se justificaba por parte de Telefónica, argumentando que en las zonas rentables a los operadores le interesa el negocio suficiente como para invertir en infraestructuras.
Después de leer el artículo (La CMT anula la ventaja de Telefónica en fibra óptica) parece que a la comisión europea no le ha gustado la argumentación y no le permite a la CMT esta diferenciación de regulaciones por zonas.
La clave parece estar ahora en la velocidad. Esto es válido a partir de ciertos caudales. Es decir, para caudales inferiores a un límite (actualmente 30 Mbps) la regulación exige a Telefónica a revender el servicio a precios regulados, mientras que para caudales superiores, tiene libertad de precios en esta reventa de servicio. El truco es que el regulador se reseva el derecho a modificiar este límite, pudiendo en un futuro incrementarlo a 50 Mbps, 100 Mbps, etc. Esto es muy lógico, teniendo en cuenta que la tecnología en matería de telecomunicaciones, tiene el caudal elemento clave de cobro.

viernes, 21 de noviembre de 2008

Canalizaciones y Cableado: Capacidad de conductos

Índices de Llenado

Un índice de llenado se refiere a la cantidad de cableado que se puede tender en una canalización o espacio. Para conservar las garantías en materiales ignífugos y para reducir el efecto de diafonía exógena, estos índices se deben mantener de acuerdo con las normas. Para diámetros de cable más grandes, como los permitidos en los diseños UTP de categoría 6 aumentada, el número de cables permitidos en un espacio concreto disminuirá y en muchos casos se requerirán canalizaciones y espacios más grandes. En algunas jurisdicciones en las que todo el cableado debe pasar por conductos debido regulaciones locales, los costos de construcción iniciales y de actualización pueden aumentar de manera significativa. Para áreas en paredes de oficinas donde hay que proporcionar canaletas, se necesitarían conductos de tamaño más grande para los nuevos sistemas 6A UTP.

En la siguiente tabla se muestran tamaños y áreas comerciales de los conductos.

Tabla 1: Áreas y tamaños comerciales de los conductos

El tamaño del conducto se expresa según el tamaño comercial en pulgadas o milímetros. El área es el área interna que puede ser ocupada por cables. Se recomienda usar un índice de llenado de 40% para los tendidos iniciales para dejar espacio para nuevos tendidos futuros. La fórmula para calcular el índice de llenado es la siguiente:

Los codos o curvaturas también se deben tener en cuenta y afectan directamente la capacidad del conducto. Se debe incluir un factor de reducción del 15% por cada codo para asegurar que la tensión de jalado no se vea afectada de modo importante. En consecuencia, un tendido de conducto con un 40% de llenado y 3 codos estaría limitado a una capacidad calculada de:

100%-15%-15%-15%= 55% ; 40% de llenado x 55% de capacidad = 22% de índice
de llenado disponible


Artículo extraído de http://www.siemon.com.

Algunos cálculos adicionales:

Indice de llenado 50,00%




31,67 63,82 19,64
Áreas transversales de los conductos: mm2 Cantidad de cables Cantidad de cables Cantidad de cables
16 193 3,05 1,51 4,91
21 340 5,37 2,66 8,66
27 560 8,84 4,39 14,26
41 1313 20,73 10,29 33,44
53 2172 34,29 17,02 55,31
63 3086 48,72 24,18 78,58
78 5024 79,32 39,36 127,93
91 6387 100,84 50,04 162,64
103 8231 129,95 64,49 209,6





Area transversal del Cable



Categoría 6 aumentada UTP (9 mm) 63,82


Categoría 6 (6.35 mm) 31,67 Alcatel Symtek 100 Ohm Cat6

Cableado Categoria 5 5mm 19,64




lunes, 21 de enero de 2008

SSH sin contraseña

Cansado de tener que buscar este tipo de soluciones, molestarme en seleccionar la correctamente explicada y traducirme temporalmente los contenidos, voy a volcar mis notas técnicas en este blog. Disculpad los que tengan que sufrir.
1.- Generamos una pareja de claves pública y privada en la máquina y usuarios, desde el cual accederemos. Esto es como crear una identidad digital, para que los demás nos conozcan. Una cuestion importante antes de esto. Lo recomendable es introducir una frase de paso antes para emplear las claves, pero esto nos obligará a introducirla siempre que las usemos. Mi consejo es que si tu objetivo es no memorizar las claves de cada una de las máquinas, unificando el acceso en una sola clave, adelante. Si tu objetivo es, como fue el mio, emplear esto en scripts, no le pongas clave, pero mucho ojo con los permisos de los ficheros y con la seguridad del usuario en la máquina local:
# ssh-keygen -t rsa.
Esto genera dos ficheros ubicados en /home/"usuario_local"/.ssh :
id_rsa y id_rsa.pub (Claves privada y pública). El primero NUNCA debe de salir de tu equipo, mientras que el segundo debes de incorporarlo a los demás.

2.- Debemos de acceder a la máquina remota, elige tu el sistema, para depositar nuestra identidad. La identidad la debes de depositar en el directorio /home/"usuario_remoto"/.ssh, siendo el "usuario_remoto", el usuario con el cual entras. Dentro de este directorio hay al menos un archivo denominado
authorized_keys. En este AÑADES la línea contenida en el fichero id_rsa.pub. En mi caso me gusta seguir estos pasos:
2.1.- Desde el equipo local, ubicándonos en el directorio .ssh , copiamos el fichero .pub:
local# scp id_rsa.pub eqremoto:/home/"usuario_remoto"/.ssh/importar_clave
2.2.- Añadimos la línea. Ya entrando en la máquina remota:
local# ssh eqremoto
remota# cd /home/"usuario_remoto"/.ssh
remota# cat importar_clave >> authorized_keys
remota# chmod 644 authorized_keys
2.3. La línea chmod evita que alguien no autorizado pueda modificar el fichero. Ya podemos borrar el fichero creado para llevar la clave de la máquina local a la remota.
remota# rm
/home/"usuario_remoto"/.ssh/authorized_keys

(Acepto comentarios y sugerencias de mejora, incluso dudas al respecto.).
Fe de erratas: Se ha corregido un error en el nombre del fichero de claves, faltaba una h.

Gracias.

Complemento:
Para aquellos que necesiten realizar una copia en un dispositivo remoto empleando el ufsdump, tan popular en los Solaris, podéis emplear el método anterior para garantizar que el acceso vía ssh no requiere contraseña, y luego ejecutar el comando siguiente:
# ufsdump 0uf - /dev/md/rdsk/d33 | ssh eqremoto "dd obs=32k ibs=32k
of=/dev/rmt/0n"
Esto está probado entre dos máquinas Solaris y funciona perfectamente.

SOLUCION DE PROBLEMAS:

1.- Una potente manera de resolver problemas en la puesta en marcha de esta solución es arrancar el demonio y el cliente con las opciones de depuración:
Ejecutamos el demonio en la máquina remita:
eqremoto# /usr/sbin/sshd -p 2200 -ddd
(la opción -p indica el puerto del servicio, las 'd's indican los grados de depuración.)
En el caso del cliente hacemos algo similar:
eqlocal# ssh -p 2200 -vvv remota
Ambos terminales nos darán información de las negociaciones para la conexión.

2.- Comparar la identidad de la máquina local con la identidad registrada en la remota puede resultar conveniente.
Os recomiendo en la máquina remota ejecutar lo siguiente:
eqremoto# cat -n /home/"usuarioremoto"/.ssh/authorized_keys
Este enumera las líneas para diferenciar claramente cada una de las claves
eqlocal# cat -n /home/"usuariolocal"/.ssh/id_rsa.pub
Este solo debe de contener una linea y ha de ser idéntica a alguna de las existentes en el equipo remoto.

3.- Debéis de aseguraros que ambas máquinas se identifican correctamente por nombre, es decir, que los nombres de los asociados a cada máquina, están correctamente relacionados en el fichero /etc/hosts.

Libertad para Telefónica

Acabo de leer un artículo francamente interesante. Obviamente su título no es el de esta reseña.

El artículo en cuestión menciona la comunicación de la CMT hacia las operadoras, de las nuevas tendencias en el reglamento que está preparando. En líneas generales, y siempre según el artículo, el objetivo de la CMT es conseguir que se realicen inversiones en nuevas tecnologías orientadas a mejorar las redes e infraestructuras de lo que se denomina la última milla, es decir, hasta la casa del abonado.

¿Cómo lo pretenden realizar?, no forzando los precios de Telefónica en las contrataciones que otras operadoras realicen, sobre estas nuevas infraestructuras. Forzando así
La regulación se justifica, dado que Telefónica ejerce una posición dominante en la ultima milla, en cuanto a pares de cobres tendidos. Ninguna empresa sería capaz de realizar un tendido de cobre similar al de Telefónica y además hacer rentables estas inversiones, en un plazo razonable.
No sucede lo mismo, o esa es la teoría, con las redes de fibra, ya que Telefónica no tiene fibra óptica hasta el abonado, no tiene posición dominante. En resumen, Telefónica tendrá libertad para poner precios a sus tendidos de fibra óptica hasta la el abonado, para la prestación de servicios por parte de otras operadoras, lo que actualmente no sucede con los pares de cobre.

Adicionalmente, se mezcla en el artículo la nueva definición de servicio universal. Tras leer el artículo, no me resulta muy claro si es referido a las nuevas infraestructuras o también para las existentes, pero se abre la puerta a establecer diferentes regiones geográficas en las regulaciones de la CMT, es decir, básiamente habrá zonas de primera (competitivas) y zonas de segunda (no competitivas). Las primeras, serán las zonas donde se supone que es muy rentable invertir en infraestructuras y por tanto, no se aplicarán condiciones especiales a Telefónica, ya que al resto de operadoras también les resulta rentable invertir en despliegue de red. En las zonas de segunda, donde las inversiones no serán rentables (pueblos, aldeas, zonas escasamente pobladas), será la CMT quien marque más estrechamente las reglas y exigencias a la operadora dominante. ¿Cuáles serán estas?.

En el artículo se menciona que este nuevo reglamento es favorable a Telefónica, ya que le entrega un escenario trabajo donde puede luchar con todas sus armas, contra las demás operadoras. Adicionalmente, la diferenciación regulatoria para las zonas competitivas y no competitivas, es una petición de Telefónica desde hace algún tiempo. Esto me hace pensar, unido a las fechas preelectorales, que este anuncio de la CMT resulta muy rentable a nivel político. Promete 100 megas a los usuarios, servicios inimaginables y "libertades" mayores a una de las empresas más grandes de España.
[Espacio para meditar]

Como usuario vicioso del Internet, solo espero que si ahora pago por 4 megas y tengo solo 1 mega, cuando intenten vender los 100 megas, a mi me bajen el precio, o me den lo que pago.