Support for bonding and other advanced networking topics

[Michael DeHaan]

Just recently on IRC (join #cobbler on irc.freenode.net if you aren't 
there already) we were discussing whether we could use Cobbler's concept 
of interfaces to describe more complicated setups and then use a Cobbler 
snippet called in %post to set everything up.

We initially were thinking we could describe an interface like this:

cobbler system edit --name=foo --interface=1 --bond-group=asdf 
--bond-opts="a=1 b=2 ..." --bond-alias="..."
cobbler system edit --name=foo --interface=2 --bond-group=asdf 
--bond-opts="a=2 b=3 ..." --bond-alias="..."

And the %post section snippet (this would be new) would insure that the 
order of NICs booted is the same as those installed and everything is 
configured.   This would also set up things that Anaconda could not set up.

In the above example, eth1 and eth2 would be bonded as "asdf".

In the above proposal, I'd be willing to add the bits to Cobbler to 
store the above kind of data, though I'd like for someone with more 
networking skills to write the network configuration snippet.

We also talked a bit about IP "aliases" / VIPs and bridging.   I will 
admit at this point that networking is /not/ my area, so what are 
everyone's thoughts to the implementation of the above?  

What fields do we need to store to make this all possible to be defined 
at provisioning time and "just work"?

--Michael

[Jasper Capel]

Michael DeHaan wrote:
>  Just recently on IRC (join #cobbler on irc.freenode.net if you
> aren't 
>  there already) we were discussing whether we could use Cobbler's concept 
>  of interfaces to describe more complicated setups and then use a Cobbler 
>  snippet called in %post to set everything up.
>  
>  We initially were thinking we could describe an interface like this:
>  
>  cobbler system edit --name=foo --interface=1 --bond-group=asdf 
>  --bond-opts="a=1 b=2 ..." --bond-alias="..."
>  cobbler system edit --name=foo --interface=2 --bond-group=asdf 
>  --bond-opts="a=2 b=3 ..." --bond-alias="..."
>   
The problem with this is that the bonding options are a property of the 
resulting bonding interface asdf, and should be the same for both 
interfaces. I'm not sure where we'd want to store those options.

>  And the %post section snippet (this would be new) would insure that
> the 
>  order of NICs booted is the same as those installed and everything is 
>  configured.   This would also set up things that Anaconda could not set up.
>  
>  In the above example, eth1 and eth2 would be bonded as "asdf".
>  
>  In the above proposal, I'd be willing to add the bits to Cobbler to 
>  store the above kind of data, though I'd like for someone with more 
>  networking skills to write the network configuration snippet.
>   
I can do that. It probably wouldn't be much more than reusing bits of my 
existing snippets. :)

>  We also talked a bit about IP "aliases" / VIPs and
> bridging.   I will 
>  admit at this point that networking is /not/ my area, so what are 
>  everyone's thoughts to the implementation of the above?  
>   
Hmm, this would be a fairly complex network topology for cobbler. I 
think VIPs would be doable (just add a list of aliases to an interface), 
but briding-setups are very specific to the user's situation.

>  What fields do we need to store to make this all possible to be
> defined 
>  at provisioning time and "just work"?
>   
To eliminate the possibility of different bonding options specified on 
two slaves of the same bond, we'd need a special bonding configuration 
object (but this might be ugly). This bonding object would contain the 
bonding options and the IP-configuration.
Per interface we need a field "bonding master", to link the interface to 
this bonding object. We'd want a checkbox for hotplug as well. This 
defaults to ON, but there's a bug with bonding + VLANs and hotplug. 
(https://bugzilla.redhat.com/show_bug.cgi?id=442339)
Or we should just disable it by default.
Per interface we'd also need a list of virtual IPs.

Jasper

[Michael DeHaan]

Jasper Capel wrote:
>  Michael DeHaan wrote:
>    
> > Just recently on IRC (join #cobbler on irc.freenode.net if you aren't 
> > there already) we were discussing whether we could use Cobbler's concept 
> > of interfaces to describe more complicated setups and then use a Cobbler 
> > snippet called in %post to set everything up.
> >
> > We initially were thinking we could describe an interface like this:
> >
> > cobbler system edit --name=foo --interface=1 --bond-group=asdf 
> > --bond-opts="a=1 b=2 ..." --bond-alias="..."
> > cobbler system edit --name=foo --interface=2 --bond-group=asdf 
> > --bond-opts="a=2 b=3 ..." --bond-alias="..."
> >
> >     
>  The problem with this is that the bonding options are a property of the 
>  resulting bonding interface asdf, and should be the same for both 
>  interfaces. I'm not sure where we'd want to store those options.
>
>     
How about with the first interface in the bonded set?
> > And the %post section snippet (this would be new) would insure
> that the 
> > order of NICs booted is the same as those installed and everything is 
> > configured.   This would also set up things that Anaconda could not set up.
> >
> > In the above example, eth1 and eth2 would be bonded as "asdf".
> >
> > In the above proposal, I'd be willing to add the bits to Cobbler to 
> > store the above kind of data, though I'd like for someone with more 
> > networking skills to write the network configuration snippet.
> >
> >     
>  I can do that. It probably wouldn't be much more than reusing bits of my 
>  existing snippets. :)
>
>    
> > We also talked a bit about IP "aliases" / VIPs and bridging.   I will 
> > admit at this point that networking is /not/ my area, so what are 
> > everyone's thoughts to the implementation of the above?  
> >
> >     
>  Hmm, this would be a fairly complex network topology for cobbler. I 
>  think VIPs would be doable (just add a list of aliases to an interface), 
>  but briding-setups are very specific to the user's situation.
>
>     
Yeah, we could just not do them. Virt-bridging is already dealt with by 
libvirt.
> > What fields do we need to store to make this all possible to be
> defined 
> > at provisioning time and "just work"?
> >
> >     
>
>  To eliminate the possibility of different bonding options specified on 
>  two slaves of the same bond, we'd need a special bonding configuration 
>  object (but this might be ugly). This bonding object would contain the 
>  bonding options and the IP-configuration.
>  Per interface we need a field "bonding master", to link the interface to 
>  this bonding object. We'd want a checkbox for hotplug as well. This 
>  defaults to ON, but there's a bug with bonding + VLANs and hotplug. 
>  (https://bugzilla.redhat.com/show_bug.cgi?id=442339)
>  Or we should just disable it by default.
>  Per interface we'd also need a list of virtual IPs.
>     
Given the above "cobbler system edit" syntax can you sketch out what you 
think this might look like?

For things that are proprieties of the bonded set, I'd say storing them 
with the first in the set wouldn't be too hideous.

Otherwise we could just do it correctly and modify the bonding rules on 
top of the interfaces already there, though this ends up complicating 
the webapp just a bit.

A crazy way to do it might be

cobbler system edit --name=foo --bonds="alpha=0,1:options 
beta=2,3:options" or something a bit more complex, though that is less 
editable and probably not as clean.

>  Jasper
>  _______________________________________________
>  cobbler mailing list
>  cobbler(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/cobbler
>

[Jasper Capel]

Michael DeHaan wrote:
> >>     
> > The problem with this is that the bonding options are a property of the 
> > resulting bonding interface asdf, and should be the same for both 
> > interfaces. I'm not sure where we'd want to store those options.
> >
> >   
>  How about with the first interface in the bonded set? 
Sure, that'd be fine. :)

> >>
> >>     
> > To eliminate the possibility of different bonding options specified on 
> > two slaves of the same bond, we'd need a special bonding configuration 
> > object (but this might be ugly). This bonding object would contain the 
> > bonding options and the IP-configuration.
> > Per interface we need a field "bonding master", to link the interface to 
> > this bonding object. We'd want a checkbox for hotplug as well. This 
> > defaults to ON, but there's a bug with bonding + VLANs and hotplug. 
> > (https://bugzilla.redhat.com/show_bug.cgi?id=442339)
> > Or we should just disable it by default.
> > Per interface we'd also need a list of virtual IPs.
> >   
>  
>  Given the above "cobbler system edit" syntax can you sketch out what you 
>  think this might look like?
>   
cobbler system edit --name=foo --interface=1 --bond-group=asdf
--bond-opts="a=1,b=2 ..." --hotplug=no --alias=slave0 
--ip-alias="192.168.1.53/24,192.168.1.54/24"
this would set up the bond (resulting interface name foo) and rename 
this slave interface to slave0. It would also add aliases on the interface.

cobbler system edit --name=foo --interface=2 --bond-group=asdf 
--hotplug=no --alias=slave1
rename the interface to slave1 and add it to bond foo

Something like this?

>  For things that are proprieties of the bonded set, I'd say
> storing them 
>  with the first in the set wouldn't be too hideous.
>  
>  Otherwise we could just do it correctly and modify the bonding rules on 
>  top of the interfaces already there, though this ends up complicating 
>  the webapp just a bit.
>  
>  A crazy way to do it might be
>  
>  cobbler system edit --name=foo --bonds="alpha=0,1:options 
>  beta=2,3:options" or something a bit more complex, though that is less 
>  editable and probably not as clean.
>   
I think we should go the easy way. When we get things working we can 
decide if it should be moved some place else.

Jasper

[Dave Augustus]

On Tue, 2008-09-23 at 14:46 -0400, Michael DeHaan wrote:
>  Given the above "cobbler system edit" syntax can you sketch
> out what
>  you 
>  think this might look like?
>   
What about something like this?

for bonding interfaces:
cobbler system edit --name=foo --interface=bond0 --ip=10.10.10.10 --
mac_addr=00:11:22:33:44:55

for ethernet interfaces:
cobbler system edit --name=foo --interface=eth0 --mac=01:23:45:67:89:00
--master=bond0

cobbler system edit --name=foo --interface=eth1 --mac=99:99:77:66:55:44
--master=bond0

for ip addresses(aliases only)
cobbler system edit --name=foo --interface=bond0 --ipalias=192.168.100.2

--
Thanks for cobbler!
Dave

[Dave Augustus]

On Tue, 2008-09-23 at 14:26 -0500, Dave Augustus wrote:
>  On Tue, 2008-09-23 at 14:46 -0400, Michael DeHaan wrote:
>  > Given the above "cobbler system edit" syntax can you sketch out what
>  > you 
>  > think this might look like?
>  > 
>  
>  What about something like this?
>  
>  for bonding interfaces:
>  cobbler system edit --name=foo --interface=bond0 --ip=10.10.10.10 --
>  mac_addr=00:11:22:33:44:55
>  
>  for ethernet interfaces:
>  cobbler system edit --name=foo --interface=eth0 --mac=01:23:45:67:89:00
>  --master=bond0
>  
>  cobbler system edit --name=foo --interface=eth1 --mac=99:99:77:66:55:44
>  --master=bond0
>  
>  for ip addresses(aliases only)
>  cobbler system edit --name=foo --interface=bond0 --ipalias=192.168.100.2 
Here are some revisions/additions to the above mentions with input from
IRC:

build the bonding interface:
cobbler system edit --name=foo --interface=bond0 --ip=10.10.10.10 --
netmask=255.255.255.0 --bondingopts="arp_interval=100
arp_ip_target=10.10.10.11,10.10.10.12,10.10.10.13"

add an ethernet interface to it:
cobbler system edit --name=foo --interface=eth0 --mac=01:23:45:67:89:00
--master=bond0 --hotplug=no 

add an ip alias to bond0:
cobbler system edit --name=foo --interface=bond0 --addip --
ipalias=192.168.168.1 --netmask=255.255.255.0

add a second ip to bond0:
cobbler system edit --name=foo --interface=bond0 --addip --
ipalias=172.49.49.10 --netmask=255.255.255.0


By only putting the *master* parameter on the "eth" lines, the number of
"eths" used can be numerous. I realize that *slave* is needed for
configuring bonding but my idea was that the cheetah(or python- whatever
it is that does this) would handle that portion, scanning a system for
ETH interfaces FIRST, then BONDING interfaces. I am not sure if that is
possible but I would assume so.

Thanks,
Dave

[Dave Augustus]

On Tue, 2008-09-23 at 15:06 -0500, Dave Augustus wrote:
>  Here are some revisions/additions to the above mentions with input
>  from
>  IRC:
>  
>  build the bonding interface:
>  cobbler system edit --name=foo --interface=bond0 --ip=10.10.10.10 --
>  netmask=255.255.255.0 --bondingopts="arp_interval=100
>  arp_ip_target=10.10.10.11,10.10.10.12,10.10.10.13"
>  
>  add an ethernet interface to it:
>  cobbler system edit --name=foo --interface=eth0 --
>  mac=01:23:45:67:89:00
>  --master=bond0 --hotplug=no 
>  
>  add an ip alias to bond0:
>  cobbler system edit --name=foo --interface=bond0 --addip --
>  ipalias=192.168.168.1 --netmask=255.255.255.0
>  
>  add a second ip to bond0:
>  cobbler system edit --name=foo --interface=bond0 --addip --
>  ipalias=172.49.49.10 --netmask=255.255.255.0 

One more time!

build the bonding interface:
cobbler system edit 
--name=foo 
--interface=bond0 
--ip=10.10.10.10 
--netmask=255.255.255.0 
--bondingopts="arp_interval=100
arp_ip_target=10.10.10.11,10.10.10.12,10.10.10.13" 

add an ethernet interface to it:
cobbler system edit 
--name=foo
--mac=01:23:45:67:89:00
--interface=eth0
--master=bond0
--onboot=yes 
--userctl=no 
--comment="Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet" 

I am unsure of the userctl parameter. If it is not needed, then it could
default to *no*.


Thanks!
Dave

[Jasper Capel]

Dave Augustus wrote:
>  One more time!
>
>  build the bonding interface:
>  cobbler system edit 
>  --name=foo 
>  --interface=bond0 
>  --ip=10.10.10.10 
>  --netmask=255.255.255.0 
>  --bondingopts="arp_interval=100
>  arp_ip_target=10.10.10.11,10.10.10.12,10.10.10.13" 
>
>     
It would be a very-nice-to-have if the bonding options could be 
inherited from the profile, they're likely to be the same for a lot of 
machines.
>  add an ethernet interface to it:
>  cobbler system edit 
>  --name=foo
>  --mac=01:23:45:67:89:00
>  --interface=eth0
>  --master=bond0
>  --onboot=yes 
>  --userctl=no 
>  --comment="Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet" 
>
>  I am unsure of the userctl parameter. If it is not needed, then it could
>  default to *no*.
>
>     
Add --hotplug=yes/no to the list. :)

Jasper

[PATCH] Generic interface support (was Re: Support for bonding and other advanced networking topics)

[John Eckersberg]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

First and foremost, the bonding stuff discussed today sounds great and
is something that I'd be interested in helping with and using.

Before we dig too far into that, however, I want to post up something
I've been meaning to finish for the past month or so but just haven't
had the time to flesh it out completely.  I'd like to get it applied
(assuming others think it's a good patch :D) before we go tearing up the
interface code even more.

The attached patch adds support for generic interface names, and as a
side-effect allows an arbitrary number of interfaces to be assigned to a
system.  This work looks to be a pre-requisite for the bonding examples
anyways, so it should prove useful.

More information is available in the commit log of the patch.

As always, suggestions / gripes / feedback / patches are welcome!

- --
John Eckersberg
Systems Administrator, CIS
Red Hat, Inc.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkjZlPIACgkQdxt4pd4ztYuBegCfTgcny9hdoLovwWD/UU+QPOwW
> QBEAoICMHcU/ji+0teuihbNitB1Pwr+k
> =ZuJ9
> -----END PGP SIGNATURE----- 
> From f39dbead3f8f9f6de9b734e1856e66e8035e2f04 Mon Sep 17 00:00:00 2001
From: John Eckersberg <jeckersb(a)redhat.com&gt;
Date: Tue, 23 Sep 2008 20:41:53 -0400
Subject: [PATCH] * Add new functions __get_default_interface and set_default_interface
   to the System class.

* Add new setting 'default_interface' to automatically name the
  interface used when creating new systems.  Defaults to 'intf0' for
  backwards compatibility.  I suspect most people will want to set
  this to 'eth0'.

* Modify the printable method of System to always print the default
  interface first and mark it as the default

* Modify cli_system to add two new options:
  * --delete-interface
  * --default-interface

* Whatever interface is set as the default cannot be deleted.

These changes allow for an arbitrary number of interfaces to be added
to a system, as well as allows for the interfaces to be named
something more meaningful than intf0-7.

TODO
----
*** The WebUI is NOT updated by this patch and needs fixed! ***

* Allow default_interface to be set at profile level

* Add method to fetch system interfaces over XMLRPC.  I want to query
  my cobbler server in my Puppet exernal nodes script to build out
  interface configuration.  YMMV.
---
 cobbler/item_system.py        |   69 +++++++++++++++++++++++++++-------------
 cobbler/modules/cli_system.py |   19 ++++++++---
 cobbler/settings.py           |    1 +
 config/settings               |    5 +++
 4 files changed, 65 insertions(+), 29 deletions(-)

diff --git a/cobbler/item_system.py b/cobbler/item_system.py
index c83e74b..4d8796a 100644
--- a/cobbler/item_system.py
+++ b/cobbler/item_system.py
@@ -45,6 +45,7 @@ class System(item.Item):
         self.kernel_options_post  = {}
         self.ks_meta              = {}    
         self.interfaces           = {}
+        self.default_interface    = self.settings.default_interface
         self.netboot_enabled      = True
         self.depth                = 2
         self.mgmt_classes         = []              
@@ -61,12 +62,10 @@ class System(item.Item):
 
     def delete_interface(self,name):
         """
-        Used to remove an interface.  Not valid for intf0.
+        Used to remove an interface.  Not valid for the default interface.
         """
-        if name == "intf0":
-            raise CX(_("the first interface cannot be deleted"))
-        if self.interfaces.has_key(name):
-            del self.interfaces[name]
+        if self.interfaces.has_key(name) and self.default_interface != name:
+                del self.interfaces[name]
         else:
             # NOTE: raising an exception here would break the WebUI as currently
implemented
             return False
@@ -74,9 +73,8 @@ class System(item.Item):
         
 
     def __get_interface(self,name):
-
-        if name not in [ "intf0", "intf1", "intf2",
"intf3", "intf4", "intf5", "intf6",
"intf7" ]:
-            raise CX(_("internal error: invalid key for interface lookup or storage,
must be 'intfX' where x is 0..7"))
+        if name is None:
+            return self.__get_default_interface()
 
         if not self.interfaces.has_key(name):
             self.interfaces[name] = {
@@ -91,6 +89,12 @@ class System(item.Item):
             }
         return self.interfaces[name]
 
+    def __get_default_interface(self):
+        if self.default_interface != "":
+            return self.__get_interface(self.default_interface)
+        else:
+            raise CX(_("no default interface defined"))
+
     def from_datastruct(self,seed_data):
 
         # load datastructures from previous and current versions of cobbler
@@ -110,6 +114,7 @@ class System(item.Item):
         self.netboot_enabled      = self.load_item(seed_data, 'netboot_enabled',
True)
         self.server               = self.load_item(seed_data, 'server',
'<<inherit>>')
         self.mgmt_classes         = self.load_item(seed_data, 'mgmt_classes',
[])
+        self.default_interface    = self.load_item(seed_data,
'default_interface', self.settings.default_interface)
 
         # virt specific 
         self.virt_path   = self.load_item(seed_data, 'virt_path',
'<<inherit>>') 
@@ -182,7 +187,7 @@ class System(item.Item):
         Set the name.  If the name is a MAC or IP, and the first MAC and/or IP is not
defined, go ahead
         and fill that value in.  
         """
-        intf = self.__get_interface("intf0")
+        intf = self.__get_default_interface()
 
 
         if self.name not in ["",None] and self.parent not in
["",None] and self.name == self.parent:
@@ -211,14 +216,14 @@ class System(item.Item):
         self.server = server
         return True
 
-    def get_mac_address(self,interface="intf0"):
+    def get_mac_address(self,interface):
         """
         Get the mac address, which may be implicit in the object name or explicit with
--mac-address.
         Use the explicit location first.
         """
 
-
         intf = self.__get_interface(interface)
+
         if intf["mac_address"] != "":
             return intf["mac_address"]
         # obsolete, because we should have updated the mac field already with set_name
(?)
@@ -227,13 +232,14 @@ class System(item.Item):
         else:
             return None
 
-    def get_ip_address(self,interface="intf0"):
+    def get_ip_address(self,interface):
         """
         Get the IP address, which may be implicit in the object name or explict with
--ip-address.
         Use the explicit location first.
         """
 
         intf = self.__get_interface(interface)
+
         if intf["ip_address"] != "": 
             return intf["ip_address"]
         else:
@@ -258,22 +264,28 @@ class System(item.Item):
                 return True
         return False
 
-    def set_dhcp_tag(self,dhcp_tag,interface="intf0"):
+    def set_default_interface(self,interface):
+        if self.interfaces.has_key(interface):
+            self.default_interface = interface
+        else:
+            raise CX(_("invalid interface (%s)") % interface)
+
+    def set_dhcp_tag(self,dhcp_tag,interface):
         intf = self.__get_interface(interface)
         intf["dhcp_tag"] = dhcp_tag
         return True
 
-    def set_hostname(self,hostname,interface="intf0"):
+    def set_hostname(self,hostname,interface):
         intf = self.__get_interface(interface)
         intf["hostname"] = hostname
         return True
 
-    def set_static(self,truthiness,interface="intf0"):
+    def set_static(self,truthiness,interface):
         intf = self.__get_interface(interface)
         intf["static"] = utils.input_boolean(truthiness)
         return True
 
-    def set_ip_address(self,address,interface="intf0"):
+    def set_ip_address(self,address,interface):
         """
         Assign a IP or hostname in DHCP when this MAC boots.
         Only works if manage_dhcp is set in /etc/cobbler/settings
@@ -284,24 +296,24 @@ class System(item.Item):
            return True
         raise CX(_("invalid format for IP address (%s)") % address)
 
-    def set_mac_address(self,address,interface="intf0"):
+    def set_mac_address(self,address,interface):
         intf = self.__get_interface(interface)
         if address == "" or utils.is_mac(address):
            intf["mac_address"] = address
            return True
         raise CX(_("invalid format for MAC address (%s)" % address))
 
-    def set_gateway(self,gateway,interface="intf0"):
+    def set_gateway(self,gateway,interface):
         intf = self.__get_interface(interface)
         intf["gateway"] = gateway
         return True
 
-    def set_subnet(self,subnet,interface="intf0"):
+    def set_subnet(self,subnet,interface):
         intf = self.__get_interface(interface)
         intf["subnet"] = subnet
         return True
     
-    def set_virt_bridge(self,bridge,interface="intf0"):
+    def set_virt_bridge(self,bridge,interface):
         intf = self.__get_interface(interface)
         intf["virt_bridge"] = bridge
         return True
@@ -414,6 +426,7 @@ class System(item.Item):
            'kernel_options_post'   : self.kernel_options_post,
            'depth'                 : self.depth,
            'interfaces'            : self.interfaces,
+           'default_interface'     : self.default_interface,
            'ks_meta'               : self.ks_meta,
            'kickstart'             : self.kickstart,
            'netboot_enabled'       : self.netboot_enabled,
@@ -451,9 +464,21 @@ class System(item.Item):
         buf = buf + _("virt ram              : %s\n") % self.virt_ram
         buf = buf + _("virt type             : %s\n") % self.virt_type
 
+        # list the default interface first
+        name = self.default_interface
+        x    = self.interfaces[name]
+        buf = buf + _("interface        : %s (default)\n") % (name)
+        buf = buf + _("  mac address    : %s\n") %
x.get("mac_address","")
+        buf = buf + _("  ip address     : %s\n") %
x.get("ip_address","")
+        buf = buf + _("  hostname       : %s\n") %
x.get("hostname","")
+        buf = buf + _("  gateway        : %s\n") %
x.get("gateway","")
+        buf = buf + _("  subnet         : %s\n") %
x.get("subnet","")
+        buf = buf + _("  virt bridge    : %s\n") %
x.get("virt_bridge","")
+        buf = buf + _("  dhcp tag       : %s\n") %
x.get("dhcp_tag","")
+        buf = buf + _("  is static?     : %s\n") %
x.get("static",False)
 
-        counter = 0
         for (name,x) in self.interfaces.iteritems():
+            if name == self.default_interface: continue
             buf = buf + _("interface        : %s\n") % (name)
             buf = buf + _("  mac address    : %s\n") %
x.get("mac_address","")
             buf = buf + _("  ip address     : %s\n") %
x.get("ip_address","")
@@ -463,8 +488,6 @@ class System(item.Item):
             buf = buf + _("  virt bridge    : %s\n") %
x.get("virt_bridge","")
             buf = buf + _("  dhcp tag       : %s\n") %
x.get("dhcp_tag","")
             buf = buf + _("  is static?     : %s\n") %
x.get("static",False)
-            counter = counter + 1
-         
 
         return buf
 
diff --git a/cobbler/modules/cli_system.py b/cobbler/modules/cli_system.py
index 7d5a032..3ffd7cd 100644
--- a/cobbler/modules/cli_system.py
+++ b/cobbler/modules/cli_system.py
@@ -29,7 +29,7 @@ sys.path.insert(0, mod_path)
 
 from utils import _, get_random_mac
 import commands
-import cexceptions
+from cexceptions import *
 
 
 class SystemFunction(commands.CobblerFunction):
@@ -54,9 +54,11 @@ class SystemFunction(commands.CobblerFunction):
             p.add_option("--hostname",        dest="hostname",     
help="ex: server.example.org")
 
             if not self.matches_args(args,["find"]):
-                p.add_option("--interface",       dest="interface",
help="edit this interface # (0-7, default 0)")
+                p.add_option("--interface",       dest="interface",
help="edit this interface")
+                p.add_option("--delete-interface",
dest="delete_interface", metavar="INTERFACE", help="delete the
selected interface")
+                p.add_option("--default-interface",
dest="default_interface", metavar="INTERFACE", help="set
INTERFACE as the system default")
             p.add_option("--image",           dest="image",        
help="inherit values from this image, not compatible with --profile")
-            p.add_option("--ip",              dest="ip",           
help="ex: 192.168.1.55, for static IP or dynamic reservation, (RECOMMENDED)")
+            p.add_option("--ip",              dest="ip",           
help="ex: 192.168.1.55, (RECOMMENDED)")
             p.add_option("--kickstart",       dest="kickstart",    
help="override profile kickstart template")
             p.add_option("--kopts",           dest="kopts",        
help="ex: 'noipv6'")
             p.add_option("--kopts-post",      dest="kopts_post",   
help="ex: 'clocksource=pit'")
@@ -130,9 +132,9 @@ class SystemFunction(commands.CobblerFunction):
         if self.options.virt_path:       obj.set_virt_path(self.options.virt_path)
 
         if self.options.interface:
-            my_interface = "intf%s" % self.options.interface
+            my_interface = self.options.interface
         else:
-            my_interface = "intf0"
+            my_interface = None
 
         if self.options.hostname:    obj.set_hostname(self.options.hostname,
my_interface)
         if self.options.mac:
@@ -146,7 +148,12 @@ class SystemFunction(commands.CobblerFunction):
         if self.options.dhcp_tag:    obj.set_dhcp_tag(self.options.dhcp_tag,
my_interface)
         if self.options.virt_bridge: obj.set_virt_bridge(self.options.virt_bridge,
my_interface)
         if self.options.static:      obj.set_static(self.options.static, my_interface)
-              
+
+        if self.options.delete_interface:
+            success = obj.delete_interface(self.options.delete_interface)
+            if not success:
+                raise CX(_('interface does not exist or is the default interface
(%s)') % self.options.delete_interface)
+        if self.options.default_interface:
obj.set_default_interface(self.options.default_interface)
 
         if self.options.owners:       obj.set_owners(self.options.owners)
         if self.options.mgmt_classes: obj.set_mgmt_classes(self.options.mgmt_classes)
diff --git a/cobbler/settings.py b/cobbler/settings.py
index fd2af0a..d652e4a 100644
--- a/cobbler/settings.py
+++ b/cobbler/settings.py
@@ -34,6 +34,7 @@ DEFAULTS = {
     "allow_duplicate_ips"         : 0,
     "bind_bin"                    : "/usr/sbin/named",
     "cobbler_master"              : '',
+    "default_interface"           : 'intf0',
     "default_kickstart"           : "/etc/cobbler/default.ks",
     "default_virt_bridge"         : "xenbr0",
     "default_virt_type"           : "auto",
diff --git a/config/settings b/config/settings
index 9ac6cec..67ea1a3 100644
--- a/config/settings
+++ b/config/settings
@@ -20,6 +20,11 @@ allow_duplicate_ips: 0
 # the path to BIND's executable for this distribution.
 bind_bin: /usr/sbin/named
 
+# name of the default interface when creating a new system.
+# this is intf0 for backwards-compatibility; you may want to
+# specify something else (e.g. eth0) to be more meaningful
+default_interface: intf0
+
 # if no kickstart is specified, use this template (FIXME)
 default_kickstart: /etc/cobbler/default.ks
 
-- 
1.5.5.1

[PATCH] Generic interface support (was Re: Support for bonding and other advanced networking topics)

[Jasper Capel]

John Eckersberg wrote:

>  Before we dig too far into that, however, I want to post up
> something
>  I've been meaning to finish for the past month or so but just haven't
>  had the time to flesh it out completely.  I'd like to get it applied
>  (assuming others think it's a good patch :D) before we go tearing up the
>  interface code even more.
>   
I haven't tested your patch, but this definitely looks like something we 
need / can use for the interface bonding.

Jasper

[PATCH] Generic interface support (was Re: Support for bonding and other advanced networking topics)

[Michael DeHaan]

John Eckersberg wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>  First and foremost, the bonding stuff discussed today sounds great and
>  is something that I'd be interested in helping with and using.
>
>  Before we dig too far into that, however, I want to post up something
>  I've been meaning to finish for the past month or so but just haven't
>  had the time to flesh it out completely.  I'd like to get it applied
>  (assuming others think it's a good patch :D) before we go tearing up the
>  interface code even more.
>
>  The attached patch adds support for generic interface names, and as a
>  side-effect allows an arbitrary number of interfaces to be assigned to a
>  system.  This work looks to be a pre-requisite for the bonding examples
>  anyways, so it should prove useful.
>
>  More information is available in the commit log of the patch.
>
>  As always, suggestions / gripes / feedback / patches are welcome!
>
>  - --
>  John Eckersberg
>  Systems Administrator, CIS
>  Red Hat, Inc.
>
> >  -----BEGIN PGP SIGNATURE-----
> >  Version: GnuPG v1.4.9 (GNU/Linux)
> >  Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> >
> >  iEYEARECAAYFAkjZlPIACgkQdxt4pd4ztYuBegCfTgcny9hdoLovwWD/UU+QPOwW
> >  QBEAoICMHcU/ji+0teuihbNitB1Pwr+k
> >  =ZuJ9
> >  -----END PGP SIGNATURE----- 
>    
>  ------------------------------------------------------------------------
>
>  _______________________________________________
>  cobbler mailing list
>  cobbler(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/cobbler 

Comments:

-- Make test runs clean and general edit commands seem to work fine.

-- I had to modify the network_config snippet we're shipping Cobbler 1.3 
to set up the network parts of kickstart (does not do %post config) to 
be compatible.     This is a new feature and the change was simple, so 
that's not too bad.  It also makes the "post network config" snippet on 
the Wiki incompatible though since we are thinking about including that 
in Cobbler also (per recent emails) that's not a problem.

-- Are you planning on adding the multiple interface views to the 
webapp, or is that something I need to look into?   Either way we should 
add an item to Trac with "blocker" status on that one and get that done 
for 1.3.

Being able to use arbitrary names for the interfaces is definitely a 
bonus.   I think it would be fine to simplify and call things "eth0" 
though the reason we don't now is because we do not have the 
post_network_config snippet in place to ensure the first interface 
actually /is/ eth0.  We are now using ipappend 2 and such, so this 
should be possible in the future.   If we include a post_network_config 
setup tool that populates /etc/sysconfig/network in %post, then I think 
we can simplify and name the default interface eth0.   In which case, we 
probably /also/ want to add code to auto-rename any "intf0" interfaces 
to "eth0" and such as well.   Since we are at a development point in the 
code, we /can/ do this.   Thoughts?

This would mean --interface=X would either take ethN or bondN, if we 
also support the bonding case, as opposed to a freeform string.

Either way, this is applied and will be pushed shortly, and I'm opening 
a Trac item on the webapp so we don't forget it.

--Michael

[PATCH] Generic interface support (was Re: Support for bonding and other advanced networking topics)

[Dave Hatton]

>  This would mean --interface=X would either take ethN or bondN, if we 
>  also support the bonding case, as opposed to a freeform string.
>
>     
If you allow for --interface=X:Y  then this would allow for the IPalias 
support discussed yesterday

(eg: --interface=eth0:1 --ip=x.x.x.x --netmask=x.x.x.x)

this should generate a standard ifcfg file under 
/etc/sysconfig/network-scripts but with a name like ifcfg-eth0:1

dave

[PATCH] Generic interface support (was Re: Support for bonding and other advanced networking topics)

[Michael DeHaan]

Dave Hatton wrote:
> > This would mean --interface=X would either take ethN or bondN, if
> we 
> > also support the bonding case, as opposed to a freeform string.
> >
> >   
> >     
>  If you allow for --interface=X:Y  then this would allow for the IPalias 
>  support discussed yesterday
>
>  (eg: --interface=eth0:1 --ip=x.x.x.x --netmask=x.x.x.x)
>
>  this should generate a standard ifcfg file under 
>  /etc/sysconfig/network-scripts but with a name like ifcfg-eth0:1
>
>  dave
>
>  _______________________________________________
>  cobbler mailing list
>  cobbler(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/cobbler
>     
Right now the interface name could be arbitrary, so it seems it would 
only depend on the magic to set things up right in %post. Does anyone 
care to take a shot at cleaning up the "post-network-system-config" 
snippet on the Wiki now? We should make it account for mutliple 
interfaces first, add it to %post in the default templates, and then we 
can teach it about bonding once that is established.

(Also regarding my earlier web comments, this interface change may prove 
a reason enough to clean up the webapp in general --- adding 
multi-interface support is going to be hand without making it more ajaxy 
anyway. This might make it a little longer between releases but could 
make for some interesting things. Still evaluating -- I'll chase this 
while everyone is looking at the networking details, we need them both)

--Michael

[PATCH] Generic interface support (was Re: Support for bonding and other advanced networking topics)

[Jasper Capel]

Michael DeHaan wrote:

>  Right now the interface name could be arbitrary, so it seems it would
>
>  only depend on the magic to set things up right in %post. Does anyone 
>  care to take a shot at cleaning up the "post-network-system-config" 
>  snippet on the Wiki now? We should make it account for mutliple 
>  interfaces first, add it to %post in the default templates, and then we 
>  can teach it about bonding once that is established.
>   
If we're gonna do some %post magic anyway, why not add adding custom 
routes on an interface as well? It would be a small effort to write the 
route-<ifname> files as well.

something like this:
--interface=eth0 --gateway=10.1.1.254 --routes="10.0.0.0/24 via 
10.1.1.1,10.0.2.0/24 via 10.1.1.2"
--gateway would write the default gateway (as it is now) and --routes 
would add anything there to routes-eth0 (but with a newline instead of a 
comma)

Just a thought. :)

Jasper

[PATCH] Generic interface support (was Re: Support for bonding and other advanced networking topics)

[Michael DeHaan]

Jasper Capel wrote:
>  Michael DeHaan wrote:
>
>    
> > Right now the interface name could be arbitrary, so it seems it would 
> > only depend on the magic to set things up right in %post. Does anyone 
> > care to take a shot at cleaning up the "post-network-system-config" 
> > snippet on the Wiki now? We should make it account for mutliple 
> > interfaces first, add it to %post in the default templates, and then we 
> > can teach it about bonding once that is established.
> >
> >     
>  If we're gonna do some %post magic anyway, why not add adding custom 
>  routes on an interface as well? It would be a small effort to write the 
>  route-<ifname> files as well.
>
>  something like this:
>  --interface=eth0 --gateway=10.1.1.254 --routes="10.0.0.0/24 via 
>  10.1.1.1,10.0.2.0/24 via 10.1.1.2"
>  --gateway would write the default gateway (as it is now) and --routes 
>  would add anything there to routes-eth0 (but with a newline instead of a 
>  comma)
>
>  Just a thought. :)
>
>  Jasper
>  _______________________________________________
>  cobbler mailing list
>  cobbler(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/cobbler
>     
There's a fine line between this and a config managment tool, though 
networking /does/ have to be set up properly before that.

This seems reasonable, though the syntax maybe could be cleaner.

"10.0.0.0/24=10.1.1.1 10.0.2.0/24=10.1.1.2" would allow the python code 
in utils.py to parse it just like any other --ks-meta or --kernel option.

I can see a big Wiki page on "advanced networking topics" building up now :)

--Michael

[PATCH] Generic interface support (was Re: Support for bonding and other advanced networking topics)

[Jasper Capel]

Michael DeHaan wrote:

>  Right now the interface name could be arbitrary, so it seems it would
>
>  only depend on the magic to set things up right in %post. Does anyone 
>  care to take a shot at cleaning up the "post-network-system-config" 
>  snippet on the Wiki now? We should make it account for mutliple 
>  interfaces first, add it to %post in the default templates, and then we 
>  can teach it about bonding once that is established.
>   
I spent some time on this yesterday, but unfortunately I won't be able 
to test it this week, so there's probably some typo in it.
If someone wants to look at it, then great, else I'll try to find the 
time next week. :)

See:
http://bender.newnewyork.nl/git/gitweb.cgi?p=cobbler/.git;a=commit;h=4746...
or:
git://bender.newnewyork.nl/cobbler (branch: post-network)

Jasper

[PATCH] Generic interface support (was Re: Support for bonding and other advanced networking topics)

[Jasper Capel]

Jasper Capel wrote:
>  Michael DeHaan wrote:
>  
> > Right now the interface name could be arbitrary, so it seems it would 
> > only depend on the magic to set things up right in %post. Does anyone 
> > care to take a shot at cleaning up the "post-network-system-config" 
> > snippet on the Wiki now? We should make it account for mutliple 
> > interfaces first, add it to %post in the default templates, and then we 
> > can teach it about bonding once that is established.
> >
>  
>  I spent some time on this yesterday, but unfortunately I won't be able 
>  to test it this week, so there's probably some typo in it.
>  If someone wants to look at it, then great, else I'll try to find the 
>  time next week. :)
>   
Tested, removed a few bugs and this works for EL5 now. I don't know if 
we'd want to call this one by default, as there's still a default 
interface intf0 for systems. This would result in the first interface 
being called intf0 instead of eth0, which doesn't make much sense to me. 
I think we should change that behaviour first. :)
And I'm not too happy with the name post_network_system_config, so I 
renamed it to post_install_network_config, any objections?

Once this is done, we can look into bonding and vlan support. VLANs 
would be fairly easy, so that's a nice next target.

>  See:
>
> http://bender.newnewyork.nl/git/gitweb.cgi?p=cobbler/.git;a=commit;h=4746...
http://bender.newnewyork.nl/git/gitweb.cgi?p=cobbler/.git;a=shortlog;h=re...
>  or:
>  git://bender.newnewyork.nl/cobbler (branch: post-network)
>  
>  Jasper

[PATCH] Generic interface support (was Re: Support for bonding and other advanced networking topics)

[Michael DeHaan]

Jasper Capel wrote:
>  Jasper Capel wrote:
>    
> > Michael DeHaan wrote:
> >
> >     
> >> Right now the interface name could be arbitrary, so it seems it would 
> >> only depend on the magic to set things up right in %post. Does anyone 
> >> care to take a shot at cleaning up the "post-network-system-config" 
> >> snippet on the Wiki now? We should make it account for mutliple 
> >> interfaces first, add it to %post in the default templates, and then we 
> >> can teach it about bonding once that is established.
> >>
> >>       
> > I spent some time on this yesterday, but unfortunately I won't be able 
> > to test it this week, so there's probably some typo in it.
> > If someone wants to look at it, then great, else I'll try to find the 
> > time next week. :)
> >
> >     
>  Tested, removed a few bugs and this works for EL5 now. I don't know if 
>  we'd want to call this one by default, as there's still a default 
>  interface intf0 for systems. This would result in the first interface 
>  being called intf0 instead of eth0, which doesn't make much sense to me. 
>  I think we should change that behaviour first. :)
>  And I'm not too happy with the name post_network_system_config, so I 
>  renamed it to post_install_network_config, any objections?
>
>  Once this is done, we can look into bonding and vlan support. VLANs 
>  would be fairly easy, so that's a nice next target.
>
>    
> > See:
> >
> http://bender.newnewyork.nl/git/gitweb.cgi?p=cobbler/.git;a=commit;h=4746...
> >     
>
>
> http://bender.newnewyork.nl/git/gitweb.cgi?p=cobbler/.git;a=shortlog;h=re...
>    
> > or:
> > git://bender.newnewyork.nl/cobbler (branch: post-network)
> >
> > Jasper
> >     
>
>  _______________________________________________
>  cobbler mailing list
>  cobbler(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/cobbler
>     
I haven't applied this just yet.

One thing it needs to do is be aware there is a new "static" interface 
attribute, so we should use that versus checking to see if the ip is 
defined or not.

The reason for this is that in cobbler you can define the MAC and IP of 
a system and when using manage_dhcp features it can set up reservations 
automatically for you in DHCP. This does not mean that you should be 
using static IP, just that cobbler is maintaing the MAC <-> IP 
relationship for you.

So if you change this, I think this is good to apply.

As far as the naming of "intf0" before, the reason for that is before 
this patch existed, there really was no guaranteed relationship between 
the interface defined in Cobbler and the interface you would get when 
you installed it, so I felt is was important to not give anyone 
assumptions about what was really eth0 or not... it was really an 
arbitary name only used for internal storage. Now that it's important, 
yes, the default will be eth0
for all new installs.

We /could/ add some code to automatically rename any interfaces so they 
start with "eth", though it could very well break applications written 
on top of the Cobbler API. However, it's better to name things 
consistently. So, fair warning... we'll start calling things "eth0" 
properly now.

Another thing is that this patch doesn't include RPM packaging for the 
snippet, or inclusion of the snippet into any of the default templates, 
so once you revise this, I can take care of that if needed. Then we'll 
also need a fair amount of testing to make sure all the networking is 
nice and happy.

Good feature.

--Michael

[PATCH] Generic interface support (was Re: Support for bonding and other advanced networking topics)

[Michael DeHaan]

Jasper Capel wrote:
>  Jasper Capel wrote:
>    
> > Michael DeHaan wrote:
> >
> >     
> >> Right now the interface name could be arbitrary, so it seems it would 
> >> only depend on the magic to set things up right in %post. Does anyone 
> >> care to take a shot at cleaning up the "post-network-system-config" 
> >> snippet on the Wiki now? We should make it account for mutliple 
> >> interfaces first, add it to %post in the default templates, and then we 
> >> can teach it about bonding once that is established.
> >>
> >>       
> > I spent some time on this yesterday, but unfortunately I won't be able 
> > to test it this week, so there's probably some typo in it.
> > If someone wants to look at it, then great, else I'll try to find the 
> > time next week. :)
> >
> >     
>  Tested, removed a few bugs and this works for EL5 now. I don't know if 
>  we'd want to call this one by default, as there's still a default 
>  interface intf0 for systems. This would result in the first interface 
>  being called intf0 instead of eth0, which doesn't make much sense to me. 
>  I think we should change that behaviour first. :)
>  And I'm not too happy with the name post_network_system_config, so I 
>  renamed it to post_install_network_config, any objections?
>
>  Once this is done, we can look into bonding and vlan support. VLANs 
>  would be fairly easy, so that's a nice next target.
>
>    
> > See:
> >
> http://bender.newnewyork.nl/git/gitweb.cgi?p=cobbler/.git;a=commit;h=4746...
> >     
>
>
> http://bender.newnewyork.nl/git/gitweb.cgi?p=cobbler/.git;a=shortlog;h=re...
>    
> > or:
> > git://bender.newnewyork.nl/cobbler (branch: post-network)
> >
> > Jasper
> >     
>
>  _______________________________________________
>  cobbler mailing list
>  cobbler(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/cobbler
>     
Looks like I did actually merge it, though the aforementioned cleanup 
would be nice.

I'll go ahead and see if I can knock that out.

--Michael

[PATCH] Generic interface support (was Re: Support for bonding and other advanced networking topics)

[Jasper Capel]

Michael DeHaan wrote:
> >   
>  
>  Looks like I did actually merge it, though the aforementioned cleanup 
>  would be nice.
>  
>  I'll go ahead and see if I can knock that out.
>  
>  --Michael
>   
For everyone's information: there's still a bug in this that would cause 
anaconda to mix up physical devices / IP-information when using multiple 
interfaces. I hope to fix this some time this week by writing a %pre 
snippet to match the mac-addresses to interface names as seen by anaconda.

Jasper

[PATCH] Generic interface support (was Re: Support for bonding and other advanced networking topics)

[Koelewijn, Marcel - Acision]

Hi all,

When extending the network configuration it could be very useful to add VLAN trunking
(802.1Q I think) as well.

As far as I know this would follow the alias method quite closely and could use similar
syntax.

/marcel

>  From: cobbler-bounces(a)lists.fedorahosted.org [mailto:cobbler-
>  bounces(a)lists.fedorahosted.org] On Behalf Of Michael DeHaan
>  Sent: woensdag 24 september 2008 17:59
>  To: lists(a)davehatton.it; cobbler mailing list
>  Subject: Re: [PATCH] Generic interface support (was Re: Support for
>  bonding and other advanced networking topics)
>
>  Dave Hatton wrote:
>  >> This would mean --interface=X would either take ethN or bondN, if we
>  >> also support the bonding case, as opposed to a freeform string.
>  >>
>  >>
>  >>
>  > If you allow for --interface=X:Y  then this would allow for the
>  IPalias
>  > support discussed yesterday
>  >
>  > (eg: --interface=eth0:1 --ip=x.x.x.x --netmask=x.x.x.x)
>  >
>  > this should generate a standard ifcfg file under
>  > /etc/sysconfig/network-scripts but with a name like ifcfg-eth0:1
>  >
>  > dave
>  >
>  > _______________________________________________
>  > cobbler mailing list
>  > cobbler(a)lists.fedorahosted.org
>  > https://fedorahosted.org/mailman/listinfo/cobbler
>  >
>
>  Right now the interface name could be arbitrary, so it seems it would
>  only depend on the magic to set things up right in %post. Does anyone
>  care to take a shot at cleaning up the "post-network-system-config"
>  snippet on the Wiki now? We should make it account for mutliple
>  interfaces first, add it to %post in the default templates, and then we
>  can teach it about bonding once that is established.
>
>  (Also regarding my earlier web comments, this interface change may
>  prove
>  a reason enough to clean up the webapp in general --- adding
>  multi-interface support is going to be hand without making it more
>  ajaxy
>  anyway. This might make it a little longer between releases but could
>  make for some interesting things. Still evaluating -- I'll chase this
>  while everyone is looking at the networking details, we need them both)
>
>  --Michael
>  _______________________________________________
>  cobbler mailing list
>  cobbler(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/cobbler 

This e-mail and any attachment is for authorised use by the intended recipient(s) only. It
may contain proprietary material, confidential information and/or be subject to legal
privilege. It should not be copied, disclosed to, retained or used by, any other party. If
you are not an intended recipient then please promptly delete this e-mail and any
attachment and all copies and inform the sender. Thank you.

[PATCH] Generic interface support (was Re: Support for bonding and other advanced networking topics)

[Michael DeHaan]

John Eckersberg wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>  First and foremost, the bonding stuff discussed today sounds great and
>  is something that I'd be interested in helping with and using.
>
>  Before we dig too far into that, however, I want to post up something
>  I've been meaning to finish for the past month or so but just haven't
>  had the time to flesh it out completely.  I'd like to get it applied
>  (assuming others think it's a good patch :D) before we go tearing up the
>  interface code even more.
>
>  The attached patch adds support for generic interface names, and as a
>  side-effect allows an arbitrary number of interfaces to be assigned to a
>  system.  This work looks to be a pre-requisite for the bonding examples
>  anyways, so it should prove useful.
>
>  More information is available in the commit log of the patch.
>
>  As always, suggestions / gripes / feedback / patches are welcome!
>
>  - --
>  John Eckersberg
>  Systems Administrator, CIS
>  Red Hat, Inc.
>
> >  -----BEGIN PGP SIGNATURE-----
> >  Version: GnuPG v1.4.9 (GNU/Linux)
> >  Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> >
> >  iEYEARECAAYFAkjZlPIACgkQdxt4pd4ztYuBegCfTgcny9hdoLovwWD/UU+QPOwW
> >  QBEAoICMHcU/ji+0teuihbNitB1Pwr+k
> >  =ZuJ9
> >  -----END PGP SIGNATURE----- 
>    
>  ------------------------------------------------------------------------
>
>  _______________________________________________
>  cobbler mailing list
>  cobbler(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/cobbler 
Update:   I'll take a look at making the webapp do the infinite number 
of interfaces stuff today.

Better networking modelling/setup seems to be the new theme for 1.3 ...  
I assume "shiny webui upgrades (things like web-based search)" as a 
theme was not at the top of anyone's list, even so, it is still very 
much on the radar/roadmap.

We definitely do spend more time on things that get patches coming in, 
so it makes sense to spend time here where there is interest.   Thanks 
to everyone for the recent interest, ideas, and patches on the 
networking features.  

--Michael