question about netconf and GSoC

[Bas Wijnen]

On Sun, Mar 16, 2008 at 12:16:54AM +1000, Alexey Tarasov wrote:
> > = 1 =
> > I want port netconf to FreeBSD (cause I like FreeBSD last years more than
> > Linux). For this purpose some replacement is needed, cause netconf deeply
> > relies on shell scripts, that utilize iproute2.
> 
> > Iproute2 provides an interface to the kernel. AFAIK, this interface is
> > not kernel-specific and could in principle be implemented on any other
> > system with networking support.
> 
> netconf uses ip command (and I'm pretty sure intends to use command
> similar to tc in future).  Such commands are absent in base FreeBSD
> (traffic shaping for example usually is implemented in pipes, provided
> by ipfw). Interface may be exists, but used by netconf scripts are
> working with standalone utilities, not with system calls.

The interface I was talking about is the arguments that ip and tc (and
maybe other utilities) accept.  In this case, for porting, I find it
acceptable to port those tools instead of netconf, and let netconf use
those ported tools on freebsd.

> > If this is correct, then IMO netconf should just continue to use those
> > tools. If things can't work on FreeBSD that way, the bug is with
> > iproute2 not being available there, not with netconf using it.
> 
> Well, bug or not bug, it prevents from direct and easy porting.

A problem with porting is always a bug in Debian's terminology, only it
may be severity wishlist. ;-)  The point I was making is that the fact
that a tool doesn't exist on some platforms is no reason not to use it
IMO.  It does make porting harder, but that's the problem of people
maintaining that platform.  If they don't have all the tools, they
shouldn't expect to be able to use anything just like that.  I would
not have a problem with reimplementing or porting some utilities if I
would want to port something using them to a GNU/Linux system.

> > I don't know enough about the internals to comment much on this. In
> > principle, passing events instead of scripts sounds good to me, but
> > doing different things on different platforms should be avoided
> > whenever possible IMO.
> 
> Hiding real script name must help to make everything in uniform way on
> every platform.

I think using different scripts on different platforms is not a good
thing.  It means more code, probably lots of duplicate code, with
duplicate bugs, much of which will be untested, etc.

> >> = 4 =
> > IMO the policy should be very flexible, but very simple. That means
> > something like you propose would be one option, but there should also be
> > a way to use user-provided scripts to decide what is allowed.
> 
> You mean tool for user-friendly generation of security policy configuration
> file?

No, I mean the user may have very complex security (or other) policy
wishes, which she chooses to write in the form of a script.  Netconf
should be able to call such a script to ask what it should do.  This is
the most configurable policy.  Simple acls are much less configurable,
but often good enough.  So that should probably be possible as well.

> >> = 5 =
> > This is conceptually a hard problem. It would be nice if the plugins
> > don't need to know about each other's existance, so you would need to
> > use the list approach. However, sometimes a plugin may want to say "I
> > can handle this, but it won't be optimal". Should it fail or not?
>
> In other message I've suggested "priority". Decision to use module is
> done by event dispatcher, which may operate priority to choose correct
> module.  (there is problem still how priority and optimality are
> related :), but if priority is set in configuration file, then user
> knows which is better)

Yes, this is the filter I was proposing.  This, combined with a
module-provided score, gives more flexibility.

> > Perhaps it would be best to always ask all plugins and let them say how
> > good they can handle it. Filter those numbers through some
> > user-provided filter (default: don't change), and the highest scoring
> > plugin will actually handle the event.
> 
> Scores are not good, cause author of one module may show you 10,
> author of other module 155.
> But in fact they are same but in different author's scales.

Only if you don't define the scale.  When using scores, it is of course
important to define something like "1000 means this module thinks it's
probably the best one to handle this, 0 means it cannot handle it" and
perhaps even some intermediate values like "I can handle this, but it's
not optimal".

> Better to use predefined categories (MODULE_CAN, MODULE_CANNOT,
> MODULE_DONTWANTBUTCAN) or somewhat similar.

Those can map to some defined scores (1000, 0, 100).  Using scores gives
the module the opportunity to say "a bit more than that".

> Look to example:
> 1. user configured ppp interface, init configured eth0 statically and eth1
> via DHCP. So, three different configuration events.
> 2. user made computer sleep.
> 
> To go to sleep acpi related script must know all about configured interfaces
> and configuration types to use control socket. That is – as I think –
> is not good. But if related script uses control socket only to send
> event like "store state" and on wakeup - "restore state", there is no
> such problem with need in very clever script.

I think a "save state" and a "restore state" command would be very
useful in general.  Netconf should anyway be able to determine the
current system state, so saving it should not be very hard.  Restoring
it might be a bigger problem, but it would certainly be useful.

> Handling issues with acpi related and unrelated kernel module hang
> ups, of course is not problem of netconf.

Indeed, that's what I was saying. :-)

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/netconf-devel/attachments/20080315/65b4aef8/attachment-0001.pgp