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:

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:

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:

Perfecto, al hacer un ls -l me doy cuenta de que tengo crontabcrontab.old sin permisos ambos, vamos bien…..

Intento cambiar de dueño el fichero, o darle permisos, pero recibo lo siguiente:

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:

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:

Ninguna solución me sirve :(, hasta que finalmente busco el problema de otra forma y doy con el siguiente foro:

Así que intento lo que indican, cambiar los atributos del fichero mediante el siguiente comando:

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:

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

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:

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:

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:

 

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.