Comandos interesantes, dtrx

Hoy es uno de estos días en los que te das cuenta de que GNU/Linux puede ser bueno y simplificarte la vida. También puede ser el día en el que te des cuenta de que vas mayor y ya no quieres acordarte de los parámetros que le pasas a un comando. Sea como sea, hoy voy a hablar del comando dtrx. Quizás alguno ya lo conozcáis, y otros todavía no. dtrx descomprime o extrae los fichero de un número muy grande de formatos. En la versión 6.6, soporta tar, zip, cpio, rpm, deb, gem, 7z, cab, rar, gzip, bzip2, lzma, compress and InstallShield. Como veis una gran cantidad de formatos que muchas veces tenemos que andar recordando cómo se hace. Gracias a dtrx esto ya no será necesario.
Para usarlo, nada más simple que,
shell> dtrx zabbix-2.0.8.tar.gz
Por defecto y si no le pasamos parámetros detecta el tipo de fichero y lo descomprime. En caso de que le pasemos como parámetro la opción -l/-t, podemos sacar un listado de los ficheros que están dentro del contenedor, sin extraer su contenido.

Sin duda, uno de esos comandos que te simplifican la vida.

La entrada Comandos interesantes, dtrx la puedes leer en Puppet Linux.
Leer más

kUbuntu VirtualBox Guest additions fail

Por motivos que todavía desconozco muy bien, terminé instalando un sistema kUbuntu en una máquina virtual. Si bien es cierto que fui usuario de KDE, hace años que lo dejé de lado, ya que cada vez cargaba más y más la máquina, para sacar el mismo provecho que XFCE.
El caso es que tras instalar la máquina, decidí instalar las Guest additions de VirtualBox para que vaya más fluida y pueda intercambiar datos de forma rápida y sencilla con el host anfitrión. Tras hacerlo (y por lo que parece todo terminar correctamente), reinicio la máquina tal como indican las instrucciones y al volver al sistema, no es lo que esperaba, los servicios se han instalado, pero no arrancan. El módulo del kernel no está cargado y además no se puede cargar. Si intento forzar el arranque obtengo lo siguiente:
shell> /etc/init.d/vboxadd start
Starting the VirtualBox Guest Additions ...fail!
(modprobe vboxguest failed)

shell> modprobe vboxguest
FATAL: Module vboxguest not found.
Esto no es desde luego lo esperado. El sistema tiene instalado el software, pero no funciona. Lo vuelvo a instalar y pasa exactamente lo mismo. Está claro que el fallo viene de otro lugar.
La ejecución de VBoxLinuxAdditions.run no está, lo que se dice precisamente depurada, y aunque falten un buen puñado de paquetes instalados, no avisa y lo que es peor, termina aparentemente bien. La solución,
shell> apt-get install dkms
shell> apt-get install build-essential
Tras la instalación de estos paquetes, volvemos a lanzar el instalador de las Guest additions.
shell> ./VBoxLinuxAdditions.run
Y ahora ya podéis reiniciar el sistema y debería de funcionar correctamente :-)

La entrada kUbuntu VirtualBox Guest additions fail la puede leer en Puppet Linux.
Leer más

Importante vulnerabilidad en Zimbra

Llevo unos 15 días bastante ocupado, por lo que las lecturas educativas de noticias se ha reducido y mucho.
Ayer me entero, gracias a @susibarreras, de una importante vulnerabilidad en Zimbra que según lo que apuntan, se descubrió a principios de este mes. Luego realmente, y según los responsables de Zimbra, dicha vulnerabilidad ya fue reportada hace tiempo (Febrero 2013) y todo parece ser así, ya que desde la versión 8.0.3 en adelante está corregida.
El problema radica en todas aquellas versiones no actualizadas. Se estima que cerca del 80% son vulnerables en la actualidad. El fallo es un LFI (Local File Inclusion) sobre una URL a la que cualquier persona puede acceder y descubrir así las credenciales del servidor sobre el que lance la consulta, ya que de forma muy simple se puede leer el archivo localconfig.xml de Zimbra (credenciales de acceso).

La vulnerabilidad saltó al público de manos de rubina119, que publicó un pequeño código Ruby que se aprovecha de dicha vulnerabilidad.

El LFI se produce sobre el fichero
/res/I18nMsg,AjxMsg,ZMsg,ZmMsg,AjxKeys,ZmKeys,ZdMsg,Ajx%20TemplateMsg.js.zgz
y cualquier persona puede acceder, a la siguiente URL
/res/I18nMsg,AjxMsg,ZMsg,ZmMsg,AjxKeys,ZmKeys,ZdMsg,Ajx%20TemplateMsg.js.zgz?v=091214175450&skin=../../../../../../../../../opt/zimbra/conf/localconfig.xml
y observar todas las credenciales del servidor. Gracias al exploit, crear una cuenta de usuario válida es muy sencillo.

Se recomienda una actualización urgente de todos los servidores Zimbra afectados.

Más información:
exploit-db.com
Leer más

Optimización de Linux con discos SSD

Hace poco adquirí un nuevo portátil, con disco SSD. Era uno de los pocos requisitos, pero casi indispensable para la compra. El precio era la otra gran incógnita.
Tras la instalación del nuevo sistema operativo, en este caso opté por una Linux Mint (XFCE Edition), pude probar de primera mano la velocidad de esta nueva tecnología. Sorprende!
El gran problema de la tecnología SSD es que tiene un límite máximo de escrituras y es por ello que hay que cuidarlo diariamente. Cuando más podamos reducir las escrituras, mejor.
Otro de los aspectos a tener en cuenta es el cambio radical del acceso a disco. Ahora el acceso es directo (al igual que en un pen drive) y no depende de una cabeza lectora. Por lo tanto, el algoritmo de optimización de escritura, que traen todos los kernel's puede ya no ser útil. Es por ello, que en este artículo voy a describir los pasos que seguí a la hora de optimizar la instalación.
  1. Uso de TRIM
    TRIM es una orden especial para trabajar con discos SSD que permite al SO comunicarle al disco qué bloques ya no están en uso, para poder marcarlos como libres. El propósito de esta instrucción es mantener la velocidad del disco durante toda su vida.
    Lo primero que tenemos que saber es si nuestro disco soporta este tipo de tecnología. Se presupone que sí, pero mejor garantizarnos. Para ello,
    shell> hdparm -I /dev/sda | grep TRIM
      *  Data Set Management TRIM supported (limit 8 blocks)
    
    Con usa salida similar a esta, significa que tenéis soporte TRIM. Ahora debemos de montar cada partición que esté sobre el disco SSD con la opción discard. Para ello, editamos el fichero fstab y añadimos y cambiamos las líneas implicadas (ajustar a cada disco y cada partición como corresponda)
    /dev/sda1  /  ext4  errors=remount-ro  0  1
    
    por
    /dev/sda1  /  ext4  discard,errors=remount-ro  0  1
    
  2. Optimización de /etc/fstab
    A mayores de los cambios de discard, en el fichero fstab también podemos tener otro tipo de optimizaciones, como las que suponen noatime y nodiratime. Ambas evitan que se escriban los datos de acceso a ficheros y directorios cada vez que estos se producen. Para un equipo de sobremesa o un portátil, es una buena idea, puesto que no nos interesa tener estos datos.
    /dev/sda1  /  ext4  noatime,nodiratime,discard,errors=remount-ro  0  1
    
    Este cambio, con la mayoría de programas no supone problema alguno. Quizás haya alguno que sí necesite tener estos datos escritos. Si es así, entonces podemos pensar en cambiar ambas opciones por "norelatime", que sí escribe los datos, pero no cada momento que se producen.
  3. Deshabilitando el uso de SWAP
    Con la cantidad de RAM que actualmente traen los equipos, mínimo hablamos de 4Gb de RAM, sino más, es lógico pensar que no se vaya a usar la SWAP. Si optaste por crear una partición SWAP, vamos a desactivarla para que no se use. En caso de que sea necesario su uso en un futuro, el cambio es fácilmente reversible. En el fichero, /etc/sysctl.conf agregamos la línea
    vm.swappiness=0
    
  4. Aprovechamiento de la RAM
    Sí, vamos a optar por llevar todos aquellos directorios temporales sobre los que se hacen muchas pequeñas escrituras a la RAM. Esto hará que se hagan más rápido y también que no se emplee el disco para datos temporales. Esta opción es realmente aplicable a cualquier sistema con mucha RAM, ya que siempre es más rápida que el disco.
    Yo personalmente opté por dejar en memoria los directorios /tmp, /var/tmp y /home/USER/.cache, los que más datos temporales suelen tener. Para ello, escribí en el fichero /etc/fstab lo siguiente.
    tmpfs  /home/javier/.cache  tmpfs  size=1024M,mode=777   0  0
    tmpfs  /tmp                 tmpfs  noatime,mode=1777     0  0
    tmpfs  /var/tmp             tmpfs  noatime,mode=777      0  0
    
    Los directorios que querráis poner en RAM ya es cosa vuestra, simplemente tener en cuenta cuando el equipo se apaga, esos datos se pierden. Leí artículos que hablaban de llegar a poner /var/log en RAM y también los directorios de lock y run. Personalmente esos datos a mi me interesa tenerlos, así que no los pasé a RAM.
  5. Modificar cola de escritura en disco
    Otro de los grandes cambios, y ya el último, es cambiar el plafinicador de escritura a disco. Vamos a pasar de tener el por defecto, deadline a noop.
    shell> cat /sys/block/sdX/queue/scheduler 
    noop [deadline] cfq
    
    Para ello editamos el fichero /etc/default/grub y dejamos la línea tal como sigue,
    ...
    GRUB_CMDLINE_LINUX="elevator=noop"
    ...
    
    Y a continuación, actualizamos el grub para que recoja los cambios.
    shell> update-grub
    
Con todo esto, lo mejor es reiniciar ahora el equipo, para que arranque con todos los cambios. Tras el obligado reboot, tendremos el sistema tal que así,
shell> cat /sys/block/sda/queue/scheduler 
[noop] deadline cfq

shell> mount
/dev/sda1 on / type ext4 (rw,noatime,nodiratime,discard,errors=remount-ro)
tmpfs on /tmp type tmpfs (rw,noatime,mode=1777)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
tmpfs on /var/tmp type tmpfs (rw,noatime,mode=777)
tmpfs on /home/javier/.cache type tmpfs (rw,size=1024M,mode=777)
Y el sistema debería de hacer menos escrituras en disco e ir realmente bien.

Leer más

Formulario de contacto

Nombre

Correo electrónico *

Mensaje *

Últimos comentarios