Explicación de la bomba fork()

Aunque por suerte ya casi todos los sistemas GNU/Linux actuales no se ven afectados por el exploit local que se conocía como la bomba fork(), sí todavía sigue siendo algo de mucho interés: cómo una simple línea capaz de causar una denegación completa de servicio y terminar con los recursos de una máquina.
:(){ :|:& };:
La verdad, es que si vemos la línea tal que así, puede resultar cuanto menos confuso comprender lo que hacer. Es lo bueno de la ofuscación. Así que vamos a desglosarla un poco para poder explicarla, pero sin cambiarle el significado.
bomba_fork() {
   bomba_fork | bomba_fork &
}; bomba_fork
Empleando nombre más descriptivos y usando más de una línea, creo que la cosa ya mejora algo. Esta última función y la anterior son la misma y tiene el mismo efecto, pero una está un poco más clara que la otra y por lo tanto, es más sencilla de explicar.
  • bomba_fork()
    Es el nombre de la función y cómo se define ésta en bash.
    En el código ofuscado, el nombre de la función es ":".
  • bomba_fork
    Es la llamada a la función. Cada vez que escribimos esto, lo que hacemos es una llamada a la función previamente definida y por lo tanto ejecuta lo que hay dentro de la misma.
    Recordar que en el código ofuscado, el nombre de la función es ":".
  • bomba_fork | bomba_fork
    Esta en una llamada a la función y puesto que está dentro de la función es recursiva. Acordaros lo que vimos en el punto anterior, bomba_fork es el nombre de la función, cada vez que la llamemos se ejecuta la función.
    Con el pipe, "|", lo que conseguimos es que en cada llamada a la función se llame a la misma dos veces.
  • &
    Esto hace que la función quede en segundo plano y no se muera, consumiendo recursos de la máquina.
Quizás así ahora esté ya más claro de por qué este código tan simple hace tanto daño. Como vemos, consume recursos infinitamente hasta que estos se agotan, ya que las llamadas recursivas nunca terminan.
Leer más

Restaurar permisos originales de un fichero

¿A quién no lo pasó alguna vez que cambió los permisos de un fichero o directorio completo sin querer y luego no sabía volver a los preestablecidos por el desarrollador?
Supongo que alguna vez ésto nos pasó a todos y no es una buena experiencia. Así que para intentar subsanar este tipo de fallos, hoy os presento un truco muy simple, para sistemas Red Hat y derivados, que permite restablecer los valores originales de forma muy sencilla. Ya bien sea para un fichero concreto o para todo un directorio, gracias a rpm --setperms volver a poner los permisos originales nunca fue tan sencillo.
Vamos a ver el comando en funcionamiento, que es la mejor forma de entender de lo que hablamos.
Partimos de estos permisos originales de un fichero cualquiera.

shell> ls -l /etc/ssh/ssh_config
  -rw-r--r--. 1 root root 2047 may 15  2012 /etc/ssh/ssh_config
y se los cambiamos por estos otros,
shell> chmod 777 /etc/ssh/ssh_config
shell> ls -l /etc/ssh/ssh_config
  -rwxrwxrwx. 1 root root   2047 may 15  2012 /etc/ssh/ssh_config
Como vemos, una equivocación no muy común, pero que en ese fichero puede traer consecuencias inesperadas. Aunque en el ejemplo es muy sencillo volver a los permisos originales, entre otras cosas por que sabemos a que volver, imagina que esto mismo se hiciera recursivo y afectase a todo /etc.
Lo que nos interesa es ver cómo volver a los valores originales del paquete sin tener que hacerlo manualmente. Para ello,
shell> rpm --setperms openssh-clients-5.3p1-81.el6.x86_64
shell> ls -l /etc/ssh/ssh_config
  -rw-r--r--. 1 root root   2047 may 15  2012 /etc/ssh/ssh_config
Y lo único que necesitas saber es el nombre del paquete que contiene el fichero o ficheros que has modificado, para lo cual,
shell> rpm -qf /etc/ssh/ssh_config
  openssh-clients-5.3p1-81.el6.x86_64

