Tag: Administración

Migrando cuentas de usuario en LDAP

20 septiembre 2014

Hace tiempo ya que vengo observando un molesto problema con los identificadores numéricos de usuarios (uid) dentro de la red. Sus valores son lo bastante bajos como para colisionar con los usuarios normales que crean algunos paquetes, especialmente aquél que me fuerza a crear la instalación de una nueva máquina y que por el momento (hasta que no tenga automatizado dicho proceso) no puedo evitar.

Necesitaba efectuar un cambio y mover todos los valores numéricos a un rango válido pero fuera de uso. Lo que he hecho ha sido lo siguiente:

  • Instalar el paquete ldap-account-manager y habilitarlo como servicio en https://admin.venexma.net/lam.
  • Crear un perfil que incluyese atributos para una cuenta POSIXy una inetOrgPerson para disponer también de correo electrónico y teléfono móvil.
  • Volver a crear los grupos y los usuarios, ambos con valores numéricos por encima de 10000.
  • Añadir un servicio de cambio de contraseñas para los usuarios:
  • Comenzar el proceso de cambio y  testeo individualmente.
Proceso de cambio

El proceso de cambio de identificador de usuario consiste en:

  • Tomar nota del identificador antiguo y del nuevo.
  • Eliminar la entrada antigua del directorio.
  • Asignar una contraseña a la nueva
  • Buscar archivos asignados al identificador antiguo y cambiarlos por el nuevo:
    • Buscar y reemplazar en los archivos compartidos y los archivos propios en red.
    • Buscar y reemplazar en los archivos de su máquina personal.

El script que empleo para ello es el siguiente:

#!/bin/bash

set -e

#   Variables
VERSION=0.2
LOGFILE="/tmp/$(basename $0).log"

#   Parámetros
OLD_UID=$1
NEW_UID=$2
OLD_GID=$3
NEW_GID=$4

if [ $# -ne 4 ]; then
cat <<EOF >&2
$0 - $VERSION

uso: $0 old_uid new_uid old_gid new_gid

Busca en el directorio actual los archivos que pertenezcan al identificador
antiguo (old_uid) y los cambia al nuevo (new_uid). Realiza después la misma
operación con el grupo antiguo (old_gid) y el nuevo (new_gid).

Directorio actual: $(pwd)
Archivo de registro: $LOGFILE

EOF
exit 1
fi

echo «${0}: Buscando archivos en $(pwd)»

cat <<EOF >$LOGFILE
— $(date)
$(pwd)
cambio de UID ${OLD_UID} a ${NEW_UID}
cambio de GID ${OLD_GID} a ${NEW_GID}
—
EOF

echo -e «tcambiando usuario propietario …»
find . -user $OLD_UID -print -exec chown $NEW_UID {} ; | tee -a $LOGFILE

echo -e «tcambiando grupo propietario …»
find . -group $OLD_GID -print -exec chown $NEW_GID {} ;

echo «${0}: proceso registrado en $LOGFILE»
exit 0

[/sourcecode]

Gestor de contraseñas

12 septiembre 2014

Llevo ya dos días intentando instalar y configurar el gestor de contraseñas teampass con resultados dispares.

La instalación no ha sido complicada, no más allá de descargar, desempaquetar, cambiar permisos y crear la base de datos. La configuración es vía web y se ha encargado de todo sin más problemas.

La configuración sí que está resultando pesada. Una vez con la cuenta del administrador he procedido a seguir estos pasos:

  • Crear roles: administración y gerencia
  • Crear usuarios y asignarles roles: luismi, mariano y yo
  • Crear carpetas y asignar acceso a los roles a éstas.

También he activado la creación de carpetas personales y todo bien hasta que me he encontrado con un problema un tanto absurdo con las rutas de las carpetas upload y files.

En la documentación recomiendan que ambas carpetas estén fuera de la raíz del servidor y eso es lo que he hecho. Mientras que el programa está instalado en /opt/teampass las dos carpetas las he situado en /var/lib/teampass. El problema es que el URL de acceso a teampas (configurable en el panel del administrador) está situada en un subdirectorio de una máquina virtual y entonces no me queda otra que situar un enlace simbólico de /opt/teampass/upload a /var/lib/teampass por lo que dichas carpetas vuelven a estar, teóricamente, en la carpeta raíz del programa.

Veo dos soluciones:

  • Crear alguna regla de reescritura en la configuración del servidor web específica para esos dos sitios (con el programa de no saber si aceptaría más de un componente en el URL de filtrado).
  • Situar la instalación en una máquina virtual concreta: algo como pass.venexma.net.

Tengo que analizarlo con más calma.

Problemas con la impresión en local

10 septiembre 2014

Las máquinas facturacion1 y extranjero se han quedado sin poder imprimir en la red esta mañana. Después de varios reintentos he conseguido que vuelvan a aparecer las impresoras pero no estoy seguro de qué lo ha causado y cómo se ha arreglado.

El problema se encuentra en que cups, el servidor local de impresión, no puede acceder a ciertos puertos en la red para escuchar qué impresoras se ofrecen. He reiniciado los servicios rpcbind, avahi-daemon y cups con varias combinaciones hasta que lo he conseguido.

Sí que he visto en los registros mensajes que hacía tiempo que no veía. Concretamente algo como:

Sep 10 09:49:06 extranjero rpc.idmapd[1783]: nss_getpwnam: name ‘alfredo@venexma.net’ does not map into domain ‘localdomain’

Y es algo que he visto antes pero no consigo saber dónde. Algún detalle de la última instalación, supongo.

 

Arreglando detallitos: el blog, actualizaciones y estadísticas web

9 septiembre 2014

Hoy, entre otras cosas, me propongo reparar tres aspectos de la administración del sistema que no funcionan: la vista del blog de desarrollo desde la intranet, el usuario especial actualizador con el que pongo al día los sistemas y desatascar el analizador de registros del servidor web de venexma.es (y otros) que se hace un lío con registros antiguos.

Navegación interna por el blog de desarrollo

Tan sencillo como activar las reglas de reescritura de direcciones en el archivo htaccess correspondiente. En mi caso, y creo que es norma en Debian, este archivo se sitúa en /etc/wordpress/.htaccess, como enlace procedente de /usr/share/wordpress/.htaccess.

La estrofa es la siguiente:

[apache]

RewriteEngine On

RewriteBase /

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule . /index.php [L]

[/apache]

Usuario especial para actualizar máquinas

En todos los sistemas existe un usuario específico para actualizarlas en remoto y en bloque. Se llama actualizador, tiene la misma contraseña en todas las máquinas (es lo más cómodo, no lo más seguro) y accede desde un punto central (sigfrido) a cada una empleando una clave pública.

Hasta ahora no lo he automatizado por pura pereza, pero cada vez que cambio los componentes de una máquina la conexión se pierde y es necesario volver a hacer lo mismo.

Escribo una pequeña lista de cosas que hacer para poner en marcha una máquina como nodo del mecanismo de actualizaciones remotas:

  1. Instalar el paquete apt-dater-host.
  2. Activar configuración de sudo en el archivo /etc/sudoers.d/apt-dater-host.
  3. Crear un usuario llamado actualizador dentro del grupo adm y con la contraseña habitual registrada en https://admin.venexma.net/passwords.
  4. Accedemos al servidor central (sigfrido) con el usuario actualizador y desde allí copiamos la clave pública en la máquina que estamos configurando. Empleamos para ello ssh-copy-id sin darle más indicaciones que el destino.
  5. Testear ésto último entrando vía ssh a la máquina en configuración desde el servidor. Y cuidado porque es posible que ni así se consiga dado que la dirección IP, la identificación de la máquina o combinaciones de ambas hayan cambiado y sea necesario retocar el archivo ~/.ssh/known_hosts del usuario actualizador en sigfrido.

Martes, 9 de Septiembre

Obviamente ayer no me dio tiempo a completar lo que me proponía, así que esta mañana he tenido trabajo pendiente.

Registros de acceso al servidor web no válidos

Todo el mecanismo de creación de estadísticas web (y disponible aquí) tenía un fallo que impedía que funcionase y, de paso, me inundaba el buzón con mensajes de error. Resulta que los registros generados por el servidor web en venexma.es deben estar en un formato concreto. Si no es así awstats no puede realizar su trabajo y aborta todo el proceso.

La solución ha consistido en efectuar un filtrado previo de los registros para aceptar únicamente aquellos que tienen el formato adecuado. Dado que la configuración de awstats es flexible he creado un programa (incluído en el paquete venexma-sigfrido) que se encarga de este trabajo y de llamar a la herramienta correspondiente.

La configuración de cada dominio para las estadísiticas incluye una línea como la que sigue:

[ini]

LogFile=»/usr/bin/weblog2awstats dominio | »

[/ini]

reemplazando dominio por aquél que queremos procesar (static.venexma.com,venexma.com,…).

 

 

 

Miércoles reconstructivo

18 junio 2014

He comenzado la mañana poniendo reconstruyendo mi equipo y aunque me he encontrado con algunas dificultades por ahora la operación está en marcha. Prueba de ello es que esta entrada la estoy escribiendo desde mi sesión.

La carga del sistema es muy alta en estos momentos. He conseguido que acepte la lista de paquetes de la instalación anterior y estaban pendientes más de 2000. Son muchos años cambiando de versión de sistema operativo sin realizar una limpia real; tampoco es ahora el momento para ello.

También resulta que esta entrada la he escrito como administrador, en lugar de como usuario. Voy a publicarla y luego completaré la historia con otra.