[Yum] yumtunnel and ignore-failure

Robert G. Brown rgb at phy.duke.edu
Wed Jul 30 15:52:56 UTC 2003


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 at 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 at 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 at 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 at phy.duke.edu






More information about the Yum mailing list