Tuxjm el sitio de jmedina

Category: Servidores (page 2 of 4)

El soporte Xen PVOPS ya esta dentro del kernel Linux

Les traigo una noticia muy importante para aquellos que estan cerca de los entornos de virtualización con Linux, en este caso les hablare de el soporte del kernel Linux para correr en maquinas virtuales Xen DomU y Dom0 sobre el hypervisor Xen.

Desde hace ya algunos años es posible correr un kernel Linux vanila en maquinas virtuales Xen DomU sobre el hypervisor Xen, en un principio con unos parches al kernel Linux (XenLinux), después se integraron los parches en el kernel oficial Linux desde la versión 2.6.27 con PVOPS, el soporte que se incluyo fueron los drivers Xen Bus, network driver además de I/O driver entre otros componentes, esto permite correr el kernel Linux vanilla en hardware fisico como en maquinas virtuales Xen DomU.

El soporte para correr Linux en modo dominio de adminitración o Domain-0 se mantenia por separado, en parches para el ahora algo viejo kernel 2.6.18 o en kernels algo modernos que solo algunas distribuciones lo soportaban no oficialmente, sin embargo, seguian siendo esfuerzos separados.

Ahora todo ha cambiado ya que Linus Torvalds ha aceptado integrar en la rama oficial 2.6.39+ el soporte PVOPS de forma oficial para que Linux corra de forma nativa en entornos fisicos, virtualizados como Xen Domain-0 o DomU y otras alternativas como KVM, estos esfuerzos benefician tanto a la comunidad, equipos de desarrollo y a todos aquellos que estan ya usando Xen para virtualizar sistemas Linux.

Para más información les recomiendo el articulo publicado en los blogs de Oracle: Linux mainline contains all the Xen code bits for Dom0 and DomU, además les recomiendo leer la pagina del wiki Xen paravirt_ops for upstream Linux kernel, donde podrán encontrar más información de el progreso de los componentes integrados.

Como ver el tipo de tabla en MySQL

Aqui les dejo un tip para algo que ya habia requerido más de una vez, como ver el tipo o en especifico el motor de una tabla en MySQL. Esta es una pregunta que me hice hace rato cuando revisaba alguna información sobre respaldos en MySQL.

Para este ejercicio usaremos una base de datos que se llama “Syslog” y tiene una tabla llamada “SystemEvents”, para ver su tipo lanzamos el siguiente query:

mysql> show table status like 'SystemEvents';
+--------------+--------+---------+------------+-----------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+------------+-------------------+----------+----------------+---------+
| Name | Engine | Version | Row_format | Rows | Avg_row_length | Data_length | Max_data_length | Index_length | Data_free | Auto_increment | Create_time | Update_time | Check_time | Collation | Checksum | Create_options | Comment |
+--------------+--------+---------+------------+-----------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+------------+-------------------+----------+----------------+---------+
| SystemEvents | MyISAM | 10 | Dynamic | 288527454 | 153 | 44233702400 | 281474976710655 | 2960958464 | 0 | 288527455 | 2011-02-28 17:50:31 | 2011-04-25 22:13:18 | NULL | latin1_swedish_ci | NULL | | |
+--------------+--------+---------+------------+-----------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+------------+-------------------+----------+----------------+---------+
1 row in set (2.56 sec)

La salida de arriba se ve algo egorrosa porque son muchas columnas, pero el resultado es el de la segunda “Engine” la cual es “MyISAM”, ahi esta :P.

Espero que este tipo les sea de utilidad como lo es para mi.

Xen.org 4.1 Liberado

Así es, ya esta aquí la versión estable de Xen 4.1, despuśe de 11 meses de desarrollo y gracias a las contribuciones de voluntarios y empresas que contribuyen al desarrollo de Xen.org, Aquí les dejo el anuncio oficial (en inglés), ya es hora de probar esta versión y esperemos que se corrijan muchos de los problemas que había en Xen 4.0.

After 11 months of development and 1906 commits later (6 a day !!!), Xen.org is proud to present its new stable Xen 4.1 release. We also wanted to take this opportunity to thank the 102 individuals and 25 organisations who have contributed to the Xen codebase and the 60 individuals who made just over 400 commits to the Xen subsystem and drivers in the Linux kernel.

New Xen Features

Xen 4.1 sports the following new features:

  • A re-architected XL toolstack that is functionally nearly equivalent to XM/XEND
  • Prototype credit2 scheduler designed for latency-sensitive workloads and very large systems
  • CPU Pools for advanced partitioning
  • Support for large systems (>255 processors and 1GB/2MB super page support)
  • Support for x86 Advanced Vector eXtension (AVX)
  • New Memory Access API enabling integration of 3rd party security solutions into Xen virtualized environments
  • Even better stability through our new automated regression tests

Further information can be found in the release notes.

XL Toolstack: Xen 4.1 includes a re-architected toolstack, that is based on the new libxenlightlibrary, providing a simple and robust API for toolstacks. XL is functionally equivalent and almost entirely backwards compatible with existing XM domain configuration files. The XEND toolstack remains supported in Xen 4.1 however we strongly recommend that users upgrade to XL. For more information see the Migration Guide. Projects are underway to port XCP’s xapi and libvirt to the new libxenlight library.

Credit2 Scheduler: The credit1 scheduler has served Xen well for many years.  But it has several weaknesses, including working poorly for latency-sensitive workloads, such as network traffic and audio. The credit2 scheduler is a complete rewrite, designed with latency-sensitive workloads and very large numbers of CPUs in mind. We are still calling it a prototype scheduler as the algorithm needs more work before it will be ready to become the main scheduler. However it is stable and will perform better for some workloads than credit1.

CPU pools: The default credit scheduler provides limited mechanisms (pinning VMs to CPUs and using weights) to partition a machine and allocate CPUs to VMs. CPU pools provide a more powerful and easy to use way to partition a machine: the physical CPUs of a machine are divided into pools.  Each CPU pool runs its own scheduler and each running VM is assigned to one pool.   This not only allows a more robust and user friendly way to partition a machine, but it allows using different schedulers for different pools, depending on which scheduler works best for that workload.

Large Systems: Xen 4.1 has been extended and optimized to take advantage of new hardware features, increasing performance and scalability in particular for large systems. Xen now supports the Intel x2APIC architecture and is able to support systems with more than 255 CPUs. Further, support for EPT/VTd 1GB/2MB super pages has been added to Xen, reducing the TLB overhead. EPT/VTd page table sharing simplifies the support for Intel’s IOMMU by allowing the CPU’s Enhanced Page Table to be directly utilized by the VTd IOMMU. Timer drift has been eliminated through TSC-deadline timer support that provides a per-processor timer tick.

Advanced Vector eXtension (AVX): Support for xsave and xrestor floating point instructions has been added, enabling Xen guests to utilize AVX instructions available on newer Intel processors.

Memory Access API: The mem_access API has been added to enable suitably privileged domains to intercept and handle memory faults. This extents Xen’s security features in a new direction and enables third parties to invoke malware detection software or other security solutions on demand from outside the virtual machine.

Upstreaming

During the development cycle of Xen 4.1, the Xen community worked closely with upstream Linux distributions to ensure that Xen dom0 support and Xen guest support is available from unmodified Linux distributions. This means that using and installing Xen has become much easier than it was in the past.

  • Basic dom0 support was added to the Linux kernel and a vanilla 2.6.38 kernel is now able to boot on Xen as initial domain. There is still some work to do as the initial domain is not yet able to start any VMs, but this and other improvements have already been submitted to the kernel community or will be soon.
  • Xen developers rewrote the Xen PV-on-HVM Linux drivers in 2010 and submitted them for inclusion in upstream Linux kernel. Xen PV-on-HVM drivers were merged to upstream kernel.org Linux 2.6.36, and various optimizations were added in Linux 2.6.37. This means that any Linux 2.6.36 or 2.6.37 kernel binary can now boot natively, on Xen as dom0, on Xen asPV guest and on Xen as PV on HVM guest. For a full list of supported Linux distributions seehere.
  • Xen support for upstream Qemu was developed, such that upstream Qemu can be used as Xen device model. Our work has received a good feedback from the Qemu Community, but is not yet in the mainline.

The Xen development community recognizes that there is still some way to go, thus we will continue to work with upstream open source projects to ensure that Xen works out-of-the-box with all major operating systems, allowing users to get the benefits of Xen such as multi-OS support, performance, reliability, security and feature richness without incurring the burden of having to use custom builds of operating systems.

More Info

Downloads, release notes, data sheet and other information are available from the download page. Links to useful wiki pages and other resources can be found on the Xen support page.

Granja de 35,000 nucleos con Ubuntu, clave para la producción de Avatar

IMPORTANTE: Este articulo es original de TuxRoot y pueden ver la versión original en el URL: http://tuxroot.wordpress.com/2010/01/19/ubuntu-clave-para-la-produccion-de-avatar.

Como señalan , La revolucionaria “Avatar” se ha convertido en una referencia para el futuro del cine en tres dimensiones, pero aquellos que quieran producir una película similar tendrán que tener en cuenta las ingentes necesidades que impone.

Una charla de uno de los administradores de sistemas de Weta Digital -la empresa encargada de los efectos especiales- ha revelado algunos detalles sobre los centros de datos que se utilizaron para una producción que usó  Ubuntu como sistema operativo.

Uno de los asistentes a las conferencias Linux Conf Australia 2010 (LCA2010) ha contado cómo en una de las charlas intervino Paul Gunn, administrador de sistemas en Weta Digital, responsable de los efectos visuales de la película Avatar.

En el post de Dustin Kirkland -que trabaja en Ubuntu Server- se indica que la infraestructura del centro de datos que tuvo que poner en marcha Weta Digital para esta producción fue impresionante. Ya habíamos hablado de la matriz de almacenamiento con capacidad para hasta 2 Petabytes, pero aún hay más detalles.

Entre otros, que se usó una red de conectividad a 10 Gbps, que había más de 4.000 HP Blades con cerca de 35.000 núcleos de proceso en su interior en el centro de datos y 104 Tbytes de memoria RAM en total, y que aún así se tardaba 48 horas en renderizar algunas de las secuencias gráficas.

Según Paul Gunn, responsable de la charla “Challenges in Data Center Growth“, Ubuntu fue el sistema operativo base de todo este desarrollo, y estaba instalado en todos los nodos de renderizado y en el 90% de los PCs de sobremesa de Weta Digital. De hecho, Gunn indicó que su propia “granja de renderizado” hace uso de Ubuntu Server, y no de RHEL como se publicó en algunos medios.

Eso ha permitido generar una película en la cual cada minuto ha ocupado nada menos que 17,28 Gbytes de datos, y curiosamente para refrigerar toda la instalación se limitaron a establecer la temperatura a 25º C, una cifra mayor que la mayoría de centros de datos, pero que les permitió ahorros energéticos importantes

Entre otros, que se usó una red de conectividad a 10 Gbps, que había más de 4.000 HP Blades con cerca de 35.000 núcleos de proceso en su interior en el centro de datos y 104 Tbytes de memoria RAM en total, y que aún así se tardaba 48 horas en renderizar algunas de las secuencias gráficas.

Como deshabilitar el soporte IPv6 en Ubuntu

En diferentes versiones de Ubuntu Desktop y Server se tiene habilitado el soporte IPv6 por default, esto ocaciona que algunas conexiones a Internet se alenten, en especial aquellas relacionadas con el consultas DNS, esto es debido a que la biblioteca resolver por default hace primero una consulta a servidores DNS por IPv6 y hasta que falla hace la consulta por IPv4 lo que para algunos usuarios y administradores no es nada deseable.

En este articulo veremos como deshablitar el soporte IPv6 en Ubuntu en sus diferentes versiones, tanto Escritorio como Servidor, siga las instrucciones especificas para la versión que tenga instalada.

En Ubuntu Server 8.0.4 LTS:

Primero edite el archivo /etc/modprobe.d/blacklist.local y desactive la carga al arranque del sistema del modulo ipv6, por ejemplo:

$ sudo sh -c 'echo "install ipv6 /bin/true" > /etc/modprobe.d/blacklist.local'

Para que los cambios anteriores tomen efecto re incie el sistema:

$ sudo reboot

Después de haber re iniciado el sistema verifique que el modulo ipv6 ya no este cargado:

$ lsmod | grep ipv6

También pude usar ifconfig para verificar que la dirección ipv6 ya no este disponible.

Para Ubuntu 8.04 este metodo fué el único efectivo, hay algunos otros metodos descritos en el articulo WebBrowsingSlowIPv6IPv4 del wiki de la comunidad Ubuntu.

ACTUALIZACIÓN: El método anterior también funciona en Debian Lenny.

El métido anterior no funciona para Ubuntu Karmic 9.10, para desactivar la carga del modulo ipv6 al arranque del sistema en 9.10 debe pasar el parametro ipv6.disable=1 al kernel a través del gestor de arranque.

Para GRUB2 edite el archivo /etc/default/grub y agregue el parametro ipv6.disable=1, por default esta así:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

Cambiela a:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash ipv6.disable=1"

Ahora actualice la configuración de grub:

$ sudo update-grub2

Re inicie el sistema y verifique que el modulo ipv6 no este cargado.

Recursos adicionales:

WebBrowsingSlowIPv6IPv4:
https://help.ubuntu.com/community/WebBrowsingSlowIPv6IPv4

Configuración de Firewall Shorewall de dos interfaces con NAT en Ubuntu Server

Buen día aquí les dejo un nuevo documento que se describe la instalación y configuración de un sistema Firewall para filtrado de paquetes y control de conexiones sobre el sistema operativo Ubuntu Server LTS 8.04.4.

Durante el transcurso del documento realizaremos diferentes tareas de configuración en un Firewall con funciones de enrutado en un sistema con Ubuntu Server LTS 8.04.4, el cual cuenta con dos interfaces de red, una conectada directamente a un router o modem del provedor de Internet y otra conectada al switch de la red local a la que esta conectados varios servidores y PCs de usuario así como impresoras en red. Las tareas más comunes de configuración, administración y monitorización de un Firewall serán descritas en este documento, en la siguiente lista podemos ver las tareas a realizar:

  • Configurar los parametros de red para sistema GNU/Linux dos interfaces de red (Multi-homed)
  • Instalación de los pre requisitos del sistema GNU/Linux para operar como Router y Firewall
  • Instalación y configuración básica del Firewall Shorewall en un sistema con dos interfaces de red
  • Configuración de Ennmascaramiento de IP (MASQUERADING/SNAT) para dar salida a Internet a los usuarios de la LAN de forma segura y controlada
  • Crear reglas de Firewall para Proxy HTTP Transparente
  • Crear reglas de NAT Port Forwarding (DNAT) para redireccionar tráfico desde el Internet a sistemas en la red local
  • Crear reglas NAT One-to-One
  • Configuración de sistema de Logs para el registro de eventos del Firewall Shorewall
  • Monitorizando las conexiones al firewall y ancho de banda
  • Usando los comandos de operación del firewall Shorewall

Para ver el documento en línea vaya a: Configuración de Firewall Shorewall de dos interfaces con NAT en Ubuntu Server.

Si tienen dudas o comentarios acerca del documento no duden en consultarme.

Como ver el ChangeLog de un paquete Debian

Siempre es recomendable leer el ChangeLog o la bitacora de cambios de un paquete ya sea por que queremos estar al tanto de nuevas funcionalidades el paquete actual o en la versión más reciente, verificar los cambios también es recomendable cuando se realice una actualización de un paquete critico en el sistema, por ejemplo, un servicio critico para la empresa es el servicio LDAP, por lo tanto veremos la lista de cambios de la versión más reciente usando aptitude, por ejemplo:

$ sudo aptitude changelog slapd
openldap (2.4.18-0ubuntu1) karmic; urgency=low
* New upstream release: (LP: #419515):
+ pcache overlay supports disconnected mode.
* Fix nss overlay load (LP: #417163).
-- Mathias Gug
Mon, 07 Sep 2009 13:41:10 -0400
openldap (2.4.17-1ubuntu3) karmic; urgency=low
* Install a minimal slapd configuration instead of creating a default
database with a default DIT:
+ Move openldap user home from /var/lib/ldap to /nonexistent.
+ Remove all code and templates dealing with the default database and DIT
creation.
+ Add an Authz map from root user (UID=0) to cn=localroot,cn=config and
grant all access to the latter in the cn=config database as well as the
default backend configuration.
* Add cn=localroot,cn=config authz mapping on upgrades.
— Mathias Gug
Tue, 11 Aug 2009 14:48:56 -0400

Y ahi esta!, ahora veamos si alguno de los cambios pudiera afectar la operación, claro la actualización debe ser creada en un ambiente de producción, la virtualización ofrece esa ventaja a un bajo costo :).

Aun cuando los cambios de la nueva versión no involucre cambios importantes siempre es recomendado respaldar una versión del paquete .deb y dependencias (por si requiere recuperar el sistema y no tiene internet), archivos y directorios de configuración, archivos y directorios de cache, spool, datos y logs de tal forma que podamos restaurar un sistema a un estadio limpio.

Como establecer un nombre de interfaz de red persistentes en Ubuntu Server

En GNU/Linux en la mayoría de las instalaciones el nombre de interfaz de red Ethernet principal es eth0, cada distribución define su propio mecanismo para mapear una interfaz de red con la dirección MAC de la NIC.

Si por alguna razón se cambia la interfaz de red, se cambia la MAC, o por cuestiones raras después de re iniciar el sistema nos damos cuenta de que ya no existe eth0 o que en un sistema con dos o más interfaces de red se intercambiaron los nombres y hemos perdido la conectividad.

En este articulo explicaré como definir un nombre fijo o persistente a una interfaz de red, el nombre de la interfaz estará mapeado a la dirección MAC de la NIC, de esta forma, independientemente de como el sistema detecte las tarejetas, la interfaz con x MAC siempre tendrá el mismo nombre de interfaz.

En Ubuntu Server se usa udev como mecanismo para definir los nombres persistentes para diferentes dispositivos, a continuación les explico un caso común de cambio de interfaz de red.

Nuestro sistema siempre funcion con eth0 conectado a la LAN, la interfaz fisica se daño y la remplazamos con una nueva, después de reiniciar el sistema nos damos cuenta de que no tenemos red, aquí un procedimiento común para diagnosticar la red en GNU/Linux.

– Verficiar si la interfaz eth0 esta activa:

# ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:58 errors:0 dropped:0 overruns:0 frame:0
TX packets:58 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:4020 (4.0 KB) TX bytes:4020 (4.0 KB)

Como podemos eth0 no esta activa, veamos todas las interfaces de red disponibles en el sistema:

# ifconfig -a
eth1 Link encap:Ethernet HWaddr 00:1d:72:e7:ce:f4
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:544089 errors:0 dropped:0 overruns:0 frame:0
TX packets:415730 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:492809586 (492.8 MB) TX bytes:102066321 (102.0 MB)
Interrupt:17

Note que eth0 no existe y en su lugar vemos una interfaz eth1, esto es porque el sistema udev tiene almacenada una configuración donde la MAC de la vieja NIC estaba mapeada a eth0, y como instalamos una nueva tarjeta reservo eth0 para la otra NIC y asigno eth1 a la nueva.

Para mantener nuestras configuraciones anteriores de red y sigamos usando eth0 para la nueva NIC, configuraremos udev para realizar el mapeo.

Editamos el archivo de mapeo de interfaces de red de udev:

# vim /etc/udev/rules.d/70-persistent-net.rules

La configuración anterior esta así:

# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="40:61:86:0d:2c:e7", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
# PCI device 0x14e4:0x1684 (tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1d:72:e7:ce:f4", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

Veamos que hay dos configuraciones una para eth1 y eth1, para resolver el problema podemos eliminar la configuración anterior para eth0 y en la linea que mapea la interfaz tg3 a eth1, realice los cambios:

Cambiar:
NAME="eth1"

Por
NAME="eth0"

Al final su archivo va a quedar:

# PCI device 0x14e4:0x1684 (tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1d:72:e7:ce:f4", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

Verifique su archivo /etc/network/interfaces para ver que aun esta su configuración de red para eth0.

Si tiene un sistema con multiples interfaces de red y se intercambiaron los nombres puede usar ethtool(8) o mii-tool(8) para indentificar cada interfaz por el enlace fisico y así identifique el MAC de cada interfaz.

Se recomienda que reinicie el sistema para que todo arranque correctamente y que los servicios que dependen de la red inicien con la red apropiada.

Como verificar si una interfaz de red en GNU/Linux tiene enlace fisico

Uno de los promeros diagnosticos para verificar si un servidor Linux tiene conectividad es verificar el enlace fisico a nivel Ethernet, en GNU/Linux podemos verificar y cambiar ciertos parametros a nivel Ethernet para una NIC usando el program ethtool.

Para verificar el enlace fisico de la interfaz de red eth0 use ethtool:

# ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: g
Wake-on: g
Current message level: 0×000000ff (255)
Link detected: no

La información importante es la de “Link detected“, como podemos ver en el ejemplo podemos ver que no hay enlace fisico, puede revisar la conectividad desde el cable, patch panels o switches, una interfaz de red con enlace fisico se debe ver:

# ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: g
Wake-on: g
Current message level: 0×000000ff (255)
Link detected: yes

Si la prueba de enlace fisico pasa ahora puede empezar a usar ping :).

