question about netconf and GSoC

Alexey Tarasov glorgster at gmail.com
Sat Mar 15 14:16:54 UTC 2008


> That's nice to hear. Note that "will be" is not at all sure at this
moment.
> It's just a proposal AFAIK.

think about commenting like just answering to some person, without any
relations to GSoC :)
I'm also not sure, I'll apply GSoC this year.

> = 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.

> 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.

> I don't have a problem with requiring people to use a reasonable new
> kernel. Getting iproute2 to work on an old distribution with a new
> kernel should be no problem.

Old kernels were mentioned to highlight porting issue.

> 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.

>> Other one opportunity - forget about scripts and use C module, which
>> executes system calls. There are not so many network related events, so
one
>> solid network related module may handle all of them by cost of a little
bit
>> harder extensibility.
> And more work. Those script tools already exist, the module still needs
> to be written.

You're right it'll need more work, but many operations like modification of
routing table
and so on may be done by system call. Module with bindings to python may be
more
convenient. But as I understood, such way is against main idea of netconf to
use external
scripts and utilities, so it's better for me that it must not be created.

>> = 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?

>> = 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)

> 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.

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

> I think Martin talked about this sort of thing at FOSDEM.
> What he said was basically that we don't want to hack around bugs.
> I agree with that. (This is related to the iproute2 thing as well.)
> I think it's good to handle events like "go to sleep" and "wake up",
> which can come in response to ACPI events. However, hacking around
> hardware bugs should happen as close to the hardware as possible, which
> (almost?) always means not in netconf.

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.

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

Thanks for your comments.

---
Best regards,
Alexey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/netconf-devel/attachments/20080316/b6172221/attachment.htm 


More information about the netconf-devel mailing list