dhcp.template and multiple subnets

hi,
just noticed an issue when you define multiple subnets in 
dhcp.template.  it seems that if you have setup your template file to 
use mutiple subnets dhpcd will fail to start unless you have tagged a 
system to live on one of the secondary subnets.  for example take this 
dhcp.template:

subnet 172.30.214.0 netmask 255.255.255.0 {
...
}

$insert_cobbler_system_definitions

subnet 172.30.206.0 netmask 255.255.255.0 {
...
}

$insert_cobbler_system_definitions_abq

restarting dhcpd (or running cobbler sync) will fail due to the fact 
that "$insert_cobbler_system_definitions_abq" will litterally end up in 
/etc/dhpcd.conf.  once you tag a system to use the secondary subnet (in 
this case --dhcp-tag=abq) the $insert_cobbler... variable is expanded 
correctly and dhcp restarts as expected.

i am not sure if anyone else has run into this, or if this issue can we 
worked around (i am not too familiar with how template's).

-pete

ARP failing when I ping from host to guest

I'm running x86_64 Fedora7 host and 32 bit Fedora 7 guest on KVM. Here
what the default bridged network setting gave me -

HOST -

[root fed-amd64 ~]# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:1A:A0:56:52:E5
         inet addr:192.168.1.9  Bcast:192.168.1.255  Mask:255.255.255.0
         inet6 addr: fe80::21a:a0ff:fe56:52e5/64 Scope:Link
         UP BROADCAST RUNNING MULTICAST  MTU:1492  Metric:1
         RX packets:4144 errors:0 dropped:0 overruns:0 frame:0
         TX packets:4490 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:1000
         RX bytes:3143529 (2.9 MiB)  TX bytes:1026716 (1002.6 KiB)
         Interrupt:23 Base address:0x6000

lo        Link encap:Local Loopback
         inet addr:127.0.0.1  Mask:255.0.0.0
         inet6 addr: ::1/128 Scope:Host
         UP LOOPBACK RUNNING  MTU:16436  Metric:1
         RX packets:11074 errors:0 dropped:0 overruns:0 frame:0
         TX packets:11074 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:0
         RX bytes:49074613 (46.8 MiB)  TX bytes:49074613 (46.8 MiB)

virbr0    Link encap:Ethernet  HWaddr 00:FF:EE:14:6D:91
         inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
         inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
         RX packets:61 errors:0 dropped:0 overruns:0 frame:0

Re: ARP failing when I ping from host to guest

> To be more specific, I'm doing a tcpdump on guest's
> eth0(192.168.122.195). When the host pings 192.168.122.195, I see
> following -
>
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
> 12:15:49.058031 arp who-has 192.168.122.195 tell 192.168.122.1
> 12:15:51.065437 arp who-has 192.168.122.195 tell 192.168.122.1
> 12:15:52.069123 arp who-has 192.168.122.195 tell 192.168.122.1
> 12:15:53.071852 arp who-has 192.168.122.195 tell 192.168.122.1
> 12:15:55.077218 arp who-has 192.168.122.195 tell 192.168.122.1
>
> When the guest's eth0 is receiving ARP for it's right IP address, why
> is it not responding?
>
I also tried creating new virtual networks with virt-manager as both
"Isolated virtual network" and "Forwarding to physical network". Each
time I ping the host's virtual interface which is on the same subnet
as the guest's eth0, it fails. On doing a tcpdump on host's virtual
interface(vnet2), I see that the guest's ARP *is* coming through, but
the host is unable to resolve guest's eth0 IP (192.168.99.128 below).
Host's virtual IP is 192.168.99.1.

[root <at> fed-amd64 ~]# tcpdump -i vnet2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vnet2, link-type EN10MB (Ethernet), capture size 96 bytes
01:24:52.588689 arp who-has 192.168.99.128 tell 192.168.99.1
01:24:53.588448 arp who-has 192.168.99.128 tell 192.168.99.1
01:24:54.588226 arp who-has 192.168.99.128 tell 192.168.99.1

Re: ARP failing when I ping from host to guest

On Nov 4, 2007 1:37 AM, kewlemer <kewlemer@...> wrote:
> > To be more specific, I'm doing a tcpdump on guest's
> > eth0(192.168.122.195). When the host pings 192.168.122.195, I see
> > following -
> >
> > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> > listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
> > 12:15:49.058031 arp who-has 192.168.122.195 tell 192.168.122.1
> > 12:15:51.065437 arp who-has 192.168.122.195 tell 192.168.122.1
> > 12:15:52.069123 arp who-has 192.168.122.195 tell 192.168.122.1
> > 12:15:53.071852 arp who-has 192.168.122.195 tell 192.168.122.1
> > 12:15:55.077218 arp who-has 192.168.122.195 tell 192.168.122.1
> >
> > When the guest's eth0 is receiving ARP for it's right IP address, why
> > is it not responding?
> >

Sorry for the confusion, now on doing tcpdump on guest's eth0, I saw
that the guest receives host's ARP response (for it's 192.168.99.1),
but is NOT receiving the host's ARP requests  ("who-has 192.168.99.128
tell 192.168.99.1").

> I also tried creating new virtual networks with virt-manager as both
> "Isolated virtual network" and "Forwarding to physical network". Each
> time I ping the host's virtual interface which is on the same subnet
> as the guest's eth0, it fails. On doing a tcpdump on host's virtual
> interface(vnet2), I see that the guest's ARP *is* coming through, but
> the host is unable to resolve guest's eth0 IP (192.168.99.128 below).
> Host's virtual IP is 192.168.99.1.
>

cobbler git: multiple interfaces + hostnames

For those who aren't tracking the git version of cobbler, it includes
support for multiple interfaces.

