Es un pequeño Intel e2160 de 1gb de Ram, mas que suficiente para este portal y otras webs.

Vamos a comunicar a todas las empresas de hosting ya que nos sentimos orgullosos de que nos ofrezcan servicio de hosting por mail.

Los post que vieron que mencionaban los problemas que teniamos con los hosting free. Por eso nos ofrecian hospedaje web. Gracias

Aqui encontramos nuestro hogar, en este flamante servidor situado en Lincoln, Buenos Aires, Argentina. Gracias a su sysadmin nivel novel Fabián Bonetti que con lo que aprendio en el team supremos pudo hacer la asaña de montar este servidor.

Aqui estaremos en zeuza

Es software libre, y esta a la disposición publica.

Listado de servidores de statusnet en el mundo

http://legadolibre.com.ar/

esta es la dirección del cortador —»http://cut07.tk/ podemos poner el “Navegador Bookmarklets” arrastrando hacia nuestro panel de firefox y cuando tengamos una larga la cortamos pinchando en el icono del cortador

pueden usarlo con su twitter o similares.
o cuando buscamos algo con google y por ser ansiosos copiamos la url y pegamos en msn o irc y al final google nos dio un choclo enorme que ocupa toda la pantalla que nuestros amigos se quejan de eso.
espero que les guste. es para usarlo y difundirlo.

via bazzar

 bzr branch http://mamalibre.2.je/bzr/pastebin

ejemplo de como quedaría http://pastebin.2.je/

Que emocionante recordar este video.

El Gateway era un Linux/Redhat 8.0, y aunque al final casi se me suicidadara porque el paquete iproute2 venia con
bugs, pudimos solucionarlo.
El balanceo que elegimos, no es nada más que un reparto equitativo del
tráfico de salida a las puertas de enlace (en
nuestro caso 20), por lo que desde la versión 2.4.15 del kernel de
Linux, llevan incorporado la opción “equal cost multi
path” (Advanced Router−Networking Options), que deberemos activar, junto
un parche de Julian Anastov (2)al igual
que ip_conntrack de Netfilter(3) por si luego queremos hacer movidas con
IPTABLES (SNAT,DNAT,etc), Policy
Routing por si queremos hacer tablas para decidir qué paquetes deben ir
por un sitio u otro, rutas estáticas vamos, (las
tablas no las hemos usamos para nada) y activar el forwarding.
Hecho esto, compilamos el kernel, y bajamos el paquete de iproute2
(ojo!, el paquete de iproute2 de la redhat8 no
funciona bien y muestra el mensaje “dead link pervasive” (conexion
muerta penetrante), por lo cual no va bien a la hora
de tomar decisiones.
Entonces nos bajamos el paquete más reciente( en la fecha que lo hicimos
nosotros tuvimos que bajarnos el tarball
porque en .rpm no habia otro ).
Bien, ¿como funciona esto? Aquí esta el quid.
Se supone que hay otros métodos para hacerlo, pero según he leido, al
recibir las tramas en el camino de retorno se
harían por una sola IP o ruta, con lo cual sería algo lenta la
transferencia, también he leido cosas acerca de hacerlo con
DNAT, pero me parece a mi que todo eso que he visto planteado no hace
reparto equitativo entre las diferentes lineas
externas, sino que directamente asigna rutas estáticas, esta “solución”
que se planteó es hacer rutas dinámicas, y os
expongo una pequeña explicación de como funcionan las cosas:

• Si la máquina 10.0.0.2 quiere llegar a Internet, ha de formar un
paquete primero, lo que hace cualquier
programa es utilizar bind(), éste consulta al sistema de rutas del
sistema operativo acerca de que “ip de origen
debe coger”, −−| p.ej. si yo hago ping a 127.0.0.1, la ip de origen la
tomará como 127.0.0.1, pero si hago ping
a 192.168.1.6, me tomará como ip de orígen 192.168.1.254, ha quedado
claro creo…

• Entonces, cuando llega a 10.0.0.1 (Gateway con Linux) nuestro sistema
de rutas dinámico decide qué camino
ha de coger mediante un algoritmo bastante raro me parece a mi.. por lo
que pude leer del kernel, él va
asignando conexiones a las distintas pasarelas, una por una (pim pam), y
si por lo que fuera por una pasarela
se mueren conexiones, el propio sistema se encarga de asignar nuevas
conexiones por esa pasarela (supongo
que para que haya igual número de conexiones en todas las rutas).
Lo que no logré comprender (quizás porque no me dio tiempo a leer más)
es que realmente el kernel asignaba
conexiones segun ip de origen e ip de destino, es decir, desde 10.0.0.2
podia hacer 10 conexiones (cada una a
diferente ip) y el kernel me encaminaba a la misma pasarela ADSL, pero
vamos… será la parte que no me leí
X−D.

• Siguiendo el hilo… se acciona el mecanismo de forwarding (si lo
tenemos activado, claro) y hace que el
paquete vaya al router adsl que corresponda. El router hace NAT hacia el
router de la intranet del ISP y luego
a Internet…

• Para el retorno de los paquetes no hay ningún problema porque cuando
lo hace, el kernel reconoce este
paquete y sabe retornar por dónde le toca (olé con el forwarding).
Creo que hasta aquí ya he dado mucho el coñazo con la parte teórica.
Continuamos con la parte Práctica
Empezaré con la parte del bonding.
Configurar un sistema con bonding es tan sencillo como activar el modulo
‘bonding.o’ o bien activarlo desde el kernel
(está dentro de Networking Options).
Luego, levantar las tarjetas mediante un programa en c que está dentro
de Documentation/networking del kernel que
deberemos compilar…

# cd /usr/src/Linux/Documentation/networking
# gcc ifenslave.c −o ifenslave (compilamos)
# cp ifenslave /sbin

Para hacer bonding no tendremos más que hacer:

# modprobe bonding max_bonds=2 (El máximo que se puede hasta la fecha
según leí)
# /sbin/ifenslave bond0 eth0 eth1 (Lo que nosotros tocaremos a partir de
ahora es bond0)

