Dear yumsters and dulug humans: With Duke's recent move of off-campus broadband services into commercial ISPs, it has become much more difficult to run yum off of the restricted (duke only) part of the linux@duke repository. All the alternatives require some sort of authenticated access and have pro's and con's. Yesterday I tested doing it with a vpn client. This works, with the pro of providing transparent access to all sorts of duke-IP-restricted resources, not just yum's restricted space. The con is that ALL traffic then routes through the VPN (in my case from intrex.net), which makes my desktop at duke 19 hops away (I counted with traceroute) from my laptop inside my home network. These 16-19 hops, plus the 10-16 accessing a typical internet site FROM duke can add, (empirically) actually breaks ping contact to selected sites without screwing around with ICMP TTL values or whatever parameter is being exhausted. It also adds significant latency -- a single ping can traverse 60+ routers, each with variable load. My conclusion was that vpn is lovely as something to turn on on demand, but is a lousy solution to leave on all the time. Today I tested doing it instead with an IP tunnel over ssh. ssh can be set up easily to work without a password (on a per host, per user basis!), uses strong bidirectional encryption and host-level authentication, and requires only that the user have ssh access to a single system inside duke.edu to work. Just about all linux@duke users will have ssh access to at least one system on campus and hence inside duke.edu. I knew that this would "work" as I've used it before dating back to yup, but wanted to "encapsulate" it reusably this time. So I wrote /etc/init.d/yumtunnel and /usr/sbin/yumtunnel. They do what one expects: provide chkconfig control of the tunnel so that it automagically starts when a system (in my test case my linux@duke-9 laptop) boots, and then runs a trivial script (su'd to me) that is de facto a forwarding daemon on a specific, unprivileged port. I did not have success using the -D ssh option, probably because I couldn't figure out how to morph the resource request through the dynamic port allocation (help appreciated, as if I get this to work I don't need the vpn client at all and can use the tunnel on a per connection basis!). It all works. I didn't really do the su "correctly" (I did it in the script itself, only noting afterwards that the daemon function in init.d has an option for --user that does the same thing, I think). If that is your criterion for correctness. So at this point yum will auto-update at some odd hour in the morning via the tunnel, including the restricted space, without my having to either maintain a permanent vpn connection or be awake to type in a password. Scripts available on request. They are pretty trivial, and you might prefer to write them yourself, but I wanted to register this in the list archives as an available method both for Duke and for other domains with similar problems. During this process I noticed that it would actually be "nice" to have one more option on a per-repository basis -- ignore-failure. Right now yum dies altogether if the failover list for a repository is exhausted without finding a valid one. This is fine and good behavior if the repositories are primary ones for important components of the install. Not so good if they are add-on repositories for a little used component that you don't care so much about (as is actually the case for the duke add-on, which currently updates a single tool -- xv -- on my laptop which actually exists and "works" in the main repository anyway). ignore-failure would tell yum to go ahead and proceed in the event that the failover list is exhausted (either way, rr or priority), using only the repositories it can access. I would think that it would "freeze" revisions installed from the downed repository (which it can check on the basis of its existing header list). I would expect it to announce the fact that the repository was down (at the point where it does the Server: xxxx line) and that it was, per requested policy, updating (or whatever) from everything else. If this feature already exists, feel free to whack me with a manual, as always, but I scanned man yum.conf a number of times while playing and failed to see any way around a (transiently) inaccessible server short of actively editing it out of yum.conf. A user should be able to specify how "important" a server is to their update policy, since I now have two servers, one not at Duke at all, that provide updates of a single, highly nonessential package and as server lists get longer the relative fragility of yum's nightly update will increase. rgb -- Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@xxxxxxxxxxxx
