FranGarcia.me (Posts about tips)

Satellite 6.2 : Pruning mongodb database

Fran Garcia — Sat, 29 Jul 2017 16:22:20 GMT

Satellite 6 uses a MongoDB database to keep track, among other things, which RPMs compose a certain content view, etc. As the Satellite gets used and CVs are created and deleted, it can leave some old data around.

A way to trim that data can be achieved with the MongoDB built-in tools, mongod. Note that you will need as much free space as your database uses at the moment, plus a couple of GB. You can check the MongoDB documentation for more details:

https://docs.mongodb.com/v2.6/faq/storage/#how-do-i-reclaim-disk-space

This can help improve content view promotion time among other tasks.

The process would be:

Stop Satellite services with katello-service stop .
Backup your MongoDB ; a tar would suffice or use katello-backup .
Launch the repair: mongod --dbpath {{ mongodb_path }} --repair
Start services with katello-service start .

This can reduce MongoDB database size up to 50% and halve publication time :-)

Happy hacking!

Satellite 6: Force repository download

Fran Garcia — Mon, 15 May 2017 13:51:41 GMT

As a part of the Satellite 6.2.9 release, it is now possible to force a re-download of a certain repository.

This is a big help to fix the following scenarios:

Missing/broken on-disk RPM files due to human error, bitrot, others.
Restoring a Satellite without the Pulp data.

The resynchornization can be launched with :

# hammer repository list --organization "Example"
# hammer repository synchronize --validate-contents=true --id=42

Alternatively a full RPM spool check can be triggered with :

# foreman-rake katello:validate_yum_content --trace

There is further information in the following KCS note.

Happy hacking!

Taming PackageKit's disk usage

Fran Garcia — Sun, 30 Apr 2017 12:36:58 GMT

PackageKit is is a D-Bus abstraction layer that allows the session user to manage packages in a secure way using a cross-distro, cross-architecture API.

To me is more a space hog that caches all available RPM updates of my installed software, with no reasonable way of getting them cleaned/expunged.

There are a few bugs still opened for F24 and F25 on its default behaviour and while no consensus has been reached, I was still in need of a way to trim the usage of my /var/cache/PackageKit directory.

The long term solution is apparently to just disable the software updates via Gnome's gconf :

$ gsettings get org.gnome.software download-updates
true

$ gsettings set org.gnome.software download-updates false

$  gsettings get org.gnome.software download-updates
false

This will only affect future downloads; it does not take care of actually cleaning the currently cached packages. The pkcon tool should take care of this:

# pkcon refresh force -c -1
Refreshing cache              [=========================]         
Loading cache                 [=========================]         
Downloading repository information[=========================]         
Loading cache                 [=========================]         
Downloading repository information[=========================]         
Loading cache                 [=========================]         
Downloading repository information[=========================]         
Loading cache                 [=========================]         
Downloading repository information[=========================]         
Loading cache                 [=========================]         
Downloading repository information[=========================]         
Loading cache                 [=========================]         
Downloading repository information[=========================]         
Loading cache                 [=========================]         
Downloading repository information[=========================]         
Loading cache                 [=========================]         
Downloading repository information[=========================]         
Loading cache                 [=========================]         
Downloading repository information[=========================]         
Loading cache                 [=========================]         
Downloading repository information[=========================]         
Loading cache                 [=========================]         
Downloading repository information[=========================]         
Loading cache                 [=========================]         
Finished                      [=========================]

... however it seems it only cleans old information partially. In the end I ended up going through the drastic method and just sudo rm -rf /var/cache/PackageKit/* .

Happy hacking!

Listing Hypervisors and VMs in Red Hat Satellite

Fran Garcia — Wed, 12 Apr 2017 06:55:33 GMT

One of my current pet peeves in Satellite is getting a list of Hypervisors and their associated VMs. This is specially helpful for trouleshooting virt-who or performing general Satellite clean up tasks.

With the snippet below we can get a list of all hypervisors configured in Satellite:

Additionally, virt-who created entities are usually named virt-who-UUID-1 or virt-who-HypervisorHostname-1. In order to easily identify them in the Satellite Web UI, the following filter can be used as a search pattern:

name ~ "virt-who-%-%-%"

Happy hacking!

Truco: Seleccionar el navegador predeterminado

Fran Garcia — Thu, 09 Oct 2014 23:29:00 GMT

Si queremos configurar el navegador predeterminado del escritorio, hay una herramienta muy útil llamada xdg-settings.

Las opciones para cambiarlo son:

$ xdg-settings --list
Known properties:
default-url-scheme-handler Default handler for URL scheme
default-web-browser Default web browser

$ xdg-settings get default-web-browser
midori-private.desktop

$ xdg-settings set default-web-browser firefox.desktop

$ xdg-settings get default-web-browser
firefox.desktop

Esto es válido en Fedora, Debian, tanto para XFCE como Gnome. El paquete que provee este ejecutable es xdg-utils, que da esta información :

Name : xdg-utils
Summary : Basic desktop integration functions
URL : http://portland.freedesktop.org/
License : MIT
Description : The xdg-utils package is a set of simple scripts that provide basic
: desktop integration functions for any Free Desktop, such as Linux.
: They are intended to provide a set of defacto standards.
: This means that:
: * Third party software developers can rely on these xdg-utils
: for all of their simple integration needs.
: * Developers of desktop environments can make sure that their
: environments are well supported
: * Distribution vendors can provide custom versions of these utilities
:
: The following scripts are provided at this time:
: * xdg-desktop-icon Install icons to the desktop
: * xdg-desktop-menu Install desktop menu items
: * xdg-email Send mail using the user's preferred e-mail composer
: * xdg-icon-resource Install icon resources
: * xdg-mime Query information about file type handling and
: install descriptions for new file types
: * xdg-open Open a file or URL in the user's preferred application
: * xdg-screensaver Control the screensaver
: * xdg-settings Get various settings from the desktop environment

Ya no perderé el tiempo buscando entre confusos menús gráficos :-)

Optimizando un job de backup

Fran Garcia — Sun, 05 Aug 2012 18:48:00 GMT

Este fin de semana me aburría y me he puesto a optimizar un script para realizar backup que llevo usando unos cuantos años en diversos PCs de escritorio. Es un poco "pedestre" puesto que básicamente se dedica a comprimir con tar una serie de directorios, y guardar el contenido en un disco externo USB.

Originalmente el script era algo así :

#! /bin/bash
DATE=$(date +%Y-%m-%d)
BACKUP_MNT="/media/disco_usb"
BACKUP_TARGET="$BACKUP_MNT/backup/$HOSTNAME"
TAROPS="--absolute-names --atime-preserve -z "

mkdir -p $BACKUP_TARGET/$DATE
BACKUP_TARGET="$BACKUP_TARGET/$DATE"

FILEPREFIX="$BACKUP_TARGET/$DATE-$HOSTNAME"

if [ ! -d "$BACKUP_TARGET" ]; then
        echo "Backup target '$BACKUP_TARGET' does not exit, cannot backup"
        exit 0
fi

tar -c $TAROPS -f $FILEPREFIX-home.tar.gz /home
tar -c $TAROPS -f $FILEPREFIX-etc.tar.gz  /etc
# Y aquí más comandos similares para otros directorios.

md5sum $FILEPREFIX-home.tar.gz > $FILEPREFIX-home.tar.gz.md5
md5sum $FILEPREFIX-etc.tar.gz  > $FILEPREFIX-etc.tar.gz.md5
# Despues de comprimir los ficheros, guardamos la suma MD5 para poder
# saber en el futuro si han sido alterados (fichero a medias, problemas
# de lectura si es un CDROM, etc).

Esta forma de hacer el backup no es muy eficiente, porque gzip (opción -z) solo aprovecha un único core a la vez, con lo que no sacamos provecho de tener múltiples cores/procesadores.

Además, el proceso de hacer un md5sum era bastante costoso al tener que releer desde disco el fichero comprimido (en mi caso, unos 20Gb).

Para el primer problema, me ha alegrado descubrir pigz, un clon de gzip multihilo que aprovecha todos los cores de forma simultánea. El uso es tan sencillo como pigz fichero.tar , o en el caso de quererlo usar con tar :

tar -I pigz -cf fichero.tar.gz  dir1 dir2 dir3

Para el segundo problema, he recordado la existencia de tee, un programa de GNU que nos permite enviar la entrada estándar hacia múltiples procesos y salidas. ¿Cómo nos influye esto en el rendimiento? Simplemente es mucho menos costoso hacer la suma MD5SUM antes de escribir el fichero en disco (mientras está en memoria), que escribirlo y luego tenerlo que leer.

La idea con esto, por tanto, es que tar genere un fichero comprimido y que mediante tee, sea examinado por MD5SUM y, por otra parte, redireccionada la salida estándar al fichero .tar.gz correspondiente. Tal que así :

tar -I pigz -c dir1 dir2 dir3 | tee >( md5sum > fichero.tar.gz.md5 ) > fichero.tar.gz

Ojo que al usar tee debemos cambiar la forma en la que invocamos tar. Ya no es posible usar la opción -f para indicar el fichero de salida, si no que se especifica redireccionado la salida estándar.

Al final quedaría el script de backup de esta forma:

#! /bin/bash
DATE=$(date +%Y-%m-%d)
BACKUP_MNT="/media/disco_usb"
BACKUP_TARGET="$BACKUP_MNT/backup/$HOSTNAME"
TAROPS="--absolute-names --atime-preserve -I pigz "

mkdir -p $BACKUP_TARGET/$DATE
BACKUP_TARGET="$BACKUP_TARGET/$DATE"

FILEPREFIX="$BACKUP_TARGET/$DATE-$HOSTNAME"

if [ ! -d "$BACKUP_TARGET" ]; then
        echo "Backup target '$BACKUP_TARGET' does not exit, cannot backup"
        exit 0
fi

tar -c $TAROPS /home | tee >(md5sum > $FILEPREFIX-home.tar.gz.md5) > $FILEPREFIX-home.tar.gz
tar -c $TAROPS /etc  | tee >(md5sum > $FILEPREFIX-etc.tar.gz.md5)  > $FILEPREFIX-etc.tar.gz

¿Cuánto ha mejorado con esto? Mi trabajo tardaba originalmente unos 26 minutos en completarse. Activando la compresión paralela, ha pasado a tardar unos 17. Y activando la suma md5sum con tee, ha pasado a tardar 13.5min .

No está mal bajar a la mitad de tiempo con un par de comandos! ;-)

Autenticar Postfix contra un servidor SMTP via SASL

Fran Garcia — Sat, 14 Apr 2012 20:49:00 GMT

Aquí va una pequeña receta para hacer que tu Postfix local use SASL para autenticarse contra un relay externo. Esto es especialmente útil para usuarios móviles (portátiles, etc) donde tu IP varía y no es viable realizar una autorización en base a IPs estáticas.

Basado en el artículo de Patric Koetter.

Para realizar esto, simplemente es necesario crear un fichero con las credenciales SASL a utilizar, tal que:

# ls -l /etc/postfix/sasl_passwd
-rw-------. 1 root root 55 Nov  3 00:15 /etc/postfix/sasl_passwd
# sudo cat  /etc/postfix/sasl_passwd
relay.example.org       user@loquesea:MiPassword

Y añadir esto al fichero main.cf de postfix :

smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_sasl_type = cyrus

Instalar software en RHEL6 desde CD/DVD

Fran Garcia — Sat, 02 Jul 2011 17:23:00 GMT

Como ya comenté hace tiempo se pueden configurar repositorios de YUM que apuntan al CD original, y en RHEL6 no iba a ser menos.

Aquí va el fichero de configuración, ej /etc/yum.repos.d/localcd.repo :

[RHEL6-CD-SERVER]
name=Red Hat 6 Server
baseurl=file:///mnt/Server
enabled=1
gpgcheck=0

[RHEL6-CD-HA]
name=Red Hat 6 Server HA
baseurl=file:///mnt/HighAvailability
enabled=1
gpgcheck=0

[RHEL6-CD-LB]
name=Red Hat 6 LB
baseurl=file:///mnt/LoadBalancer
enabled=1
gpgcheck=0

[RHEL6-CD-RStor]
name=Red Hat 6 RStor
baseurl=file:///mnt/ResilientStorage
enabled=1
gpgcheck=0

[RHEL6-CD-SFS]
name=Red Hat 6 SFS
baseurl=file:///mnt/ScalableFileSystem
enabled=1 
gpgcheck=0

Fetchmail y procmail: ¡descarga y filtra tu correo ya!

frangdlt — Sat, 09 Nov 2002 16:43:00 GMT

Fetchmail es una utilidad diseñada por ESR para recoger el correo de servidores remotos (pop3, imap, ...) mientras que procmail es un programa que filtra todos estos correos entrantes según unas reglas que podemos definir.

En primer lugar, debemos tener configurado un sistema de correo local. Sendmail, postfix, exim, qmail... todos son buenas alternativas para hacer esto :-)

Recoger correo : fetchmail

El primer paso es definir una serie de cuentas de las que fetchmail deberá recoger los correos. Es necesario editar el fichero $HOME/.fetchmailrc y poner entradas del tipo:

poll pop3.servidor.com protocol pop3
    user USUARIOREMOTO with pass "secreto" is USUARIOLOCAL here

Lanzando fetchmail desde la línea de comandos, hará que éste lea el fichero de configuraciones y pase a bajar todos los correos en cada uno de los servidores, inyectandolos en el sistema de correo local. Según distribuciones, el correo suele ir a /var/spool/mail/USUARIO ó /var/mail/USUARIO, siendo ya accesible por cualquier cliente de correo.

NOTA: algunos clientes de correo tienen la costumbre de mover el correo una vez leido o accedido a $HOME/mbox. Esto puede ser algo engorroso cuando no se usa siempre el mismo cliente de correo, algo a tener en cuenta :-)

TRUCO:Puede ser que tengamos contratado un hosting/housing para un determinado dominio, pero que nos interese hacer el reparto y filtrado de forma local (menos cuentas pop, menos gastos). Para ello fetchmail permite inyectar los correos entrantes en el sistema de correo. Para todo esto, nuestro MTA debe aceptar correo para el dominio requerido (en este caso, maquina.dom-local.com y dom-externo.es):

poll pop.isp-externo.com proto pop3
    localdomains maquina.dom-local.com dom-externo.es
    user USUARIOEXTERNO with pass "secreto" is * fetchall

Descargamos el correo con:

$ fetchmail --envelope X-Envelope-To

Filtrar correo : procmail

Llegados a este punto, desearemos filtrar los correos entrantes . Para ello, debemos editar $HOME/.procmailrc añadiendo los filtros que sean necesarios.

NOTA:Según nuestra configuración de /etc/procmailrc, puede ser necesario que cada usuario llame a procmail de forma discrecional, editando $HOME/.fordward con una línea como esta:

"|IFS=' ' && exec /usr/bin/procmail -f- || exit 75 #USUARIO"

Las reglas de filtrado están en $HOME/.procmailrc

En este caso, vamos a ver un par de reglas de filtrado simples, aunque en los links recomendados se ve cómo hacer cosas más complejas. Las reglas están formadas por, al menos, 3 líneas. La primera de ellas alude a qué parte del mensaje se ha de aplicar, la segunda es similar una expresion regular, que si se cumple, dará lugar a que el correo se almacene en el fichero al que se refiere la tercera línea. Ejemplo:

:0:
* From.*pepe@example.com
mail/correo_de_pepe

Con esto nos serviría, por ejemplo, para poder filtrar el correo de una lista de correo :-)