WordPress. El misterioso caso del cuelgue diario a las 9 de la mañana

icono de wordpress Los blogs están muertos. Por fin. Bueno, no todos. Hay alguno que resiste hoy y siempre a la invasión de las redes sociales. A ratos me gusta pensar que este es uno de ellos… pero si soy sincero conmigo mismo ciertamente está un poco desnutrido. No le presto mucha antención, no… Hace meses, por ejemplo, que se cuelga durante aproximadamente media hora todas las mañanas y ni siquiera me he preocupado de ver que le pasa. Bueno, ya no. Ya está arreglado. Los malos hados subestiman el poder de esas tareas tediosas y desagradables que hacen que hasta te den ganas de ponerte a planchar o a limpiar los baños. Bueno, yo me he conformado con arreglar por fin este problemilla. Los baños otro día. 🙂

¿Síntomas mi querido Watson? Apenas nada: la indisponibilidad se producía por un elevado consumo de CPU y mirando con htop resulta que la responsable es mariadb (aunque en el pantallazo aparezca mysql ya sabéis que son compatibles a nivel binario).

htop - mysql se come todo el tiempo de proceso de ambos cores

Alguna pista mas: conéctandome a mariadb observo que lo que se están ejecutando son consultas aparentemente bastante simples sobre la tabla wp_options:

MariaDB [unlugar]> show processlist;
+-------+---------+-----------+---------+---------+------+--------------+------------------------------------------------------------------------------------------------------+----------+
| Id    | User    | Host      | db      | Command | Time | State        | Info                                                                                                 | Progress |
+-------+---------+-----------+---------+---------+------+--------------+------------------------------------------------------------------------------------------------------+----------+
| 29462 | unlugar | localhost | unlugar | Query   | 1043 | Sending data | DELETE a, b FROM wp_options a, wp_options b
			WHERE a.option_name LIKE '\\_transient\\_%'
			AND a. |    0.000 |
| 29552 | root    | localhost | unlugar | Query   |    0 | init         | show processlist                                                                                     |    0.000 |
| 29559 | unlugar | localhost | unlugar | Query   |   40 | update       | INSERT INTO `wp_options` (`option_name`, `option_value`, `autoload`) VALUES ('jetpack_nonce_15275779 |    0.000 |
| 29560 | unlugar | localhost | unlugar | Query   |   22 | updating     | UPDATE `wp_options` SET `option_value` = '1527578481.1030609607696533203125' WHERE `option_name` = ' |    0.000 |
| 29561 | unlugar | localhost | unlugar | Query   |    7 | updating     | UPDATE `wp_options` SET `option_value` = '1527578505', `autoload` = 'yes' WHERE `option_name` = 'jet |    0.000 |
| 29562 | unlugar | localhost | unlugar | Query   |    0 | updating     | UPDATE `wp_options` SET `option_value` = '1527578503.1177010536193847656250' WHERE `option_name` = ' |    0.000 |
+-------+---------+-----------+---------+---------+------+--------------+------------------------------------------------------------------------------------------------------+----------+

Así que le echamos un vistazo a esa tabla y resulta que tiene la friolera de más de 40.000 registros y consume cerca de 38 Megas de espacio ¿Qué tiene dentro?¿Los casos de corrupción del PP? Porque la estructura de la tabla también es bastante simplona:

MariaDB [unlugar]> describe wp_options;
+--------------+---------------------+------+-----+---------+----------------+
| Field        | Type                | Null | Key | Default | Extra          |
+--------------+---------------------+------+-----+---------+----------------+
| option_id    | bigint(20) unsigned | NO   | PRI | NULL    | auto_increment |
| option_name  | varchar(191)        | NO   |     | NULL    |                |
| option_value | longtext            | NO   |     | NULL    |                |
| autoload     | varchar(20)         | NO   |     | yes     |                |
+--------------+---------------------+------+-----+---------+----------------+
4 rows in set (0.01 sec)

Un último dato: la exactitud en la periodicidad me escamaba también. Incluso uno de esos días de puentes con un tiempo maravilloso donde no queda ni el friki más irredento paseándose por algo donde no despachan cerveza el blog también se caía. Y a la misma hora, así que le eché un vistazo al cron del sistema y no había nada que se lanzara a esa hora. ¿Y? De repente recordé que wordpress viene con su propio planificador de tareas y que estas se pueden inspeccionar fácilmente. Por ejemplo a través del plugin WP Cron Cleaner. Bingo. Ahí la tengo: Justo a las 9.04 y todos los días hay una tarea que se llama delete_expired_transients. Y eso de “transient” ya era algo que habíamos visto por ahí arriba en la consulta que se estaba realizando en mariadb.

El proceso que se lanza diariamente alrededor de las 9 realiza una limpieza de transients

Tocaba googlear a ver que es eso de los transients pero ya teníamos datos suficientes para reunir en la biblioteca a todos los implicados y desvelar quien es el asesino.

Los transients, al parecer, son registros con información temporal que proviene de los plugins que tenemos instalados. ¿Sirven para algo? Pues una vez que caducan no, para nada. De hecho precisamente por eso está ahí esa tarea que elimina los caducados. ¿Qué es lo que ocurre entoces? Pues que es evidente que muy bien no funciona porque la mayoría de esos 40.000 registros son transients. Más de 35.000, de hecho. Y la búsqueda se realiza a través del campo wp_options que como vemos no está indexado. Fatal. La primera aproximación al problema pasa, pues, por crear un índice sobre esa columna:

MariaDB [unlugar]> alter table wp_options add index (option_name);
Query OK, 0 rows affected (3 min 47.86 sec)         
Records: 0  Duplicates: 0  Warnings: 0

Mano de santo, oigan. Al día siguiente a las 9.04 por primera vez en meses el blog no se colgó. ¿Lo dejo así?¿Con una tabla diez veces mas grande que el contenido de todo lo escrito en el blog?¿Hasta donde la dejo crecer entonces? Toca hacer otra búsqueda y por ahí me encuentro con mucha mas gente que ha tenido problemas similares y que asegura que se puede hacer tábula rasa y borrarlos todos. Así que hago un backup rápido, los elimino… y parece que todo va bien. Fantástico 🙂

¿Cómo eliminarlos? Pues a través de línea de comando es fácil:

MariaDB [unlugar]> DELETE FROM `wp_options` WHERE `option_name` LIKE ('%\_transient\_%')

Puestos a buscar una solución más cómoda y permanente para no llegar de nuevo aquí dentro de 10 años encontré otro plugin (Transient Cleaner) que te permite borrarlos puntualmente y/o programar una tarea para hacer una limpieza mas efectiva que la de wordpress de forma periódica.

Y listo. O eso parece. Mañana los baños. Sin falta 🙂

Laravel 5.6. Estructura y primeros pasos: Autenticación de usuarios

icono de php Ya yenemos Laravel 5.6 instalado en alguno de los dos entornos que hemos visto antes. ¿Qué sigue? Lo primero, entender un poquito la estructura de directorios que nos ha creado composer. Sólo lo imprescindible. El resto lo iremos viendo a medida que avanzamos.

josemaria@valeria /var/www/html/prueba $ ls -la
total 236
drwxr-xr-x 12 root www-data   4096 mar  9 19:31 .
drwxr-xr-x  3 root www-data   4096 mar  9 18:29 ..
drwxr-xrwx  6 root www-data   4096 ene  3 17:52 app
-rwxr-xrwx  1 root www-data   1686 ene  3 17:52 artisan
drwxr-xrwx  3 root www-data   4096 ene  3 17:52 bootstrap
-rw-r--rw-  1 root www-data   1413 ene  3 17:52 composer.json
-rw-r--rw-  1 root www-data 143565 mar  8 07:37 composer.lock
drwxr-xrwx  2 root www-data   4096 ene  3 17:52 config
drwxr-xrwx  5 root www-data   4096 ene  3 17:52 database
-rw-r--r--  1 root www-data    612 mar  9 19:31 .env
-rw-r--r--  1 root www-data    565 ene  3 17:52 .env.example
-rw-r--r--  1 root www-data    111 ene  3 17:52 .gitattributes
-rw-r--r--  1 root www-data    146 ene  3 17:52 .gitignore
-rw-r--rw-  1 root www-data   1125 ene  3 17:52 package.json
-rw-r--rw-  1 root www-data   1040 ene  3 17:52 phpunit.xml
drwxr-xrwx  4 root www-data   4096 ene  3 17:52 public
-rw-r--rw-  1 root www-data   3550 ene  3 17:52 readme.md
drwxr-xrwx  5 root www-data   4096 ene  3 17:52 resources
drwxr-xrwx  2 root www-data   4096 ene  3 17:52 routes
-rw-r--rw-  1 root www-data    563 ene  3 17:52 server.php
drwxrwxrwx  5 root www-data   4096 ene  3 17:52 storage
drwxr-xrwx  4 root www-data   4096 ene  3 17:52 tests
drwxr-xrwx 36 root www-data   4096 mar  8 07:38 vendor
-rw-r--rw-  1 root www-data    549 ene  3 17:52 webpack.mix.js

El directorio public ejerce de DocumentRoot. Allí encontraremos el index.php que da entrada a nuestra aplicación web así como las hojas de estilos, etc. El fichero .env que vemos aquí arriba en el directorio raiz de nuestra aplicación es el fichero de configuración principal. De hecho, puesto que vamos a empezar a trabajar con bases de datos en este momento podemos aprovechar para editar las siguientes directivas:

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=laravel
DB_USERNAME=laravel
DB_PASSWORD=secreto

Importante: aunque usemos mariadb la directiva DB_CONNECTION debe de ser mysql porque Laravel no entiende otra y, a fin de cuentas, ambas son compatibles a nivel binario. Para que Laravel sea capaz de hacer uso de esa base de datos debemos de crearla. A ella y al usuario que le hemos dicho que va a usar para manejarla. Entramos en nuestro gestor (mysql o mariadb) y ejecutamos lo siguiente:

CREATE DATABASE laravel;
CREATE USER laravel@localhost IDENTIFIED BY 'secreto';
GRANT ALL ON laravel.* TO laravel@localhost;

Vamos ahora a crear nuestro sistema de autenticación. Laravel viene ya con un módulo llamado User.php que reside en el directorio app. Para generar el resto de lo que necesitamos ejecutamos lo siguiente:

php artisan make:auth
php artisan migrate

La primera línea crea el código y rutas necesario para la gestión de usuarios. En particular, creará o modificará los siguientes ficheros:

routes/web.php
resources/views/auth/login.blade.php
resources/views/auth/register.blade.php
resources/views/auth/passwords/email.blade.php
resources/views/auth/passwords/reset.blade.php

La segunda instrucción crea la estructura de tablas necesaria en la base de datos que hemos configurado previamente. Si ahora volvemos a cargar la web de nuestro aplicación veremos que en la esquina superior derecha tenemos dos nuevos enlaces correspondientes a las funcionalidades de Login y Registro:

Laravel 5.6 con la funcionalidad de login y registro

Las pantallas de registro y login por defecto son estas:

Pantalla de registro en Laravel 5.6
Pantalla de login en Laravel 5.6

Y una vez hecho login vemos que en la barra de menú se nos identifica con nuestro nombre de usuario y tenemos la posibilidad de cerrar sesión:

Logout en Laravel 5.6

Si le echamos un vistazo a “las tripas” vemos que nos ha creado dos tablas una de las cuales, la de usuarios, es la que guardará la información relativa a los registros de usuarios.
Tablas creadas por Laravel 5.6 para la autenticación de usuarios

Además, tal y como está mandado, vemos que no almacena las contraseñas en claro sino un hash de las mismas:

hash de las passwords en Laravel 5.6

La castellanización de los recursos es tan sencilla como editar alguno de los ficheros php que hemos indicado anteriormente. Por ejemplo, el fichero login.blade.php es el que contiene la ventana de login y register.blade.php la de registro. Con muy poco esfuerzo tendremos las ventanas anteriores en perfecto castellano. Pero eso ya os lo dejo a vosotros 😉

Chuletillas (y XXXXVIII) – Cambiar el formato de tablas de MySQL o MariaDB de Antelope a Barracuda (para instalar o actualizar Moodle)

chuletaLas últimas versiones de moodle exigen que las tablas usen InnoDB con formato Barracuda en lugar de Antelope. De hecho, en algunos casos puede que la actualización falle sólo por el hecho de no cumplir este requisito y sin que medie ningún comentario informativo acerca de cual es el origen del problema.

Para evitar este problema tenemos que añadir las siguientes líneas en el archivo my.cnf de configuración de mysql o mariadb:

innodb_large_prefix=ON
innodb_file_format=Barracuda
innodb_file_per_table=ON
innodb_file_format_check=ON
innodb_file_format_max=Barracuda

No soy un gran experto en bases de datos, mi lector habitual ya lo sabe, pero tengo entendido que la principal ventaja que aporta Barracuda es la compresión de datos. Quién quiera hablar sobre ello con propiedad puede echarle un vistazo a este texto. En cualquier caso, si quieres seguir usando moodle no tienes mas remedio que pasar por el aro. Son lentejas, ya sabes 😉

Chuletillas (y XXXXV) – Integrar comandos MySQL en un shell script

chuletaExisten diversas formas de integrar comandos de MySQL dentro de un shell script de linux. La más cómoda, creo, es utilizar el parámetro -e del cliente en línea de myql. Por ejemplo, así:

#!/bin/sh
# comandos bash...
mysql -u usuario -p -e "CREATE DATABASE ejemplo;"
#comandos bash...

Lo que pasa es que así puesto sirve de bien poco porque nos va a pedir el password de forma interactiva. Para evitarlo podemos poner la password en el propio archivo del script. No es un método elegante ni especialmente seguro, pero en entornos poco críticos sirve perfectamente:

#!/bin/sh
PASSWORD=mipassword
# comandos bash...
mysql -u usuario --password=$PASSWORD -e "CREATE DATABASE ejemplo;"
#comandos bash...

Por último, si tenemos que ejecutar varios comandos, lo más cómodo es escribirlos uno a continuación de otro en un archivo independiente (con extensión sql por claridad) y ejecutarlos usando el comando source de mysql:

#!/bin/sh
PASSWORD=mipassword
# comandos bash...
mysql -u usuario --password=$PASSWORD -e "source /opt/sripts/imysql/importar_databases.sql"
#comandos bash...
NOTA: Todo lo dicho aquí sirve igualmente para MariaDB

Autenticación en Apache (y II): digest y con mySQL

apache Continuamos hoy con otros dos métodos de autenticación en Apache. El primero que vamos a ver recupera los problemas de gestión de usuarios y contraseñas pero soluciona el problema de la transferencia de contraseñas en claro sin necesidad de usar SSL. Consiste en usar la autenticación mediante digest. El procedimiento, como veréis, es muy similar al visto el otro día con la autenticación básica pero cambiando algunas de las directivas y usando la utilidad htdigest en lugar de htpassword para crear el fichero de contraseñas. El módulo de autenticación necesario suele venir con Apache pero no habilitado por defecto. Para activarlo usamos la utilidad a2enmod y, a continuación reiniciamos el servidor Apache:

$ sudo a2enmod auth_digest
$ sudo /etc/init.d/apache2 restart

Luego incluimos una sección como esta en el fichero de configuración de nuestro Virtual Host:

<Directory "/var/www/miweb/privado">
     Order deny,allow
     AuthType Digest
     AuthName "dominio"
     AuthUserFile "/etc/claves/digest.txt"
     <Limit GET POST>
          Require valid-user
     </Limit>
</Directory>

Como vemos, es muy similar a la configuración necesaria en la autenticación básica. Sólo dos notas: el fichero donde se dejan las contraseñas se indicaba con la directiva AuthDigestFile hasta la versión 2.2 de apache. Ahora, como veis en el ejemplo, es AuthUserFile. Y dos: la directiva AuthName que en la autenticación básica se usaba para mostrar un mensaje en la ventana que pide el usuario y contraseña, ahora se usa también para identificar un nombre de dominio (realm) que debe de coincidir con el que aparezca después en el fichero de contraseñas. Dicho esto, vamos a generar dicho fichero con la utilidad htdigest:

# htdigest -c /etc/claves/digest.txt dominio josemaria
Adding password for josemaria in realm dominio.
New password:
Re-type new password:

Al igual que ocurría con htpassword, la opción -c (create) sólo debemos de usarla al crear el fichero con el primer usuario. Luego añadiremos los restantes usuarios prescindiendo de ella. A continuación vemos el fichero que se genera después de añadir un segundo usuario:

josemaria:dominio:8d6af4e11e38ee8b51bb775895e11e0f
gemma:dominio:dbd98f4294e2a49f62a486ec070b9b8c

El último método que vamos a ver usa una base de datos de mySQL como repositorio de contraseñas. Esto nos permitirá preparar de forma fácil unas páginas para gestionarlas por personal no experto o, incluso, permitir al propio usuario final que haga cambios por si mismo, crear algún método de recuperación automático por email, etc. Esto, combinado con un cifrado SSL, nos proporciona un método cómodo, flexible y suficientemente seguro para la mayoría de los casos. Lo primero que debemos de hacer es instalar el módulo que nos proporciona este modelo de autenticación, activarlo y reiniciar nuestro apache:

$ sudo apt-get install libapache2-mod-auth-mysql
$ sudo a2enmod auth_mysql
$ sudo /etc/init.d/apache2 restart

A continuación necesitamos crear una base de datos adecuada en el servidor mysql. Los únicos campos imprescindibles son los dos correspondientes al usuario y contraseña, tal y como se muestran en la siguiente imagen. El resto, a nuestro gusto y dependiendo de si planeamos hacer alguna página para gestionarlos y las funcionalidades que queremos que tenga (nombre completo, dirección de email, etc.)

base de datos para autenticación con Apache

Necesitaremos, además, un usuario de mySQL con acceso a estas tablas para que Apache pueda usarlo. Con concederle privilegios de lectura (SELECT) nos basta:

usuario para la autenticación

Añadimos un par de registros a nuestra base de datos para hacer pruebas:
usuarios para las pruebas de acceso

Y, por último, editamos la sección correspondiente en la configuración de nuestro Virtual Host y pedimos a apache que haga un reload de la misma:

<Directory "/var/www/miweb/privado">
     AuthType Basic
     AuthName "Zona Privada"
     AuthBasicAuthoritative Off
     AuthMYSQL on
     AuthMySQL_Authoritative on
     Auth_MySQL_Host localhost
     AuthMySQL_DB httpdauthmysql
     AuthMySQL_Password_Table usuarios
     Auth_MySQL_User apacheauth
     Auth_MySQL_Password 4pache3Sql
     AuthMySQL_Username_Field login
     AuthMySQL_Password_Field pwd
     AuthMySQL_Empty_Passwords off
     AuthMySQL_Encryption_Types Plaintext
     Require valid-user
</Directory>

El significado de los campos a personalizar para nuestra configuración es fácilmente distinguible:

  • AuthMySQL_DB y Auth_MySQL_Host determinan los nombres de la base de datos y el servidor donde esta reside, que usaremos para la autenticación de usuarios.
  • Auth_MySQL_User y Auth_MySQL_Password son los datos del usuario que apache usará para leer de la base de datos anterior.
  • AuthMySQL_Password_Table, AuthMySQL_Username_Field y AuthMySQL_Password_Field describen, respectivamente, la tabla donde se guardan las credenciales de los usuarios con permiso de acceso y los campos que usaremos para almacenar sus usuarios y contraseñas.

El campo Auth_MySQL_Encryption_Types, por último, nos permite definir la forma en que la contraseña se guarda en nuestra base de datos y admite múltiples formas. Tal y como está en el ejemplo anterior, indicamos que la contraseña se guardará en texto plano. Si queremos hacerlo un poco más serio y no guardar la contraseña así podríamos, por ejemplo, almacenar un hash de la misma. Existen diversos métodos para esto, pero lo más sencillo es variar el valor de este campo por lo siguiente:

AuthMySQL_Encryption_Types Crypt

Esto nos permitirá usar las mismas firmas generadas por la utilidad htpasswd que vimos aquí o, en general, las creadas a partir de la llamada a la función crypt(). Copiamos el hash al campo pwd de la base de datos antes generada, volvemos a hacer un reload a nuestro apache y listo.

Autenticación en Apache: básica y PAM

apache El servidor web Apache puede acompañarse de distintos módulos para proporcionar diferentes modelos de autenticación. Hoy vamos a echarle un vistazo a la configuración básica de dos de los más utilizados y sencillotes. Vamos allá.

La primera forma que veremos es la más simple. Usamos para ello el módulo de autenticación básica que viene instalada “de serie” con cualquier Apache. La configuración que tenemos que añadir en el fichero de definición del Virtual Host a proteger podría ser algo así:

<Directory "/var/www/miweb/privado">
     Order deny,allow
     AuthUserFile "/etc/apache2/claves/passwd.txt"
     AuthName "Palabra de paso"
     AuthType Basic
     <Limit GET POST>
          Require valid-user
     </Limit>
</Directory>

La información a personalizar está marcada en negritas. En Directory escribimos el directorio a proteger, que puede ser el raíz de nuestro Virtual Host o un directorio interior a este. En AuthUserFile ponemos el fichero que guardará la información de usuarios y contraseñas que debería de estar, como en este ejemplo, en un directorio que no sea visitable desde nuestro Apache. Ahora comentaremos la forma de generarlo. Por último, en AutnName personalizamos el mensaje que aparecerá en la ventana del navegador que nos pedirá la contraseña. Existen otras directivas adicionales o modificaciones a estas útiles para personalizar el acceso: AuthGroupFile, Require user, Require group, etc. Ya sabéis: Google es vuestro amigo 😉

El fichero de contraseñas se genera mediante la utilidad htpasswd. Su sintaxis es bien sencilla. Para añadir un nuevo usuario al fichero operamos así:

# htpasswd /etc/apache2/claves/passwd.txt carolina
New password:
Re-type new password:
Adding password for user carolina

Para crear el fichero de contraseñas con la introducción del primer usuario tenemos que añadir la opción -c (create) al comando anterior. Si por error la seguimos usando al incorporar nuevos usuarios borraremos todos los anteriores, así que cuidado con esto. Las contraseñas, como podemos ver a continuación, no se guardan en claro. Lo que se almacena es el resultado de aplicar una función hash.

josemaria:rOUetcAKYaliE
carolina:hmO6V4bM8KLdw
alberto:9RjyKKYK.xyhk

Para denegar el acceso a algún usuario basta con que borremos la línea correspondiente al mismo. No es necesario que le pidamos a Apache que vuelva a leer su configuración (/etc/init.d/apache2 reload) cada vez que hagamos algún cambio en este fichero de contraseñas, pero si lo es después de hacer los cambios en el fichero de definición del Virtual Host.

autenticación en apache La principal ventaja de este método es su sencillez. Sus inconvenientes: lo incómodo de delegar la generación de nuevos usuarios en alguien que no sea un administrador de sistemas o de hacer un front-end para que sea el propio usuario quien cambie su contraseña. Y, por supuesto, que dichas contraseñas viajan en claro a través de la red. Si queremos evitar esto último podemos crear una instancia Apache con SSL.

El segundo método que vamos a tocar usa PAM, el propio sistema de autenticación de la máquina donde está instalado nuestro servidor de Apache. Si ya tenemos alguna herramienta de gestión de usuarios y contraseñas en la misma este sistema nos ahora el engorro de tener que generar otro tipo de usuario. En caso contrario no ganamos mucho en este sentido y seguimos teniendo el problema de que las contraseñas viajan en claro con el agravante adicional de que ahora se trata de usuarios de la máquina… así que ya sabéis: o configuráis ssl o usáis el truco que comentamos el otro día por aquí para deshabilitar la conexión remota.

Usaremos para ello el módulo mod_auth_pam y lo primero que tenemos que hacer es instalarlo:

# sudo apt-get install libapache2-mod-auth-pam

En el fichero de configuración del Virtual Host tendríamos que incluir algo así:

<Directory "/var/www/privado">
     AuthType Basic
     AuthName "Palabra de paso"
     AuthPAM_Enabled On
     AuthBasicAuthoritative Off
     AuthUserFile /dev/null
     Require user josemaria gemma fernando araceli
</code>

Si en este caso la directiva usada fuese Require valid-user se permitiría el acceso a cualquier usuario con cuenta en la máquina. Ah, y no olvides hacer un reload de apache después de este cambio.

Sólo nos quedan un par de pasos. Primero, añadir el usuario www-data (el que usa apache) al grupo shadow para que pueda verificar las contraseñas:

usermod -a -G shadow www-data

Y dos, hacer un enlace como el que sigue. Ignoro la causa, pero el motivo de que esto sea necesario es debido a que apache (en los binarios de Debian y Ubuntu, al menos) pretende leer del archivo /etc/pam.d/http mientras que el módulo de autenticación ha creado el archvo /etc/pam.d/apache2. El módulo auth_pam hace años que no está soportado e imagino que esto tiene algo que ver, pero no lo se a ciencia cierta. Simplemente lo leí por ahí...

ln -s /etc/pam.d/apache2 /etc/pam.d/httpd

Y con esto está todo listo. No lo he probado nunca pero también he leído que la autenticación se hace contra el directorio activo si Apache está instalado en una máquina windows configurada en un dominio. Existe también un módulo para autenticar contra un ldap (mod_auth_ldap) que si que he probado y que ya veremos otro día 😉