Seguridad en linux

Cortesia del señor Andres, una serie de consejos imprescindibles para tener un servidor minimamente asegurado en linux

http://www.cyberciti.biz/tips/linux-security.html

Una de linux

Pues eso.

Y si Torvalds no lo dice…

… aqui nos seguimos chupando las pollas por  toda la eternidad.

En este articulito el amigo Linus Torvalds dice que con los continuos cambios y añadidos el kernel de linux se ha vuelto una bestia lenta y pesada, cosa con la que estoy plenamente de acuerdo, pero no solo circunscrito al kernel sino ya al resto de la distro de rigor: es corriente ver distros de escritorio petadas hasta la bandera de decenas de procesos que se ejecutan en segundo plano, por no hablar de los mil-y-un-paquetes-que-nunca-llegaras-a-utilizar y que se instalan asi por la patilla y sin venir ni a cuento.

Mas de uno saltara diciendo que si tal, que si cual, que se pueden desinstalar, que recompiles el kernel para dejarlo mas fino, que toquetees rc3.d (o rc2.d… y porque cojones me han vuelto a cambiar inittab en ubuntu? joder! dejalo quieto yaaa!!), que te instales la distribucion de pepito grillo que es mas liviana pero que no tiene no se que otra cosa q necesitas…  me cago en mi vida!!! que no!!! que no quiero perder el tiempo con el sistema operativo coño! que no me da la gana de tener que dedicar 3 meses a customizar y makear el puñetero SO y solo “porque se puede”, que es algo que tendria q pasar desapercibido desde todos los puntos de vista! impacto en el rendimiento casi nulo, manejo natural, sobrecarga casi nula, respuesta inmediata, configuracion inmediata…

Pero nada, la gente prefiere hacerse pajillas delante del linux, modificar todo lo modificable, descojonar el sistema para volver a recojonarlo y asi tener la sensacion de controlar un huevo y parte del otro. Oye pues muy bien, yo prefiero algo como BeOS o Amiga OS 4, bien curradito, pequeñito, ligerito, funcional y todas esas cosas que deberian de ser un SO y que Linux no es.

Y todo esto se aplica en mayor o menor medida a Windows of course.

backup con rsnapshot

Recientemente he tenido que montar un chiringo de copias de seguridad para un par de servidores web tipicos (php+mysql) bajo CentOS y como estamos en crisis ha tenido que ser con software gratuito, de modo que despues de mirar las soluciones disponibles me decante por Rsnapshot, un script hecho en perl que por debajo usa las utilidades tipicas del sistema y rsync, reconocido programa para sincronizar directorios por red.

En principio el proceso es simple, pero como siempre sucede en el mundo Linux, lo que empieza simple acaba convirtiendose en un cipotillo de padre y muy señor mio, y esta vez no va a ser la excepcion aunque hay q reconocer que tampoco es para tanto. Lo importante es que una cosa simple te lleva horas por detalles estupidos, con lo que lo que te ahorras en licencias te lo gastas en mano de obra, pero esa es otra historia que merece ser comentada en otro momento.

La idea es hacer una copia de las paginas web, base de datos y ficheros de configuracion una vez al dia y dejarlos en un equipo remoto.

Para empezar la fiesta vamos a bautizar a los equipos: por un lado esta el servidor web y por el otro lado esta el servidor de copias. El caso es que el servidor de copias actua mas como cliente que como servidor ya que sera el servidor de copias el que se conecte al servidor web para recuperar los ficheros que hayan cambiado; con esto quiero decir que el servidor web no sera el que envie los datos a su gusto y antojo al servidor de copias sino sera el servidor de copias el que pida los datos al servidor web (push vs pull). Una ventaja de este esquema es que no es necesario instalar ningun agente ni nada en los servidores que vayamos a copiar (siempre y cuando tengan las herramientas basicas del sistema, servidor de ssh y una version de rsync modernilla).

• Primeramente descargamos rsnapshot de aqui.

• Lo vamos a instalar unicamente en el servidor de copias con:

gunzip rsnapshot.tar.gz
tar xvf rsnapshot.tar
./configure
make install
cp /usr/local/etc/rsnapshot.conf.default /usr/local/etc/rsnapshot.conf

• Para que la cosa rule de forma un poco segura lo vamos a lanzar con la cuenta rsnapshot (luego veremos el porque) que procedemos a crear en el servidor de copias:

adduser rsnapshot

• Vamos a realizar una copia todos los dias a las 2 de la mañana asi que creamos el fichero

touch /var/spool/cron/rnsapshot

le damos permisos de r,w,x para el usuario que lo va a lanzar

chmod 700 /var/spool/cron/rnsapshot

chown rsnapshot:rsnapshot /var/spool/cron/rnsapshot

A continuacion vamos a añadir una linea que le indique al cron cuando y qué debe de ejecutar

0 2 * * * /usr/local/bin/rsnapshot daily

y con esto y un bizcocho reiniciamos el cron a las 8 =:? para que lea los ficheros de config:

/etc/init.d/cron restart

Bien, ya tenemos lo mas facil, el script instalado y listo para ejecutarse todos los dias a las 2 AM.

• Ahora vamos a ver el fichero de configuracion del rsnapshot:

