[CentOS] Yum / Up2date issues and mirror.centos.org

[Bryan J. Smith]

Les Mikesell <lesmikesell at gmail.com> wrote:
> Among other things, it changes when you move the machine.
> How do you deal with laptops?  The proxy at work is not
> available on my home network or a remote wireless
connection.

Okay, now you're talking about far _bigger_ issues than just
YUM.  Especially since I expect mobile users to talk to the
network far differently at work than when at home or when
mobile.  E.g., I don't believe in setting "default gateways"
on systems on a corporate network.  I also use multiple
Firefox and Evolution profiles, just like I do Outlook ones,
for when users are at home, at work or roaming.

But I'll meet you half-way.

First off, many Linux tools (including YUM) that access
information via HTTP look for a global environmental variable
called "http_proxy" in the format of:  
  http_proxy=http://USER:PASS@some.domain.com:PORT/
So your network scripts will need to export this, based on
what network you have connected to.  I do this all-the-time
for my mobile users, with our scripts.  Debian has actually
had a nice little framework for years to do this.

Secondly, Fedora Core 4 (and so RHEL 5) adds GNOME's
NetworkManager.  GNOME's NetworkManager basically addresses
the issues you talk about -- providing a _standard_ way for
_applications_ to go to _single_ place for dynamic networking
information.  It is essentially the GNOME equivalent proxy
settings for all GNOME applications to those of MS IE for all
GDI/Explorer applications.

That includes getting the Proxy server option from a DHCP
server, which brings me to my final item.

Proxy server information is commonly passed on enterprise
networks as a DHCP option.  IETF RFC2132 nailed down the
common DHCP options 8 years ago, but proxy server wasn't one
of them.  So it wasn't long before companies added their own
option for proxy server URL:port (e.g., Microsoft put the
option into its ADS/DHCP service starting with Windows 2000
Server), which eventually led to IETF BCP0043 (aka RFC2939)
-- the process on adding more.  Today there are a few DHCP
options that are "best current practices" (BCPs) that are
accepted by servers and clients.

But to go beyond that, there has been a continuing draft
standard** that not only addresses the current practices
beyond what BCP0043 specified, but defines an extensible set
so you can change the proxy server based on the service you
are trying to reach.  So it goes well above and beyond the
standard industry DHCP option, that basically gives only a
single URL:port for all.  E.g., I would personally like a way
I can direct SSH to a dedicated SOCKS proxy well away from
any other proxy.

[ **The latest revision (4) of this draft standard can be
found here: 
http://www.ietf.org/internet-drafts/draft-ietf-dhc-proxyserver-opt-04.txt

If the term "draft standard" throws you off, understand
almost _all_ standards created and used in the last 4-5 years
are _still_ "draft standards."  E.g., IPv4 LINKLOCAL
(169.254/16) is still considered a "draft standard" even
though it's been in widespread use for 6+ years.  The legacy
"throw everything out as a Request for Comments (RFC)" was
deprecated long ago -- let alone the whole "RFC" tag never
meant (by its very acronym) a "standard" either.  ;-]

As someone mentioned, from a security standpoint, using
transparent proxies should be "against the law."  ;->

Now, how much more do you want to throw at this?



-- 
Bryan J. Smith                | Sent from Yahoo Mail
mailto:b.j.smith at ieee.org     |  (please excuse any
http://thebs413.blogspot.com/ |   missing headers)