En esta oportunidad les cuento cómo, desde Linux/OSX, reventar un disco rígido para dejarlo "0km".

# dd if=/dev/zero of=/dev/sda bs=1M count=2

Con esto lo que hacemos es llenar de ceros los primeros 2MB del disco rígido, donde se encuentra el MBR y la tabla de parción (o parte de ella). Con esto dejamos el disco preparado para ser particionado sin dejar basura en él.

pd: esto no deja el disco vacío, de hecho sus datos pueden ser recuperados!

Tengo un GPON Huawai HG850a y Telmex de 5Mb.

Estimados, necesito hacerles una consulta técnica. Intenté evacuarla por teléfono pero nunca me pudieron dar una solución.

La prueba consiste en bajar del mismo servidor una imagen de CD de Ubuntu o ver un mismo video HD en Youtube.

Cuando conecto:
* una PC con determinadas placas de red (Realtek, Nvidia);
* notebooks;
* playstation;

directamente al módem de ustedes la conexión anda de mil maravillas:
Descarga de 400KB/s a 600KB/s aprox (ya sea que use Windows o Mac OS X).

El problema viene cuando conecto routers (tengo uno Linksys, TPLink, NetGear y una PC Linux que tengo desde siempre).
En ese caso por más que haya una única PC conectada al router, no logro bajar a más de 90KB/s.

Por otro lado usando una PC con Windows XP y su Internet Connection Sharing como router se navega perfectamente teniendo 2 o 3 PCs descargando simultaneamente.

Quisiera saber si el módem que ustedes me proveen detecta de alguna manera que conecté un router y en base a eso activa algún sistema de QoS, porque si no no encuentro razón alguna para que suceda esto.

En los routers que tengo he desactivado siempre el QoS, verificado que el MTU esté bien, que las reglas de NAT y routing sean las correctas pero no logré mejorar esta situación. También, sospechando que el módem pueda detectar mis routers probé cambiando la Mac Address por alguna de Realtek, Intel o Nvidia... pero tampoco funcionó.

Realmente me gustaría que me den una respuesta concreta, ya que telefónicamente me dicen que es un problema del router, que lo reinicie y cosas de ese estilo. Llevando mi mismo router y con la misma configuración a la casa de un vecino que tiene el mismo servicio todo funciona correctamente. Esto lo he comentado telefónicamente e insisten en que el problema es mío y no del servicio o configuración del módem de fibra óptica.

Espero poder resolver este problema, porque la realidad es que si bien la latencia de la fibra óptica es genial para jugar en internet, estoy pagando 170 pesos para navegar a 100KB/s y me parece un despropósito.

Muchas gracias.

Luego mandé este segundo, mucho más jugoso!

Estimados, me vuelvo a contactar para ampliar la consulta en base a
unas pruebas que he realizado.

Hoy cuando charlé con la persona de soporte técnico me encontraba en
mi lugar de trabajo. Al llegar a mi domicilio realicé las siguientes
pruebas:

Prueba 1

1. Conecté un switch (no un router, un simple switch) directo al módem
de fibra que ustedes me asignaron.
2. A este switch conecté por cable dos PCs, una Laptop y una playstation.

* Al verificar los equipos, todos habían adquirido IPs públicas del
tipo 186.182.122.x;
* Cada uno de ellos navegaba a un máximo de 90KB/s;

Prueba 2

1. Conecté un switch directo al módem de fibra de ustedes.
2. A este switch conecté una única PC.

* dicha PC tomó una IP pública y navegaba a un máximo de 90KB/s

Prueba 3

1. Conecté una PC con Windows XP e Internet Connection Sharing como
router directo al módem.
2. Conecté un Router (con la misma configuración que lleva cuando lo
conecto directo al módem de ustedes) a esa PC con Windows XP.
3. Conecté mis otras PCs al router.

* Todas las PCs conectadas el router navegaban de mil maravillas,
entre 150KB/s a 600KB/s

Con estos resultados se da por entendido que:

* el módem que ustedes me dieron efectivamente detecta cuando hay un
switch conectado a él y reparte el ancho de banda de forma fija aunque
haya un único equipo conectado;

* el módem detecta cuando se conecta una PC y entonces le asigna todo
el ancho de banda (asignado por el plan que tengo) a ese único equipo;

* el módem interpreta que se le conectó un switch cuando en realidad
se le conecta un router, entonces todas las PCs conectadas a dicho
router quedan limitadas a 90KB/s que es lo que el módem le da al
router.

Una duda que me surge es que cómo yo contratando un servicio
residencial puedo gozar de tantas IPs públicas.

A esta altura, y con todas las pruebas que realicé no caben dudas algo
en la configuración del módem está mal, y no me refiero a los valores
del GPON, si no a su configuración operativa.

Por las dudas adjunto la Mac Address del módem: 28 6e d4 xx xx xx
(esto lo hago, porque hace un tiempo tuve una serie de problemas con
la conexión y me decían que estaba todo bien cuando el módem
directamente no sincronizaba y resultó ser que tenían otra mac address
en su sistema)

Bueno, quedo a la espera de una respuesta.

Muchas gracias.

Por lo pronto, navego a 1Mb :/

Primero que nada, amo las colas... las amo por el doble sentido que generan en nuestro idioma, seguramente tendré miles de hits con intenciones de dudooosa moralidad

¿Qué es una cola?

Una cola es una estructura de datos, es un elemento en el que podemos poner datos por un lado y sacarlos por el otro

¿Para qué sirve una cola?

Según lo recién expuesto, para ponerla y sacarla Esto aplicado a la informática serviría para que un programa, encargado de cierta tarea, pueda poner su resultado en la cola; luego, otro programa encargado de procesar esos resultados los tome y haga algo.

Pasando a la parte seria del asunto voy a contarles de mi experiencia con RabbitMQ. Jaja, no puedo evitar reirme: colas, meter, sacar, rabbit (conejito), saquen sus conclusiones -aunque claro que PlayBoy no es algo del ambiente nerd-

Entendamos la infraestructura y aclaremos los tantos: RabbitMQ implementa el protocolo AMQP, cosa que no conozco en detalle -saliendo de que es un sistema de colas abierto- ni me interesa por el momento. Así hablaré basándome en RabbitMQ (siendo que la mayoría va a ser aplicable a colas basadas en AMQP).

Teoría de colas x $2.-

Vayamos por partes, en todo sistemas basados en colas tenemos tres elementos principales:

1. Un emisor: Es el que origina un dato y lo pone en la cola.
2. La cola: Es el lugar donde ese dato reside.
3. Un receptor: Es el que toma un dato y hace algo con él.

Nos vamos a enfocar en el punto dos: La cola.

La cola en realidad comprende un concepto algo más complejo que un simple lugar donde se tiran cosas y de dónde se las sacan. En ella encontraremos:

1. El message: Será el portador de nuestra información.
2. El exchange: Será el recepcionista de nuestro mensaje y deberá saber qué hace con él.
3. La routing key: Será una simple palabra o texto que nuestro exchange deberá conocer.
4. La queue: Será la cola en donde realmente residirá nuestro message.
5. El binding: Será el encargado de decirle al exchange en qué queue guardará el message dado según su routing key.

El message es un objeto que contiene la información concreta que le damos nosotros y una serie de propiedades, en la que destacamos el delivery_mode, que acepta dos valores 1: mensaje temporal, 2: mensaje persistente.

Las colas son demasiado flexibles para los que estamos acostumbrados a las cosas viejas de la informática, por ejemplo: Se declaran en tiempo de ejecución; se borran cuando el último cliente se desconecta y éstas están vacías; por parte del servidor no hace falta configurar un corno; etc; etc.

El exchange es un broker, es con quién charla directamente el programa que se conecta a la cola para meter un message. Él sabe, o debería saber, qué hacer con el mensaje que le damos -es decir, en qué cola guardarlo- y cómo distribuirlo: direct: es un método de trabajo donde una routing key define una única cola de destino, fanout: es un método en el que no importa nada, todo lo que llega va a todas las colas definidas, entre otros modos que hay y que no voy a tratar.

La routing key es un simple texto idenfiticativo, pero que no trataré en mayor detalle.

La queue es la amada cola, que puede ser o no persistente: es decír que puede existir mientras se use y luego desaparecer o bien durar en el tiempo, soportando que el servidor sea reiniciado.

El binding es la acción de crear la siguiente regla: exchange-routing key va a la cola queue.

Hasta aquí, no van a entender un carajo... y mi idea no es ayudarlos, sino quedar como un duque en el tema y ganar minitas

Ahora vamos a las acciones básicas que tenemos en la cola:

1. publish: Se le da el message deseado, el exchange a usar y la routing key.
2. get: Se le da el nombre de la cola, para obtener un mensaje.
3. consume: Se le da el nombre de la cola y queda a la escucha de mensajes.
4. tx_select: Se usa para activar transacciones.
5. tx_commit: Se usa para confirmar la transacción y automáticamente inicia otra.
6. tx_rollback: Se usa para abortar la transacción y automáticamente inicia otra.

En fin, acá hay conceptos básicos y otros complejos... realmente esto lo pensé para mí mismo pero les prometo que en breve publicaré unos ejemplos en Python para que puedan aprender un poco más de cómo implementar esta teoría.

Hasta la próxima

Según un referente en la materia (?), Ángel Freire, y con quién coincido: Es mejor controlar qué servicios se brindan y dónde escuchan, que desconocerlos y a causa de eso cargar reglas mediante iptables a nuestro querido net filter.

Pero algo se escapa, qué pasa con los ataques por fuerza bruta a servicios vitales como SSH? Bien, a continuación mi solución.

Una vez que decidimos qué servicios brindaremos, tenemos que ver que escuchen donde realmente lo queremos.

~ # netstat -an | grep LISTEN
tcp        0      0 0.0.0.0:8000            0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:1978          0.0.0.0:*               LISTEN

Aquí vemos varios servicios, cada uno de ellos escuchando en distintas interfaces y no por casualidad. Las bases de datos (3306, MySQL y 1978, TokyoTyrant) escuchando en loopback, localhost o como le quieran decir y por otro lado los servicios públicos (8000, 80, 25 y 22) escuchando tanto en loopback como el resto de las interfaces

Si tuviésemos todo a la bartola, necesitaríamos bloquear, por ejemplo, el acceso a MySQL y Tokyo con unas reglas de iptables. No es más lindo así?

Bien, es más lindo así ahora, qué pasa con el puerto 22 de SSH? Necesitamos que escuche en las interfaces externas, si no no tendría sentido que exista, pero al hacerlo está suceptible a los inescrupulosos intentos de cientos y miles de idiotas por hacerse del control de nuestros servidores.

Un buen día me harté de ver miles y miles de ráfagas de intentos de autenticación a mi SSH, gestionados por scripts, con usuarios básicos o clásicos de sistemas Unix.

¿La solución? Usar net filter (mediante reglas de iptables) cuando se lo necesita:

#!/bin/bash
# Borramos todas las reglas existentes
iptables -F

# Permitimos la comunicación desde nuestra casa
iptables -A INPUT  -i eth0 -s DNS_DE_MI_CASA -d IP_DE_MI_SERVIDOR -p tcp --dport 22 -j ACCEPT
iptables -A OUTPUT -o eth0 -s IP_DE_MI_SERVIDOR -d DNS_DE_MI_CASA -p tcp --sport 22 -j ACCEPT

# Permitimos la comunidación desde nuestro trabajo
iptables -A INPUT  -i eth0 -s DNS_DE_MI_TRABAJO -d IP_DE_MI_SERVIDOR -p tcp --dport 22 -j ACCEPT
iptables -A OUTPUT -o eth0 -s IP_DE_MI_SERVIDOR -d DNS_DE_MI_TRABAJO -p tcp --sport 22 -j ACCEPT

# Denegamos el resto de accesos
iptables -A INPUT  -i eth0 -s 0/0 -d IP_DE_MI_SERVIDOR -p tcp --dport 22 -j DROP

Con un script como ese, sólo permitimos que al puerto 22 lleguen peticiones de nuestros dominios dinámicos Lo cual es muy cómodo, aunque en el caso de tener IPs dinámica, tendrán que ejecutar este script, sea mediante cron u otro método, para que las mismas sean actualizadas con las reglas de iptables.

En fin, hasta la próxima!

$ gvim ~/.bashrc

y luego agreamos algo como

alias lsa='ls -lha''

lsa va a ser el nombre del comando al que llamaremos desde la terminal. Lo seguido del igual, y entrecomillado, es lo que se va a ejecutar

Para evitarnos dolores de cabeza hacemos lo siguiente:

1. nos situamos en el raíz de nuestro proyeco y creamos un archivo llamado .svnignore con un contenido similar a éste:

.pyc
.pyo
.tmp
.swp

y luego ejecutamos el siguiente comando:

svn ps svn:ignore . -F .svnignore -R

Con esto logramos que se aplique recursivamente la exclusión del monitoreo en todo nuestro proyecto

python -m SimpleHTTPServer

para tener un servidor compartiendo los ficheros por http

Es obvio que tanto un intermedio como un neófito de GNU/Linux puede compilar desde las fuentes aunque seguramente utilice algún gestor de paquetes, pero no que la media de novatos logre hacer andar (configurar correctamente) los programas que instale. Por eso voy a ir paso a paso por el camino de instalar y configurar la fórmula antes mencionada.

Primero vamos a instalar los servicios (web y de base de datos, respectivamente):

$ sudo aptitude install lighttpd
$ sudo aptitude install mysql-server

Terminada la instalación de MySQL, se nos solicitará que ingresemos una clave para el usuario root mediante una caja de diálogo de ncurses

Ahora vamos por el intérprete de PHP:

$ sudo aptitude install php5-cgi

En este momento, si nada grave ocurrió, tenemos andando a lighttpd y MySQL en nuestra PC. Pero hay que meter mano en unos archivos para que PHP funcione con ellos

Abrimos el archivo de configuración de PHP ...

$ sudo gedit /etc/php5/cgi/php.ini

... y descomentamos la línea que dice "cgi.fix_pathinfo=0" y cambiamos ese 0 por un 1. quedando

cgi.fix_pathinfo=1

y guardamos.

Ahora tenemos que activar en lighttpd su módulo de FastCGI y configurar el intérprete de PHP, para lo cual...

$ sudo gedit /etc/lighttpd/lighttpd.conf

y buscamos la línea que diga "server.modules", ahí agregamos "mod_fastcgi", quedando algo como:

server.modules              = (
            "mod_access",
            "mod_alias",
            "mod_accesslog",
            "mod_compress",
            "mod_fastcgi",
#           "mod_rewrite",
#           "mod_redirect",
#           "mod_status",
#           "mod_evhost",
#           "mod_usertrack",
#           "mod_rrdtool",
#           "mod_webdav",
#           "mod_expire",
#           "mod_flv_streaming",
#           "mod_evasive"
 )

Antes de cerrar el archivo, vamos a la opción "server.document-root" y cambiamos el /var/www/ por

server.document-root       = "/home/TU_NOMBRE_DE_USUARIO/webs/"

así podemos trabajar tranquilamente en nuestro propio home sin lidiar con permisos de root a la hora de crear o modificar los archivos que vamos a hospedar Y ahora sí, guarden los cambios y listo.

Ahora nos queda la siguiente linea de comandos

$ sudo cp /etc/lighttpd/conf-available/10-fastcgi.conf /etc/lighttpd/conf-enabled/

con la que copiaremos la configuración por defecto que trae lighttpd para operar con PHP. Si somos experimentados en el tema, podemos "enchular" (jaja) esas opciones... pero por ahora no es necesario

Seguro te lo estabas preguntando... y es ahora! vamos a reiniciar lighttpd para que tome los cambios:

$ sudo /etc/init.d/lighttpd restart

Sí señores, ya está "todo" andando Para probarlo créen un "prueba.php" cuyo contenido sea como el siguiente y a navegar se ha dicho!

<?
phpinfo();
?>

Aclaración: dije que "ya está "todo" andando" porque legalmente está todo regio, pero seguramente nos hará falta el soporte de las GD y MySQL para PHP, como quizás otras librerías. Por eso debemos hace un...

$ sudo aptitude install php5-gd php5-mysql

... y volver a reiniciar lighttpd

$ sudo /etc/init.d/lighttpd restart

para que los cambios sean efectuados.

Para consultar el resto de librerías disponibles, y que quizás debamos instalar según nuestras necesidades, basta con

$ sudo aptitude search php5

Descargo: Al momento de escribir este artículo en los repositorios del Ubuntu Gutsy Gibbon se encuentran los siguientes paquetes: lighttpd 1.4.18-1ubuntu1; php5-cgi 5.2.3-1ubuntu6.2; mysql-server 5.0.45-1ubuntu3.1.

Ahora sí, hasta la próxima!

Me encantó lo bien que emula al aparato de Sony, pero a los minutos me irritó tener que poner y sacar los CDs de mi lectora por lo que empecé a buscarle la vuelta como para poder ejecutar grandiosos títulos como "Collin McRae Rally 2" o "Legend" desde el disco rígido de la PC.

Así que vayamos al grano:

$ sudo cdrdao scanbus

Con eso obtenemos la dirección, en el sistema, de nuestras lectoras de CDs. Nos devolverá algo similar a "ATAPI:0,1,0 SONY , DVD RW DW-D26A , JYS3".

Ahora, con ese dato, procedemos a extrar el contenido del disco para generar el .bin y .toc

$ cdrdao read-cd --read-raw --device ATAPI:0,1,0 --datafile NOMBRE_DEL_JUEGO.bin NOMBRE_DEL_JUEGO.toc

A esta altura tenemos el .bin (con el contenido crudo del CD leido) y el .toc (la tabla de contenido del .bin). Para poder usar esta imagen con el pSX necesitamos un archivo .cue (cumple la misma función que el .toc pero utiliza otro formato).

$ toc2cue NOMBRE_DEL_JUEGO.toc NOMBRE_DEL_JUEGO.cue

Y voilá! Más linda que nunca!, tenemos una imagen idéntica a la del CD que podemos usar directamente, mediante el .cue, con el pSX o a modo de back-up para grabarla en un CD-R en caso de pérdida o rotura del original

Un saludo para todos!

Generalmente, y más que nada en PHP, uno utiliza tanto servidores locales (ubicados en país de uno, con la hora en dicha zona horaria) como servidores de Estados Unidos, Alemania o cualquier otra zona del mundo. En este segundo caso surgen los problemas porque cada servidor va a tener la hora que corresponde a su ubicación geográfica, sigamos el siguiente ejemplo:

Yo, nachopro, hago un trabajo para un cliente que tiene su sistema acá, en Argentina. Este cliente contrató un servidor de última generación que se ubica en Texas (Estados unidos). Resultando que la hora que mi cliente necesita es la GMT-3 mientras que la hora que tiene el servidor es GMT-8.

El problema es que al usar la función date() de PHP, siendo las 9:42 AM acá en Argentina, me va a devolver 4:42 AM. Una notable diferencia de 5 horas, nada menos

La solución consiste en generar la hora en base a la hora GMT-0 y sumarle nuestra diferencia respecto a ella. Es decir, nosotros estamos en GMT-3. Quiere decir que si la hora GMT es 12:46 y le sumamos nuestra zona horaria (-3) obtenemos 12:46 + (-3:00) = 9:46! En el caso de Texas realizamos 12:46 + (-8:00) = 4:46!

Esto es amazing y se resuelve con el siguiente código de PHP:

?php

function hora_local($zona_horaria = 0)
{
	if ($zona_horaria > -12.1 and $zona_horaria < 12.1)
	{
		$hora_local = time() + ($zona_horaria * 3600);
		return $hora_local;
	}
	return 'error';
}

echo gmdate('d-m-Y H:i:s', hora_local(-8));

?

Esta función recibe una zona horaria y nos devuelve los segundos de la hora actual más los segundos de dicha zona horaria. Se debe emplear como segundo parámetro de la función gmdate() para que genere correctamente la hora .

En caso de que se ingrese una zona horaria mayor a 12 o menor a -12 la función retorna un string para generar un error en la función gmdate(), la cual acepta sólo enteros como segundo parámetro, y así reconocer fácilmente un error de zona horaria.

Espero que les sirva. Hasta la próxima!