FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 11-25-2010, 03:24 PM
Olaf Kirch
 
Default Introducing wicked

Presenting wicked network configuration
=======================================

This is the first public release of wicked, an experimental framework
for network configuration.

You may ask, don't we have enough of those already? Don't we have
NetworkManager, connman, netcf, and a few more?

The point I started from was the desire to unify what is usually provided
through the traditional ifup script kudzu, with some of the more desktop
oriented services provided by facilities like NetworkManager. I also
wanted to move towards a more powerful set of functionality written in
C, which is able to subsume functionality provided by ifconfig, ip(8),
brctl, vconfig, ethtool, etc, and be able to drive these through an
extensible XML representation of the network configuration.

Kind of the Grand Unified Theory of network configuration :-)

Right now, this implementation uses a daemon service and a command
line utility. These two communicate securely via a local UNIX socket,
allowing the server to validate the client's user id.

The server offers a REST interface to various aspects of network
configuration. The client application uses REST calls to retrieve
interface configuration and status, or to reconfigure interfaces.
The path space used by the API can be extended to cover other aspects
of network configuration as well, such as reading, writing and restoring
the resolv.conf file.

After having hacked on this for a while, I want to release this to
the community for feedback.

If you're interested in finding out more, you will find a README
and several manpages in the source code, which is available from
http://gitorious.org/wicked

Regards,
Olaf Kirch <okir@suse.de>

--
Neo didn't bring down the Matrix. SOA did. (soafacts.com)
--------------------------------------------
Olaf Kirch - Director Server (okir@novell.com)
SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-25-2010, 07:29 PM
"Richard W.M. Jones"
 
Default Introducing wicked

On Thu, Nov 25, 2010 at 05:24:37PM +0100, Olaf Kirch wrote:
> You may ask, don't we have enough of those already? Don't we have
> NetworkManager, connman, netcf, and a few more?

Indeed ... You don't explain how it's better than netcf.

I notice a lot of hand-written C config file parsing in your code.
netcf uses augeas which is a much sounder basis for making changes to
config files.

http://augeas.net/
https://fedorahosted.org/netcf/

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-25-2010, 09:01 PM
Pete Zaitcev
 
Default Introducing wicked

On Thu, 25 Nov 2010 20:29:30 +0000
"Richard W.M. Jones" <rjones@redhat.com> wrote:
> On Thu, Nov 25, 2010 at 05:24:37PM +0100, Olaf Kirch wrote:

> > You may ask, don't we have enough of those already? Don't we have
> > NetworkManager, connman, netcf, and a few more?
>
> Indeed ... You don't explain how it's better than netcf.

Or NM for that matter. There is nothing "desktop-oriented" about NM
beyond the history when it was introduced to solve issues that
originated on desktop. But its technical design is no different
from what you are offering. Thus the case for replacement is not made.

-- Pete
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-25-2010, 09:17 PM
nodata
 
Default Introducing wicked

On 25/11/10 17:24, Olaf Kirch wrote:
>
> Presenting wicked network configuration
> =======================================
>
> This is the first public release of wicked, an experimental framework
> for network configuration.
>
> You may ask, don't we have enough of those already? Don't we have
> NetworkManager, connman, netcf, and a few more?
>
> The point I started from was the desire to unify what is usually provided
> through the traditional ifup script kudzu, with some of the more desktop
> oriented services provided by facilities like NetworkManager. I also
> wanted to move towards a more powerful set of functionality written in
> C, which is able to subsume functionality provided by ifconfig, ip(8),
> brctl, vconfig, ethtool, etc, and be able to drive these through an
> extensible XML representation of the network configuration.

XML? *cries*

How about a nice simple file?