La entrada Restaurar permisos originales de un fichero la puedes leer el El mundo en bits.
Leer más

Conseguir permisos para guardar ficheros desde vi

Fijo que no soy al único que le pasa lo de editar un fichero en vi y cuando vas a guardarlo te das cuenta de que no tienes permisos para hacerlo. Si las modificaciones que has realizado son pocas y pequeñas, aun puede no molestar demasiado, pero sino, efectivamente volver a aplicarlas nuevamente esta vez ya con permisos resulta molesto. A la mayoría de los administradores cuando nos sucede esto lo que hacemos es escribir en un fichero temporal los datos y luego "machacar" el original. Por suerte vi para estas cosas nos facilita la vida, y con un simple
:w /tmp/ssh.config
logramos que se guarde en el fichero temporal que deseemos, ya luego es cuestión de mover los datos.
Sin embargo, si estamos editando y obtenemos alguno de estos errores,
W10: Advertencia: cambiando un fichero de sólo lectura 58,1 Final

E45: Está activa la opción 'readonly' (añada «!» para forzar).

E212: No puedo abrir el fichero para escribir en él.
antes de optar por guardar con otro nombre, quizás sea mejor obtener desde vi los permisos necesarios y así evitar la molestia y la inseguridad que puede provocar dejar un fichero de configuración, por ejemplo, en un directorio temporal. Para ello,
:w !sudo tee %
[sudo] password for javier: 

Si te parece útil este truco, úsalo y compártelo!

Leer más

GPG key Error con yum

Aunque este error fue algo esporádico, la verdad es que tiene su lógica y probablemente a vosotros también os haya pasado si habéis creado el fichero de acceso a EPEL directamente y no instalasteis el paquete del repositorio.
Por defecto, el fichero que emplea yum para acceder al repositorio EPEL es /etc/yum.repos.d/epel.repo, el cual contiene una línea similar a la que sigue, que hace referencia a un fichero de clave GPG.
...
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6
gpgcheck=1
Si dicho fichero no existe, no se puede verificar la autenticidad de los paquetes, por lo que el siguiente fallo aparecerá al intentar descargar e instalar algún paquete desde dicho repositorio.
shell> yum update
...
Downloading Packages:
warning: rpmts_HdrFromFdno: Header V3 RSA/SHA256 Signature, key ID 0608b895: NOKEY
Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6

GPG key retrieval failed: [Errno 14] Could not open/read file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6
La solución más sencilla es instalar el fichero del repositorio con el paquete epel-release, que se encargará de crear el fichero del repositorio, localizado bajo /etc/yum.repos.d/ y también el fichero con la clave GPG.
shell> yum install epel-release.noarch
Tras la instalación de dicho paquete, ya no se debería de volver a tener dicho error. Al intentar instalar algo por primera vez desde el repositorio EPEL, nos saldrá el siguiente aviso de empleo de clave GPG.
shell> yum update
...
Downloading Packages:
warning: rpmts_HdrFromFdno: Header V3 RSA/SHA256 Signature, key ID 0608b895: NOKEY
Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6
Importing GPG key 0x0608B895:
 Userid : EPEL (6) 
 Package: epel-release-6-8.noarch (@epel)
 From   : /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6
Is this ok [y/N]: y
Running rpm_check_debug
...
Tras aceptarlo, ya se podrá trabajar con el repositorio EPEL de forma permanente y certificando la autenticidad de los paquetes.
Leer más

Rotar o purgar MySQL error.log

Cuando estás empleando MySQL de forma regular suele suceder que se producen errores, bien en el replicado (si empleas replicación M-M o M-S) o bien cualquier otro error que haga que el servidor de MySQL escriba directamente en el log de error. Cada vez que algo nuevo se escribe, este fichero ocupa un poco más y pasado un tiempo, es lógico que pueda llegar a alcanzar más de 1 Gb. Es por lo tanto buena idea hacer un rotado o purgado del mysql-error.log.
Puesto que lo que menos interesa es parar el servidor, desde la página oficial de MySQL nos dicen cómo hacerlo "en caliente" y de forma segura. Depende mucho de la versión que tengamos instalada, pero para versiones de MySQL superiores a la 5.5.7 la forma es la siguiente,
shell> mv mysql-error.log mysql-error.log.old
shell> mysqladmin -u root -p flush-logs
shell> mv mysql-error.log.old backup-directory
La última sentencia ejecutada, lo que hace es mover el fichero de error a un directorio donde tengamos espacio de almacenamiento. Lógicamente, si lo que deseas es un purgado de dicho fichero, puedes optar por borrarlo libremente.
Leer más

Zabbix: Autenticación local y LDAP

Los temas de autenticación de Zabbix son un poco curiosos y en versiones anteriores a la rama 2.x, una vez que se seleccionase el método de autenticación por defecto, todos los usuarios tenía que hacerlo de esta forma. Esto, aunque podía no suponer un problema, cuando menos sí era molesto. Podía darse el caso de que usuarios tuvieran que tener una cuenta dentro de un LDAP para autenticarse en Zabbix, pero que no perteneciesen a la organización.
Por suerte, desde la versión 2.x, esto cambió y ahora, por defecto todos los usuarios emplean el método de autenticación por defecto, excepto que pertenezcan a un grupo especialmente diseñado para realizar una autenticación local.
Dicho de otro formal, vamos a ver cómo realizar una autenticación mediante LDAP para todos los usuarios, dejando una puerta puerta local abierta al usuario Admin, pues la red puede ser que en alguna ocasión nos de malas pasadas. Lógicamente, quien dice usuario Admin, dice cualquier usuario que se desee para autenticación local.
Los pasos a realizar son los siguientes.
  1. Autenticación LDAP configurada y funcionando
    Si nos sabes cómo hacerlo, puedes ver aquí cómo hacerlo.
  2. Crear un grupo de usuarios de autenticación local
    En este caso hemos optado por crear un grupo de usuarios llamado "Local Users" y la parte importante de este proceso es la definición del "Frontend access" o "Acceso al interfaz web", que tenemos que seleccionar entre la opción por defecto (en este caso LDAP) o la opción de autenticación interna.
    La creación de dicho grupo, se muestra en la imagen.
  3. Añadir los usuarios al grupo "Local Users"
    Todos los usuarios que pertenezcan a este grupo tendrán autenticación local, mientras que el resto no. Autenticación local implica que el usuario tendrá una contraseña y ésta, lógicamente, deberá ser segura.
Si no sabías este truco de Zabbix, espero que te sirva de ayuda.
Leer más

Ocultar los procesos a usuarios

En el último artículo de Debian Administration leo un sorprendente post que habla sobre cómo esconder los procesos a usuarios sin privilegios, mediante un parámetro presente desde el kernel 3.2.
Para hacer este tipo de protecciones la única forma que existía con antelación era emplear utilidades y parches aplicados en el kernel. Por suerte, con las últimas versiones del kernel de Linux, esto ya lo podemos hacer de forma nativa e inmediata, lo cual facilita, y mucho, el trabajo a la hora de proteger y ocultar datos a los administradores de sistemas.

¿Cuándo emplear este truco?

En los equipos de sobremesa habituales, desde luego no tiene sentido hacer este tipo de filtros, pues no es necesario ocultar los proceso de otros usuarios; entre otras cosas, suelen ser mono-usuario.
En servidores, quipos compartidos por varios usuarios a la vez (GNU/Linux es multi-usuario de verdad!) o equipos en los que se están a ejecutar procesos críticos, pues quizás sí tenga más sentido ocultar los procesos que no son del propio usuario. Por qué el usuario X tiene que saber lo que está a ejecutar el usuario Y. Si no interesa que lo sepa, empleamos este truco y listo.

Cómo configurar esta nueva utilidad del kernel

La nueva utilidad descrita está basada en un parámetro, hidepid, que se le pasa como parámetro de montaje a la partición /proc. Los posibles valores que puede tomar son:
  • 0 - Valor por defecto del sistema. Todos los usuarios pueden ver todos los procesos.
  • 1 - Esta opción ya ofrece algo de restricción a lo que un usuario normal puede ver. Ante la salida estándar de "ps aux", por ejemplo, no se pueden ver procesos de otros usuarios, pero bajo /proc todavía puede ver estos procesos.
  • 2 - Esta es la opción más restrictiva. Un usuario normal no puede ver nada que otros estén ejecutando ni siquiera accediendo a la carpeta /proc. Todo está oculto para él.
