vsftp en versión unstable

Hola,
¿Funciona el servidor ftp en la versión unstable?. Porque cuando trato de acceder me sale el mensaje "vsftpd: applet not found".

Pues en principio tendría que funcionar, porque no se ha actualizado en mucho tiempo.

Comprueba por telnet que existe el directorio "/var/run/vsftpd"
Si no existe, edita el archivo "/etc/rc.mini" y cambia esta línea:

Código:

/bin/mkdir -p -m 755 /var/run /var/log /var/media /var/lock

por:

Código:

/bin/mkdir -p -m 755 /var/run/vsftpd /var/log /var/media /var/lock

También puedes mirar el archivo /var/log/messages para ver si se ve el error.

A mi esto sí me funciona.

El directorio /var/run/vsftpd sí existe. En messages no aparece nada cuando trato de conectarme vía ftp.

El binario /usr/sbin/vsftpd ocupa 108181 bytes. Y si trato de ejecutarlo directamente me sale ésto:

Código:

/usr/sbin/vsftpd: line 1: ELFp44: not found
¬ÐçY: not foundd: line 2: GNUA
/usr/sbin/vsftpd: line 3: syntax error: unexpected ")"


Lo raro es el mensaje. Lo del "applet not found". Como si el busybox se creyera que el vsftpd es parte de él (no lo es, ¿no?).

Buscando por ahí, he leído que cuando el busybox confunde programas externos con applets internas puede ser debido a enlaces rotos en las librerías compartidas.

Por si fuera por ahí, el comando ldd sobre vsftpd me da:

Código:

        linux-gate.so.1 =>  (0xffffe000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0xb77fb000)
        libnsl.so.1 => /lib/libnsl.so.1 (0xb77e1000)
        libc.so.6 => /lib/libc.so.6 (0xb7674000)
        /lib/ld-linux.so.2 (0xb784f000)


No sé si será eso, pero en el gigaset no existe /lib/libc.so.6, existe /lib/libc.so.0.

Al menos, lo que sí es cierto, es que el vsftpd es vs...

Código:

/usr/sbin/vsftpd: line 3: syntax error: unexpected ")"

A mi esto me suena de cuando intenté ejecutar el gdb compilado por nuestro toolchain en el propio gigaset y resulta que lo que tenemos es un cross debugger y por tanto se tiene que ejecutar desde tu PC, no desde el gigaset.

Creo que estos errores son porque al tener permiso de ejecución pero no reconocerse como un programa nativo, lo intenta interpretar la shell, no encontrando los comandos ni entendiendo la sintaxis.

¿El ldd lo ejecutas en el PC o te has compilado uno para el gigaset? Porque a mi el ldd y el file en el PC me dicen cosas raras:

Código:

$ ldd ./rootfs_dir_m740_pro/usr/sbin/vsftpd
   no es un ejecutable dinámico
$ file ./rootfs_dir_m740_pro/usr/sbin/vsftpd
./rootfs_dir_m740_pro/usr/sbin/vsftpd: ELF 32-bit MSB executable, MIPS, MIPS-II version 1 (SYSV), dynamically linked (uses shared libs), corrupted section header size


Pero lo dice en todos los binarios del gigaset. Por cierto, el vsftpd me ocupa 186256 bytes.

Yo creo que o no se ha compilado el ejecutable para la arquitectura MIPS (pasale el file) o está corrupto o le faltan librerías dinámicas. Alguna razón por la que a ti no se te ejecuta como programa nativo y se intenta interpretar como shell script.

He ejecutado el file y tienes razón, no estaba compilado para MIPS:

Código:

rootfs_dir_m740_andreas-unstable/usr/sbin/vsftpd: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.4, dynamically linked (uses shared libs), corrupted section header size

Por hacer una prueba, he cambiado en el vsftpd.mk esta línea

Código:

$(UCLIBC_ENV) $(MAKE) -C $(VSFTPD_DIR)

por esta otra:

Código:

$(UCLIBC_ENV) $(MAKE) -C $(VSFTPD_DIR) $(UCLIBC_ENV)

y voilà:

Código:

rootfs_dir_m740_andreas-unstable/usr/sbin/vsftpd: ELF 32-bit MSB executable, MIPS, MIPS-II version 1 (SYSV), dynamically linked (uses shared libs), corrupted section header size

Lo cual, plantea unas cuantas dudas:

La primera es ¿por qué a mi me falla y a otros les funciona?. Tengo la sospecha de que la versión del make (3.82) tiene algo que ver (en otro problema con el que me encontrado, esa era la causa), pero no lo puedo asegurar.

La segunda es ¿por qué compila correctamente otros ejecutables, dónde el .mk es como el del vsftpd?

Por ejemplo, en dropbear.mk la linea que llama al make es:

Código:

$(UCLIBC_ENV) $(MAKE) -C $(DROPBEAR_DIR) PROGRAMS="dropbear dbclient dropbearkey scp" MULTI=1

así, que tampoco debería crear ejecutables compilados para MIPS y, sin embargo, lo hace.

En el caso del dropbear he buscado la respuesta: el Makefile lo construye el configure y es el propio Makefile el que contiene los CFLAGS correctos:

Código:

CFLAGS=-I. -I$(srcdir) -I$(srcdir)/libtomcrypt/src/headers/ $(CPPFLAGS) -march=mips2 -mtune=vr4120 -O3 -msoft-float -mfix-vr4120


Pero ¿qué pasa con el resto?. Los he revisado todos y el único que estaba mal era el vsftpd, pero creo que hay que andarse con ojo.