El Sun, 01 Jun 2014 20:31:38 +0200, José Miguel (sio2) escribió: > 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.
(...) 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. >> 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". Si existe una jaula (?) que impida salir de "/Material" que entiendo es la raíz, tienes que asegurarte de que los usuarios puedan acceder al contenido externo aunque supongo que eso ya lo habrás tenido en cuenta. En cualquier caso, convendría que hicieras las mismas pruebas *sin* jaula de por medio, sólo para comparar los resultados en ambos casos. > 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). Es decir, tenemos que: /srv/ftp/Almacen/Curso_2013-2014/f.txt contiene "Adios" y por ende, /srv/ftp/Almacen/Contenedor/f.txt contiene Adios ¿correcto? (...) > #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. > 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. > #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? > 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 Bien, pero entiendo que ese sería otro tema (digo, permitir la descarga desde un acceso fuera de la jaula), obviamente el usuario necesita permiso para poder acceder al recurso. > 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. 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. Dos pruebas adicionales que se me ocurren: 1/ Probar con un enlace duro 2/ Probar con ssh (mediante sftp) 3/ Probar con un enlace simbólico que esté en el mismo directorio > 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. 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). Saludos, -- Camaleón -- 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/pan.2014.06.02.14.23...@gmail.com