Y la forma de emplearla es, en tiempo real y sin hacer nada, volver a montar la partición /proc, pasándole como parámetro esta nueva opción.
shell> mount -o remount /proc --options=hidepid=2
Al realizarlo, el cambio es inmediato y según el valor que le pasemos, dentro de los posibles, veremos el resultado en usuarios sin privilegios de root. Por ejemplo, si ejecutamos la línea que os acabo de indicar, cualquier usuario que no tenga permisos dejará de ver todos aquellos procesos que no sean suyos y para él, el servidor sólo ejecutará cosas suyas.
Si nos interesa emplear esta funcionalidad de forma permanente, tendremos que aplicar el cambio en el fichero /etc/fstab y añadir la opción comentada a la partición /proc, tal como sigue.
proc   /proc   proc   defaults,hidepid=2   0   0
Las diferentes salidas se muestran a continuación. La primer, en ejemplo de lo que ve un usuario sin privilegios antes de bloquearle el acceso a los procesos que no son suyos,
javier@shell> ps aux
USER      PID %CPU %MEM   VSZ   RSS TTY  STAT START   TIME COMMAND
root        1  0.0  0.0  2776  2864 ?    Ss   mar12   0:00 /sbin/init
root        2  0.0  0.0     0     0 ?    S    mar12   0:00 [kthreadd]
root        3  0.0  0.0     0     0 ?    S    mar12   0:00 [ksoftirqd/0]
root        4  0.0  0.0     0     0 ?    S    mar12   1:22 [kworker/0:0]
root        5  0.0  0.0     0     0 ?    S<   mar12   0:00 [kworker/0:0H]
root        7  0.0  0.0     0     0 ?    S    mar12   0:00 [migration/0]
...
Y a continuación, el mismo usuario una vez pasada la opción hidepid=2.
javier@shell> ps aux
USER      PID %CPU %MEM  VSZ   RSS TTY  STAT START   TIME COMMAND
javier   2589  0.0  0.0 3352  7876 ?    Ssl  mar12   0:00 x-session-manager
javier   2649  0.0  0.0 4444   500 ?    S    mar12   0:00 /usr/bin/dbus...
javier   2650  0.0  0.0 1856  2048 ?    Ss   mar12   0:09 //bin/dbus-...
javier   2661  0.0  0.0 9360  2548 ?    S    mar12   0:00 /usr/lib/x86...
javier   2665  0.1  0.2 3284 17076 ?    S    mar12   5:12 xfwm4
javier   2669  0.2  0.2 2584 20508 ?    Sl   mar12   7:34 xfce4-panel
...
Sin dudarlo, una opción muy interesante para equipos compartidos que debería de estar presente en muchos, por no decir todos los servidores de producción. 

Referencia: debian-administration.org
Leer más

Yum, Metadata file does not match checksum

Hoy tuve una mala experiencia con yum. Necesitaba instalar unos paquetes y como siempre, en el peor momento, el mejor error. El detalle vino al intentar actualizar el listado de paquetes disponibles que tenía el servidor remoto (en este caso epel). Tras descargar la base de datos, al hacer la comparación daba un error de checksum: Los datos no coinciden!.
shell> yum install php-pdo.x86_64
...
epel/pkgtags                                       | 996 kB     00:01
http://...: [Errno -1] Metadata file does not match checksum
Trying other mirror.                               | 997 kB     00:00
epel-testing/pkgtags                               | 996 kB     00:01
http://...: [Errno -1] Metadata file does not match checksum
Este fallo se produce en numerosas ocasiones en sistemas RedHat, CentOS y Fedora, principales distribuciones basadas en RPM. El error que obtenemos, nos indica que la versión del fichero que tenemos cacheada no coincide con la versión que estamos descargando. Existen por lo tanto dos soluciones: La primera, esperar a que se caduque la caché local, lo que hará el purgado automático de dicho fichero. La segunda, forzar la limpieza de la caché con,
shell> yum clean all
Y tras ello ejecutar nuevamente el comando. Descargará todos los ficheros completos, lo que puede llevarle un tiempo si tenemos muchos repositorios, pero habremos solucionado el problema.
shell> yum install php-pdo.x86_64
...
epel/metalink                                      |  23 kB     00:00
epel                                               | 4.2 kB     00:00
epel/primary_db                                    | 6.0 MB     00:00
epel-testing/metalink                              |  23 kB     00:00
epel-testing                                       | 4.2 kB     00:00
epel-testing/primary_db                            | 405 kB     00:00
Setting up Update Process
Resolving Dependencies
...

