Bug 154762

Summary: http install can't find CD[2-5] if missing trailing / in specified path
Product: [openSUSE] SUSE Linux 10.1 Reporter: Chad Groneman <cgroneman>
Component: InstallationAssignee: Jiri Srain <jsrain>
Status: RESOLVED FIXED QA Contact: Klaus Kämpf <kkaempf>
Severity: Normal    
Priority: P5 - None CC: alexander.a.subbotin, bugproxy, forgotten_QtBI7gWTIh, mvidner, suse-beta
Version: Beta 6   
Target Milestone: ---   
Hardware: x86-64   
OS: Other   
Whiteboard:
Found By: Other Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: bz2 archive of YaST Log files
archive of /var/log/apache2

Description Chad Groneman 2006-03-02 17:23:44 UTC
Doing an http install, the installer can't find CD 2,3,4,5 if the path is missing the trailing slash.  I will attach logs when I get home from work. :)

I set up a SUSE Linux 10.0 Installation server and used the YaST module to create an http install source for SUSE Linux 10.1 beta6.  Then, from the CD boot menu, I choose an HTTP installation.  I specify the IP address of the install server, and a path such as "/install/b6" or "install/b6".  It works for the first CD, but for each subsequent CD, it cannot find it.  If I go to the details and add a trailing slash (ie, from "http://10.0.0.1/install/b6" to "http://10.0.0.1/install/b6/"), it is able to find the next CD and continue until it is ready for the next CD, where it has the same problem.
Comment 1 Chad Groneman 2006-03-02 17:26:31 UTC
BTW, I'm not using smaster.novell.com - Bugzilla must have resolved that internally.  I really put in http_://_10.1.1._1/install/b6 (remove the underscores).
Comment 2 Kirk Coombs 2006-03-02 23:38:39 UTC
This happens with FTP as well. I know this behavior did not occur in past versions.
Comment 3 Marius Tomaschewski 2006-03-03 13:02:15 UTC
Can you provide the YaST logs from your installation, please?
Please provide all y2log* files from /var/log/YaST2 -- see
http://en.opensuse.org/Bug_Reporting_FAQ#YaST
Comment 4 Chad Groneman 2006-03-03 15:14:43 UTC
Created attachment 71166 [details]
bz2 archive of YaST Log files
Comment 5 Jon Nelson 2006-03-04 20:28:06 UTC
That's interesting - would you be able to find and post a small portion of the httpd logs - the httpd should log the access to the (non-existant) resource. I'm wondering if this is related to bug 152068.
Comment 6 Marius Tomaschewski 2006-03-06 13:53:36 UTC
It is not a problem of a "/" or missed "/" at the end of the Url, but
results from Url rewriting that is done in the MediaSet class.
It assumes, that each CD is in a .../CD1, .../CD2, ... subdirectories
and modifies the last path-part in the Url.

In the scenario used here, all CDs are "merged" (copied over each other)
into one directory, so it is not needed to rewrite the Url at all.

Perhaps we can just replace the verifier in the access handler of CD1,
to the one checking for CD2 to see if the Url / access handler of CD1
also provides CD2, before any rewrite of the Url.

From y2log-2:

2006-03-01 18:09:41 <0> linux(4136) [source] MediaSet.cc(rewriteUrl):113 Rewriting url http://172.26.10.152/install/b6
2006-03-01 18:09:41 <0> linux(4136) [source] MediaSet.cc(rewriteUrl):125 Url rewrite result: http://172.26.10.152/install/b2
2006-03-01 18:09:41 <1> linux(4136) [media] MediaAccess.cc(open):96 Trying scheme 'http'
2006-03-01 18:09:41 <1> linux(4136) [media] MediaCurl.cc(MediaCurl):78 MediaCurl::MediaCurl(http://172.26.10.152/install/b2, )
Comment 7 Marius Tomaschewski 2006-03-06 14:00:42 UTC
*** Bug 154110 has been marked as a duplicate of this bug. ***
Comment 8 Stanislav Visnovsky 2006-03-06 14:58:46 UTC
Jiri, MediaSet should not try to rewrite non-CD/DVD URLs.
Comment 9 Jiri Srain 2006-03-06 20:48:56 UTC
It has to, because of the scenario for having CDs sepratelly (each in its directory). The only thing that can be done to prevent this problem is to extend the regular expression...
Comment 10 Chad Groneman 2006-03-07 01:23:02 UTC
Created attachment 71495 [details]
archive of /var/log/apache2

I don't remember if I've used the web server for installing each beta.  Some I did, some I used NFS, some I used CDs.

My naming convention is /srv/www/htdocs/install/[a,b][0-9], ie b4 for beta4, a2 for alpha2, etc.  But I think I delete the old install sources when I create an updated source.
Comment 11 Jiri Srain 2006-03-07 15:12:37 UTC
I fixed the regular expression in SVN, so that it rewrites the URL only if there is CDx or DVDx at the end (case insensitive). It shuold solve the prohblem.
Comment 12 Marius Tomaschewski 2006-03-07 17:44:43 UTC
(In reply to comment #9)
> It has to, because of the scenario for having CDs sepratelly (each in its
> directory). The only thing that can be done to prevent this problem is to
> extend the regular expression...

Yes, the Url needs a rewrite, except the media id Url of CD1 providers
also the CD2.

This seems to be the case if the http installation server is prepared by
some yast2 module (Bug #154110#c3 contains a directory listing).

Perhaps we can add a check for this condition and reuse the access id and
replace the verifier only?
See my mail with attached diff, that should show if the condition is true.
Comment 13 Jiri Srain 2006-03-09 22:16:31 UTC
*** Bug 141181 has been marked as a duplicate of this bug. ***
Comment 14 Jiri Srain 2006-03-15 20:57:51 UTC
*** Bug 157470 has been marked as a duplicate of this bug. ***
Comment 15 Stanislav Visnovsky 2006-03-16 14:29:44 UTC
*** Bug 153476 has been marked as a duplicate of this bug. ***
Comment 16 Jiri Srain 2006-03-16 15:42:37 UTC
*** Bug 157928 has been marked as a duplicate of this bug. ***
Comment 17 LTC BugProxy 2006-03-20 03:12:04 UTC
changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ACCEPTED                    |CLOSED
             Impact|------                      |Installability




------- Additional Comments From shenlinf@cn.ibm.com  2006-03-19 22:07 EDT -------
This bug doesn\'t occure on beta8.
Closing this defect. 
Thanks all for you help. 
Comment 18 LTC BugProxy 2006-03-20 13:51:57 UTC
changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ACCEPTED                    |CLOSED
             Impact|------                      |Installability




------- Additional Comments From shenlinf@cn.ibm.com  2006-03-19 22:07 EDT -------
This bug doesn\'t occure on beta8.
Closing this defect. 
Thanks all for you help.