> That's nice to hear. Note
that "will be" is not at all sure at this moment.<br>> It's just a proposal AFAIK.
<p style="margin-bottom: 0cm;">think about commenting like just
answering to some person, without any relations to GSoC :)<br>I'm also not sure, I'll apply GSoC this
year. <br><br>> = 1 =<br>> I want port netconf to FreeBSD
(cause I like FreeBSD last years more than<br>> Linux). For this
purpose some replacement is needed, cause netconf deeply<br>>
relies on shell scripts, that utilize iproute2.<br><br>> Iproute2
provides an interface to the kernel. AFAIK, this interface is<br>>
not kernel-specific and could in principle be implemented on any
other<br>> system with networking support.</p>
<p style="margin-bottom: 0cm;">netconf uses ip command (and I'm pretty
sure intends to use command similar to tc in future).<br>Such commands are absent in base
FreeBSD (traffic shaping for example usually is implemented in pipes,<br>provided by ipfw). Interface may be exists, but used by netconf
scripts are working with standalone utilities,<br>not with system
calls.<br><br>> If this is correct, then IMO netconf should just
continue to use those<br>> tools. If things can't work on
FreeBSD that way, the bug is with<br>> iproute2 not being available
there, not with netconf using it.</p>
<p style="margin-bottom: 0cm;">Well, bug or not bug, it prevents from
direct and easy porting.<br><br>> I don't have a problem with
requiring people to use a reasonable new<br>> kernel. Getting
iproute2 to work on an old distribution with a new<br>> kernel
should be no problem.</p>
<p style="margin-bottom: 0cm;">Old kernels were mentioned to highlight
porting issue.<br><br>> I don't know enough about the internals to
comment much on this. In<br>> principle, passing events instead of
scripts sounds good to me, but<br>> doing different things on
different platforms should be avoided whenever<br>> possible IMO.</p>
<p style="margin-bottom: 0cm;">Hiding real script name must help to
make everything in uniform way on every platform.<br><br>>>
Other one opportunity - forget about scripts and use C module,
which<br>>> executes system calls. There are not so many
network related events, so one<br>>> solid network related
module may handle all of them by cost of a little bit<br>>>
harder extensibility.<br>> And more work. Those script tools
already exist, the module still needs<br>> to be written.</p>
<p style="margin-bottom: 0cm;">You're right it'll need more work, but
many operations like modification of routing table<br>and so on may be
done by system call. Module with bindings to python may be more<br>convenient. But as I understood, such way is against main idea of
netconf to use external<br>scripts and utilities, so it's better for me
that it must not be created.<br><br>>> = 4 =<br>> IMO
the policy should be very flexible, but very simple. That means<br>>
something like you propose would be one option, but there should also
be<br>> a way to use user-provided scripts to decide what is
allowed.</p>
<p style="margin-bottom: 0cm;">You mean tool for user-friendly
generation of security policy configuration file?<br><br>>> = 5
=<br>> This is conceptually a hard problem. It would be nice if
the plugins<br>> don't need to know about each other's existance,
so you would need to<br>> use the list approach. However,
sometimes a plugin may want to say "I<br>> can handle this,
but it won't be optimal". Should it fail or not?<br>In other
message I've suggested "priority". Decision to use module is done<br>by event dispatcher, which may operate
priority to choose correct module.<br>(there is problem still how priority
and optimality are related :), but if priority<br>is set in configuration file, then user
knows which is better)</p>
<p style="margin-bottom: 0cm;">> Perhaps it would be best to
always ask all plugins and let them say how<br>> good they can
handle it. Filter those numbers through some<br>> user-provided
filter (default: don't change), and the highest scoring<br>>
plugin will actually handle the event.</p>
<p style="margin-bottom: 0cm;">Scores are not good, cause author of
one module may show you 10, author of other module 155.<br>But in fact they are same but in
different author's scales.</p>
<p style="margin-bottom: 0cm;">Better to use predefined categories
(MODULE_CAN, MODULE_CANNOT,<br>MODULE_DONTWANTBUTCAN) or somewhat
similar. <br><br>> I think Martin talked about this sort of thing
at FOSDEM.<br>> What he said was basically that we
don't want to hack around bugs.<br>> I agree with that. (This is
related to the iproute2 thing as well.)<br>> I think it's good to handle events
like "go to sleep" and "wake up",<br>> which
can come in response to ACPI events. However, hacking around<br>>
hardware bugs should happen as close to the hardware as possible,
which<br>> (almost?) always means not in netconf.</p>
<p style="margin-bottom: 0cm;">Look to example:<br>1. user configured ppp interface, init
configured eth0 statically and eth1 via DHCP. So, three different
configuration events.<br>2. user made computer sleep.
</p>
<p style="margin-bottom: 0cm;">To go to sleep acpi related script must
know all about configured interfaces and configuration types<br>to use
control socket. That is – as I think – is not good. But if
related script uses control socket only<br>to send event like "store
state" and on wakeup - "restore state", there is no such
problem with need<br>in very clever script. <br><br>Handling issues
with acpi related and unrelated kernel module hang ups, of course is
not problem of netconf.<br><br>Thanks for your comments.<br></p>
<p style="margin-bottom: 0cm;">---<br>Best regards,<br>Alexey</p>