La entrada Yum, Metadata file does not match checksum la puedes leer en El mundo en bits.
Leer más

Disponible Xen 4.4

Tras 8 meses de intenso desarrollo la comunidad de Xen anunció la tan esperada nueva release: Xen Project Hypervisor version 4.4. En sacar esta nueva versión, colaboraron empresas tales como AMD, Intel, Oracle y por supuesto Citrix.
La nota con todos los cambios y mejoras efectuados la puedes leer aquí, pero los más destacados son:
  • Soporte grub2 para Xen Project PV Images
  • Soporte experimental para EFI boot
  • Integración entre GlusterFS y Xen
  • Soporte de entornos móviles y mayor integración "en la nube"
  • Soporte para arquitecturas ARM
    • Hipervisor ABI para ARM finalmente estable
    • Disponibilidad de sistemas de 64 bits sobre plataforma ARM
    • Soporte LVM sobre plataforma ARM
Más información en la web oficial: www.xenproject.org
Leer más

Ahorrar espacio en git

git, del que ya comentamos cosas más de una vez, es fantástico a la hora de gestionar un proyecto con varias ramas y muchos cambios, pero tiene un curioso problema, el espacio que puede llegar a ocupar un repositorio. Bajo la carpeta del repositorio están almacenados todos los cambios y todas las ramas, para poder acceder a cualquier versión preliminar y esto, lógicamente, ocupa espacio.
Por poner un ejemplo claro, de un repositorio que tengo actualmente está ocupando 90Mb, mientras que si sumas todos los ficheros que forman parte del repositorio su tamaño ronda aproximadamente los 50Mb. Una diferencia de casi 40Mb es espacio extra que está ocupando. Cierto es que con los discos actuales no es un problema, pero aun así es bueno saber cómo poder optimizar este espacio.
Por suerte git tiene un comando para ello, gc (garbage collector), que no es más que un pequeño "recolector de basura", al más puro estilo java, que se encarga de eliminar todos aquellos objetos que son inalcanzables. Aunque se supone que git realiza esta tarea automáticamente si lo considera oportuno, también podemos forzar dicho purgado de forma manual.
Es importante saber que ningún objeto que sea alcanzable será borrado, sino que se borrarán branches, tags, entradas de logs, blobs, trees y objetos que hacen referencia a parent commits, pero que no sean alcanzables desde ningún punto. A mayores de la recolección de basura, gc también se encarga de organizar y empaquetar todos los objetos en un único archivo usando delta compression1 .
En un ejemplo de uso, mi repositorio pasó de ocupar 90Mb a 80Mb sin perder ningún dato de interés. No es mucho, pero siempre puede ser interesante para ahorrar espacio.
shell> du -sh proyect_1
90M proyect_1/

shell> cd proyect_1

shell> git gc
Counting objects: 7503, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3783/3783), done.
Writing objects: 100% (7503/7503), done.
Total 7503 (delta 4257), reused 6237 (delta 3398)

shell> cd ..

shell> du -sh proyect_1
80M proyect_1/

1. Método de compresión optimizado para snapshots con pequeñas diferencias entre ellos.

La entrada Ahorrar espacio en git la puedes leer en El mundo en bits.
Leer más

Debian squeeze: Error de GPG

