Bug 505424 - Unable to retrieve kickstart from password-protected FTP server
Summary: Unable to retrieve kickstart from password-protected FTP server
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: anaconda
Version: 5.3
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Martin Sivák
QA Contact: Alexander Todorov
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-06-11 20:44 UTC by Brad Hinson
Modified: 2010-03-30 08:02 UTC (History)
5 users (show)

Fixed In Version: anaconda-11.1.2.199
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-03-30 08:02:20 UTC
Target Upstream Version:
Embargoed:


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


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2010:0194 0 normal SHIPPED_LIVE anaconda bug fix and enhancement update 2010-03-29 12:24:02 UTC

Description Brad Hinson 2009-06-11 20:44:19 UTC
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 Program Management 2009-09-25 17:44:02 UTC
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 17:40:42 UTC
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 08:03:01 UTC
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 09:36:51 UTC
Fix should appear in anaconda 11.1.2.196.

Comment 7 Alexander Todorov 2009-12-14 17:27:25 UTC
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 10:15:54 UTC
Can you give me the log files too please? I'm interested in DEBUG messages.

Comment 9 Alexander Todorov 2009-12-15 10:56:13 UTC
Created attachment 378471 [details]
tar.gz archive of /tmp in stage2

Comment 10 Alexander Todorov 2009-12-15 10:58:02 UTC
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 15:12:16 UTC
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 15:12:58 UTC
moving back to assigned.

Comment 14 Martin Sivák 2010-01-15 11:14:28 UTC
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 12:57:43 UTC
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 13:07:20 UTC
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 12:49:15 UTC
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 11:48:08 UTC
(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 11:50:25 UTC
(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 11:39:05 UTC
(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 16:03:42 UTC
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 16:06:26 UTC
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 08:02:20 UTC
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.