This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 505424 - Unable to retrieve kickstart from password-protected FTP server
Unable to retrieve kickstart from password-protected FTP server
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: anaconda (Show other bugs)
5.3
All Linux
medium Severity medium
: rc
: ---
Assigned To: Martin Sivák
Alexander Todorov
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-11 16:44 EDT by Brad Hinson
Modified: 2010-03-30 04:02 EDT (History)
5 users (show)

See Also:
Fixed In Version: anaconda-11.1.2.199
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-03-30 04:02:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Parse login/password from url (3.36 KB, patch)
2009-06-11 16:44 EDT, Brad Hinson
no flags Details | Diff
tar.gz archive of /tmp in stage2 (32.90 KB, application/x-gzip)
2009-12-15 05:56 EST, Alexander Todorov
no flags Details
tar.gz archive of /tmp in stage2 (32.45 KB, application/x-gzip)
2010-01-14 10:12 EST, Alexander Todorov
no flags Details

  None (edit)
Description Brad Hinson 2009-06-11 16:44:19 EDT
Created attachment 347471 [details]
Parse login/password from url

Description of problem:
In RHEL 5.3 (anaconda-11.1.2.168) the installer fails to retrieve a kickstart file hosted on password-protected FTP with syntax:

ks=ftp://user:pass@server.example.com/path/to/ks

with error message:

16:52:09 ERROR   : failed to retrieve
http://user:pass@server.example.com///path/to/ks


Strangely enough, the code to parse the login and password was present in RHEL 4 (anaconda-10.1.1.99) and is also present in F12.  The attached patch is a backport from HEAD of the relevant parts to parse login and password from ks= parameter.


Version-Release number of selected component (if applicable):
anaconda-11.1.2.168


How reproducible:
100%
Comment 1 RHEL Product and Program Management 2009-09-25 13:44:02 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 2 Chris Lumens 2009-09-30 13:40:42 EDT
It's worth noting that for RHEL6, once we have anaconda-13.0 or later in the tree, we will need to retest this to verify that it's still fixed in light of my libcurlization patch.
Comment 4 Martin Sivák 2009-11-05 03:03:01 EST
I touched the code in Fedora recently, so I may as well backport the feature to rhel too.
Comment 5 Martin Sivák 2009-11-10 04:36:51 EST
Fix should appear in anaconda 11.1.2.196.
Comment 7 Alexander Todorov 2009-12-14 12:27:25 EST
This fails with anaconda 11.1.2.198. 

ks=ftp://atodorov:passwprd@server.com/ks.cfg

anaconda.log says:

INFO: transfering ftp://atodorov:passwprd@server.com/ks.cfg to a fd
ERROR: cannot determine address family of atodorov
ERROR: failed to retrieve http://atodorov:password@server.com/ks.cfg
Comment 8 Martin Sivák 2009-12-15 05:15:54 EST
Can you give me the log files too please? I'm interested in DEBUG messages.
Comment 9 Alexander Todorov 2009-12-15 05:56:13 EST
Created attachment 378471 [details]
tar.gz archive of /tmp in stage2
Comment 10 Alexander Todorov 2009-12-15 05:58:02 EST
The logs this time look a bit different than from comment #7. I've canceled the ks.cfg download and went to stage2 to collect all the logs under /tmp
Comment 12 Alexander Todorov 2010-01-14 10:12:16 EST
Created attachment 383694 [details]
tar.gz archive of /tmp in stage2

This is with anaconda-11.1.2.200-1 -0114.nightly.

Tested on virtual machine where anaconda boot command line has ks=ftp://atodorov:redhat@server/ks.cfg. 

loader prompted for ks.cfg location as it was not able to download the file. trying with wget and the same ftp url works just fine. 

/var/log/xferlog looks like:
Thu Jan 14 15:10:15 2010 1 10.36.11.189 372 /home/atodorov/ks.cfg b _ o r atodorov ftp 0 * c
Thu Jan 14 15:11:00 2010 1 10.16.71.182 0 /ks.cfg b _ o r atodorov ftp 0 * i
Thu Jan 14 15:11:03 2010 1 10.16.71.182 0 /ks.cfg b _ o r atodorov ftp 0 * i


1st line is with wget from my desktop and 2nd and 3rd lines are from anaconda.
Comment 13 Alexander Todorov 2010-01-14 10:12:58 EST
moving back to assigned.
Comment 14 Martin Sivák 2010-01-15 06:14:28 EST
Well this doesn't seem to be related to ftp login bug. It seems that we logged in successfully and we asked for /ks.cfg exactly as you requested in the url. Your ftp server apparently returned nothing...

So this might be a new bug, because your wget used different path than anacondas ftp client. Is there any reason for it?
Comment 15 Alexander Todorov 2010-01-15 07:57:43 EST
Martin,
I don't know why the request path differs. Adding jskala to CC as he seems to be vsftpd maintainer.

Jiri,
can you take a look at comment #12 and comment #14 and tell us why the same url request appears as 2 different paths on the server?
Comment 16 Martin Sivák 2010-01-15 08:07:20 EST
Alex: can you retest using /home/atodorov/ks.cfg as the path in anaconda? We may at least figure out if the login&download code works and concentrate only on the path issue if it does.
Comment 17 Jiri Skala 2010-01-18 07:49:15 EST
I've tested vsftpd on RHEL5 with wget and ftp. Xferlog contains the same paths in both cases. What about sync with mounting time of /home or something similar.

Send more info about your tests (conf, versions etc.) ...

Jiri
Comment 18 Alexander Todorov 2010-01-20 06:48:08 EST
(In reply to comment #16)
> Alex: can you retest using /home/atodorov/ks.cfg as the path in anaconda? We
> may at least figure out if the login&download code works and concentrate only
> on the path issue if it does.    

Martin,
when ks=ftp://atodorov:password@server.com/home/atodorov/ks.cfg then anaconda is able to pull down the ks.cfg file and proceed to stage2 automatically. It's probably a path issue.
Comment 19 Alexander Todorov 2010-01-20 06:50:25 EST
(In reply to comment #17)
> Send more info about your tests (conf, versions etc.) ...
> 


Jiri,
I'm using vsftpd on RHEL5.5 with it's default configuration. What I do before starting anaconda is this:

1) yum -y install vsftpd
2) service vsftpd start
3) useradd atodorov
4) passwd atodorov
5) chmod a+r /home/atodorov
6) create /home/atodorov/ks.cfg
Comment 20 Ludek Smid 2010-01-28 06:39:05 EST
(In reply to comment #18)
> (In reply to comment #16)
> when ks=ftp://atodorov:password@server.com/home/atodorov/ks.cfg then anaconda
> is able to pull down the ks.cfg file and proceed to stage2 automatically. It's
> probably a path issue.    
Alex, this seems verified then. If you have issues with path, I recommend to file a new bug. Move this to VERIFIED, please.
Comment 21 Alexander Todorov 2010-01-28 11:03:42 EST
I've tried password ftp for the method= URL with RHEL5.4. It also needs the user to specify the full path to the tree, including the user home directory. 

I'll move this to VERIFIED because the same behavior is present in 5.4 and because comment #18 successfully retrieved the ks.cfg file when specified by full path
Comment 22 Alexander Todorov 2010-01-28 11:06:26 EST
Jiri, Martin,
please advise what should be the default behavior wrt file path. When opening the non-anonymous URL with Firefox it automatically displays the contents of the user's home directory. It is also able to download files without specifying the absolute path on disk but only the relative path (relative to $HOME). 

If anaconda needs the absolute path this should be documented.
Comment 24 errata-xmlrpc 2010-03-30 04:02:20 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2010-0194.html

Note You need to log in before you can comment on or make changes to this bug.