La semana pasada se descubrió un interesante y grave fallo de seguridad en el paquete OpenSSL. Existía una función con la palabra reservada goto que podía aprovecharse para hacer cosas extrañas y entre otras, crear certificados SSL no válidos.
La verdad es que la primera vez que lo leí, me quedé bastante sorprendido, pues hacía años que no veía el goto, muy famoso en lenguajes deprecated, como pueden ser Pascal o Cobol. Pero cierto es que se usa también en lenguajes como C. Una vez apareció el bug, presente desde 2005, y la forma de explotarlo, era lógico que alguien lo hiciera. Imaginaros la sorpresa, y susto, que llevé cuando una buena amiga me pasa este fallo que le estaba dando una debian al intentar actualizar el listado de paquetes.
shell> apt-get update
...
W: Error de GPG: http://ftp.es.debian.org squeeze-updates Release: Las firmas siguientes no se pudieron verificar porque su llave pública no está disponible: NO_PUBKEY 8B48AD6246925553
Lo primero que pensé, alguien accedió a los servidores de es.debian.org y está haciendo cosas raras. Ya bien hayan sido hackeados o bien alguien haya conseguido redireccionar todo el tráfico a otras máquinas. Por suerte, emplear paquetes firmados sirve de algo. Después de una búsqueda inicial y observar que el certificado de es.debian no había sido violado, tocaba arreglar el problema. Instalar paquetes desde servidores que no confías no es buena idea.
Comenzamos viendo el listado repositorios que tenía el servidor configurados.
shell> cat /etc/apt/sources.list
deb http://ftp.es.debian.org/debian/   squeeze main
deb http://security.debian.org/        squeeze/updates main
deb http://ftp.es.debian.org/debian/   squeeze-updates main
Los servidores era buenos y estaban bien. No había nada extraño y desde el equipo contestaba la IP que era de esperar a dicho DNS. Entonces, ¿qué es lo que podía estar pasando?
Se me ocurrió entonces ver dentro de los paquetes instalados, la versión del paquete de llaves de debian que tenía instalado. Por suerte, no hacía mucho que había actualizado un equipo a squeeze y me acordaba que ese paquete se había actualizado con nuevas claves. Así que antes de seguir pensando que hay algo extraño, vamos a lo sencillo,
shell> dpkg -l |grep debian-archive-keyring
ii  debian-archive-keyring  2010.08.28  GnuPG archive keys of the Debian
He aquí el problema. La versión del paquete que está instalada no es la última. Cuando alguien actualizó ese sistema a squeeze se olvidó de actualizar uno de los paquetes más importantes. Concretamente el paquete con las nuevas llaves de los servidores. Al usar las llaves antiguas, apt daba error de clave desconocida, pues efectivamente no tenía la correcta. Para solucionarlo, actualizamos el paquete debian-archive-keyring.
shell> apt-get install debian-archive-keyring
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias       
Leyendo la información de estado... Hecho
Se actualizarán los siguientes paquetes:
  debian-archive-keyring
1 actualizados, 0 se instalarán, 0 para eliminar y 96 no actualizados.
...
gpg: Cantidad total procesada: 7
gpg:               importadas: 2  (RSA: 2)
gpg:              sin cambios: 5
gpg: no se encuentran claves absolutamente fiables
Tras actualizar el paquete a su última versión, apt ya no da error y el funcionamiento es el esperado, ya que las claves GPG son reconocidas.
shell> apt-get update
...
Descargados 7137 kB en 4seg. (1622 kB/s)                       
Leyendo lista de paquetes... Hecho
Lo que fue un susto inicialmente, quedó en una breve anécdota y únicamente hizo falta actualizar uno de los paquete más sencillos y a la vez más importantes del sistema. Lo que sí, casualidades de la vida, justo pasó en el momento más inoportuno con un fallo que podía haber puesto en jaque a numerosos sistemas.
Leer más

Añadir aplicación al inicio de sesión