Primeramente hay que tener cuidado con la sintaxis, no se admiten espacios, hay que tabular siempre.

La mayor parte de los parametros estan  bien como vienen y el fichero es bastante autoexplicativo.

Con snapshot_root indicamos la carpeta donde se dejaran los backups

snapshot_root   /home/snapshots/

Los ficheros de log los dejamos en

logfile        /home/snapshots/sys/rsnapshot

El fichero que contiene el pid en

lockfile        /home/snapshots/sys/rsnapshot.pid

para el nivel de verbosity

verbose         2
loglevel        3

Se dejan los logs en el home del usuario ya que necesita permisos de escritura y que mejor lugar que su propio directorio. Lo mismo le pasa al fichero que contiene el pid del proceso.

Precisamente la parte que hay que cambiar por narices viene fatalmente explicada en la pagina web, y es la que nos permite indicar QUE hay que copiar y CUANTO tiempo hay q mantener las copias. Se trata de las siguientes lineas:

interval        daily   7
backup  /home/          localhost/

Hay que hacer notar CON MAYUSCULAS que la linea interval no tiene nada que ver con intervalos y la palabra daily, weekly etc NO INDICAN NADAN, ES SOLO UNA ETIQUETA que puede ser sustituida por cualquier otra.

Lo que se esta diciendo aqui es que nuestra copia se llamara daily y se rotara 7 veces, esto es: se mantendran las ultimas 7 copias. Como en el cron lo hemos puesto diario entonces vamos a mantener 7 dias de copias.

Por otro lado la linea backup  /home/          localhost/ indica que hay que hacer un backup de /home/ y dejarlo en localhost, que es un path relativo que se añade al indicado en snapshot_root.

Lo que a mi no me cabia en la cabeza era que se le estuviera indicando un CUANDO hacer la copia en el fichero de configuracion si ya se lo estaba indicando yo en el cron (es aqui cuando empiezan las paranoias: tendra el script implementado su propio cron? como se conjuga el daily con la configuracion del cron? bueno, pues nada, el daily no significa nada, solo es el nombre de la carpeta que va a crear el rsnapshot cuando haga el backup).

• Generar y configurar los certificados

Finalmente la cosa viene con otra de esas tocadillas de pito cortesia del linux de rigor, y es que hay q bregar con los dichosos certificados digitales. Claro, uno se pensara que es lo guapo del software libre, todo se hace por piezas, lo que hizo pepe lo reutiliza juan y que bien que funcionan las cosas. Bueno, pues vale. El caso es que aqui la transferencia de ficheros se hace por ssh pero no se puede usar autenticacion por password, asi que toca empaparse un poco de certificados. Ya nos hemos tenido que empapar de como funciona el cron, el propio programa con el fichero de configuracion que va a su puta bola con los tabuladores y ahora toca ssh y certis; vamos que nos vamos:

Pues para no liar demasiado al personal vamos a resumir: se genera un par de claves asimetricas para la autenticacion del servidor de copias en el servidor web. El servidor web es el que corre el demonio ssh y el servidor de copias el que ejecutara el cliente de ssh.

Las claves asimetricas van emparejadas: lo que encripta una lo desencripta la otra y viceversa. Asi, una vez generadas tendre una clave publica y una clave privada, las dos relativas al equipo que se va a conectar, esto es, el servidore de copias. La clave privada es privada y solo la sabe el servidor de copias. La publica es publica y la sabe el servidor de copias y el servidor web. Es mas, las claves no se generan por equipo (ya podrian) sino por usuario, asi tenemos que el usuario rsnapshot del servidor de copias se quiere conectar al servidor web, de modo que para empezar tendremos que dar de alta esta cuenta en el servidor web:

adduser rsnapshot

Una vez hecho, en el servidor de copias generamos el par de claves:

su rsnapshot

ssh-keygen -t rsa

Es importante cambiar al usuario para el que vamos a generar el par de claves. Hemos elegido el algoritmo de cifrado asimetrico rsa aunque podriamos haber puesto dsa, que es el otro disponible (para mas info de esto mirar en la wikipedia aqui y aqui).

Despues de esto tendremos nuestras claves en /home/rsnapshot/.ssh. Una sera ids_rsa y la otra ids_rsa.pub. El pub es de publico asi que la primera es la que no tiene que salir del equipo ya que es la privada.

Ojo que al generar las claves nos pide passprase, no se puede poner nada ahi porque sino el rsnapshot no funciona. Esto de por si es una verdadera anchoa en cuanto a seguridad, mas de uno estara pensando “joder, tanta historia con cifrados, certificados y tal pero como me manguen la clave ya la hemos liado parda porque la van a poder usar sin mas complicacion”. Pues si, estas cosas son asi, ya se sabe. Es por eso que todo se resuelve con una cuenta como rsnapshot, muy capada. Se puede capar mas instalando cualquier alternativa a bash que restrinja los comandos a lanzar, pero ya es que me parece una sobrada hacer estas movidas para instalar un triste programa de backup. Yo no recomendaria generar certificados para root y usar este usuario para lanzar rsnapshot aunque sea algo muy tentador por temas de permisos como ya se vera. Tambien podemos añadir algo de seguridad restringiendo las IPs de origen permitidas para conectarse por ssh; estas cosas ya las dejo un poco en el aire porque sino va a quedar un post mas largo que un año sin pan.

