El Mon, 02 de Jun de 2014, a las 02:23:43PM +0000, Camaleón dijo:
> Si el problema no era de jaulas, el montaje con "bind" no te va a servir,
> por eso me extrañaba que dieras esa opción como válida.
El problema es provocado por la jaula, lo que pasa que no es el típico
problema de que los contenidos queden fuera de la jaula, sino que la
jaula modifica el directorio raíz y como consecuencia la ruta absoluta
deja de ser válida dentro de la jaula. Creo que en todo este hilo es eso
lo que no he sido capaz de transmitir bien o tú no has comprendido del
todo.
Veamos. El fichero:
/srv/ftp/Almacen/Contenedor/f.txt
tiene una ruta absoluta que es esa precisamente:
/srv/ftp/Almacen/Contenedor/f.txt. Si en el sistema tengo un enlace
simbólico con esa ruta absoluta, el enlace no está roto. Ahora bien, el
servidor FTP no tiene como raiz la raíz del sistema, sino
/srv/ftp/Material, porque está enjaulado en ese directorio. Así pues a
ojos del FTP la ruta absoluta de ese fichero f.txt /Contenedor/f.txt,
puesto que /srv/ftp/Almacen/Contenedor/f.txt referiría al un hipotético
fichero que en el sistema de archivos se encontrase en:
/srv/ftp/Almacen/srv/ftp/Almacen/Contenedor/f.txt
Eso es lo que le pasa a mis enlaces simbólicos con ruta absoluta: son
válidos en el sistema, pero en el FTP, no.
¿Qué tiene de malo esto? Pues que el comportamiento del FTP cuando se
sube un fichero no es sobreescribir el enlace simbólico por el fichero
regular que estoy subiendo (a diferencia de mv o cp que sí lo hacen),
sino seguir el enlace y modificar el fichero apuntado (f.txt en este
ejemplo). Si el enlace está roto, el FTP no encuentra el fichero
apuntado y suelta un error.
Creo que por el RFC que me indicaste, aunque no lo entiendo muy bien,
este es el comportamiento lógico del protocolo: no hay dos ficheros (el
enlace simbólico y el fichero regular), sino un solo fichero al que se
puede llegar por dos rutas diferentes; y, por tanto, no sería posible
hacer lo que me hubiera gustado: que el FTP en las subidas se comportase
como los comandos mv o cp.
> [...]
> > #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).
>
> Es decir, tenemos que:
>
> /srv/ftp/Almacen/Curso_2013-2014/f.txt contiene "Adios"
Si te vas al sistema de ficheros, este fichero sigue siendo un enlace
simbólico.
> y por ende,
>
> /srv/ftp/Almacen/Contenedor/f.txt contiene Adios
>
> ¿correcto?
Efectivamente, el cambio se ha producido en 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:
>
> Falla este pero no ha fallado el primero y entiendo que es porque en el
> primero no había ningún archivo anterior que tuviera que sobrescribir.
No, observa que todos los enlaces simbólicos apuntan a un fichero que
existe:
/srv/ftp/Almacen/Contenedor/f.txt
A veces, La ruta es absoluta y a veces la ruta es relativa.
> > FAIL UPLOAD: Client "XX.XXX.XXX.XXX", "/Curso_2012-2013/f.txt",
> > 0.00Kbyte/sec
>
> ¿Y ya está? :-?
>
> Dale más verbosidad al registro del servidor FTP si te lo permite.
No lo que falla es la ruta. La ruta /srv/ftp/Almacen/Contenedor/f.txt,
no es válida para el FTP, porque para el la ruta absoluta es
/Contenedor/f.txt. Esta es la razón por la que falla: yo veo coherente
el comportamiento.
> > #v+
> > $ ftp ftp.dominio.com [...]
> > ftp> cd Curso_2012-2013 ftp> put f2.txt [...]
> > 226 Transfer complete.
> > #v-
>
> Este lo hace bien porque no había ningún archivo "f2.txt" que
> sobrescribir ¿correcto?
No, esto no falla porque f2.txt es un enlace simbólico a f.txt con la
ruta absoluta que ve el servidor FTP:
/Contenedor/f.txt
Obviamente este enlace simbólico dentro del sistema es un enlace roto,
que no apunta a ningún fichero existente.
Ningún "put" que he hecho ha creado ningún fichero nuevo en el servidor:
todos sobreescriben el fichero regular f.txt que está en Contenedor.
Salvo el put que falla, claro.
> Lo que me queda claro es que sabemos en qué condiciones (cuándo) falla
> (cuando ya existe un archivo con ese nombre que es un enlace simbólico)
> pero no porqué, intenta que el servidor ftp saque más información.
Yo sí veo claro por qué: porque el enlace a ojos de FTP está roto y
apunta a un fichero que no existe dentro de un directorio que no existe.
Es más, no he hecho la prueba pero si en mi sistema existiera el
directorio:
/srv/ftp/Almacen/srv/ftp/Almacen/Contenedor/
estoy seguro que la prueba que me ha fallado no lo habría hecho.
Simplemente habría creado f.txt dentro de ese directorio. Es lo mismo
que ocurre si en un FTP vacío intento hacer:
put a/fichero.txt
Fallará porque el directorio a no existe y para poder subir el fichero a
"a", tiene que existir "a" antes.
> Dos pruebas adicionales que se me ocurren:
> 1/ Probar con un enlace duro
Eso va a funcionar: no veo el problema de que no lo haga.
> 2/ Probar con ssh (mediante sftp)
Tengo la duda. Creo que alguien me dijo que le funcionaba. Quizás porque
el sftp de ssh, sí sobreescribe el enlace simbólico en vez de seguir su
ruta.
> 3/ Probar con un enlace simbólico que esté en el mismo directorio
No entiendo esto que dices.
> Yo entendería que lo más sencillo (lo más lógico) es que sobrescribiera
> el destino al que apunta el enlace simbólico siempre y cuando tenga los
> permisos adecuados y que en este caso los tiene (aparentemente).
Es que eso es lo que hace: el problema es el que te he apuntado al
principio: que el cambio de raíz rompe las rutas absolutas.
> Saludos,
Un saludo.
--
Todos buscan quien ampare, yo quien enmiende; que más
quiero ir entendido que defendido.
--- Lope de Vega ---
--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140602174845.gb3...@cubo.casa
