Algo de Linux: septiembre 2013

viernes, 27 de septiembre de 2013

Realizar búsquedas en ldap mediante ldapsearch

LDAP (Lightweigh Directory Access Protocol) es esencialmente un servicio de directorio que nos va a permitir almacenar la información necesaria de nuestra organización (usuarios, grupos, hosts, dns, dhcp, ...) en una base de datos optimizada para consultas.

En nuestro trabajo diario usamos con mucha frecuencia ldap, aunque lo cierto es que no siempre necesitamos recurrir a herramientas de línea de comandos como ldapsearch, ldapadd, ldapmodify o ldapdelete, que forman parte del paquete ldap-utils y gestionamos nuestra B.D. ldap con herramientas como phpldapadmin o nuestro superútil controlies.
No obstante, cuando tenemos que procesar un conjunto de registros de una manera más o menos automatizada, puede venirnos muy bien echar mano de éstas.

El árbol de directorio de ldap se encuentra organizado mediante los siguientes componentes:
  • dc: domain component
  • ou: organizational unit
De este modo, podemos tener una base de directorio como:
  • dc=instituto,dc=extremadura,dc=es
 Y dentro del mismo, tener unidades organizativas donde almacenar nuestros usuarios, como:
  •  ou=People,dc=instituto,dc=extremadura,dc=es
O unidades organizativas donde almacenar los grupos:
  •  ou=Group,dc=instituto,dc=extremadura,dc=es
Como ldapsearch tiene muchísimas opciones, y me parece un poco rollo listarlas, vamos a ver cómo usar ldapsearch mediante unos cuantos ejemplos y si alguien necesita más información, puede recurrir al man:

# man ldapsearch

Primer ejemplo.- Obtener los datos de usuarios que tengan un objectClass=inetOrgPerson.
# ldapsearch -xLLL -h ldap -b "dc=instituto,dc=extremadura,dc=es" "(objectClass=inetOrgPerson)"
  • Con la opción -x  estamos indicando a ldapsearch que queremos usar autentificación simple.
  • Con la opción -LLL indicamos a ldapsearch que deseamos obtener una salida LDAPv1.
  • Con la opción -h host indicamos el servidor ldap en el que vamos a realizar la búsqueda. 
  • Con la opción -b base indicamos cuál es el punto del árbol ldap desde donde se debe realizar la búsqueda.
  • Por último, especificamos un filtro de búsqueda. En el ejemplo: "(objectClass=inetOrgPerson)"

Segundo ejemplo.- Obtener los datos de usuarios que tengan un objectClass=inetOrgPerson, haciendo la consulta con un usuario autentificado:
# ldapsearch -xLLL -h ldap -D "cn=admin,ou=People,dc=instituto,dc=extremadura,dc=es" -W -b "ou=People,dc=instituto,dc=extremadura,dc=es" "(objectClass=inetOrgPerson)"

Si os fijáis, la única diferencia con el caso anterior son las siguientes opciones:
  • Con -D "cn=admin,ou=People,dc=instituto,dc=extremadura,dc=es" indicamos el usuario con el que vamos a realizar la consulta.
  • Con -W le indicamos al comando ldapsearch que nos pida la contraseña.
  • Si quisiéramos especificar directamente la contraseña, utilizaríamos la opción -w password.
Tercer ejemplo.- Obtener los datos de usuarios que tengan un objectClass=inetOrgPerson, haciendo la consulta con un usuario autentificado y especificando la password del usuario en la línea de comandos:

# ldapsearch -xLLL -h ldap -D "cn=admin,ou=People,dc=instituto,dc=extremadura,dc=es" -w mipassword -b "ou=People,dc=instituto,dc=extremadura,dc=es" "(objectClass=inetOrgPerson)"

Cuarto ejemplo.- Obtener los datos de usuarios que tengan un objectClass=inetOrgPerson, haciendo la consulta con un usuario autentificado, utilizando una autentificación SSL/TLS:
# ldapsearch -xLLL -H "ldaps://ldap:636" -D "cn=admin,ou=People,dc=instituto,dc=extremadura,dc=es" -W -b "ou=People,dc=instituto,dc=extremadura,dc=es" "(objectClass=inetOrgPerson)"
Quinto ejemplo.- Imaginemos que tenemos almacenados los datos del host asignado a cada usuario mediante el objectClass=hostObject y queremos obtener los datos de aquellos usuarios que tengan asignado el host "a01-o02". Podríamos hacer una consulta anónima con un filtro compuesto:

# ldapsearch -xLLL -h ldap "(&(objectClass=hostObject)(host=a01-o02))"

De este modo, obtendríamos todos los atributos del usuario o usuarios que tengan asignado el host a01-o02.

Sexto ejemplo.- Si ahora quisiéramos obtener tan sólo el atributo host del usuario, no tendríamos más que indicarlo a continuación:

# ldapsearch -xLLL -h ldap "(&(objectClass=hostObject)(host=a01-o02))" host

Séptimo ejemplo.- Si ahora quisiéramos obtener, además del host, el atributo homeDirectory del usuario, no tendríamos más que indicarlo a continuación:

# ldapsearch -xLLL -h ldap "(&(objectClass=hostObject)(host=a01-o02))" host homeDirectory


Octavo ejemplo.- Si ahora quisiéramos obtener el host asignado a un usuario, concreto, no tendríamos más que modificar el filtro de búsqueda:

# ldapsearch -xLLL -h ldap "(&(objectClass=hostObject)(uid=ponente)(host=*))" host

Noveno ejemplo.- Si quisiéramos obtener tan sólo el nombre del host asignado al alumno sin la información del dn, no tendríamos más que filtrar la salida con comandos. Por ejemplo:

# ldapsearch -xLLL -h ldap "(&(objectClass=hostObject)(uid=ponente)(host=*))" host | grep "host:" | cut -f2 -d" "

Décimo ejemplo.- Por último, si quisiéramos consultar el e-mail de todos los usuarios de nuestro servidor ldap, podríamos hacer la siguiente búsqueda:

# ldapsearch -x -h ldap -p 389 -b "ou=People,dc=instituto,dc=extremadura,dc=es" "(&(objectClass=inetOrgPerson)(mail=*))" mail
 
Publicado por primera vez en http://enavas.blogspot.com.es

miércoles, 18 de septiembre de 2013

Paquetes de firefox 24.0 para instalar en las máquinas de los IES

A continuación dejo dos enlaces para descargar los paquetes de 32 y 64 bits creados "de forma rápida" para instalar firefox 24.0 en el directorio /opt/firefox/ de las máquinas del instituto. 

Importante: Estos paquetes tan sólo colocan firefox en /opt/firefox/. No cambian el enlace de /usr/bin/iceweasel a /opt/firefox/firefox para que se siga pudiendo usar iceweasel como navegador por defecto. 

Para realizar el cambio de iceweasel a firefox o firefox a iceweasel, tengo dos tareas puppet:
  • activa-firefox 
  • activa-iceweasel 
De este modo, si quiero que los portátiles, los servidores ltsp o los workstation usen firefox, les pongo la tarea activa-firefox y si quiero que usen iceweasel, les pongo la tarea activa-iceweasel.

Publicado por primera vez en http://enavas.blogspot.com.es

lunes, 16 de septiembre de 2013

Configurar nuestro pendrive wifislax 4.6 para usarlo en modo persistente

Cuando instalamos una ISO en un pendrive, todos los cambios que realicemos se perderán al reiniciar, de igual modo que cuando lo usamos en CD. WifiSlax 4.6 tiene opciones en el menú de inicio que nos permitirán usar un modo persistente con el que se guardarán los cambios cuando utilicemos la distribución, de modo que éstos permanecerán en el próximo arranque.

Si queremos utilizarlas, lo único que tendremos que hacer será configurar el modo persistente. Para ello, iniciamos normalmente la distribución. En el ejemplo de la pantalla siguiente he iniciado con el kernel NORMAL. Si estáis arrancando en una máquina con más de 4 GB de RAM, seleccionad "Arrancar con kernel PAE":


Tanto si seleccionáis un kernel, como si seleccionáis el otro, la siguiente ventana será similar a ésta:


Si os fijáis, tiene opciones para arrancar en modo normal (sin que se guarden los cambios) o  en modo persistente (de forma que se guarden los cambios). Como lo que vamos a hacer es configurar el modo persistente, iniciamos seleccionando un modo NO PERSISTENTE.

Una vez arrancado, WifiSlax, abrimos un terminal y ejecutamos:

# changes xxx

Sustituyendo "xxx" por la cantidad en Mb que queremos que tenga el fichero de cambios. Por ejemplo:

# changes 512