La última actualización de XFCE bajo Linux Mint hace que determinados programas que tengo abiertos en la sesión no se inicien cuando vuelvo a arrancar. Esto no me supone un problema, la verdad, pero ya puestos a hacer las cosas bien, lo lógico es que sí arranque, así que me puse a investigar cómo añadir o quitar un programa en el arranque de la sesión.
Como era de esperar, desde XFCE dan la posibilidad de hacerlo de forma gráfica. En "Inicio"/Configuración/Sesión e inicio tenemos una ventana similar a la que se muestra a continuación. Desde ella es posible añadir fácilmente aplicaciones al inicio de la sesión.
Aunque siempre puede interesarnos automatizar este tipo de aplicaciones en varios sistemas al mismo tiempo, o definir más opciones de arranque en las aplicaciones. Para eso, la mejor opción es siempre ir al fichero nativo y crearlo/editarlo. En el caso que nos atañe, la ruta completa de las aplicaciones de arranque es /etc/xdg/autostart/. Ahí hay un listado de aplicaciones, más de las que salen desde el interfaz gráfico. Esto es por que una de las opciones que pueden tener estos ficheros es NoDisplay, que indica si se debe mostrar o no dicha aplicación.

Añadir aplicación al inicio de sesión

Esto es realmente lo que nos interesaba, saber cómo hacer para añadir un nuevo programa al inicio de sesión. Para ello, simplemente en la ruta de la que hablamos es necesario crear un nuevo fichero de extensión .desktop. Por ejemplo, para iniciar Pidgin, es necesario crear el fichero pidgin.desktop con el siguiente contenido,
[Desktop Entry]
Type=Application
Terminal=false
Name=Pidgin Internet Messenger
Comment=Chat over IM.  Supports AIM, Google Talk, Jabber/XMPP, MSN, Yahoo and more
Exec=pidgin
StartupNotify=true
OnlyShowIn=XFCE;GNOME;Unity;MATE;KDE;
Icon=pidgin
Como veis, es un fichero simple pero con muchos parámetros. Saber de la existencia de estos ficheros, contenido y cómo manejarlos puede resultar útil, especialmente si estamos en entornos de muchos equipos manejados con puppet o saltstack. Con crear un nuevo fichero, todos arrancarían Pidgin en el inicio de sesión, por ejemplo.
Si por ejemplo no nos interesa que se pueda ver desde el interfaz gráfico y por lo tanto el usuario no lo pueda desactivar añadimos,
NoDisplay=true
Y en caso de que queramos que únicamente arranque Pidgin, o el software que sea, únicamente para el escritorio XFCE, modificamos la línea OnlyShowIn
OnlyShowIn=XFCE;
Nota: El parámetro Exec lleva todos los parámetros de inicio del comando.

La entrada Añadir aplicación al inicio de sesión la puedes leer en El mundo en bits.
Leer más

Montar LVM desde LiveCD

Ya hemos comentado en varias ocasiones cómo manejar volúmenes LVM en el sistema y poder hacer cosas más que interesantes con ellos. Sin embargo, hay una cosa de la que nunca hablamos, cómo acceder a dichos volúmenes si el sistema que empleamos no es el de la instalación.
Esto no suele ser muy habitual, pero si tenemos la necesidad de arrancar el sistema desde un livecd, por ejemplo, los discos normales, /dev/sda1, por ejemplo, se suelen montar de forma automática, mientras que los volúmenes LVM no lo suelen hacer. El principal motivo por el que pasa esto es por que el sistema del CD no suele traer soporte para LVM. Así que vamos a describir los pasos para darle soporte y montar nuestras particiones.


  • Instalando herramientas LVM
    Lo primero que necesitamos es instalar las herramientas para trabajar con LVM en caso de que el sistema no las traiga. Si usamos un live basado en Debian, emplearemos directamente apt.
    shell> apt-get install lvm2
    
    Todos los paquetes que acabamos de instalar son un añadido al sistema. Estos se almacenan en memoria y por lo tanto, una vez reiniciado, desaparecerá. Si volvemos a arrancar desde el livecd necesitaremos volverlos a instalar.
  • Buscando los volúmenes
    Una vez tengamos ya el soporte LVM, necesitamos forzar un escaneo de los grupos de volúmenes (herramienta vg*). Aquí ya nos tendría que aparecer el volumen que tiene el sistema original.
    shell> vgscan 
      Reading all physical volumes.  This may take a while...
      Found volume group "vg0_samsung" using metadata type lvm2
    
  • Buscando los dispositivos
    Ya tenemos acceso a las particiones, y las podemos listar.
    shell> lvdisplay
      --- Logical volume ---
      LV Path                /dev/vg0_samsung/home
      LV Name                home
      VG Name                vg0_samsung
      LV UUID                V10K7C-MeqC-ApXw-TUIA-...
      LV Write Access        read/write
      LV Creation host, time samsung, 2013-11-29 10:12:42 +0100
      LV Status              NOT available
      # open                 1
      ...
    
    El problema ahora está en que no están disponibles para poderlas montar. Para hacerlo, necesitamos forzar su estado a "available". Lo haremos tal que así,
    shell> vgchange -a y
      1 logical volume(s) in volume group "vg0_samsung" now active
    
    shell> lvdisplay
      --- Logical volume ---
      LV Path                /dev/vg0_samsung/home
      LV Name                home
      VG Name                vg0_samsung
      LV UUID                V10K7C-MeqC-ApXw-TUIA-...
      LV Write Access        read/write
      LV Creation host, time samsung, 2013-11-29 10:12:42 +0100
      LV Status              available
      # open                 1
      ...
    
