On Wed, 2005-11-30 at 14:11, Bryan J. Smith wrote:
> > The 'what' is the problem. If our sales person want to
> > demo a product that connects on 6 different ports to
> > places that aren't known until the first connection
> > is established, will it work?
>
> If I setup the proxy to allow all access by default, such as
> I would in such a situation, then yes. But I do _not_ let
> just any port out the firewall.
Proxies won't handle our streaming data - and the ports
are not the commonly used ones. The next version
will work over socks5 but for now it has to go direct.
> > I didn't design the product, but I've had to help make
> > it work in places that don't use a default gateway.
> > It's not pretty.
>
> If people would make such security considerations in the
> first place, the Internet would be a lot safer. The problem
> is not the networks, but the apps.
An earlier product where I was involved in the design used
only couple of addresses and ports with the server farms
behind load balancers using a single address. Now we are
integrated into a much larger company with a more distributed
server base where the initial authentication server also
performs load balancing by telling the client which individual
server to use for each data type. There are disadvantages but
that approach scales better.
> > The reason there are other ways is that none of them
> > are perfect. There's nothing wrong with understanding
> > the flaws and tradeoffs of each.
>
> That was my point!
>
> So why were you so hell-bent on talking about how something
> must work only one way? And you continually discarded
> countless suggestions from others, and even more from myself,
> as if they were not options?
I don't think they solve the general problem unless they work
by default. That is, trying to reduce mirror bandwidth usage
by relying one every user with more than one machine to set
up their own mirror just doesn't seem right. Yes, it works,
yes it can solve an individual problem - but there has to be
a better way and it doesn't need new technology. Spreading
load has been solved ages ago with RRDNS - saving bandwidth
on repeated downloads was solved with caching proxies. Neither
needs special per-distribution setup or ongoing work.
> > Generally I don't want applications to use a proxy
> > unless I know they are going to download the same big
> > files as other systems. Otherwise it slows things down
> > slightly and has no benefit.
>
> No benefit?!?!?! Security???
Maybe, if you hook a virus scanner to the proxy or limit
destinations.
> > That's a reasonable approach, but takes an extra step and
> > unless the same programs are installed everywhere the
> > 1st system may not have all the others need.
>
> But it would _still_ cache the programs that are similar, as
> well as they test at least on the "common" system. Even you
> mentioned "testing," so I'm now even more curious how you're
> managing these systems?!
Generally I update all within a short time after knowing
the first box didn't break. Realistically, I've had exactly
one surprise in the lifetime of Centos when an update fixed
the ifup/down scripts to ignore interfaces if the HWADDR entry
didn't match the hardware MAC address, and I wouldn't have
caught that one with additional testing because it only affected
machines where the disk had been built in one machine and the
IP settings added, then moved to the destination box. So,
any additional effort would have had no benefit. This just
doesn't seem like a big risk considering the QA that has gone
into the code before it reaches the Centos repositories - although
I still wish yum could be told to ignore updates that might have
been added to the repositories since the time of the initial/tested
run. On the other hand, we have more windows boxes to maintain
than Linux and we have had instances where updates affected our apps.
If you have come up with a way to automatically restrain windows
to a known-to-work update level without waiting for service pack
releases, I'd like to know how to do it.
> > I'm not demanding solutions, but if people don't consider
> > the problems there won't ever be any solutions.
>
> Not the solution you explicitly want, as you seem to want to
> consider no others, or their merits for that matter.
I've considered them - and pointed out the flaws.
> > It's a one-line command. How does making it a script
> > help?
>
> First off, you're aruging that 1 command is easy to do on a
> lot of systems. So how difficult is it to make a 1 line
> change to yum.conf? Could you please _stick_ with something,
> instead of just arguing however it may favor your viewpoint
> at any given moment?
It's more difficult than not making it - especially over time
when the disk or whole machine may be shipped to different
locations where the setting will be incorrect. Most are
configured at the main office, then shipped to a colo site
where they run until needed elsewhere or there are hardware
problems.
> Secondly, you're forgetting that you're SSH'ing into systems,
> etc... All those manual steps -- launch the terminal, etc...
> -- for _each_ system.
In some cases that's necessary to control the apps and load
balancer around the update and possible reboot window. In others
it's a one line ssh command from my workstation.
--
Les Mikesell
lesmikesell@xxxxxxxxx