Currently, cobbler has a "hostname" field for every interface.   This
is confusing and incorrect.   Every host has exactly one hostname, so
"hostname" should be a system field.    It may make sense to change
hostname in the interfaces to dns_name, alias, or something similar,
but it is not a hostname.   If I were crafting the tool towards my
specific situation, I'd drop "name" and just have "hostname" on the
system, then optional support for dns names on interfaces (which I
could then forward into DNS).

If I weren't already working on authorization support, I'd write the
patch ;)   That and I think this may require a little discussion
before the right approach shakes out.

-Al

cobbler git: multiple interface system edit cleanup

I got distracted by the multiple interface system edit screen and
decided to clean it up a bit.   A patch and partial screenshot are
attached.

The javascript is a lot less complex.   The screen looks a lot more
useable for the common case now.    The help text is hidden for
interfaces > 0, which saves a ton of vertical space.   Each interface
is in its own fieldset element now, which groups it better IMO.
Configured interfaces are displayed by default.

I took out the image-based +/- for now, but it can go back if people
really like it better.   I only changed it to simplify things while
hacking.  Most of the stuff in cobbler.js can go away if this approach
is taken instead.

-Al

diff --git a/webui_templates/system_edit.tmpl b/webui_templates/system_edit.tmpl
index 83d5908..baa584d 100644
--- a/webui_templates/system_edit.tmpl
+++ b/webui_templates/system_edit.tmpl
@@ -12,12 +12,47 @@

 <script language="javascript">

+function toggle_vis(target, num, display)
+{
+    t = document.getElementById(target + num);
+    c = document.getElementById('control' + num);

cobbler support for users & tags

The attached patch is the first step towards an authorization system
for cobbler.    It only adds tags for systems and user support.   The
tags do nothing yet, but will come into play with later patches.

Michael, you can apply if you want or do the sensible thing and wait
until this does something useful.    I'll try to push my branch to the
public repository later if people want to try that rather than
patches.

The authorization support I have in mind uses these generic tags to
grant users access to systems and profiles.     I think profiles will
have inheritable tags, but will not be editable by non-superuser
users, since this is probably what most people want.    Basically, if
a user has a tag that a system (or its upstream profile(s)) also has,
they have r/w access.   Otherwise, it's a deny-all policy.    Users
can be granted superuser access with the --superuser flag which is
only available on the CLI for now.

It looks like it will be really easy to support authorization in both
the webui and CLI.   The CLI support will come via sudo and its
SUDO_USER environment variable.   That way users can be given access
to run the CLI as root, but only for given systems.   It will be up to
each sysadmin out there to determine whether they want to risk giving
sudo access to cobbler as root and trust cobbler's code.

I'm definitely open to discussion about how the authorization stuff
plays out.   Right now I'm sticking to the KISS principle and trying
to keep things very flexible.

-Al

Re: et-mgmt-tools Digest, Vol 15, Issue 4

On Sun, 2007-11-04 at 19:19 -0500, et-mgmt-tools-request@...
wrote:
> Send et-mgmt-tools mailing list submissions to
> 	et-mgmt-tools@...
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www.redhat.com/mailman/listinfo/et-mgmt-tools
> or, via email, send a message with subject or body 'help' to
> 	et-mgmt-tools-request@...
> 
> You can reach the person managing the list at
> 	et-mgmt-tools-owner@...
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of et-mgmt-tools digest..."
> 
> 
> Today's Topics:
> 
>    1. cobbler support for users & tags (Al Tobey)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Sun, 4 Nov 2007 16:19:19 -0800
> From: "Al Tobey" <tobert@...>
> Subject: [et-mgmt-tools] cobbler support for users & tags
> To: "Michael DeHaan" <mdehaan@...>,	"Fedora/Linux Management

Re: dhcp.template and multiple subnets

Peter Wright wrote:
> hi,
> just noticed an issue when you define multiple subnets in 
> dhcp.template.  it seems that if you have setup your template file to 
> use mutiple subnets dhpcd will fail to start unless you have tagged a 
> system to live on one of the secondary subnets.  for example take this 
> dhcp.template:
>
> subnet 172.30.214.0 netmask 255.255.255.0 {
> ...
> }
>
> $insert_cobbler_system_definitions
>
> subnet 172.30.206.0 netmask 255.255.255.0 {
> ...
> }
>
> $insert_cobbler_system_definitions_abq
>
>
>
> restarting dhcpd (or running cobbler sync) will fail due to the fact 
> that "$insert_cobbler_system_definitions_abq" will litterally end up 
> in /etc/dhpcd.conf.  once you tag a system to use the secondary subnet 
> (in this case --dhcp-tag=abq) the $insert_cobbler... variable is 
> expanded correctly and dhcp restarts as expected.
>
> i am not sure if anyone else has run into this, or if this issue can 
> we worked around (i am not too familiar with how template's).

Re: cobbler git: multiple interfaces + hostnames

Al Tobey wrote:
> For those who aren't tracking the git version of cobbler, it includes
> support for multiple interfaces.
>
> Currently, cobbler has a "hostname" field for every interface.   This
> is confusing and incorrect.   Every host has exactly one hostname, so
> "hostname" should be a system field.    It may make sense to change
> hostname in the interfaces to dns_name, alias, or something similar,
> but it is not a hostname.   If I were crafting the tool towards my
> specific situation, I'd drop "name" and just have "hostname" on the
> system, then optional support for dns names on interfaces (which I
> could then forward into DNS).
>   

Each interface (say we have AA:BB:CC:DD:EE:EE, AA:BB:CC:DD:EE:FF) can be 
handed
a seperate IP (say 192.168.1.50, 192.168.151) and then we can give those 
IPs different names in DNS.

So, if I understand correctly, this is just a discussion on the name of 
the field?

--Michael