La línea anterior creará un fichero de 512 Mb en el que se guardarán los cambios.

Si queremos crear un fichero de cambios de 1024 Mb, ejecutaríamos:

# changes 1024

Cuando termine de crearse el archivo, no tenemos más que reiniciar el equipo y en las opciones de arranque, seleccionar una que nos permita usar el modo persistente:
  • Wifislax con KDE + Persistent
  • Wifislax con XFCE + Persistent

Publicado por primera vez en http://enavas.blogspot.com.es

Instalar wifislax 4.6 en un pendrive de forma manual

Además de instalar WifiSlax mediante UnetBootin, podemos hacerlo de forma manual, como vamos a ver a continuación:

Primero.- Descargamos la ISO desde la web:

# wget http://www.downloadwireless.net/isos/wifislax-4-6-final.iso

Segundo.- Una vez descargado el archivo wifislax-4-6-final.iso, lo montamos en un directorio:

# mkdir /mnt/iso
# mount -o loop wifislax-4-6-final.iso /mnt/iso

Tercero.- Montamos el pendrive en un directorio. Por ejemplo, suponiendo que nuestro pendrive es /dev/sdc y tiene una partición /dev/sdc1, lo montamos de la siguiente manera:

# mkdir /mnt/usb
# mount /dev/sdc1 /mnt/usb

Cuarto.- Copiamos los archivos al pendrive:

# cp -r /mnt/iso/* /mnt/usb/

Quinto.- Nos situamos en el directorio boot del dispositivo usb:

# cd /mnt/disco/boot

Sexto.- Ejecutamos el script bootinst.sh:

# ./bootinst.sh

Si os fijáis, el instalador configurará, en mi caso, la partición /dev/sdc1 para que arranque Wifislax y sobreescribirá el MBR del dispositivo /dev/sdc.  En vuestro caso, el dispositivo puede tener otro nombre.


Pulsamos una tecla para aceptar y realizará la configuración:


Si todo ha ido bien, como en mi caso, pulsamos una tecla para salir y ya tendremos nuestro pendrive autoarrancable con Wifislax instalado.

Publicado por primera vez en http://enavas.blogspot.com.es

Instalar wifislax 4.6 en un pendrive mediante unetbootin

La forma más sencilla de instalar wifislax en un pendrive es haciendo uso de unetbootin. Veamos cómo:

Primero.- Descargamos la ISO de WifiSlax desde http://www.wifislax.com/category/download/nuevas-versiones/

Segundo.- Abrimos UNetbootin:


Tercero.- Una vez abierta, seleccionamos la opción Disco/Imagen y pulsamos sobre el botón de los puntos suspensivos:



Cuarto.- Se nos abrirá un cuadro de diálogo para que seleccionemos el archivo ISO que vamos a instalar en el pendrive.  Lo elegimos y pulsamos el botón "Open":


Quinto.- Así es como nos quedará la aplicación:
 

Pulsamos el botón "Aceptar" y comenzará el proceso de instalación:


Cuando termine, no tendremos más que pulsar el botón "Salir"  y ya tendremos nuestro WifiSlax instalado en el pendrive.



Ahora no tendremos más que arrancar el equipo desde USB para utilizar la distribución.


Publicado por primera vez en http://enavas.blogspot.com.es

viernes, 13 de septiembre de 2013

FBReader: Un lector de libros electrónicos para Linux/Windows

Esta mañana, un compañero preguntaba en la lista de administradores si alguien conocía un lector de libros electrónicos para instalar en nuestros equipos Debian y no conseguía recordar el nombre. Ahora que acabo de acordarme lo publico aquí: FBReader.

FBReader es un lector de libros electrónicos OpenSource para Linux/Windows PDA/UMPC/PC. FBReader que soporta una gran candidad de formatos: ePub, fb2, chm, rtf, etc. 



Si os fijáis en el pantallazo, también puede leer directamente archivos comprimidos en formato zip, tar, gzip y bzip2 .

Como se encuentra en los repositorios de Debian, es muy fácil instalarlo:

# apt-get install fbreader

Publicado por primera vez en http://enavas.blogspot.com.es

jueves, 5 de septiembre de 2013

apt-pinning: Controlar desde qué repositorio se instalan nuestros paquetes

En ocasiones nos interesa forzar la instalación de paquetes desde un repositorio determinado, como por ejemplo, backports o un repositorio local.  Para ello, podemos hacer apt-pinning en Debian y derivados.

Para configurar el apt-pinning podemos usar dos ubicaciones:
  • El fichero /etc/apt/preferences
  • El directorio /etc/apt/preferences.d/
Personalmente, prefiero usar el directorio /etc/apt/preferences.d/, más que nada por organización y tener claro de un vistazo lo que estoy forzando. Si os decantáis por esta opción, lo único que tenéis es que hacer es crear un fichero dentro del directorio con las preferencias que queráis establecer. Por ejemplo, puedo tener un fichero /etc/apt/preferences.d/iceweasel en el que configuro las opciones de apt para que los paquetes de iceweasel se instalen desde squeeze-backports.

Cada vez que quiero definir unas determinadas preferencias, uso la siguiente estructura básica en el archivo de configuración:

Package: 
Pin:
Pin-Priority:

Mediante Package indicamos la lista de paquetes a instalar.
Mediante Pin indicamos la rama, versión o repositorio desde el que queremos instalar los paquetes.
Mediante Pin-Priority especificamos la prioridad que tendrán los paquetes a la hora de actualizar.

Veamos un fichero de ejemplo:
sprofesores-pro:~# cat /etc/apt/preferences/iceweasel 
Package: iceweasel iceweasel-l10n-es-es libnss3 libnss3-1d
Pin: release a=squeeze-backports
Pin-Priority: 600

En el fichero anterior, estoy indicando a apt que los paquetes iceweasel, iceweasel-l10n-es-es, libnss y libnss3-1d deben instalarse desde squeeze-backports siempre que la versión instalada sea más antigüa y no exista una versión más reciente en la rama principal.

Otro ejemplo:
sprofesores-pro:~# cat /etc/apt/preferences/repositorio-local 
Package: *
Pin: origin recursos.valledeljerte3
Pin-Priority: 1000

En este ejemplo le estoy diciendo a apt que se debe instalar cualquier paquete (*) del repositorio recursos.valledeljerte3 (que es mi repositorio local) salvo que la versión ya instalada sea más reciente, aunque dicho paquete no provenga de la rama principal.
Si os fijáis en el ejemplo anterior, he usado un comodín (*) para representar cualquier paquete.

También podría especificar lo siguiente: 

Package: iceweasel*

Y estaría indicando que las condiciones se apliquen a cualquier paquete que comience por la cadena iceweasel. 

Diferentes opciones para especificar en Pin:
  • Pin: release a=stable (Indicamos la rama del repositorio a usar: stable, unstable, testing)
  • Pin: release n=wheezy (Indicamos el nombre de la versión de Debian: squeeze, wheezy, ...)
  • Pin: release v=6.0 (Indicamos la versión de Debian: 5.0, 6.0, 7.0, ...)
  • Pin: release c=main (Indicamos el componente del repositorio: main, contrib, non-free )
  • Pin: origin recursos.valledeljerte3 (Indicamos el servidor de los paquetes)

Definición de prioridades con Pin-Priority:
Las prioridades pueden ser números enteros positivos o negativos. Veamos cómo se interpretan los valores de prioridad:
  • Prioridad > 1000: La versión se instalará desde el repositorio indicado, incluso si es una versión anterior a la instalada en el sistema.
  • 990 < Prioridad <= 1000: Se instalará la versión aunque no provenga de la distribución objetivo, a menos que la versión instalada sea más reciente.
  • 500 < Prioridad <= 990: Se instalará el paquete siempre que la versión instalada sea más antigua y no exista una versión más reciente en la rama principal.
  • 100 < Prioridad <= 500: Se instalará el paquete siempre que la versión instalada sea más antigua y no exista una versión más reciente en cualquiera de los repositorios.
  • 0 < Prioridad <= 100: La versión sólo se instala si no hay ninguna versión del paquete ya instalada.
  • Prioridad <= 0: Evita la instalación del paquete especificado en las condiciones.

Usar Stages en Puppet para garantizar las actualizaciones de paquetes mediante APT

Uno de los problemas que tenemos con Puppet es que, en ocasiones, realizamos un módulo que instala un software y cuando se ejecuta dicho módulo, falla la ejecución porque los índices de los repositorios no se encuentran actualizados.

Una forma de solucionar este problema es haciendo uso de un recurso que nos proporciona Puppet: Las stages o etapas.

