Michael Stenner wrote: > I'm in the process of working in the patch you submitted. I have a > couple of comments, and a question for the list. > > Let me start with the question because that's likely of the most > general interest: What happens when you do both authenticated > connections AND failover/mirroring? Specifically, what happens if you > want to have two servers in a failover list with different > username/password, or one's public? I haven't been following the failover thing at all. So with failover, there can be multiple baseurl entries per serverid? > If we deal with this by having options in the config file, you're > sorta screwed. If the info is buried in the url, then you can do it > PER url. I can think of three real options, in order of increasing > technical pain and complexity. > > 1) allow options only - build up the url where needed (ftp, etc) This is where I've been going, obviously, because Seth pointed me in that direction, and I had no strong objections to it. (BTW-Seth, was there a reason to switch to urllib2, instead of urllib, other than just that it is newer? It seems unnecessarily complicated and new-fangled for what yum has to do, while urllib is dead simple. But I'm a Python newbie, so I'm not allowed to hold strong opinions.) > 2) allow url-embedding only - for the new http stuff, that would > require pulling them out of the url and dealing with them > correctly. This wouldn't be that hard. The complexity that results is made up for by the simpler FTP case (in the FTP case, with user and password directives, we have to build up the embedded URL). It also has the minor benefit of keeping the same syntax that currently works in earlier urllib-based yum versions. I lean towards this being the Right Way for that reason. > 3) allow both - url-embedded info overriding option info. This way, > if you have all the same auth info, just use the options. If > they're different, then encode them in the urls. This is the best > of both world for users, and worst of both worlds for the coders. I'd really rather not see two ways to deal with auth info. It is inconsistent for the user, harder to program, and provides no benefits to the user that I can think of. I hold a strong opinion on this one, just from a user perspective. Pick one way, and use it universally for all types of server auth info. I'll also mention that from perspective of developers of GUIs, multiple syntaxes for the same thing make life more difficult than necessary and bugs in the GUI/docs/etc. more likely. I say this from the perspective of one planning to add yum support to Webmin's Software Packages module in the next week or two. > On Tue, May 20, 2003 at 12:49:46AM -0500, Joe Cooper wrote: > >>I've attached a patch that adds HTTP basic auth to yum 1.97 using the >>urllib2 HTTPBasicAuthHandler. It adds three new configuration file >>directives (user, password, and realm). All three appear to be required >>for the urllib2 auth support to work (I would so love to kill the realm >>directive but I can find no documentation that explains how to get by >>without it, and a couple of hours of testing and searching resulted only >>in frustration--if anyone has a clue on this point, I'd be very happy to >>hear it). > > > Joe, I've done this... sorta. I've derived from > urllib2.HTTPPasswordMgr and overridden find_user_password so that > there is a "default" realm. Anything added with realm=None will get > put there. Yeah, I was talking to someone via IRC the other day (thanks Tres!) about this, and he seemed to think the HTTPPasswordMgrWithDefaultRealm would do what I want without even having to override anything. I couldn't figure out how to make this one go when I was working on it over the weekend, but I can only safely plead ignorance rather than claim the documentation is lacking significantly, though that would be my first instinct were it a language I know better. >>I haven't added in the FTP support yet, but it is harmless to all of the >>other schemes (file and ftp), as far as I know. >> >>I've tested all of the yum commands against a server that does require >>and a server that does not require authentication and they all work, but >>I'm sure it is still buggy. > > > The biggest change that I've made is that you do not need to rebuild > the handler every time you get a file. It is sufficient simply to add > the username/password/realm to the existing handler. With that > change, the part that happens inside urlgrab is reduced to: > > if username and password and http_auth_handler and scheme == 'http': > http_auth_handler.add_password(realm, host, user, password) This makes sense. I noticed that quite a lot of stuff was persistent between calls to retrygrab, once I was finished with the bulk of the work. I don't understand why they are persistent yet, but now that I see that they are this kind of approach makes more sense. >>One comment, which is probably more of a statement of my Python >>ignorance than a useful criticism: The keepalive bit at the top of >>urlgrabber forces some extra extraneous checks into the auth code, >>because it doesn't guarantee that an opener comes into existence. This >>seems like it could lead to bugs. If the way the keepalive setup works >>changes, auth setup breaks...I'm probably in the wrong on this, but I >>couldn't figure out a way to check for the existence of the opener >>object (and believe me I tried). I guess another try/except, of some >>sort, might be the solution to this. > > The above helps a lot, of course. Basically, I set up the auth stuff > FIRST. After that, you're guaranteed to have an opener (as long as > it's python 2). Then keepalive just does .add_handler as you were > doing later. Ok. That's a better way, indeed. Thanks for pointing it out. >>I'm just posting for comments, as I plan to add FTP support before I >>start campaigning for Seth to add this to the real yum. But I welcome >>any criticisms, as long as you've got a better way and tell me what it >>is. ;-) > > > I'd still be interested in your ftp code. I'm holding off on working > on that until I get some replies to my question. If you're interested > in seeing the actual code, I'll send it to you. Otherwise, I'm going > to wait to see which way folks want to go before committing. Go ahead and send over what you've got and I'll add FTP support tomorrow. It sounds like your changes make things a little cleaner than my implementation, and I'll be happy to be rid of the weird reliance on the keepalive stuff never changing. I'll also do some more experimentation with the HTTPPasswordMgrWithDefaultRealm class to see if I can make it go. -- Joe Cooper <joe@xxxxxxxxxxxxx> Web caching appliances and support. http://www.swelltech.com