Ahora el balanceo:

Para el balanceo debemos aprender a llevarnos bien ‘ip’, y si os salta
algún kernel panic, no os preocupéis, es que Linux
2.4 aun no va muy fino con ip.

Primero debemos arrancar sin ninguna configuración de ifconfig, así que
si tenéis alguna, quitadla. Lo malo es que si
ya teneis el pc arrancado no se borrará de la tabla tan facilmente (es
decir, haciendo ifconfig ethx down).

# ip addr (vemos que las ips siguen ahí)

Aquí os pego un pequeño script que no es de mi invención, para borrar
las que haya:

# d=`ip −o link show | cut −d: −f2`
for i in $d ; do
ip addr flush $i
ip link set $i down
done
unset i d

Una vez hecho esto, al hacer “ip addr” no nos debería dar ninguna ip por
interfaz, así que empezaremos dando de alta
las interfaces y las ip’s.

# ip addr add 127.0.0.1/8 dev lo (interface loopback)
# ip link set lo up
# ip route add 127.0.0.0/8 dev lo

Ahora configuramos las dos interfaces que irán para los usuarios que
vengan de 10.x.x.x

# modprobe bonding max_bonds=2 (cargamos el modulo)
# ip link set bond0 up (damos de alta el bond0 como interfaz)
# ip addr add 10.0.0.1/8 dev bond0 (le asignamos una ip)
# ip route add 10.0.0.0/8 dev bond0 (le asignamos una ruta estática para
10.0.0.0)
# /sbin/ifenslave bond0 eth0 eth1 (levantamos el bonding)

Acto seguido el bond1, que son la conjunción de las dos tarjetas que van
a los routers ADSL.

# ip link set bond1 up
# ip addr add 192.168.1.254/24 dev bond1
# ip route add 192.168.1.0/24 dev bond1
# /sbin/ifenslave bond1 eth2 eth3

Las rutas mágicas…

# ip route add default proto static\
nexthop via 192.168.1.1 dev bond1\
nexthop via 192.168.1.2 dev bond1\
nexthop via 192.168.1.3 dev bond1\
... (hasta 20)

Y el forwarding… (porque si no, todo lo que hemos hecho no sirve para
nada)

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

Y el forzado de las tarjetas de red.

Ayuda de ‘mii−tool’

