Me ha resultado difícil concretar el problema en tan poco espacio en el título. La situación es la siguiente:

• Sun LDAP Server
• Cliente Red Hat Enterprise Linux con LDAP nativo configurado contra el servidor de Sun

La configuración del LDAP Nativo en Red Hat es relativamente sencilla, únicamente lanzamos el authconfig-tui o pasamos los parámetros correspondientes al comando authconfig. Una vez configurado, ya deberíamos poder autenticarnos con los usuarios del LDAP.

En este caso concreto, todo funcionaba correctamente a excepción de la autenticación. Si hacíamos su desde root a cualquier usuario del LDAP funcionaba, la salida del comando getent passwd o getent shadow mostraba todos los usuarios, podíamos hacer ldapsearch, etc.

Con la autenticación, nos pedía continuamente cambiar la password porque había expirado:

$ ssh test@10.0.0.15
You are required to change your LDAP password immediately.
Warning: Your password has expired, please change it now
...
...

Por lo que sea, los servidores Solaris en nuestro caso hacían caso omiso a los atributos de expiración, llevabamos años sin problemas, pero RHEL sí que los revisaba. Todo debería haber funcionado una vez cambiada la clave, pero los servidores RHEL seguían pidiendo continuamente que se cambiara (en Solaris sí que se accedía con la nueva clave).

Para poder acceder correctamente desde Red Hat (y creo que desde cualquier máquina Linux) hay que prestar especialmente atención a estos atributos de LDAP para cada usuario:

shadowMax:
shadowMin:
shadowWarning:

Si están presentes, es necesario que su valor este vacío (no 0) para solucionar el problema. O eso, o especificar una expiración de 99999 en shadowMax… una vez cambiado accederéis sin problemas vía ssh  y con el resto de autenticación.

La utilidad de monitorización en servidores Web de Sun/Oracle ha mejorado mucho a partir de la versión 7.0. Si bien antes únicamente podíamos acceder a estos datos vía web, ahora podemos hacerlo a través de la shell/CLI wadm, permitiendo acceder a estadísticas a tiempo real de monitorización sin necesidad de hacerlo vía HTTP, con los problemas que conllevaba con el sistema cargado.

La nueva versión, disponible en Sun Java System Web Server, Oracle iPlanet Web Server 7.0 o como lo queráis llamar, añade la posibilidad de ver las Ips y peticiones que se están haciendo a cada instancia y así poder detectar con mayor facilidad el origen de un cuello de botella o sobrecarga del sistema.

Para acceder a wadm nos situamos en la ruta base del servidor web y ejecutamos el siguiente comando indicando usuario y clave de administración:

root@solaris:/opt/oracle/webserver7# ./bin/wadm --user=admin
Indique admin-user-password>
Conexión a localhost:8989
Oracle iPlanet Web Server 7.0.12 B07/01/2011 03:56
wadm>

Una vez dentro, elegimos la instancia y nodo del que queremos ver las estadísticas y tendremos el volcado de información:

wadm> get-perfdump --config solaris --node localhost

La información que recibimos es la siguiente. Tened en cuenta que es un webserver de prueba por lo que no hay apenas información:

wadm> get-perfdump --config solaris --node localhost

Oracle iPlanet Web Server 7.0.12 B07/01/2011 03:56 (SunOS DOMESTIC)

Server started Sat Feb 11 15:24:28 2012
Process 1133 started Sat Feb 11 15:24:29 2012

ConnectionQueue:
-----------------------------------------
Current/Peak/Limit Queue Length            0/4/16384
Total Connections Queued                   20
Average Queue Length (1, 5, 15 minutes)    0,00, 0,00, 0,00
Average Queueing Delay                     10,88 milliseconds

ListenSocket http-listener-1:
------------------------
Address                   https://0.0.0.0:443
Acceptor Threads          1
Default Virtual Server    solaris

ListenSocket http-listener-2:
------------------------
Address                   http://0.0.0.0:80
Acceptor Threads          1
Default Virtual Server    solaris

KeepAliveInfo:
--------------------
KeepAliveCount        6/32768
KeepAliveHits         8
KeepAliveFlushes      0
KeepAliveRefusals     0
KeepAliveTimeouts     6
KeepAliveTimeout      30 seconds

SessionCreationInfo:
------------------------
Active Sessions           0
Keep-Alive Sessions       6
Total Sessions Created    8/129

CacheInfo:
-----------------------
File Cache Enabled       yes
File Cache Entries       14/1024
File Cache Hit Ratio     76/108 ( 70,37%)
Maximum Age              30
Accelerator Entries      0/1024
Acceleratable Requests   18/45 ( 40,00%)
Acceleratable Responses  0/18 (  0,00%)
Accelerator Hit Ratio    0/0 (  0,00%)

Native pools:
----------------------------
NativePool:
Idle/Peak/Limit               1/1/128
Work Queue Length/Peak/Limit  0/0/0

DNSCacheInfo:
------------------
enabled             yes
CacheEntries        0/1024
HitRatio            0/0 (  0,00%)

Async DNS disabled

Performance Counters:
------------------------------------------------
                           Average         Total      Percent

Total number of requests:                     20
Request processing time:    0,0395        0,7899

default-bucket (Default bucket)
Number of Requests:                           20    (100,00%)
Number of Invocations:                       289    (100,00%)
Latency:                    0,0050        0,0999    ( 12,65%)
Function Processing Time:   0,0345        0,6899    ( 87,35%)
Total Response Time:        0,0395        0,7899    (100,00%)

Sessions:
-------------------------------------------------------
Process  Status  Client  Age  VS  Method  URI  Function

Resultan muy interesantes para detectar problemas y optimizar el rendimiento la sección “ConnectionQueue:” y “Sessions:“, en esta última es donde veremos las Ips de acceso, peticiones, URI, etc. Toda la información es bastante descriptiva y comprensible a primera vista. A partir de esta información se pueden generar scripts de recolección de datos, añadir a monitorización tipo Nagios o BigBrother, etc. Los que utilicéis servidores anteriores a la versión 7.0 habréis detectado un gran cambio de la cantidad de información del antiguo perfdump al nuevo.

Evidentemente existen muchas maneras de monitorizar MySQL, por ejemplo con cacti, MyTop, etc. No obstante he encontrado una aplicación propia de Sun/MySQL muy interesante, se trata de MySQL Query Analyzer.

Captura oreilly.com

Como se observa en la captura de pantalla, se trata de una interfaz web sobre la que podemos monitorizar y recolectar datos de los servidores MySQL que necesitemos, destaca la monitorización a tiempo real de queries en el servidor, rápida identificación de problemas en las queries, detalle de las queries y debug para solucionar y optimizar consultas mal construidas con explain. Por supuesto hay un historico de consultas, posibilidad de buscar, ordenar, etc.

Puedes descargarlo y encontrar más información en este enlace.