Buenas tardes a todos! (esta vez sí que son buenas de verdad, si llego a escribir este artículo por la mañana seguramente os hubiera dicho otra cosa en lugar de !Buenos días!)
Hoy vengo cargadito de información, espero que para algunos, bastante útil (y está mal que lo diga yo, pero creo que en esta ocasión el artículo va a salvar el “culo” a más de uno, de hecho espero que así sea y que déis con esta solución rápido si os sucede lo mismo que a mí hoy).
El tema de hoy, como no podía ser de otra manera, está relacionado con la administración de sistemas y concretamente con una incidencia en un servidor con distribución Gentoo (aunque esto puede suceder en cualquier Linux).
Esta mañana amanecí como de costumbre, acerqué a mi novia a trabajar y me paré por la piscina municipal cubierta a hacerme unos larguetes, es una actividad que abre mi mente y me permite estar más activo durante el día e incluso rendir más en mi trabajo (ya sabéis que soy un divulgador de lo sano y me gusta siempre que puedo fomentar hábitos saludables en twitter, en mi blog de fitness, en vitónica o incluso por la radio).
El fichero imborrable, con permisos 000, chmod 000 fichero
Llegué a mi puesto de trabajo a las 9:00 y cuál fue mi sorpresa cuando una web no funcionaba correctamente. Días atrás esta misma web había dado un pequeño fallo, y pensamos que el problema podía ser el mismo, así que aplicamos la misma solución, pero sin obtener esta vez un buen resultado.
Dicha web tiene una complejidad algo elevada en su funcionamiento y requiere unas tareas programadas que se ejecutan de forma continua en el servidor y que deben estar programadas como tareas en el cron. Cuál fue mi sorpresa cuando al intentar ejecutar el siguiente comando:
crontab -e
Obtengo como resultado “-bash: /usr/bin/crontab: Permiso denegado” y ahora es cuando me decís “bah!, eso es que no estabas funcionando como root” pues sí, sí lo estaba, y aquí empieza el juego :).
Lo siguiente que me diríais es “mira a ver si el crontab tiene permisos de ejecución como root” así que ejecuto lo siguiente y obtengo el resultado que indico:
ls -l /usr/bin/crontab ---------- 1 root 103 33160 Dec 11 2007 /usr/bin/crontab
La leche…. ¿os habéis fijado en la lista de permisos del fichero? efectivamente !no tiene ninguno! o lo que es lo mismo, es como si aplicamos un chmod 000 /usr/bin/crontab.
Madre mía ¿pero cómo ha podido pasar? Pues ni idea…. porque nadie accedió a la máquina por SSH, solo se me ocurre que pudiera modificarlo un servicio que se ejecuta a diario en el servidor, pero hasta esta noche no sabré si es por ello o no, aunque de momento no me preocupa.
Bueno, tras este descubrimiento, intento hacer una copia del fichero crontab actual así que ejecuto lo siguiente:
cp /usr/bin/crontab /usr/bin/crontab.old
Perfecto, al hacer un ls -l me doy cuenta de que tengo crontab y crontab.old sin permisos ambos, vamos bien…..
Intento cambiar de dueño el fichero, o darle permisos, pero recibo lo siguiente:
chown root:root /usr/bin/crontab chown: cambiando el propietario de /usr/bin/crontab: Operaci?n no permitida chmod 755 /usr/bin/crontab chmod: changing permissions of `/usr/bin/crontab': Operation not permitted
Efectivamente cuando un fichero no tiene permisos de ser escrito o ejecutado ni por su dueño…. tampoco permite que se realicen estas operaciones.
Si os fijáis anteriormente, el “dueño” del fichero crontab si es root pero el grupo aparece como un número, 103, así que con ayuda de mi hermano (autor de Babuleando.com, un blog que os recomiendo leer si os gusta la tecnología de andar por casa) y de su compañero de trabajo Óscar (que tiene otro blog algo más técnico pero que seguro que también os mola leer) , me comentan que cree un nuevo grupo con el id 103 y que asigne a root ese grupo, así que así lo hago:
groupadd -g 103 crontabdeloshuevos usermod -G crontabdeloshuevos root
Tras esto, efectivamente ahora en lugar de 103 aparece como grupo crontabdeloshuevos, pero sigue sin funcionar :), no me permite hacer nada.
Desesperado, intento fallidamente todo lo que indican en estos foros:
- http://forums.cpanel.net/f5/usr-bin-crontab-permissions-wrong-please-set-4755-a-81497.html#post377509
- http://serverfault.com/questions/78159/what-could-cause-permission-denied-for-command-crontab-e
- http://askubuntu.com/questions/296107/all-commands-in-my-crontab-fail-with-permission-denied
De repente, se ve algo de luz en el problema
Así que intento lo que indican, cambiar los atributos del fichero mediante el siguiente comando:
chattr -ia crontab
Pero todo sigue igual… así que tras unos minutos de desesperación (hasta aquí habían transcurrido nada menos que 4 horas de mi mañana) se me ocurre primero listar los atributos del fichero mediante:
listattr crontab
Y me doy cuenta de que tiene un atributo asignado, el atributo ‘s’. Busqué que significaba y aunque la wikipedia no me gusta mucho, esta vez me dio una respuesta bastante correcta , concretamente el atributo ‘s’ indica secure deletion (s), así que vuelvo a repetir el comando chattr pero esta vez con -s
chattr -s /usr/bin/crontab
Y esta fue la salvación :), pude borrar por fin el fichero con un rm /usr/bin/crontab y reinstalé crontab mediante el gestor de paquetes de Gentoo emerge:
emerge vixie-cron rc-update add vixie-cron default
Ahora tenía un problema, al intentar modificar el cron mediante crontab -e me indicaba que no podía con un mensaje tipo /tmp/cront.asdad.adasd to crontabs/root rename: Operation not permitted, así que me puse a mirar y efectivamente ya era un problema de grupo y permisos de las carpetas /var/spool/cron y de sus subdirectorios, así que hice lo siguiente:
chown root:root /var/spool/cron chown root:root /var/spool/cron/crontabs chmod 755 /var/spool/cron chmod 755 /var/spool/cron/crontabs rm /var/spool/cron/crontabs/root touch /var/spool/cron/crontabs/root
Y ya con esto funcionó todo a la perfección :), pude ejecutar crontab -e con normalidad y volver a programar mis tareas. Por cierto, para que se os abra otro editor distinto al VI cuando ejecutéis crontab -e podéis asignarle por ejemplo el nano de la siguiente forma:
env EDITOR=nano crontab -e
En resumen
Cuando no podáis borrar un fichero con permisus nulos (——- es decir, 000) listad sus atributos mediante listattr fichero y quitádselos mediante chattr. De esta forma ya podréis borrarlo, moverlo o lo que queráis, sin ningún problema.
Error 500 – “GET / HTTP/1.1″ 500 en wordpress | Jose Alberto Benítez Andrades
Oct 23, 2014 -
[…] más raros con los que me he encontrado en lo que a administrador de sistemas se refiere (vease Fichero imborrable crontab con permisos 000 “bash: /usr/bin/crontab: Permiso denegado” ), hoy me he encontrado con un error totalmente aleatorio y sin información […]
Recopilación de lecturas semanales fitness (LIX) |
Oct 24, 2014 -
[…] si algún aburrido tiene interés puede verla, al igual que otra entrada que escribí en mi blog de jabenitez.com sobre una experiencia que tuve con mi trabajo esta semana y otra experiencia más (dos, […]
Descarga de un fichero .gz al acceder a mi web | Jose Alberto Benítez Andrades
Oct 27, 2014 -
[…] solucionado bastante rápido y no me ha entretenido mucho tiempo, no como los de la semana pasada (1 y […]