Installazione CentOS da mirror locale.

[frakka]

La situazione è la seguente:

1_ Server ftp con vsftpd su debian, accesso anonimo perfettamente funzionante e ampiamente testato. Vi ho aggiunto una directory che è aggiornata giornalmente con rsync per avere un mirror locale di CentOS 6.4.
2_ Il client è una virtual machine CentOS6.4 su un host KVM sempre CentOS6.4. Ho creato la virtual machine indicando come sorgente per l'installazione l'url "ftp://ftp.miodominio.it/Centos/6/os/x86_64/"
3_ Lo stesso url è correntemente utilizzato da yum come mirror per l'aggiornamento delle installazioni di CentOS presenti sulla mia rete locale ed è perfettamente funzionante.

Avvio la virtual machine, l'installazione parte in modalità grafica. l'installer mi chiede tutte le informazioni che gli servono per la configurazione e poi parte l'installazione. Al momento di recuperare i pacchetti dall'ftp, però, l'installazione si blocca e non va avanti: L'installer segnala l'impossibilità di accedere ai pacchetti rpm necessari che sono però effettivamente presenti sul server.

Ho quindi provato a scaricare a mano uno di questi pacchetti switchando su un'altra tty:

ftp> dir Centos/6/os/x86_64/Packages/alsa-utils*
227 Entering Passive Mode (192,168,200,1,123,60).
150 Here comes the directory listing.
-rw-rw-r--    1 ftp      ftp       2057272 Feb 23 19:40 alsa-utils-1.0.22-5.el6.x86_64.rpm
226 Directory send OK.
ftp> get Centos/6/os/x86_64/Packages/alsa-utils*
Centos/6/os/x86_64/Packages/alsa-utils*: Bad directory components
ftp> get Centos/6/os/x86_64/Packages/alsa-utils-1.0.22-5.el6.x86_64.rpm
Centos/6/os/x86_64/Packages/alsa-utils-1.0.22-5.el6.x86_64.rpm: Bad directory components
ftp> cd Centos/6/os/x86_64/Packages/
250 Directory successfully changed.
ftp> get alsa-utils-1.0.22-5.el6.x86_64.rpm
alsa-utils-1.0.22-5.el6.x86_64.rpm: Bad directory components
ftp> get alsa-utils*
227 Entering Passive Mode (192,168,200,1,121,87).
550 Failed to open file.

Ho messo in debug il log, loggando anche il protocollo ma non mi pare ci sia nulla di utile.

[...]
Sat Apr 13 17:41:46 2013 [pid 2] FTP command: Client "192.168.200.202", "USER anonymous"
Sat Apr 13 17:41:46 2013 [pid 1] [ftp_pubblico] OK LOGIN: Client "192.168.200.202", anon password ""
Sat Apr 13 17:41:46 2013 [pid 3] [ftp_pubblico] FTP response: Client "192.168.200.202", "230-"
Sat Apr 13 17:41:46 2013 [pid 3] [ftp_pubblico] FTP response: Client "192.168.200.202", "230-*** Directory riservata agli utenti anonimi. ***"
Sat Apr 13 17:41:46 2013 [pid 3] [ftp_pubblico] FTP response: Client "192.168.200.202", "230-"
Sat Apr 13 17:41:46 2013 [pid 3] [ftp_pubblico] FTP response: Client "192.168.200.202", "230 Login successful."
Sat Apr 13 17:41:46 2013 [pid 3] [ftp_pubblico] FTP command: Client "192.168.200.202", "SYST"
Sat Apr 13 17:41:46 2013 [pid 3] [ftp_pubblico] FTP response: Client "192.168.200.202", "215 UNIX Type: L8"
Sat Apr 13 17:42:02 2013 [pid 3] [ftp_pubblico] FTP command: Client "192.168.200.202", "CWD Centos/6/os/x86_64/Packages/"
Sat Apr 13 17:42:02 2013 [pid 3] [ftp_pubblico] FTP response: Client "192.168.200.202", "250 Directory successfully changed."
Sat Apr 13 17:43:45 2013 [pid 3] [ftp_pubblico] FTP command: Client "192.168.200.202", "CWD /"
Sat Apr 13 17:43:45 2013 [pid 3] [ftp_pubblico] FTP response: Client "192.168.200.202", "250 Directory successfully changed."
Sat Apr 13 17:44:08 2013 [pid 3] [ftp_pubblico] FTP command: Client "192.168.200.202", "CWD Centos/6/os/x86_64/Packages/"
Sat Apr 13 17:44:08 2013 [pid 3] [ftp_pubblico] FTP response: Client "192.168.200.202", "250 Directory successfully changed."
Sat Apr 13 17:45:08 2013 [pid 3] [ftp_pubblico] FTP command: Client "192.168.200.202", "TYPE I"
Sat Apr 13 17:45:08 2013 [pid 3] [ftp_pubblico] FTP response: Client "192.168.200.202", "200 Switching to Binary mode."
Sat Apr 13 17:45:08 2013 [pid 3] [ftp_pubblico] FTP command: Client "192.168.200.202", "PASV"
Sat Apr 13 17:45:08 2013 [pid 3] [ftp_pubblico] FTP response: Client "192.168.200.202", "227 Entering Passive Mode (192,168,200,1,121,87)."
Sat Apr 13 17:45:08 2013 [pid 3] [ftp_pubblico] FTP command: Client "192.168.200.202", "RETR alsa-utils*"
Sat Apr 13 17:45:08 2013 [pid 3] [ftp_pubblico] FTP response: Client "192.168.200.202", "550 Failed to open file."
Sat Apr 13 17:45:08 2013 [pid 3] [ftp_pubblico] FAIL DOWNLOAD: Client "192.168.200.202", "/Centos/6.4/os/x86_64/Packages/alsa-utils*", 0.00Kbyte/sec

