GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash elevator=deadline”

Después de editar el archivo, lo guardamos y ejecutamos como root:

root@mambo-tango:~# update-grub

, para que vuelva a releer la configuración… luego reiniciamos y listo.

Para los que quieran saber mas de este parámetro y que cambia, pueden leer este link http://www.cyberciti.biz/faq/linux-change-io-scheduler-for-harddisk/

IOnice permite setear por proceso, la prioridad de acceso al I/O del sistema, utilizando para esto 3 tipos de comportamientos:

1. Idle: el proceso solo accede cuando a pasado un determinado tiempo de gracia sin que ningún proceso acceda al recurso (la prioridad mas baja, util para procesos batch o que no son prioritarios).
2. Best effort (mejor esfuerzo): Esta es la clase por defecto, y dentro de la misma se setea una prioridad de 0-7, siendo la prioridad 0 la máxima.
3. Real time (en tiempo real): El proceso accede directamente al recurso sin esperar a que termine un proceso anterior (lo interrumpe). Es la prioridad máxima que se puede conseguir.

Algunos ejemplos de uso serían:

#~$ ionice -c3 -p8912

(Establece que el proceso “8912″ tenga acceso en tiempo real al disco.)

#~$ ionice -c2 -n0 3221

(Establece la maxima prioridad, para el proceso 3321, en la cola de procesos que estan configurados como best effort (clase 2) )

#~$ ionice -c2 -n2 bash

(Ejecuta bash con best effort, prioridad 2). Como siempre, mas info en man ionice .

Esto en capa 3 (IP) es lo habitual si B es nuestro gateway, pero a nivel de capa4 (TCP) no lo es. Esto puede ser medio extraño para algunos, ya que nos podemos plantear que A se conecte directamente a C, pero que pasa si entre A y B está el firewall de la empresa en la que trabajamos, y por medio del cual solo pasa contenido web (puerto 80 y 443), por ej.?, y nosotros queremos tener acceso ssh a C (puerto22) ?.

En este caso lo que podemos hacer, si B es de nuestra pertenencia (el equipo de casa por ejemplo), es levantar el ssh en el puerto 80 del equipo B, armar un tunel entre nuestro equipo A (el del trabajo) y B, y hacer que B se conecte al puerto 22 de C, con lo que todas las conexiones ssh que iniciemos contra el puerto 80 de B, serán redirigidas al puerto 22 de C. Esto se traduce en el siguiente comando:

ssh -p 80 -L2222:IP-Host-C:22 usuario@Host_b

por ejemplo  ssh -p 80 -L 2222:201.122.101.2:22 mboscovich@miequipob.com

la opción -L 2222:201.122.101.2:22 quiere decir que localmente se vincula el puerto 2222 (del equipo A) con el puerto 22 del equipo 201.122.101.2 (equipo C), la opción -P 80 es para se conecte al 80 el ssh, en vez del 22 (por defecto).

Luego, si hacemos ssh -p 2222 localhost, estaremos accediendo al equipo C  :D.

Debo aclarar que si bien esta es una versión de desarrollo, es totalmente funcional, y esta en este estado desde agosto de 2009, lo que probablemente indique que el desarrollador no la publico todavía por fiaca .

rm ~/.kde/share/config/knotifyrc

y listo, a partir de ahora podemos volver a apagar el equipo desde el menu K.

Nota: dicho comando debe ser ejecutado con el usuario que iniciamos sesión, no como root.

De seguro muchas veces les ha pasado que tienen que loguearse remotamente a un servidor, y ejecutar muchos comandos en simultáneo, y monitorear sus salidas.  Esta tarea implica por cada comando establecer una nueva conexión ssh, para de este modo tener una terminal para dicho comando, algo bastante molesto. Por suerte screen puede ayudarnos a hacer simple esta tarea, estableciendo una sola conexión y multiplexando nuestra terminal para poder ejecutar varios comandos en simultáneo.

Veamos un ejemplo:  supongamos que queremos monitorear nuestro sistema con tres comandos en simultáneo, por ejemplo el comando top, el comando tail -f /var/log/syslog y el comando watch netstat -t4u4n. Bien, para esto nos conectamos a nuestro equipo remotamente,y ejecutamos

mboscovich@fuser3:~$ screen

( con esto empezamos a utilizar la bestia   )

bien, en esa misma consola ejecutamos el primer comando (top)

mboscovich@fuser3:~$ top
top - 17:11:47 up  1:00,  3 users,  load average: 0.05, 0.05, 0.03

Tasks: 155 total,   1 running, 154 sleeping,   0 stopped,   0 zombie

Cpu(s):  5.0%us,  1.8%sy,  0.0%ni, 93.0%id,  0.0%wa,  0.0%hi,  0.2%si,  0.0%st

Mem:   2057784k total,  2039872k used,    17912k free,    58876k buffers

Swap:  4000176k total,     6404k used,  3993772k free,   994096k cached
PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND

2069 mboscovi  20   0  379m  41m  17m S    3  2.1   0:09.64 konsole

860 root      20   0  686m  93m  14m S    2  4.7   2:45.82 Xorg

......

bien, ahora tenemos corriendo en nuestra primer consola virtual, el proceso top.  Si ahora hacemos ctrl+A+c (la c es de create), crearemos una nueva consola virtual colgada de la misma sesión . Ejecutamos eso y luego ejecutamos el segundo comando (tail -f /var/log/syslog)

mboscovich@fuser3:~$ tail -f /var/log/syslog
Oct  5 17:12:59 fuser3 dhclient: bound to 192.168.1.14 -- renewal in 28 seconds.
Oct  5 17:13:27 fuser3 dhclient: DHCPREQUEST of 192.168.1.14 on eth0 to 192.168.1.1 port 67
Oct  5 17:13:27 fuser3 dhclient: DHCPACK of 192.168.1.14 from
......

bien, ahora tenemos dos consolas colgadas de la misma sesión, corriendo en simultáneo . Si queremos crear una nueva consola (la tercera), volvemos a ejecutar ctrl+a+c , así que hacemos eso y ejecutamos el tercer comando ( watch netstat -tunp)

mboscovich@fuser3:~$ netstat -tupn
Every 2,0s: netstat -tupn                                                                     Mon Oct  5 17:19:36 2009
(No todos los procesos pueden ser identificados, no hay informacin de propiedad del proceso

no se mostrarn, necesita ser superusuario para verlos todos.)

Conexiones activas de Internet (servidores w/o)

Protocolo Recv-Q Send-Q Direccin Local Direccin Externa Estado       PID/Program name

tcp        0      0 192.168.1.14:45049      76.13.15.40:5050        ESTABLECIDO 3839/kopete

tcp        0      0 192.168.1.14:52069      64.233.169.125:5223     ESTABLECIDO 3839/kopete

tcp        0      0 192.168.1.14:35523      65.54.50.160:1863       ESTABLECIDO 3839/kopete

.....

Listo, ya tenemos los tres procesos ejecutándose en simultáneo, como queríamos. Ahora para navegar entre las distintas consolas creadas, y ver la salidas que se muestran en las mismas, simplemente hacemos ctrl+a+n (la n es de next), o ctrl+a+p (previous), no es lindo ?? .

Bien, pero ahí no termina la mágia de screen…. supongamos que por alguna razón tenemos que cerrar nuestra conexión al servidor remoto, pero no queremos que estos procesos dejen de ejecutarse en el servidor. Bien en este caso lo que hacemos es simplemente desconectarnos del proceso screen que controla las consolas creadas, lo que en screen se conoce como detach. Para realizar esto simplemente ejecutamos ctrl+a+d, y después si, cerramos la sessión al servidor ( nos desconectamos de el digamos). Bien, ahora la magia, si volvemos a loguearnos en el servidor, y hacemos un screen -ls, apareceran los procesos screen que se continuan ejecutando en el servidor, por ejemplo

mboscovich@fuser3:~$ screen -ls
There is a screen on:
 4450.pts-4.fuser3       (05/10/09 17:09:24)     (Detached)
1 Socket in /var/run/screen/S-mboscovich

esto nos muestra que tenemos un proceso screen corriendo (el 4450.pts-4.fuser3) desde las 17:09 del día 05/10/09, y que este esta detached. Bien para volver a conectarnos a dicho proceso screen, hacemos

mboscovich@fuser3:~$ screen -r 4450.pts-4.fuser3

y chan! tenemos nuestras tres consolas virtuales, que siguen ejecutándose en el servidor, y podemos seguir monitoreando el mismo sin tener que volver a lanzar dichos procesos .

Imaginen la potencia de esto, si tiene que lagar un proceso en el servidor que va a demorar varias horas, y ustedes no quieren dejar su pc cliente prendida mientras se ejecuta el mismo, sino que ejecutan este por medio de screen, detachan la consola que muestra la salida del mismo, se desconectan del servidor, para luego, al rato,  volver a conectarse al mismo, y al proceso screen que tiene la consola con el proceso que se continua ejecutando, es una excelente solución para estos casos no… .

Por último, si queremos cerrar los procesos que se estan ejecutando en dichas consolas virtuales, simplemente hacemos exit en cada una y listo.

Siempre podemos chequear que no quedo ninguna consola abierta, con el comando screen -ls

Bueno, espero que a alguien le sirva, en mi caso fue de mucha utilidad, sobre todo porque había usado screen hace ya unos años, pero me había olvidado de su magia, hasta que hoy tuve que volver a sacarle el jugo .

Los pasos que seguí fueron los siguientes:

• Instale la librería libsdl1.2debian-pulseaudio (en mi sistema estaba instalada la libsdl1.2debian-alsa, pero alsa no es más el sistema de sonido en ubuntu 9.10, así que la reemplace por la versión para pulseaudio).
• Modifiqué el archivo /etc/default/pulseaudio, y puse PULSEAUDIO_SYSTEM_START=1
• Agregué a mi usuario al grupo pulse-access (sudo adduser ${USER} pulse-access) (Si hay más de un usuario en el sistema, debemos agregarlo también a este grupo, sino no tendra sonido )

Listo, después de eso reinicie y todo funciona de maravillas (el reinicio es obligatorio, porque a partir del cambio en el archivo /etc/default/pulseaudio, pulseaudio corre como demonio del sistema, en vez de correr para cada sessión por medio de X11).

Este modem funciona muy bien en GNU/Linux (aunque la gente de CTI diga lo contrario ), particularmente utilizo kubuntu 8.10 (kernel 2.6.27-11).

El modem utiliza el protocolo ppp para establecer un enlace punto a punto contra un host de CTI, el que hace de gateway para nosotros proporcionandonos el tan ansiado acceso a internet.

Los pasos a seguir para configurar el modem son los siguientes:
1) Crear el archivo /etc/udev/rules.d/50-md300.rules y agregar el siguiente contenido en el mismo:

NOTA: Cuidado con las comillas si copian y pegan!!!!,
tienen que borrarlas y escribirlas de nuevo en caso
de que les dé error de sintaxis el udev.
Seguramente en muy poco tiempo este paso ya no sea
necesario, dado que en futuras versiones este  archivo
ya puede venir por defecto. Por el momento hay que
crearlo.

2) Instalar gnome-ppp

sudo apt-get install gnome-ppp

3) Crear ó modificar el archivo $HOME/.wvdial.conf  y poner el siguiente contenido:

[Dialer Defaults]
Modem = /dev/ttyACM0
ISDN = off
Modem Type = USB Modem
Baud = 460800
Init = ATZ
Init2 = AT+CFUN=1
Init3 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Init4 = AT+CGDCONT=1,”IP”,”internet.ctimovil.com.ar”
Init5 =
Init6 =
Init7 =
Init8 =
Init9 =
Phone = *99#
Phone1 =
Phone2 =
Phone3 =
Phone4 =
Dial Prefix =
Dial Attempts = 1
Dial Command = ATM1L3DT
Ask Password = off
Password = 3616
Username = ctigprs
Auto Reconnect = off
Abort on Busy = off
Carrier Check = on
Check Def Route = on
Abort on No Dialtone = on
Stupid Mode = off
Idle Seconds = 0
Auto DNS = off
;Domain =
;Nameserver = 170.51.255.100
;Nameserver2 =
;Minimize = off
;Dock = on
;Do NOT edit this file by hand!

NOTA: este archivo solo funcinará con la empresa CTI, para otras empresas hay que cambiar algunos datos (datos que debería proveer el ISP )

4) Creamos el archivo /etc/ppp/ip-up.d/gateway  y 
le  ponemos lo siguiente:

#!/bin/sh
route add default gw 10.64.64.64

5) Seteamos los permisos para este archivo:

sudo chown root:root /etc/ppp/ip-up.d/gateway

sudo chmod 755 /etc/ppp/ip-up.d/gateway

6) Agregamos a nuestro usuario a los grupos dialout y dip

sudo adduser $USER dialout

sudo adduser $USER dip

7) Cerramos la sesión y la volvemos a abrir 

(esto es para que tome los nuevos grupos a los que pertenece el usuario)

  Listo!!!

Ahora podemos abrir la aplicación gnome-app y  con solo poner

 conectar deberíamos salir navegando sin problemas   . 

Bueno, espero que a alguién le sirva, se aceptan mejoras y
comentarios.

Buscando como testear el pendrive, me encontré con una aplicación que se llama badblocks, que como su nombre lo indica, se encarga de buscar bloques defectuosos en las particiones o en discos.

La forma de usar esta aplicación es muy simple, solo basta con ejecutar

sudo badblocks /dev/sdX

donde sdX es el nombre del dispositivo, en mi caso sdb.

Esto realizará el testeo y mostrará los errores que encuentre. En el caso de que la partición ó el disco (en este caso un pendrive) no contenga errores, no mostrará nada en la salida.

Badblocks tiene un montón de opciones (man badblocks para más info ), una de las interesantes es -o, que nos permite guardar la lista de bloques malos en un archivo, el que luego puede ser pasado como parámetro al programa mkfs para decirle que, a la hora de crear el filesystem, no utilice dichos bloques .

En definitiva, los pasos para detectar y no utilizar bloques malos en un dispositivos, son los siguientes (Ojo!!!, esto borrará el contenido completo del dispositivo!!!):

# busca bloques malos y los lista en un archivo

sudo badblocks -o bloquesmalos /dev/sdX

# Crea el filesystem, ignorando los bloques malos.

sudo mkfs.vfat -l bloquesmalos /dev/sdX

(Donde sdX es el dispositivo en cuestión)

y listo .

Este fin de semana, sin ganas de hacer otra cosa, me puse a jugar un poco con esto. Buscando por todos lados, no puede encontrar un elemento que me permita ver las conexiones entrantes y salientes de mi máquina, así que me decidí a hacer uno propio, después de todo no pintaba muy difícil. Como siempre, empecé por buscar si había algo hecho, y lo más cercano que encontré fue logtail, así que lo baje y basandome en los beneficios que me da la licencia GPL, me puse a examinar su código. Cambien una línea acá, puse otra línea allá… termino andando… pero como siempre, uno no esta conforme con su obra , así que refactorize un poco la cosa, y como resultado tuve la versión 0.5 de netstat ( así decidí llamarlo, no soy muy creativo ).

Buscando un poco, encontré como subirlo a kde-look (que es de donde lo descarga superkaramba). Así que lo subí a eso de las 22hs del día domingo. Mi sorpresa fué el día lunes, cuando a eso de las 9hs revisé el estado de las descargas, y me había encontrado con que ya tenía 80 descargas . Eso me motivó a seguir jugando con netstat, y le agregué un par de gráficas, imagen de fondo y demás yerbas, con lo cual surgió la versión 0.9, que es la actual.

Resumiendo, el fin de semana no fue “taaan” poco  productivo como pensaba .

URL de netstat: http://kde-look.org/content/show.php/Netstat?content=83874