Llegados a este punto ya tememos acceso a las particiones LVM y lo más probable es que el sistema las monte automáticamente. En caso contrario lo tendremos que hacer con mount.

La entrada Montar LVM desde LiveCD la puedes leer en El mundo en bits.
Leer más

Error: Queue report unavailable - mail system is down



Zimbra suele ser muy poderoso y prácticamente todo se puede hacer desde su interfaz web o de forma bastante sencilla desde la línea de comandos. Pero como todos los softwares grandes, siempre puede tener algún fallo.
Hoy quiero hablar del error que da título a esta entrada. No es algo habitual ni mucho menos, por suerte, pero puede que os haya pasado y la primera vez, cuesta un poco ver el fallo. Tenemos el error de que nuestro servicio postfix no se está ejecutando y por lo tanto no hay correo entrante ni saliente. Eso ya de por sí es un problema. El otro, es que ante la siguiente ejecución, todos los servicios están correctos,

shell> zmcontrol status
Host localhost
   antispam          Running
   antivirus         Running
   convertd          Running
   ldap              Running
   logger            Running
   mailbox           Running
   mta               Running
   opendkim          Running
   proxy             Running
   snmp              Running
   spell             Running
   stats             Running
   zmconfigd         Running
El sistema nos dice que todo está correcto, pero algo no funciona. Vamos a echarle un vistazo a los puertos abiertos de nuestro equipo. postfix emplea el 25, así qué...
shell> netstat -punta | grep 25
tcp   0   0 0.0.0.0:7025   0.0.0.0:*   LISTEN   -
Efectivamente, el sistema nos dice que el servicio MTA está levantado, pero en realidad está caído. Toda ahora ensuciarse un poco más, así que vamos a los logs
shell> tail -f /var/log/mail.log
...
Feb 08 19:31:15 zcs postfix/postqueue[9529]: fatal: Queue report unavailable - mail system is down
Bien, tenemos el maravilloso fallo. Ya sabemos que el sistema no arranca por que algo está fallando.

¿postfix está arrancado, pero a la vez no está disponible?

El problema es que en la última parada del sistema, ya bien fuese ordenada o bien por un apagón, se os quedó por ahí colgado el fichero de PID que indica que el servicio está arrancado. Al realizar un start o un status del mismo, para el sistema sí está arrancado, pero en realidad esto no es así. Zimbra cree que está funcionando, pero no lo está. La solución, por suerte es sencilla,
shell> locate master.pid
/opt/zimbra/data/postfix/spool/pid/master.pid
shell rm /opt/zimbra/data/postfix/spool/pid/master.pid
Y ahora ya podemos arrancar el MTA que estaba fallando,
shell> zmmtactl start
Rewriting configuration files...done.
Starting saslauthd...already running.

La entrada Error: Queue report unavailable - mail system is down la puedes leer en El mundo en bits.
Leer más

Formulario de contacto

Nombre

Correo electrónico *

Mensaje *

Últimos comentarios