por ·18 comentarios

Calidad de servicioAyer leyendo Un Sanjuanino en Rio Cuarto me dí con una entrada mencionando un vínculo a HowtoForge donde se plantea la alternativa mas facil que he visto hasta ahora para tener una implementación de QoS (por Quality of service en inglés: calidad de servicio) que aunque rudimentaria es totalmente funcional.

Se puede extender a cualquier otra disciplina de encolado y mejorar en función de las necesidades de cada uno, así que vamos a los bifes.

Requisitos necesarios:

  • Kernel con soporte para iptables.
  • Iptables instalado.
  • El comando tc instalado, que es parte del paquete iproute2
  • Opcional, l7filter para iptables.

Cualquier distribución orientada a servidor/router o redes en general ya trae estos tres requisitos preinstalados y configurados. En caso de no ser así basta con usar el gestor de paquetes de cabecera para instalar iproute2 e iptables, y seguir cualquier guía de configuración del kernel para darle soporte a iptables.

Esquematizando un poco:

El esquema de mi red es exactamente el mismo del ejemplo de howtoforge:

[internet]<–>[cablemodem]<–>[eth1  linux  eth0]<–>[red local]

Queda en cada uno adaptar las siguientes instrucciones para la topología de su red.Continúa leyendo

por ·Sin comentarios

Siguiendo la línea del post anterior en que uso mplayer para reproducir videos de youtube, se me acaba de ocurrir otro tip estúpido, de esos que simplifican la vida:

Descargar videos de youtube simplemente presionando una combinación de teclas (evitando así eso de instalar extensiones para el navegador que cumplan la misma función y si te pasa como en mi caso, evitando llevar las manos hasta el mouse para hacer click, que soy de los que tienen mas tiempo las manos en el teclado que en el mouse).

La idea es:

  • Copiar la URL (la dirección del video de youtube) al clipboard o portapales – como prefieran
  • Llamar por medio de un atajo de teclado a un script de bash que descargue el video en donde le especifiquemos.
  • Opcional: reproducir el video descargado con mplayer o tu reproductor de cabecera.

Desde un terminal (o si prefieren, en modo gráfico) creen una carpeta en donde almacenar los videos que descargará el script. El siguiente comando crea una carpeta llamada videos dentro de /home/tu_usuario/ :

mkdir  ~/videos

Instalar el paquete youtube-dl y si no lo tienen instalado del post anterior instalen además el paquete xclip. No puedo dar instrucciones específicas para cada distribución. Usen su gestor de paquetes para instalarlos. En Gentoo:

emerge youtube-dl xclip

Crear un archivo en blanco:

touch ytdl.sh

hacerlo ejecutable:

chmod +x ytdl.sh

Editar con su editor de texto de cabecera el archivo ytdl.sh:

nano ytdl.sh

Copiar dentro del archivo el siguiente contenido:

#!/bin/bash

youtube_url=`xclip -o|sed “s/ .*//”|head -n1`

cd ~/videos

#Descomentar la opción que se vaya a usar:

#Opción 1 sin especificar nombre de usuario y contraseña:

#youtube-dl -b -t $youtube_url

#Opción 2, especificado usuario y contraseña:

#youtube-dl -u <usuario> -p <password> -b -t $youtube_url

Crear un atajo de teclado que llame a ytdl.sh:

De nuevo no puedo dar instrucciones específicas pero todos los gestores de ventanas (Gnome, KDE, XFCE, etc…) tienen algún modo de definir atajos de teclado.

He estado mirando un poco y para usar atajos de teclado en XCFE que es el entorno de escritorio que estoy usando hay que ir a Settings / Xfce 4 settings manager / Keyboard / Application shortcuts. (Sepan disculpar pero tengo XFCE instalado en inglés).

Por ejemplo, asociar el combo de teclas CTRL + Y para que al ser pulsado ejecute ytdl.sh o si quieren llamarlo por el path completo, que llame a /usr/bin/ytdl.sh

Es realmente un TIP estúpido ¿No? 😀

Simplifica mucho la vida, eso si…

