7:33 p.m.
Hi,
I'm just working on getting netcf integrated into Gentoo. See also:
http://bugs.gentoo.org/show_bug.cgi?id=295993
But I have some basic questions first.
I have installed netcf and put the netcf.aug into
/usr/share/augeas/lenses/netcf.aug.
Is it correct to put the aug file into this directory or should it remain in
the default installation path (/usr/share/netcf/lenses).
I've never used an Augeas based tool before, sorry for this question ;-)
Is or should ncftool/netcf be able to read existing interfaces?
So I could just use it on top of another network configuration.
e.g.:
- Gentoo's Initsystem creates + configures interfaces
- netcf provides read-only information about them to further services like
libvirt
Don't worry, my plan is to integrate it fully into Gentoo, but depending on it
completely makes it hard establishing it in existing environments, so this
read-existing-interfaces capability would be quite interesting, I just don't
know whether this is already possible as 'ncftool list' displays nothing here
without providing an XML based definition.
Thank you!
Regards,
Elias P.
11:44 a.m.
On 12/06/2009 08:33 PM, elias wrote:
Hi,
I'm just working on getting netcf integrated into Gentoo. See also:
http://bugs.gentoo.org/show_bug.cgi?id=295993
But I have some basic questions first.
I have installed netcf and put the netcf.aug into
/usr/share/augeas/lenses/netcf.aug.
Is it correct to put the aug file into this directory or should it remain in
the default installation path (/usr/share/netcf/lenses).
I've never used an Augeas based tool before, sorry for this question ;-)
Is or should ncftool/netcf be able to read existing interfaces?
So I could just use it on top of another network configuration.
e.g.:
- Gentoo's Initsystem creates + configures interfaces
- netcf provides read-only information about them to further services like
libvirt
Don't worry, my plan is to integrate it fully into Gentoo, but depending on it
completely makes it hard establishing it in existing environments, so this
read-existing-interfaces capability would be quite interesting, I just don't
know whether this is already possible as 'ncftool list' displays nothing here
without providing an XML based definition.
netcf is expected to read existing interfaces. For example, Fedora's
installer will set up interface config files in
/etc/sysconfig/network-scripts, and netcf knows how to parse these and
exposes the interface list through its API (and ncftool). If the user
creates a config for a bridge interface and drops it in /etc/..., netcf
will see that as well.
Unless Gentoo is using the same initscripts as Fedora, netcf will need
to be taught how to understand Gentoo network configuration. David sent
an email recently describing how the existing code works and how to go
about expanding it:
https://fedorahosted.org/pipermail/netcf-devel/2009-December/000382.html
- Cole
5:28 p.m.
netcf is expected to read existing interfaces. For example,
Fedora's
installer will set up interface config files in
/etc/sysconfig/network-scripts, and netcf knows how to parse these and
exposes the interface list through its API (and ncftool). If the user
creates a config for a bridge interface and drops it in /etc/..., netcf
will see that as well.
I was referring to reading existing interfaces directly from
the system, as an
interface might even be changed/created by another 3rd party tool like
OpenVPN.
OpenVPN might be one of the more harmless scenarios here as it usually just
adds/removes an TUN/TAP interface, but there are a plenty of 3rd party tools
out there in the wild which do way more changes.
I think it would be really important to be able to rely not only on the static
interface configuration, as this would limit the usage scope of netcf IMHO
quite too much.
Unless Gentoo is using the same initscripts as Fedora, netcf will
need
to be taught how to understand Gentoo network configuration.
Ok, this part was
already clear to me. Due to Gentoo's modularity, there are
multiple ways for the network configuration, but I think the most future proof
and widespread would be OpenRC which was faced with a lot of discussions
because of some radical changes to the network configuration layer.
As far as I understood netcf now, it doesn't replace a distribution's
configuration mechanism, but builds another layer on top of it.
Wouldn't it be possible to use netcf as a complete replacement?
My idea was to get optional support for netcf directly into OpenRC (and later
probably other initsystems).
So the initsystem would directly control networking interfaces through netcf
without another layer of configuration files - the configuration would be done
directly through netcf/XML files.
This would:
- simplify network configuration
- provide optional support in OpenRC as replacement for the basic 'ifconfig'-
style cross-platform support which was recently introduced and caused a lot of
discussions as a lot of people liked the previous config style way more
- create a de-facto standard for network configurations in initsystems
Is netcf's architecture ready for using it like this? Can it be decoupled from
parsing config files through Augeas and using it just directly?
So all this narrows done to this basic questions:
- Is netcf able to read the current live configuration of devices outside of
the configuration files (through /sys or other mechanisms)?
- Can netcf be decoupled from Augeas and work just on its own?
- Are there any interests in getting netcf into this direction + do you think
it would make sense?
Regards, Elias P.
6:50 p.m.
On Tue, 2009-12-08 at 00:28 +0100, elias wrote:
> netcf is expected to read existing interfaces. For example,
Fedora's
> installer will set up interface config files in
> /etc/sysconfig/network-scripts, and netcf knows how to parse these and
> exposes the interface list through its API (and ncftool). If the user
> creates a config for a bridge interface and drops it in /etc/..., netcf
> will see that as well.
I was referring to reading existing interfaces directly from the system, as an
interface might even be changed/created by another 3rd party tool like
OpenVPN.
OpenVPN might be one of the more harmless scenarios here as it usually just
adds/removes an TUN/TAP interface, but there are a plenty of 3rd party tools
out there in the wild which do way more changes.
I think it would be really important to be able to rely not only on the static
interface configuration, as this would limit the usage scope of netcf IMHO
quite too much.
Initially, netcf was strictly meant as a tool to munge interface
configuration via ncf_define and ncf_if_xml_desc. Laine added support
for querying 'live' config (i.e., properties of interfaces as they are
running, rather than what's in configuration files) with
ncf_if_xml_state. That works reasonably well, though there's probably
some room for improvement for more esoteric setups.
As far as I understood netcf now, it doesn't replace a
distribution's
configuration mechanism, but builds another layer on top of it.
Wouldn't it be possible to use netcf as a complete replacement?
Since this would be a _huge_ change in any distro, I don't think that
that's realistic - at least for Fedora/RHEL, there are a ton of tools
and lots of knowledge built around the current config format. Netcf
gives you an alternate route to handling those, and because it's
bidirectional, the integration is seamless, in that you can either use
your existing tools or netcf.
So the initsystem would directly control networking interfaces
through netcf
without another layer of configuration files - the configuration would be done
directly through netcf/XML files.
This would:
- simplify network configuration
- provide optional support in OpenRC as replacement for the basic 'ifconfig'-
style cross-platform support which was recently introduced and caused a lot of
discussions as a lot of people liked the previous config style way more
- create a de-facto standard for network configurations in initsystems
Is netcf's architecture ready for using it like this? Can it be decoupled from
parsing config files through Augeas and using it just directly?
It's not really what netcf was meant to be, nad to be honest, I think
the chances of success for such an approach are quite slim.
So all this narrows done to this basic questions:
- Is netcf able to read the current live configuration of devices outside of
the configuration files (through /sys or other mechanisms)?
Some of it - see ncf_if_xml_state.
- Can netcf be decoupled from Augeas and work just on its own?
There's no hard requirement to write any driver using Augeas; for
Fedora/RHEL, there isn't much point in doing this split.
- Are there any interests in getting netcf into this direction + do
you think
it would make sense?
I think it's a gigatic undertaking, with very slim chances of success -
replacing tried and true config mechanisms is a huge battle, and
generally not worth the effort.
David
9:54 a.m.
On 12/09/2009 07:50 PM, David Lutterkort wrote:
On Tue, 2009-12-08 at 00:28 +0100, elias wrote:
>> netcf is expected to read existing interfaces. For example, Fedora's
>> installer will set up interface config files in
>> /etc/sysconfig/network-scripts, and netcf knows how to parse these and
>> exposes the interface list through its API (and ncftool). If the user
>> creates a config for a bridge interface and drops it in /etc/..., netcf
>> will see that as well.
>>
> I was referring to reading existing interfaces directly from the system, as an
> interface might even be changed/created by another 3rd party tool like
> OpenVPN.
> OpenVPN might be one of the more harmless scenarios here as it usually just
> adds/removes an TUN/TAP interface, but there are a plenty of 3rd party tools
> out there in the wild which do way more changes.
> I think it would be really important to be able to rely not only on the static
> interface configuration, as this would limit the usage scope of netcf IMHO
> quite too much.
>
Initially, netcf was strictly meant as a tool to munge interface
configuration via ncf_define and ncf_if_xml_desc. Laine added support
for querying 'live' config (i.e., properties of interfaces as they are
running, rather than what's in configuration files) with
ncf_if_xml_state. That works reasonably well, though there's probably
some room for improvement for more esoteric setups.
Note that ncf_if_xml_state will only return current state info about
interfaces that are described in the config, so it's not exactly what
you're looking for. At least one other person has suggested it would be
useful for netcf to return info on transient interfaces, though.
1:04 p.m.
On Thu, 2009-12-10 at 10:54 -0500, Laine Stump wrote:
Note that ncf_if_xml_state will only return current state info about
interfaces that are described in the config, so it's not exactly what
you're looking for. At least one other person has suggested it would be
useful for netcf to return info on transient interfaces, though.
I certainly would welcome any patches that go into that direction.
David
12:08 p.m.
Hi Elias,
On Mon, 2009-12-07 at 02:33 +0100, elias wrote:
I'm just working on getting netcf integrated into Gentoo. See
also:
http://bugs.gentoo.org/show_bug.cgi?id=295993
Excellent - that would be a great addition.
But I have some basic questions first.
I have installed netcf and put the netcf.aug into
/usr/share/augeas/lenses/netcf.aug.
Is it correct to put the aug file into this directory or should it remain in
the default installation path (/usr/share/netcf/lenses).
It doesn't really matter ;) netcf tells augeas to also look for files
in /usr/share/netcf/lenses, besides augeas' standard load path
of /usr/share/augeas/lenses:/usr/share/augeas/lenses/dist
Is or should ncftool/netcf be able to read existing interfaces?
Absolutely; to expand on what Cole said, netcf has to be able to cope
with arbitrary changes to the network config files between different
netcf runs. We want to make sure that people's wonderful + crazy
homegrown scripts to fiddle with their network config work, and the use
of netcf is completely transparent to them.
David
5252
days inactive
5255
days old
netcf-devel@lists.fedorahosted.org
6 comments
4 participants
participants (4)
-
Cole Robinson -
David Lutterkort -
elias -
Laine Stump