>
> Kind of the Grand Unified Theory of network configuration :-)
>
> Right now, this implementation uses a daemon service and a command
> line utility. These two communicate securely via a local UNIX socket,
> allowing the server to validate the client's user id.
>
> The server offers a REST interface to various aspects of network
> configuration. The client application uses REST calls to retrieve
> interface configuration and status, or to reconfigure interfaces.
> The path space used by the API can be extended to cover other aspects
> of network configuration as well, such as reading, writing and restoring
> the resolv.conf file.
>
> After having hacked on this for a while, I want to release this to
> the community for feedback.
>
> If you're interested in finding out more, you will find a README
> and several manpages in the source code, which is available from
> http://gitorious.org/wicked
>
> Regards,
> Olaf Kirch<okir@suse.de>
>

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-25-2010, 09:42 PM
Chris Jones
 
Default Introducing wicked

On Thu, 2010-11-25 at 17:24 +0100, Olaf Kirch wrote:
> Presenting wicked network configuration
> =======================================
>
> This is the first public release of wicked, an experimental framework
> for network configuration.
>
> You may ask, don't we have enough of those already? Don't we have
> NetworkManager, connman, netcf, and a few more?
>
> The point I started from was the desire to unify what is usually provided
> through the traditional ifup script kudzu, with some of the more desktop
> oriented services provided by facilities like NetworkManager. I also
> wanted to move towards a more powerful set of functionality written in
> C, which is able to subsume functionality provided by ifconfig, ip(8),
> brctl, vconfig, ethtool, etc, and be able to drive these through an
> extensible XML representation of the network configuration.
>
> Kind of the Grand Unified Theory of network configuration :-)
>
> Right now, this implementation uses a daemon service and a command
> line utility. These two communicate securely via a local UNIX socket,
> allowing the server to validate the client's user id.
>
> The server offers a REST interface to various aspects of network
> configuration. The client application uses REST calls to retrieve
> interface configuration and status, or to reconfigure interfaces.
> The path space used by the API can be extended to cover other aspects
> of network configuration as well, such as reading, writing and restoring
> the resolv.conf file.
>
> After having hacked on this for a while, I want to release this to
> the community for feedback.
>
> If you're interested in finding out more, you will find a README
> and several manpages in the source code, which is available from
> http://gitorious.org/wicked
>


I'm going to be a little more positive with my comments for Olaf.

The way I read his original post, is he is simply providing an
alternative in addition to what we already have.
I certainly didn't ready it as a replacement proposal.

Good work Olaf. Keep up the good work.

For future reference, we need to encourage these sorts of development
projects. It's great for both Fedora and Linux.

Regards


--
Chris Jones

PHOTO RESOLUTIONS - Photo - Graphic - Web
ABN: 98 317 740 240
@: chrisjones@comcen.com.au
WWW: http://photoresolutions.freehostia.com

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-25-2010, 10:09 PM
Richard Zidlicky
 
Default Introducing wicked

On Thu, Nov 25, 2010 at 11:17:48PM +0100, nodata wrote:
> On 25/11/10 17:24, Olaf Kirch wrote:
> >
> > Presenting wicked network configuration
> > =======================================
> >
> > This is the first public release of wicked, an experimental framework
> > for network configuration.
> >
> > You may ask, don't we have enough of those already? Don't we have
> > NetworkManager, connman, netcf, and a few more?

making a list of those is already an achievement

> > The point I started from was the desire to unify what is usually provided
> > through the traditional ifup script kudzu, with some of the more desktop
> > oriented services provided by facilities like NetworkManager. I also
> > wanted to move towards a more powerful set of functionality written in
> > C, which is able to subsume functionality provided by ifconfig, ip(8),
> > brctl, vconfig, ethtool, etc, and be able to drive these through an
> > extensible XML representation of the network configuration.
>
> XML? *cries*
>
> How about a nice simple file?

seconded. Or JSON if something fancy is desperately needed.

Richard
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-26-2010, 08:24 AM
Olaf Kirch
 
Default Introducing wicked

On Thursday 25 November 2010 21:29:30 Richard W.M. Jones wrote:
> On Thu, Nov 25, 2010 at 05:24:37PM +0100, Olaf Kirch wrote:
> > You may ask, don't we have enough of those already? Don't we have
> > NetworkManager, connman, netcf, and a few more?
>
> Indeed ... You don't explain how it's better than netcf.

That's because I'm not a huge fan of introducing my code by dissing other
people's projects :-)

Okay, so here's where I see the significant differences

netcf, from what I have seen so far, converts between sysconfig files
and XML using a combination of augeas and XSLT. To bring up and shut
down interfaces, it continues to rely on ifup/ifdown scripts. Is that
an accurate description?

This has a number of problems, I believe


1. ifcfg files are dead

First and foremost, ifup/ifdown and the shell scripts that do the dirty
work in the background do not scale very well, and I believe as an
architecture they've reached their best before date. It gets increasingly
hard to represent complex topologies in sysconfig files. Setups like bridges
on top of bonding devices on top of VLANs tend to result in rather messy
ifcfg files to begin with - and I would guess that was one of the main
motivations for creating netcf, and representing network configuration using
a hierarchical, extensible syntax such as XML.

I think we need to take this a step further, though. Converting the structured
configuration data (be it XML or something else, I couldn't care less) to
ifcfg files and then invoke the same old messy ifup is not going to work. It's
a convenience to those people writing configuration front-ends, but it doesn't
do anything to make things work better.

Thus, I believe we need to take out the ifcfg format in the long run, and take
the structured configuration data all the way to the actual system calls that
set up the interface. And that is what wicked does. At the system end of
things, wicked doesn't call ip or route or ethtool or vconfig; for all its
configuration requirements it talks to the kernel directly.

The only concession wicked makes to the "old school" ifcfg files is that
it still supports them as one choice of where configuration data can be kept.
That's because we have system management tools that mess with these files
today, and you probably can't rewrite these all at once. But wicked doesn't
*require* ifcfg files. You can easily configure it to store all network
configuration in XML files (or any other structured format), and it will
just continue to work.

(BTW if you look into the source code, you'll find a file named netcf.c
which tries to provide a shim layer that translates netcf API calls to
wicked's REST API - more of a case study than a complete shim though :-)


2. Why a daemon, not a library

The first reason to do this is pretty simple; hotplugging. Traditional ifup
doesn't handle this at all; you need to rely on separate services like
ifplugd or NetworkManager.

But it actually goes beyond that. You may actually want to do more things
in response to network events than just hotplug an interface. It can be
simple things like, starting a dhcp6 client when we see a Managed/Other flag
in a router advertisement.

Or consider the usual fun to be had when you need to juggle the information
obtained from DHCP running on several interfaces. You get DNS information
from two DHCP servers and maybe on PPP uplink - does one of them take
precedence? Or should you merge them? What do you restore when one interface
goes down? How does that relate to information obtained from iBFT? Try to
handle that in shell code, and you'll need a lot of aspirin. (To be honest
here; wicked cannot do all of that yet, but it is getting close).

So, what I wanted to create with wicked was a network configuration facility
that allows to integrate different aspects more closely than what is
possible if things live in lots of different applications that were never
designed to interact very closely.



3. Why not NetworkManager?

On the other hand, there's NetworkManager (and I'm getting to this point
because Pete Zaitcev brought this up). Right now, NetworkManager doesn't
handle bridges, bonds, infiniband, token ring - that's why I say it's a bit
desktopish, the server environment simply has never been the focus of
NetworkManager's development. Also, it links against a somewhat longish lists
of fairly heavy-weight libraries (including nspr), and requires dbus - all of
which make it pretty much impossible to use in initrd or an environment where
space is a premium.


Olaf
--
Neo didn't bring down the Matrix. SOA did. (soafacts.com)
--------------------------------------------
Olaf Kirch - Director Server (okir@novell.com)
SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-26-2010, 08:02 PM
Jon Masters
 
Default Introducing wicked

Hi Olaf,

Thanks for posting about your project.

On Fri, 2010-11-26 at 10:24 +0100, Olaf Kirch wrote:

> 1. ifcfg files are dead

Ok. But I think we want to be very careful with this. Yes, it's nice to
use structured data formats but IMO we want to make sure sysadmins can
still edit files by hand without using any kind of Linux Registry to do
it (g/dconf/etc). So if you're just proposing making the format have
some kind of structured standard, ok, but please don't go too far

I'll use something I can work around, but the main reason I turn off
NetworkManager on servers is that (historically) I just want a config
file that says "use these settings" that I know will work, is simple,
and well understood, and always behaves the same way on every boot. If
there's a lot more complexity, it'll be hard to sell to sysadmins.

> 3. Why not NetworkManager?
>
> On the other hand, there's NetworkManager (and I'm getting to this point
> because Pete Zaitcev brought this up). Right now, NetworkManager doesn't
> handle bridges, bonds, infiniband, token ring - that's why I say it's a bit
> desktopish, the server environment simply has never been the focus of
> NetworkManager's development. Also, it links against a somewhat longish lists
> of fairly heavy-weight libraries (including nspr), and requires dbus - all of
> which make it pretty much impossible to use in initrd or an environment where
> space is a premium.

Good points, and I don't love NetworkManager on the server today (I do
use various bridging, etc.) but I think we're getting to the point soon
where NM might start to do some of these things nicely. So I think it's
worth being cautious not to have two solutions that half solve the
problem than one solution that is adequate enough for most folks.

Jon.


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-26-2010, 09:21 PM
"Richard W.M. Jones"
 
Default Introducing wicked

On Fri, Nov 26, 2010 at 04:02:28PM -0500, Jon Masters wrote:
> Hi Olaf,
>
> Thanks for posting about your project.
>
> On Fri, 2010-11-26 at 10:24 +0100, Olaf Kirch wrote:
>
> > 1. ifcfg files are dead
>
> Ok. But I think we want to be very careful with this. Yes, it's nice to
> use structured data formats but IMO we want to make sure sysadmins can
> still edit files by hand without using any kind of Linux Registry to do
> it (g/dconf/etc). So if you're just proposing making the format have
> some kind of structured standard, ok, but please don't go too far

.. and remember that Augeas solves the problem of having traditional
config files that can be edited in a structured way, including
preserving all the comments and whitespace and everything else.

# augtool match '//files/etc/ntp.conf/server[*]'
/files/etc/ntp.conf/server[1] = 0.fedora.pool.ntp.org
/files/etc/ntp.conf/server[2] = 1.fedora.pool.ntp.org
/files/etc/ntp.conf/server[3] = 2.fedora.pool.ntp.org
/files/etc/ntp.conf/server[4] = 3.fedora.pool.ntp.org
# augtool <<EOF
> set '//files/etc/ntp.conf/server[1]' ntp.annexia.org
> save
> EOF
Saved 1 file(s)
# augtool match '//files/etc/ntp.conf/server[*]'
/files/etc/ntp.conf/server[1] = ntp.annexia.org
/files/etc/ntp.conf/server[2] = 1.fedora.pool.ntp.org
/files/etc/ntp.conf/server[3] = 2.fedora.pool.ntp.org
/files/etc/ntp.conf/server[4] = 3.fedora.pool.ntp.org

[ then look at /etc/ntp.conf to verify that all comments and
formatting are preserved ]

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://et.redhat.com/~rjones/libguestfs/
See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-26-2010, 11:49 PM
Pete Zaitcev
 
Default Introducing wicked

On Fri, 26 Nov 2010 10:24:34 +0100
Olaf Kirch <okir@suse.de> wrote:

> 3. Why not NetworkManager?
>
> On the other hand, there's NetworkManager (and I'm getting to this point
> because Pete Zaitcev brought this up). Right now, NetworkManager doesn't
> handle bridges, bonds, infiniband, token ring - that's why I say it's a bit
> desktopish, the server environment simply has never been the focus of
> NetworkManager's development. Also, it links against a somewhat longish lists
> of fairly heavy-weight libraries (including nspr), and requires dbus - all of
> which make it pretty much impossible to use in initrd or an environment where
> space is a premium.

Thanks, I see. Not sure I agree entirely though, but duly noted.

-- Pete
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 08:11 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org