El cliente y el servidor ssh van un poco de la mano: el cliente coge su clave privada del directorio /home/rsnapshot/.ssh para encriptar la comunicacion cuando quiere enviarle algo al servidor ssh y el servidor ssh coge la clave publica de /home/rsnapshot/.ssh cuando quiere descifrar lo que recibe cifrado del usuario rsnapshot. De esta guisa hay que copiar ids_rsa.pub desde la maquina del cliente (el servidor de copias) a la maquina servidora (el servidor web) y dejarlo en el mismo directorio pero renombrando el fichero como authorized_keys.

scp /home/rsnapshot/.ssh/id_rsa.pub rsnapshot@IP:/home/rsnaphost/.ssh/authorized_keys

Asi como cada cliente que se conecta al servidor va a tener su propia clave privada en su directorio home, el servidor puede tener un unico fichero authorized_keys con todas las claves publicas de todos los clientes que se vayan a conectar. Para ello solo hay que ir copiando el contenido de todos los .pub que los distintos clientes hayan generado.

Llegados a este punto se impone recapitular:

Cliente: tiene la clave privada (ids_rsa)  en /home/rsnapshot/.ssh

Servidor: tiene la clave publica (ids_rsa.pub)  en /home/rsnapshot/.ssh renombrada como authorized_keys.

OJO: Revisar los permisos!!, el owner de /home/rsnapshot/.ssh y de su contenido tanto en el cliente como en el servidor tiene que ser el user rsnapshot y los permisos 700!! (r,w,x para el owner) sino no fona.

Mas cosas, hay que habilitar la autenticacion por RSA en el servidor ssh:

RSAAuthentication yes
PubkeyAuthentication yes

Para indicar donde buscara el servidor sshd las claves publicas de los clientes que se vayan conectando se puede poner

AuthorizedKeysFile    /path/to/authorized_keys

si lo queremos centralizado en un mismo sitio o sino

AuthorizedKeysFile    .ssh/authorized_keys

que hace referencia a un path relativo, que varia segun el usuario que se conecte

Reinicar el demonio

/etc/nit.d/sshd restart

y listo.

Podemos hacer una prueba de conectividad: en el cliente hacemos

su rsnapshot

ssh IP_WEB

y vemos que no nos pide clave

Si la cosa no ha funcionado y nos sigue pidiendo clave se pueden sacar los mensajes de debug del cliente ssh con

ssh-vvv IP_WEB

y mirar en el fichero

tail -f /var/log/secure

del servidor ssh para ver lo que esta pasando por sus tripas.

Una vez hecha la prueba hacemos desde el servidor de copias

su rsnapshot

rsnapshot daily

Con lo que se ejecutara y dejara los resultados en la carpeta que hayamos configurado. Si hay errores quedaran marcados en consola y en el fichero indicado en la directiva de configuracion logfile del fichero de configuracion rsnapshot.conf

Aqui viene el otro tinglado, y es que como el rsnapshot se ejecuta con permisos un poco cutres es posible que no pueda ni leer algunas paginas web o ficheros. Yo lo que recomendaria es configurar el apache para que se ejecute bajo un usuario y grupo determinado, hacer un

chown -R usuarioapache:grupoapache /www

de todo el arbol de paginas web y meter al rsnapshot en el grupo grupoapache, teniendo cuidado de ejecutar antes algo como

chmod -R 640 /www

para dar permisos de r,w a usuarioapache, de r a grupoapache (es decir, a rsnapshot) y nada para el resto al arbol de directorios web.

• Mysql

Despues de todo este tingladillo, que no es poco, vienen las copias del mysql. Esto es facil, nos bajamos automysqlbackup.sh de aqui, lo ponemos en el cron para que se ejecute antes del rsnapshot y a correr. Yo lo tengo como root asi

0 1 * * * /usr/local/bin/automysqlbackup.sh.2.5

Este script vuelca todas las bases de datos a texto a la carpeta q le indiquemos. De alli la podremos transferir de la misma forma que transferimos ficheros o paginas con el rsnapshot.

Los parametros mas importantes del automysqlbackup son los que siguen:

USERNAME= "usuario para conectarse a la bd"

PASSWORD= "password para conectarse a la bd"

DBNAMES="all" #bases de datos a grabar

BACKUPDIR="/path" #path donde se dejan

MAILADDR="user@mail.com"

MDBNAMES="mysql $DBNAMES"

Y yo creo q esto es todo, que no es precisamente poco. Un exito mas para el software libre un tanto descafeinado.

Y para que vale este demonio?

Hace poco tube que reinstalar un CentOS 5.x y me cague literalmente por las patas de la millarda de movidas que habia en /etc/init.d. Era una version server pero habia historias de Bluetooth como para parar un tren, entre otros scripts de arranque de cosas que no habia oido hablar en la vida. Me recordo a una vez hace 10 años, instalando una de mis primeras distros RedHat en el curro (no se si era una 4.3) para un servidor Qmail; vino un compañero de Madrid en plan “soy un guru y no me levanteis la voz que os meto un par de ostias” y al ver la lista de scripts de arranque de init.d nos explico para que valia cada uno de ellos. Y yo flipando claro, como ahora gracias a

