Bloquear (o redirigir) Spotify mediante iptables

Spotify

Spotify

Spotify es cojonudo. Si, una revolución. Pero un dolor de cabeza para todos los administradores de redes que ven como poco a poco, Spotify se va comiendo ancho de banda. Y además con su crecimiento nos vemos en la tesitura de que todos los usuarios ya van abandonando el mp3 para ir poco a poco pasándose al streaming, lo que nos hace que nuestros firewall tengan tráfico extra.

No soy el primero que se ha tenido que pelear con el, de hecho ya he visto alguna pregunta para bloquear Spotify en firewalls corporativos.

La solución que proponen la mayoría es bloquear el login del programa, que intentan a una subred en particular como puedes leer en el blog de Fernando Luis aunque con una pequeña mejora respecto a lo que leéis en su blog, traducido a iptables, el comando mágico es:

iptables -I FORWARD -d 78.31.8.0/21 -j DROP

Pero si lo que quieres es dejar a la gente que disfrute de este gran programa, y tienes varias lineas de ADSL y quieres que salga por una linea en concreto, puedes intentar marcar los paquetes mediante marcas, para luego redirigir el trafico marcado. Doy por sentado que tienes algún tipo de script dentro de tu servidor que pone las políticas del firewall en marcha, por lo que no me voy a parar en explicarte como hacer un script que monte todo el tinglado de un enrutamiento en un firewall (como por ejemplo como modificar el fichero /etc/iproute2/rt_tables, que cuento que lo tendrás modificado).
Eso si, os dejo las lineas que os redirigirán todo el tráfico de Spotify por otro ADSL, en este caso ADSL2.

ip rule add fwmark 1 table ADSL2    # ADSL con poco trafico
ip route add default via 192.168.221.1 dev eth1 table ADSL2
iptables -A PREROUTING -t mangle -i eth0 -d 78.31.8.0/21 -j MARK --set-mark 1          # Login Spotify
iptables -A PREROUTING -t mangle -i eth0 -d 195.55.74.0/24 -j MARK --set-mark 1         # Streaming Spotify
Please follow and like us:

Como resetear un campo «autoincrement» en SQLite

Muchas veces, tras trabajar en una base de datos y hacer pruebas, queremos borrar toda huella de que hemos «metido mano», y uno de los problemas que me he encontrado, ha sido que cuando tienes una tabla con una clave autoincrementada, aunque borres toda la tabla entera, esta al insertar una nueva fila continua con la secuencia en la clave autoincremental.

Es decir, si meto 3 registros en una tabla con un campo autoincremental, obtienen el valor 0, 1 y 2, respectivamente. Si borro estas tres y meto una cuarta tras el borrado, recibe el valor 3 (en vez de 0).

En casi todas las bases de datos hay truquillos, y este es para SQLite, ejecutando esta SQL:

D3LETE FROM sqlite_sequence WHERE name='NombreDeTablaAResetear';

Ojo, quita el «3» de la sentencia, ya que mi server no me deja meter SQL en el texto de mis post…

Please follow and like us:

El misterioso caso del «crontab -l» vacío

Os pongo en situación: equipo linux, con una Ubuntu para ser más precisos. Mágicamente, las tareas programadas en el cron, no se ejecutan. ¿El síntoma?:

nas001@nas001:~$ sudo crontab -l
no crontab for root

Como no expresar, ante esta situación, en un grito al cielo: «¡Me cago en tó…!».

Tras leer y leer, y que mi amigo (y el de todos) Google, me lanzara muchas soluciones que no me funcionaban, lo encontré yo mismo:

