El navegador Google Chrome o Chromium usa la biblioteca Mozilla NSS para el soporte SSL/TLS, para instalar el certificado raíz vamos a requierir el programa certutil parte del paquete libnss3-tools.
Instalamos el paquete libnss3-tools:
$ sudo aptitude install libnss3-tools
Ahora descargamos el certificado raíz:
$ wget http://mail.e-compugraf.com/ca.crt -O ~/Compugraf-rootca.crt
Instalamos el certificado raíz en el llavero local:
$ certutil -d sql:$HOME/.pki/nssdb -A -t TC -n "compugraf.com" -i ~/Compugraf-rootca.crt
Listo, ahora si abra google chrome y vaya al sitio seguro para el cual quiere validar la autenticidad mediante el certificado raíz y vea que ya no aparece la tache roja :).
En este post les explicare como instalar el navegador Google Chrome en Kubuntu 9.10, creo que vale la pena probar este nuevo navegador.
Primero descargue el paquete .deb del sitio: http://www.google.com/chrome/eula.html?hl=es, ya que yo uso una distribución AMD64 me descargue el que dice ".deb de 64 bits (para Debian/Ubuntu)".
Ahora instalamos el paquete con dpgk:
$ sudo dpkg -i ~/Downloads/google-chrome-beta_current_amd64.deb
Y listo, ahora puede ejecutar en una consola el programa google-chrome o ir al menú K=>Applications=>Intermet y dar clic en Google Chrome.
Espero poder usar este navegador y dar mis comentarios.
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.
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 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
En OpenLDAP el DN definido en la directiva rootdn del archivo slapd.conf(5) no es sujeto a las restricciones impuestas por las ACLs, ya que esta es una cuenta privilegiada se recomienda que se asigne una contraseña fuerte y que dicha cuenta solo se use para tareas que requieran privilegios elevados.
Para cambiar o asignar una nueva contraseña al rootdn sigamos el siguiente procedimiento:
- En el archivo slapd.conf(5) tenemos nuestra definición de base de datos tenemos las siguientes directivas:
rootdn cn=Manager,dc=example,dc=com rootpw secret
En este ejemplo la contraseña del rootdn esta en texto plano, para cambiarla y y protegerla usando un hash criptográfico generamos el hash de contraseña con el programa slappasswd:
# slappasswd
New password:
Re-enter new password:
{SSHA}VanYekdrphCkbjDffLCXbBsxsg3QJBI6NOTA: El hash predefinido es SSHA, si desea cambiar el tipo de hash use la opción -h para definir un hash diferente, por ejemplo: -h {CRYPT}, para más información vea la pagina del manual de slappasswd(8).
Copie el HASH {SSHA}VanYekdrphCkbjDffLCXbBsxsg3QJBI6 y cambielo en el valor rootpw del archivo slapd.conf(5).
IMPORTANTE: Asegurese de que el archivo slapd.conf(5) tenga los permisos adecuados, por ejemplo en Debian/Ubuntu se recomiendan los permisos: root:openldap / 640.
Para que el cambio tome efecto reinicie el servicio LDAP:
# /etc/init.d/slapd restart
Tambien puede mantener la contraseña del rootdn fuera del archivo slapd.conf(5), es decir, puede eliminar la directiva rootpw del archivo slapd.conf(5) y agregar una entrada para el DN en el directorio LDAP.
Los beneficios que obtenemos al mantener la entrada el rootdn en el directorio son:
- Puede actualizar la contraseña de forma dinamica sin reiniciar el servicio usando una operación de modificación desde cualquier cliente LDAP.
- Si olvida la contraseña siempre puede realizar la configuración manual usando slappasswd(8) y slapd.conf(5).
Para mantener la entrada del RootDN en el directorio LDAP siga este procedimiento:
- Cree una entrada en el directorio usando el archivo LDIF:
dn: cn=Manager,dc=example,dc=com
cn: Manager
sn: Manager
objectClass: person
objectClass: top
userPassword: {SSHA}someSSHAdata- Agrega el LDIF usando ldapadd:
# ldapadd -v -x -D "cn=Manager,dc=example,dc=com" -W -h localhost -f rootdn.ldif
Se recomienda que no use la cuenta cn=Manager,dc=example,dc=com en sus tareas de administración de rutina, en su lugar se recomienda que cree una cuenta privilegiada para tales propositos, por ejemplo en Debian/Ubuntu se usa el DN de la cuenta cn=admin,dc=example,dc=com la cual ya tiene los ACLs predefinidos para que tenga permisos completos sobre la base de datos predefinida.
Referencias:
OpenLDAP Software 2.4 Administrator’s Guide - Access Control
Cuando usa OpenLDAP con backends basados en BerkeleyDB por ejemplo el backend tipo hdb debe de tener indexados los atributos más utilizados en las consultas LDAP y así incrementar el rendimiento en las consultas desde las aplicaciones y clientes LDAP, un ejemplo de un atributo no indexado lo podemos ver en los logs de OpenLDAP:
slapd[4164]: <= bdb_equality_candidates: (uniqueMember) not indexed
El mensaje anterior nos muestra que se estan haciendo consultas para el atributo uniqueMember y no esta indexado lo cual se puede reflejar en bajo rendimiento del servicio LDAP.
Para agregar uno o más atributos a la lista de indices para una base de datos en OpenLDAP debe de seguir el siguiente procedimiento:
- Agregar definición de indice para los atributos deseados al archivo de configuración del servicio OpenLDAP:
# vim /etc/ldap/slapd.conf
NOTA: Estas tareas se realizan sobre distribuciones basadas en Debian como Unbuntu.
Bajo la definición de la base de datos en cuestion agregue los indices:
index memberUid,uniqueMember eq
En este caso agregamos los atributos memberUid y uniqueMember de tipo Equality.
Si solo reinicia el servicio slapd solo se indexarán los atributos para las nuevas entradas, para que los atributos existentes también sean indexados debe detener el servicio slapd y ejecutar el programa slapindex, por ejemplo:
Detener servicio slapd:
# invoke-rc.d slapd stop
Indexar los atributos memberUid y uniqueMember:
# slapindex -v memberUid uniqueMember
Re establecer permisos para archivos de bases de datos de slapd:
# chown -R openldap:openldap /var/lib/ldap
Ahora ya puede iniciar el servicio slapd con todos los atributos indexados.
# invoke-rc.d slapd stop
Referencias:
Desde hace tiempo vengo haciendo este documento pero creo que no lo había hecho público, creo que solo lo estuve posteando en listas de correo, foros y otros lugares, bueno creo que ya es un documento bastante maduro como para publicarlo.
Aquí les dejo el documento de configuración de Controlador de Dominio con Samba y OpenLDAP en Ubuntu Server 8.04, la implementación de este servidor nos ayudará a mantener de forma centralizada la información de usuarios, grupos y equipos de red, ya sea para equipos GNU/Linux o Windows.
La autenticación y autorización de clientes GNU/Linux se realizará con los el modulo de resolución de nombres NSS LDAP y los modulos de autenticaicón PAM LDAP, para clientes Windows la autenticación la realiza el servidor Samba que actuará como Controlador de Dominio (PDC) al estilo NT4.
Aquí les dejo el temario para que se den una idea:
Tabla de contenidos
1. Introducción
2. Caracteristicas de la Implementación
3. Requerimientos de Software
4. Instalación y Configuración del servidor OpenLDAP
5. Configuración del Cliente LDAP
6. Configuración de Samba y las herramientas smbldap-tools
7. Configuración de la resolución de Identidades con NSS_LDAP
8. Configuración de la Autenticación con PAM_LDAP
9. Migración de usuarios y grupos Unix/Posix al directorio LDAP
10. Administración de cuentas Unix y Samba vía smbldap-tools
11. Tareas Administrativas y de Mantenimiento sobre el servidor Slapd
12. Integrando Clientes Windows al Dominio Samba
13. Integrando Clientes Linux/Unix al Dominio Samba
14. Resolución de Problemas
15. Referencias adicionales
16. Apendices
A. Licencia de Documentación Libre de GNU
ACTUALIZACIÓN 23 Febrero de 2010:
He realizado varias actualizaciones al documento, les dejo un extracto del historial de revisiones:
| Revisión 0.88 | 2010-02-07 | jam |
| - Correji varios errores de en las sintaxis de comandos y configuraciones, revise el proceso de instalacion ya que habia un problema para seguir el asistente, varias mejoras en secciones de indices y acls. - Correji el orden de configuracion de los logon scripts | ||
| Revisión 0.89 | 2010-02-22 | jam |
| Actualización del capitulo de instalación openldap - Cambios en el DIT para reflejar ou=Computers Actualización del capitulo de mantenimiento con secciones - Asignar contraseña a rootdn - Respaldar y restaurar archivos de configuración y bases de datos OpenLDAP - Agregar nuevos indices de atributos en OpenLDAP - Ligar sección de atributos en capitulo de instalación | ||
Para leer el documento en formateado en multiples paginas HTML ir al siguiente enlace:
Configurar un servidor Controlador de Dominio con Samba y OpenLDAP en Ubuntu Server Hardy 8.04
NOTA: Por el momento solo tengo la versión HTML con capitulos/secciones por separado, espero poder preparar una versión HTML de una sola pagina para que así puedan imprimir el documento por ejemplo usando aplicaciones web como PrintFiendly.
Espero que el documento les sea de ayuda al configurar un entorno similar, si tienen alguna dudas, comentarios o desean colaborar con la edición del documento no duden en contactarme usando la forma de contacto en este sitio.
View comments (1)