Instalacion de Linux en un servidor SUN Fire

A continuacion se describe el Procedimiento para la Instalacion del Sistema Operativo Debian GNU/Linux en un
Hardware Servidor SUN Fire V210. Como sabemos, este Hadrware no dispone de Tarjeta para Salida de Video
VGA ni Puerto PS2 para Teclado. Lo que si dispone es de un Puerto Serial para Management. Este Servidor tiene
una Arquitectura SPARC de 64 Bits.

A continuacion los Pasos:

1.- Descarga de la Imagen ISO.
Debemos ir al Link http://cdimage.debian.org/debian-cd/6.0.3/sparc/iso-cd/
y descargar al menos el CD1 de la Distro Debian para Sparc64 (con el CD1 es Suficiente para la Instalacion)
Descargamos entonces el ISO: http://cdimage.debian.org/debian-cd/6.0.3/sparc/iso-cd/debian-6.0.3-sparc-CD-1.iso
y lo quemamos en un CD Virgen con cualquier Quemador. Siempre recomiendo quemar los CDs a baja velocidad para evitar algunos inconvenientes.
Colocamos el CD de la Imagen Debian en la Unidad CD/DVD ROM del Servidor.

2.- Ahora, debemos establecer una Conexion via Serial COM con el Servidor Sun Fire V210.
Podemos utilizar Hyperterminal, Minicom o incluse Puttytel. Establecemos una Conexión con los Parametros 9600,8,n,1 (Default). El cable a utilizar es un cable tipo Rollover (NO Crossover). Tipicamente los cables de consola de los equipos Cisco van a funcionar.

3.- Arrancamos el Servidor. El Reto es lograr que haga Boot de la Unidad de CDROM.
Para ello, hacemos lo siguiente: Cuando el Servidor este Arrancando, presionamos la Secuencia 'STOP + A'.
En un Teclado Convencional, esta secuencia es la misma que 'CTRL+SHIFT+BREAK' o 'CTRL+BREAK'.
Al hacer esto, nos aparecera el PROMPT {} Ok, cuando ello suceda hacemos lo siguiente:
{}Ok printenv auto-boot        (Para ver el Estado del Flag auto-boot)
{}Ok setenv auto-boot false    (Para Setear el Flag auto-boot en False)
{}Ok reset-all    (Reiniciamos el Sistema)

4.- Cuando el Sistema Reinicie, volvemos a Presionar 'STOP + A', y al aparecer el Prompt {}Ok lo que hacemos es
indicarle que haga Boot del CDROM, asi:
{}Ok boot cdrom
A partir de este momento comenzara el Boot del Servidor desde el CDROM. Recomiendo que se coloque a
FULL SCREEN el Hyperterminal para ver la Instalacion como si fuera una Pantalla Completa.
Desde este momento, se sigue exactamente el procedimiento de Instalacion de Debian (Usuarios, Particiones, Repositorios, etc.)

Puntos Clave:
- Descargar la Imagen ISO para SPARC 64.
- La Secuencia 'STOP + A', la cual puede ser tambien 'CTRL+BRAK' o 'CTRL+SHIFT+BREAK'.
- Colocar la Pantalla en FULL Screen.
- Si en algun Momento se Pierde la Conexion Serial (suele pasar con Puttytel), simplemente Cierre y Reabra la
Conexion Serial y Teclee cualquier Tecla para recuperar la Instalacion.
- El sistema BOOTEA del CDROM cuandl estando el PROMPT {}Ok se Teclea 'boot cdrom  (Muy Importante...!!!)
- Para que el servidor arranque de manera automatica es necesario en el prompt ok escribir lo siguiente:

auto-boot?=true  

boot-device=disk

 

 

 Espero sea util.

Manual basado en documentacion de profesor Jose Gregorio Cotua

Actualizar de Android 1.5 a Android 2.1 en Samsung i5700

Situacion:
  Deseo actualizar mi samsung i5700 de Android 1.5 a 2.1

Notas:
  Keis moderno no funciona en Android 1.5 en el i5700 por ello es necesario el software: Kiesmini que se consigue en: http://www.samsung.com/ca/support/download/supportDownloadMain.do. Es muy importante realizar esta tarea porque el Market de Android no funciona correctamente con Andriod 1.5

Procedimiento:
  - Desinstalar cualquier referencia en el PC que tenga software de Samsung
  - El telefono debe estar completamente cargada (el software kiesmini puede indicar que no va a realizar la operaciones porque el telefono no tiene suficiente carga
   - Remover el SIM y la memoria SD del telefono
   - Apagar GPS y bluetooth del telefono
   - Conectar via USB (Obligatoriamente USB, no Bluetooth ni wireless) el Telefono y el PC
   - Ejecutar minikies
   - En la opcion de Menu instalar el driver USB (sino se hace el telefono no será reconocido)
   - Luego de que el telefono es reconido realizar el upgrade

  En caso de error reiniciar el telefono y estar completamente seguro que el SIM Card esta removido asi como la memoria SD.

ESTE PROCEDIMIENTO LO CORRES A TU PROPIO RIESGO. NO DOY GARANTIA DE QUE FUNCIONA. REALIZA UN BACKUP ANTES DE REALIZAR EL PROCEDIMIENTO

 

Certificacion IPv6 de Hurricane Electric

  En esta oportunidad voy a dejarles mis impresiones sobre la certificacion IPv6 que tiene Hurricane Electric en http://ipv6.he.net/certification
na primera oportunidad la habia ignorado pero en esta oportunidad la curiosidad me llamo.
  Les comento que me parece muy interesante la misma; me gusta la manera como esta organizada. Les cuento un poco:

- La certificacion se puede hacer por pasos y en varios dias. Esto da bastante comodidad.
- Para cada nivel te mandan a hacer varias "tareas" tales como: Configurar un servidor Web, de Correo, DNS, prueban conectividad a equipos tuyos etc.
- Es didactica y divertida
- Logicamente para comenzar la certificacion debes estar desde una maquina IPv6
- Existen varios niveles de certificacion: Newbie, Entusiasta, Administrator, Professional, Guru, Sage. A pesar de que me agrada la idea de varios niveles, creo que los nombres le quedan grande al nivel, por ejemplo, obtener el grado de Administrator me parece sencillo y su nombre suena casi a experto.
- Te mandan una franela/remera gratis de IPv6!!!!

  Desde mi punto de vista las personas que manejen servidores y conectividad directamente tienen una enorme ventaja sobre los que no.

Consejos previos para prepararse para la certificacion:
  - Como recomendacion, antes de comentar el examen, tengan un dominio con el cual puedan trabajar, quiero decir, que puedas crear zonas, modificar registros, etc.
  - Maquina servidor (preferiblemente Linux) con conectividad a IPv6
  - Acceso y configuracion a servicios tales como Web Server y Mail Server

Mas informacion
  - La pagina para los que esten interesados es: http://ipv6.he.net/certification/
  - En este blog hay mucha informacion sobre IPv6 sobre Linux y algunos servicios como Apache y Sendmail http://acostanetwork.blogspot.com

  Saludos y suerte a los que deseen tomar la certificacion!!.    

Verificar el origen de un prefijo BGP

Historia:
  En algunas situaciones queremos estar seguros que el prefijo BGP aprendido en nuestro router sea efectivamente originado por quien debería ser. Han ocurrido ciertas eventualidades en la historia del mundo de Internetworking donde un Sistema Autonomo ha publicado redes no debidas (ej: http://www.ripe.net/internet-coordination/news/industry-developments/youtube-hijacking-a-ripe-ncc-ris-case-study).
  Hoy en día un poco más del 10% de los prefijos asignados por los RIRs (Lacnic, RIPE, Afrinic, ARIN y APNIC) tienen asignado un ROA (Route Origin Authorization) el cual indica de manera segura quien es el sistema autonomo asignado para publicar cierto prefijo. A lo anterior se le conoce como Resource Public Key Infrastructure (RPKI) 


Problema:
  Deseo saber cual debería ser el sistema autónomo de un prefijo especifico (por ejemplo una red aprendida por BGP). 


Solución:
  Seguramente en un futuro cercano tendremos decenas de páginas Web donde podamos consultar el sistema autonomo que debería publicar cierta red (quizás hoy en día existen y yo no las conozco), en fin, nuestro buen amigo whois nunca nos falla. En esta oportunidad nos apoyaremos en el servidor whois de bgpmon.net


  Aquí les dejo los comandos y unas salidas ejemplos:

• ROA con problemas (
  Se esperaba el AS 17NN9 y esta siendo publicado por el 79NN)):

aacosta@bind:~$ whois -h whois.bgpmon.net 2001:NNNN::0


Prefix:              2001:NNNN::/32
Prefix description:  
Country code:        VE
Origin AS:           79NN
Origin AS Name:      NNNNNN.
RPKI status:         ROA validation failed: Invalid Origin ASN, expected 17NN9

• ROA satisfactorio:

aacosta@bind:~$ whois -h whois.bgpmon.net 2001:NNNN::0


Prefix:              2001:NNNN::/32
Prefix description:  
Country code:        VE
Origin AS:           79NN
Origin AS Name:      NNNNNNN.
RPKI status:         ROA validation successful

• SIN ROA (en este prefijo no podremos saber que AS debería publicarlo):

aacosta@bind:~$ whois -h whois.bgpmon.net 2800:NN::0

Prefix:              2800:NN::/32
Prefix description:  
Country code:        AR
Origin AS:           79NN
Origin AS Name:      NNNNNN
RPKI status:         No ROA found

Más información:
http://acostanetwork.blogspot.com/2011/03/historico-de-tablas-bgp-hijack-de-mi.html (Histórico de tablas BGP)
https://labs.ripe.net/Members/Paul_P_/content-serving-roas-rpsl-route-objects
http://bgpmon.net/blog/?p=414

Ejemplos de hping

Ejemplos de hping:

Enviar paquetes TCP SYN al puerto 0 en la máquina example.com (nótese que hping  incrementara el puerto origen en 1 por cada paquete enviado):
#hping example.com-S-V  

Enviar los paquetes TCP SYN al puerto 443 en el host example.com:
#hping example.com -S-V-443 p  

Enviar paquetes TCP al puerto 443 en el host example.com con los flags SYN + ACK encendidos en conjunto:  
#hping example.com-S-A-V-443 p  

Enviar paquetes TCP al puerto 443 en el host example.com con el SYN + ACK FIN + set:  
#hping example.com -S-A-F-443 V-p  

Enviar paquetes TCP SYN cada 5 segundos en el puerto 443 en el host example.com:  
#hping example.com -S-443 V-p-i 5  

Enviar paquetes TCP SYN cada 100.000 microsegundos (es decir, cada 0,1 segundos o 10 por segundo) en el puerto 443 en el host example.com. Tenga en cuenta que se ha eliminado detallado:  
#hping example.com -S-p 443-i u100000

Enviar paquetes TCP SYN cada 10.000 microsegundos (es decir, cada 0,01 segundos, o 100 por segundo) en el puerto 443 en el host example.com:  
#hping example.com-S-p 443-i u10000  

Enviar paquetes TCP SYN cada 10.000 microsegundos (es decir, cada segundo de 0,01 o 100 por segundo) en el puerto 443 en el host example.com. Parar después de 500 paquetes:  
#hping example.com-S-p 443-i-c u10000 500  

Enviar paquetes UDP al puerto 111 en el host example.com (argumento - udp puede ser sustituido por -2): #hping example.com - udp-V-111 p

Enviar paquetes ICMP echo request para recibir example.com (argumento - icmp puede ser sustituido por -1): 
#hping example.com - icmp-V 

Enviar ICMP paquetes de solicitud de marca de tiempo para organizar example.com:  
#hping example.com - icmp - icmp-ts-V 

 Escaneo de puertos TCP 100 a 110 en el host example.com (argumento - el examen puede ser sustituido con -8)
#hping example.com-V - scan 100-110  

Enviar paquetes UDP falsa a partir de host de origen para recibir 192.168.1.150 example.com
#hping example.com - udp - parodia 192.168.1.150  

Enviar paquetes UDP falsa a varios de IP de origen aleatoria para recibir example.com
#hping example.com - udp - rand-fuente  

Enviar paquetes UDP con la parte de datos rellena con 100 bytes para albergar example.com
#hping example.com-V - udp - los datos de 100  

Enviar paquetes UDP con la parte de datos rellena con 100 bytes, pero con el contenido de payload.txt para albergar example.com (la carga útil se truncará si es menor de lo especificado por el argumento - de datos) 
 #hping example.com-V - udp - payload.txt archivo - los datos de 100


Más info:
El presente documento es una traducción con una pequeña adaptación de:
http://rationallyparanoid.com/articles/hping.html  (documento sencillo y practivo que me pareció excelente)

Utizando Netem. Simulando escenarios de red. Ejemplos de tc/netem

Problema:
  Deseo simular algunos escenarios de red.
    a) Simular en un salto satelital
    b) Simular perdida de paquetes

  Lo anterior es de mucha utilidad porque permite probar escenarios -casi reales-. Se pueden probar aplicaciones y conocer como se comportan ante una alta tasa de pérdida de paquetes y/o ante altos tiempos de respuesta. Otra opción es conocer el comportamiento ante pérdidad y/o RTT aleatorios y muchas otras cosas.


