adduser: cuando necesitas añadir muchas cuentas

Y es que sigo con mi propósito de facilitar la creación de copias de seguridad y hasta ahora he visto que lo más usable son las cuentas de sistema.

Porque sí, las cuentas virtuales están muy bien para otras cosas como el correo, la validación de credenciales o el acceso a sistemas de archivos exóticos, pero cuando necesitas interactuar con un conjunto de herramientas como las disponibles en un Linux (Debian en mi caso) el uso de la norma es lo más sólido.

Así que he aprovechado para estudiar un poco más sobre la herramienta adduser que se incluye en Debian y lo primero que he buscado son las diferencias entre ella y useradd que es más conocida.

La respuesta más precisa la he encontrado en los foros de StackOverFlow (para variar) que viene a decir que adduser es una herramienta de mayor nivel que useradd, que emplea un archivo de configuración específico en /etc/adduser.conf y que abarca más aspectos sobre la creación de cuentas en Debian. Es, pues, más recomendable, aunque no hay nada que haga una que no pueda hacer la otra.

La configuración

El archivo /etc/adduser.conf limita y guía el funcionamiento de la herramienta; las opciones más interesantes que he encontrado son:

DHOME=/home
LETTERHOMES=no
SKEL=/etc/skel
QUOTAUSER=""
EXTRA_GROUPS="dialout cdrom floppy audio video plugdev users"
ADD_EXTRA_GROUPS=1

Todo ello referido a los usuarios normales, aquellos que no se consideran de sistema.

El directorio de trabajo

La variable SKEL indica un directorio que emplear como molde cuando se crea el directorio de trabajo del usuario (HOME) y es allí donde se pueden incluir algunas cosas interesantes.

Por ejemplo se puede añadir un directorio para las conexiones ssh y otro para facilitar la publicación de contenido vía web.

root@gladius:/etc# tree /etc/skel/
/etc/skel/
└── public_html

1 directory, 0 files
root@gladius:/etc# tree -puag /etc/skel/
/etc/skel/
├── [-rw-r--r-- root     root    ]  .bash_logout
├── [-rw-r--r-- root     root    ]  .bashrc
├── [-rw-r--r-- root     root    ]  .kshrc
├── [-rw-r--r-- root     root    ]  .profile
├── [drwxr-xr-x root     root    ]  public_html
└── [drw------- root     root    ]  .ssh

2 directories, 4 files

Y el siguiente usuario que creemos su directorio de trabajo estará así:

root@gladius:~# adduser coco
Añadiendo el usuario `coco' ...
Añadiendo el nuevo grupo `coco' (1003) ...
Añadiendo el nuevo usuario `coco' (1003) con grupo `coco' ...
Creando el directorio personal `/home/coco' ...
Copiando los ficheros desde `/etc/skel' ...
Introduzca la nueva contraseña de UNIX: 
Vuelva a escribir la nueva contraseña de UNIX: 
passwd: contraseña actualizada correctamente
Cambiando la información de usuario para coco
...
¿Es correcta la información? [S/n] s
root@gladius:~# tree -puag /home/coco/
/home/coco/
├── [-rw-r--r-- coco     coco    ]  .bash_logout
├── [-rw-r--r-- coco     coco    ]  .bashrc
├── [-rw-r--r-- coco     coco    ]  .kshrc
├── [-rw-r--r-- coco     coco    ]  .profile
├── [drwxr-xr-x coco     coco    ]  public_html
└── [drw------- coco     coco    ]  .ssh

2 directories, 4 files

Ya tiene un directorio .ssh con los permisos correctos y un directorio que emplear con el servidor web Apache y el correspondiente módulo para que pueda servir contenido empleando el URL http://localhost/~coco.

Los permisos se copian tal cual, el usuario y el grupo, obviamente no.

Sin embargo esta configuración es un poco exagerada cuando lo que queremos es que un grupo concreto de cuentas de usuario dispongan de una estructura de carpetas específica.

Usuarios para copias de seguridad

¿ Podemos emplear lo anterior para facilitar la creación de usuarios que, siendo del sistema, tengan unas características especiales ? Pues sí, siempre que sepamos qué queremos exactamente.

Supongamos que estamos creando un servidor de copias de seguridad; llamamos al proyecto spaces en un alarde de originalidad y queremos que las cuentas elegidas dispongan de un acceso seguro a una parte del disco (de las cuotas ya hablo otro día).

Hemos elegido conexiones sftp para ello (aunque también pueden emplearse scp y rsync al mismo tiempo) y necesitamos que dichos usuarios tengan:

  1. Un nombre que empiece por la secuencia sp_ seguida de su número, nada de nombres reconocibles.
  2. Un directorio de trabajo bajo /srv/backups.
  3. Un shell limitado como /usr/bin/rssh.
  4. Un identificador de usuario que esté situado en un margen especial. Si en Debian los usuarios normales están entre el el 1000 y el 29999 los nuestros se situarán a partir del 15000.
  5. Un grupo compartido para asignarles otro tipo de facilidades. Pongamos que creamos el grupo spaces con el identificador numérico 15000 y que queremos que sea el predeterminado para todos ellos.
  6. La estructura básica de su directorio será diferente y, por tanto, no podrá tomarse de la habitual en /etc/skel..

La manera más sencilla de conseguir esto es indicarle a adduser que utilice otro archivo de configuración. Éste puede tener un aspecto similar al siguiente:

# Guardado bajo /etc/spaces.conf
DSHELL=/usr/bin/rssh
DHOME=/srv/backups
SKEL=/etc/skel-backups
FIRST_UID=15000
FIRST_GID=15000
DIR_MODE=0750
SETGID_HOME=yes
QUOTAUSER=""
EXTRA_GROUPS=spaces
ADD_EXTRA_GROUPS=1
NAME_REGEX="^sp_[0-9]*\$"

Aunque antes de proceder con la creación de usuarios tendríamos que crear el directorio de plantillas al que hacemos referencia en la configuración (en este ejemplo lo he creado en mi directorio temporal):

victor@gladius:~/tmp $ tree -puag skel-backup
skel-backup
├── [-rw-r--r-- victor   victor  ]  .profile
├── [-rw-rw-r-- victor   victor  ]  README
└── [drw------- victor   victor  ]  .ssh

1 directory, 2 files

Y, por supuesto el grupo que indicamos como principal cuando creamos el usuario:

victor@gladius:~/tmp$ sudo addgroup --conf ./spaces.conf --force-badname spaces
Permitiendo el uso de un nombre de usuario dudoso.
Añadiendo el grupo `spaces' (GID 15000) ...
Hecho.

En este caso nos hemos disparado en el pié y hemos tenido que indicarle que ignore la validación del nombre de grupo, pero dado que será la primera y única vez que lo usemos para ello tampoco es tan grave.

Ahora sí, ahora podemos añadir el usuario:

victor@gladius:~/tmp$ sudo adduser --conf ./spaces.conf --disabled-login --ingroup spaces --gecos "Spaces's user" sp_0001
Añadiendo el usuario `sp_0001' ...
Añadiendo el nuevo usuario `sp_0001' (15000) con grupo `spaces' ...
Creando el directorio personal `/srv/backups/sp_0001' ...
Copiando los ficheros desde `./skel-backups' ...
Añadiendo al nuevo usuario `sp_0001' a grupos adicionales ...
Añadiendo al usuario `sp_0001' al grupo `spaces' ...
victor@gladius:~/tmp$ sudo tree -puag /srv/backups/
/srv/backups/
└── [drwxr-x--- sp_0001  spaces  ]  sp_0001
    ├── [-rw-r--r-- sp_0001  spaces  ]  .profile
    ├── [-rw-rw-r-- sp_0001  spaces  ]  README
    └── [drw------- sp_0001  spaces  ]  .ssh

2 directories, 2 files

Como detalles finales queda la creación de un pequeño script envoltorio que facilite el lío de los parámetros y, también, asignar las contraseñas correspondientes para que los datos comiencen a llegar.