usage: mii−tool [−VvRrwl] [−A media,... | −F media] [interface ...]
−V, −−version
display version information
−v, −−verbose
more verbose output
−R, −−reset
reset MII to poweron state
−r, −−restart
restart autonegotiation
−w, −−watch
monitor for link status changes
−l, −−log
with −w, write events to syslog
−A, −−advertise=media,…
advertise only specified media
−F, −−force=media
force specified media technology
media: 100baseT4, 100baseTx−FD, 100baseTx−HD, 10baseT−FD, 10baseT−HD,
(to advertise both HD and FD) 100baseTx, 10baseT

Creo que está bien claro: Al hacer ‘mii−tool’ a secas, te dice que
‘media’ está funcionando, y a qué estado ha
negociado (o no). En el caso de los Catalysts, habría que forzar las
tarjetas a lo que uno desee.
En nuestro caso los servers tuvieron que forzarse a 100baset, full duplex:

# mii−tool −F 100baseTx−FD eth0 (por ejemplo).

Y creo que eso es todo lo que tenia que contaros; lo demás son problemas
no relacionados con los Linux, y que tienen
importancia, pero lo he visto publicado en Bulma con anterioridad, así
que no le doy mucha importancia.

Notas

• Para saber esto, nos leimos el Nano−HOWTO, que explica pasito a pasito
como hacerlo, lo que pasa es que el
gacho del howto se enreda un monton y opino que, no explica muy
claramente todos los conceptos y al final
puedes hacerte una empanada mental, por ejemplo, con las tablas (en
nuestro caso no necesitabamos tablas
para nada).

• Cuidado con el bonding. Para hacer bonding, al otro lado ha de haber
bonding también (o en nuestro caso
etherchannel con los cisco catalyst), tened cuidado con el tipo de
etherchannel que hagáis porque según me
han comentado hay varios tipos de etherchannel, y no todos son
compatibles con bonding.

• La opción “proto static” del balanceo es muy importante, si alguna
ruta deja de funcionar, automáticamente es
descartada por el kernel, y a los 60 segundos (por defecto) vuelve a
intentar con la tabla de rutas que tiene, este
intervalo lo podeis tocar a través de /proc/sys/net/ipv4/route/gc_interval.

• Yo lo tengo claro, pero por si alguien no tiene muchos conocimientos
de networking quiero que se entienda: el
balanceo no puede nunca coger las 20 ADLSL’s para una conexión, es
decir, no podemos coger una trama,
dividirla en 20 y enviar cada una por cada ADSL, porque sino habria
fragmentos que no tendrían cabecera, y
en el supuesto caso de que las tuvieran, el destino no sabria como
reensamblarlas al retornar desde ip’s
diferentes (habría que hacer movidas no contempladas, como crear un
nuevo protocolo en una capa superior a
IP y decirle que cuando los paquetes retornen se reensamblen por
diferentes ip’s, y eso creo que no está
contemplado.)

• Para cercioraros de que el balanceo vaya bien, haced un ‘ip route ls
cache’ y si tenéis algún problema con
alguna ruta antigua ‘ip route flush cache’ y os borrará completamente
las rutas que esté tomando en ese
momento.

• Las conexiones SSH con clientes Linux no funcionaban, en cambio con
windows sí, supongo que el sistema
de funcionamiento con las ips seria diferente, pero no me lo miré mucho.

Por maestrolinux vía mail.

Download

Pagina oficial de la revista

Que medios es tu preferido para comunicarte?

Fecha de inicio: 3 Febrero, 2012 @ 23:53
Fecha de fin: 3 Febrero, 2014 @ 23:53

¿nos suspenderan en este hosting free?

Fecha de inicio: 28 Septiembre, 2010 @ 18:53
Fecha de fin: 28 Septiembre, 2013 @ 18:53

¿Que entorno te gusta mas?

Fecha de inicio: 28 Septiembre, 2010 @ 18:52
Fecha de fin: 28 Septiembre, 2013 @ 18:52

Qué tal está mi página?

Fecha de inicio: 13 Agosto, 2010 @ 2:43
Fecha de fin: 13 Septiembre, 2013 @ 2:47

Autores: jebus, totoloco, maestrolinux y mama21mama
Solo apto para mayores de 18 años

Musica: Delcraft (Pablo Valdés)
www.delcraftmusic.com