Re: Servidor FTP (vsftpd) y enlaces simbólicos
El Sun, 01 de Jun de 2014, a las 03:50:14PM +0000, Camaleón dijo:
> Hum... pero si antes me dijiste que eso no funcionaba, pillín >;-)
Mis disculpas. Dije que el problema no estaba en que el enlace
apuntara fuera, porque, de hecho, no apunta fuera. Efectivamente se hace
un "mount -o bind", pero no se hace para que funcione el ftp, sino para
que funcione todo lo demás. Me explico: la cutre solución sería hacer
los enlaces "mal". En vez de esto:
f.txt -> /srv/ftp/Almacen/f.txt
esto:
f.txt -> /Almacen/f.txt
que es lo que ve el ftp, puesto que está enjaulado. Ahora el enlace
funcionaría en el ftp (o eso creo, no lo he probado). Lo que no
funcionaría es en el resto del sistema. Así que creamos un /Almacen y
hacemos en mount -o bind.
> A mí tampoco me queda claro, de hecho la sección que indicas no parece
> mencionar problemas con enlaces simbólicos por lo que deberían respetarse
> siempre y cuando el sistema los admita y por eso creo que sería relevante
> la información que te preguntaba en un correo anterior:
>
> https://lists.debian.org/debian-user-spanish/2014/05/msg00470.html
>
> Es decir, si (en teoría) el servidor ftp puede trabajar con enlaces
> simbólicos a los que tenga acceso -que estén en su ámbito- como parece
> ser el caso, sería interesante saber qué error registra cuando se intenta
> sobrescribir un archivo que está apuntando a otro archivo.
A ver. Intentaré dar respuesta. Los ficheros en el servidor son estos:
/srv/ftp/Almacen/Contenedor/f.txt
/srv/ftp/Almacen/Curso_2013-2014/f.txt -> ../Contenedor/f.txt
/srv/ftp/Almacen/Curso_2013-2014/f2.txt -> ../Contenedor/f.txt
/srv/ftp/Almacen/Curso_2012-2013/f.txt -> /srv/ftp/Material/Contenedor/f.txt
/srv/ftp/Almacen/Curso_2012-2013/f2.txt -> /Contenedor/f.txt
El ftp está enjaulado en /srv/ftp/Material y f.txt contiene "Hola".
En el cliente creo dos ficheros f.txt y f2.txt ambos con el texto
"Adios".
#v+
$ ftp ftp.dominio.com
[...]
ftp> cd Curso_2013-2014
ftp> put f.txt
[...]
226 Transfer complete.
#v-
Vale, sobreescribe el fichero apuntado (el enlace simbólico, intacto).
#v+
$ ftp ftp.dominio.com
[...]
ftp> cd Curso_2013-2014
ftp> put f2.txt
[...]
226 Transfer complete.
#v-
Vale, sobreescribe el fichero apuntado.
#v+
$ ftp ftp.dominio.com
[...]
ftp> cd Curso_2012-2013
ftp> put f.txt
[...]
553 Could not create file.
#v-
Falla. En el servidor el error es:
FAIL UPLOAD: Client "XX.XXX.XXX.XXX", "/Curso_2012-2013/f.txt", 0.00Kbyte/sec
#v+
$ ftp ftp.dominio.com
[...]
ftp> cd Curso_2012-2013
ftp> put f2.txt
[...]
226 Transfer complete.
#v-
Vale, como era de esperar, sin ni siquiera haber hecho el mount ni
creado /Contenedor. Ahora bien, si se quiere que esos ficheros sean
descargables por web, no hay más remedio que hacerlo, porque en el
sistema el enlace simbólico no funciona:
$ cd /srv/ftp/Almacen/Curso_2012-2013
$ cat f2,txt
cat: f2.txt: No existe el fichero o el directorio
Creo que no hay ninguna incoherencia en lo que hace el servidor FTP con
los enlaces simbólicos. El problema es que al subir un fichero, busca el
fichero apuntado, en vez de sobreescribir el fichero-enlace. Por eso,
cuando el enlace apunta "a ningún fichero" (para el ftp la ruta absoluta
del enlace no existe, porque su directorio / es otro), falla.
Quizás esto tenga que ver con lo que dice el RFC. Creo entender que
cuando hay varias rutas alternativas a un fichero, para el FTP hay un
fichero, nada de un fichero regular y un enlace simbólico que apunta al
fichero regular: un fichero al que se accede por dos rutas diferentes.
Por eso intenta sobreescribir el fichero enlazado. Esa es la explicación
que quiero darle.
Saludos.
--
El hombre que se ríe de todo es que todo lo desprecia. La
mujer que se ríe de todo es que sabe que tiene una
dentadura bonita.
--- Enrique Jardiel Poncela ---
Reply to: