Mientras no exista 802.1x en el iPod Touch no se puede conectar a UPVNET2G, pero actualmente si instalas mail en el iPod se instala también una opción en preferencias > general > red para crear una vpn, con lo que podemos conectar a UPVNET.

Los datos de configuración para conectarse a internet en la UPV a través de una VPN en la WiFi libre de UPVNET deben de ser los siguientes:

• Tipo de VPN: PPTP
• Servidor: 158.42.255.4
• Cuenta: dominio\usuario
• RSA SecurID: apagado
• Contraseña: la contraseña de usuario de la upv.
• Nivel de encriptación: automático
• Enviar todo el tráfico: activado

El dominio será uno de los de la upv, normalemente alumno. Una vez puesto, activamos la vpn y ya podremos salir a internet a través de la UPV.

Es importante poner la ip de vpn.upv.es en lugar del nombre ya que por alguna razón que desconozco el iPod no consigue resolver el nombre por la ip, por lo que hay que darselo ‘masticado’.

Supongo que esta configuración es tan válida para el iPhone como para el iPod Touch pero al falta de tener un iPhone a mano espero que alguien me lo confirme.

En las últimas horas me he percatado que en las páginas de este mismo blog en donde se muestran comentarios ponía, en lugar de estos, un mensaje de error que citaba:

WordPress database error: [Table './AAA/wp_comments' is marked as crashed and last (automatic?) repair failed]
SELECT * FROM wp_comments WHERE comment_post_ID = ‘XXX’ AND comment_approved = ‘1′ ORDER BY comment_date

En donde AAA es el nombre de la tabla que contiene la tabla corrupta y XXX es el id del post que en ese momento se está viendo.

Tras buscar en google “how to repair crashed table” encontré este enlace del faq de mysql en donde de forma extensa explican como se puede tratar de recuperar una tabla según su error.

Para comprobar el tipo de error que hay en la tabla, hay que ejecutar myisamchk de la siguiente forma (haste este punto no es necesario parar el demonio mysqld):

root@host:~# cd [path]
root@host:/[path]# myisamchk wp_comments.MYI

En donde [path] es la ruta de nuestras tablas (normalmente /var/lib/mysql/databasename). Esta ha sido la salida del programa myisamchk:

Checking MyISAM file: /[path]/wp_comments.MYI
Data records: 150 Deleted blocks: 0
myisamchk: warning: Table is marked as crashed and last repair failed
myisamchk: warning: 1 client is using or hasn’t closed the table properly
- check file-size
- check record delete-chain
- check key delete-chain
- check index reference
- check data record references index: 1
- check data record references index: 2
- check data record references index: 3
myisamchk: error: Found 151 keys of 150
- check record links
myisamchk: error: Record-count is not ok; is 151 Should be: 150
myisamchk: warning: Found 151 parts Should be: 150 parts
MyISAM-table ‘/chroot/mysql/var/lib/mysql/myblog/wp_comments.MYI’ is corrupted
Fix it using switch “-r” or “-o”

Al parecer (no acabo de comprender de que manera) habia una entrada mas en la tabla de las que el contator tiene marcadas (hay 151, el contador marca 150). Para arreglarlo ha sido tan sencillo como parar el demonio mysqld (importante !!) y:

root@host:/[path]# myisamchk -r -q wp_comments.MYI

La opcion -r significa repair y la opción -q quick, por lo que myisamchk tratará de hacer un recovery rápido de la tabla. En mi caso ha sido suficiente con esto y ya ha vuelto a funcionar la tabla adecuadamente:

root@host:/[path]# myisamchk wp_comments.MYI
Checking MyISAM file: wp_comments.MYI
Data records: 151 Deleted blocks: 0
- check file-size
- check record delete-chain
- check key delete-chain
- check index reference
- check data record references index: 1
- check data record references index: 2
- check data record references index: 3
- check record links

En cambio, si las opciones -r -q no hubiesen sido suficientes, habría que ejecutar myisamchk solo con la opción -r.