Este recurso nos permite ordenar "la ejecución" de los recursos en etapas. Por defecto, tan sólo hay una etapa definida en Puppet llamada "main", de forma que todos los recursos son automáticamente asociados a ella, a menos que asignemos especificamente un recurso a otra etapa definida por nosotros.

Las etapas definidas por el usuario se declaran como cualquier otro recurso.

Vamos a ver a continuación cómo usar el recurso stage para garantizar que se realice siempre un apt-get update antes de que se ejecute cualquier otro recurso:

Lo ideal es que definamos nuestras stages en el archivo /etc/puppet/manifests/site.pp, salvo que no tengamos control sobre él, en cuyo caso, podemos definirlo en otra clase de orden inferior. Como éste es nuestro caso, las he definido en las clases de servidores ltsp, workstations y  portátiles:
  • /etc/puppet/manifests/classes/clase-especifica-squeeze.pp
  • /etc/puppet/manifests/classes/especifica-workstation.pp
  • /etc/puppet/manifests/classes/especifica-miniportatil-2011.pp


Primero.- Definimos las etapas que queramos crear y les damos el nombre que queramos. Como se puede ver en el siguiente ejemplo, yo he creado dos etapas: first y last.

stage { [first, last]: }

Segundo.- Especificamos cuál debe ser el orden de ejecución de las etapas. Por ejemplo:

Stage[first] -> Stage[main] -> Stage[last]

Con ésto, logramos:
  • Que la etapa "first" se ejecute antes que la etapa "main". 
  • Y la etapa "last" se ejecute después que la etapa "main".

Tercero.- Asociamos módulos o clases a etapas. Como se puede ver a continuación, estoy definiendo que el módulo "apt-get-update" debe ejecutarse en la etapa "first".

class { apt-get-update: stage => first }

Y listo.Con ésto, garantizaremos que el apt-get update se ejecute siempre antes que cualquier otro módulo que por defecto estará asociado a la etapa "main".

Como se puede ver, he definido tres etapas. De momento, no uso la etapa "last". Tan sólo la he creado por si la necesito posteriormente.

lunes, 2 de septiembre de 2013

Instalar iceweasel en Debian Wheezy desde wheezy-backports en español

Allá por marzo del año pasado, publiqué una entrada en la que explicaba cómo instalar iceweasel desde los repositorios backports en Debian Squeeze. 

Mantener actualizado iceweasel en Debian Wheezy es igual de sencillo, pero como hay gente que usa mi blog como referencia y me lo han pedido para tenerlo todo "al alcance de la mano", publico aquí la entrada de como hacerlo.

Primero.- Añadimos los repositorios necesarios a un archivo de fuentes. Para mantener un poco organizadas las fuentes de mis repositorios, lo haré de la siguiente manera:

# echo "# Repositorio del Mozilla Debian Team\n\ndeb http://mozilla.debian.net/ wheezy-backports iceweasel-release" > /etc/apt/sources.list.d/mozilla.list

# echo "# Repositorio wheezy-backports\n\ndeb http://ftp.debian.org/debian/ wheezy-backports main contrib non-free" > /etc/apt/sources.list.d/wheezy-backports.list

Segundo.- Actualizamos los índices de los repositorios:

# apt-get update

Tercero.- Instalamos el paquete que contiene la firma del repositorio de mozilla:

# apt-get install  pkg-mozilla-archive-keyring

Cuarto.- Por último, instalamos iceweasel en español:

# apt-get -t wheezy-backports install iceweasel iceweasel-l10n-es-es

Paquetes de firefox 23.0.1 para instalar en las máquinas de los IES

Bueno, empezamos septiembre y volvemos a la carga de nuevo...

Como siempre, aquí dejo dos enlaces para descargar los paquetes de 32 y 64 bits creados "de forma rápida" para instalar firefox 23.0.1 en el directorio /opt/firefox/ de las máquinas del instituto. 

Importante: Estos paquetes tan sólo colocan firefox en /opt/firefox/. No cambian el enlace de /usr/bin/iceweasel a /opt/firefox/firefox para que se siga pudiendo usar iceweasel como navegador por defecto. 

Para realizar el cambio de iceweasel a firefox o firefox a iceweasel, tengo dos tareas puppet:
  • activa-firefox 
  • activa-iceweasel 
De este modo, si quiero que los portátiles, los servidores ltsp o los workstation usen firefox, les pongo la tarea activa-firefox y si quiero que usen iceweasel, les pongo la tarea activa-iceweasel.