crontab: usage error: unrecognized option
usage:  crontab [-u user] file
        crontab [-u user] { -e | -l | -r }
                (default operation is replace, per 1003.2)
        -e      (edit user's crontab)
        -l      (list user's crontab)
        -r      (delete user's crontab)

¿Qué ven mis ojos?… se le puede indicar cual es el fichero que quiero que cargue. Pues nada, manos a la obra:

nas001@nas001:~$ sudo crontab /etc/crontab

Mano de santo, oiga.

Please follow and like us:

Al fin, como lograr que un cliente linux, actualice el DNS de un Windows 2003 server mediante el DHCP

Disclaimer: Desgraciadamente esto solo esta probado en un entorno con clientes Ubuntu, y servidores Windows 2003 Server. Si no es exactamente esta configuración de equipos, no te aseguro que funcione.

¡Por fin!… Un método que funciona, para que tu cliente Linux, metido dentro de una red con un Active Directory, pueda actualizar el DNS cuando recibe una ip a través de la DHCP del servidor.
El escenario en el cual esta solución es aplicable, es cuando tu ordenador Linux, recibe una ip del servidor DHCP de Windows, pero el resto de los equipos no pueden resolver el nombre de la máquina, solo mediante ip pueden contactar con la máquina. Y tras revisar el fichero «/etc/dhcp3/dhcp.conf» es correcto (en teoria no tendrías que tocar nada de fichero por defecto).

Bien… ¡deja de mirar a tu máquina Linux como la culpable!. La culpa esta en el servidor Windows. Tras mucho revisar a nuestro amigo Google, y culpar a mi pobre Linux, al final he visto que solo hay que tocar el servidor Windows en su servicio de DHCP para que todo vaya fino.

Por partes, solo hay que seguir este manual, aunque yo la voy a traducir y anotar:

  • ad_usuarioLo primero de todo es generar un usuario con los suficiente permisos para incluir registros/punteros en el DNS. Ir a «Usuarios y equipos de Active Directory», allí crear un nuevo usuario, pon por ejemplo un nombre muy descriptivo («dhcpTOdns», o «dhcpAdns» o «noBorrarEstePutoUsuario») pon un password que sea sencillo de recordar ya que no lo usaras muy a menudo :).
    Tras generarlo, tienes que incluirlo en el grupo «DnsUpdateProxy», el cual es el que nos concede el permiso para actualizar el DNS. Quitale cualquier otro permiso (quitale del grupo de «usuarios de dominio»).
  • dhcp_configAhora pasamos a la madre del cordero. Configurar el servicio de DHCPdel Windows 2003, para que use este nuevo usuario que hemos incluido. Entramos en la consola de administración del DHCP y pulsamos sobre el arbol de la izquierda sobre el servidor, luego «Propiedades», allí ve a la pestaña «DNS», y dejala tal y como pone en la imagen que te aparece en la derecha. Tras esto, solo queda ir a la pestaña de «Opciones Avanzadas» para allí pulsar sobre el botón de «Credenciales». Pon el usuario/dominio/password del usuario que hemos creado anteriormente.

Ahora en la máquinas Linux, haz un «sudo dhcpclient3 -d ethx» (donde ethx es tu tarjeta de red conectada al dominio) y todo el mundo podrá acceder por tu hostname a la maquina Linux. Huyuuuu….

Please follow and like us:

¿Error #1045 en MySQL con root en otro host (no localhost)?

ACLARACIÓN: No se muy bien porqué, pero la seguridad de WordPress, no me permite usar ciertas palabras, del lenguaje SQL. Para arreglarlo, donde veas un «3», pon una «e». Así de simple. Parece ser que ocurre a mas gente y hay una solución: aquí.

Esto me he encontrado en mi trabajo tras actualizar una maquina linux… no habia manera de conectar remotamente, y siempre nos daba un error 1045 (sin permisos). Solemos usar el usuario root, limitado a nuestra subred (al rango me refiero), sin password o con un password prefijado (que no os voy a contar :P) pero hoy no entraba de ninguna manera.

¿Que hacer?, muy sencillo (y parece que a mucha gente le asusta la consola de comandos) si tienes acceso a la maquina en localhost, y lo mas sencillo es hacer esto:

S3LECT host,user,password FROM user;

Comprobar que el usuario tiene el host correcto, es decir, que permite tener permisos a la máquina donde te conectas, y si tienes dudas (temporalmente) usa el simbolo «%», para decir que cualquiera (es un comodin). Usa el comando (la subred que ves será la tuya, o un host en particular):

UPDAT3 user SET host='%' WHERE user='root' AND host='192.168.0.%';

Una vez hecho esto, si ves que hay un password y todavía no te puedes conectar, seguramente es porque ese usuario desde ese host, tiene asignado un password que no coneces. Simplemente lo reseteamos:

UPDAT3 user SET password='' WHERE user='root' AND host='%';

Ahora no tendrás ningún problema en entrar… PERO tu servidor es tremendamente inseguro. Tras hacer comprobaciones, backups y esas cosas, pon un password a el root.

Please follow and like us:

Como resolver los "TimeOuts" con SNMP en Ubuntu

Llevo unos dias liado con un servidor rebelde, que necesita el SNMP para monitorizarle, que no queria funcionar con la ip de su red. El problema tiene un sintoma clave:

Funciona en localhost pero no con la ip de la red.

La solucion es que hay que eliminar de «/etc/default/snmp» en la variable SNMPDOPTS la parte «127.0.0.1». Y ¡¡¡tachán!!!, ya tienes el servicio SNMP activo.

Para la instalación completa la puedes leer en ingles aqui.

Please follow and like us: