COM/CORBA/DCOP (was: Hello people. I have some questions)

Alex Martelli aleax at aleax.it
Tue Sep 4 06:06:14 EDT 2001


"Erno Kuusela" <erno-news at erno.iki.fi> wrote in message
news:kusne3hcry.fsf at lasipalatsi.fi...
> In article <9mvp3505rt at enews2.newsguy.com>, "Alex Martelli"
> <aleax at aleax.it> writes:
>
> | But, boy, the *joys* of ipf and ipnat
> | versus IPTables (and let's not even mention ipchains,
> | ipfwadm, etc, nor, of course, the utter lack of any such
> | indispensable tools as part of Win32 protocol stacks!-)...
>
> "joy" and "nat" in the same sentence? ugh!

With ipf/ipnat, the oxymoron of joyful nat'ting
magically became possible:-).


> btw, ipf is not in openbsd any more
> (http://www.monkey.org/openbsd/archive/tech/0105/msg00266.html).
> i hope they come up with a good replacement.

Looks like they are (http://www.benzedrine.cx/pf.html) -- I'll
quietly stay with 2.9-stable until the new pf is mature enough,
then uneventfully switch to it -- looks pretty compatible.
(Despite some early musings, it doesn't seem they're going to
provide for "userland" controllers, so I doubt I'll be able to
use Python to _control_ the filtering/natting directly -- oh
well, I'll live:-).


>    -- erno, still using ipfwadm on linux 2.4

Funny, the only serious reason I can see to upgrade to 2.4.?
(despite its dubious stability) is IPTables (it ain't ipfilter,
but it does seem usable) -- well, unless you need to support
some specific HW added in 2.4 wrt 2.2, I guess:-).  That was
one reason I started investigating OpenBSD -- ensuring I could
decide to stay with a 2.2 kernel on the Linux boxes while not
hampering my filtering/natting/firewalling abilities.

Python's potential roles in a router/firewall/proxy box
scenario still deserve exploration, IMHO -- not in the core
inner loop where each packet is looked at, sure (there, I
see that even a context switch from kernel to user mode
could be detrimental, for a low-end-enough box dealing
with a busy-enough set of networks), but at higher, kind
of policy/strategical decisions.  I'm (vaguely!-) thinking
of the "dynamic firewalling" article on the IBM site and
of how some of that stuff might be automated, or at least
made much more palatable with a Python front-end to it.

Of course, I'm not running any X (or other GUI-able stuff)
on the router/fw/proxy box -- so it would have to be either
curses (which I think I've entirely forgotten and would
have to study anew!), or some X-client subset and another
box on the LAN to provide the front-end -- but I worry about
the security status of any out-of-box hookup: remember the
scenario is that of a network currently under active and
dangerous attack -- I'm no security expert, but surely I
want to run *as little as possible* on the security-core
box, and *nothing if possible* that depends on the network
for security-crucial functions...?  "The pieces that aren't
there are those you know won't break", etc, etc".


Alex






More information about the Python-list mailing list