En algunas distribuciones no se incluye el programa ethtool ya que incluyen el programa mii-tool(8)que también lo puede usar para validar
la conectividad fisica, por ejemplo:

# mii-tool eth0
eth0: negotiated 100baseTx-FD flow-control, link ok

Referencias:

man ethtool(8)
man mii-tool(8)
man ping(8)

Como respaldar y restaurar una base de datos de OpenLDAP

Como buen administrador siempre procuramos tener una copia de seguridad reciente de las bases de datos de las apliaciones que administramos para poder re establecer el sistema en caso de desastre.

En este articulo explicare como crear una copia de seguridad de una base de datos en un servidor OpenLDAP, generaremos respaldos en frio y en caliente, los respaldos serán generados en formato LDIF.

Suponiendo que en el archivo slapd.conf(5) tenemos una definición de base de datos así:

# Specific Backend Directives for hdb:
backend hdb
# Specific Directives for database #1, of type hdb:
database hdb
# The base of your directory in database #1
suffix "dc=example,dc=com"
# Where the database file are physically stored for database #1
directory "/var/lib/ldap"

El programa slapcat(8) lee la información de la base de datos en orden secuencial y genera la salida correspondiente en formato LDIF incluyendo atributos de usuario y operacionales, el programa slapcat solo respaldara las entradas que se leyeron en el momento de la ejecución, si en el momento de que slapcat esta ejecutandose se realiza una operación de escritura sobre alguna entrada dicho cambio no será incluido en el respaldo.

En OpenLDAP las bases de datos de tipo hdb y bdb pueden ser respaldadas mientras el servicio slapd(8) esta en ejecución usando el programa slapcat, a este tipo de respaldo se le llama en caliente.

Si no esta seguro de que no habrá modificacioens en los datos de las bases de datos de OpenLDAP y no sabe si dichos cambios puedan afectar las aplicaciones o clientes LDAP se recomienda que detenga el servicio slapd antes de generar el respaldo con slapcat, a este tipo de respaldo se le llama en frio.

Para crear un respaldo en frio de una base de datos de OpenLDAP siga el siguiente procedimiento:

1.- Detener el servicio slapd:

# /etc/init.d/slapd stop

2.- Respaldar la base de datos usando el programa slapcat:

# slapcat -b dc=example,dc=com -l respaldo-dc=example,dc=com-`date +%d-%b-%Y`.ldif

El comando slapcat generará un respaldo de la base de datos dc=example,dc=com definida por el parametro -b en el archivo respaldo-dc=example,dc=com-`date +%d-%b-%Y`.ldif definido por el parametro -l.

Para crear un respaldo en caliente de una base de datos de OpenLDAP solo ejecute el comando slapcat como en el paso dos del ejemplo anterior.

Se recomienda que el archivo del respaldo sea movido a un lugar fuera del servidor.

Para restaurar la base de datos a partir del archivo LDIF generado por slapcat siga el siguiente procedimiento:

1- Apagar el servicio slapd:

# /etc/init.d/slapd stop

2.- Limpiar el directorio de base de datos de slapd:

# (cd /var/lib/ldap/; rm -fv alock __db.* *.bdb log.*)

3.- Restaurar directorio a partir del archivo LDIF:

# slapadd -v -b dc=example,dc=com -l respaldo-dc=example,dc=com-`date +%d-%b-%Y`.ldif

– Opcionalmente Re indexe todos los atributos :

# slapindex -v

– Re establecer permisos al directorio de datos:

# chown -R openldap:openldap /var/lib/ldap

– Iniciar el servicio slapd:

# /etc/init.d/slapd start

Referencias:

El formato LDIF
man slapd.conf(5)
man slapd(8)
man slapcat(8)
man slapadd(8)
OpenLDAP Software 2.4 Administrator’s Guide – Directory Backups

Olderposts Newerposts

Copyright © 2019 Tuxjm el sitio de jmedina

Theme by Anders NorenUp ↑