http://www.redhatmagazine.com/2007/03/09/understanding-your-red-hat-enterprise-linux-daemons/

Ahi vienen muchos de esos procesos explicaditos con pelos y señales. Lo mejor es que he recortado hasta dejar… 6?

10 trukis para Linux

10 truquillos imaginativos para Linux.

Mi enésima intentona con Ubuntu

No es la primera vez que intento sustituir a Windows como SO en el PC de casa, y como ha sido norma hasta ahora, el intento ha terminado en fracaso.

Se podría pensar que, o bien no soy lo suficientemente espabilado como para echar a andar un Ubuntu, o me estoy haciendo mayor y mas intolerante a los cambios (o las dos cosas juntas). El caso es que hace unos meses reintenté por enésima vez la sustitución y no ha podido ser.

El objetivo era claro: estaba aburrido del Windows de toda la vida, tenía ganas de cambiar de sistema y todas las tareas que llevo a cabo en casa se pueden hacer mas o menos con Linux. Sin embargo no todo lo que reluce es oro, y me explico:

La primera impresión que se lleva uno al manejar Ubuntu es que es… denso. Hago un “ps ax” y veo una legión de procesos corriendo, la mayoría de ellos desconocidos para mi ya que mi experiencia en el mundo Unix esta fuertemente ligada a sistemas y redes, alejado de entornos de escritorio. El consumo de memoria recién instalado el sistema operativo es mayor que en Windows XP se coja como se coja: cierto es que si me limito a la línea de comandos y descargo las X los consumos caen en picado pero en condiciones normales mi Windows ocupa del orden de 300 megas de memoria con todos los programas secundarios que suelo usar ya cargados, mientras que Ubuntu consume sobre las 450 megas (y siempre hago uso del sistema de ventanas en entornos de escritorio).

Asocio la palabra “lentitud” con “X-Windows” sin pretenderlo. Y no me refiero a que el sistema vaya lento en general (que rasque de swap o que la pantalla se dibuje a trompicones) sino con una cierta falta de interactividad o agilidad. Hay un molesto retardo desde que hago doble click en una carpeta hasta que se abre. También asocio X-Windows con escritorios mal aprovechados en cuanto a espacio (abigarrados o no). En Gnome me pasa igual: los iconos de carpetas son grandes, se deja mucho espacio entre uno y otro y si se tunea el sistema se descacharra todo y pasan cosas como las que relataba en una entrada anterior con los nombres de ficheros demasiado largos. Aun así son cosas que se pueden sobrellevar. Otro detalle es el panel que tengo en la parte de arriba (aplicaciones, lugares, sistema etc). En la versión 8.04 incluyen una animación cuando pasas cerca el ratón si tienes puesto el “autohide”. Me gusta la animación pero veo que si la barra aparece, haces click en un icono y rápidamente sacas el ratón de la barra, la barra no se oculta, se queda fija hasta que nuevamente pasas el ratón por la barra. Este defecto lo he visto en todas las instalaciones a las q tengo accesion (3) y es un verdadero coñazo. También en muchas ocasiones los gráficos de los iconos se me corrompen: al arrastrar una carpeta o lanzar un programa desde el panel sale un garabato de colores amarillos o verde chillón bastante feo. También me pasa mucho que al copiar ficheros me sale la barra de progreso (que ha mejorado mucho y me gusta) con los nombres de los ficheros y directorios corruptos (gráficos extraños). No pasa siempre de todos modos, solo un 30% de las veces mas o menos).

Utilizar una aplicación de KDE y comerse un sobre consumo de 100 megas en librerías QT me toca la nariz… No sería mas rentable independizar de alguna manera el programa del sistema de ventanas elegido y que sea a la hora de configurar o compilar cuando se enlace con las librerías pertinentes? Supongo que esto es un verdadero tinglado de programar pero cosas mas complicadas se han hecho…

Veo series y pelis con el PC así que probé Totem. Al margen de que no me coge subtítulos (aparece en gris la opción, por ahora no se el porqué) la barra de seek funciona mal y no han sido pocas las veces que he pinchado, arrastrado y soltado y el evento de soltar no es bien recogido por Totem de modo que la barra sigue el movimiento horizontal del ratón aunque ya no esté ni posicionado en la ventana: tengo que mover el ratón hasta la barra y hacer click de nuevo. No pocas han sido las veces que al mover la barra un tanto frenéticamente (como consecuencia de lo anterior) el programa ha salido con un error de streaming. Como este programa no pillaba subtítulos y no tenía ganas de comerme el tarro instale VideoLan, gran conocido entre los usuarios de Windows. Este pilla subtítulos… pero solo algunos. Por alguna extraña razón de 10 frases me sale 1 mas o menos. He probado con varias pelis y así ha sido en todas ellas. Finalmente instale Mplayer. Mplayer visualiza correctamente los subtítulos pero lo hace a un tamaño exagerado que me llena la mitad de la pantalla y no he visto la forma de configurarlo gráficamente (seguro q se puede toqueteando los ficheros de configuración). Además, no se porque, en ocasiones tarda unos 30 segundos en arrancar al hacer doble click en una película: primero no pasa nada (no se ve nada, no hay feedback, no sabes si le has dado o no) después aparece la ventana en blanco, como medio colgada, y finalmente empieza la película. Son 30-40 segundos muy molestos. Para retamar, los 3 reproductores que he probado padecen de un terrible judder (y aqui en castellano) que en Windows se ve muy atenuado, por no decir inexistente. Esto del judder es una cosa que levanta pasiones por parte de aquellos que tienen la sensibilidad para notarlo. Por desgracia yo soy uno de ellos: reconozco que soy muy sensible a cosas como la pérdida de sincronismo sonoro, artefactos en la imagen o mala proporción de imagen fruto de la no configuración del modo de pantalla (widescreen pan&scan, 2:35, 1:85, modos de zoom y todo eso). El caso es que en Windows el judder es casi inapreciable y en Linux todo lo contrario, es a veces hasta exagerado. Quizá se deba al driver de la tarjeta gráfica o a la particular configuración hardware que tengo (escritorio a 1600, pantalla 16:9). Mis historia con los players no acaba aqui: si tengo desconectado el mando a distancia Lirc no se entera cuando lo reconecto, y aunque reinicie el servicio a mano el Mplayer se sigue sin enterar; en ocasiones me sale una franja blanca en la pantalla, en ocasiones pierdo la barra de seek, en ocasiones la pantalla sale en negro y solo puedo oir el audio… todos estos problemas han hecho que siga viendo las series en Windows.

