Monitorizar upload FTP desde script

Upload FTP¿Cómo podríamos saber si un fichero que está siendo subido por FTP ha acabado o no de subirse? Hay algunas posibles soluciones en esta conversación de SuperUser.com, la última de las cuales, es la que he usado.

Para los testeos, he usado un servidor vsFTPd (configurado tal y como expliqué aquí) sobre un servidor CentOS 5.4. Como no tenía ficheros grandes para hacer el test, he creado uno de forma instantánea, con el siguiente comando:

[root@adripc]# fallocate -l 100M test.img
[root@adripc]# ls -lah test.img
-rw-r–r– 1 root root 100M Jul 18 10:20 test.img

La idea es usar lsof para saber el PID del proceso de vsFTPd que está siendo usado para subir el fichero destino, y entoces monitorizar ese PID.  El problema que me he encontrado, al menos con el entorno de test que he usado, es que ese PID de subida puede cambiar durante la subida. No sé bien bien porqué razón, pero en mi caso cambia. Si cambia el PID entonces ya no podremos monitorizar ese PID, ya que el PID habrá finalizado (o no) pero no así la subida, que estará usando otro PID diferente.

En este caso, la solución es más sencilla aun, ya que bastará con símplemente ir consultando mediante lsof y en caso de devolver vacío, nos indicará que no hay ningún proceso usando el fichero y que por tanto, la subida ha finalizado. Así, nos dará igual que el PID cambie. Lo único importante es que durante la subida del fichero, ese archivo tendrá un PID asociado, mientras que cuando haya acabado el upload, no tendrá ningún PID y por tanto lsof devolverá vacío.

Continuar leyendo «Monitorizar upload FTP desde script»

vsftpd con TLS explícito en CentOS

Seguridad

vsftpd es un servidor FTP que debería ser «Very Secure FTP», pero que por defecto es justo lo contrario. Con un poco de trabajo, podemos dejarlo bastante mejor, que es precisamente, lo que voy a mirar de describir a continuación.

Lo que queremos es forzar a los clientes a usar FTP+TLS Explícito, en lugar de FTP simple, para forzar comunicaciones cifradas. Además, usaremos FTP pasivo, enjaularemos a los usuarios y crearemos un listado de usuarios que puedan conectar, para tener controlados a los usuarios FTP.

Las pruebas se han realizado sobre un servidor CentOS 5.4 con vsFTPd 2.0.5.

En primer lugar, si no lo tenemos ya, podremos instalar vsftpd desde yum.

[root@MyServer]# yum install vsftpd

Certificado SSL

A continuación, generaremos el certificado para el SSL y le daremos los valores adecuados:

[root@MyServer]# openssl req -x509 -nodes -days 365 -newkey rsa:1024 -keyout /etc/vsftpd/vsftpd.pem -out /etc/vsftpd/vsftpd.pem
Country Name (2 letter code) [GB]:ES
State or Province Name (full name) [Berkshire]:Spain
Locality Name (eg, city) [Newbury]:Barcelona
Organization Name (eg, company) [My Company Ltd]:Mi Empresa S.A.
Organizational Unit Name (eg, section) []: IT
Common Name (eg, your name or your server’s hostname) []:midominio.com
Email Address []:

Una vez generado, cambiaremos los permisos del fichero:

[root@MyServer]# chmod 600 /etc/vsftpd/vsftpd.pem

Continuar leyendo «vsftpd con TLS explícito en CentOS»

chmod recursivo diferenciando ficheros y directorios

En Linux, en más de una ocasión necesitamos cambiar los permisos de todo un árbol de directorios, por ejemplo, de un proyecto web que encontramos con demasiados permisos. Es habitual, para los directorios, dejar los permisos 755, mientras que para ficheros se suele usar 644.

Pero, ¿cómo modificar los permisos de forma recursiva, diferenciando ficheros de directorios? Unos comandos muy muy útiles (y que podemos encontrar en muchas webs, por ejemplo aquí) son los siguientes:

Modificar los permisos recursivamente únicamente de directorios, desde el punto en el que estamos situados:

find . -type d -exec chmod 755 {} \;

Modificar los permisos recursivamente únicamente de ficheros, también desde el punto en el que estamos situados:

find . -type f -exec chmod 644 {} \;

Con estos dos comandos, podremos cambiar los permisos de forma recursiva, aplicando diferentes permisos para los directorios y para los ficheros. Si se quiere profundizar más, el siguiente enlace explica cómo usar «find» para distinguir los tipos de ficheros.

Fuentes:

http://rainsoftletters.wordpress.com/2008/07/22/recursively-chmodi-only-directories-or-files/

Programar tareas con ‘at’ en Linux

Un comando que he de reconocer que no uso todo lo que debería, es «at». Esta herramienta nos permite programar tareas que se ejecutarán una única vez. Es realmente fácil de usar y funciona a las mil maravillas. No tiene sentido usar «cron» para este tipo de tareas, puesto que cron está pensado para programar tareas que se ejecutarán con cierta periodicidad.

La idea es primeramente escribir en qué momento se va a ejecutar la tarea. Por ejemplo, si estamos a jueves a las 16:00, y queremos ejecutar una tarea una única vez la madrugada del jueves al viernes, a las 06:00, podemos ejecutar:

[root@myserver]# at -v 06:00
Fri May 17 06:00:00 2013

Actualización: Si por el contrario, queremos programar la tarea para que se ejecute el próximo 18 de Mayo a las 03AM, bastará con ejecutar:

[root@myserver]# at -v 3am May 18
Sat May 18 03:00:00 2013

La opción «-v» nos devolverá la fecha en que se va a programar la tarea. Al ejecutar la sentencia, nos entrará en «at>», que es donde tendremos que introducir la tarea a ejecutar, que al igual que hacemos con cron, puede ser una instrucción o por ejemplo la ejecución de un script:

at> /home/adri/script.sh >> /tmp/out_script.log 2>&1

Una vez acabados de introducir los comandos a ejecutar, pulsaremos «Control+D» para salir de «at>» y finalizar así las instrucciones a ejecutar. Ésto nos mostrará el fin de la tarea, el job id y de nuevo la fecha y hora programados:

at> <EOT>
job 1 at 2013-05-17 06:00

Con «at -l» listaremos las tareas pendientes, donde el primer carácter corresponderá con el id del job:

[root@myserver]# at -l
1 2013-05-17 06:00 a root

Podremos ver los detalles de la tarea programada, con «at -c» seguido del id del job. Ésto nos mostrará todo lo que se ejecutará, incluído el entorno:

[root@myserver]# at -c 1

Finalmente, siempre podremos cancelar un job, antes de la fecha de ejecución, con la opción «-d»:

[root@myserver]# at -d 1

Fuente:

http://content.hccfl.edu/pollock/unix/atdemo.htm