Usuario y grupo en WordPress

wordpress

Es posible obtener este error al intentar realizar la actualización (realmente un upgrade, con actualizaciones menores no lo había notado hasta la fecha) automática en WordPress:

Descargando paquete de instalación desde https://downloads.wordpress.org/release/es_ES/wordpress-4.6.zip…

Descomprimiendo actualización…

Verificando los archivos descomprimidos…

No se ha podido descomprimir la actualización.

Instalación fallida

Antes de aventuraros con la actualización manual (tediosa y dado que podéis meter la pata si no hacéis un buen backup), os recomiendo revisar permisos del sistema de ficheros, y si son correctos revisad toda la cadena siguiente:

  • Usuario (Linux/FTP) que gobierna la web / dominio, en este caso basada en el cms WordPress.org, para los ejemplos del articulo usaré “joselito“, este ha de ser el dueño o propietario de toda la carpeta sobre la que descansa el cms, en nuestro artículo será la carpeta “blog/”:
ls -l
total 36
drwxrwxr-x 6 joselito www-data 4096 Aug 22 16:03 blog
  • Los permisos para una carpeta como la que se aprecia arriba, deberían permitir escritura a usuario y a grupo (775 en octal, en cambio para un fichero 664)
  • Grupo del servidor Web en el caso de apache2 basado en sistemas Debian es el usuario / grupo “www-data“, en otros sistemas suele ser www, nobody, …
  • Que el usuario “joselito” tenga como grupo primario o secundario “www-data”. La pertenencia a grupos se puede comprobar con el comando id de Linux. Si estáis logados como el usuario en cuestión sin parámetros, y la salida que produce es como esta:
id
uid=2003(webmaster) gid=2003(webmaster) grupos=2003(webmaster),33(www-data)
  • Si queréis interrogar la pertenencia a grupos de otro usuario, siempre que tengáis permiso para ello:
id webmaster
uid=2003(webmaster) gid=2003(webmaster) grupos=2003(webmaster),33(www-data)
  • No es nada recomendable que la carpeta que aloja la web pertenezca al usuario/grupo del servidor web, funcionaría pero es una brecha de seguridad.
  • El grupo “www-data” ha de ser el grupo de toda la carpeta sobre la que descansa el cms:
  • ls -l
    total 36
    drwxrwxr-x 6 joselito www-data 4096 Aug 22 16:03 blog

Si tenemos mal configurado el usuario que maneja la instalación de wordpress, o bien el grupo, mediante el comando chown, podemos cambiar el propietario y el grupo de forma recursiva:

chown -R joselito:www-data blog

Repito: Se recomienda por seguridad que el propietario (owner) de la carpeta no sea el demonio sobre el que corre apache2, en nuestros ejemplos www-data.

Por lo que el propietario debería ser un usuario al uso, del sistema Linux, en nuestros ejemplos “joselito” y además este usuario debe pertenecer al grupo sobre el que corre el servidor web.

En uno de los VPS que administro di de alta el usuario de forma demasiado manual e hice que su grupo primario fuese www-data directamente (mediante la orden useradd), y ayer tras este error me di cuenta de que en el fichero /etc/group, a la altura de www-data no había ningún usuario:

cat /etc/group|grep ^www
www-data:x:33:

En otros servidores este mismo comando:

cat /etc/group|grep ^www
www-data:x:33:webmaster[, ...]

Con el comando usermod, y las opciones -aG podemos agregar cierto usuario a un grupo:

usermod -aG www-data joselito

Estoy agregando el usuario “joselito” al grupo apache2 “www-data”

Si volvemos a hacer el cat sobre el fichero de grupos filtrando el del servidor web obtenemos que nuestro usuario ya pertenece al mismo:

cat /etc/group|grep ^www
www-data:x:33:joselito

Si intentamos actualizar wordpress de nuevo debería poder hacerlo sin problemas. En ocasiones hace falta cerrar la sesión (de joselito) para forzar la lectura del archivo de grupos Linux. Mediante el comando id podemos saber a qué grupo/s pertenecemos o pertenece un usuario:

id
uid=2003(joselito) gid=33(www-data) groups=33(www-data)

Si por alguna de aquellas todavía no funciona la actualización, es posible que en algún rincón haya algún archivo que si no pertenece a “www-data” no pueda sobreescribirse.

En estas situaciones, sobre todo si se trata de upgrade (4.5.3 a 4.6)  y no de update (4.5.2 a 4.5.3), la solución temporal pasa por hacer propietario a “www-data” de toda la estructura y después volver a hacer propietario al usuario FTP / Linux, en el caso que nos ocupa “joselito”:

chown -R www-data blog/

Con la opción -R de chmod lo estamos aplicando recursivamente a la carpeta blog y todas las subcarpetas/archivos.

Y después, tras poder actualizar recordad, de nuevo por seguridad, volver a restablecer como propietario al usuario “joselito” con el que conectamos vía FTP, o SSH, o usuario Linux asociado al dominio en cuestión:

chown -R joselito blog/

Hasta la próxima.

find: `/var/lib/amavis/virusmails/’: No such file or directory

find: `/var/lib/amavis/virusmails/': No such file or directory

Los que usáis la solución http://www.iredmail.org/ como servidor de correo es posible que en alguna ocasión recibáis por correo una alerta como la del título de esta entrada.

Existe un crontab para el usuario amavis que elimina periódicamente los virus encontrados en el correo electrónico, para ello trabaja con la carpeta /var/lib/amavis/virusmails donde va dejando los rastros encontrados.

# Delete virus mails which created 15 days ago.
1 5 * * * find /var/lib/amavis/virusmails/ -ctime +15 | xargs rm -rf {}

Se puede editar con la orden siguiente:

crontab -e -u amavis

Si no se reciben virus en 15 días se borrará el directorio virusmails, y con el próximo virus como mucho se irán concatenando los mismos en un fichero llamado igual, con lo que la orden find (que espera sea una carpeta) dejará de funcionar y recibiremos el mencionado error:

find: `/var/lib/amavis/virusmails/’: No such file or directory

La solución pasa por cambiar justo antes de la búsqueda, la fecha de modificación de la mencionada carpeta: un simple touch delante del find, que se ejecute justo antes de la limpieza, así como y usar -mtime en lugar de -ctime. El crontab del usuario ‘amavis’ debería quedar así:

# Delete virus mails which created 15 days ago.
1 5 * * * touch /var/lib/amavis/virusmails; find /var/lib/amavis/virusmails/ -mtime +15 | xargs rm -rf {}

Si seguís recibiendo el Warning

Debe ser porque la carpeta ya no existe, basta recrearla mediante un mkdir, pero dejando los permisos correctos de usuario y grupo ‘amavis‘, tal y como aparece en la salida de este comando ls:

ls -ld /var/lib/amavis/virusmails
drwxr-x--- 2 amavis amavis 4096 sep 6 2014 /var/lib/amavis/virusmails

Para ello tenemos varias alternativas, os dejo dos:

  1. Ubicaros en la carpeta anterior /var/lib/amavis/, y crear el directorio virusmails habiendo suplantado mediante el comando su al usuario ‘amavis‘ (lo podéis hacer si sois root)
cd /var/lib/amavis/

su amavis

mkdir virusmails

2. Cread la carpeta y después mediante chown cambiad tanto usuario propietario como pertenencia a grupo de la misma:

cd /var/lib/amavis/

mkdir virusmails

chown amavis:amavis virusmails

Sólo por si os apetece probar una tercera alternativa, podríamos en lugar de touch, probar a recrear en el crontab la carpeta, y redireccionar el posible error si existe a /dev/null. Por lo que un crontab alternativo (que no he probado) seria este:

# Delete virus mails which created 15 days ago.
1 5 * * * mkdir /var/lib/amavis/virusmails 2> /dev/null; find /var/lib/amavis/virusmails/ -mtime +15 | xargs rm -rf {}

De esta forma, y hablando “teóricamente” crearía si no existe todavía la carpeta y después realizaría la búsqueda, en caso de que exista desbiaría cualquier salida de error 2> a /dev/null, de nuevo teóricamente no sería necesario ya que crontab se ejecuta desatendido, aunque y por tercera vez de forma teórica, posiblemente recibamos un mensaje de error al email diciendo algo así como: “la carpeta ya existe”.

Hasta la próxima