En el apartado sonoro el sistema no sonó hasta que desactive la tarjeta de audio integrada en placa y dejé la Sound Blaster en solitario. Mejor dicho, el sistema sonaba pero los programas no. Había decenas de salidas y configuraciones a elegir pero no tiraba ni una. Amarok ha sido un gran descubrimiento pero tiene una serie de defectos que me fastidian un poco. Por un lado tiene problemas con los tags de wma y APE. Si, ya se que no son formatos libres precisamente pero claro, yo tengo muchas pistas en wma y APE y Amarok se niega a escribir ID3 en ciertos campos de los wma. Los APE ni los huele, el soporte a este formato en Linux es francamente limitado. Peor es que al escribir ID3 en wma no de errores y represente correctamente la colección hasta que cierras y abres el programa, momento en que las cosas retornan al estado anterior al de “escribir· los tags que no le gustan (toda la colección descojonada otra vez). Por otro lado al escribir ID3 sobre grupos de archivos grandes (cientos) en ocasiones falla y se deja algunos por escribir, en otras ocasiones aparece una ventanita diciendo que “los siguientes ficheros no pudieron ser modificados” (aunque la lista siempre aparece vacía). También es muy lento manejando bases de datos largas: uso SQLite porque instalar una base de datos hecha y derecha como MySQL solo para administrar mi colección de música me parece matar moscas a cañonazos, en este sentido Foobar2000 le da mil vueltas, pero de esto hablare en otra entrada. Finalmente, Amarol a veces peta, no se porqué. No me peta el Amarok al copmleto sino algún modulillo suelto (yo no he instalado nada, esta tal y como viene del repositorio); no se exactamente que es todavía, pero me aparece una pantalla típica de KDE diciendo que el modulo tal cual peto y se cerrará. Si mas. Con mucho acceso a disco Amarok es candidato a quedarse “gris” aunque siempre se recupera.

Son ya conocidos los petes de las X sin venir a cuento. Con la 8.04 no me ha pasado todavía, pero con la 7.10 me sucedió media docena de veces: estar tan tranquilo y de repente todas las X se caen (arrastrando a todos los programas que tuviera abiertos claro). No pasa a menudo (ni mucho menos) pero ahí esta. Tambien fastidia salir del sistema y tardar en aparecer 30 segundos la pantalla de logout, reiniciar etc durante los cuales no se puede hacer nada. Esto me pasa en 1 equipo de los 3 curiosamente.

Otras cosas tampoco entiendo: en teoría es un sistema flexible. Tengo configurado el Nautilus para que me muestre el icono de Papelera, Entorno de red y Mi PC en el escritorio. Si navego por Entono de Red (servidores de red mejor dicho) tengo un interface similar al de Windows: me sale el grupo de trabajo Samba, dentro los Pcs, los recursos compartidos etc. Sin embargo no puedo arrastrar el icono de un servidor o recurso compartido al escritorio y que se monte cuando haga click en el. Puedo usar el Nautilus para tener un panel a la izquierda donde efectivamente se me graba un enlace al servidor que automonta el recurso al hacer click pero yo lo tengo configurado para no ver ese panel porque me molesta tenerlo en cada carpeta que abro. Tampoco he conseguido que cuando quito todos los puntos de montaje de un hd entre en suspensión y deje de girar. Con hdparm se podría hacer algo (de hecho lo hago desde rc.local al arrancar el equipo paro los hds que no uso normalmente) pero las soluciones automaticas que se dan en foros son artificiosas: lo ideal seria que se desmontara y entrara en suspension cuando ya no se use.

Brasero es un programa que me duró 3 minutos: lo puse para formatear un dvd-rw en modo completo (15 minutos) y lo terminó en 2 segundos (luego no lo reconocía). K3b es mucho mejor pero no he conseguido grabar un DVD UDF solamente (solo UDF, nada de ISO9660): aunque lo configure para solo UDF al grabar me pone “grabando ISO9660″ (realmente no se que es lo que graba, aunque lo graba bien en el sentido de legible por un lector, pero me jode el despiste porque si los quiero leer con la Xbox es posible que tenga problemas si no están hechos de una forma muy concreta). Grabando DVD-RW es igual o peor que Brasero. No he conseguido grabar un regrabable en Linux.

