Installazione CentOS da mirror locale.

Visualizzazione dei risultati da 1 a 5 su 5
  1. #1
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    43
    Messaggi
    23,380
    configurazione

    Predefinito Installazione CentOS da mirror locale.

    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.

    Clicca sull'immagine per ingrandirla

Nome:   ftp-png.png
Visite: 460
Dimensione:   155.8 KB
ID: 13212

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

    codice:
    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.
    codice:
    [...]
    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)
    codice:
    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??

    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  2. #2
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    43
    Messaggi
    23,380
    configurazione

    Predefinito

    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:
    Clicca sull'immagine per ingrandirla

Nome:   no_REST.png
Visite: 309
Dimensione:   16.4 KB
ID: 13213

    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:
    Originariamente inviato da /etc/vsftpd/vsftpd.conf
    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:
    Originariamente inviato da /etc/vsftpd/vsftpd.conf
    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

    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  3. #3
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    43
    Messaggi
    23,380
    configurazione

    Predefinito

    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:
    codice:
    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"

    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  4. #4
    ●⁞◌ Ȏrȉzzȏntέ Ðέglȋ ȨvέntȊ ◌⁞●
    Registrato
    Aug 2008
    Località
    Palermo
    Messaggi
    2,952

    Predefinito

    = 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.


  5. #5
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    43
    Messaggi
    23,380
    configurazione

    Predefinito

    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!!

    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

Informazioni Thread

Users Browsing this Thread

Ci sono attualmente 1 utenti che stanno visualizzando questa discussione. (0 utenti e 1 ospiti)

Regole d'invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
nexthardware.com - © 2002-2022