Cuando en nuestro sistema conviven una buena cantidad de usuarios y grupos, y queremos ‘mantener el orden’ en lo referente a el espacio usado por cada uno de ellos, tenemos la opción de activar el sistema de cuotas/quotas a nivel de sistema de ficheros de modo que podamos personalizar por usuario y grupo el espacio máximo o número de inodos que pueden utilizar.

Activación e inicialización de quotas

Lo primero que debemos averiguar es si nuestro sistema es compatible con las quotas, para ello, por un lado deberíamos tener instalado el paquete quota, en RHEL, CentOS y derivados lo podemos verificar así:

# rpm -qa | grep quota
quota-3.13-4.el5

Si está instalado, el próximo paso es saber si la partición o sistema de ficheros sobre el que queremos activar quotas tiene los flags correspondientes que lo activan (usrquota,grpquota):

# mount
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw,acl)

Si no lo tiene, como es el caso anterior, lo activamos remontando el sistema de ficheros así:

# mount -o remount,usrquota,grpquota /
# mount
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw,acl,usrquota,grpquota)

Para que esto tenga efecto tras el reinicio tendréis que añadir las flags al fichero /etc/fstab:

/dev/VolGroup00/LogVol00 /                       ext3    defaults,usrquota,grpquota       1 1

Ahora podemos usar quotas en /, únicamente nos falta inicializarlas, para ello utilizamos el comando quotacheck, que hace un escaneo de las quotas asignadas a grupos y usuarios, y en caso de que sea la primera vez, crea los ficheros de quota para usuarios y grupos. Veréis aparecen errores, es normal al ser la primera vez ya que no existen:

# quotacheck -cgumv /
quotacheck: Scanning /dev/mapper/VolGroup00-LogVol00 [/] quotacheck: Cannot stat old user quota file: No such file or directory
quotacheck: Cannot stat old group quota file: No such file or directory
quotacheck: Cannot stat old user quota file: No such file or directory
quotacheck: Cannot stat old group quota file: No such file or directory
done
quotacheck: Checked 4266 directories and 31262 files
quotacheck: Old file not found.
quotacheck: Old file not found.

Los parámetros son:

• -c: Escaneo del sistema de ficheros en busca de quotas
• -g: Busca quotas de grupos
• -u: Busca quotas de usuarios
• -m: No intenta hacer un remount en sistemas read-only
• -v: Verbose

Tras el escaneo, podemos activar las quotas en el sistema de ficheros elegido (-u de usuario, -g de grupo y -v de verbose):

# quotaon -ugv /
/dev/mapper/VolGroup00-LogVol00 [/]: group quotas turned on
/dev/mapper/VolGroup00-LogVol00 [/]: user quotas turned on

Asignación de quota a usuarios o grupos

A la hora de editar las quotas podemos hacerlo de dos formas, directamente desde la línea de comandos con setquota o editando el fichero correspondiente con edquota, vamos a ver las dos formas.

Asignamos una quota de 250M de soft limit, 300 de hard limit y sin límite de inodos al usuario foo en /:

# setquota -u foo 256000 307200 0 0 /

O lo hacemos con edquota:

# edquota foo
Disk quotas for user foo (uid 10000):
  Filesystem                   blocks       soft       hard     inodes     soft     hard
  /dev/mapper/VolGroup00-LogVol00    1068920     256000     307200      35408        0        0

Para visualizar el estado de las quotas de un usuario o grupo, utilizamos quota -v:

# quota -v foo
Disk quotas for user foo (uid 10000):
     Filesystem  blocks   quota   limit   grace   files   quota   limit   grace
/dev/mapper/VolGroup00-LogVol00
                1068920* 256000  307200   6days   35407       0       0

Para los grupos es igual, pero utilizando el parámetro -g:

# edquota -g grupo
# setquota -g grupo 256000 307200 0 0 /

También podéis ver distintos reportes con el comando repquota. Reportes de todos los usuarios, todos los grupos, todo un sistema de ficheros, etc:

# repquota -v /
*** Report for user quotas on device /dev/mapper/VolGroup00-LogVol00
Block grace time: 7days; Inode grace time: 7days
Block limits                File limits
User            used    soft    hard  grace    used  soft  hard  grace
----------------------------------------------------------------------
root      +- 1068920  256000  307200  6days   35407     0     0
daemon    --      20       0       0              3     0     0
nobody    --       4       0       0              1     0     0

# repquota -vg /
*** Report for group quotas on device /dev/mapper/VolGroup00-LogVol00
Block grace time: 7days; Inode grace time: 7days
                        Block limits                File limits
Group           used    soft    hard  grace    used  soft  hard  grace
----------------------------------------------------------------------
root      -- 1066300       0       0          35348     0     0
daemon    --      28       0       0              4     0     0
tty       --      28       0       0              2     0     0
disk      --       4       0       0              1     0     0
mail      --     220       0       0              7     0     0
man       --     256       0       0             32     0     0

Algo a tener en cuenta son los ‘periodos de gracia’ o dicho de otro modo, el tiempo que dejamos al usuario o al grupo pasar el soft-limit sin que suceda nada. Lo podemos modificar utilizando el parámetro -t. Podemos ver la configuración y/o modificarla así para todos los usuarios y grupos:

# edquota -t
Grace period before enforcing soft limits for users:
Time units may be: days, hours, minutes, or seconds
  Filesystem             Block grace period     Inode grace period
  /dev/mapper/VolGroup00-LogVol00                  7days                  7days

Por defecto son 7 días, tanto para inodos como para bloques. Si quisieramos modificarlo de forma individual sería con la T mayúscula, y añadiendo la g si es para grupos:

# edquota -t foo
# edquota -tg grupo

Si lo hacemos con setquota, tendremos que especificar el tiempo en segundos:

Para un usuario:

# setquota -uT foo 20000 20000 /

Para un grupo:

# setquota -ug grupo 20000 20000 /

Y para todos los usuarios:

# setquota -ut 20000 20000 /

Deshabilitar quotas

Podemos deshabilitar las quotas del sistema de ficheros o en general con el comando quotaoff:

Para todos los filesystems:

# quotaoff -av
/dev/mapper/VolGroup00-LogVol00 [/]: group quotas turned off
/dev/mapper/VolGroup00-LogVol00 [/]: user quotas turned off

O para uno en concreto:

# quotaoff -av /
/dev/mapper/VolGroup00-LogVol00 [/]: group quotas turned off
/dev/mapper/VolGroup00-LogVol00 [/]: user quotas turned off

Vamos a ver como crear un RAID 1 (espejo) por software entre dos discos extra añadidos a un sistema CentOS o RHEL. Este sistema nos ofrece total redundancia de datos a expensas de utilizar el doble de espacio en disco. En caso de disponer una controladora para hacer el RAID por hardware lógicamente es más recomendable que esta opción, ya que el rendimiento es mucho mejor.

Vamos a partir de la base de que además del disco que engloba el sistema, tenemos dos discos más disponibles para trabajar:

# fdisk -l | egrep -e "hdb|hdd"
Disk /dev/hdb doesn't contain a valid partition table
Disk /dev/hdd doesn't contain a valid partition table
Disk /dev/hdb: 1073 MB, 1073741824 bytes
Disk /dev/hdd: 1073 MB, 1073741824 bytes

Creación del RAID 1

Lo primero que tenemos que hacer es configurar dos particiones, una en cada disco y del tipo RAID AUTODETECT (fd). Aquellos que tengáis dudas con este paso, revisad este artículo: crear y eliminar particiones con fdisk en Linux

Haríamos este paso en ambos discos:

# fdisk /dev/hdd
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.

The number of cylinders for this disk is set to 2080.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-2080, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-2080, default 2080):
Using default value 2080

Command (m for help): t Selected partition 1
Hex code (type L to list codes): fd
Changed system type of partition 1 to fd (Linux raid autodetect)

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.
# partprobe

El resultado hasta el momento sería esto (omitiendo el disco de sistema):

# fdisk -l

Disk /dev/hdb: 1073 MB, 1073741824 bytes
16 heads, 63 sectors/track, 2080 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hdb1               1        2080     1048288+  fd  Linux raid autodetect

Disk /dev/hdd: 1073 MB, 1073741824 bytes
16 heads, 63 sectors/track, 2080 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hdd1               1        2080     1048288+  fd  Linux raid autodetect

Ahora ya podemos hacer uso del comando mdadm para crear el RAID 1 entre las particiones configuradas en ambos discos. Especificamos con -v la opción verbose, -C significa la creación del raid seguido del nombre asignado al array /dev/md0 y le indicamos que los dos discos serán activos (-n 2), podríamos asignar discos spare con -x. Finalmente especificamos los dispositivos a configurar en el array (las dos particiones creadas antes) y especificamos que es un RAID 1 con -l 1:

# mdadm -v -C /dev/md0 -n 2 /dev/hdb1 /dev/hdd1 -l 1
mdadm: size set to 1048192K
mdadm: array /dev/md0 started.

Monitorizar y gestionar el RAID

Podemos ver el estado del RAID en cualquier comento con mdadm –detail seguido del RAID a revisar:

# mdadm --detail /dev/md0
/dev/md0:
        Version : 0.90
  Creation Time : Tue Sep 27 18:02:46 2011
     Raid Level : raid1
     Array Size : 1048192 (1023.80 MiB 1073.35 MB)
  Used Dev Size : 1048192 (1023.80 MiB 1073.35 MB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Tue Sep 27 18:03:33 2011
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           UUID : 9a7817d8:038050a4:82a2f37d:414f679e
         Events : 0.2

    Number   Major   Minor   RaidDevice State
       0       3       65        0      active sync   /dev/hdb1
       1      22       65        1      active sync   /dev/hdd1

En caso de que uno de los discos fallase, habría que sacar del raid el disco fallido y reemplazarlo por otro, con el cual habría que seguir todos los pasos anteriores para prepararlo.

Forzamos el disco como fallido para hacer la prueba:

# mdadm /dev/md0 -f /dev/hdd1
mdadm: set /dev/hdd1 faulty in /dev/md0

Si ahora hicieramos un mdadm -D /dev/md0 veríamos el fallo del disco y el estado degraded:

# mdadm --detail /dev/md0
/dev/md0:
        Version : 0.90
  Creation Time : Tue Sep 27 18:02:46 2011
     Raid Level : raid1
...
...
...
          State : clean, degraded
 Number   Major   Minor   RaidDevice State
       0       3       65        0      active sync   /dev/hdb1
       1       0        0        1      removed

       2      22       65        -      faulty spare   /dev/hdd1

Sacamos el disco fallido del raid:

# mdadm /dev/md0 -r /dev/hdd1
mdadm: hot removed /dev/hdd1

Ahora el estado seguiría siendo degraded pero sin el disco fallido, así que sólo quedaría añadir un nuevo disco para que el RAID se reconstruyera:

# mdadm /dev/md0 -a /dev/hdd1
mdadm: re-added /dev/hdd1

Y automáticamente debería activarse el rebuild/recover y sincronizar la información entre ambos discos:

# mdadm -D /dev/md0
/dev/md0:
        Version : 0.90
  Creation Time : Tue Sep 27 18:02:46 2011
     Raid Level : raid1
     Array Size : 1048192 (1023.80 MiB 1073.35 MB)
  Used Dev Size : 1048192 (1023.80 MiB 1073.35 MB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Tue Sep 27 18:12:32 2011
          State : clean, degraded, recovering
 Active Devices : 1
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 1

 Rebuild Status : 44% complete

           UUID : 9a7817d8:038050a4:82a2f37d:414f679e
         Events : 0.6

    Number   Major   Minor   RaidDevice State
       0       3       65        0      active sync   /dev/hdb1
       1      22       65        1      spare rebuilding   /dev/hdd1

Eliminar un RAID

Para eliminar un RAID antes hay que pararlo, y posteriormente destruirlo:

# mdadm -vS /dev/md0
mdadm: stopped /dev/md0
# mdadm -vr /dev/md0

A partir de aquí, pues únicamente quedaría dar formato a /dev/md0 con el sistema de ficheros que necesitéis y gestionarlo como un sistema de ficheros normal.

Esquema raid: dis.um.es

Ya vimos en otra entrada (/usr/sbin y /sbin no están en $PATH al hacer su) los problemas que nos podía generar hacer login contra un usuario usando únicamente su. Básicamente, la diferencia es que si hacemos su <usuario> a secas “heredaremos” las variables de entorno y lo especificado en los ficheros de inicialización del usuario origen en lugar de recibir los del nuevo. Vamos a ver un ejemplo:

$ whoami
alex
$ echo $PATH
/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/home/alex/bin
$ su
Contraseña:
# whoami
root
# echo $PATH
/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/home/alex/bin

En el anterior ejemplo, pese a convertirme en root, seguía siendo aplicado el $PATH del usuario anterior (alex). En cambio, si ejecutamos su seguido de un guión y el usuario (para ser root no hace falta especificar el usuario) sí que se leerán los ficheros de inicialización de root y por consiguiente se definirá la variable $PATH correctamente:

$ whoami
alex
$ echo $PATH
/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/home/alex/bin
$ su -
Contraseña:
# whoami
root
# echo $PATH
/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin

Hace un tiempo vimos como establecer la caducidad de claves en Linux con el comando passwd. Hoy vamos a aprender otra forma de hacerlo, en este caso con el comando chage, con el que además podemos especificar la caducidad de la cuenta de un usuario concreto, no sólo de su clave.

Echando un vistazo a la ayuda del comando vemos claramente la función de cada uno de los parámetros:

$ chage --help
Modo de uso: chage [opciones] [USUARIO]

Opciones:
  -d, --lastday ULTIMO_DÍA      establece el último cambio de clave a
                                ULTIMO_DÍA
  -E, --expiredate FECHA_EXP    establece la fecha de caducidad de la
                                cuenta a FECHA_EXP
  -h, --help                    muestra este mensaje de ayuda y termina
  -I, --inactive INACTIV        desactiva la cuenta después de INACTIV
                                días desde la fecha de expiración
  -l, --list                    muestra la información de envejecimiento
                                de la cuenta
  -m, --mindays DÍAS_MIN        establece el número mínimo de días antes
                                de cambiar la clave a DÍAS_MIN
  -M, --maxdays DÍAS_MAX        establece el número máximo de días antes
                                de cambiar la clave a DÍAS_MAX
  -W, --warndays DÍAS_AVISO     establece el número de días de aviso
                                a DÍAS_AVISO

Como podéis ver, se puede especifica la fecha exacta en la que expirará la clave de acceso, los días permitidos tras la expiración de la cuenta hasta que se desactiva por completo, los días de aviso, etc. Vamos a ver unos ejemplos:

Cambiar la fecha de expiración de la cuenta al día 2011-9-28 al usuario foo

# chage -E 2011-9-28 foo

Listamos los atributos de caducidad especificados para esta cuenta:

# chage -l foo
Último cambio de contraseña					: sep 07, 2011
La contraseña caduca					: nunca
Contraseña inactiva					: nunca
La cuenta caduca						: sep 28, 2011
Mínimo número de días entre cambios de contraseña		: 0
Máximo número de días entre cambios de contraseña		: 99999
Número de días de aviso antes de que caduque la contraseña	: 7

Cambiar número de días entre cambios de clave (15) y la caducidad por inactividad de la clave (150)

# chage -m 15 -M 15 -I 150 foo
# chage -l foo
Último cambio de contraseña					: sep 07, 2011
La contraseña caduca					: sep 22, 2011
Contraseña inactiva					: feb 19, 2012
La cuenta caduca						: sep 28, 2011
Mínimo número de días entre cambios de contraseña		: 15
Máximo número de días entre cambios de contraseña		: 15
Número de días de aviso antes de que caduque la contraseña	: 7

Obligar a cambiar la clave en el próximo intento de acceso

# chage -d 0 foo

Hace ya casi un par de años vimos en una entrada cómo crear un Linux Logical Volume Manager (LVM) usando fdisk. En ese post cubrimos la primera parte necesaria para gestionar volúmenes lógicos en GNU/Linux además de hacer una introducción a LVM.

Vamos a continuar donde lo dejamos, omitimos el paso de fdisk porque está explicado en ese artículo. Partimos de la base entonces de que tenemos ya creada una partición Linux LVM, en nuestro caso /dev/sda3:

# fdisk -l | grep sda3
/dev/sda3               1        3232    25961008+  8e  Linux LVM

Crear los volúmenes físicos (PV – pvcreate)

Lo primero que debemos hacer cuando trabajamos con LVM es crear los volúmenes físicos (PV) de las particiones con las que queramos crear volúmenes lógicos. Esto lo hacemos con el comando pvcreate. Esto hay que hacerlo en todas las particiones que queramos usar con LVM. En nuestro caso de momento únicamente /dev/sda3:

# pvcreate /dev/sda3
  Physical volume "/dev/sda3" successfully created

Si quisieramos añadir más particiones, simplemente sería ejecutar ese comando con cada una de ellas.

Nota: Hay que tener el paquete lvm2 instalado para poder usar LVM. En Debian:

# apt-get install lvm2

Crear el grupo de volúmen (VG – vgcreate)

Ahora que ya tenemos configuradas las particiones que queremos usar como LVM, podemos añadir el primer grupo de volumen, que contendrá ya nuestros volúmenes lógicos finales. Lo haremos con el comando vgcreate. En nuestro caso sólo tenemos una partición, pero si quisiéramos añadir varias al grupo lo haríamos así:

vgcreate volgroup_01 /dev/sda3 /dev/sda4 /dev/sda5

Bien, voy a añadirlo entonces con mi partición /dev/sda3 que es con la que estamos trabajando de momento:

# vgcreate volgroup_01 /dev/sda3
  Volume group "volgroup_01" successfully created

Con el comando vgscan podemos consultar los grupos creados, con el comando pvscan los volúmenes físicos:

# vgscan
  Reading all physical volumes.  This may take a while...
  Found volume group "volgroup_01" using metadata type lvm2
# pvscan
  PV /dev/sda3   VG volgroup_01   lvm2 [24,76 GB / 24,76 GB free]
  Total: 1 [24,76 GB] / in use: 1 [24,76 GB] / in no VG: 0 [0   ]

Crear los volúmenes lógicos (LV – lvcreate)

Llegados a este punto, únicamente nos falta crear el volúmen lógico, sobre el que ya añadiremos el sistema de ficheros deseado. Vamos a crear un volúmen lógico de 2G de espacio sobre el grupo creado anteriormente (volgroup_01):

# lvcreate -L2G -n volumen_01 volgroup_01
  Logical volume "volumen_01" created

Y con el comando lvscan vemos el estado de los volúmenes:

# lvscan
  ACTIVE            '/dev/volgroup_01/volumen_01' [2,00 GB] inherit

Ahora ya sólo faltaría darle formato y montarlo como una partición normal:

# mkfs.ext4 /dev/volgroup_01/volumen_01
mke2fs 1.41.4 (27-Jan-2009)
Etiqueta del sistema de ficheros=
Tipo de SO: Linux
Tamaño del bloque=4096 (bitácora=2)
Tamaño del fragmento=4096 (bitácora=2)
131072 nodos-i, 524288 bloques...
...
...
...

# mount /dev/volgroup_01/volumen_01 /temporal/
# df -h | grep temporal
                      2,0G   67M  1,9G   4% /temporal

Añadir nuevas particiones a un grupo volumen (vgextend)

La gracia de LVM es que si disponemos de nuevos discos o particiones podemos añadirlas al grupo de volúmen de forma sencilla. Primero tenemos que crear los volúmenes físicos de esas nuevas particiones (recordad, con pvcreate) y luego asignarlas al grupo de volúmen deseado. Vamos a añadir /dev/sda5 a nuestro grupo volgroup_01:

# pvcreate /dev/sda5
# vgextend volgroup_01 /dev/sda5

Aumentar o reducir el tamaño de nuestro volúmen lógico y sistema de ficheros (lvextend – resize2fs)

Ahora podríamos ampliar si quisiéramos el tamaño de nuestro volumen lógico creado anteriormente porque disponemos de más espacio gracias a las nuevas particiones añadidas al grupo de volúmen. VAmos a añadirle 2G más con el comando lvextend:

# lvextend -L +2G /dev/volgroup_01/volumen_01
  Extending logical volume volumen_01 to 4,00 GB
  Logical volume volumen_01 successfully resized

Finalmente tendríamos que ampliar la última capa, el sistema de ficheros, en nuestro caso es ext4 así que usamos resize2fs. Tened cuidado con este último paso ya que tiene su riesgo y si se hace mal se pueden perder datos:

# resize2fs /dev/volgroup_01/volumen_01 4G
resize2fs 1.41.4 (27-Jan-2009)
Filesystem at /dev/volgroup_01/volumen_01 is mounted on /temporal; on-line resizing required
old desc_blocks = 1, new_desc_blocks = 1
Performing an on-line resize of /dev/volgroup_01/volumen_01 to 1048576 (4k) blocks.
El sistema de ficheros en /dev/volgroup_01/volumen_01 tiene ahora 1048576 bloques.

Y el nuevo tamaño ya queda reflejado:

# df -h | grep temporal
                      4,0G   68M  3,7G   2% /temporal

Espero que os haya sido de utilidad esta introducción a LVM (logical volume manager) en GNU/Linux.

Vamos a ver cómo convertir una partición con el sistema de ficheros ext3 a ext4. Partimos de la base de que tenemos una partición formateada con ext3, en este caso /dev/sda3. La partición se encuentra montada:

# mount | grep ^/dev/sda3
/dev/sda3 on /temporal type ext3 (rw)

Ejecutamos el comando tune2fs para activar las características de ext4 sobre el sistema de ficheros:

# tune2fs -O extents,uninit_bg,dir_index /dev/sda3
tune2fs 1.41.4 (27-Jan-2009)

Por favor ejecute e2fsck sobre el sistema de ficheros.

Tal y como nos indica el comando, ahora tenemos que ejecutar e2fsck para verificar la consistencia del sistema de ficheros y arreglar los cambios de estructura. Para ello antes debemos desmontar la partición:

# umount /dev/sda3

Nota: Si lo estáis haciendo sobre la partición / tendréis que arrancar en modo de emergencia/mantenimiento o con un Live CD para poder hacerlo.

Hacemos el e2fsck:

# e2fsck -fDC0 /dev/sda3 -y

Finalmente ya podemos volver a montar el sistema de ficheros. Ojo, a partir de ahora no hay que montarlo como ext3 sino como ext4. Si lo añadís vía fstab acordaros de cambiar ese parámetro…

# mount /dev/sda3 /temporal/
# mount | grep ^/dev/sda3
/dev/sda3 on /temporal type ext4 (rw)

En fstab:

/dev/sda3                                  /temporal    ext4         defaults           0  0

El otro día hice un artículo en el que veíamos cómo instalar y configurar LDAP (OpenLDAP). Resumiendo un poco, lo que vimos es la instalación propia de OpenLDAP, su configuración básica y la importación de usuarios y grupos de sistema a nuestro directorio. El segundo paso tras esas tareas es la de configurar sshd (OpenSSH) para que pueda autenticarse contra LDAP.

Lo primero que hay que hacer es seguir los pasos del anterior artículo para configurar LDAP correctamente, y sobre todo la sección “Configurar el sistema para autenticar contra LDAP”. Como recordatorio, modificabamos el fichero /etc/nsswitch.conf y le indicabamos que la autenticación a través de passwd/shadow/group también se puede hacer vía LDAP:

passwd:  files ldap
group:  files ldap
shadow:   files ldap

Una vez realizados los pasos indicados en el otro artículo, únicamente nos falta configurar la parte del lado de OpenSSH. Es bastante sencillo, pues todo el trabajo pesado se hace en LDAP. Únicamente tenemos que activar la directiva PAMAuthenticationViaKbdInt en el fichero de configuración /etc/ssh/sshd_config y reiniciar el servicio:

# vim /etc/ssh/sshd_config

Y añadimos la línea:

PAMAuthenticationViaKbdInt yes

Reiniciamos el servicio:

# /etc/init.d/sshd restart

E inmediantamente si hacemos login vía SSH con un usuario creado en el directorio LDAP veremos que funciona correctamente y también que queda registrado en el log correspondiente:

# tail -f /var/log/ldap.log
...
...
Sep 3 12:53:01 cluster01 slapd[2382]: => access_allowed: backend default read access granted to "(anonymous)"
Sep 3 12:53:01 cluster01 slapd[2382]: => access_allowed: read access to "uid=alex,ou=People,dc=ldap-db,dc=com" "uidNumber" requested
Sep 3 12:53:01 cluster01 slapd[2382]: => access_allowed: backend default read access granted to "(anonymous)"
Sep 3 12:53:01 cluster01 slapd[2382]: => access_allowed: read access to "uid=alex,ou=People,dc=ldap-db,dc=com" "gidNumber" requested
Sep 3 12:53:01 cluster01 slapd[2382]: => access_allowed: backend default read access granted to "(anonymous)"
Sep 3 12:53:01 cluster01 slapd[2382]: => access_allowed: read access to "uid=alex,ou=People,dc=ldap-db,dc=com" "homeDirectory" requested
Sep 3 12:53:01 cluster01 slapd[2382]: => access_allowed: backend default read access granted to "(anonymous)"
Sep 3 12:53:01 cluster01 slapd[2382]: => access_allowed: read access to "uid=alex,ou=People,dc=ldap-db,dc=com" "gecos" requested
Sep 3 12:53:01 cluster01 slapd[2382]: => access_allowed: backend default read access granted to "(anonymous)"
...
...

CentOS ha publicado un nuevo repositorio a través de mirror.centos.org. CentOS-5.6 Continuous Release ( CR ) contiene rpms que serán incluidas en la próxima versión de la rama 5.X de CentOS, pero que debido a que son actualizaciones de seguridad y soluciones a bugs conocidos es recomendable instalarlas sin tener que esperar a que salgan a la luz con la nueva versión 5.7, que saldrá aproximadamente en una semana.

Se recomienda encarecidamente activar estos repositorios y actualizar el sistema. Únicamente hay que instalar los siguientes repos y actualizar el sistema. Como ya sabéis se añadirá el nuevo repositorio CentOS-CR.repo en la ruta /etc/yum.repos.d/. Podéis descargar los rpm a continuación:

i386:

http://mirror.centos.org/centos/5.6/cr/i386/RPMS/centos-release-cr-5-6.el5.centos.1.i386.rpm

md5: 67bbeb40cb77a91379847074667d2956
sha256: 50cd9f3d35b391a9009a9caae80182dcfccfa5abaf4ff4ef5f4d880bcf26b04c

x86_64:

http://mirror.centos.org/centos/5.6/cr/x86_64/RPMS/centos-release-cr-5-6.el5.centos.1.x86_64.rpm

md5: c447f54818a657a9dfd7fdd28a28cfcc
sha256: dab390a0fca17612e438b215fc90448ebcef982e96e25cbea8426f00edc8b7a5