El otro dia ya fue el colmo y la gota que colmo el vaso: arranque Mplayer y el sistema se colgo al completo. No se movia ni el raton. Reinicie y el panel superior me desapareció. Lo tenia super currado pero voló el desgraciado. Luego me di cuenta que no había volado sino que se había pueso en la parte inferior y el panel de las tareas solapaba al otro. No pude volver a ponerlo arriba, por alguna extraña razón se negaba. Lo he tenido que dejar abajo.

En resumidas cuentas: le falta un par de vueltas (o tres). Como concepto esta bien, pero no más allá. Choca al tratarse de un sistema con tantísimos años de desarrollo encima, pero yo lo achaco principalmente a la forma de evolución que ha tenido: no hay interés en sacar un producto de calidad, solo hay una especie de carrera por ver quien tarda menos en arrancar el sistema, quien hace mas filigranas con las ventanas o quien tiene el uptime mas alargado: son una serie de baremos que se han aceptado y es dificil desprenderse de ellos. Cosas como “entorno intuitivo, correcto feedback al usuario, sistema pulido, flexible en los detalles” pasan a un segundo plano. Ya pasaba lo mismo hace años con las tarjetas gráficas: quien escupe mas poligonos? pues esa es la mejor, como si no hubiera otras cosas. Yo entiendo que a toda esa gente que contribuye gratuitamente con sus desvelos no tenga interés en solucionar los pequeños detalles y pongan todo su ardor en definir una nueva ornada de interfaces para widgets, diseñar un nuevo sistema de ventanas o generar el enésimo lenguaje interpretado que hará las delicias de todos los presentes ante su nueva sintaxis hiper legible, velocidad de ejecución y ridículos consumos de memoria. A mi todo esto me parece muy bien y lo aplaudo, pero por desgracia, en el dia a dia de escritorio, un sistema operativo del 2003 llamado XP, de 32 bits, está mucho mucho más maduro y afinado que el recomendado (que no recomendable) Ubuntu 8.04 de reciente aparición.

Todo lo escrito aquí es un pequeño resumen en realidad, ya que ha habido muchos muchos mas pequeños problemas (llamemosles “incordios”) que dejan un mal sabor de boca, aunque Ubuntu tenga tantas y tantas virtudes y adelantos con respecto al vetusto XP y al infame Vista, del que también hablaré en otra entrada próxima.

Estas son las cosas…

… que tocan las pelotas con el Linux:

“sambehera

January 3rd, 2008, 05:20 AM

this is ridiculous… 5 years and no resolution to long filenames..? we’ve worked on making brilliant effects on compiz fusion but haven’t made gnome truncate long file names? … KDE has been truncating long filenames for quite some time now…”

Aquí mas.

La movidita viene a colación de esto:

Y esto es lo que va a sustituir a Windows? He de reconocer que he elegido el formato ‘compact’ del Nautilus para poder aprovechar un poco mejor el espacio y rebajado el tamaño del icono al 75% ya que tal y como viene por defecto se desaprovecha terriblemente el espacio en el escritorio.

Pues nada, 5 añitos llevan con el tema, que claro, ahora saldrá el otro diciendo que esto es gratis, que si me lo curre yo, que si tal y que si cual. Cosas como estas son las que denotan la poca seriedad en los entornos de escritorio de linux.

Otra por el mismo precio, que no tiene nada que ver, pero me ha dejado sorprendido: actualizo a la version 8.04 (sin errores, todo hay que decirlo, fino fino) y que ven mis ojos? pues que han metido la version beta 5 del Firefox 3… y la mitad de los plugins ya no son complatibles. Cojonuti!! No quiero pensar que hubiera pasado si con el Vista hubieran metido una beta del IE…

Pakito: Recapitulando

Esta entrada valdrá para esclarecer un poco la casuística que rodea, no a la instalación de Pakito, sino a su desempeño, features y todas estas cosas que siempre quedan un poco a la sombra. Las preguntas serían: “es lo mismo que tener un cliente de emule instalado en el PC?, realmente supone un ahorro energético?”

Por una parte las features del interface web son mucho menores que las de su homónimo ’standand-alone’: hay cosas que ya tenemos asumidas en un cliente gráfico de emule como son poder ver las colas de usuarios (y configurarlas), configurar las prioridades de subida y bajada de forma sencilla, ofuscación de protocolo, ip filter para banear aquellos rangos de ips que sepamos pertenecen a empresas que se dedican a envenenar la red emule (fake servers, clientes que publican videos anti-piratería etc), definir “amigos”, mensajería, IRC etc… muchas de estas cosas no se pueden configurar directamente con el interface web o incluso no tienen soporte en absoluto en amuled. Aun así no hay nada que yo haya echado en falta y que sea vital: una de las cosas que más me preocupaba era la ofuscación de protocolo para evitar el trottling de los ISPs, pero amule trae soporte para ello (no asi mldonkey, cosa que lo inutiliza totoalmente en muchos casos). Últimamente varios ISPs están ’shapeando’ conexiones p2p por el drástico método de enviar RSTs a clientes que inicien o mantengan una gran cantidad de conexiones abiertas en puertos no conocidos. Azuerus mantiene una lista de estos IPSs gracias a un plugin que ha sacado para su cliente 3.0 (la lista aquí).