por ·6 comentarios

O de como se le va haciendo cada vez mas dificil la vida al spammer promedio.

Como decía, me gustaba mas antes, cuando era como el lejano oeste. No había tantas trabas, no existían tantas regulaciones, ni leyes, uno podía ir por internet haciendo desastres sin que nada ni nadie lo impida…

Eran épocas de gloria y pena, donde los hackers eran leyenda , no existía el concepto de zero-day, las cosas no se parchaban tan rápidamente, apache y sendmail caían todos en la volteada. Los antivirus no detectaban troyanos premanufacturados, los virus infectaban ejecutables y realmente hacían daño del que duele borrando y rompiendo, uno podía mandar un paquete mal parido formado y hacer caer windows 95 –aunque parece que ahora, con windows Vista, Server 2008 y Windows Seven caminamos sobre huellas del pasado-, el ambiente under era realmente under… Eran tiempos salvajes!

Continúa leyendo

por ·4 comentarios

Viene de la época en que el manual de Gentoo ofrecía como alternativa la posibilidad de que un amigo mas experimentado «te ayude» durante la instalación del sistema operativo, con todos los perjucios que eso conlleva mas adelante a la hora del mantenimiento periódico…

Screen es una herramienta poderosísima a la que no termino nunca de encontrarle nuevos usos. Entre tantas cosas que permite hacer, se puede usar para compartir una sesión en la consola de comandos con N cantidad de personas, donde todos pueden leer los comandos que los demás tipean y la salida por consola que estos comandos devuelven y todos pueden escribir en la misma consola de comandos. Es como una orgía, pero en Bash.

Por hacer una comparación, sería como una especie de VNC o Terminal Server pero para el modo texto de linux, en tiempo real y multiusuario.

Muy útil para mostrarle a algún colega/cliente/amigo como se hace tal o cual cosa en linux mientras se mantiene a la par una conversación por video conferencia, teléfono, chat, etc.

Nunca he asistido a uno de esos FLISOL pero esto se me ocurre que sería una buena alternativa también.

*COF*puedeservirparachatearyparacontrolarunabotnet*COF*

Teniendo Screen instalado, el funcionamiento es bastante sencillo, por ejemplo:

  • Una pc remota de nombre pcremota
  • Un usuario remoto identificado como usuarioremoto
  • Un usuario local identificado como usuariolocal
  • Usuariolocal necesita compartir una sesión de consola con usuarioremoto en pccremota.

Como se pone en funcionamiento:

Usuariolocal se conecta a pcremota identificádose a si mismo como usuarioremoto:

~ $ ssh usuarioremoto@pcremota

Usuariolocal inicia screen en pcremota:

~ $ screen -S sesioncompartida

Usuarlocal inicia el modo multiusuario de screen presionando las teclas [CTRL] + [a] y luego tipeando:

:multiuser on

Usuarioremoto se conecta a la sesión compartida:

~ $ screen -x usuarioremoto/

Y eso es todo. Durante toda la sesión ambos pueden leer y escribir sobre la misma consola.

Al ejecutar screen -S sesióncompartida se está especificando un nombre para la  sesión en cuestión. Si cualquiera de los usuarios conectados se desconectara, podría recuperar todo en donde lo dejó usando:

~ $ screen -r sesioncompartida

¿Y si son usuarios distintos?

Si se trata de usuarios distintos, por poner un ejemplo, donde usuariolocal se autentica contra pcremota como root y usuarioremoto se va a conectar a la sesión de root, entonces el ejecutable de screen necesita tener habilitado el bit SUID:

~ $ chmod u+s /usr/bin/screen

Por otro lado, luego de habilitado el modo multiusuario de la sesión screen que inició root, este tendría que darle permiso a usuarioremoto para que se conecte a su sesión. Como todos los comandos en scren, presionando primero [CTRL] + [a] y tipeando:

:acladd usuarioremoto

Y  así sucesivamente N cantidad de veces, una por cada usuario que se va a conectar a la sesión screen con credenciales diferentes a las del usuario que inició el proceso.