Para los despistados, una vez recuperada(s) la(s) tablas(s) corrupta(s) se vuelve a poner en marcha el demonio mysqld y a correr.

Ahora mismo ya funcionan los comentarios y podeis dejar uno mas abajo :D

La mayoría de las personas que leeis este blog sabeis que está montado en un homemade server en mi casa y que debido a mi escaso upload, apache está limitado a una subida de 20Kb/s para archivos menores de 1Mb y a 10Kb/s para el resto, pero estos últimos días el blog ha ido muy lento.

En principio la lentitud era debida a la publicacion en la portada de meneame de la noticia de la estafa de educasite.es, pero luego de dejar de recibir visitantes procedentes de meneame el blog seguia igual de lento.

Esto fué debido a que estube ‘jugando’ con la configuración del módulo bandwidth de apache cuando vi que el server web se saturaba debido a las visitas tratando de buscar un buen equilibrio de ancho de banda.

Al cambiar la configuración en diferentes anchos de banda no me di cuenta que se iban quedando restos en unas capertas temporales que el módulo bandwidth utiliza (localizadas en /var/lib/apache/bandwidth en debian y en /tmp/apachebw/mod-bandwidth/ (link y master)) y que estos restos influian, por lo que por mas que cambiase la configuracion de ancho de banda no conseguia que este funcionase bien.

Arreglarlo ha sido tan fácil como vaciar los dos directorios /var/lib/apache/bandwidth/link y /var/lib/apache/bandwidth/master para evitar colisiones de viejas configuraciones con la actual, por lo que si alguno usa mod_bandwidth de apache y quiere cambiar la configuración del mismo, lo ideal es que vacieis estas dos carpetas o de lo contrario no funcionará bien la nueva configuración.

Update: Cabe destacar que normalmente este blog recibe en el orden de 20 a 50 visitas por día, para lo cual mi ancho es mas que suficiente. En esta imagen de Google Analytics se puede ver la basta diferencia:

Debido a un uso excesivo de la banda de subida a internet en la red de mi casa, me vi obligado a denegar cualquier p2p que procediese del ordenador de mi hermana.

Encontré un módulo para iptables de tipo MATCH que me identifica perfectamente los paquetes pertenecientes a cualquiera de los siguientes clientes p2p:

• KaZaA
• Gnutella
• eDonkey/eMule/Overnet
• BitTorrent
• Direct Connect
• AppleJuice
• WinMX
• SoulSeek
• Ares

La fuente del módulo la podemos encontrar en su pagina oficial. Lo descargamos, descomprimimos y compilamos (hay que tener la fuente de la version de iptables que estemos utilizando):

# tar xvfz ipp2p-.tar.gz
# make
# cp ipt_ipp2p.ko /lib/modules/$(uname -r)/
# cp libipt_ipp2p.so /lib/iptables
# depmod -ae
# modprobe ipt_ipp2p

Si todo nos ha ido bien, ahora tendremos el módulo correctamente instalado en nuestro sistema. A continuación solamente tenemos que poner la regla que mas nos convenga segun nuestra situación.

En mi caso solamente necesitaba denegar a un solo ordenador, así que combiné ipp2p con coincidencia de dirección física MAC, quedando así:

iptables -A FORWARD -m mac –mac-source XX:XX:XX:XX:XX:XX -m ipp2p –ipp2p -j DROP

La opción –ipp2p para el módulo ipp2p significa cualquier p2p que el módulo sea capaz de detectar. Si solamente quisiesemos detectar una de las p2p disponibles utilizariamos las opciones combinadas segun necesitemos. Para mas ayuda:

# iptables -m ipp2p –help

Este monstruo tan popular resulta ser la mascota de un canal de televisión por cable de Japón, cuya característica mas notable resulta ser que cuando se enfada se tira pedos sin parar.

Se hizo muy famoso debido a una imagen que rezaba: Every time you marturbate, God kills a Kitten. A continuación pongo una variante que me gusta mas x)