La interface web de amuled es fea de cojones y espartana como pocas. No hay nada de AJAX ni ningún recurso para mejorar un poco el feedback, además añadir e-links es un poco tedioso porque tienes que copiar y pegar el link en el interface web y darle a descargar. Para ver el estado de las descargas hay que refrescar manualmente la página: son los inconvenientes típicos de un cliente web que no aprovecha en modo alguno los adelantos de la web 2.0.

Aun con todo lo indicado anteriormente puedo decir y digo que es un lujazo tener a Pakito entre nosotros: las descargas son muy buenas, con mi linea de 6 Mbits he descargado una media de 7 gigas por día, cosa que no esta nada mal para tratarse del emule (sobre bittorrent ya hablaremos en otra ocasión dado que pertenece a otra liga claramente: no creo que tuviera disco duro suficiente para mantener 1 semana de bittorrent a pleno rendimiento).

Por otro lado el ruido que emite el aparato, aunque claramente audible de noche, es ínfimo: supongo que lo mas ruidoso será el disco duro, que a veces da la impresión de emitir un ruido como de chapoteo líquido =:?? por lo demás lo que mas molesta de Pakito de noche es la luz del led de encendido, que es una autentica linterna azul y que recomiendo enfocar hacia otro lado porque si os da en la cara no vais a poder sobar en condiciones (o ponerle un cartoncillo o algo).

Finalmente consumos: sobre esto podría hacer miles de pajas mentales pero yo creo que lo mas indicado es contrastar los consumos de KiloWatio/h diarios de Pakito con el PC normal de casa. Las condiciones de medición han sido las siguientes:

- Medidor: EMC (ni idea del modelo oiga, es un producto ‘made in liddle’ o como se escriba, hogar de jubilados inadaptados todavía con el hábito de levantarse de la cama demasiado temprano, entre ellos mi progenitor).
- Duración: 8 horas exactas.
- Dispositivos medidos: Pakito y PC (fuente de alimentación de 500W, Intel Core2Duo a 1.67 Ghz, 2 gigas de Ram, 2 HDs SATA, 1 Grabadora DVD-+RW, 2 ventiladores de 12 cm en su interior, caja Antec SOLO, tarjeta grafica Nvidia 7800 sin ventilador). Solo se ha medido el PC, el monitor estaba apagado.

Los resultados son los siguientes:

PC: 0.74 Kw/h al día

Pakito: 0.14 Kw/h al dia

El consumo viene a ser entre 4 y 5 veces menos. Depende del lugar donde hagáis la medición el ahorro sera mayor ya que el KW/h se cobra muy distinto según la provincia (aquí anda por el 0.30 impuestos incluidos) pero la proporcion es esa. No entro en cuanto tiempo se tardaría en amortizar el bitxo porque eso ya varía mucho (hay que tener en cuenta que aunque el 90% del dia el PC esta apagado si es cierto que hay momentos en que los 2 aparatos estan encendidos con lo que el consumo es mayor que antes de traer a Pakito). POr otra parte el desgaste del PC principal será menor, otro punto a su favor.

En resumidas cuentas: buena o muy buena compra. Actualmente tengo rTorrnet con dtach instalado, del cual hablaremos en otro momento, pero también da buenos rendimientos. Por otro lado poder usar un único emule y que cada usuario se baje sus cositas en su propia carpeta compartida es un chollete, que podría verse coronado por un vídeo tipo AppleTV que los pillara por streaming y los pasara por la tele directamente. Eso si que molaría pero tendrá que esperar un tiempo.

Pakito finds Amuled

Vamos allá:

Sobre una Ubuntu Server 7.10 hay que realizar las siguientes instalaciones previas:

apt-get samba open-ssh xinetd build-essential kernel-package libpng12-dev
libgd2-noxpm-dev libcrypto++dev

No se si me he dejado algo, creo que no. Con todo eso vamos a instalar algunas cosas que ahora mismo no se necesitarán pero en breves pondré otra entrada para recompilar el kernel al gusto de EPIA y VIA para intentar rebajar la memoria consumida. Tampoco creo que sea necesario el xinetd (lo instalé para open-ssh pero este servidor no tira de xinetd parece). Samba lo queremos para compartir lo descargado y el resto de cosas las pide el amuled.

Hasta aquí lo que se puede descargar desde repositorios que yo haya probado. A parte hay que descargarse el paquete zlilb desde aquí y el paquete wxWidgets desde acá y los dejamos en la carpeta /root. En ambos casos hacemos un

tar xvf fichero.tar.gz
./configure
make
make install

Con todo este mondongo ya instalado podemos descargar el amuled sin temor a encontrarnos fallos de dependencias. Para ello cogemos el toro por los cuernos y nos bajamos de aqui la última versión CVS que haya y la descomprimimos con tar xvfj fichero.tar.bz2

Ahora nos toca poner los parámetros del ./configure. Estos son los que yo he usado y parecen funcionar:

./configure --enable-optimize --disable-debug --disable-upnp --with-toolkit=base
--enable-amulecmd --enable-webserver --disable-monolithic --enable-amule-daemon

opciones a punta tralla. Recomiendo habilitar el optimize aunque me ha dado warnings a tutiplén cuando compilaba. Quizá algunas cosas queráis quitar: yo no puedo ni ver el uPnP y la info de debug suele ser tan críptica que en general no vale para gran cosa.

Una vez configurado le damos al make y make install. Aquí la cosa se alarga un poco (media hora aprox).

Ahora ejecutamos amuled a palo seco para crear el fichero ~/.aMule/amule.conf donde irá toda la configuración del demonio. Acto seguido ejecutamos amuleweb -w para generar el fichero remote.conf que en estos momentos no tengo muy clara su utilidad (en teoría valdría para configurar el servidor web pero todo se configura desde amule.conf).

Damos de alta una cuenta de sistema para ejecutar amuled con permisos de usuario cutre. Para ello hacemos un adduser amuled, contestamos todas las preguntas y copiamos el contenido completo de /root/.aMule a la carpeta /home/amuled.

Hecho esto vamos a configurar amuled mínimamente para que funcione y levante el servidor web. Para ello editamos el fichero amule.conf y modificamos las siguientes entradas:

En la sección [EMULE]

MaxUpload=30
MaxDownload=500

indicamos el máximo de subida y bajada en Kbytes por segundo

Port=4662
UDPPort=4672

Indicamos los puertos TCP y UDP que habremos redirigido convenientemente en nuestro router.

MaxSourcesPerFile=600
MaxConnections=990

Indicamos las conexiones máximas por fichero y totales. Las conexiones máximas totales no deben de pasar de 1000 porque las librerías utilizadas para todo el tema de red tienen esa limitación; por otro lado tampoco se yo si este hardware aguantaria valores muy altos.

TempDir=/home/amuled/.aMule/Temp
IncomingDir=/home/amuled/.aMule/Incoming

Aquí va el path de los temporales y del Incoming:

OSDirectory=/home/amuled/.aMule/

Este no se para que se usa pero por si acaso modificar.

DownloadCapacity=6000
UploadCapacity=512

Para temas estadísticos se indica el ancho de banda contratado con el proveedor en Kbits (no Kbytes como antes) por segundo.
En la sección [WebServer]

ECPassword= cadena
Enabled=1

Esto habilita el acceso por web y le da una contraseña. Para generar una contraseña hay que convertirla a formato MD5, que se podrá hacer con la siguiente instrucción:

$ echo -n yourpasswordhere | md5sum | cut -d ' ' -f 1

Nos dará un churro de caracteres q pegamos en ECPassword.

El amuled no soporta configurar categorías a través del front-end web asi que hay q ponerlas a piñón en el fichero amuled.conf

Aquí un ejemplo para 3 categorías.

[General]
Count=3
[Cat\#1]
Title=categoria1
Incoming=/home/amuled/.aMule/Incoming/categoria1
Comment=
Color=3329330
Priority=1
[Cat\#2]
Title=categoria2
Incoming=/home/amuled/.aMule/Incoming/categoria2
Comment=
Color=3329330
Priority=1
[Cat\#3]
Title=categoria3
Incoming=/home/amuled/.aMule/Incoming/categoria3
Comment=
Color=3329330
Priority=1

Para tener un directorio de compartidos tenemos que editar el fichero shareddir.dat y añadir entradas de este pelo:

/home/amuled/.aMule/compartir/bso
/home/amuled/.aMule/compartir/music
/home/amuled/.aMule/compartir/pdf
/home/amuled/.aMule/compartir/pelis

No es recursivo como se ve, así q tenemos que ir uno a uno.

Aquí tenemos el script de arranque que pondremos con permisos de ejecución en /etc/init.d. Podemos llamarlo “amuled” por ejemplo

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/local/bin/amuled
WEB=/usr/local/bin/amuleweb
NAME=amuled
DESC=amuled
RUNAMULE=yes
USER=amuled
set -e
case "$1" in
start)
echo -n "Starting $DESC: "
su $USER -c "$DAEMON -f"
while ! netstat -l -n -p -t | grep -q amuled ; do sleep 1 ; done
su $USER -c "$WEB --quiet &"
echo "$NAME."
;;
stop)
echo -n "Stopping $DESC: "
killall --quiet --ignore-case $WEB
killall --quiet --ignore-case $DAEMON
echo "$NAME."
;;
restart|force-reload)
echo -n "Restarting $DESC: "
killall --quiet --ignore-case $WEB
killall --quiet --ignore-case $DAEMON
sleep 1
su $USER -c "$DAEMON -f"
while ! netstat -l -n -p -t | grep -q amuled ; do sleep 1 ; done
su $USER -c "$WEB --quiet &"
echo "$NAME."
;;
*)
N=/etc/init.d/$NAME
echo "Usage: $N {start|stop|restart|force-reload}" >&2
exit 1
;;
esac
exit 0

podemos linkarlo en el runlevel3 si queremos que arranque al iniciar el sistema operativo.

Y esto es todo por ahora. Las conclusiones del sistema vendrán en una tercera entrega.