Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Servidor FTP (vsftpd) y enlaces simbólicos
415 views
Skip to first unread message
José Miguel (sio2)
May 24, 2014, 12:10:02 PM5/24/14
to
Hola, listeros:
Antes de nada, quiero aclarar que este no es el típico problema de tener
enjaulado el servidor FTP y un directorio que apunta fuera de la jaula.
Mi problema es el siguiente:
Tengo un servidor FTP enjaulado al que se suben de vez en cuando
archivos. Estos archivos semanalmente son movidos por un script a un
almacen y en su lugar se deja un enlace simbólico con ruta absoluta.
Como el servidor FTP está enjaulado, la raíz del sistema no coincide
con la suya, por lo que a ojos del servidor FTP el enlace simbólico
no enlaza con un archivo existente. Como los ficheros se descargan por
web, no hay ningún problema en las descargas.
El problema surge cuando se quiere actualizar un fichero existente. He
comprobado que el servidor FTP no se comporta como los comandos cp o mv
de linux. Con estos comandos, si se sobreescribe un enlace simbólico con
un fichero regular, desaparece el enlace simbólico y su lugar lo ocupa
el nuevo fichero. En cambio, cuando se sobreescribe un fichero, el FTP
no hace esto, lo que hace es seguir la ruta del enlace simbólico y
sustituir el fichero apuntado. Y ese es el problema: como el fichero
apuntado "no existe", se produce un error y la subida del fichero falla.
Si primero se borra el fichero del servidor (enlace simbólico) y luego
se sube la nueva versión del fichero, no hay problema.
He brujuleado por internet pero sin éxito y sospecho que el problema es
irresoluble[1], pero por si acaso lo pregunto: ¿hay algún modo de hacer que
al subir un fichero, vsftpd sustitutuya el enlace simbólico, en vez de
seguir la ruta y cambiar el fichero enlazado?
[1] Alguno podrá argumentar que puedo usar rutas relativas en los
enlaces. El problema de eso es que entonces si un usuario decide
reorganizar un poco los ficheros del servidor, creando subdirectorios y
metiendo dentro de él ficheros, los enlaces simbólicos se romperán.
Gracias de antemano.
--
Parezco en mi fortuna al Manzanares,
que con agua o sin ella siempre es río.
--- Tomé de Burguillos ---
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/2014052416...@cubo.casa
Antes de nada, quiero aclarar que este no es el típico problema de tener
enjaulado el servidor FTP y un directorio que apunta fuera de la jaula.
Mi problema es el siguiente:
Tengo un servidor FTP enjaulado al que se suben de vez en cuando
archivos. Estos archivos semanalmente son movidos por un script a un
almacen y en su lugar se deja un enlace simbólico con ruta absoluta.
Como el servidor FTP está enjaulado, la raíz del sistema no coincide
con la suya, por lo que a ojos del servidor FTP el enlace simbólico
no enlaza con un archivo existente. Como los ficheros se descargan por
web, no hay ningún problema en las descargas.
El problema surge cuando se quiere actualizar un fichero existente. He
comprobado que el servidor FTP no se comporta como los comandos cp o mv
de linux. Con estos comandos, si se sobreescribe un enlace simbólico con
un fichero regular, desaparece el enlace simbólico y su lugar lo ocupa
el nuevo fichero. En cambio, cuando se sobreescribe un fichero, el FTP
no hace esto, lo que hace es seguir la ruta del enlace simbólico y
sustituir el fichero apuntado. Y ese es el problema: como el fichero
apuntado "no existe", se produce un error y la subida del fichero falla.
Si primero se borra el fichero del servidor (enlace simbólico) y luego
se sube la nueva versión del fichero, no hay problema.
He brujuleado por internet pero sin éxito y sospecho que el problema es
irresoluble[1], pero por si acaso lo pregunto: ¿hay algún modo de hacer que
al subir un fichero, vsftpd sustitutuya el enlace simbólico, en vez de
seguir la ruta y cambiar el fichero enlazado?
[1] Alguno podrá argumentar que puedo usar rutas relativas en los
enlaces. El problema de eso es que entonces si un usuario decide
reorganizar un poco los ficheros del servidor, creando subdirectorios y
metiendo dentro de él ficheros, los enlaces simbólicos se romperán.
Gracias de antemano.
--
Parezco en mi fortuna al Manzanares,
que con agua o sin ella siempre es río.
--- Tomé de Burguillos ---
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/2014052416...@cubo.casa
Camaleón
May 24, 2014, 12:30:01 PM5/24/14
to
El Sat, 24 May 2014 18:00:53 +0200, José Miguel (sio2) escribió:
> Antes de nada, quiero aclarar que este no es el típico problema de tener
> enjaulado el servidor FTP y un directorio que apunta fuera de la jaula.
Hum... "excusatio non petita..." :-)
> Antes de nada, quiero aclarar que este no es el típico problema de tener
> enjaulado el servidor FTP y un directorio que apunta fuera de la jaula.
> Mi problema es el siguiente:
>
> Tengo un servidor FTP enjaulado al que se suben de vez en cuando
> archivos. Estos archivos semanalmente son movidos por un script a un
> almacen y en su lugar se deja un enlace simbólico con ruta absoluta.
> Como el servidor FTP está enjaulado, la raíz del sistema no coincide con
> la suya, por lo que a ojos del servidor FTP el enlace simbólico no
> enlaza con un archivo existente. Como los ficheros se descargan por web,
> no hay ningún problema en las descargas.
punteros a rutas que están fuera del alcance del servidor ftp? Se te
lleva más espacio en disco pero puedes verlo como una copia de seguridad.
> El problema surge cuando se quiere actualizar un fichero existente. He
> comprobado que el servidor FTP no se comporta como los comandos cp o mv
> de linux. Con estos comandos, si se sobreescribe un enlace simbólico con
> un fichero regular, desaparece el enlace simbólico y su lugar lo ocupa
> el nuevo fichero. En cambio, cuando se sobreescribe un fichero, el FTP
> no hace esto, lo que hace es seguir la ruta del enlace simbólico y
> sustituir el fichero apuntado. Y ese es el problema: como el fichero
> apuntado "no existe", se produce un error y la subida del fichero falla.
> Si primero se borra el fichero del servidor (enlace simbólico) y luego
> se sube la nueva versión del fichero, no hay problema.
servidor ftp no tiene acceso por estar enjaulado.
> He brujuleado por internet pero sin éxito y sospecho que el problema es
> irresoluble[1], pero por si acaso lo pregunto: ¿hay algún modo de hacer
> que al subir un fichero, vsftpd sustitutuya el enlace simbólico, en vez
> de seguir la ruta y cambiar el fichero enlazado?
Usando enlaces duros o permitiendo el flujo convencional de acceso a los
enlaces simbólicos a través de montajes con "--bind".
Saludos,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
José Miguel (sio2)
May 24, 2014, 1:30:02 PM5/24/14
to
El Sat, 24 de May de 2014, a las 04:25:42PM +0000, Camaleón dijo:
>> Antes de nada, quiero aclarar que este no es el típico problema de tener
>> enjaulado el servidor FTP y un directorio que apunta fuera de la jaula.
> Hum... "excusatio non petita..." :-)
Bueno, porsiaca... La verdad es que al intentar averiguar esto, me
saltaba siempre la misma explicación del mount -o bind, etc...
> Preguntonta... ¿por qué no trabajas con enlaces duros en lugar de dejar
> punteros a rutas que están fuera del alcance del servidor ftp? Se te
> lleva más espacio en disco pero puedes verlo como una copia de seguridad.
También se me ocurrió eso (porque el almacen está en el mismo sistema de
ficheros), pero no me convence del todo porque dificulta la limpieza. A
veces alguno se dedica a meter ahí imágenes de máquinas virtuales, o
hasta software pirata (aunque esté terminantemente prohibido). Cuando
toca limpieza, si se usan enlaces simbólicos sé que me basta con
brujulear en el "Almacen", si se usan enlaces duros, no.
> Tal y como lo interpreto, no es que no exista el archivo, es que el
> servidor ftp no tiene acceso por estar enjaulado.
No, también se tiene acceso al fichero enlazado, el problema como he
dicho es el cambio en la raíz. Lo explico con un ejemplo. Imagina esta
situación muy simple:
/srv/ftp/Almacen/fichero.txt
/srv/ftp/Curso2013-2014/fichero.txt -> /srv/ftp/Almacen/fichero.txt
Los usuarios están enjaulados bajo /srv/ftp (o sea, / para el FTP es
/srv/ftp para el sistema); así que, aunque se tiene acceso al directorio
Almacen, el enlace simbólico a /srv/ftp/Almacen/fichero.txt no funciona.
No lo he probado, la verdad, pero supongo que /Almacen/fichero.txt sí
que funcionaría dentro del ftp (aunque no en el sistema).
>> He brujuleado por internet pero sin éxito y sospecho que el problema es
>> irresoluble[1], pero por si acaso lo pregunto: ¿hay algún modo de hacer
>> que al subir un fichero, vsftpd sustitutuya el enlace simbólico, en vez
>> de seguir la ruta y cambiar el fichero enlazado?
funciona, y la tercera solución (enlaces con ruta relativa) también
tiene su pega. Lo suyo es que hubiera forma de decirle al FTP que no
siguiera los enlaces simbólicos, sino que los machacara; pero no he dado
con la forma; quizás, porque, simplemente, no se puede.
Gracias.
--
e non l'arbitrio de femina lieve,
che sempre inchina a quel che men far deve.
--- Ludovico Ariosto ---
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/2014052417...@cubo.casa
>> Antes de nada, quiero aclarar que este no es el típico problema de tener
>> enjaulado el servidor FTP y un directorio que apunta fuera de la jaula.
> Hum... "excusatio non petita..." :-)
saltaba siempre la misma explicación del mount -o bind, etc...
> Preguntonta... ¿por qué no trabajas con enlaces duros en lugar de dejar
> punteros a rutas que están fuera del alcance del servidor ftp? Se te
> lleva más espacio en disco pero puedes verlo como una copia de seguridad.
ficheros), pero no me convence del todo porque dificulta la limpieza. A
veces alguno se dedica a meter ahí imágenes de máquinas virtuales, o
hasta software pirata (aunque esté terminantemente prohibido). Cuando
toca limpieza, si se usan enlaces simbólicos sé que me basta con
brujulear en el "Almacen", si se usan enlaces duros, no.
> Tal y como lo interpreto, no es que no exista el archivo, es que el
> servidor ftp no tiene acceso por estar enjaulado.
dicho es el cambio en la raíz. Lo explico con un ejemplo. Imagina esta
situación muy simple:
/srv/ftp/Almacen/fichero.txt
/srv/ftp/Curso2013-2014/fichero.txt -> /srv/ftp/Almacen/fichero.txt
Los usuarios están enjaulados bajo /srv/ftp (o sea, / para el FTP es
/srv/ftp para el sistema); así que, aunque se tiene acceso al directorio
Almacen, el enlace simbólico a /srv/ftp/Almacen/fichero.txt no funciona.
No lo he probado, la verdad, pero supongo que /Almacen/fichero.txt sí
que funcionaría dentro del ftp (aunque no en el sistema).
>> He brujuleado por internet pero sin éxito y sospecho que el problema es
>> irresoluble[1], pero por si acaso lo pregunto: ¿hay algún modo de hacer
>> que al subir un fichero, vsftpd sustitutuya el enlace simbólico, en vez
>> de seguir la ruta y cambiar el fichero enlazado?
> Usando enlaces duros o permitiendo el flujo convencional de acceso a los
> enlaces simbólicos a través de montajes con "--bind".
Lo primero ya te he dicho por qué no me convence. Lo segundo no
> enlaces simbólicos a través de montajes con "--bind".
funciona, y la tercera solución (enlaces con ruta relativa) también
tiene su pega. Lo suyo es que hubiera forma de decirle al FTP que no
siguiera los enlaces simbólicos, sino que los machacara; pero no he dado
con la forma; quizás, porque, simplemente, no se puede.
Gracias.
--
e non l'arbitrio de femina lieve,
che sempre inchina a quel che men far deve.
--- Ludovico Ariosto ---
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Camaleón
May 24, 2014, 1:50:02 PM5/24/14
to
El Sat, 24 May 2014 19:21:53 +0200, José Miguel (sio2) escribió:
> El Sat, 24 de May de 2014, a las 04:25:42PM +0000, Camaleón dijo:
(...)
> El Sat, 24 de May de 2014, a las 04:25:42PM +0000, Camaleón dijo:
>> Tal y como lo interpreto, no es que no exista el archivo, es que el
>> servidor ftp no tiene acceso por estar enjaulado.
>
> No, también se tiene acceso al fichero enlazado, el problema como he
> dicho es el cambio en la raíz. Lo explico con un ejemplo. Imagina esta
> situación muy simple:
>
> /srv/ftp/Almacen/fichero.txt
> /srv/ftp/Curso2013-2014/fichero.txt -> /srv/ftp/Almacen/fichero.txt
>
> Los usuarios están enjaulados bajo /srv/ftp (o sea, / para el FTP es
> /srv/ftp para el sistema); así que, aunque se tiene acceso al directorio
> Almacen, el enlace simbólico a /srv/ftp/Almacen/fichero.txt no funciona.
> No lo he probado, la verdad, pero supongo que /Almacen/fichero.txt sí
> que funcionaría dentro del ftp (aunque no en el sistema).
pones, entiendo que los enlaces simbólicos están dentro de la jaula y por
tanto, accesibles de cara al servidor ftp. Pero dices que vsftpd no puede
acceder a "/srv/ftp/Curso2013-2014/fichero.txt", que da error...
¿correcto? Si es así, interesaría saber:
1/ El error que te registra el servidor ftp cuando se intenta acceder al
recurso que apunta al enlace simbólico
2/ El error que te aparece en el cliente
3/ El tipo de cliente que usas para acceder a ese recurso (aplicación
dedicada ftp, navegador web...)
(...)
>> Usando enlaces duros o permitiendo el flujo convencional de acceso a
>> los enlaces simbólicos a través de montajes con "--bind".
>
> Lo primero ya te he dicho por qué no me convence. Lo segundo no
> funciona, y la tercera solución (enlaces con ruta relativa) también
> tiene su pega. Lo suyo es que hubiera forma de decirle al FTP que no
> siguiera los enlaces simbólicos, sino que los machacara; pero no he dado
> con la forma; quizás, porque, simplemente, no se puede.
concretamente el #3659¹) pero en principio, que el servidor ftp no siga
los enlaces simbólicos que están dentro de su ámbito no me parece
"normal" salvo que el sistema de archivos (es decir, los permisos de
usuarios en esos directorios) lo impida.
¹http://tools.ietf.org/html/rfc3659
Saludos,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Santiago Vila
May 24, 2014, 6:20:01 PM5/24/14
to
On Sat, May 24, 2014 at 04:25:42PM +0000, Camaleón wrote:
> Preguntonta... ¿por qué no trabajas con enlaces duros en lugar de dejar
> punteros a rutas que están fuera del alcance del servidor ftp? Se te
> lleva más espacio en disco pero puedes verlo como una copia de seguridad.
Los enlaces duros, cuando se pueden hacer, *no* ocupan más que los
> Preguntonta... ¿por qué no trabajas con enlaces duros en lugar de dejar
> punteros a rutas que están fuera del alcance del servidor ftp? Se te
> lleva más espacio en disco pero puedes verlo como una copia de seguridad.
enlaces simbólicos.
# cd /boot
# ls -l initrd.img-3.2.0-4-amd64
-rw-r--r-- 5 root root 11994354 may 13 07:57 initrd.img-3.2.0-4-amd64
# mkdir a
# ln initrd.img-3.2.0-4-amd64 a/1
# ln initrd.img-3.2.0-4-amd64 a/2
# ln initrd.img-3.2.0-4-amd64 a/3
# ln initrd.img-3.2.0-4-amd64 a/4
# du a
11720 a
Precisamente por ser enlaces duros, solamente se guarda una copia de
entre todos los que estén enlazados entre sí, forma parte de la gracia.
Es posible incluso que ocupen menos que si fueran enlaces simbólicos,
ya que al referirse al mismo nodo-i, no gastan ni siquiera el mínimo
de 4K que suele gastar cada nodo-i.
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Francesc Guitart
May 27, 2014, 3:40:03 AM5/27/14
to
Hola,
No estoy seguro de haverlo entendido bien y además me parece que mi
solución es tan evidente que supongo ya la habrás probado, pero... ala voy:
1. Crea /Almacen en la raíz. De esta manera los nuevos enlaces
simbólicos tendrán la ruta /Almacen (que corresponde con la ruta dentro
del chroot).
2. Monta con --o bind el directorio /Almacen en /srv/ftp/Almacen.
>
>>> He brujuleado por internet pero sin éxito y sospecho que el problema es
>>> irresoluble[1], pero por si acaso lo pregunto: ¿hay algún modo de hacer
>>> que al subir un fichero, vsftpd sustitutuya el enlace simbólico, en vez
>>> de seguir la ruta y cambiar el fichero enlazado?
>> Usando enlaces duros o permitiendo el flujo convencional de acceso a los
>> enlaces simbólicos a través de montajes con "--bind".
>
> Lo primero ya te he dicho por qué no me convence. Lo segundo no
> funciona, y la tercera solución (enlaces con ruta relativa) también
> tiene su pega. Lo suyo es que hubiera forma de decirle al FTP que no
> siguiera los enlaces simbólicos, sino que los machacara; pero no he dado
> con la forma; quizás, porque, simplemente, no se puede.
>
Espero haberme explicado.
> Gracias.
>
Saludos.
--
Francesc Guitart
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/53843F81...@gmx.com
No estoy seguro de haverlo entendido bien y además me parece que mi
solución es tan evidente que supongo ya la habrás probado, pero... ala voy:
simbólicos tendrán la ruta /Almacen (que corresponde con la ruta dentro
del chroot).
2. Monta con --o bind el directorio /Almacen en /srv/ftp/Almacen.
>
>>> He brujuleado por internet pero sin éxito y sospecho que el problema es
>>> irresoluble[1], pero por si acaso lo pregunto: ¿hay algún modo de hacer
>>> que al subir un fichero, vsftpd sustitutuya el enlace simbólico, en vez
>>> de seguir la ruta y cambiar el fichero enlazado?
>> Usando enlaces duros o permitiendo el flujo convencional de acceso a los
>> enlaces simbólicos a través de montajes con "--bind".
>
> Lo primero ya te he dicho por qué no me convence. Lo segundo no
> funciona, y la tercera solución (enlaces con ruta relativa) también
> tiene su pega. Lo suyo es que hubiera forma de decirle al FTP que no
> siguiera los enlaces simbólicos, sino que los machacara; pero no he dado
> con la forma; quizás, porque, simplemente, no se puede.
>
> Gracias.
>
Saludos.
--
Francesc Guitart
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
José Miguel (sio2)
Jun 1, 2014, 6:30:01 AM6/1/14
to
El Tue, 27 de May de 2014, a las 09:32:17AM +0200, Francesc Guitart dijo:
> No estoy seguro de haverlo entendido bien y además me parece que mi
> solución es tan evidente que supongo ya la habrás probado, pero... ala
> voy:
>
> [...]
Siento responder tan tarde, pero no me ha acompañado la salud...
No, no se me había ocurrido. Es una solución bastante guarretera, pero
creo sí es solución (no lo he probado). Miré el RFC que me dijo
Camaleón, pero no llegué a comprender del todo por qué se comporta el
servidor FTP con los enlaces simbólicos del modo en que se comporta:
http://tools.ietf.org/html/rfc3659#section-7.5
Creo que la posible explicación está en 7.5.2, pero no saco nada en
claro. Comprobé que si el enlace simbólico y el fichero real no tienen
el mismo nombre, no funciona el enlace dentro del FTP, aunque use ruta
relativa.
Muchas gracias.
--
Flérida para mí dulce y sabrosa,
más que la fruta de cercado ajeno.
--- Garcilaso de la Vega ---
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/20140601102...@cubo.casa
> No estoy seguro de haverlo entendido bien y además me parece que mi
> solución es tan evidente que supongo ya la habrás probado, pero... ala
> voy:
>
Siento responder tan tarde, pero no me ha acompañado la salud...
No, no se me había ocurrido. Es una solución bastante guarretera, pero
creo sí es solución (no lo he probado). Miré el RFC que me dijo
Camaleón, pero no llegué a comprender del todo por qué se comporta el
servidor FTP con los enlaces simbólicos del modo en que se comporta:
http://tools.ietf.org/html/rfc3659#section-7.5
Creo que la posible explicación está en 7.5.2, pero no saco nada en
claro. Comprobé que si el enlace simbólico y el fichero real no tienen
el mismo nombre, no funciona el enlace dentro del FTP, aunque use ruta
relativa.
Muchas gracias.
--
Flérida para mí dulce y sabrosa,
más que la fruta de cercado ajeno.
--- Garcilaso de la Vega ---
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Camaleón
Jun 1, 2014, 12:00:02 PM6/1/14
to
El Sun, 01 Jun 2014 12:25:50 +0200, José Miguel (sio2) escribió:
> El Tue, 27 de May de 2014, a las 09:32:17AM +0200, Francesc Guitart
> dijo:
>
>> No estoy seguro de haverlo entendido bien y además me parece que mi
>> solución es tan evidente que supongo ya la habrás probado, pero... ala
>> voy:
>>
>> [...]
>
> Siento responder tan tarde, pero no me ha acompañado la salud...
>
> No, no se me había ocurrido. Es una solución bastante guarretera, pero
> creo sí es solución (no lo he probado).
Hum... pero si antes me dijiste que eso no funcionaba, pillín >;-)
> El Tue, 27 de May de 2014, a las 09:32:17AM +0200, Francesc Guitart
> dijo:
>
>> No estoy seguro de haverlo entendido bien y además me parece que mi
>> solución es tan evidente que supongo ya la habrás probado, pero... ala
>> voy:
>>
>> [...]
>
> Siento responder tan tarde, pero no me ha acompañado la salud...
>
> No, no se me había ocurrido. Es una solución bastante guarretera, pero
> creo sí es solución (no lo he probado).
> Miré el RFC que me dijo Camaleón, pero no llegué a comprender del todo
> por qué se comporta el servidor FTP con los enlaces simbólicos del modo
> en que se comporta:
>
> http://tools.ietf.org/html/rfc3659#section-7.5
>
> Creo que la posible explicación está en 7.5.2, pero no saco nada en
> claro. Comprobé que si el enlace simbólico y el fichero real no tienen
> el mismo nombre, no funciona el enlace dentro del FTP, aunque use ruta
> relativa.
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.
Saludos,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
José Miguel (sio2)
Jun 1, 2014, 2:40:02 PM6/1/14
to
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 ---
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/2014060118...@cubo.casa
> Hum... pero si antes me dijiste que eso no funcionaba, pillín >;-)
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.
/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 ---
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Camaleón
Jun 2, 2014, 10:30:02 AM6/2/14
to
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.
(...)
> 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".
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).
/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:
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
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-
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
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.
(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.
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-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
José Miguel (sio2)
Jun 2, 2014, 1:50:03 PM6/2/14
to
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-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/2014060217...@cubo.casa
> 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.
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"
simbólico.
> 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.
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 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?
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.
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
> 2/ Probar con ssh (mediante sftp)
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
> 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).
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-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Camaleón
Jun 2, 2014, 5:10:02 PM6/2/14
to
El Mon, 02 Jun 2014 19:48:45 +0200, José Miguel (sio2) escribió:
> 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.
Pero la jaula (y el montaje con --bind) lo único que hace es permitir que
> 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.
un usuario sin acceso a un directorio (por quedar fuera de su ámbito)
pueda acceder. No debería interferir para nada en el comportamiento del
ftp ni de los enlaces simbólicos, siempre y cuando estén configurados los
permisos correctamente.
> 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.
al principio del hilo.
El usuario que accede mediante ftp tiene que tener acceso a "/srv/ftp/
Almacen" y todo lo que cuelgue de ahí, para eso sirve precisamente montar
el recurso "bindeado". Si no tiene acceso, ningún enlace (sea duro o
blando) funcionará.
> ¿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.
de reconocer los enlaces simbólicos y seguirlos pero se topa con el muro
de la jaula que le impide acceder al recurso tienes que solucionar eso,
obviamente. Pero como estabas tan convencido de que este no era un
problema de enjaulamiento me has hecho dudar :-)
Salvo que lo que quieras (como así parece ser) es sobrescribir el enlace
simbólico por un archivo con el contenido completo que subes, vamos, que
quieras romper ese enlace simbólico para generar un archivo convencional.
> 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.
archivo, y que entiendo tiene prioridad en este caso.
Vale, entonces ya veo que el problema no es de la jaula ni de permisos ni
de rutas relativas/absolutas ni demás gaitas, lo que quieres es que el
servidor ftp rompa en enlace simbólico sin generar ningún error. Lo cual
me lleva a la siguiente preguntonta... si no quieres que se sigan los
enlaces simbólicos ¿para qué los generas?
(...)
>> 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.
Bien, en tu caso no existe porque no lo has configurado para que tenga
acceso pero sería posibles hacerlo, aunque si al final he entendido lo
que quieres hacer, no es eso lo que buscas.
>> 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.
se le puede pedir mucho.
>> 3/ Probar con un enlace simbólico que esté en el mismo directorio
>
> No entiendo esto que dices.
usuarios no tienen acceso al directorio "/srv/ftp/Almacen/".
>> 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.
seguir, al subir el archivo (put) se modificaría el destino y veo que no
es eso lo que quieres porque eso sí que sería factible configurando la
jaula correctamente.
Saludos,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
0 new messages