La cosa strana, è che puntando con un qualunque browser lo stesso identico files, ovviamente viene scaricato perfettamente e senza problema alcuno ad ogni tentativo.
Altra stranezza: creando dei semplici files nella stessa directory, (touch nomefile) queste risulta invece perfettamente scaricabile.
Sembra che il problema sia limitato ai files rpm prensenti nel repository, non è un problema di permessi perchè anche assegnando 777 al files non cambia nulla.

Mentre scrivevo il post, sono riuscito in un paio di casi a scaricare il file sulla macchina fisica (non ho fatto nulla, solo rilanciato il medesimo comando di prima per prendere il log)

Sat Apr 13 17:56:03 2013 [pid 3] [ftp_pubblico] FTP command: Client "192.168.200.202", "RETR /Centos/6.4/os/x86_64/Packages/alsa-utils-1.0.22-5.el6.x86_64.rpm"
Sat Apr 13 17:56:03 2013 [pid 3] [ftp_pubblico] FTP response: Client "192.168.200.202", "150 Opening BINARY mode data connection for /Centos/6.4/os/x86_64/Packages/alsa-utils-1.0.22-5.el6.x86_64.rpm (2057272 bytes)."
Sat Apr 13 17:56:03 2013 [pid 3] [ftp_pubblico] OK DOWNLOAD: Client "192.168.200.202", "/Centos/6.4/os/x86_64/Packages/alsa-utils-1.0.22-5.el6.x86_64.rpm", 2057272 bytes, 11416.06Kbyte/sec

ma dall'installazione in VM continua a fallire con lo stesso errore.

Altra casistica: Sempre dalla vm, se provo a scaricare il medesimo files usango wget (wget ftp://ftp.miodominio.it/Centos/6.4/os/x86_64/Packages/alsa-utils-1.0.22-5.el6.x86_64.rpm) il download va a buon fine (sempre tramite protocollo ftp direi) senza alcun problema.

Bug??

[frakka]

Me la suono e me la canto...

Anticipo che ho avuto un problema analogo alcuni giorni fà in ufficio, tentando di sincronizzare un tablet Galaxy con un server ftp ed avevo già ipotizzato che il problema potesse essere lo stesso... Ma avevo sbagliato il comando!
Sono passato su un'altra tty e ho visto questo:

Nella configurazione del server ftp in ufficio non avevo un comando utilizzato dall'APP del tablet per scaricare i files dal server ftp tra gli "allowed": Ho controllato la mia configurazione ed effettivamente anche qui mi mancava il comando REST (serve per il download con resume, mentre per scaricare genericamente un file RETR è sufficiente). Il problema era effettivamente lo stesso che avevo in ufficio.
Avevo già provato a togliere dalla configurazione di vsftpd l'istruzione "cmds_allowed" ma evidentemente "REST" non fà parte della configurazione predefinita...

La configurazione era questa:

cmds_allowed=ABOR,APPE,AUTH,CDUP,CWD,DELE,FEAT,HELP,LIST,MKD,MDTM,NLST,NOOP,PASS,PASV,PBSZ,PROT,PWD, OPTS,QUIT,RMD,RNFR,RNTO,RETR,SIZE,STOR,SYST,TYPE,USER

modificata così ha preso a funzionare tutto correttamente:

cmds_allowed=ABOR,APPE,AUTH,CDUP,CWD,DELE,FEAT,HELP,LIST,MKD,MDTM,NLST,NOOP,PASS,PASV,PBSZ,PROT,PWD, OPTS,QUIT,RMD,RNFR,RNTO,RETR,REST,SIZE,STOR,SYST,TYPE,USER

Antipatico però il fatto che il log di vsftpd, seppure in debug e con registrazione del protocollo, non abbia riportato niente di utile per giungere alla soluzione del problema, tra ufficio e casa ci ho perso un sacco di tempo.



Ref:
RFC 5797 - FTP Command and Extension Registry

[frakka]

Ne ho approfittato per rivedere un attimo la configurazione dell'ftp, rivedendo la lista in base a quelli che vengono definiti come "mandatory" e "optional" dalla RFC:

Ora l'istruzione che uso è questa:

cmds_allowed=ABOR,ACCT,ALLO,AUTH,APPE,CDUP,CWD,DELE,FEAT,HELP,LIST,MDTM,MKD,MODE,NLST,NOOP,OPTS,PASS,PASV,PBSZ,PROT,PROT+,PORT,PWD,QUIT,REIN,REST,RETR,RMD,RNFR,RNTO,SITE,SIZE,SMNT,STAT,STOR,STOU,STRU,SYST,TYPE,USER

Che sono essenzialmente tutti i "mandatory" e gli "optional" con l'aggiunta di "AUTH,FEAT,MDTM,PBSZ,PROT,PROT+,OPTS,SIZE"

[Totocellux]

= come la precisa volontà di risoluzione portata avanti tramite capacità di una corretta rilevazione dei
riscontri e un'attenta analisi di questi, può in relativo breve tempo portare alla soluzione di un problema.

Molto molto bene.

[frakka]

Grazie.
Proprio "breve" no, ancora non capisco perchè aver disabilitato l'istruzione "cmds_allowed" (che avevo immaginato fin da subito come probabile causa) il problema persistesse...

Però sicuramente sono testardo!!