Solución:
  Netem (Network Emulacion) que permite simular escenarios de red muy tipicos en redes WAN, MAN y Satelitales.
   Netem es controlado con el comando tc que es parte de iproute2

Ejemplos:

a)  Simular el Round Trip Time de un salto satelital (550 ms):

# tc qdisc add dev eth0 root netem delay 550ms

Fijense del tiempo del ping antes y durante el comando (salto del 10 al 11):

[root@localhost ~]# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=53 time=51.7 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=53 time=48.6 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=53 time=50.9 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=53 time=49.8 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=53 time=51.8 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=53 time=50.4 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=53 time=49.9 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=53 time=50.6 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=53 time=51.1 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=53 time=50.6 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=53 time=601 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=53 time=600 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=53 time=601 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=53 time=600 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=53 time=600 ms
64 bytes from 8.8.8.8: icmp_seq=16 ttl=53 time=600 ms


b) Simular una red WAN con tiempos de mayor variación (de 100 ms - 10 ms) de manera aleatoria:

# tc qdisc change dev eth0 root netem delay 100ms 10ms

64 bytes from 8.8.8.8: icmp_seq=60 ttl=53 time=49.3 ms
64 bytes from 8.8.8.8: icmp_seq=61 ttl=53 time=50.5 ms
64 bytes from 8.8.8.8: icmp_seq=62 ttl=53 time=59.6 ms
64 bytes from 8.8.8.8: icmp_seq=63 ttl=53 time=50.7 ms
64 bytes from 8.8.8.8: icmp_seq=64 ttl=53 time=49.6 ms
64 bytes from 8.8.8.8: icmp_seq=65 ttl=53 time=143 ms
64 bytes from 8.8.8.8: icmp_seq=66 ttl=53 time=152 ms
64 bytes from 8.8.8.8: icmp_seq=67 ttl=53 time=157 ms
64 bytes from 8.8.8.8: icmp_seq=68 ttl=53 time=153 ms
64 bytes from 8.8.8.8: icmp_seq=69 ttl=53 time=159 ms
64 bytes from 8.8.8.8: icmp_seq=70 ttl=53 time=155 ms


c) Simular perdida % de paquetes:


 # tc qdisc change dev eth0 root netem loss 0.1%

El comando anterior ocasiona una pérdida de 1/1000 paquetes descartados de manera aleatoria

Más opciones:
Existen muchas otras opciones como:
  a) Duplicar paquetes
     # tc qdisc change dev eth0 root netem duplicate 9%


  b) Corromper (dañar) un paquete:
     # tc qdisc change dev eth0 root netem corrupt 0.1%

Mas información:
http://www.linuxfoundation.org/collaborate/workgroups/networking/netem
http://www.cyberciti.biz/faq/linux-traffic-shaping-using-tc-to-control-http-traffic/

Twitters sobre IPv6 en español

Introducción:
   Deseo seguir información de Tweets en español sobre IPv6.

A quienes seguir:
@lactf  (Latin American & Caribbean Task Force sobre IPv6)
@MendozaIPv6Day 
@ipv6cl 
@SI6NetworksES (sobre IPv6 pero con mayor tendencia a Seguridad y hacking)

  Indiscutiblemente hay muchos más sin embargo los anteriores son exclusivamente de IPv6 y en español. Muchas veces existe información en otros idiomas (ejemplo retweets) pero la mayoría son idioma español.

Mas info
http://www.twitter.com
Lista de correo LACTF: http://acostanetwork.blogspot.com/2011/06/lista-de-correo-de-ipv6-lac-tf-de.html
@lactf tambien tiene un grupo en  linkedin: http://t.co/IGBx8iB