From wright at imageworks.com Fri Nov 2 18:35:34 2007 From: wright at imageworks.com (Peter Wright) Date: Fri, 02 Nov 2007 11:35:34 -0700 Subject: [et-mgmt-tools] dhcp.template and multiple subnets Message-ID: <472B6DF6.6020907@imageworks.com> 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 -- Peter Wright Systems Engineer Sony Pictures Imageworks wright at imageworks.com www.imageworks.com From kewlemer at gmail.com Sun Nov 4 01:23:53 2007 From: kewlemer at gmail.com (kewlemer) Date: Sat, 3 Nov 2007 18:23:53 -0700 Subject: [et-mgmt-tools] ARP failing when I ping from host to guest Message-ID: <79cbe6750711031823n686010dct987d164934a98910@mail.gmail.com> 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 TX packets:86 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:9261 (9.0 KiB) TX bytes:12220 (11.9 KiB) vnet0 Link encap:Ethernet HWaddr 00:FF:EE:14:6D:91 inet6 addr: fe80::2ff:eeff:fe14:6d91/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:61 errors:0 dropped:0 overruns:0 frame:0 TX packets:61 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:10115 (9.8 KiB) TX bytes:7195 (7.0 KiB) [root fed-amd64 ~]# Here is what the GUEST landed up with when using the default configuration- [root fed-guest ~]# ifconfig eth0 Link encap:Ethernet HWaddr 00:16:3E:6B:C6:36 inet addr:192.168.122.195 Bcast:192.168.122.255 Mask:255.255.255.0 inet6 addr: fe80::216:3eff:fe6b:c636/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:00:00:00:00:00 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 TX packets:86 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:9261 (9.0 KiB) TX bytes:12220 (11.9 KiB) [root fed-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? Here are the routing tables - HOST- [root fed-amd64 ~]# netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0 [root fed-amd64 ~]# GUEST- [root guest~]# netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 0.0.0.0 192.168.122.1 0.0.0.0 UG 0 0 0 eth0 [root guest ~]# The problem is that I'm unable to ping from the host to the guest (to 192.168.122.195). tcpdump shows that guest is not responding to ARPs for 192.168.122.195. Can anyone tell me why? I can ping the host's eth0 from the guest though. Are my eth0 and virbr0 settings correct? I see that the hw address of virbr0 of guest is 0, while that of host is non-0 - is that alright? Note that I have iptables and SELinux turned off. The found these references, but unfortunately they went of help in my case - http://watzmann.net/blog/index.php/2007/04/27/networking_with_kvm_and_libvirt http://www.gnome.org/~markmc/virtual-networking.html The other thing I tried was to have a tun/tap driver like UML. So I set up tap0 on the host as 10.90.93.1. Then I changed eth0 of QEMU-KVM guest to 10.90.93.50. Then again the ARP response from the guest failed. Here are the relevant details - HOST- [root at fed-amd64 ~]# netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.90.93.50 0.0.0.0 255.255.255.255 UH 0 0 0 tap0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0 [root at fed-amd64 ~]# [root at fed-amd64 ~]# arp -a ? (192.168.1.1) at 00:E0:98:53:63:0E [ether] on eth0 [root at fed-amd64 ~]# //note that it's not seeing 10.90.93.50 since the guest is not responding GUEST- root at guest ~]# netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.90.93.0 0.0.0.0 255.255.255.255 U 0 0 0 eth0 0.0.0.0 10.90.93.1 0.0.0.0 UG 0 0 0 eth0 [root at guest ~]# [root at guest]# arp -a [root at guest]# tcpdump dump on tap0 shows that the host is not getting the ARP response for 10.90.93.50. However when a do a tcpdump on eth0 of host, it's not receiving the pings at all. Can anyone tell me what I'm missing in this case. Any pointers greatly appreciated. Thanks in advance, KM From kewlemer at gmail.com Sun Nov 4 08:37:06 2007 From: kewlemer at gmail.com (kewlemer) Date: Sun, 4 Nov 2007 01:37:06 -0700 Subject: [et-mgmt-tools] Re: ARP failing when I ping from host to guest In-Reply-To: <79cbe6750711031823n686010dct987d164934a98910@mail.gmail.com> References: <79cbe6750711031823n686010dct987d164934a98910@mail.gmail.com> Message-ID: <79cbe6750711040137k3a3955aagd88a7453c3dc184@mail.gmail.com> > 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 Like before it's failing on the ARP. Any pointers greatly appreciated. Thanks, KM From kewlemer at gmail.com Sun Nov 4 09:05:54 2007 From: kewlemer at gmail.com (kewlemer) Date: Sun, 4 Nov 2007 02:05:54 -0700 Subject: [et-mgmt-tools] Re: ARP failing when I ping from host to guest In-Reply-To: <79cbe6750711040137k3a3955aagd88a7453c3dc184@mail.gmail.com> References: <79cbe6750711031823n686010dct987d164934a98910@mail.gmail.com> <79cbe6750711040137k3a3955aagd88a7453c3dc184@mail.gmail.com> Message-ID: <79cbe6750711040105w7da4ac17n28810a86bbe4782e@mail.gmail.com> On Nov 4, 2007 1:37 AM, 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. > > [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 > > This observation is still valid. Looks like I'm missing something basic. Any pointers? Thanks, KM From tobert at gmail.com Sun Nov 4 20:35:16 2007 From: tobert at gmail.com (Al Tobey) Date: Sun, 4 Nov 2007 12:35:16 -0800 Subject: [et-mgmt-tools] cobbler git: multiple interfaces + hostnames Message-ID: <5ac7acb10711041235s63c333acxc0510d93ce4d6013@mail.gmail.com> 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 From tobert at gmail.com Sun Nov 4 22:03:41 2007 From: tobert at gmail.com (Al Tobey) Date: Sun, 4 Nov 2007 14:03:41 -0800 Subject: [et-mgmt-tools] cobbler git: multiple interface system edit cleanup Message-ID: <5ac7acb10711041403q7a304fc6jc3551f8a237cf686@mail.gmail.com> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: system_edit-cleanup.diff Type: text/x-patch Size: 13435 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cobbler-system-interfaces-tobeya.jpg Type: image/jpeg Size: 67180 bytes Desc: not available URL: From tobert at gmail.com Mon Nov 5 00:19:19 2007 From: tobert at gmail.com (Al Tobey) Date: Sun, 4 Nov 2007 16:19:19 -0800 Subject: [et-mgmt-tools] cobbler support for users & tags Message-ID: <5ac7acb10711041619l4028a85fk29fb8a571af3a049@mail.gmail.com> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-users-and-tags.patch Type: text/x-patch Size: 57805 bytes Desc: not available URL: From dan.dengate at cern.ch Mon Nov 5 07:54:07 2007 From: dan.dengate at cern.ch (Dan Dengate) Date: Mon, 05 Nov 2007 08:54:07 +0100 Subject: [et-mgmt-tools] Re: et-mgmt-tools Digest, Vol 15, Issue 4 In-Reply-To: <20071105001927.28F3172FED@hormel.redhat.com> References: <20071105001927.28F3172FED@hormel.redhat.com> Message-ID: <1194249247.6421.1.camel@slinky> On Sun, 2007-11-04 at 19:19 -0500, et-mgmt-tools-request at redhat.com wrote: > Send et-mgmt-tools mailing list submissions to > et-mgmt-tools at redhat.com > > 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 at redhat.com > > You can reach the person managing the list at > et-mgmt-tools-owner at redhat.com > > 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" > Subject: [et-mgmt-tools] cobbler support for users & tags > To: "Michael DeHaan" , "Fedora/Linux Management > Tools" > Message-ID: > <5ac7acb10711041619l4028a85fk29fb8a571af3a049 at mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > 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. ...any tips for persuading others that this is ok? > > 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 > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: 0001-Add-users-and-tags.patch > Type: text/x-patch > Size: 57804 bytes > Desc: not available > Url : https://www.redhat.com/archives/et-mgmt-tools/attachments/20071104/a3248fd9/0001-Add-users-and-tags.bin > > ------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > End of et-mgmt-tools Digest, Vol 15, Issue 4 > ******************************************** From mdehaan at redhat.com Mon Nov 5 17:04:55 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 05 Nov 2007 12:04:55 -0500 Subject: [et-mgmt-tools] dhcp.template and multiple subnets In-Reply-To: <472B6DF6.6020907@imageworks.com> References: <472B6DF6.6020907@imageworks.com> Message-ID: <472F4D37.8010104@redhat.com> 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). > > -pete > > This would work... I'll add it to the Wiki. #if $getVar("insert_cobbler_system_definitions_abq","none") != "none" subnet 172.30.206.0 netmask 255.255.255.0 { ... } $insert_cobbler_system_definitions_abq #end if From mdehaan at redhat.com Mon Nov 5 17:08:49 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 05 Nov 2007 12:08:49 -0500 Subject: [et-mgmt-tools] cobbler git: multiple interfaces + hostnames In-Reply-To: <5ac7acb10711041235s63c333acxc0510d93ce4d6013@mail.gmail.com> References: <5ac7acb10711041235s63c333acxc0510d93ce4d6013@mail.gmail.com> Message-ID: <472F4E21.7070204@redhat.com> 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 From mdehaan at redhat.com Mon Nov 5 17:27:03 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 05 Nov 2007 12:27:03 -0500 Subject: [et-mgmt-tools] cobbler git: multiple interface system edit cleanup In-Reply-To: <5ac7acb10711041403q7a304fc6jc3551f8a237cf686@mail.gmail.com> References: <5ac7acb10711041403q7a304fc6jc3551f8a237cf686@mail.gmail.com> Message-ID: <472F5267.2000707@redhat.com> Al Tobey wrote: > 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. Nice... I do like the boxes and not repeating the tooltips for the later interfaces. > 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. > Well, Cobbler.js is going to stay. The point is to get the javascript code pulled out of the templates as much as possible, so it can be read all in one place, and we don't have things copy/pasted everywhere when they are more generically useful. Ideally the javascript code in this patch would be moved there. A few things I'd like to see done before I can apply this: -- Have you tested this in MSIE? -- Put back the +/- graphics -- Fix mixed tabs/spaces Thanks! --Michael > -Al > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From mdehaan at redhat.com Mon Nov 5 17:37:48 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 05 Nov 2007 12:37:48 -0500 Subject: [et-mgmt-tools] Re: cobbler support for users & tags In-Reply-To: <5ac7acb10711041619l4028a85fk29fb8a571af3a049@mail.gmail.com> References: <5ac7acb10711041619l4028a85fk29fb8a571af3a049@mail.gmail.com> Message-ID: <472F54EC.7020502@redhat.com> Al Tobey wrote: > 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 > I'm wanting to work with the FreeIPA folks some rather than build a lot of infrastructure ourselves here. http://freeipa.org/page/Main_Page -- which is on my list to investigate more fully in the coming weeks. We probably do want to keep the user/group requirements stored in Cobbler, but how that plays out in the greater whole I am not entirely sure yet. Keeping things in generic tags is a good way to keep options open, though I'm hesitant to implement a Cobbler-specific auth model at this point, given we can possibly leverage other projects and the RFE list is already quite large. I really would like to see more of those core items dealt with first. (https://hosted.fedoraproject.org/projects/cobbler/report/) A good suggestion submitted by others would be to have a way to request a Cobbler edit through the the WebUI and be able to have an admin level user approve it. This may imply a slightly variant CGI that allows users to pick a system or create a new one and have their edits go into a queue. That sort of approach may also keep us from having to build/maintain a lot of auth/user/group infrastructure. --Michael From mdehaan at redhat.com Mon Nov 5 17:54:29 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 05 Nov 2007 12:54:29 -0500 Subject: [et-mgmt-tools] dhcp.template and multiple subnets In-Reply-To: <472F4D37.8010104@redhat.com> References: <472B6DF6.6020907@imageworks.com> <472F4D37.8010104@redhat.com> Message-ID: <472F58D5.4000504@redhat.com> Michael DeHaan wrote: > 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). >> >> -pete >> >> > > This would work... I'll add it to the Wiki. > > #if $getVar("insert_cobbler_system_definitions_abq","none") != "none" > subnet 172.30.206.0 netmask 255.255.255.0 { > ... > } > $insert_cobbler_system_definitions_abq > #end if > > > > > > Small tweak: #if $getVar("insert_cobbler_system_definitions_abq","") != "" subnet 172.30.206.0 netmask 255.255.255.0 { ... } $insert_cobbler_system_definitions_abq #end if From wright at imageworks.com Mon Nov 5 17:36:10 2007 From: wright at imageworks.com (Peter Wright) Date: Mon, 05 Nov 2007 09:36:10 -0800 Subject: [et-mgmt-tools] dhcp.template and multiple subnets In-Reply-To: <472F58D5.4000504@redhat.com> References: <472B6DF6.6020907@imageworks.com> <472F4D37.8010104@redhat.com> <472F58D5.4000504@redhat.com> Message-ID: <472F548A.2070506@imageworks.com> Michael DeHaan wrote: > Michael DeHaan wrote: > >> 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). >>> >>> -pete >>> >>> >>> >> This would work... I'll add it to the Wiki. >> >> #if $getVar("insert_cobbler_system_definitions_abq","none") != "none" >> subnet 172.30.206.0 netmask 255.255.255.0 { >> ... >> } >> $insert_cobbler_system_definitions_abq >> #end if >> >> >> >> >> >> >> > Small tweak: > > #if $getVar("insert_cobbler_system_definitions_abq","") != "" > subnet 172.30.206.0 netmask 255.255.255.0 { > ... > } > $insert_cobbler_system_definitions_abq > #end if > > > awesome, thanks! i'll give this a go later today. -pete -- Peter Wright Systems Engineer Sony Pictures Imageworks wright at imageworks.com www.imageworks.com From kewlemer at gmail.com Mon Nov 5 17:58:56 2007 From: kewlemer at gmail.com (kewlemer) Date: Mon, 5 Nov 2007 09:58:56 -0800 Subject: [et-mgmt-tools] Re: ARP failing when I ping from host to guest In-Reply-To: <79cbe6750711040105w7da4ac17n28810a86bbe4782e@mail.gmail.com> References: <79cbe6750711031823n686010dct987d164934a98910@mail.gmail.com> <79cbe6750711040137k3a3955aagd88a7453c3dc184@mail.gmail.com> <79cbe6750711040105w7da4ac17n28810a86bbe4782e@mail.gmail.com> Message-ID: <79cbe6750711050958h40c375b0ge15d8743353feb0e@mail.gmail.com> On 11/4/07, kewlemer wrote: > On Nov 4, 2007 1:37 AM, 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. > > > > [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 > > > > > This observation is still valid. Looks like I'm missing something > basic. Any pointers? > I've posted this question on xen-list, kvm-list and this list and havent gotten a single response. So I don't know if I'm posting this question on the wrong forum, or if I haven't done my homework (I've spent a day on this). Can anyone at least tell me if there is a better forum to post my question ? Can anyone using KVM-QEMU post their ifconfig and netstat -rn output - I'll check against mine ? Thanks, KM From fj1826dm at aa.jp.fujitsu.com Tue Nov 6 00:05:20 2007 From: fj1826dm at aa.jp.fujitsu.com (Masayuki Sunou) Date: Tue, 6 Nov 2007 09:05:20 +0900 Subject: [et-mgmt-tools] [PATCH] Strengthen port number validation Message-ID: <200711060905.EDH87533.7NEG9K32@aa.jp.fujitsu.com> Hi Installation fails when port number used by other processes is set to --vncport of virt-install, because graphical console is not displayed. The same problem occurs when port number exceeds upper bound. One of patches fixes to request re-input when port number used is set. --> check_vncport_used.patch Other fixes to output error message when port number exceeds upper bound. --> check_vncport_upperbound.patch Signed-off-by: Masayuki Sunou Thanks, Masayuki Sunou. -------------- next part -------------- A non-text attachment was scrubbed... Name: check_vncport_upperbound.patch Type: application/octet-stream Size: 710 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: check_vncport_used.patch Type: application/octet-stream Size: 1867 bytes Desc: not available URL: From tobert at gmail.com Tue Nov 6 20:37:53 2007 From: tobert at gmail.com (Al Tobey) Date: Tue, 6 Nov 2007 12:37:53 -0800 Subject: [et-mgmt-tools] cobbler git: multiple interface system edit cleanup In-Reply-To: <472F5267.2000707@redhat.com> References: <5ac7acb10711041403q7a304fc6jc3551f8a237cf686@mail.gmail.com> <472F5267.2000707@redhat.com> Message-ID: <5ac7acb10711061237p30dd14acr2df12396f93fcd9c@mail.gmail.com> On 11/5/07, Michael DeHaan wrote: > Al Tobey wrote: > > 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. > Nice... > > I do like the boxes and not repeating the tooltips for the later interfaces. > > > 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. > > > > Well, Cobbler.js is going to stay. The point is to get the javascript > code pulled out of the templates > as much as possible, so it can be read all in one place, and we don't > have things copy/pasted everywhere > when they are more generically useful. Ideally the javascript code in > this patch would be moved there. > > A few things I'd like to see done before I can apply this: > > -- Have you tested this in MSIE? > -- Put back the +/- graphics > -- Fix mixed tabs/spaces New patch attached. I only tested IE7 which was horribly broken. I think the
's were defaulting to width="100%" or something, making the left nav bar width 100%. I forced the div containing the nav bar to 200px in the CSS which seems to have brought it under control. -Al > > Thanks! > > --Michael > > > > -Al > > > > ------------------------------------------------------------------------ > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > et-mgmt-tools mailing list > > et-mgmt-tools at redhat.com > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From tobert at gmail.com Tue Nov 6 20:43:48 2007 From: tobert at gmail.com (Al Tobey) Date: Tue, 6 Nov 2007 12:43:48 -0800 Subject: [et-mgmt-tools] cobbler git: multiple interface system edit cleanup In-Reply-To: <5ac7acb10711061237p30dd14acr2df12396f93fcd9c@mail.gmail.com> References: <5ac7acb10711041403q7a304fc6jc3551f8a237cf686@mail.gmail.com> <472F5267.2000707@redhat.com> <5ac7acb10711061237p30dd14acr2df12396f93fcd9c@mail.gmail.com> Message-ID: <5ac7acb10711061243i2034e761l7cc1cc5f2476fc5b@mail.gmail.com> Now with attachments! On 11/6/07, Al Tobey wrote: > On 11/5/07, Michael DeHaan wrote: > > Al Tobey wrote: > > > 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. > > Nice... > > > > I do like the boxes and not repeating the tooltips for the later interfaces. > > > > > 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. > > > > > > > Well, Cobbler.js is going to stay. The point is to get the javascript > > code pulled out of the templates > > as much as possible, so it can be read all in one place, and we don't > > have things copy/pasted everywhere > > when they are more generically useful. Ideally the javascript code in > > this patch would be moved there. > > > > A few things I'd like to see done before I can apply this: > > > > -- Have you tested this in MSIE? > > -- Put back the +/- graphics > > -- Fix mixed tabs/spaces > > New patch attached. > > I only tested IE7 which was horribly broken. I think the
's > were defaulting to width="100%" or something, making the left nav bar > width 100%. I forced the div containing the nav bar to 200px in the > CSS which seems to have brought it under control. > > -Al > > > > > Thanks! > > > > --Michael > > > > > > > -Al > > > > > > ------------------------------------------------------------------------ > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > et-mgmt-tools mailing list > > > et-mgmt-tools at redhat.com > > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > > > _______________________________________________ > > et-mgmt-tools mailing list > > et-mgmt-tools at redhat.com > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Rework-system-edit-webui-screen.patch Type: text/x-patch Size: 24183 bytes Desc: not available URL: From dpaulo at fedoraproject.org Wed Nov 7 19:21:24 2007 From: dpaulo at fedoraproject.org (Davidson Rodrigues Paulo) Date: Wed, 7 Nov 2007 17:21:24 -0200 Subject: [et-mgmt-tools] Installing CentOS Xen domU on a Fedora 7 dom0 via virt-manager In-Reply-To: References: Message-ID: Hi, I'm trying to install a CentOS domU on my Fedora 7 dom0 using virt-manager, but when I click "Finish" I get the following error: Unable to complete install ' Invalid file location given: No such file or directory Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/create.py", line 681, in do_install dom = guest.start_install(False, meter = meter) File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line 706, in start_install self._prepare_install(meter) File "/usr/lib/python2.5/site-packages/virtinst/ParaVirtGuest.py", line 45, in _prepare_install self._installer.prepare(guest = self, meter = meter) File "/usr/lib/python2.5/site-packages/virtinst/DistroManager.py", line 678, in prepare self._prepare_kernel_and_initrd(guest, distro, meter) File "/usr/lib/python2.5/site-packages/virtinst/DistroManager.py", line 648, in _prepare_kernel_and_initrd distro = distro) File "/usr/lib/python2.5/site-packages/virtinst/DistroManager.py", line 578, in acquireKernel progresscb=progresscb, distro=distro, scratchdir=scratchdir) File "/usr/lib/python2.5/site-packages/virtinst/DistroManager.py", line 561, in _storeForDistro if store.isValidStore(fetcher, progresscb): File "/usr/lib/python2.5/site-packages/virtinst/DistroManager.py", line 213, in isValidStore if fetcher.hasFile("Fedora", progresscb): File "/usr/lib/python2.5/site-packages/virtinst/DistroManager.py", line 160, in hasFile tmpfile = self.acquireFile(filename, progresscb) File "/usr/lib/python2.5/site-packages/virtinst/DistroManager.py", line 150, in acquireFile raise ValueError, _("Invalid file location given: ") + msg ValueError: Invalid file location given: No such file or directory ' This is a bug or it's not possible install CentOS domU via virt-manager? My packages: * virt-manager-0.4.0-2.fc7 * xen-3.1.0-6.fc7 * kernel-xen-2.6.20-2936.fc7 Thanks, -- Davidson Paulo http://fedoraproject.org/wiki/DavidsonPaulo From clalance at redhat.com Wed Nov 7 19:30:37 2007 From: clalance at redhat.com (Chris Lalancette) Date: Wed, 07 Nov 2007 14:30:37 -0500 Subject: [et-mgmt-tools] Installing CentOS Xen domU on a Fedora 7 dom0 via virt-manager In-Reply-To: References: Message-ID: <4732125D.4090100@redhat.com> Davidson Rodrigues Paulo wrote: > tmpfile = self.acquireFile(filename, progresscb) > File "/usr/lib/python2.5/site-packages/virtinst/DistroManager.py", > line 150, in acquireFile > raise ValueError, _("Invalid file location given: ") + msg > ValueError: Invalid file location given: No such file or directory > ' > > This is a bug or it's not possible install CentOS domU via virt-manager? This is a bug. See https://bugzilla.redhat.com/show_bug.cgi?id=325591, where we fixed this for Rawhide. Please clone that bug for Fedora-7 so we can fix it there. Thanks, Chris Lalancette From dpaulo at fedoraproject.org Wed Nov 7 19:53:07 2007 From: dpaulo at fedoraproject.org (Davidson Rodrigues Paulo) Date: Wed, 7 Nov 2007 17:53:07 -0200 Subject: [et-mgmt-tools] Installing CentOS Xen domU on a Fedora 7 dom0 via virt-manager In-Reply-To: References: <4732125D.4090100@redhat.com> Message-ID: 2007/11/7, Chris Lalancette : > This is a bug. See https://bugzilla.redhat.com/show_bug.cgi?id=325591, where we > fixed this for Rawhide. Please clone that bug for Fedora-7 so we can fix it there. Done. Take a look and see if it's all right. * https://bugzilla.redhat.com/show_bug.cgi?id=370221 Thanks, -- Davidson Paulo http://fedoraproject.org/wiki/DavidsonPaulo From mdehaan at redhat.com Wed Nov 7 21:12:59 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 07 Nov 2007 16:12:59 -0500 Subject: [et-mgmt-tools] [ANNOUNCE] Cobbler 0.6.3 and Koan 0.6.3 Message-ID: <47322A5B.2010304@redhat.com> Hi, It's time to release Cobbler 0.6.3 and Koan 0.6.3! I've already uploaded the RPMs, and will have everything added to the build system (and various yum repositories) shortly. http://cobbler.et.redhat.com/download/cobbler-0.6.3-2.src.rpm http://cobbler.et.redhat.com/download/koan-0.6.3-2.src.rpm The main change in this release is the much-requested ability to represent multiple network interfaces. This works with Cobbler's DHCP management features as well as for virtual installs. The syntax remains basically as before, though now there are options like --ip1, --ip2, to supplement the existing --ip arguments and so on. This should be more clear by looking at the Web UI. Cobbler will automatically migrate the configuration files over to support this when you install/upgrade. (The old copies are saved in a directory in /var/lib/cobbler). All templates will continue to work, so things like $ip_address work as before, though you can also say things like $ip_address_intf1 to get the data for additional interfaces in your templates. For those folks who were using the Web UI, it now uses htaccess control for users, which allows for plugging into multiple authentication systems. The setup changes are documented in the manpage and on the Cobbler Wiki: https://hosted.fedoraproject.org/projects/cobbler/wiki/CobblerWebUi In addition, there are some new parameters useful for when a Cobbler install must manage multiple networks where the server address might change, which don't apply to everyone, but are detailed here: https://hosted.fedoraproject.org/projects/cobbler/wiki/MultipleCobblerServerAddresses . It's rather obscure but useful if you need it. As a side effect of the above change, the way we generate yum configurations from cobbler is now much more dynamic, making it much easier to host a cobbler server on a laptop (or equivalent) that changes addresses often. (Basically all the yum repository config files are now templatized so the server addresses are no longer hard coded). You'll probably want to run cobbler reposync (if you are using that feature) and then a cobbler sync to generate the config files. I've copied the full changelogs for cobbler and koan below. Because of the new way interfaces are handled, you will need to upgrade koan to work with the new cobbler. Thanks once again to everyone who made this release possible by testing, sharing ideas, and contributing patches. As the list of open RFE's is growing quite large, and there are are a lot of excellent suggestions there, I want to spend most of the next few releases knocking out many of these requests and ideas. As always, if you have ideas for features, please share. --Michael Cobbler 0.6.3 Changelog - Be able to define and use Multiple NICs per system - Add --virt-cpus to profile editing - Fix bug where WUI (XMLRPC) auth wasn't supported on EL4 - Add --virt-bridge to profile editing and NICs - Added serializer_shelve (as option) for added performance/persistance over YAML, experimental in /etc/cobbler/modules.conf, see Wiki - Backup state files and migrate state structures upon RPM upgrade - Added some more redundant files (for unsupported distros) to the rsync.exclude file - added pre-sync and post-sync triggers, service restarts are now handled by /var/lib/cobbler/triggers - webui now uses htaccess (see manpage and Wiki for setup instructions) - added pagination to the WUI to keep pages from growing overly long - added --server-override parameter for help with multi-subnet configurations (also see Wiki) - removed yum-utils as a hard requirement, cobbler check now looks for yum-utils - fixed bug where cobbler would try to copy hardlinks to themselves during sync - misc random bugfixing * Tue Nov 07 2007 Michael DeHaan - 0.6.3-2 - Multiple NIC support - Added traceback print to detect bridge connection problems, if any - Use --virt-cpu setting from Cobbler - Misc bugfixing From crobinso at redhat.com Wed Nov 7 21:44:29 2007 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 07 Nov 2007 16:44:29 -0500 Subject: [et-mgmt-tools] [PATCH] Strengthen port number validation In-Reply-To: <200711060905.EDH87533.7NEG9K32@aa.jp.fujitsu.com> References: <200711060905.EDH87533.7NEG9K32@aa.jp.fujitsu.com> Message-ID: <473231BD.7010101@redhat.com> Masayuki Sunou wrote: > Hi > > Installation fails when port number used by other processes is set > to --vncport of virt-install, because graphical console is not displayed. > The same problem occurs when port number exceeds upper bound. > > One of patches fixes to request re-input when port number used is set. > --> check_vncport_used.patch > Other fixes to output error message when port number exceeds upper bound. > --> check_vncport_upperbound.patch > > Signed-off-by: Masayuki Sunou > > Thanks, > Masayuki Sunou. Hi, The upperbound check looks good, I just applied it. The vncport collision detection though I'm a bit worried about. Parsing 'netstat' doesn't seem like a nice solution: its a lot of output to parse for little gain and requires an external utility to do it. I think the nice way to check the port would be to have a function that actually attempts to bind the port, to test that it is empty. You would understandably have to release it if you succeeded so the install can use it in the future. I'm not sure if this would carry any residual effects, maybe someone else has a better idea? - Cole -- Cole Robinson crobinso at redhat.com From crobinso at redhat.com Wed Nov 7 22:24:14 2007 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 07 Nov 2007 17:24:14 -0500 Subject: [et-mgmt-tools] [PATCH] Rework virtinst device lists for install Message-ID: <47323B0E.2070904@redhat.com> The following patch changes around how the 'disks' and 'nics' lists in a Guest object are used during an install. These lists are the public attributes used to specify the devices to connect to the guest at install time. Currently, during the actual install, these lists can be manipulated by the installer, to add a boot.iso as a CDROM disk to use for the install, for example ('nics' actually isn't altered during any install path but I wanted to be consistent.) This causes issues if the install fails, but the Guest object is kept around to try again (i.e. virt-manager): any re-attempt would append another cdrom disk based off the boot.iso. Rather than have an error cleanup restore things to their post install state, which would probably cause this bug to pop up again if another error path was added, I went with a small reorg which seems to be the right way to fix this. 'disks' and 'nics' remain but they are copied over to private lists at the start of the install to be used for all mid-install disk/nic additions. The public interface remains the same, its just behind the scenes workings that are shuffled. Any comments appreciated! - Cole -- Cole Robinson crobinso at redhat.com -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: virtinst-device-add-rework-patch URL: From berrange at redhat.com Thu Nov 8 02:00:11 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 8 Nov 2007 02:00:11 +0000 Subject: [et-mgmt-tools] [PATCH] Rework virtinst device lists for install In-Reply-To: <47323B0E.2070904@redhat.com> References: <47323B0E.2070904@redhat.com> Message-ID: <20071108020011.GA5378@redhat.com> On Wed, Nov 07, 2007 at 05:24:14PM -0500, Cole Robinson wrote: > The following patch changes around how the 'disks' and 'nics' lists in a > Guest object are used during an install. > > These lists are the public attributes used to specify the devices to > connect to the guest at install time. Currently, during the actual > install, these lists can be manipulated by the installer, to add a > boot.iso as a CDROM disk to use for the install, for example ('nics' > actually isn't altered during any install path but I wanted to be > consistent.) This causes issues if the install fails, but the Guest object > is kept around to try again (i.e. virt-manager): any re-attempt would > append another cdrom disk based off the boot.iso. > > Rather than have an error cleanup restore things to their post install > state, which would probably cause this bug to pop up again if another > error path was added, I went with a small reorg which seems to be the > right way to fix this. 'disks' and 'nics' remain but they are copied over > to private lists at the start of the install to be used for all > mid-install disk/nic additions. The public interface remains the same, its > just behind the scenes workings that are shuffled. ACK, looks good to me. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From fj1826dm at aa.jp.fujitsu.com Thu Nov 8 08:54:10 2007 From: fj1826dm at aa.jp.fujitsu.com (Masayuki Sunou) Date: Thu, 8 Nov 2007 17:54:10 +0900 Subject: [et-mgmt-tools] [PATCH] Strengthen port number validation In-Reply-To: <473231BD.7010101@redhat.com> References: <200711060905.EDH87533.7NEG9K32@aa.jp.fujitsu.com> <473231BD.7010101@redhat.com> Message-ID: <200711081754.CBF13572.7N9KG23E@aa.jp.fujitsu.com> Hi Thanks for reviewing. > I think the nice way to check the port would be to have a function that > actually attempts to bind the port, to test that it is empty. You would > understandably have to release it if you succeeded so the install can use > it in the future. I'm not sure if this would carry any residual effects, > maybe someone else has a better idea? > This idea looks better. I remake the patch. This patch checks the port by using socket. Thanks, Masayuki Sunou ------------------------------------------------------------------------------- diff -r f40212ea1fd6 virtinst/cli.py --- a/virtinst/cli.py Wed Nov 07 16:31:59 2007 -0500 +++ b/virtinst/cli.py Fri Nov 09 11:55:28 2007 +0900 @@ -15,6 +15,7 @@ import os, sys import os, sys import logging import logging.handlers +import socket import libvirt import util @@ -207,6 +208,8 @@ def get_graphics(vnc, vncport, nographic guest.graphics = False return if vnc is not None: + if vncport is not None and vncport >= 5900: + vncport = port_search(vncport) guest.graphics = (True, "vnc", vncport, keymap) return if sdl is not None: @@ -216,6 +219,8 @@ def get_graphics(vnc, vncport, nographic res = prompt_for_input(_("Would you like to enable graphics support? (yes or no)")) try: vnc = yes_or_no(res) + if vncport is not None and vncport >= 5900: + vncport = port_search(vncport) except ValueError, e: print _("ERROR: "), e continue @@ -224,6 +229,26 @@ def get_graphics(vnc, vncport, nographic else: guest.graphics = False break + +def port_search(vncport): + while 1: + try: + s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) + s.bind(('', vncport)) + except socket.error, e: + s.close() + s = None + if s is not None: + s.close() + return vncport + port = prompt_for_input(_("Installation cannot be continued, because the specified port number is already used.\n Please set another port number or just push enter to allocate a port number automatically.")) + try: + if port is "": + return None + else: + vncport = int(port) + except ValueError, e: + print _("ERROR: "), e ### Option parsing def check_before_store(option, opt_str, value, parser): ------------------------------------------------------------------------------- In message <473231BD.7010101 at redhat.com> "Re: [et-mgmt-tools] [PATCH] Strengthen port number validation" "Cole Robinson " wrote: > Masayuki Sunou wrote: > > Hi > > > > Installation fails when port number used by other processes is set > > to --vncport of virt-install, because graphical console is not displayed. > > The same problem occurs when port number exceeds upper bound. > > > > One of patches fixes to request re-input when port number used is set. > > --> check_vncport_used.patch > > Other fixes to output error message when port number exceeds upper bound. > > --> check_vncport_upperbound.patch > > > > Signed-off-by: Masayuki Sunou > > > > Thanks, > > Masayuki Sunou. > > > Hi, > > The upperbound check looks good, I just applied it. > > The vncport collision detection though I'm a bit worried about. Parsing > 'netstat' doesn't seem like a nice solution: its a lot of output to parse > for little gain and requires an external utility to do it. > > I think the nice way to check the port would be to have a function that > actually attempts to bind the port, to test that it is empty. You would > understandably have to release it if you succeeded so the install can use > it in the future. I'm not sure if this would carry any residual effects, > maybe someone else has a better idea? > > - Cole > > -- > Cole Robinson > crobinso at redhat.com > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From berrange at redhat.com Thu Nov 8 14:38:11 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 8 Nov 2007 14:38:11 +0000 Subject: [et-mgmt-tools] [PATCH] Strengthen port number validation In-Reply-To: <473231BD.7010101@redhat.com> References: <200711060905.EDH87533.7NEG9K32@aa.jp.fujitsu.com> <473231BD.7010101@redhat.com> Message-ID: <20071108143811.GA16895@redhat.com> On Wed, Nov 07, 2007 at 04:44:29PM -0500, Cole Robinson wrote: > Masayuki Sunou wrote: > > Hi > > > > Installation fails when port number used by other processes is set > > to --vncport of virt-install, because graphical console is not displayed. > > The same problem occurs when port number exceeds upper bound. > > > > One of patches fixes to request re-input when port number used is set. > > --> check_vncport_used.patch > > Other fixes to output error message when port number exceeds upper bound. > > --> check_vncport_upperbound.patch > > > > Signed-off-by: Masayuki Sunou > > > > Thanks, > > Masayuki Sunou. > > > Hi, > > The upperbound check looks good, I just applied it. > > The vncport collision detection though I'm a bit worried about. Parsing > 'netstat' doesn't seem like a nice solution: its a lot of output to parse > for little gain and requires an external utility to do it. > > I think the nice way to check the port would be to have a function that > actually attempts to bind the port, to test that it is empty. You would > understandably have to release it if you succeeded so the install can use > it in the future. I'm not sure if this would carry any residual effects, > maybe someone else has a better idea? This kind of check does not belong in virt-install. It is not merely a problem when installing the guest. If you allocate a fixed port to a guest it can clash any time you start the guest. The *ONLY* viable place to check & report errors for this is the code which actually opens the port ie QEMU itself. QEMU can propagate errors back to XenD / libvirt and in turn back to the user. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From mdehaan at redhat.com Thu Nov 8 18:22:14 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 08 Nov 2007 13:22:14 -0500 Subject: [et-mgmt-tools] [ANNOUNCE] Cobbler 0.6.3 and Koan 0.6.3 In-Reply-To: <47322A5B.2010304@redhat.com> References: <47322A5B.2010304@redhat.com> Message-ID: <473353D6.4050601@redhat.com> Michael DeHaan wrote: > Hi, > > It's time to release Cobbler 0.6.3 and Koan 0.6.3! I've updated the install docs for the Web UI ... mainly some chmod and Apache configuration stuff that was missing earlier. If you're upgrading or just setting it up for the first time, check it out to make sure everything is tweaked correctly. https://hosted.fedoraproject.org/projects/cobbler/wiki/CobblerWebUi --Michael From tobert at gmail.com Thu Nov 8 21:39:53 2007 From: tobert at gmail.com (Al Tobey) Date: Thu, 8 Nov 2007 13:39:53 -0800 Subject: [et-mgmt-tools] Re: Cobbler Authorisation In-Reply-To: <1194526816.5594.76.camel@slinky> References: <1194526816.5594.76.camel@slinky> Message-ID: <5ac7acb10711081339h76a5aacao51a3b815355799a4@mail.gmail.com> On Nov 8, 2007 5:00 AM, Dan Dengate wrote: > Hi Al, > > I should introduce myself first. My name is Dan, I'm based at ..., > working on Unix Installation tools. We are currently working on a > project to rewrite our existing install infrastructure and have been > considering, along with others (existing, and off the shelve), cobbler > for our needs. > > Cobbler is giving us a lot of stuff for free, but for it to succeed it > obviously has to fit all our requirements, or be easily extended for our > environment, as well as sustainable in the future. > > I'm aware that you're currently working on authorization, which is one > our first areas to tackle. It's probably best to discuss this now, > before things start to head in one direction. > > In simple, are requirements are as follows: > > [1] Only certain users should be able to add (remove, edit, etc) > distributions. > > [2] Only certain users should be able to add (remove, edit, etc) > profiles. > > [3] Only the correct "owner" of a system should be able to touch a given > system. > > > What we'd ideally like to do is keep aware from administering any user > information. There are plenty of databases around with all the > information we could ever need. Hopefully that'll be easy to accomplish with plugins and/or scripts to auto-populate cobbler's users. > One ideal solution would be to limit who can add a distribution [1] and > profiles [2] based on maybe, the users Kerberos credentials. The way I've thought about it, we mostly care about systems, since profiles and distributions should be maintained by superusers. Obviously, I'm wrong ;) I'd like to hear more about how you see Cobbler working in your shop as a kind of use-case if you have a need for users to administer distros & profiles. > So there would be a group of people, bob at FOO.COM, john at FOO.COM... listed > somewhere, like .klogin for example. Bob or John would log on to the > install server and have access to distribution management. > > ...or something along those lines... > > With regard to [3], it gets slightly more confused. For example, we have > a network database which details all the devices on the network, and > maps the device to a responsible and/or main user. This could be pulled into cobbler via triggers or some kind of backend data adapter. For instance, the user code I implemented uses Cobbler's serializer which Michael has conveniently made pluggable. All you'd need to do is write a plugin to pull & map users from your database rather than Cobbler's files. Other users have requested to be able to do this for systems too, specifically against LDAP servers that already have all their system information. > This checking and auth or denying is easy, but how this can map into > Cobbler is where I'm becoming stuck. Originally my idea was to rely on > the Triggers, to check the database and make a decision, returning 1 for > yes user is ok, so they can do stuff, returning zero if they're a > fraudster.. but in talking this through with Michael a little bit, I'm > beginning to move away from this. > > So, there's a lot to take in there. > > I've read the mailing list about the tags. If I understand them > correctly, if a system has a tag 'Dan', only Dan can do stuff with the > object(s) that have that tag? That right. That's pretty close. If a system or its profile has "Dan" and the user has the tag "Dan", then that user has access to the system. The main problem with my tagging approach is that it requires that you be careful about what tags users/systems/profiles get or you could accidentally grant access to things by accident. That's true of any system, but especially easy with something as fast and loose as tag-based authorization. > The idea that sysadmins give root access to users for certain machines, > although is principle is ok, and I'm sure the protection is there, it > just doesn't "feel" right. It feels like we would have to maintain a > list of sudo users.. I'm pretty sure just about any system in cobbler will require sudo to get user-based authorization correct. I'm mainly concentrating on the webui, but noticed that the same code could probably support the CLI via SUDO_USER where the webui would use REMOTE_USER. Maybe it might be worth looking into having a reduced version of the CLI tool that uses XMLRPC like the webui so it doesn't have to run as root. That would make things a bit more interesting ;) > So in conclusion, where is Cobbler going with regard to authorisation > now? Michael's in requirements gathering phase, AFAIK. I'm just throwing together prototypes to see what's easy. Once we figure out an approach that works for most people, it'll probably fall together pretty quickly. > Michael says he's looking at the IPA stuff, which doesn't seem all that > bad, but how it fits together, I've no idea. It looks like a nice suite, but I don't think people would appreciate cobbler being hooked too tightly to any single system, since near 100% of users already have some kind of system in place. I also don't think they're providing much in the way of API's yet (could be wrong), which is really what we'd want. The webui is already pretty trivial to put behind kerberos for authentication using any number of Apache modules, as of 0.6.3. Authorization will be trickier, since that's often done using some kind of LDAP or SQL scheme. Cobbler is trying to stay agnostic towards databases, which is a nice idea, but leaves us on our own for implementing an auth system - we can't just borrow somebody else's wholesale. I've considered extending the webui's usage of PATH_INFO so that it'll be easier to have apache modules implement authorization behind Cobbler's back, similar to how you can have sudo parse command line options. For instance, you could do: dan localhost=/usr/bin/cobbler system edit --name=dan_workstation bob localhost=/usr/bin/cobbler system edit --name=bob_workstation This is hacky though and a PITA to administer, though it wouldn't be too bad if you autogenerated it from a database. Instead I'd like to see: dan localhost=/usr/bin/cobbler And have cobbler check if "dan" has edit access on "dan_workstation". That raises a couple more questions: 1. Do we only care about write access? 2. Does anybody have a need to grant read access to only parts of cobbler? 3. Please tell us if you would have use for user-based authorization in the cobbler CLI. If we only care about the webui, completely different approaches can be taken. > Many Thanks > Dan Dengate From mdehaan at redhat.com Thu Nov 8 22:18:54 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 08 Nov 2007 17:18:54 -0500 Subject: [et-mgmt-tools] Re: Cobbler Authorisation In-Reply-To: <5ac7acb10711081339h76a5aacao51a3b815355799a4@mail.gmail.com> References: <1194526816.5594.76.camel@slinky> <5ac7acb10711081339h76a5aacao51a3b815355799a4@mail.gmail.com> Message-ID: <47338B4E.3090106@redhat.com> Al Tobey wrote: > On Nov 8, 2007 5:00 AM, Dan Dengate wrote: > >> Hi Al, >> >> I should introduce myself first. My name is Dan, I'm based at ..., >> working on Unix Installation tools. We are currently working on a >> project to rewrite our existing install infrastructure and have been >> considering, along with others (existing, and off the shelve), cobbler >> for our needs. >> >> Cobbler is giving us a lot of stuff for free, but for it to succeed it >> obviously has to fit all our requirements, or be easily extended for our >> environment, as well as sustainable in the future. >> >> I'm aware that you're currently working on authorization, which is one >> our first areas to tackle. It's probably best to discuss this now, >> before things start to head in one direction. >> >> In simple, are requirements are as follows: >> >> [1] Only certain users should be able to add (remove, edit, etc) >> distributions. >> >> [2] Only certain users should be able to add (remove, edit, etc) >> profiles. >> >> [3] Only the correct "owner" of a system should be able to touch a given >> system. >> >> >> What we'd ideally like to do is keep aware from administering any user >> information. There are plenty of databases around with all the >> information we could ever need. >> This seems to lend itself to further leveraging "modules" in cobbler. Right now the modules system allows for trading out serialization modules, and we could extend this to also allow trading out authorization modules. This allows things to be expanded for various environments that are relatively diverse without installing something in core that may not be the best fit for everyone. > > Hopefully that'll be easy to accomplish with plugins and/or scripts to > auto-populate cobbler's users. > > >> One ideal solution would be to limit who can add a distribution [1] and >> profiles [2] based on maybe, the users Kerberos credentials. >> > > The way I've thought about it, we mostly care about systems, since > profiles and distributions should be maintained by superusers. > Obviously, I'm wrong ;) I'd like to hear more about how you see > Cobbler working in your shop as a kind of use-case if you have a need > for users to administer distros & profiles. > An auth module could provide something look like verify(user, pass,cobbler_object) -> True | False Again, the default auth module (in /etc/cobbler/modules.conf) would be auth_none, which would describe the present system. > >> So there would be a group of people, bob at FOO.COM, john at FOO.COM... listed >> somewhere, like .klogin for example. Bob or John would log on to the >> install server and have access to distribution management. >> >> ...or something along those lines... >> >> With regard to [3], it gets slightly more confused. For example, we have >> a network database which details all the devices on the network, and >> maps the device to a responsible and/or main user. >> > > This could be pulled into cobbler via triggers or some kind of backend > data adapter. For instance, the user code I implemented uses > Cobbler's serializer which Michael has conveniently made pluggable. > All you'd need to do is write a plugin to pull & map users from your > database rather than Cobbler's files. > Seems like we are on the same page :) > Other users have requested to be able to do this for systems too, > specifically against LDAP servers that already have all their system > information. > > >> This checking and auth or denying is easy, but how this can map into >> Cobbler is where I'm becoming stuck. Originally my idea was to rely on >> the Triggers, to check the database and make a decision, returning 1 for >> yes user is ok, so they can do stuff, returning zero if they're a >> fraudster.. but in talking this through with Michael a little bit, I'm >> beginning to move away from this. >> >> So, there's a lot to take in there. >> >> I've read the mailing list about the tags. If I understand them >> correctly, if a system has a tag 'Dan', only Dan can do stuff with the >> object(s) that have that tag? That right. >> > > That's pretty close. If a system or its profile has "Dan" and the > user has the tag "Dan", then that user has access to the system. > > The main problem with my tagging approach is that it requires that you > be careful about what tags users/systems/profiles get or you could > accidentally grant access to things by accident. That's true of > any system, but especially easy with something as fast and loose as > tag-based authorization. > The above module approach could leave the permissions infrastructure completely out of cobbler... so it could optionally look at tags, or it might just be a yes/no sort of thing based on the type of object ... depending on what the site wanted to implement. The main thing we'd want is to not require setup of /anything/ for the core install to work and make it easy enough for a complex site install to adapt to their needs. > >> The idea that sysadmins give root access to users for certain machines, >> although is principle is ok, and I'm sure the protection is there, it >> just doesn't "feel" right. It feels like we would have to maintain a >> list of sudo users.. >> > > I'm pretty sure just about any system in cobbler will require sudo to > get user-based authorization correct. I'm mainly concentrating on > the webui, but noticed that the same code could probably support the > CLI via SUDO_USER where the webui would use REMOTE_USER. Maybe it > might be worth looking into having a reduced version of the CLI tool > that uses XMLRPC like the webui so it doesn't have to run as root. > That would make things a bit more interesting ;) > I'd like to leave the complexity out of the command line invocations. We should be thinking about web services, for which the command line can be a client. > >> So in conclusion, where is Cobbler going with regard to authorisation >> now? >> > > Michael's in requirements gathering phase, AFAIK. I'm just throwing > together prototypes to see what's easy. Once we figure out an > approach that works for most people, it'll probably fall together > pretty quickly. > > Yep... seeing what people want, and how best to do it. Ultimately I like the modules approach best, and in general, I intend to expand cobbler to be more modular in this regard as well. For instance, as the command line is expanded, each function in the command line might be a module, making it easier for folks to custom commands outside the core. Modules also the advantage of being able to trade cobbler objects, which the triggers don't have. Triggers aren't going away though, they are simple, and simple can be good. For something like an email notification, that's all you need. >> Michael says he's looking at the IPA stuff, which doesn't seem all that >> bad, but how it fits together, I've no idea. >> > > It looks like a nice suite, but I don't think people would appreciate > cobbler being hooked too tightly to any single system, since near 100% > of users already have some kind of system in place. I also don't > think they're providing much in the way of API's yet (could be wrong), > which is really what we'd want. > It's just investigation. If anything this would be "we can have a module that hooks into kerb" at most. It most certaintly would not be required, the standard behavior is to keep things working like they work now, and for things to be very simple to setup up. That's incredibly important for a large portion of the cobbler install base. > The webui is already pretty trivial to put behind kerberos for > authentication using any number of Apache modules, as of 0.6.3. > Authorization will be trickier, since that's often done using some > kind of LDAP or SQL scheme. Cobbler is trying to stay agnostic > towards databases, which is a nice idea, but leaves us on our own for > implementing an auth system - we can't just borrow somebody else's > wholesale. > Seems like where you'd want to hook into kerb to me. > I've considered extending the webui's usage of PATH_INFO so that it'll > be easier to have apache modules implement authorization behind > Cobbler's back, similar to how you can have sudo parse command line > options. For instance, you could do: > > dan localhost=/usr/bin/cobbler system edit --name=dan_workstation > bob localhost=/usr/bin/cobbler system edit --name=bob_workstation > > This is hacky though and a PITA to administer, though it wouldn't be > too bad if you autogenerated it from a database. Instead I'd like > to see: > dan localhost=/usr/bin/cobbler > > And have cobbler check if "dan" has edit access on "dan_workstation". > > That raises a couple more questions: > > 1. Do we only care about write access? > Yes. > 2. Does anybody have a need to grant read access to only parts of cobbler? > Assume no. The permissions on all the files in the kickstart directories are world readable, as needed by Anaconda. > 3. Please tell us if you would have use for user-based authorization > in the cobbler CLI. If we only care about the webui, completely > different approaches can be taken. > Anything we do needs to be done at the services layer, not with just respect for the Web UI or the CLI. This enables remote command lines and integration with other services. > >> Many Thanks >> Dan Dengate >> > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From sghosh at redhat.com Fri Nov 9 04:39:55 2007 From: sghosh at redhat.com (Subhendu Ghosh) Date: Thu, 08 Nov 2007 23:39:55 -0500 Subject: [et-mgmt-tools] Re: Cobbler Authorisation In-Reply-To: <47338B4E.3090106@redhat.com> References: <1194526816.5594.76.camel@slinky> <5ac7acb10711081339h76a5aacao51a3b815355799a4@mail.gmail.com> <47338B4E.3090106@redhat.com> Message-ID: <4733E49B.2000703@redhat.com> Michael DeHaan wrote: > Al Tobey wrote: >> On Nov 8, 2007 5:00 AM, Dan Dengate wrote: >> >>> Hi Al, >>> >>> I should introduce myself first. My name is Dan, I'm based at ..., >>> working on Unix Installation tools. We are currently working on a >>> project to rewrite our existing install infrastructure and have been >>> considering, along with others (existing, and off the shelve), cobbler >>> for our needs. >>> >>> Cobbler is giving us a lot of stuff for free, but for it to succeed it >>> obviously has to fit all our requirements, or be easily extended for our >>> environment, as well as sustainable in the future. >>> >>> I'm aware that you're currently working on authorization, which is one >>> our first areas to tackle. It's probably best to discuss this now, >>> before things start to head in one direction. >>> >>> In simple, are requirements are as follows: >>> >>> [1] Only certain users should be able to add (remove, edit, etc) >>> distributions. >>> >>> [2] Only certain users should be able to add (remove, edit, etc) >>> profiles. >>> >>> [3] Only the correct "owner" of a system should be able to touch a given >>> system. >>> >>> >>> What we'd ideally like to do is keep aware from administering any user >>> information. There are plenty of databases around with all the >>> information we could ever need. >>> > This seems to lend itself to further leveraging "modules" in cobbler. > Right now the modules > system allows for trading out serialization modules, and we could extend > this to also allow trading > out authorization modules. This allows things to be expanded for > various environments that are > relatively diverse without installing something in core that may not be > the best fit for everyone. > >> >> Hopefully that'll be easy to accomplish with plugins and/or scripts to >> auto-populate cobbler's users. >> >> >>> One ideal solution would be to limit who can add a distribution [1] and >>> profiles [2] based on maybe, the users Kerberos credentials. >>> >> >> The way I've thought about it, we mostly care about systems, since >> profiles and distributions should be maintained by superusers. >> Obviously, I'm wrong ;) I'd like to hear more about how you see >> Cobbler working in your shop as a kind of use-case if you have a need >> for users to administer distros & profiles. >> > > An auth module could provide something look like > > verify(user, pass,cobbler_object) -> True | False > > Again, the default auth module (in /etc/cobbler/modules.conf) would be > auth_none, which would describe > the present system. > >> >>> So there would be a group of people, bob at FOO.COM, john at FOO.COM... listed >>> somewhere, like .klogin for example. Bob or John would log on to the >>> install server and have access to distribution management. >>> >>> ...or something along those lines... >>> >>> With regard to [3], it gets slightly more confused. For example, we have >>> a network database which details all the devices on the network, and >>> maps the device to a responsible and/or main user. >>> >> >> This could be pulled into cobbler via triggers or some kind of backend >> data adapter. For instance, the user code I implemented uses >> Cobbler's serializer which Michael has conveniently made pluggable. >> All you'd need to do is write a plugin to pull & map users from your >> database rather than Cobbler's files. >> > > Seems like we are on the same page :) > >> Other users have requested to be able to do this for systems too, >> specifically against LDAP servers that already have all their system >> information. >> >> >>> This checking and auth or denying is easy, but how this can map into >>> Cobbler is where I'm becoming stuck. Originally my idea was to rely on >>> the Triggers, to check the database and make a decision, returning 1 for >>> yes user is ok, so they can do stuff, returning zero if they're a >>> fraudster.. but in talking this through with Michael a little bit, I'm >>> beginning to move away from this. >>> >>> So, there's a lot to take in there. >>> >>> I've read the mailing list about the tags. If I understand them >>> correctly, if a system has a tag 'Dan', only Dan can do stuff with the >>> object(s) that have that tag? That right. >>> >> >> That's pretty close. If a system or its profile has "Dan" and the >> user has the tag "Dan", then that user has access to the system. >> >> The main problem with my tagging approach is that it requires that you >> be careful about what tags users/systems/profiles get or you could >> accidentally grant access to things by accident. That's true of >> any system, but especially easy with something as fast and loose as >> tag-based authorization. >> > > The above module approach could leave the permissions infrastructure > completely out > of cobbler... so it could optionally look at tags, or it might just be a > yes/no sort of thing > based on the type of object ... depending on what the site wanted to > implement. The main > thing we'd want is to not require setup of /anything/ for the core > install to work and make > it easy enough for a complex site install to adapt to their needs. > >> >>> The idea that sysadmins give root access to users for certain machines, >>> although is principle is ok, and I'm sure the protection is there, it >>> just doesn't "feel" right. It feels like we would have to maintain a >>> list of sudo users.. >>> >> >> I'm pretty sure just about any system in cobbler will require sudo to >> get user-based authorization correct. I'm mainly concentrating on >> the webui, but noticed that the same code could probably support the >> CLI via SUDO_USER where the webui would use REMOTE_USER. Maybe it >> might be worth looking into having a reduced version of the CLI tool >> that uses XMLRPC like the webui so it doesn't have to run as root. >> That would make things a bit more interesting ;) >> > > I'd like to leave the complexity out of the command line invocations. > > We should be thinking about web services, for which the command line can > be a client. > > >> >>> So in conclusion, where is Cobbler going with regard to authorisation >>> now? >>> >> >> Michael's in requirements gathering phase, AFAIK. I'm just throwing >> together prototypes to see what's easy. Once we figure out an >> approach that works for most people, it'll probably fall together >> pretty quickly. >> >> > Yep... seeing what people want, and how best to do it. > > Ultimately I like the modules approach best, and in general, I intend to > expand > cobbler to be more modular in this regard as well. For instance, as the > command line > is expanded, each function in the command line might be a module, making > it easier > for folks to custom commands outside the core. > > Modules also the advantage of being able to trade cobbler objects, which > the triggers > don't have. Triggers aren't going away though, they are simple, and > simple can be good. > For something like an email notification, that's all you need. > >>> Michael says he's looking at the IPA stuff, which doesn't seem all that >>> bad, but how it fits together, I've no idea. >>> >> >> It looks like a nice suite, but I don't think people would appreciate >> cobbler being hooked too tightly to any single system, since near 100% >> of users already have some kind of system in place. I also don't >> think they're providing much in the way of API's yet (could be wrong), >> which is really what we'd want. >> > > It's just investigation. If anything this would be "we can have a > module that > hooks into kerb" at most. It most certaintly would not be required, > the standard > behavior is to keep things working like they work now, and for things to > be very > simple to setup up. That's incredibly important for a large portion of > the cobbler > install base. > >> The webui is already pretty trivial to put behind kerberos for >> authentication using any number of Apache modules, as of 0.6.3. >> Authorization will be trickier, since that's often done using some >> kind of LDAP or SQL scheme. Cobbler is trying to stay agnostic >> towards databases, which is a nice idea, but leaves us on our own for >> implementing an auth system - we can't just borrow somebody else's >> wholesale. >> > Seems like where you'd want to hook into kerb to me. > >> I've considered extending the webui's usage of PATH_INFO so that it'll >> be easier to have apache modules implement authorization behind >> Cobbler's back, similar to how you can have sudo parse command line >> options. For instance, you could do: >> >> dan localhost=/usr/bin/cobbler system edit --name=dan_workstation >> bob localhost=/usr/bin/cobbler system edit --name=bob_workstation >> >> This is hacky though and a PITA to administer, though it wouldn't be >> too bad if you autogenerated it from a database. Instead I'd like >> to see: >> dan localhost=/usr/bin/cobbler >> >> And have cobbler check if "dan" has edit access on "dan_workstation". >> >> That raises a couple more questions: >> >> 1. Do we only care about write access? >> > > Yes. > >> 2. Does anybody have a need to grant read access to only parts of >> cobbler? >> > > Assume no. The permissions on all the files in the kickstart > directories are world readable, as needed > by Anaconda. > >> 3. Please tell us if you would have use for user-based authorization >> in the cobbler CLI. If we only care about the webui, completely >> different approaches can be taken. >> > > Anything we do needs to be done at the services layer, not with just > respect for the Web UI or the CLI. This enables > remote command lines and integration with other services. >> One other aspect to authorization that I would add is logging and reporting - who did what and when. This could be achieved by wrappers in the actions and pluggable modules to some cobbler/syslog facilities. I can think of all the sarbox audits that clients go thru on the patching side, don't see how this would be any different. -regards Subhendu -------------- next part -------------- A non-text attachment was scrubbed... Name: sghosh.vcf Type: text/x-vcard Size: 266 bytes Desc: not available URL: From tim.verhoeven.be at gmail.com Fri Nov 9 10:29:53 2007 From: tim.verhoeven.be at gmail.com (Tim Verhoeven) Date: Fri, 9 Nov 2007 11:29:53 +0100 Subject: [et-mgmt-tools] Cobbler - Fix to help enable authentication for the webinterface Message-ID: <2a7fce340711090229o76af2ba3rbc7423bebc0823b2@mail.gmail.com> Hi, The current process for enabled authentication for the webinterface involves setting "AllowOverride Node" to "AllowOverride All" for the cgi-bin directory in the main apache configfile. This can be solved much cleaner by adding this to the cobbler.conf httpd configfile : AllowOverride All Options None Order allow,deny Allow from all This only sets the "AllowOverride" for the Cobbler cgi-bin directory, not the whole cgi-bin directory. It's all a bit cleaner. Regards, Tim -- Tim Verhoeven - tim.verhoeven.be at gmail.com - 0479 / 88 11 83 Hoping the problem magically goes away by ignoring it is the "microsoft approach to programming" and should never be allowed. (Linus Torvalds) From mdehaan at redhat.com Fri Nov 9 15:44:28 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 09 Nov 2007 10:44:28 -0500 Subject: [et-mgmt-tools] Cobbler - Fix to help enable authentication for the webinterface In-Reply-To: <2a7fce340711090229o76af2ba3rbc7423bebc0823b2@mail.gmail.com> References: <2a7fce340711090229o76af2ba3rbc7423bebc0823b2@mail.gmail.com> Message-ID: <4734805C.70706@redhat.com> Tim Verhoeven wrote: > Hi, > > The current process for enabled authentication for the webinterface > involves setting "AllowOverride Node" to "AllowOverride All" for the > cgi-bin directory in the main apache configfile. > > This can be solved much cleaner by adding this to the cobbler.conf > httpd configfile : > > > AllowOverride All > Options None > Order allow,deny > Allow from all > > > This only sets the "AllowOverride" for the Cobbler cgi-bin directory, > not the whole cgi-bin directory. It's all a bit cleaner. > > Regards, > Tim > > +1. I'll add this. From mdehaan at redhat.com Fri Nov 9 16:02:01 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 09 Nov 2007 11:02:01 -0500 Subject: [et-mgmt-tools] Re: Cobbler Authorisation In-Reply-To: <4733E49B.2000703@redhat.com> References: <1194526816.5594.76.camel@slinky> <5ac7acb10711081339h76a5aacao51a3b815355799a4@mail.gmail.com> <47338B4E.3090106@redhat.com> <4733E49B.2000703@redhat.com> Message-ID: <47348479.2090208@redhat.com> > > One other aspect to authorization that I would add is logging and > reporting - who did what and when. This could be achieved by wrappers > in the actions and pluggable modules to some cobbler/syslog facilities. > > I can think of all the sarbox audits that clients go thru on the > patching side, don't see how this would be any different. > A logging module and hook (independent of any authN/authZ features) is definitely doable too. By default we could just use Python standard logging, and users could replace the logger module with something more site-specific if they really wanted to. Excellent suggestion. I'll add these to the RFE list. > -regards > Subhendu > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From Greg.Caetano at hp.com Fri Nov 9 20:23:31 2007 From: Greg.Caetano at hp.com (Caetano, Greg) Date: Fri, 9 Nov 2007 20:23:31 +0000 Subject: [et-mgmt-tools] Cobbler0.6.3 WebUI error Message-ID: I have just installed cobbler 0.6.3 on a RHEL5.1 system using "rpmbuild --rebuild" from the src rpm. I believe I have made the appropriate changes to the cobbler settings file to enable the WebUI xml requests, however I'm seeing the following errors in the logs files [root at hpmgmt httpd]# tail ssl_access_log 192.168.0.1 - - [09/Nov/2007:14:13:26 -0600] "GET /cgi-bin/cobbler/webui.cgi HTTP/1.1" 401 479 192.168.0.1 - cobbler [09/Nov/2007:14:13:35 -0600] "GET /cgi-bin/cobbler/webui.cgi HTTP/1.1" 200 2319 192.168.0.1 - - [09/Nov/2007:14:13:35 -0600] "GET /cobbler/webui/style.css HTTP/1.1" 200 3566 192.168.0.1 - - [09/Nov/2007:14:13:35 -0600] "GET /cobbler/webui/cobblerweb.css HTTP/1.1" 200 659 192.168.0.1 - - [09/Nov/2007:14:13:35 -0600] "GET /cobbler/webui/cobbler.js HTTP/1.1" 200 5960 192.168.0.1 - - [09/Nov/2007:14:13:35 -0600] "GET /cobbler/webui/logo-cobbler.png HTTP/1.1" 200 15085 192.168.0.1 - - [09/Nov/2007:14:13:35 -0600] "GET /cobbler/webui/icon_16_sync.png HTTP/1.1" 200 541 192.168.0.1 - cobbler [09/Nov/2007:14:13:38 -0600] "GET /cgi-bin/cobbler/webui.cgi/settings_view HTTP/1.1" 200 2414 [root at hpmgmt httpd]# tail ssl_request_log [09/Nov/2007:14:13:26 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA "GET /cgi-bin/cobbler/webui.cgi HTTP/1.1" 479 [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA "GET /cgi-bin/cobbler/webui.cgi HTTP/1.1" 2319 [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA "GET /cobbler/webui/style.css HTTP/1.1" 3566 [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA "GET /cobbler/webui/cobblerweb.css HTTP/1.1" 659 [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA "GET /cobbler/webui/cobbler.js HTTP/1.1" 5960 [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA "GET /cobbler/webui/logo-cobbler.png HTTP/1.1" 15085 [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA "GET /cobbler/webui/icon_16_sync.png HTTP/1.1" 541 [09/Nov/2007:14:13:38 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA "GET /cgi-bin/cobbler/webui.cgi/settings_view HTTP/1.1" 2414 [09/Nov/2007:14:17:23 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA "GET /cgi-bin/cobbler/webui.cgi/settings_view HTTP/1.1" 2414 [root at hpmgmt httpd]# tail ssl_error_log [Fri Nov 09 14:12:37 2007] [warn] RSA server certificate is a CA certificate (BasicConstraints: CA == TRUE !?) [Fri Nov 09 14:12:37 2007] [warn] RSA server certificate CommonName (CN) `localhost.localdomain' does NOT match server name!? [Fri Nov 09 14:12:37 2007] [warn] RSA server certificate is a CA certificate (BasicConstraints: CA == TRUE !?) [Fri Nov 09 14:12:37 2007] [warn] RSA server certificate CommonName (CN) `localhost.localdomain' does NOT match server name!? [Fri Nov 09 14:13:35 2007] [error] [client 192.168.0.1] ('admin', 'cobbler') [Fri Nov 09 14:13:39 2007] [error] [client 192.168.0.1] ('admin', 'cobbler'), referer: https://192.168.0.1/cgi-bin/cobbler/webui.cgi [Fri Nov 09 14:17:23 2007] [error] [client 192.168.0.1] ('admin', 'cobbler'), referer: https://192.168.0.1/cgi-bin/cobbler/webui.cgi The UI displays: XMLRPC Authentication Error. See Apache logs for details. Pointers? Thanks greg Greg Caetano greg.caetano at hp.com Red Hat Certified Engineer From mdehaan at redhat.com Fri Nov 9 20:31:58 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 09 Nov 2007 15:31:58 -0500 Subject: [et-mgmt-tools] Cobbler0.6.3 WebUI error In-Reply-To: References: Message-ID: <4734C3BE.2080309@redhat.com> Caetano, Greg wrote: > I have just installed cobbler 0.6.3 on a RHEL5.1 system using "rpmbuild --rebuild" from the src rpm. > > I believe I have made the appropriate changes to the cobbler settings file to enable the WebUI xml requests, however > I'm seeing the following errors in the logs files > > [root at hpmgmt httpd]# tail ssl_access_log > 192.168.0.1 - - [09/Nov/2007:14:13:26 -0600] "GET /cgi-bin/cobbler/webui.cgi HTTP/1.1" 401 479 > 192.168.0.1 - cobbler [09/Nov/2007:14:13:35 -0600] "GET /cgi-bin/cobbler/webui.cgi HTTP/1.1" 200 2319 > 192.168.0.1 - - [09/Nov/2007:14:13:35 -0600] "GET /cobbler/webui/style.css HTTP/1.1" 200 3566 > 192.168.0.1 - - [09/Nov/2007:14:13:35 -0600] "GET /cobbler/webui/cobblerweb.css HTTP/1.1" 200 659 > 192.168.0.1 - - [09/Nov/2007:14:13:35 -0600] "GET /cobbler/webui/cobbler.js HTTP/1.1" 200 5960 > 192.168.0.1 - - [09/Nov/2007:14:13:35 -0600] "GET /cobbler/webui/logo-cobbler.png HTTP/1.1" 200 15085 > 192.168.0.1 - - [09/Nov/2007:14:13:35 -0600] "GET /cobbler/webui/icon_16_sync.png HTTP/1.1" 200 541 > 192.168.0.1 - cobbler [09/Nov/2007:14:13:38 -0600] "GET /cgi-bin/cobbler/webui.cgi/settings_view HTTP/1.1" 200 2414 > > [root at hpmgmt httpd]# tail ssl_request_log > [09/Nov/2007:14:13:26 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA "GET /cgi-bin/cobbler/webui.cgi HTTP/1.1" 479 > [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA "GET /cgi-bin/cobbler/webui.cgi HTTP/1.1" 2319 > [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA "GET /cobbler/webui/style.css HTTP/1.1" 3566 > [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA "GET /cobbler/webui/cobblerweb.css HTTP/1.1" 659 > [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA "GET /cobbler/webui/cobbler.js HTTP/1.1" 5960 > [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA "GET /cobbler/webui/logo-cobbler.png HTTP/1.1" 15085 > [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA "GET /cobbler/webui/icon_16_sync.png HTTP/1.1" 541 > [09/Nov/2007:14:13:38 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA "GET /cgi-bin/cobbler/webui.cgi/settings_view HTTP/1.1" 2414 > [09/Nov/2007:14:17:23 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA "GET /cgi-bin/cobbler/webui.cgi/settings_view HTTP/1.1" 2414 > > [root at hpmgmt httpd]# tail ssl_error_log > [Fri Nov 09 14:12:37 2007] [warn] RSA server certificate is a CA certificate (BasicConstraints: CA == TRUE !?) > [Fri Nov 09 14:12:37 2007] [warn] RSA server certificate CommonName (CN) `localhost.localdomain' does NOT match server name!? > [Fri Nov 09 14:12:37 2007] [warn] RSA server certificate is a CA certificate (BasicConstraints: CA == TRUE !?) > [Fri Nov 09 14:12:37 2007] [warn] RSA server certificate CommonName (CN) `localhost.localdomain' does NOT match server name!? > [Fri Nov 09 14:13:35 2007] [error] [client 192.168.0.1] ('admin', 'cobbler') > [Fri Nov 09 14:13:39 2007] [error] [client 192.168.0.1] ('admin', 'cobbler'), referer: https://192.168.0.1/cgi-bin/cobbler/webui.cgi > [Fri Nov 09 14:17:23 2007] [error] [client 192.168.0.1] ('admin', 'cobbler'), referer: https://192.168.0.1/cgi-bin/cobbler/webui.cgi > > The UI displays: XMLRPC Authentication Error. See Apache logs for details. > > Pointers? > > Thanks > greg > > Greg Caetano > greg.caetano at hp.com > Red Hat Certified Engineer > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > The UI error is probably because the Web UI can't read /etc/cobbler/auth.conf ... I've recently added some chmod instructions to the Wiki. Look over all the install instructions on the Wiki again and maybe you can find what you missed. The localdomain stuff appears to be noise, probably from Apache webserver using self signed certificates. --Michael From Greg.Caetano at hp.com Fri Nov 9 20:42:24 2007 From: Greg.Caetano at hp.com (Caetano, Greg) Date: Fri, 9 Nov 2007 20:42:24 +0000 Subject: [et-mgmt-tools] Cobbler0.6.3 WebUI error In-Reply-To: <4734C3BE.2080309@redhat.com> References: <4734C3BE.2080309@redhat.com> Message-ID: I think I've got it all... But still no luck... I can log into the WebUI just cant get any data returned... [root at hpmgmt cobbler]# ls -l /etc/cobbler/auth.conf -rw-rw---- 1 apache root 39 Nov 8 13:22 /etc/cobbler/auth.conf [root at hpmgmt cobbler]# getenforce Disabled [root at hpmgmt cobbler]# grep -i xml /var/lib/cobbler/settings xmlrpc_port: 25151 xmlrpc_rw_enabled: 1 xmlrpc_rw_port: 25152 [root at hpmgmt cobbler]# cat /etc/cobbler/auth.conf [xmlrpc_service_users] admin = cobbler [root at hpmgmt cobbler]# cat /var/www/cgi-bin/cobbler/.htpasswd cobbler:Cobbler WebUI Authentication:01966586b5ea70fb0905caee0468d29a [root at hpmgmt cobbler]# ls -la /var/www/cgi-bin/cobbler total 36 drwxr-xr-x 2 apache apache 4096 Nov 8 13:05 . drwxr-xr-x 3 root root 4096 Nov 8 13:05 .. -rwxr-xr-x 1 apache apache 4272 Sep 20 14:49 findks.cgi -rw-rw---- 1 apache apache 149 Oct 30 16:24 .htaccess -rw-rw---- 1 apache apache 70 Nov 8 13:30 .htpasswd -rwxr-xr-x 1 apache apache 1872 Sep 20 14:49 nopxe.cgi -rwxr-xr-x 1 apache apache 2952 Oct 29 15:39 webui.cgi -----Original Message----- From: et-mgmt-tools-bounces at redhat.com [mailto:et-mgmt-tools-bounces at redhat.com] On Behalf Of Michael DeHaan Sent: Friday, November 09, 2007 2:32 PM To: Fedora/Linux Management Tools Subject: Re: [et-mgmt-tools] Cobbler0.6.3 WebUI error Caetano, Greg wrote: > I have just installed cobbler 0.6.3 on a RHEL5.1 system using "rpmbuild --rebuild" from the src rpm. > > I believe I have made the appropriate changes to the cobbler settings > file to enable the WebUI xml requests, however I'm seeing the > following errors in the logs files > > [root at hpmgmt httpd]# tail ssl_access_log > 192.168.0.1 - - [09/Nov/2007:14:13:26 -0600] "GET > /cgi-bin/cobbler/webui.cgi HTTP/1.1" 401 479 > 192.168.0.1 - cobbler [09/Nov/2007:14:13:35 -0600] "GET > /cgi-bin/cobbler/webui.cgi HTTP/1.1" 200 2319 > 192.168.0.1 - - [09/Nov/2007:14:13:35 -0600] "GET > /cobbler/webui/style.css HTTP/1.1" 200 3566 > 192.168.0.1 - - [09/Nov/2007:14:13:35 -0600] "GET > /cobbler/webui/cobblerweb.css HTTP/1.1" 200 659 > 192.168.0.1 - - [09/Nov/2007:14:13:35 -0600] "GET > /cobbler/webui/cobbler.js HTTP/1.1" 200 5960 > 192.168.0.1 - - [09/Nov/2007:14:13:35 -0600] "GET > /cobbler/webui/logo-cobbler.png HTTP/1.1" 200 15085 > 192.168.0.1 - - [09/Nov/2007:14:13:35 -0600] "GET > /cobbler/webui/icon_16_sync.png HTTP/1.1" 200 541 > 192.168.0.1 - cobbler [09/Nov/2007:14:13:38 -0600] "GET > /cgi-bin/cobbler/webui.cgi/settings_view HTTP/1.1" 200 2414 > > [root at hpmgmt httpd]# tail ssl_request_log > [09/Nov/2007:14:13:26 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA "GET > /cgi-bin/cobbler/webui.cgi HTTP/1.1" 479 > [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA "GET > /cgi-bin/cobbler/webui.cgi HTTP/1.1" 2319 > [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA "GET > /cobbler/webui/style.css HTTP/1.1" 3566 > [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA "GET > /cobbler/webui/cobblerweb.css HTTP/1.1" 659 > [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA "GET > /cobbler/webui/cobbler.js HTTP/1.1" 5960 > [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA "GET > /cobbler/webui/logo-cobbler.png HTTP/1.1" 15085 > [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA "GET > /cobbler/webui/icon_16_sync.png HTTP/1.1" 541 > [09/Nov/2007:14:13:38 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA "GET > /cgi-bin/cobbler/webui.cgi/settings_view HTTP/1.1" 2414 > [09/Nov/2007:14:17:23 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA "GET > /cgi-bin/cobbler/webui.cgi/settings_view HTTP/1.1" 2414 > > [root at hpmgmt httpd]# tail ssl_error_log [Fri Nov 09 14:12:37 2007] > [warn] RSA server certificate is a CA certificate (BasicConstraints: > CA == TRUE !?) [Fri Nov 09 14:12:37 2007] [warn] RSA server certificate CommonName (CN) `localhost.localdomain' does NOT match server name!? > [Fri Nov 09 14:12:37 2007] [warn] RSA server certificate is a CA > certificate (BasicConstraints: CA == TRUE !?) [Fri Nov 09 14:12:37 2007] [warn] RSA server certificate CommonName (CN) `localhost.localdomain' does NOT match server name!? > [Fri Nov 09 14:13:35 2007] [error] [client 192.168.0.1] ('admin', > 'cobbler') [Fri Nov 09 14:13:39 2007] [error] [client 192.168.0.1] > ('admin', 'cobbler'), referer: > https://192.168.0.1/cgi-bin/cobbler/webui.cgi > [Fri Nov 09 14:17:23 2007] [error] [client 192.168.0.1] ('admin', > 'cobbler'), referer: https://192.168.0.1/cgi-bin/cobbler/webui.cgi > > The UI displays: XMLRPC Authentication Error. See Apache logs for details. > > Pointers? > > Thanks > greg > > Greg Caetano > greg.caetano at hp.com > Red Hat Certified Engineer > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > The UI error is probably because the Web UI can't read /etc/cobbler/auth.conf ... I've recently added some chmod instructions to the Wiki. Look over all the install instructions on the Wiki again and maybe you can find what you missed. The localdomain stuff appears to be noise, probably from Apache webserver using self signed certificates. --Michael _______________________________________________ et-mgmt-tools mailing list et-mgmt-tools at redhat.com https://www.redhat.com/mailman/listinfo/et-mgmt-tools From mdehaan at redhat.com Fri Nov 9 20:57:37 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 09 Nov 2007 15:57:37 -0500 Subject: [et-mgmt-tools] Cobbler0.6.3 WebUI error In-Reply-To: References: <4734C3BE.2080309@redhat.com> Message-ID: <4734C9C1.2070003@redhat.com> Caetano, Greg wrote: > I think I've got it all... But still no luck... I can log into the WebUI just cant get any data returned... > Ok... What do you mean by 'no data returned' ? The XMLRPC error message still? Is cobblerd running and have you restarted it? > > [root at hpmgmt cobbler]# ls -l /etc/cobbler/auth.conf > -rw-rw---- 1 apache root 39 Nov 8 13:22 /etc/cobbler/auth.conf > [root at hpmgmt cobbler]# getenforce > Disabled > [root at hpmgmt cobbler]# grep -i xml /var/lib/cobbler/settings > xmlrpc_port: 25151 > xmlrpc_rw_enabled: 1 > xmlrpc_rw_port: 25152 > [root at hpmgmt cobbler]# cat /etc/cobbler/auth.conf > [xmlrpc_service_users] > admin = cobbler > [root at hpmgmt cobbler]# cat /var/www/cgi-bin/cobbler/.htpasswd > cobbler:Cobbler WebUI Authentication:01966586b5ea70fb0905caee0468d29a > [root at hpmgmt cobbler]# ls -la /var/www/cgi-bin/cobbler > total 36 > drwxr-xr-x 2 apache apache 4096 Nov 8 13:05 . > drwxr-xr-x 3 root root 4096 Nov 8 13:05 .. > -rwxr-xr-x 1 apache apache 4272 Sep 20 14:49 findks.cgi > -rw-rw---- 1 apache apache 149 Oct 30 16:24 .htaccess > -rw-rw---- 1 apache apache 70 Nov 8 13:30 .htpasswd > -rwxr-xr-x 1 apache apache 1872 Sep 20 14:49 nopxe.cgi > -rwxr-xr-x 1 apache apache 2952 Oct 29 15:39 webui.cgi > > -----Original Message----- > From: et-mgmt-tools-bounces at redhat.com [mailto:et-mgmt-tools-bounces at redhat.com] On Behalf Of Michael DeHaan > Sent: Friday, November 09, 2007 2:32 PM > To: Fedora/Linux Management Tools > Subject: Re: [et-mgmt-tools] Cobbler0.6.3 WebUI error > > Caetano, Greg wrote: > >> I have just installed cobbler 0.6.3 on a RHEL5.1 system using "rpmbuild --rebuild" from the src rpm. >> >> I believe I have made the appropriate changes to the cobbler settings >> file to enable the WebUI xml requests, however I'm seeing the >> following errors in the logs files >> >> [root at hpmgmt httpd]# tail ssl_access_log >> 192.168.0.1 - - [09/Nov/2007:14:13:26 -0600] "GET >> /cgi-bin/cobbler/webui.cgi HTTP/1.1" 401 479 >> 192.168.0.1 - cobbler [09/Nov/2007:14:13:35 -0600] "GET >> /cgi-bin/cobbler/webui.cgi HTTP/1.1" 200 2319 >> 192.168.0.1 - - [09/Nov/2007:14:13:35 -0600] "GET >> /cobbler/webui/style.css HTTP/1.1" 200 3566 >> 192.168.0.1 - - [09/Nov/2007:14:13:35 -0600] "GET >> /cobbler/webui/cobblerweb.css HTTP/1.1" 200 659 >> 192.168.0.1 - - [09/Nov/2007:14:13:35 -0600] "GET >> /cobbler/webui/cobbler.js HTTP/1.1" 200 5960 >> 192.168.0.1 - - [09/Nov/2007:14:13:35 -0600] "GET >> /cobbler/webui/logo-cobbler.png HTTP/1.1" 200 15085 >> 192.168.0.1 - - [09/Nov/2007:14:13:35 -0600] "GET >> /cobbler/webui/icon_16_sync.png HTTP/1.1" 200 541 >> 192.168.0.1 - cobbler [09/Nov/2007:14:13:38 -0600] "GET >> /cgi-bin/cobbler/webui.cgi/settings_view HTTP/1.1" 200 2414 >> >> [root at hpmgmt httpd]# tail ssl_request_log >> [09/Nov/2007:14:13:26 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA "GET >> /cgi-bin/cobbler/webui.cgi HTTP/1.1" 479 >> [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA "GET >> /cgi-bin/cobbler/webui.cgi HTTP/1.1" 2319 >> [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA "GET >> /cobbler/webui/style.css HTTP/1.1" 3566 >> [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA "GET >> /cobbler/webui/cobblerweb.css HTTP/1.1" 659 >> [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA "GET >> /cobbler/webui/cobbler.js HTTP/1.1" 5960 >> [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA "GET >> /cobbler/webui/logo-cobbler.png HTTP/1.1" 15085 >> [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA "GET >> /cobbler/webui/icon_16_sync.png HTTP/1.1" 541 >> [09/Nov/2007:14:13:38 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA "GET >> /cgi-bin/cobbler/webui.cgi/settings_view HTTP/1.1" 2414 >> [09/Nov/2007:14:17:23 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA "GET >> /cgi-bin/cobbler/webui.cgi/settings_view HTTP/1.1" 2414 >> >> [root at hpmgmt httpd]# tail ssl_error_log [Fri Nov 09 14:12:37 2007] >> [warn] RSA server certificate is a CA certificate (BasicConstraints: >> CA == TRUE !?) [Fri Nov 09 14:12:37 2007] [warn] RSA server certificate CommonName (CN) `localhost.localdomain' does NOT match server name!? >> [Fri Nov 09 14:12:37 2007] [warn] RSA server certificate is a CA >> certificate (BasicConstraints: CA == TRUE !?) [Fri Nov 09 14:12:37 2007] [warn] RSA server certificate CommonName (CN) `localhost.localdomain' does NOT match server name!? >> [Fri Nov 09 14:13:35 2007] [error] [client 192.168.0.1] ('admin', >> 'cobbler') [Fri Nov 09 14:13:39 2007] [error] [client 192.168.0.1] >> ('admin', 'cobbler'), referer: >> https://192.168.0.1/cgi-bin/cobbler/webui.cgi >> [Fri Nov 09 14:17:23 2007] [error] [client 192.168.0.1] ('admin', >> 'cobbler'), referer: https://192.168.0.1/cgi-bin/cobbler/webui.cgi >> >> The UI displays: XMLRPC Authentication Error. See Apache logs for details. >> >> Pointers? >> >> Thanks >> greg >> >> Greg Caetano >> greg.caetano at hp.com >> Red Hat Certified Engineer >> >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools >> >> > > The UI error is probably because the Web UI can't read /etc/cobbler/auth.conf ... I've recently added some chmod instructions to the Wiki. > Look over all the install instructions on the Wiki again and maybe you can find what you missed. > > The localdomain stuff appears to be noise, probably from Apache webserver using self signed certificates. > > --Michael > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From Greg.Caetano at hp.com Fri Nov 9 21:03:04 2007 From: Greg.Caetano at hp.com (Caetano, Greg) Date: Fri, 9 Nov 2007 21:03:04 +0000 Subject: [et-mgmt-tools] Cobbler0.6.3 WebUI error In-Reply-To: <4734C9C1.2070003@redhat.com> References: <4734C3BE.2080309@redhat.com> <4734C9C1.2070003@redhat.com> Message-ID: Sorry if that was unclear... When I click on the "Settings" link the XMLRPC error message appears. It also appears if I try to click on any link except "DOCS" cobblerd and httpd have been restarted -----Original Message----- From: et-mgmt-tools-bounces at redhat.com [mailto:et-mgmt-tools-bounces at redhat.com] On Behalf Of Michael DeHaan Sent: Friday, November 09, 2007 2:58 PM To: Fedora/Linux Management Tools Subject: Re: [et-mgmt-tools] Cobbler0.6.3 WebUI error Caetano, Greg wrote: > I think I've got it all... But still no luck... I can log into the WebUI just cant get any data returned... > Ok... What do you mean by 'no data returned' ? The XMLRPC error message still? Is cobblerd running and have you restarted it? > > [root at hpmgmt cobbler]# ls -l /etc/cobbler/auth.conf > -rw-rw---- 1 apache root 39 Nov 8 13:22 /etc/cobbler/auth.conf > [root at hpmgmt cobbler]# getenforce Disabled [root at hpmgmt cobbler]# grep > -i xml /var/lib/cobbler/settings > xmlrpc_port: 25151 > xmlrpc_rw_enabled: 1 > xmlrpc_rw_port: 25152 > [root at hpmgmt cobbler]# cat /etc/cobbler/auth.conf > [xmlrpc_service_users] admin = cobbler [root at hpmgmt cobbler]# cat > /var/www/cgi-bin/cobbler/.htpasswd > cobbler:Cobbler WebUI Authentication:01966586b5ea70fb0905caee0468d29a > [root at hpmgmt cobbler]# ls -la /var/www/cgi-bin/cobbler total 36 > drwxr-xr-x 2 apache apache 4096 Nov 8 13:05 . > drwxr-xr-x 3 root root 4096 Nov 8 13:05 .. > -rwxr-xr-x 1 apache apache 4272 Sep 20 14:49 findks.cgi > -rw-rw---- 1 apache apache 149 Oct 30 16:24 .htaccess > -rw-rw---- 1 apache apache 70 Nov 8 13:30 .htpasswd > -rwxr-xr-x 1 apache apache 1872 Sep 20 14:49 nopxe.cgi -rwxr-xr-x 1 > apache apache 2952 Oct 29 15:39 webui.cgi > > -----Original Message----- > From: et-mgmt-tools-bounces at redhat.com > [mailto:et-mgmt-tools-bounces at redhat.com] On Behalf Of Michael DeHaan > Sent: Friday, November 09, 2007 2:32 PM > To: Fedora/Linux Management Tools > Subject: Re: [et-mgmt-tools] Cobbler0.6.3 WebUI error > > Caetano, Greg wrote: > >> I have just installed cobbler 0.6.3 on a RHEL5.1 system using "rpmbuild --rebuild" from the src rpm. >> >> I believe I have made the appropriate changes to the cobbler settings >> file to enable the WebUI xml requests, however I'm seeing the >> following errors in the logs files >> >> [root at hpmgmt httpd]# tail ssl_access_log >> 192.168.0.1 - - [09/Nov/2007:14:13:26 -0600] "GET >> /cgi-bin/cobbler/webui.cgi HTTP/1.1" 401 479 >> 192.168.0.1 - cobbler [09/Nov/2007:14:13:35 -0600] "GET >> /cgi-bin/cobbler/webui.cgi HTTP/1.1" 200 2319 >> 192.168.0.1 - - [09/Nov/2007:14:13:35 -0600] "GET >> /cobbler/webui/style.css HTTP/1.1" 200 3566 >> 192.168.0.1 - - [09/Nov/2007:14:13:35 -0600] "GET >> /cobbler/webui/cobblerweb.css HTTP/1.1" 200 659 >> 192.168.0.1 - - [09/Nov/2007:14:13:35 -0600] "GET >> /cobbler/webui/cobbler.js HTTP/1.1" 200 5960 >> 192.168.0.1 - - [09/Nov/2007:14:13:35 -0600] "GET >> /cobbler/webui/logo-cobbler.png HTTP/1.1" 200 15085 >> 192.168.0.1 - - [09/Nov/2007:14:13:35 -0600] "GET >> /cobbler/webui/icon_16_sync.png HTTP/1.1" 200 541 >> 192.168.0.1 - cobbler [09/Nov/2007:14:13:38 -0600] "GET >> /cgi-bin/cobbler/webui.cgi/settings_view HTTP/1.1" 200 2414 >> >> [root at hpmgmt httpd]# tail ssl_request_log >> [09/Nov/2007:14:13:26 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA >> "GET /cgi-bin/cobbler/webui.cgi HTTP/1.1" 479 >> [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA >> "GET /cgi-bin/cobbler/webui.cgi HTTP/1.1" 2319 >> [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA >> "GET /cobbler/webui/style.css HTTP/1.1" 3566 >> [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA >> "GET /cobbler/webui/cobblerweb.css HTTP/1.1" 659 >> [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA >> "GET /cobbler/webui/cobbler.js HTTP/1.1" 5960 >> [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA >> "GET /cobbler/webui/logo-cobbler.png HTTP/1.1" 15085 >> [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA >> "GET /cobbler/webui/icon_16_sync.png HTTP/1.1" 541 >> [09/Nov/2007:14:13:38 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA >> "GET /cgi-bin/cobbler/webui.cgi/settings_view HTTP/1.1" 2414 >> [09/Nov/2007:14:17:23 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA >> "GET /cgi-bin/cobbler/webui.cgi/settings_view HTTP/1.1" 2414 >> >> [root at hpmgmt httpd]# tail ssl_error_log [Fri Nov 09 14:12:37 2007] >> [warn] RSA server certificate is a CA certificate (BasicConstraints: >> CA == TRUE !?) [Fri Nov 09 14:12:37 2007] [warn] RSA server certificate CommonName (CN) `localhost.localdomain' does NOT match server name!? >> [Fri Nov 09 14:12:37 2007] [warn] RSA server certificate is a CA >> certificate (BasicConstraints: CA == TRUE !?) [Fri Nov 09 14:12:37 2007] [warn] RSA server certificate CommonName (CN) `localhost.localdomain' does NOT match server name!? >> [Fri Nov 09 14:13:35 2007] [error] [client 192.168.0.1] ('admin', >> 'cobbler') [Fri Nov 09 14:13:39 2007] [error] [client 192.168.0.1] >> ('admin', 'cobbler'), referer: >> https://192.168.0.1/cgi-bin/cobbler/webui.cgi >> [Fri Nov 09 14:17:23 2007] [error] [client 192.168.0.1] ('admin', >> 'cobbler'), referer: https://192.168.0.1/cgi-bin/cobbler/webui.cgi >> >> The UI displays: XMLRPC Authentication Error. See Apache logs for details. >> >> Pointers? >> >> Thanks >> greg >> >> Greg Caetano >> greg.caetano at hp.com >> Red Hat Certified Engineer >> >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools >> >> > > The UI error is probably because the Web UI can't read /etc/cobbler/auth.conf ... I've recently added some chmod instructions to the Wiki. > Look over all the install instructions on the Wiki again and maybe you can find what you missed. > > The localdomain stuff appears to be noise, probably from Apache webserver using self signed certificates. > > --Michael > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > _______________________________________________ et-mgmt-tools mailing list et-mgmt-tools at redhat.com https://www.redhat.com/mailman/listinfo/et-mgmt-tools From mdehaan at redhat.com Fri Nov 9 21:13:29 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 09 Nov 2007 16:13:29 -0500 Subject: [et-mgmt-tools] Cobbler0.6.3 WebUI error In-Reply-To: References: <4734C3BE.2080309@redhat.com> <4734C9C1.2070003@redhat.com> Message-ID: <4734CD79.1020609@redhat.com> Caetano, Greg wrote: > Sorry if that was unclear... > > When I click on the "Settings" link the XMLRPC error message appears. It also appears if I try to click on any link except "DOCS" > > cobblerd and httpd have been restarted > I've seen this working on a RHEL 5.1 system already (other than mine), so I am not entirely sure what's up. The tail of /var/log/cobbler/cobblerd.log or /var/log/cobbler/webui.log might yield something relevant. (Actually permissons of webui.log could be causing problems also...should also be writeable by Apache, and if neccessary, SELinux tagged appropriately) Other than that and the instructions on the Wiki I don't have a lot of ideas without taking a closer look at the box. --Michael > -----Original Message----- > From: et-mgmt-tools-bounces at redhat.com [mailto:et-mgmt-tools-bounces at redhat.com] On Behalf Of Michael DeHaan > Sent: Friday, November 09, 2007 2:58 PM > To: Fedora/Linux Management Tools > Subject: Re: [et-mgmt-tools] Cobbler0.6.3 WebUI error > > Caetano, Greg wrote: > >> I think I've got it all... But still no luck... I can log into the WebUI just cant get any data returned... >> >> > > Ok... > > What do you mean by 'no data returned' ? The XMLRPC error message still? > > Is cobblerd running and have you restarted it? > > >> [root at hpmgmt cobbler]# ls -l /etc/cobbler/auth.conf >> -rw-rw---- 1 apache root 39 Nov 8 13:22 /etc/cobbler/auth.conf >> [root at hpmgmt cobbler]# getenforce Disabled [root at hpmgmt cobbler]# grep >> -i xml /var/lib/cobbler/settings >> xmlrpc_port: 25151 >> xmlrpc_rw_enabled: 1 >> xmlrpc_rw_port: 25152 >> [root at hpmgmt cobbler]# cat /etc/cobbler/auth.conf >> [xmlrpc_service_users] admin = cobbler [root at hpmgmt cobbler]# cat >> /var/www/cgi-bin/cobbler/.htpasswd >> cobbler:Cobbler WebUI Authentication:01966586b5ea70fb0905caee0468d29a >> [root at hpmgmt cobbler]# ls -la /var/www/cgi-bin/cobbler total 36 >> drwxr-xr-x 2 apache apache 4096 Nov 8 13:05 . >> drwxr-xr-x 3 root root 4096 Nov 8 13:05 .. >> -rwxr-xr-x 1 apache apache 4272 Sep 20 14:49 findks.cgi >> -rw-rw---- 1 apache apache 149 Oct 30 16:24 .htaccess >> -rw-rw---- 1 apache apache 70 Nov 8 13:30 .htpasswd >> -rwxr-xr-x 1 apache apache 1872 Sep 20 14:49 nopxe.cgi -rwxr-xr-x 1 >> apache apache 2952 Oct 29 15:39 webui.cgi >> >> -----Original Message----- >> From: et-mgmt-tools-bounces at redhat.com >> [mailto:et-mgmt-tools-bounces at redhat.com] On Behalf Of Michael DeHaan >> Sent: Friday, November 09, 2007 2:32 PM >> To: Fedora/Linux Management Tools >> Subject: Re: [et-mgmt-tools] Cobbler0.6.3 WebUI error >> >> Caetano, Greg wrote: >> >> >>> I have just installed cobbler 0.6.3 on a RHEL5.1 system using "rpmbuild --rebuild" from the src rpm. >>> >>> I believe I have made the appropriate changes to the cobbler settings >>> file to enable the WebUI xml requests, however I'm seeing the >>> following errors in the logs files >>> >>> [root at hpmgmt httpd]# tail ssl_access_log >>> 192.168.0.1 - - [09/Nov/2007:14:13:26 -0600] "GET >>> /cgi-bin/cobbler/webui.cgi HTTP/1.1" 401 479 >>> 192.168.0.1 - cobbler [09/Nov/2007:14:13:35 -0600] "GET >>> /cgi-bin/cobbler/webui.cgi HTTP/1.1" 200 2319 >>> 192.168.0.1 - - [09/Nov/2007:14:13:35 -0600] "GET >>> /cobbler/webui/style.css HTTP/1.1" 200 3566 >>> 192.168.0.1 - - [09/Nov/2007:14:13:35 -0600] "GET >>> /cobbler/webui/cobblerweb.css HTTP/1.1" 200 659 >>> 192.168.0.1 - - [09/Nov/2007:14:13:35 -0600] "GET >>> /cobbler/webui/cobbler.js HTTP/1.1" 200 5960 >>> 192.168.0.1 - - [09/Nov/2007:14:13:35 -0600] "GET >>> /cobbler/webui/logo-cobbler.png HTTP/1.1" 200 15085 >>> 192.168.0.1 - - [09/Nov/2007:14:13:35 -0600] "GET >>> /cobbler/webui/icon_16_sync.png HTTP/1.1" 200 541 >>> 192.168.0.1 - cobbler [09/Nov/2007:14:13:38 -0600] "GET >>> /cgi-bin/cobbler/webui.cgi/settings_view HTTP/1.1" 200 2414 >>> >>> [root at hpmgmt httpd]# tail ssl_request_log >>> [09/Nov/2007:14:13:26 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA >>> "GET /cgi-bin/cobbler/webui.cgi HTTP/1.1" 479 >>> [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA >>> "GET /cgi-bin/cobbler/webui.cgi HTTP/1.1" 2319 >>> [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA >>> "GET /cobbler/webui/style.css HTTP/1.1" 3566 >>> [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA >>> "GET /cobbler/webui/cobblerweb.css HTTP/1.1" 659 >>> [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA >>> "GET /cobbler/webui/cobbler.js HTTP/1.1" 5960 >>> [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA >>> "GET /cobbler/webui/logo-cobbler.png HTTP/1.1" 15085 >>> [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA >>> "GET /cobbler/webui/icon_16_sync.png HTTP/1.1" 541 >>> [09/Nov/2007:14:13:38 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA >>> "GET /cgi-bin/cobbler/webui.cgi/settings_view HTTP/1.1" 2414 >>> [09/Nov/2007:14:17:23 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA >>> "GET /cgi-bin/cobbler/webui.cgi/settings_view HTTP/1.1" 2414 >>> >>> [root at hpmgmt httpd]# tail ssl_error_log [Fri Nov 09 14:12:37 2007] >>> [warn] RSA server certificate is a CA certificate (BasicConstraints: >>> CA == TRUE !?) [Fri Nov 09 14:12:37 2007] [warn] RSA server certificate CommonName (CN) `localhost.localdomain' does NOT match server name!? >>> [Fri Nov 09 14:12:37 2007] [warn] RSA server certificate is a CA >>> certificate (BasicConstraints: CA == TRUE !?) [Fri Nov 09 14:12:37 2007] [warn] RSA server certificate CommonName (CN) `localhost.localdomain' does NOT match server name!? >>> [Fri Nov 09 14:13:35 2007] [error] [client 192.168.0.1] ('admin', >>> 'cobbler') [Fri Nov 09 14:13:39 2007] [error] [client 192.168.0.1] >>> ('admin', 'cobbler'), referer: >>> https://192.168.0.1/cgi-bin/cobbler/webui.cgi >>> [Fri Nov 09 14:17:23 2007] [error] [client 192.168.0.1] ('admin', >>> 'cobbler'), referer: https://192.168.0.1/cgi-bin/cobbler/webui.cgi >>> >>> The UI displays: XMLRPC Authentication Error. See Apache logs for details. >>> >>> Pointers? >>> >>> Thanks >>> greg >>> >>> Greg Caetano >>> greg.caetano at hp.com >>> Red Hat Certified Engineer >>> >>> _______________________________________________ >>> et-mgmt-tools mailing list >>> et-mgmt-tools at redhat.com >>> https://www.redhat.com/mailman/listinfo/et-mgmt-tools >>> >>> >>> >> The UI error is probably because the Web UI can't read /etc/cobbler/auth.conf ... I've recently added some chmod instructions to the Wiki. >> Look over all the install instructions on the Wiki again and maybe you can find what you missed. >> >> The localdomain stuff appears to be noise, probably from Apache webserver using self signed certificates. >> >> --Michael >> >> >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools >> >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools >> >> > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From Greg.Caetano at hp.com Fri Nov 9 21:27:55 2007 From: Greg.Caetano at hp.com (Caetano, Greg) Date: Fri, 9 Nov 2007 21:27:55 +0000 Subject: [et-mgmt-tools] Cobbler0.6.3 WebUI error In-Reply-To: <4734CD79.1020609@redhat.com> References: <4734C3BE.2080309@redhat.com> <4734C9C1.2070003@redhat.com> <4734CD79.1020609@redhat.com> Message-ID: AH.... webui.log is pointing to a connection refused message... [root at hpmgmt cobbler]# cat cobblerd.log 2007-11-09 15:20:29,273 - cobbler.cobblerd - DEBUG - started 2007-11-09 15:20:30,816 - cobbler.cobblerd - INFO - XMLRPC running on 25151 2007-11-09 15:20:30,817 - cobbler.cobblerd - INFO - XMLRPC (read-write variant) running on 25152 2007-11-09 15:20:30,968 - cobbler.cobblerd - INFO - syslog running on 25150 2007-11-09 15:20:30,968 - cobbler.cobblerd - INFO - publishing avahi service 2007-11-09 15:20:31,314 - cobbler.cobblerd - INFO - avahi service terminated [root at hpmgmt cobbler]# cat webui.log 2007-11-09 15:22:23,141 - cobbler.webui - INFO - login failed for: admin 2007-11-09 15:22:23,149 - cobbler.webui - INFO - Exception occured: socket.error 2007-11-09 15:22:23,149 - cobbler.webui - INFO - Exception value: (111, 'Connection refused') 2007-11-09 15:22:23,152 - cobbler.webui - INFO - Exception Info: File "/usr/lib/python2.4/site-packages/cobbler/webui/CobblerWeb.py", line 92, in __xmlrpc_setup self.token = self.remote.login( self.username, self.password ) File "/usr/lib/python2.4/xmlrpclib.py", line 1096, in __call__ return self.__send(self.__name, args) File "/usr/lib/python2.4/xmlrpclib.py", line 1383, in __request verbose=self.__verbose File "/usr/lib/python2.4/xmlrpclib.py", line 1129, in request self.send_content(h, request_body) File "/usr/lib/python2.4/xmlrpclib.py", line 1243, in send_content connection.endheaders() File "/usr/lib/python2.4/httplib.py", line 798, in endheaders self._send_output() File "/usr/lib/python2.4/httplib.py", line 679, in _send_output self.send(msg) File "/usr/lib/python2.4/httplib.py", line 646, in send self.connect() File "/usr/lib/python2.4/httplib.py", line 630, in connect raise socket.error, msg [root at hpmgmt cobbler]# netstat -atnp | grep 251 tcp 0 0 127.0.0.1:25152 0.0.0.0:* LISTEN 5749/python tcp 0 0 0.0.0.0:25151 0.0.0.0:* LISTEN 5750/python -----Original Message----- From: et-mgmt-tools-bounces at redhat.com [mailto:et-mgmt-tools-bounces at redhat.com] On Behalf Of Michael DeHaan Sent: Friday, November 09, 2007 3:13 PM To: Fedora/Linux Management Tools Subject: Re: [et-mgmt-tools] Cobbler0.6.3 WebUI error Caetano, Greg wrote: > Sorry if that was unclear... > > When I click on the "Settings" link the XMLRPC error message appears. It also appears if I try to click on any link except "DOCS" > > cobblerd and httpd have been restarted > I've seen this working on a RHEL 5.1 system already (other than mine), so I am not entirely sure what's up. The tail of /var/log/cobbler/cobblerd.log or /var/log/cobbler/webui.log might yield something relevant. (Actually permissons of webui.log could be causing problems also...should also be writeable by Apache, and if neccessary, SELinux tagged appropriately) Other than that and the instructions on the Wiki I don't have a lot of ideas without taking a closer look at the box. --Michael > -----Original Message----- > From: et-mgmt-tools-bounces at redhat.com > [mailto:et-mgmt-tools-bounces at redhat.com] On Behalf Of Michael DeHaan > Sent: Friday, November 09, 2007 2:58 PM > To: Fedora/Linux Management Tools > Subject: Re: [et-mgmt-tools] Cobbler0.6.3 WebUI error > > Caetano, Greg wrote: > >> I think I've got it all... But still no luck... I can log into the WebUI just cant get any data returned... >> >> > > Ok... > > What do you mean by 'no data returned' ? The XMLRPC error message still? > > Is cobblerd running and have you restarted it? > > >> [root at hpmgmt cobbler]# ls -l /etc/cobbler/auth.conf >> -rw-rw---- 1 apache root 39 Nov 8 13:22 /etc/cobbler/auth.conf >> [root at hpmgmt cobbler]# getenforce Disabled [root at hpmgmt cobbler]# >> grep -i xml /var/lib/cobbler/settings >> xmlrpc_port: 25151 >> xmlrpc_rw_enabled: 1 >> xmlrpc_rw_port: 25152 >> [root at hpmgmt cobbler]# cat /etc/cobbler/auth.conf >> [xmlrpc_service_users] admin = cobbler [root at hpmgmt cobbler]# cat >> /var/www/cgi-bin/cobbler/.htpasswd >> cobbler:Cobbler WebUI Authentication:01966586b5ea70fb0905caee0468d29a >> [root at hpmgmt cobbler]# ls -la /var/www/cgi-bin/cobbler total 36 >> drwxr-xr-x 2 apache apache 4096 Nov 8 13:05 . >> drwxr-xr-x 3 root root 4096 Nov 8 13:05 .. >> -rwxr-xr-x 1 apache apache 4272 Sep 20 14:49 findks.cgi >> -rw-rw---- 1 apache apache 149 Oct 30 16:24 .htaccess >> -rw-rw---- 1 apache apache 70 Nov 8 13:30 .htpasswd >> -rwxr-xr-x 1 apache apache 1872 Sep 20 14:49 nopxe.cgi -rwxr-xr-x 1 >> apache apache 2952 Oct 29 15:39 webui.cgi >> >> -----Original Message----- >> From: et-mgmt-tools-bounces at redhat.com >> [mailto:et-mgmt-tools-bounces at redhat.com] On Behalf Of Michael DeHaan >> Sent: Friday, November 09, 2007 2:32 PM >> To: Fedora/Linux Management Tools >> Subject: Re: [et-mgmt-tools] Cobbler0.6.3 WebUI error >> >> Caetano, Greg wrote: >> >> >>> I have just installed cobbler 0.6.3 on a RHEL5.1 system using "rpmbuild --rebuild" from the src rpm. >>> >>> I believe I have made the appropriate changes to the cobbler >>> settings file to enable the WebUI xml requests, however I'm seeing >>> the following errors in the logs files >>> >>> [root at hpmgmt httpd]# tail ssl_access_log >>> 192.168.0.1 - - [09/Nov/2007:14:13:26 -0600] "GET >>> /cgi-bin/cobbler/webui.cgi HTTP/1.1" 401 479 >>> 192.168.0.1 - cobbler [09/Nov/2007:14:13:35 -0600] "GET >>> /cgi-bin/cobbler/webui.cgi HTTP/1.1" 200 2319 >>> 192.168.0.1 - - [09/Nov/2007:14:13:35 -0600] "GET >>> /cobbler/webui/style.css HTTP/1.1" 200 3566 >>> 192.168.0.1 - - [09/Nov/2007:14:13:35 -0600] "GET >>> /cobbler/webui/cobblerweb.css HTTP/1.1" 200 659 >>> 192.168.0.1 - - [09/Nov/2007:14:13:35 -0600] "GET >>> /cobbler/webui/cobbler.js HTTP/1.1" 200 5960 >>> 192.168.0.1 - - [09/Nov/2007:14:13:35 -0600] "GET >>> /cobbler/webui/logo-cobbler.png HTTP/1.1" 200 15085 >>> 192.168.0.1 - - [09/Nov/2007:14:13:35 -0600] "GET >>> /cobbler/webui/icon_16_sync.png HTTP/1.1" 200 541 >>> 192.168.0.1 - cobbler [09/Nov/2007:14:13:38 -0600] "GET >>> /cgi-bin/cobbler/webui.cgi/settings_view HTTP/1.1" 200 2414 >>> >>> [root at hpmgmt httpd]# tail ssl_request_log >>> [09/Nov/2007:14:13:26 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA >>> "GET /cgi-bin/cobbler/webui.cgi HTTP/1.1" 479 >>> [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA >>> "GET /cgi-bin/cobbler/webui.cgi HTTP/1.1" 2319 >>> [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA >>> "GET /cobbler/webui/style.css HTTP/1.1" 3566 >>> [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA >>> "GET /cobbler/webui/cobblerweb.css HTTP/1.1" 659 >>> [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA >>> "GET /cobbler/webui/cobbler.js HTTP/1.1" 5960 >>> [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA >>> "GET /cobbler/webui/logo-cobbler.png HTTP/1.1" 15085 >>> [09/Nov/2007:14:13:35 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA >>> "GET /cobbler/webui/icon_16_sync.png HTTP/1.1" 541 >>> [09/Nov/2007:14:13:38 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA >>> "GET /cgi-bin/cobbler/webui.cgi/settings_view HTTP/1.1" 2414 >>> [09/Nov/2007:14:17:23 -0600] 192.168.0.1 TLSv1 DHE-RSA-AES256-SHA >>> "GET /cgi-bin/cobbler/webui.cgi/settings_view HTTP/1.1" 2414 >>> >>> [root at hpmgmt httpd]# tail ssl_error_log [Fri Nov 09 14:12:37 2007] >>> [warn] RSA server certificate is a CA certificate (BasicConstraints: >>> CA == TRUE !?) [Fri Nov 09 14:12:37 2007] [warn] RSA server certificate CommonName (CN) `localhost.localdomain' does NOT match server name!? >>> [Fri Nov 09 14:12:37 2007] [warn] RSA server certificate is a CA >>> certificate (BasicConstraints: CA == TRUE !?) [Fri Nov 09 14:12:37 2007] [warn] RSA server certificate CommonName (CN) `localhost.localdomain' does NOT match server name!? >>> [Fri Nov 09 14:13:35 2007] [error] [client 192.168.0.1] ('admin', >>> 'cobbler') [Fri Nov 09 14:13:39 2007] [error] [client 192.168.0.1] >>> ('admin', 'cobbler'), referer: >>> https://192.168.0.1/cgi-bin/cobbler/webui.cgi >>> [Fri Nov 09 14:17:23 2007] [error] [client 192.168.0.1] ('admin', >>> 'cobbler'), referer: https://192.168.0.1/cgi-bin/cobbler/webui.cgi >>> >>> The UI displays: XMLRPC Authentication Error. See Apache logs for details. >>> >>> Pointers? >>> >>> Thanks >>> greg >>> >>> Greg Caetano >>> greg.caetano at hp.com >>> Red Hat Certified Engineer >>> >>> _______________________________________________ >>> et-mgmt-tools mailing list >>> et-mgmt-tools at redhat.com >>> https://www.redhat.com/mailman/listinfo/et-mgmt-tools >>> >>> >>> >> The UI error is probably because the Web UI can't read /etc/cobbler/auth.conf ... I've recently added some chmod instructions to the Wiki. >> Look over all the install instructions on the Wiki again and maybe you can find what you missed. >> >> The localdomain stuff appears to be noise, probably from Apache webserver using self signed certificates. >> >> --Michael >> >> >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools >> >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools >> >> > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > _______________________________________________ et-mgmt-tools mailing list et-mgmt-tools at redhat.com https://www.redhat.com/mailman/listinfo/et-mgmt-tools From bwood at responsys.com Sat Nov 10 06:24:58 2007 From: bwood at responsys.com (Brendan Wood) Date: Fri, 9 Nov 2007 22:24:58 -0800 Subject: [et-mgmt-tools] virt-install pxeboot issues Message-ID: <20071110062457.GB26264@responsys.com> Hello all, I'm working on trying to build hvm xen guests based on our kickstart servers, but it seems to be failing. I'm using CentOS 5, running kernel 2.6.18-8.1.15.el5.centos.plusxen and the xen 3.0.3-25.0.4.el5 rpm. I built libvirt 0.3.3 and python-virtinst 0.300.1 in order to test the pxeboot setup, but virt-install errors out and xm list shows the guest still running, but state is just '------' and Time is '0.0'. Shutting it down and creating it again causes it to shutdown immediately. I have a feeling the issue is that my xen install isn't new enough to support it. The qemu-dm log file says "qemu: invalid boot device in 'n'", which makes me think that network booting isn't actually set up in my installed version of qemu-dm. I just want to check to make sure it's not something else before I go and backport xen 3.1 into the kernel rpm in order to get the right qemu-dm binary. I'm including the virt-install output as well as the xend.log and relevant /var/log/messages entries. The xend-debug.log and xen-hotplug didn't give any errors. If anyone sees anything I've done wrong, would like more information, or can give me general input on getting fully virtualized xen guests to kickstart from pxeboot (or something similar), just let me know. I'd really appreciate it. Thanks, Brendan Wood --- Here is the command line I used and the resulting errors: [root at molotov bwood]# virt-install --hvm --name xen-test2 --ram 512 --file /space/xen/xen-test2.img --file-size 10 --vnc --mac 00:50:56:00:FF:02 --network bridge:xenbr0 --pxe libvir: error : configuration file syntax error: expecting an assignment libvir: error : configuration file syntax error: expecting an assignment libvir: error : configuration file syntax error: expecting an assignment libvir: error : configuration file syntax error: expecting an assignment Starting install... libvir: Xen error : Domain not found: xenUnifiedDomainLookupByUUID libvir: Xen error : Domain not found: xenUnifiedDomainLookupByName Creating storage file... 100% |=========================| 10 GB 00:00 Creating domain... 0 B 00:00 [Errno 2] No such file or directory Domain installation may not have been successful. If it was, you can restart your domain by running 'virsh start xen-test2'; otherwise, please restart your installation. Fri, 09 Nov 2007 16:19:50 ERROR [Errno 2] No such file or directory Traceback (most recent call last): File "/usr/bin/virt-install", line 485, in ? main() File "/usr/bin/virt-install", line 449, in main dom = guest.start_install(conscb,progresscb) File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 724, in start_install return self._do_install(consolecb, meter) File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 767, in _do_install child = consolecb(self.domain) File "/usr/bin/virt-install", line 429, in show_console return vnc_console(dom, options.connect) File "/usr/bin/virt-install", line 314, in vnc_console os.execvp(args[0], args) File "/usr/lib64/python2.4/os.py", line 341, in execvp _execvpe(file, args) File "/usr/lib64/python2.4/os.py", line 367, in _execvpe func(file, *argrest) OSError: [Errno 2] No such file or directory Domain installation still in progress. You can reconnect to the console to complete the installation process. libvir: Remote error : connection not open Here's what /var/log/messages had to say at that point: Nov 9 16:19:50 molotov kernel: device vif50.0 entered promiscuous mode Nov 9 16:19:50 molotov kernel: ADDRCONF(NETDEV_UP): vif50.0: link is not ready This is what shows up in /var/log/xen/xend.log: [2007-11-09 16:19:50 xend.XendDomainInfo 25184] DEBUG (XendDomainInfo:190) XendDomainInfo.create(['vm', ['name', 'xen-test2'], ['memory', '512'], ['maxmem', '512'], ['vcpus', '1'], ['uuid', '78ded68c-914b-a55d-7efc-53aa4a8ad0f0'], ['on_poweroff', 'destroy'], ['on_reboot', 'destroy'], ['on_crash', 'destroy'], ['image', ['hvm', ['kernel', '/usr/lib/xen/boot/hvmloader'], ['device_model', '/usr/lib64/xen/bin/qemu-dm'], ['vcpus', '1'], ['boot', 'n'], ['pae', '1'], ['usb', '1'], ['serial', 'pty'], ['vnc', '1'], ['vncunused', '1']]], ['device', ['vbd', ['dev', 'hda:disk'], ['uname', 'file:/space/xen/xen-test2.img'], ['mode', 'w']]], ['device', ['vif', ['mac', '00:50:56:00:FF:02'], ['bridge', 'xenbr0'], ['type', 'ioemu']]]]) [2007-11-09 16:19:50 xend.XendDomainInfo 25184] DEBUG (XendDomainInfo:296) parseConfig: config is ['vm', ['name', 'xen-test2'], ['memory', '512'], ['maxmem', '512'], ['vcpus', '1'], ['uuid', '78ded68c-914b-a55d-7efc-53aa4a8ad0f0'], ['on_poweroff', 'destroy'], ['on_reboot', 'destroy'], ['on_crash', 'destroy'], ['image', ['hvm', ['kernel', '/usr/lib/xen/boot/hvmloader'], ['device_model', '/usr/lib64/xen/bin/qemu-dm'], ['vcpus', '1'], ['boot', 'n'], ['pae', '1'], ['usb', '1'], ['serial', 'pty'], ['vnc', '1'], ['vncunused', '1']]], ['device', ['vbd', ['dev', 'hda:disk'], ['uname', 'file:/space/xen/xen-test2.img'], ['mode', 'w']]], ['device', ['vif', ['mac', '00:50:56:00:FF:02'], ['bridge', 'xenbr0'], ['type', 'ioemu']]]] [2007-11-09 16:19:50 xend.XendDomainInfo 25184] DEBUG (XendDomainInfo:397) parseConfig: result is {'shadow_memory': None, 'start_time': None, 'uuid': '78ded68c-914b-a55d-7efc-53aa4a8ad0f0', 'on_crash': 'destroy', 'on_reboot': 'destroy', 'localtime': None, 'image': ['hvm', ['kernel', '/usr/lib/xen/boot/hvmloader'], ['device_model', '/usr/lib64/xen/bin/qemu-dm'], ['vcpus', '1'], ['boot', 'n'], ['pae', '1'], ['usb', '1'], ['serial', 'pty'], ['vnc', '1'], ['vncunused', '1']], 'on_poweroff': 'destroy', 'bootloader_args': None, 'cpus': None, 'name': 'xen-test2', 'backend': [], 'vcpus': 1, 'cpu_weight': None, 'features': None, 'vcpu_avail': None, 'memory': 512, 'device': [('vbd', ['vbd', ['dev', 'hda:disk'], ['uname', 'file:/space/xen/xen-test2.img'], ['mode', 'w']]), ('vif', ['vif', ['mac', '00:50:56:00:FF:02'], ['bridge', 'xenbr0'], ['type', 'ioemu']])], 'bootloader': None, 'cpu': None, 'maxmem': 512} [2007-11-09 16:19:50 xend.XendDomainInfo 25184] DEBUG (XendDomainInfo:1264) XendDomainInfo.construct: None [2007-11-09 16:19:50 xend.XendDomainInfo 25184] DEBUG (XendDomainInfo:1296) XendDomainInfo.initDomain: 50 1.0 [2007-11-09 16:19:50 xend 25184] DEBUG (image:329) args: boot, val: n [2007-11-09 16:19:50 xend 25184] DEBUG (image:329) args: fda, val: None [2007-11-09 16:19:50 xend 25184] DEBUG (image:329) args: fdb, val: None [2007-11-09 16:19:50 xend 25184] DEBUG (image:329) args: soundhw, val: None [2007-11-09 16:19:50 xend 25184] DEBUG (image:329) args: localtime, val: None [2007-11-09 16:19:50 xend 25184] DEBUG (image:329) args: serial, val: pty [2007-11-09 16:19:50 xend 25184] DEBUG (image:329) args: std-vga, val: None [2007-11-09 16:19:50 xend 25184] DEBUG (image:329) args: isa, val: None [2007-11-09 16:19:50 xend 25184] DEBUG (image:329) args: vcpus, val: 1 [2007-11-09 16:19:50 xend 25184] DEBUG (image:329) args: acpi, val: None [2007-11-09 16:19:50 xend 25184] DEBUG (image:329) args: usb, val: 1 [2007-11-09 16:19:50 xend 25184] DEBUG (image:329) args: usbdevice, val: None [2007-11-09 16:19:50 xend 25184] DEBUG (image:329) args: k, val: None [2007-11-09 16:19:50 xend 25184] DEBUG (balloon:127) Balloon: 542352 KiB free; need 541904; done. [2007-11-09 16:19:50 xend 25184] INFO (image:136) buildDomain os=hvm dom=50 vcpus=1 [2007-11-09 16:19:50 xend 25184] DEBUG (image:282) dom = 50 [2007-11-09 16:19:50 xend 25184] DEBUG (image:283) image = /usr/lib/xen/boot/hvmloader [2007-11-09 16:19:50 xend 25184] DEBUG (image:284) store_evtchn = 1 [2007-11-09 16:19:50 xend 25184] DEBUG (image:285) memsize = 512 [2007-11-09 16:19:50 xend 25184] DEBUG (image:286) vcpus = 1 [2007-11-09 16:19:50 xend 25184] DEBUG (image:287) pae = 1 [2007-11-09 16:19:50 xend 25184] DEBUG (image:288) acpi = 0 [2007-11-09 16:19:50 xend 25184] DEBUG (image:289) apic = 0 [2007-11-09 16:19:50 xend 25184] DEBUG (image:435) hvm shutdown watch registered [2007-11-09 16:19:50 xend 25184] DEBUG (blkif:24) exception looking up device number for hda: [Errno 2] No such file or directory: '/dev/hda' [2007-11-09 16:19:50 xend 25184] DEBUG (DevController:110) DevController: writing {'backend-id': '0', 'virtual-device': '768', 'device-type': 'disk', 'state': '1', 'backend': '/local/domain/0/backend/vbd/50/768'} to /local/domain/50/device/vbd/768. [2007-11-09 16:19:50 xend 25184] DEBUG (DevController:112) DevController: writing {'domain': 'xen-test2', 'frontend': '/local/domain/50/device/vbd/768', 'dev': 'hda', 'state': '1', 'params': '/space/xen/xen-test2.img', 'mode': 'w', 'online': '1', 'frontend-id': '50', 'type': 'file'} to /local/domain/0/backend/vbd/50/768. [2007-11-09 16:19:50 xend 25184] DEBUG (DevController:110) DevController: writing {'state': '1', 'backend-id': '0', 'backend': '/local/domain/0/backend/vif/50/0'} to /local/domain/50/device/vif/0. [2007-11-09 16:19:50 xend 25184] DEBUG (DevController:112) DevController: writing {'bridge': 'xenbr0', 'domain': 'xen-test2', 'handle': '0', 'script': '/etc/xen/scripts/vif-bridge', 'state': '1', 'frontend': '/local/domain/50/device/vif/0', 'mac': '00:50:56:00:FF:02', 'online': '1', 'frontend-id': '50', 'type': 'ioemu'} to /local/domain/0/backend/vif/50/0. [2007-11-09 16:19:50 xend 25184] INFO (image:418) spawning device models: /usr/lib64/xen/bin/qemu-dm ['/usr/lib64/xen/bin/qemu-dm', '-d', '50', '-m', '512', '-boot', 'n', '-serial', 'pty', '-vcpus', '1', '-usb', '-domain-name', 'xen-test2', '-net', 'nic,vlan=1,macaddr=00:50:56:00:FF:02,model=rtl8139', '-net', 'tap,vlan=1,bridge=xenbr0', '-vncunused', '-vnclisten', '0.0.0.0'] [2007-11-09 16:19:50 xend 25184] INFO (image:420) device model pid: 25263 [2007-11-09 16:19:50 xend.XendDomainInfo 25184] DEBUG (XendDomainInfo:715) Storing VM details: {'shadow_memory': '4', 'uuid': '78ded68c-914b-a55d-7efc-53aa4a8ad0f0', 'on_reboot': 'destroy', 'start_time': '1194653990.15', 'on_poweroff': 'destroy', 'name': 'xen-test2', 'xend/restart_count': '0', 'vcpus': '1', 'vcpu_avail': '1', 'memory': '512', 'on_crash': 'destroy', 'image': '(hvm (kernel /usr/lib/xen/boot/hvmloader) (device_model /usr/lib64/xen/bin/qemu-dm) (vcpus 1) (boot n) (pae 1) (usb 1) (serial pty) (vnc 1) (vncunused 1))', 'maxmem': '512'} [2007-11-09 16:19:50 xend.XendDomainInfo 25184] DEBUG (XendDomainInfo:750) Storing domain details: {'console/port': '2', 'name': 'xen-test2', 'console/limit': '1048576', 'vm': '/vm/78ded68c-914b-a55d-7efc-53aa4a8ad0f0', 'domid': '50', 'cpu/0/availability': 'online', 'memory/target': '524288', 'store/ring-ref': '177173', 'store/port': '1'} [2007-11-09 16:19:50 xend 25184] DEBUG (image:458) hvm_shutdown fired, shutdown reason=None [2007-11-09 16:19:50 xend.XendDomainInfo 25184] DEBUG (XendDomainInfo:940) XendDomainInfo.handleShutdownWatch [2007-11-09 16:19:50 xend 25184] DEBUG (DevController:143) Waiting for devices vif. [2007-11-09 16:19:50 xend 25184] DEBUG (DevController:149) Waiting for 0. [2007-11-09 16:19:50 xend 25184] DEBUG (DevController:471) hotplugStatusCallback /local/domain/0/backend/vif/50/0/hotplug-status. [2007-11-09 16:19:50 xend 25184] DEBUG (DevController:471) hotplugStatusCallback /local/domain/0/backend/vif/50/0/hotplug-status. [2007-11-09 16:19:50 xend 25184] DEBUG (DevController:485) hotplugStatusCallback 1. [2007-11-09 16:19:50 xend 25184] DEBUG (DevController:143) Waiting for devices usb. [2007-11-09 16:19:50 xend 25184] DEBUG (DevController:143) Waiting for devices vbd. [2007-11-09 16:19:50 xend 25184] DEBUG (DevController:149) Waiting for 768. [2007-11-09 16:19:50 xend 25184] DEBUG (DevController:471) hotplugStatusCallback /local/domain/0/backend/vbd/50/768/hotplug-status. [2007-11-09 16:19:50 xend 25184] DEBUG (DevController:485) hotplugStatusCallback 1. [2007-11-09 16:19:50 xend 25184] DEBUG (DevController:143) Waiting for devices irq. [2007-11-09 16:19:50 xend 25184] DEBUG (DevController:143) Waiting for devices vkbd. [2007-11-09 16:19:50 xend 25184] DEBUG (DevController:143) Waiting for devices vfb. [2007-11-09 16:19:50 xend 25184] DEBUG (DevController:143) Waiting for devices pci. [2007-11-09 16:19:50 xend 25184] DEBUG (DevController:143) Waiting for devices ioports. [2007-11-09 16:19:50 xend 25184] DEBUG (DevController:143) Waiting for devices tap. [2007-11-09 16:19:50 xend 25184] DEBUG (DevController:143) Waiting for devices vtpm. [2007-11-09 16:19:50 xend 25184] INFO (XendDomain:370) Domain xen-test2 (50) unpaused. From Dan at cdChase.com Sat Nov 10 14:22:03 2007 From: Dan at cdChase.com (C. Daniel Chase) Date: Sat, 10 Nov 2007 09:22:03 -0500 Subject: [et-mgmt-tools] Cobbler0.6.3 WebUI error In-Reply-To: References: <4734C3BE.2080309@redhat.com> <4734C9C1.2070003@redhat.com> <4734CD79.1020609@redhat.com> Message-ID: <4735BE8B.1050906@cdChase.com> On 11/09/2007 04:27 PM, Caetano, Greg spoke thusly: > AH.... > webui.log is pointing to a connection refused message... Greg- You may want to check your iptables firewall rules. Just because there is a listener, it doesn't mean your requests will get heard. :-) 25151 is a not a commonly enabled firewall port. -Dan -- C. Daniel Chase (423) 949-4086 http://cdChase.com/ Get Firefox! http://www.spreadfirefox.com/?q=affiliates&id=58708&t=1 From berrange at redhat.com Sat Nov 10 15:57:30 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Sat, 10 Nov 2007 15:57:30 +0000 Subject: [et-mgmt-tools] virt-install pxeboot issues In-Reply-To: <20071110062457.GB26264@responsys.com> References: <20071110062457.GB26264@responsys.com> Message-ID: <20071110155730.GA4283@redhat.com> On Fri, Nov 09, 2007 at 10:24:58PM -0800, Brendan Wood wrote: > Hello all, > > I'm working on trying to build hvm xen guests based on our kickstart > servers, but it seems to be failing. I'm using CentOS 5, running kernel > 2.6.18-8.1.15.el5.centos.plusxen and the xen 3.0.3-25.0.4.el5 rpm. I built > libvirt 0.3.3 and python-virtinst 0.300.1 in order to test the pxeboot > setup, but virt-install errors out and xm list shows the guest still > running, but state is just '------' and Time is '0.0'. Shutting it down and > creating it again causes it to shutdown immediately. I'm afraid CentOS 5.0 will not support PXE boot since this capability was only added in the QEMU binary from Xen 3.1.0. You might have more luck with CentOS 5.1 - in RHEL-5.1 we updated the QEMU binary to that from 3.1.0, but I honestly can't remember offhand if we got PXE working. If CentOS 5.1 doesn't work then I know for sure PXE works in the recently released Fedora 8. We also updated virt-manager to allow PXE in F8. > I have a feeling the issue is that my xen install isn't new enough to > support it. The qemu-dm log file says "qemu: invalid boot device in 'n'", > which makes me think that network booting isn't actually set up in my > installed version of qemu-dm. I just want to check to make sure it's not > something else before I go and backport xen 3.1 into the kernel rpm in > order to get the right qemu-dm binary. Yep, that's because the QEMU in Xen 3.0.3 did not support PXE. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From fj1826dm at aa.jp.fujitsu.com Mon Nov 12 08:24:06 2007 From: fj1826dm at aa.jp.fujitsu.com (Masayuki Sunou) Date: Mon, 12 Nov 2007 17:24:06 +0900 Subject: [et-mgmt-tools] [PATCH] Strengthen port number validation In-Reply-To: <20071108143811.GA16895@redhat.com> References: <200711060905.EDH87533.7NEG9K32@aa.jp.fujitsu.com><473231BD.7010101@redhat.com><20071108143811.GA16895@redhat.com> Message-ID: <200711121724.DJC13477.KN93E2G7@aa.jp.fujitsu.com> Hi I understand your suggestion. Therefore, I decline applying this patch and examine fixing Xen. Thanks, Masayuki Sunou In message <20071108143811.GA16895 at redhat.com> "Re: [et-mgmt-tools] [PATCH] Strengthen port number validation" ""Daniel P. Berrange" " wrote: > On Wed, Nov 07, 2007 at 04:44:29PM -0500, Cole Robinson wrote: > > Masayuki Sunou wrote: > > > Hi > > > > > > Installation fails when port number used by other processes is set > > > to --vncport of virt-install, because graphical console is not displayed. > > > The same problem occurs when port number exceeds upper bound. > > > > > > One of patches fixes to request re-input when port number used is set. > > > --> check_vncport_used.patch > > > Other fixes to output error message when port number exceeds upper bound. > > > --> check_vncport_upperbound.patch > > > > > > Signed-off-by: Masayuki Sunou > > > > > > Thanks, > > > Masayuki Sunou. > > > > > > Hi, > > > > The upperbound check looks good, I just applied it. > > > > The vncport collision detection though I'm a bit worried about. Parsing > > 'netstat' doesn't seem like a nice solution: its a lot of output to parse > > for little gain and requires an external utility to do it. > > > > I think the nice way to check the port would be to have a function that > > actually attempts to bind the port, to test that it is empty. You would > > understandably have to release it if you succeeded so the install can use > > it in the future. I'm not sure if this would carry any residual effects, > > maybe someone else has a better idea? > > This kind of check does not belong in virt-install. It is not merely a > problem when installing the guest. If you allocate a fixed port to a guest > it can clash any time you start the guest. The *ONLY* viable place to > check & report errors for this is the code which actually opens the port > ie QEMU itself. QEMU can propagate errors back to XenD / libvirt and in > turn back to the user. > > > Dan. > -- > |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| > |=- Perl modules: http://search.cpan.org/~danberr/ -=| > |=- Projects: http://freshmeat.net/~danielpb/ -=| > |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From swissslinky at gmail.com Mon Nov 12 13:16:13 2007 From: swissslinky at gmail.com (Dan) Date: Mon, 12 Nov 2007 14:16:13 +0100 Subject: [et-mgmt-tools] webui error Message-ID: <1194873373.5439.12.camel@slinky> ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 08 Nov 2007 13:22:14 -0500 > From: Michael DeHaan > Subject: Re: [et-mgmt-tools] [ANNOUNCE] Cobbler 0.6.3 and Koan 0.6.3 > To: Fedora/Linux Management Tools > Message-ID: <473353D6.4050601 at redhat.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Michael DeHaan wrote: > > Hi, > > > > It's time to release Cobbler 0.6.3 and Koan 0.6.3! > I've updated the install docs for the Web UI ... mainly some chmod and > Apache configuration stuff that was missing earlier. > If you're upgrading or just setting it up for the first time, check it > out to make sure everything is tweaked correctly. > > https://hosted.fedoraproject.org/projects/cobbler/wiki/CobblerWebUi > > --Michael Setting AllowOverride All worked to bring the auth. dialog box back up, but one problem overcome, another arrives; webui returns internal error after completing the auth. dialog box. I've tweaked and checked everything I think it could be, but apache error log is telling me this: [client 128.141.57.220] configuration error: couldn't check user. No user file?: /cgi-bin/cobbler/webui.cgi So a breakdown: auth.conf is owned as apache:root, with -rw-r----- I've tried this with apache:apache too .htaccess and .htpassword both have -rw-rw---- I've tried more new permissions Any ideas, because I've none... MT Dan From swissslinky at gmail.com Mon Nov 12 14:47:38 2007 From: swissslinky at gmail.com (Dan) Date: Mon, 12 Nov 2007 15:47:38 +0100 Subject: [et-mgmt-tools] Re: Cobbler Authorisation In-Reply-To: <20071109044006.EBD1B73246@hormel.redhat.com> References: <20071109044006.EBD1B73246@hormel.redhat.com> Message-ID: <1194878859.5439.65.camel@slinky> > Al Tobey wrote: > > On Nov 8, 2007 5:00 AM, Dan wrote: > > > >> Hi Al, > >> > >> I should introduce myself first. My name is Dan, I'm based at ..., > >> working on Unix Installation tools. We are currently working on a > >> project to rewrite our existing install infrastructure and have been > >> considering, along with others (existing, and off the shelve), cobbler > >> for our needs. > >> > >> Cobbler is giving us a lot of stuff for free, but for it to succeed it > >> obviously has to fit all our requirements, or be easily extended for our > >> environment, as well as sustainable in the future. > >> > >> I'm aware that you're currently working on authorization, which is one > >> our first areas to tackle. It's probably best to discuss this now, > >> before things start to head in one direction. > >> > >> In simple, are requirements are as follows: > >> > >> [1] Only certain users should be able to add (remove, edit, etc) > >> distributions. > >> > >> [2] Only certain users should be able to add (remove, edit, etc) > >> profiles. > >> > >> [3] Only the correct "owner" of a system should be able to touch a given > >> system. > >> > >> > >> What we'd ideally like to do is keep aware from administering any user > >> information. There are plenty of databases around with all the > >> information we could ever need. > >> > This seems to lend itself to further leveraging "modules" in cobbler. > Right now the modules > system allows for trading out serialization modules, and we could extend > this to also allow trading > out authorization modules. This allows things to be expanded for > various environments that are > relatively diverse without installing something in core that may not be > the best fit for everyone. > I'm keen on a modular approach. It means that when/if a requirement changes later down the road, chances our we just rewrite/add a module, rather that touch the core. Not having to touch the core also makes integrating future releases ten times easier. > > > > Hopefully that'll be easy to accomplish with plugins and/or scripts to > > auto-populate cobbler's users. > > > > > >> One ideal solution would be to limit who can add a distribution [1] and > >> profiles [2] based on maybe, the users Kerberos credentials. > >> > > > > The way I've thought about it, we mostly care about systems, since > > profiles and distributions should be maintained by superusers. > > Obviously, I'm wrong ;) I'd like to hear more about how you see > > Cobbler working in your shop as a kind of use-case if you have a need > > for users to administer distros & profiles. > > > > An auth module could provide something look like > > verify(user, pass,cobbler_object) -> True | False > > Again, the default auth module (in /etc/cobbler/modules.conf) would be > auth_none, which would describe > the present system. > Distributions/images here don't just come from sysadmins, they're also internally created by users. Somebody may create a custom image which they wish to deploy on their cluster of 50 systems which they're solely responsible for. At present, they send us the image, we manually add it to the server, manually amend configurations for it to be available... This is a time consuming activity, especially if the provider is sending over several images a week. We'd like to allow them to upload their own images/distributions, without taking up the time of our already busy sysadmins. We want them to take control of provisioning their systems, from start to finish, all on their own. We simply provide the install mechanism. If I need to fill in any gaps here, let me know. > > > >> So there would be a group of people, bob at FOO.COM, john at FOO.COM... listed > >> somewhere, like .klogin for example. Bob or John would log on to the > >> install server and have access to distribution management. > >> > >> ...or something along those lines... > >> > >> With regard to [3], it gets slightly more confused. For example, we have > >> a network database which details all the devices on the network, and > >> maps the device to a responsible and/or main user. > >> > > > > This could be pulled into cobbler via triggers or some kind of backend > > data adapter. For instance, the user code I implemented uses > > Cobbler's serializer which Michael has conveniently made pluggable. > > All you'd need to do is write a plugin to pull & map users from your > > database rather than Cobbler's files. > > > > Seems like we are on the same page :) > > > Other users have requested to be able to do this for systems too, > > specifically against LDAP servers that already have all their system > > information. > > > > > >> This checking and auth or denying is easy, but how this can map into > >> Cobbler is where I'm becoming stuck. Originally my idea was to rely on > >> the Triggers, to check the database and make a decision, returning 1 for > >> yes user is ok, so they can do stuff, returning zero if they're a > >> fraudster.. but in talking this through with Michael a little bit, I'm > >> beginning to move away from this. > >> > >> So, there's a lot to take in there. > >> > >> I've read the mailing list about the tags. If I understand them > >> correctly, if a system has a tag 'Dan', only Dan can do stuff with the > >> object(s) that have that tag? That right. > >> > > > > That's pretty close. If a system or its profile has "Dan" and the > > user has the tag "Dan", then that user has access to the system. > > > > The main problem with my tagging approach is that it requires that you > > be careful about what tags users/systems/profiles get or you could > > accidentally grant access to things by accident. That's true of > > any system, but especially easy with something as fast and loose as > > tag-based authorization. > > > > The above module approach could leave the permissions infrastructure > completely out > of cobbler... so it could optionally look at tags, or it might just be a > yes/no sort of thing > based on the type of object ... depending on what the site wanted to > implement. The main > thing we'd want is to not require setup of /anything/ for the core > install to work and make > it easy enough for a complex site install to adapt to their needs. > > > > >> The idea that sysadmins give root access to users for certain machines, > >> although is principle is ok, and I'm sure the protection is there, it > >> just doesn't "feel" right. It feels like we would have to maintain a > >> list of sudo users.. > >> > > > > I'm pretty sure just about any system in cobbler will require sudo to > > get user-based authorization correct. I'm mainly concentrating on > > the webui, but noticed that the same code could probably support the > > CLI via SUDO_USER where the webui would use REMOTE_USER. Maybe it > > might be worth looking into having a reduced version of the CLI tool > > that uses XMLRPC like the webui so it doesn't have to run as root. > > That would make things a bit more interesting ;) > > > > I'd like to leave the complexity out of the command line invocations. > > We should be thinking about web services, for which the command line can > be a client. > > > > > >> So in conclusion, where is Cobbler going with regard to authorisation > >> now? > >> > > > > Michael's in requirements gathering phase, AFAIK. I'm just throwing > > together prototypes to see what's easy. Once we figure out an > > approach that works for most people, it'll probably fall together > > pretty quickly. > > > > > Yep... seeing what people want, and how best to do it. > > Ultimately I like the modules approach best, and in general, I intend to > expand > cobbler to be more modular in this regard as well. For instance, as the > command line > is expanded, each function in the command line might be a module, making > it easier > for folks to custom commands outside the core. > > Modules also the advantage of being able to trade cobbler objects, which > the triggers > don't have. Triggers aren't going away though, they are simple, and > simple can be good. > For something like an email notification, that's all you need. > Modules ftw! > >> Michael says he's looking at the IPA stuff, which doesn't seem all that > >> bad, but how it fits together, I've no idea. > >> > > > > It looks like a nice suite, but I don't think people would appreciate > > cobbler being hooked too tightly to any single system, since near 100% > > of users already have some kind of system in place. I also don't > > think they're providing much in the way of API's yet (could be wrong), > > which is really what we'd want. > > > > It's just investigation. If anything this would be "we can have a > module that > hooks into kerb" at most. It most certainly would not be required, > the standard > behavior is to keep things working like they work now, and for things to > be very > simple to setup up. That's incredibly important for a large portion of > the cobbler > install base. That's fair enough. Just something which can be downloaded and then plugged into an existing authentication mechanism with as little fiddling as possible. I just cannot see us going near IPA, because we already have the infrastructure in place. > > > The webui is already pretty trivial to put behind kerberos for > > authentication using any number of Apache modules, as of 0.6.3. > > Authorization will be trickier, since that's often done using some > > kind of LDAP or SQL scheme. Cobbler is trying to stay agnostic > > towards databases, which is a nice idea, but leaves us on our own for > > implementing an auth system - we can't just borrow somebody else's > > wholesale. > > > Seems like where you'd want to hook into kerb to me. > > > I've considered extending the webui's usage of PATH_INFO so that it'll > > be easier to have apache modules implement authorization behind > > Cobbler's back, similar to how you can have sudo parse command line > > options. For instance, you could do: > > > > dan localhost=/usr/bin/cobbler system edit --name=dan_workstation > > bob localhost=/usr/bin/cobbler system edit --name=bob_workstation > > > > This is hacky though and a PITA to administer, though it wouldn't be > > too bad if you autogenerated it from a database. Instead I'd like > > to see: > > dan localhost=/usr/bin/cobbler > > > > And have cobbler check if "dan" has edit access on "dan_workstation". > > > > That raises a couple more questions: > > > > 1. Do we only care about write access? > > > > Yes. > > > 2. Does anybody have a need to grant read access to only parts of cobbler? > > > > Assume no. The permissions on all the files in the kickstart > directories are world readable, as needed > by Anaconda. Indeed. I originally thought I could place permissions on the images and kickstarts, but Anaconda wouldn't like this, as Michael says. > > > 3. Please tell us if you would have use for user-based authorization > > in the cobbler CLI. If we only care about the webui, completely > > different approaches can be taken. > > > > Anything we do needs to be done at the services layer, not with just > respect for the Web UI or the CLI. This enables > remote command lines and integration with other services. > > Yes, we need authorization/authentication at CLI, as well as webUI. Not everybody wants to use a webui and not everybody wants to use a CLI, so we need to provide an interface for both to keep them all sweet. > > >> Many Thanks > >> Dan From mdehaan at redhat.com Mon Nov 12 15:42:37 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 12 Nov 2007 10:42:37 -0500 Subject: [et-mgmt-tools] webui error In-Reply-To: <1194873373.5439.12.camel@slinky> References: <1194873373.5439.12.camel@slinky> Message-ID: <4738746D.7050304@redhat.com> > [client 128.141.57.220] configuration error: couldn't check user. No user file?: /cgi-bin/cobbler/webui.cgi > Hmmm .... I haven't seen this before. What's your test system? Anything strange in your httpd.conf? From mdehaan at redhat.com Mon Nov 12 15:53:12 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 12 Nov 2007 10:53:12 -0500 Subject: [et-mgmt-tools] Re: Cobbler Authorisation In-Reply-To: <1194878859.5439.65.camel@slinky> References: <20071109044006.EBD1B73246@hormel.redhat.com> <1194878859.5439.65.camel@slinky> Message-ID: <473876E8.5000707@redhat.com> Dan wrote: > I'm keen on a modular approach. It means that when/if a requirement > changes later down the road, chances our we just rewrite/add a module, > rather that touch the core. Not having to touch the core also makes > integrating future releases ten times easier. > +1 > Distributions/images here don't just come from sysadmins, they're also > internally created by users. Somebody may create a custom image which > they wish to deploy on their cluster of 50 systems which they're solely > responsible for. > > At present, they send us the image, we manually add it to the server, > manually amend configurations for it to be available... This is a time > consuming activity, especially if the provider is sending over several > images a week. We'd like to allow them to upload their own > images/distributions, without taking up the time of our already busy > sysadmins. We want them to take control of provisioning their systems, > from start to finish, all on their own. We simply provide the install > mechanism. > > If I need to fill in any gaps here, let me know. > Yep... It's going to be difficult to model the behaviors that are important for a lot of different sites that are trying to replicate different existing policies. So, yes, this definitely points down the module route. This seems to say that some users should be able to add distros, and edit the ones they've added, but not modify distros that belong to others. Right? Cobbler doesn't have the capability to upload initrd/kernel files to the WebUI yet, but as we do things like make "cobbler import" web accessible, that is a direction we could consider. Patches always welcome, of course :) > > Modules ftw! > > :) > > Yes, we need authorization/authentication at CLI, as well as webUI. > Not everybody wants to use a webui and not everybody wants to use a CLI, > so we need to provide an interface for both to keep them all sweet. > Most likely all the security infrastructure will be implemented at the web services layer ... so this would mean remoting the CLI. I'd rather not do this when SSH works so well and it's a kludge to maintain/develop otherwise. If you've got a specific need for a remote app, you could write something simple using the XMLRPC API. I'm guessing that would be an app that did the equivalent of "system edit" for people who just wanted to modify the boot configurations of their systems, etc. From swissslinky at gmail.com Mon Nov 12 16:50:07 2007 From: swissslinky at gmail.com (Dan) Date: Mon, 12 Nov 2007 17:50:07 +0100 Subject: [et-mgmt-tools] Re: [SOLVED] webui error In-Reply-To: <4738746D.7050304@redhat.com> References: <1194873373.5439.12.camel@slinky> <4738746D.7050304@redhat.com> Message-ID: <1194886207.5439.79.camel@slinky> On Mon, 2007-11-12 at 10:42 -0500, Michael DeHaan wrote: > > [client 128.141.57.220] configuration error: couldn't check user. No user file?: /cgi-bin/cobbler/webui.cgi > > > > Hmmm .... I haven't seen this before. > > What's your test system? Anything strange in your httpd.conf? as always, EL4 ;-) Good news is, AuthUserFile to AuthDigestFile and I'm smiling again :) From crobinso at redhat.com Mon Nov 12 17:36:38 2007 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 12 Nov 2007 12:36:38 -0500 Subject: [et-mgmt-tools] [PATCH] Rework virtinst device lists for install In-Reply-To: <20071108020011.GA5378@redhat.com> References: <47323B0E.2070904@redhat.com> <20071108020011.GA5378@redhat.com> Message-ID: <47388F26.1010000@redhat.com> Daniel P. Berrange wrote: > On Wed, Nov 07, 2007 at 05:24:14PM -0500, Cole Robinson wrote: >> The following patch changes around how the 'disks' and 'nics' lists in a >> Guest object are used during an install. >> >> These lists are the public attributes used to specify the devices to >> connect to the guest at install time. Currently, during the actual >> install, these lists can be manipulated by the installer, to add a >> boot.iso as a CDROM disk to use for the install, for example ('nics' >> actually isn't altered during any install path but I wanted to be >> consistent.) This causes issues if the install fails, but the Guest object >> is kept around to try again (i.e. virt-manager): any re-attempt would >> append another cdrom disk based off the boot.iso. >> >> Rather than have an error cleanup restore things to their post install >> state, which would probably cause this bug to pop up again if another >> error path was added, I went with a small reorg which seems to be the >> right way to fix this. 'disks' and 'nics' remain but they are copied over >> to private lists at the start of the install to be used for all >> mid-install disk/nic additions. The public interface remains the same, its >> just behind the scenes workings that are shuffled. > > ACK, looks good to me. > > > Regards, > Dan. I just applied this. http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=ebf9464130c6 - Cole -- Cole Robinson crobinso at redhat.com From Greg.Caetano at hp.com Mon Nov 12 19:05:34 2007 From: Greg.Caetano at hp.com (Caetano, Greg) Date: Mon, 12 Nov 2007 19:05:34 +0000 Subject: [et-mgmt-tools] Cobbler 0.6.3 import error message regarding kickstart file Message-ID: Cobbler 0.6.3 on RHEL51 [root at hpmgmt cobbler]# cobbler import --name=rhel51 --available-as=nfs://192.168.0.1/var/www/html/kits/RHEL51/i386 --path=/var/www/html/RHEL51/i386 ---------------- (adding distros) - creating new distro: rhel51-i386 - creating new profile: rhel51-i386 - creating new distro: rhel51-xen-i386 - creating new profile: rhel51-xen-i386 ---------------- (associating kickstarts) - finding default kickstart template for redhat 5.0 - tree: nfs://192.168.0.1/var/www/html/kits/RHEL51/i386/ - finding default kickstart template for redhat 5.0 - tree: nfs://192.168.0.1/var/www/html/kits/RHEL51/i386/ ---------------- (syncing) sync distro: rhel51-i386 sync distro: rhel51-xen-i386 sync profile: rhel51-i386 Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/cobbler/action_sync.py", line 372, in validate_kickstart_for_specific_profile self.apply_template(kfile, meta, dest) File "/usr/lib/python2.4/site-packages/cobbler/action_sync.py", line 594, in apply_template (server, dir) = rest.split(":",2) ValueError: need more than 1 value to unpack Error while rendering kickstart file /etc/cobbler/kickstart_fc6.ks to /var/www/cobbler/kickstarts/rhel51-i386/ks.cfg [root at hpmgmt cobbler]# Greg Caetano Chicago, IL greg.caetano at hp.com From mdehaan at redhat.com Mon Nov 12 19:26:32 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 12 Nov 2007 14:26:32 -0500 Subject: [et-mgmt-tools] Cobbler 0.6.3 import error message regarding kickstart file In-Reply-To: References: Message-ID: <4738A8E8.7040605@redhat.com> Caetano, Greg wrote: > Cobbler 0.6.3 on RHEL51 > > [root at hpmgmt cobbler]# cobbler import --name=rhel51 --available-as=nfs://192.168.0.1/var/www/html/kits/RHEL51/i386 --path=/var/www/html/RHEL51/i386 > ---------------- (adding distros) > - creating new distro: rhel51-i386 > - creating new profile: rhel51-i386 > - creating new distro: rhel51-xen-i386 > - creating new profile: rhel51-xen-i386 > ---------------- (associating kickstarts) > - finding default kickstart template for redhat 5.0 > - tree: nfs://192.168.0.1/var/www/html/kits/RHEL51/i386/ > - finding default kickstart template for redhat 5.0 > - tree: nfs://192.168.0.1/var/www/html/kits/RHEL51/i386/ > ---------------- (syncing) > sync distro: rhel51-i386 > sync distro: rhel51-xen-i386 > sync profile: rhel51-i386 > Traceback (most recent call last): > File "/usr/lib/python2.4/site-packages/cobbler/action_sync.py", line 372, in validate_kickstart_for_specific_profile > self.apply_template(kfile, meta, dest) > File "/usr/lib/python2.4/site-packages/cobbler/action_sync.py", line 594, in apply_template > (server, dir) = rest.split(":",2) > ValueError: need more than 1 value to unpack > Error while rendering kickstart file /etc/cobbler/kickstart_fc6.ks to /var/www/cobbler/kickstarts/rhel51-i386/ks.cfg > [root at hpmgmt cobbler]# > > > > > Greg Caetano > Chicago, IL > greg.caetano at hp.com > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > Looks like you are missing a colon in the NFS path. See how it is documented in the manpage and compare with what you have in cobbler. From Greg.Caetano at hp.com Mon Nov 12 19:42:30 2007 From: Greg.Caetano at hp.com (Caetano, Greg) Date: Mon, 12 Nov 2007 19:42:30 +0000 Subject: [et-mgmt-tools] [SOLVED] Cobbler 0.6.3 import error message regarding kickstart file In-Reply-To: <4738A8E8.7040605@redhat.com> References: <4738A8E8.7040605@redhat.com> Message-ID: Yes... Adding the colon after the server ip in the nfs string clears up the issue thanks -----Original Message----- From: et-mgmt-tools-bounces at redhat.com [mailto:et-mgmt-tools-bounces at redhat.com] On Behalf Of Michael DeHaan Sent: Monday, November 12, 2007 1:27 PM To: Fedora/Linux Management Tools Subject: Re: [et-mgmt-tools] Cobbler 0.6.3 import error message regarding kickstart file Caetano, Greg wrote: > Cobbler 0.6.3 on RHEL51 > > [root at hpmgmt cobbler]# cobbler import --name=rhel51 > --available-as=nfs://192.168.0.1/var/www/html/kits/RHEL51/i386 > --path=/var/www/html/RHEL51/i386 > ---------------- (adding distros) > - creating new distro: rhel51-i386 > - creating new profile: rhel51-i386 > - creating new distro: rhel51-xen-i386 > - creating new profile: rhel51-xen-i386 > ---------------- (associating kickstarts) > - finding default kickstart template for redhat 5.0 > - tree: nfs://192.168.0.1/var/www/html/kits/RHEL51/i386/ > - finding default kickstart template for redhat 5.0 > - tree: nfs://192.168.0.1/var/www/html/kits/RHEL51/i386/ > ---------------- (syncing) > sync distro: rhel51-i386 > sync distro: rhel51-xen-i386 > sync profile: rhel51-i386 > Traceback (most recent call last): > File "/usr/lib/python2.4/site-packages/cobbler/action_sync.py", line 372, in validate_kickstart_for_specific_profile > self.apply_template(kfile, meta, dest) > File "/usr/lib/python2.4/site-packages/cobbler/action_sync.py", line 594, in apply_template > (server, dir) = rest.split(":",2) > ValueError: need more than 1 value to unpack Error while rendering > kickstart file /etc/cobbler/kickstart_fc6.ks to > /var/www/cobbler/kickstarts/rhel51-i386/ks.cfg > [root at hpmgmt cobbler]# > > > > > Greg Caetano > Chicago, IL > greg.caetano at hp.com > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > Looks like you are missing a colon in the NFS path. See how it is documented in the manpage and compare with what you have in cobbler. _______________________________________________ et-mgmt-tools mailing list et-mgmt-tools at redhat.com https://www.redhat.com/mailman/listinfo/et-mgmt-tools From crobinso at redhat.com Wed Nov 14 18:13:13 2007 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 14 Nov 2007 13:13:13 -0500 Subject: [et-mgmt-tools] [PATCH] virt-manager: log uncaught exceptions Message-ID: <473B3AB9.50007@redhat.com> The attached patch alters sys.excepthook to log uncaught exceptions. Currently in virt-manager.py the main() call is wrapped in a try...except block that was assumed to log uncaught exceptions, but the gtk.main() loop does not raise exceptions (hence why the app does not crash anytime an exception is uncaught). Info on this was found here: http://faq.pygtk.org/index.py?req=show&file=faq20.010.htp Any comments welcome. - Cole -- Cole Robinson crobinso at redhat.com -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: virt-manager-log-exceptions-patch URL: From hbrock at redhat.com Wed Nov 14 18:15:45 2007 From: hbrock at redhat.com (Hugh O. Brock) Date: Wed, 14 Nov 2007 13:15:45 -0500 Subject: [et-mgmt-tools] [PATCH] virt-manager: log uncaught exceptions In-Reply-To: <473B3AB9.50007@redhat.com> References: <473B3AB9.50007@redhat.com> Message-ID: <20071114181544.GC17977@redhat.com> On Wed, Nov 14, 2007 at 01:13:13PM -0500, Cole Robinson wrote: > The attached patch alters sys.excepthook to log uncaught exceptions. > Currently in virt-manager.py the main() call is wrapped in a try...except > block that was assumed to log uncaught exceptions, but the gtk.main() loop > does not raise exceptions (hence why the app does not crash anytime an > exception is uncaught). > > Info on this was found here: > http://faq.pygtk.org/index.py?req=show&file=faq20.010.htp > > Any comments welcome. > > - Cole > +1 this will help a lot with all those "virt-manager exits for no reason" BZs... --H From rjones at redhat.com Wed Nov 14 18:19:50 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 14 Nov 2007 18:19:50 +0000 Subject: [et-mgmt-tools] Debian packages for virt-manager, virt-install, libvirt etc. Message-ID: <473B3C46.6080109@redhat.com> I sent the attached messages yesterday to some Debian lists, but they may interest people here too. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- An embedded message was scrubbed... From: "Richard W.M. Jones" Subject: [PATCH] bug #402249 - include header files Date: Tue, 13 Nov 2007 11:12:13 +0000 Size: 6448 URL: -------------- next part -------------- An embedded message was scrubbed... From: "Richard W.M. Jones" Subject: bug #384300 - libvirt package for Debian Date: Tue, 13 Nov 2007 11:17:37 +0000 Size: 6634 URL: -------------- next part -------------- An embedded message was scrubbed... From: "Richard W.M. Jones" Subject: Debian package for gtk-vnc 0.2.0 Date: Tue, 13 Nov 2007 14:55:28 +0000 Size: 6261 URL: -------------- next part -------------- An embedded message was scrubbed... From: "Richard W.M. Jones" Subject: bug #384443 - packages for virt-install and virt-manager Date: Tue, 13 Nov 2007 15:01:04 +0000 Size: 7487 URL: -------------- next part -------------- An embedded message was scrubbed... From: "Richard W.M. Jones" Subject: Re: [Libvir] bug #384443 - packages for virt-install and virt-manager Date: Tue, 13 Nov 2007 16:39:20 +0000 Size: 6237 URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From mdehaan at redhat.com Wed Nov 14 19:52:33 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 14 Nov 2007 14:52:33 -0500 Subject: [et-mgmt-tools] [ANNOUNCE] Cobbler 0.6.4 (bugfixes) Message-ID: <473B5201.8010707@redhat.com> Hi folks, There were a few bugs in Cobbler 0.6.3 that warranted a new release. If you are running 0.6.3, you will want to upgrade to 0.6.4. If you're still on 0.6.2, there's no pressing need, but that release is still over a month old, so I would recommend it, though it is less important. Basically 0.6.4 contains fixes to the handling of yum repositories discovered during Cobbler import and also fixes a bug in the sync logic that results in kickstart URLs and metadata being mismatched between profiles and systems. Due to popular demand (and a lot of larger features on the pipe), new features will go into the 0.7.X branch (to be established shortly), while I will maintain 0.6.X for bugfixes. I don't expect the 0.6.X to be changed much, and only major fixes will be applied to 0.6.X. http://cobbler.et.redhat.com/download/cobbler-0.6.4-2.src.rpm Koan does not need to be updated.... Pushing to mirrors shortly. --Michael From bill at bfccomputing.com Wed Nov 14 20:24:07 2007 From: bill at bfccomputing.com (Bill McGonigle) Date: Wed, 14 Nov 2007 15:24:07 -0500 Subject: [et-mgmt-tools] cobbler/koan/python-cheetah blocking yum upgrade? Message-ID: <373ACE90-32EF-4096-AAE3-6F702148FE65@bfccomputing.com> I'm attempting a yum upgrade (fc6 to f7) on a machine, and yum resolves all dependencies except for cobbler, koan and python- cheetah. For some reason it appears to be looking at the fc6 packages, which is odd, it's not doing that for any other packages. The repos are synced with 'cobbler reposync'. --allow-downgrade doesn't help. Oddly, neither does '--exclude=cobbler --exclude=koan --exclude=python-cheetah'. Has anybody tripped over this one before? -Bill --> Running transaction check # of Deps = 3 Dep Number: 1/3 cobbler requires: python(abi) = 2.4 --> Processing Dependency: python(abi) = 2.4 for package: cobbler Looking for ('python(abi)', 'EQ', ('0', '2.4', None)) as a requirement of cobbler - 0.6.3-2.fc6.noarch Requiring package is installed: cobbler - 0.6.3-2.fc6.noarch Resolving for installed requiring package: cobbler - 0.6.3-2.fc6.noarch Resolving for requirement: python(abi) = 2.4 Needed Require is not a package name. Looking up: python(abi) = 2.4 Potential Provider: python.i386 0:2.4.4-1.fc6 Mode is u for provider of python(abi) = 2.4: python.i386 0:2.4.4-1.fc6 Mode for pkg providing python(abi) = 2.4: u Cannot find an update path for dep for: python(abi) = 2.4 Searching pkgSack for dep: python(abi) Potential match for python(abi) from python - 2.5-12.fc7.i386 Potential match for python(abi) from python - 2.5-14.fc7.i386 processing dep took: 0.010873 Dep Number: 2/3 koan requires: python(abi) = 2.4 --> Processing Dependency: python(abi) = 2.4 for package: koan Looking for ('python(abi)', 'EQ', ('0', '2.4', None)) as a requirement of koan - 0.6.3-3.fc6.noarch Requiring package is installed: koan - 0.6.3-3.fc6.noarch Resolving for installed requiring package: koan - 0.6.3-3.fc6.noarch Resolving for requirement: python(abi) = 2.4 Needed Require has already been looked up, cheating Potential Provider: python.i386 0:2.4.4-1.fc6 Mode is u for provider of python(abi) = 2.4: python.i386 0:2.4.4-1.fc6 Mode for pkg providing python(abi) = 2.4: u Cannot find an update path for dep for: python(abi) = 2.4 Searching pkgSack for dep: python(abi) Potential match for python(abi) from python - 2.5-12.fc7.i386 Potential match for python(abi) from python - 2.5-14.fc7.i386 processing dep took: 0.008095 Dep Number: 3/3 python-cheetah requires: python(abi) = 2.4 --> Processing Dependency: python(abi) = 2.4 for package: python-cheetah Looking for ('python(abi)', 'EQ', ('0', '2.4', None)) as a requirement of python-cheetah - 2.0-0.6.rc8.fc6.i386 Requiring package is installed: python-cheetah - 2.0-0.6.rc8.fc6.i386 Resolving for installed requiring package: python-cheetah - 2.0-0.6.rc8.fc6.i386 Resolving for requirement: python(abi) = 2.4 Needed Require has already been looked up, cheating Potential Provider: python.i386 0:2.4.4-1.fc6 Mode is u for provider of python(abi) = 2.4: python.i386 0:2.4.4-1.fc6 Mode for pkg providing python(abi) = 2.4: u Cannot find an update path for dep for: python(abi) = 2.4 Searching pkgSack for dep: python(abi) Potential match for python(abi) from python - 2.5-12.fc7.i386 Potential match for python(abi) from python - 2.5-14.fc7.i386 processing dep took: 0.007931 miss = 3 conf = 0 CheckDeps = 0 --> Finished Dependency Resolution Dependency Process ending Error: Missing Dependency: python(abi) = 2.4 is needed by package cobbler Error: Missing Dependency: python(abi) = 2.4 is needed by package koan Error: Missing Dependency: python(abi) = 2.4 is needed by package python-cheetah From rigg0022 at umn.edu Wed Nov 14 20:35:11 2007 From: rigg0022 at umn.edu (Riggs, Ben) Date: Wed, 14 Nov 2007 14:35:11 -0600 Subject: [et-mgmt-tools] [PATCH] Added with_triggers=True variable to functions that call triggers. Message-ID: <473B5BFF.9090707@umn.edu> From mdehaan at redhat.com Wed Nov 14 20:39:43 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 14 Nov 2007 15:39:43 -0500 Subject: [et-mgmt-tools] cobbler/koan/python-cheetah blocking yum upgrade? In-Reply-To: <373ACE90-32EF-4096-AAE3-6F702148FE65@bfccomputing.com> References: <373ACE90-32EF-4096-AAE3-6F702148FE65@bfccomputing.com> Message-ID: <473B5D0F.1000703@redhat.com> Bill McGonigle wrote: > I'm attempting a yum upgrade (fc6 to f7) on a machine, and yum > resolves all dependencies except for cobbler, koan and python-cheetah. > For some reason it appears to be looking at the fc6 packages, which is > odd, it's not doing that for any other packages. The repos are synced > with 'cobbler reposync'. --allow-downgrade doesn't help. Oddly, > neither does '--exclude=cobbler --exclude=koan --exclude=python-cheetah'. > > Has anybody tripped over this one before? > > -Bill Those packages are not in the f7 "core" repo you have, hence the problem. AFAIK Anaconda upgrades will update everything they can and leave the other packages out, which you could then update later. AFAIK upgrading directly from yum (versus a CD) is usually not recommended. --Michael > > --> Running transaction check > # of Deps = 3 > > Dep Number: 1/3 > > cobbler requires: python(abi) = 2.4 > --> Processing Dependency: python(abi) = 2.4 for package: cobbler > Looking for ('python(abi)', 'EQ', ('0', '2.4', None)) as a requirement > of cobbler - 0.6.3-2.fc6.noarch > Requiring package is installed: cobbler - 0.6.3-2.fc6.noarch > Resolving for installed requiring package: cobbler - 0.6.3-2.fc6.noarch > Resolving for requirement: python(abi) = 2.4 > Needed Require is not a package name. Looking up: python(abi) = 2.4 > Potential Provider: python.i386 0:2.4.4-1.fc6 > Mode is u for provider of python(abi) = 2.4: python.i386 0:2.4.4-1.fc6 > Mode for pkg providing python(abi) = 2.4: u > Cannot find an update path for dep for: python(abi) = 2.4 > Searching pkgSack for dep: python(abi) > Potential match for python(abi) from python - 2.5-12.fc7.i386 > Potential match for python(abi) from python - 2.5-14.fc7.i386 > processing dep took: 0.010873 > > Dep Number: 2/3 > > koan requires: python(abi) = 2.4 > --> Processing Dependency: python(abi) = 2.4 for package: koan > Looking for ('python(abi)', 'EQ', ('0', '2.4', None)) as a requirement > of koan - 0.6.3-3.fc6.noarch > Requiring package is installed: koan - 0.6.3-3.fc6.noarch > Resolving for installed requiring package: koan - 0.6.3-3.fc6.noarch > Resolving for requirement: python(abi) = 2.4 > Needed Require has already been looked up, cheating > Potential Provider: python.i386 0:2.4.4-1.fc6 > Mode is u for provider of python(abi) = 2.4: python.i386 0:2.4.4-1.fc6 > Mode for pkg providing python(abi) = 2.4: u > Cannot find an update path for dep for: python(abi) = 2.4 > Searching pkgSack for dep: python(abi) > Potential match for python(abi) from python - 2.5-12.fc7.i386 > Potential match for python(abi) from python - 2.5-14.fc7.i386 > processing dep took: 0.008095 > > Dep Number: 3/3 > > python-cheetah requires: python(abi) = 2.4 > --> Processing Dependency: python(abi) = 2.4 for package: python-cheetah > Looking for ('python(abi)', 'EQ', ('0', '2.4', None)) as a requirement > of python-cheetah - 2.0-0.6.rc8.fc6.i386 > Requiring package is installed: python-cheetah - 2.0-0.6.rc8.fc6.i386 > Resolving for installed requiring package: python-cheetah - > 2.0-0.6.rc8.fc6.i386 > Resolving for requirement: python(abi) = 2.4 > Needed Require has already been looked up, cheating > Potential Provider: python.i386 0:2.4.4-1.fc6 > Mode is u for provider of python(abi) = 2.4: python.i386 0:2.4.4-1.fc6 > Mode for pkg providing python(abi) = 2.4: u > Cannot find an update path for dep for: python(abi) = 2.4 > Searching pkgSack for dep: python(abi) > Potential match for python(abi) from python - 2.5-12.fc7.i386 > Potential match for python(abi) from python - 2.5-14.fc7.i386 > processing dep took: 0.007931 > miss = 3 > conf = 0 > CheckDeps = 0 > --> Finished Dependency Resolution > Dependency Process ending > Error: Missing Dependency: python(abi) = 2.4 is needed by package cobbler > Error: Missing Dependency: python(abi) = 2.4 is needed by package koan > Error: Missing Dependency: python(abi) = 2.4 is needed by package > python-cheetah > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From mdehaan at redhat.com Wed Nov 14 20:41:16 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 14 Nov 2007 15:41:16 -0500 Subject: [et-mgmt-tools] [PATCH] Added with_triggers=True variable to functions that call triggers. In-Reply-To: <473B5BFF.9090707@umn.edu> References: <473B5BFF.9090707@umn.edu> Message-ID: <473B5D6C.10401@redhat.com> Riggs, Ben wrote: > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools Ben, This attachment seems to be zero-length ... --Michael From crobinso at redhat.com Wed Nov 14 21:14:51 2007 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 14 Nov 2007 16:14:51 -0500 Subject: [et-mgmt-tools] [PATCH] virt-manager: log uncaught exceptions In-Reply-To: <20071114181544.GC17977@redhat.com> References: <473B3AB9.50007@redhat.com> <20071114181544.GC17977@redhat.com> Message-ID: <473B654B.1080707@redhat.com> Hugh O. Brock wrote: > On Wed, Nov 14, 2007 at 01:13:13PM -0500, Cole Robinson wrote: >> The attached patch alters sys.excepthook to log uncaught exceptions. >> Currently in virt-manager.py the main() call is wrapped in a try...except >> block that was assumed to log uncaught exceptions, but the gtk.main() loop >> does not raise exceptions (hence why the app does not crash anytime an >> exception is uncaught). >> >> Info on this was found here: >> http://faq.pygtk.org/index.py?req=show&file=faq20.010.htp >> >> Any comments welcome. >> >> - Cole >> > +1 this will help a lot with all those "virt-manager exits for no reason" BZs... > > --H > I just committed this: http://hg.et.redhat.com/virt/applications/virt-manager--devel?cs=9da820df4011 - Cole -- Cole Robinson crobinso at redhat.com From mdehaan at redhat.com Wed Nov 14 21:31:06 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 14 Nov 2007 16:31:06 -0500 Subject: [et-mgmt-tools] Cobbler 'devel' branch created in git Message-ID: <473B691A.8020503@redhat.com> FYI ... For those pulling cobbler from git, there is now a remote branch for 'devel' (currently 0.7.x) as well as the existing 'master' (currently 0.6.x). Releases are still organized by tags. Branches are browseable in gitweb by clicking on any of the links in the "heads" section toward the bottom. See http://git.fedoraproject.org/?p=hosted/cobbler;a=summary --Michael From robertn at the-nelsons.org Thu Nov 15 07:50:47 2007 From: robertn at the-nelsons.org (Robert Nelson) Date: Wed, 14 Nov 2007 23:50:47 -0800 Subject: [et-mgmt-tools] Virt-Manager: Supporting additional para-virtual OS's Message-ID: <473BFA57.7070601@the-nelsons.org> I've been trying to add support for additional para-virtual operating systems (OpenSolaris and Debian) to virt-manager. There is no problem getting the initial kernel and ramdisk, however there is no way to specify the target disk node based on the OS or distro. Also some OS's don't support the virtual frame buffer driver but there is no way to prevent the XML for it being created. I can't see how this could be done without doing some major restructuring of the code and creating a new class to encapsulate all the target specific information. Is there any plan on doing something like this? If someone were to do it, are the changes likely to be incorporated? From miguel.costa at neoscopio.com Thu Nov 15 13:34:40 2007 From: miguel.costa at neoscopio.com (Miguel Costa) Date: Thu, 15 Nov 2007 13:34:40 +0000 Subject: [et-mgmt-tools] Cobbler/Koan ignores my virt-bridge settings Message-ID: <473C4AF0.7080302@neoscopio.com> Hello all! I've been trying out cobbler ( 0.6.3-2) on CentOS5 and it's a wonderful tool , nice work! I (almost effortlessly) managed to install cobbler on machine1 and install a second machine, with pxe, unattended, using a slightly modified kickstart from machine1. Cool. I also had no problem installing virtual machines on machine2, using koan connecting to cobbler on machine1. Even cooler. However, I can't install virtual-machines on machine1, using koan and cobbler on the same machine, and I think the problem is that the newly created virtual-machines cannot connect to cobbler. Koan creates the virtual-machine and starts it, but then it either gets stuck waiting for an address (CentOS5 distro) or just shuts down (F8 distro). I have two network interfaces - eth0 is the internal interface, connected to machine2 - dhcpd and tftpd are only listening here. eth1 is the outgoing interface. I modified xen-config.sxp according to the docs, creating network-xen-multi-bridge in order to create two bridges instead of one, and that seems ok also. In /var/lib/cobbler/settings, I have default_virt_bridge: xenbr0 In the virtual machines profile, the default virtual bridge is xenbr0 When I run koan, I include --virt-bridge=xenbr0 However, when I look at the generated virtual machine profiles in /etc/xen, it always selects xenbr1! (e.g. vif = [ 'mac=00:16:3e:74:a9:3a, bridge=xenbr1', ]) Hoping for a simple 'it's the _____, stupid!" :) Thanks, Miguel -------------- next part -------------- A non-text attachment was scrubbed... Name: miguel.costa.vcf Type: text/x-vcard Size: 334 bytes Desc: not available URL: From hbrock at redhat.com Thu Nov 15 14:19:11 2007 From: hbrock at redhat.com (Hugh O. Brock) Date: Thu, 15 Nov 2007 09:19:11 -0500 Subject: [et-mgmt-tools] Virt-Manager: Supporting additional para-virtual OS's In-Reply-To: <473BFA57.7070601@the-nelsons.org> References: <473BFA57.7070601@the-nelsons.org> Message-ID: <20071115141911.GF17977@redhat.com> On Wed, Nov 14, 2007 at 11:50:47PM -0800, Robert Nelson wrote: > I've been trying to add support for additional para-virtual operating > systems (OpenSolaris and Debian) to virt-manager. There is no problem > getting the initial kernel and ramdisk, however there is no way to > specify the target disk node based on the OS or distro. Also some OS's > don't support the virtual frame buffer driver but there is no way to > prevent the XML for it being created. > > I can't see how this could be done without doing some major > restructuring of the code and creating a new class to encapsulate all > the target specific information. Is there any plan on doing something > like this? If someone were to do it, are the changes likely to be > incorporated? Hello Robert, thanks for your interest. I'm not sure I understand what you mean by "specify the target disk node based on the OS or distro"? I would have no problem with adding a checkbox to virt-manager that would have the effect of passing the --nographics flag to virtinst if you can determine a good place to do it. I don't think we want to spend a whole ton of time creating a new class to take different PV guest OSes into account, though. Having said that, have you looked at the *Installer class family in virtinst? Is there a way we could extend that to do what you need? Take care, --Hugh From bill at bfccomputing.com Thu Nov 15 14:46:45 2007 From: bill at bfccomputing.com (Bill McGonigle) Date: Thu, 15 Nov 2007 09:46:45 -0500 Subject: [et-mgmt-tools] cobbler/koan/python-cheetah blocking yum upgrade? In-Reply-To: <473B5D0F.1000703@redhat.com> References: <373ACE90-32EF-4096-AAE3-6F702148FE65@bfccomputing.com> <473B5D0F.1000703@redhat.com> Message-ID: <1D95FEF9-6B9D-4627-932F-A52333111FB9@bfccomputing.com> On Nov 14, 2007, at 15:39, Michael DeHaan wrote: > Those packages are not in the f7 "core" repo you have, hence the > problem. python-cheetah is in there, at least. cobbler and koan are in the updates repo - I *think* yum does the right thing there, but maybe not. It could also be that I'm not using cobbler reposync properly - previously I was rsyncing mirrors with my own scripts, which I'm looking forward to abandoning in favor of cobbler's! Do these look appropriate?: --- - arch: '' createrepo_flags: -c cache depth: 2 keep_updated: True mirror: 'http://mirror.anl.gov/pub/fedora/linux/releases/7/ Everything/i386/os' name: f7i386 parent: ~ rpm_list: '' - arch: '' createrepo_flags: -c cache depth: 2 keep_updated: True mirror: 'http://mirrors.kernel.org/fedora/updates/7/i386/' name: f7i386updates parent: ~ rpm_list: '' Aside: the docs use repo names like this, but yum doesn't seem to be able to interpret "$basearchupdates", so f7i386-updates might be a better doc example, since yum can handle "$basearch-updates". > AFAIK Anaconda upgrades will update everything they can and leave > the other packages out, which you could then update later. Come to think of it, yum skip-broken might handle this as well. Just for grins, if I were to: rpm -e python-cheetah cobbler koan would I lose my data and config files or just the programs and rpmdb entries? I could re-install the packages right after upgrade. > AFAIK upgrading directly from yum (versus a CD) is usually not > recommended. Yeah, that's the official position, but virtualization makes this even tougher - I'd have to take down 8 'machines' for a long time vs just a quick reboot. Before xen, only one machine was affected; online upgrades are an even bigger win today. Despite the official position, I have machines that work great having been yum upgraded from RH9 to F7, so far, F8 I'm just starting with. This is all predicated on my observation that F7 and F8 don't work under an FC6 cobbler/xen install. If others have contrary experience, I'd sure like to hear it - that would take some pressure off an upgrade timeframe. I've looked for a matrix/docs of which versions of Fedora and/or Xen Dom0's can host which versions in DomU's, but I haven't been able to find it yet. On the latest cobbler/koan under FC6 I can deploy other FC6 no problem, but F7 and F8 cause the Xen guest to crash during boot (according to xend.log). Thanks, -Bill ----- Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 bill at bfccomputing.com Cell: 603.252.2606 http://www.bfccomputing.com/ Page: 603.442.1833 Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf From mdehaan at redhat.com Thu Nov 15 16:20:07 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 15 Nov 2007 11:20:07 -0500 Subject: [et-mgmt-tools] Cobbler/Koan ignores my virt-bridge settings In-Reply-To: <473C4AF0.7080302@neoscopio.com> References: <473C4AF0.7080302@neoscopio.com> Message-ID: <473C71B7.3090203@redhat.com> Miguel Costa wrote: > Hello all! > > > However, I can't install virtual-machines on machine1, using koan and > cobbler on the same machine, and I think the problem is that the newly > created virtual-machines cannot connect to cobbler. > The virtual machines themselves don't need to connect to cobbler, so that can't be it... > Koan creates the virtual-machine and starts it, but then it either > gets stuck waiting for an address (CentOS5 distro) or just shuts down > (F8 distro). Koan keeps some logs in ~/.koan/koan.log that includes output from libvirt that may help explain what is going on. Is it possible you are not serving DHCP on the bridged interface in question? That doesn't really explain the shutdown though, but there may be something in the log. In practice, it seems KVM works better than Xen on Fedora, at least for me. > > I have two network interfaces - eth0 is the internal interface, > connected to machine2 - dhcpd and tftpd are only listening here. > eth1 is the outgoing interface. > > I modified xen-config.sxp according to the docs, creating > network-xen-multi-bridge in order to create two bridges instead of > one, and that seems ok also. > > In /var/lib/cobbler/settings, I have default_virt_bridge: xenbr0 > > In the virtual machines profile, the default virtual bridge is xenbr0 > > When I run koan, I include --virt-bridge=xenbr0 > > However, when I look at the generated virtual machine profiles in > /etc/xen, it always selects xenbr1! (e.g. vif = [ > 'mac=00:16:3e:74:a9:3a, bridge=xenbr1', ]) To confirm, koan is also at version 0.6.3? That version uses bridge input verbatim, and it doesn't seem to make sense that something wants xenbr1 instead. Here are the instructions I use for bridge setup: https://hosted.fedoraproject.org/projects/cobbler/wiki/VirtNetworkingSetupForUseWithKoan > > Hoping for a simple 'it's the _____, stupid!" :) Wish I had that too :) Hopefully there will be something interesting in the logs. > > Thanks, > Miguel > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From mdehaan at redhat.com Thu Nov 15 16:23:45 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 15 Nov 2007 11:23:45 -0500 Subject: [et-mgmt-tools] cobbler/koan/python-cheetah blocking yum upgrade? In-Reply-To: <1D95FEF9-6B9D-4627-932F-A52333111FB9@bfccomputing.com> References: <373ACE90-32EF-4096-AAE3-6F702148FE65@bfccomputing.com> <473B5D0F.1000703@redhat.com> <1D95FEF9-6B9D-4627-932F-A52333111FB9@bfccomputing.com> Message-ID: <473C7291.8010402@redhat.com> Bill McGonigle wrote: > On Nov 14, 2007, at 15:39, Michael DeHaan wrote: > >> Those packages are not in the f7 "core" repo you have, hence the >> problem. > > python-cheetah is in there, at least. cobbler and koan are in the > updates repo - I *think* yum does the right thing there, but maybe not. > > It could also be that I'm not using cobbler reposync properly - > previously I was rsyncing mirrors with my own scripts, which I'm > looking forward to abandoning in favor of cobbler's! Do these look > appropriate?: > You really need to upgrade using the CD so Anaconda can come into the picture, and then upgrade cobbler after you finish the CD install. I don't believe yum upgrades from FC6 -> F7 were supposed to work. (Fortunately, there are such a thing as upgrade kickstarts, if you need to do a rollout to upgrade a lot of systems... so, yes, you could technically use Cobbler to upgrade other systems via PXE and/or koan after you get that done) > --- > - > arch: '' > createrepo_flags: -c cache > depth: 2 > keep_updated: True > mirror: > 'http://mirror.anl.gov/pub/fedora/linux/releases/7/Everything/i386/os' > name: f7i386 > parent: ~ > rpm_list: '' > - > arch: '' > createrepo_flags: -c cache > depth: 2 > keep_updated: True > mirror: 'http://mirrors.kernel.org/fedora/updates/7/i386/' > name: f7i386updates > parent: ~ > rpm_list: '' > > Aside: the docs use repo names like this, but yum doesn't seem to be > able to interpret "$basearchupdates", so f7i386-updates might be a > better doc example, since yum can handle "$basearch-updates". > >> AFAIK Anaconda upgrades will update everything they can and leave the >> other packages out, which you could then update later. > > Come to think of it, yum skip-broken might handle this as well. Just > for grins, if I were to: > > rpm -e python-cheetah cobbler koan > > would I lose my data and config files or just the programs and rpmdb > entries? I could re-install the packages right after upgrade. > >> AFAIK upgrading directly from yum (versus a CD) is usually not >> recommended. > > Yeah, that's the official position, but virtualization makes this even > tougher - I'd have to take down 8 'machines' for a long time vs just a > quick reboot. Before xen, only one machine was affected; online > upgrades are an even bigger win today. > > Despite the official position, I have machines that work great having > been yum upgraded from RH9 to F7, so far, F8 I'm just starting with. > > This is all predicated on my observation that F7 and F8 don't work > under an FC6 cobbler/xen install. If others have contrary experience, > I'd sure like to hear it - that would take some pressure off an > upgrade timeframe. I've looked for a matrix/docs of which versions of > Fedora and/or Xen Dom0's can host which versions in DomU's, but I > haven't been able to find it yet. On the latest cobbler/koan under FC6 > I can deploy other FC6 no problem, but F7 and F8 cause the Xen guest > to crash during boot (according to xend.log). > > Thanks, > -Bill > > ----- > Bill McGonigle, Owner Work: 603.448.4440 > BFC Computing, LLC Home: 603.448.1668 > bill at bfccomputing.com Cell: 603.252.2606 > http://www.bfccomputing.com/ Page: 603.442.1833 > Blog: http://blog.bfccomputing.com/ > VCard: http://bfccomputing.com/vcard/bill.vcf > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From bill at bfccomputing.com Thu Nov 15 16:44:31 2007 From: bill at bfccomputing.com (Bill McGonigle) Date: Thu, 15 Nov 2007 11:44:31 -0500 Subject: [et-mgmt-tools] cobbler/koan/python-cheetah blocking yum upgrade? In-Reply-To: <473C7291.8010402@redhat.com> References: <373ACE90-32EF-4096-AAE3-6F702148FE65@bfccomputing.com> <473B5D0F.1000703@redhat.com> <1D95FEF9-6B9D-4627-932F-A52333111FB9@bfccomputing.com> <473C7291.8010402@redhat.com> Message-ID: On Nov 15, 2007, at 11:23, Michael DeHaan wrote: > I don't believe yum upgrades from FC6 -> F7 were supposed to work. They do (there's even a howto entry on the Wiki about it). I've done several typical machines without problems (it saves on airfare!) but this is my first cobbler/koan attempt. I'll try backing up everything and erasing the packages and see what happens, then report back. Thanks, -Bill ----- Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 bill at bfccomputing.com Cell: 603.252.2606 http://www.bfccomputing.com/ Page: 603.442.1833 Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf From miguel.costa at neoscopio.com Thu Nov 15 17:30:58 2007 From: miguel.costa at neoscopio.com (Miguel Costa) Date: Thu, 15 Nov 2007 17:30:58 +0000 Subject: [et-mgmt-tools] Cobbler/Koan ignores my virt-bridge settings In-Reply-To: <473C71B7.3090203@redhat.com> References: <473C4AF0.7080302@neoscopio.com> <473C71B7.3090203@redhat.com> Message-ID: <473C8252.50309@neoscopio.com> Michael DeHaan wrote: > Miguel Costa wrote: >> Hello all! >> >> >> However, I can't install virtual-machines on machine1, using koan and >> cobbler on the same machine, and I think the problem is that the >> newly created virtual-machines cannot connect to cobbler. >> > > The virtual machines themselves don't need to connect to cobbler, so > that can't be it... You're right, I meant to the dhcp and install tree managed by cobbler > >> Koan creates the virtual-machine and starts it, but then it either >> gets stuck waiting for an address (CentOS5 distro) or just shuts down >> (F8 distro). > > Koan keeps some logs in ~/.koan/koan.log that includes output from > libvirt that may help explain what is going on. It just logs "Creating guest from" and then the xml configuration, which seems ok except for the bridge being xenbr1 instead of xenbr0, and then "Saving XM config file '# Automatically generated xen config file", and the file that gets saved in /etc/xen. > Is it possible you are not serving > DHCP on the bridged interface in question? It's serving on eth0 - if I could change the virtual-bridge to xenbr0, it should work, right? > That doesn't really explain the shutdown though, but there may be > something in the log. Yes, but only Fedora 8 shuts down. CentOS 5 just can't connect to the (virtual) network. > > In practice, it seems KVM works better than Xen on Fedora, at least > for me. > >> >> I have two network interfaces - eth0 is the internal interface, >> connected to machine2 - dhcpd and tftpd are only listening here. >> eth1 is the outgoing interface. >> >> I modified xen-config.sxp according to the docs, creating >> network-xen-multi-bridge in order to create two bridges instead of >> one, and that seems ok also. >> >> In /var/lib/cobbler/settings, I have default_virt_bridge: xenbr0 >> >> In the virtual machines profile, the default virtual bridge is xenbr0 >> >> When I run koan, I include --virt-bridge=xenbr0 >> >> However, when I look at the generated virtual machine profiles in >> /etc/xen, it always selects xenbr1! (e.g. vif = [ >> 'mac=00:16:3e:74:a9:3a, bridge=xenbr1', ]) > > To confirm, koan is also at version 0.6.3? Oops! "It's the version mismatch, stupid!" :) I must have installed cobbler from epel-testing and koan from epel... (blushing) It's working now, thanks! Miguel -- Miguel Costa ------------------------------------------------------------------------ Neoscopio, S.A. Telefone: (+351) 220 301 500 Telem?vel: (+351) 919 173 602 Fax: (+351) 220 301 511 *_E-mail: miguel.costa at neoscopio.com_* Parque Tecnol?gico da UP Rua Actor Ferreira da Silva, 100 4200-298 Porto *www.neoscopio.com* -------------- next part -------------- A non-text attachment was scrubbed... Name: miguel.costa.vcf Type: text/x-vcard Size: 334 bytes Desc: not available URL: From dlutter at redhat.com Thu Nov 15 19:14:29 2007 From: dlutter at redhat.com (David Lutterkort) Date: Thu, 15 Nov 2007 19:14:29 +0000 Subject: [et-mgmt-tools] Virt-Manager: Supporting additional para-virtual OS's In-Reply-To: <20071115141911.GF17977@redhat.com> References: <473BFA57.7070601@the-nelsons.org> <20071115141911.GF17977@redhat.com> Message-ID: <1195154069.23538.5.camel@localhost.localdomain> On Thu, 2007-11-15 at 09:19 -0500, Hugh O. Brock wrote: > I would have no problem with adding a checkbox to virt-manager that > would have the effect of passing the --nographics flag to virtinst if > you can determine a good place to do it. I don't think we want to > spend a whole ton of time creating a new class to take different PV > guest OSes into account, though. Having said that, have you looked at > the *Installer class family in virtinst? Is there a way we could > extend that to do what you need? Another route (though one that takes more effort), is to base install on virt-image metadata - the idea is that we would ship stock virt-image files for installable OS's; those files would contain the salient bits about an OS (such as APIC/ACPI, whether to enable a graphics console, kernel cmdline for pv) virt-manager would have to modify those files a little before passing them off to virt-image, mostly to put things like the ISO location and path to the root disk in. David From hbrock at redhat.com Thu Nov 15 19:20:49 2007 From: hbrock at redhat.com (Hugh O. Brock) Date: Thu, 15 Nov 2007 14:20:49 -0500 Subject: [et-mgmt-tools] Virt-Manager: Supporting additional para-virtual OS's In-Reply-To: <1195154069.23538.5.camel@localhost.localdomain> References: <473BFA57.7070601@the-nelsons.org> <20071115141911.GF17977@redhat.com> <1195154069.23538.5.camel@localhost.localdomain> Message-ID: <20071115192049.GB29831@redhat.com> On Thu, Nov 15, 2007 at 07:14:29PM +0000, David Lutterkort wrote: > > Another route (though one that takes more effort), is to base install on > virt-image metadata - the idea is that we would ship stock virt-image > files for installable OS's; those files would contain the salient bits > about an OS (such as APIC/ACPI, whether to enable a graphics console, > kernel cmdline for pv) virt-manager would have to modify those files a > little before passing them off to virt-image, mostly to put things like > the ISO location and path to the root disk in. > That seems like the right way to do it. We need an image-packager though, right? --H From rigg0022 at umn.edu Thu Nov 15 19:46:18 2007 From: rigg0022 at umn.edu (Riggs, Ben) Date: Thu, 15 Nov 2007 13:46:18 -0600 Subject: [et-mgmt-tools] [PATCH] Added with_triggers=True variable to functions that call triggers. In-Reply-To: <473B5D6C.10401@redhat.com> References: <473B5BFF.9090707@umn.edu> <473B5D6C.10401@redhat.com> Message-ID: <473CA20A.4080006@umn.edu> Michael DeHaan wrote: > Ben, > > This attachment seems to be zero-length ... > > --Michael I'm confused, myself. I received this response from et-mgmt-tools-bounces at redhat.com: You are not allowed to post to this mailing list, and your message has been automatically rejected. If you think that your messages are being rejected in error, contact the mailing list owner at et-mgmt-tools-owner at redhat.com. --------------------------------------------------------------------- Subject: [PATCH] Added with_triggers=True variable to functions that call triggers. This allows one to pass with_triggers=False from the API to bypass triggers. It can be used to prevent infinite recursions caused by adding a system during a pre/post add trigger. From: Ben Riggs Date: Wed, 14 Nov 2007 14:27:21 -0600 --- cobbler/collection.py | 6 +++--- cobbler/collection_distros.py | 6 +++--- cobbler/collection_profiles.py | 6 +++--- cobbler/collection_repos.py | 6 +++--- cobbler/collection_systems.py | 6 +++--- 5 files changed, 15 insertions(+), 15 deletions(-) diff --git a/cobbler/collection.py b/cobbler/collection.py index 8e6be39..a9364d4 100644 --- a/cobbler/collection.py +++ b/cobbler/collection.py @@ -96,7 +96,7 @@ class Collection(serializable.Serializable): item = self.factory_produce(self.config,seed_data) self.add(item) - def add(self,ref,with_copy=False): + def add(self,ref,with_copy=False,with_triggers=True): """ Add an object to the collection, if it's valid. Returns True if the object was added to the collection. Returns False if the @@ -126,7 +126,7 @@ class Collection(serializable.Serializable): # perform filesystem operations if with_copy: # failure of a pre trigger will prevent the object from being added - self._run_triggers(ref,"/var/lib/cobbler/triggers/add/%s/pre/*" % self.collection_type()) + if with_triggers: self._run_triggers(ref,"/var/lib/cobbler/triggers/add/%s/pre/*" % self.collection_type()) self.listing[ref.name.lower()] = ref # save just this item if possible, if not, save @@ -146,7 +146,7 @@ class Collection(serializable.Serializable): print _("Internal error. Object type not recognized: %s") % type(ref) # save the tree, so if neccessary, scripts can examine it. - self._run_triggers(ref,"/var/lib/cobbler/triggers/add/%s/post/*" % self.collection_type()) + if with_triggers: self._run_triggers(ref,"/var/lib/cobbler/triggers/add/%s/post/*" % self.collection_type()) # update children cache in parent object parent = ref.get_parent() diff --git a/cobbler/collection_distros.py b/cobbler/collection_distros.py index b696738..b415766 100644 --- a/cobbler/collection_distros.py +++ b/cobbler/collection_distros.py @@ -31,7 +31,7 @@ class Distros(collection.Collection): """ return distro.Distro(config).from_datastruct(seed_data) - def remove(self,name,with_delete=True): + def remove(self,name,with_delete=True,with_triggers=True): """ Remove element named 'name' from the collection """ @@ -43,13 +43,13 @@ class Distros(collection.Collection): obj = self.find(name=name) if obj is not None: if with_delete: - self._run_triggers(obj, "/var/lib/cobbler/triggers/delete/distro/pre/*") + if with_triggers: self._run_triggers(obj, "/var/lib/cobbler/triggers/delete/distro/pre/*") lite_sync = action_litesync.BootLiteSync(self.config) lite_sync.remove_single_profile(name) del self.listing[name] self.config.serialize_delete(self, obj) if with_delete: - self._run_triggers(obj, "/var/lib/cobbler/triggers/delete/distro/post/*") + if with_triggers: self._run_triggers(obj, "/var/lib/cobbler/triggers/delete/distro/post/*") return True raise CX(_("cannot delete object that does not exist")) diff --git a/cobbler/collection_profiles.py b/cobbler/collection_profiles.py index b878ff9..6892e4e 100644 --- a/cobbler/collection_profiles.py +++ b/cobbler/collection_profiles.py @@ -32,7 +32,7 @@ class Profiles(collection.Collection): def factory_produce(self,config,seed_data): return profile.Profile(config).from_datastruct(seed_data) - def remove(self,name,with_delete=True): + def remove(self,name,with_delete=True,with_triggers=True): """ Remove element named 'name' from the collection """ @@ -43,13 +43,13 @@ class Profiles(collection.Collection): obj = self.find(name=name) if obj is not None: if with_delete: - self._run_triggers(obj, "/var/lib/cobbler/triggers/delete/profile/pre/*") + if with_triggers: self._run_triggers(obj, "/var/lib/cobbler/triggers/delete/profile/pre/*") lite_sync = action_litesync.BootLiteSync(self.config) lite_sync.remove_single_profile(name) del self.listing[name] self.config.serialize_delete(self, obj) if with_delete: - self._run_triggers(obj, "/var/lib/cobbler/triggers/delete/profile/post/*") + if with_triggers: self._run_triggers(obj, "/var/lib/cobbler/triggers/delete/profile/post/*") return True raise CX(_("cannot delete an object that does not exist")) diff --git a/cobbler/collection_repos.py b/cobbler/collection_repos.py index da1a3bd..62d7ff0 100644 --- a/cobbler/collection_repos.py +++ b/cobbler/collection_repos.py @@ -36,7 +36,7 @@ class Repos(collection.Collection): """ return repo.Repo(config).from_datastruct(seed_data) - def remove(self,name,with_delete=True): + def remove(self,name,with_delete=True,with_triggers=True): """ Remove element named 'name' from the collection """ @@ -47,13 +47,13 @@ class Repos(collection.Collection): obj = self.find(name=name) if obj is not None: if with_delete: - self._run_triggers(obj, "/var/lib/cobbler/triggers/delete/repo/pre/*") + if with_triggers: self._run_triggers(obj, "/var/lib/cobbler/triggers/delete/repo/pre/*") del self.listing[name] self.config.serialize_delete(self, obj) if with_delete: - self._run_triggers(obj, "/var/lib/cobbler/triggers/delete/repo/post/*") + if with_triggers: self._run_triggers(obj, "/var/lib/cobbler/triggers/delete/repo/post/*") return True raise CX(_("cannot delete an object that does not exist")) diff --git a/cobbler/collection_systems.py b/cobbler/collection_systems.py index a871f9a..d31ee2e 100644 --- a/cobbler/collection_systems.py +++ b/cobbler/collection_systems.py @@ -33,7 +33,7 @@ class Systems(collection.Collection): """ return system.System(config).from_datastruct(seed_data) - def remove(self,name,with_delete=True): + def remove(self,name,with_delete=True,with_triggers=True): """ Remove element named 'name' from the collection """ @@ -43,13 +43,13 @@ class Systems(collection.Collection): if obj is not None: if with_delete: - self._run_triggers(obj, "/var/lib/cobbler/triggers/delete/system/pre/*") + if with_triggers: self._run_triggers(obj, "/var/lib/cobbler/triggers/delete/system/pre/*") lite_sync = action_litesync.BootLiteSync(self.config) lite_sync.remove_single_system(name) del self.listing[name] self.config.serialize_delete(self, obj) if with_delete: - self._run_triggers(obj, "/var/lib/cobbler/triggers/delete/system/post/*") + if with_triggers: self._run_triggers(obj, "/var/lib/cobbler/triggers/delete/system/post/*") return True raise CX(_("cannot delete an object that does not exist")) -- 1.5.2.4 --------------040405030105090803090001-- From robertn at the-nelsons.org Thu Nov 15 19:49:17 2007 From: robertn at the-nelsons.org (Robert Nelson) Date: Thu, 15 Nov 2007 11:49:17 -0800 Subject: [et-mgmt-tools] Virt-Manager: Supporting additional para-virtual OS's In-Reply-To: <20071115141911.GF17977@redhat.com> References: <473BFA57.7070601@the-nelsons.org> <20071115141911.GF17977@redhat.com> Message-ID: <473CA2BD.5020604@the-nelsons.org> Hugh O. Brock wrote: > On Wed, Nov 14, 2007 at 11:50:47PM -0800, Robert Nelson wrote: > >> I've been trying to add support for additional para-virtual operating >> systems (OpenSolaris and Debian) to virt-manager. There is no problem >> getting the initial kernel and ramdisk, however there is no way to >> specify the target disk node based on the OS or distro. Also some OS's >> don't support the virtual frame buffer driver but there is no way to >> prevent the XML for it being created. >> >> I can't see how this could be done without doing some major >> restructuring of the code and creating a new class to encapsulate all >> the target specific information. Is there any plan on doing something >> like this? If someone were to do it, are the changes likely to be >> incorporated? >> > > Hello Robert, thanks for your interest. > > I'm not sure I understand what you mean by "specify the target disk > node based on the OS or distro"? > > Virt-Manager names the target disknodes xvda, xvdb, etc. OpenSolaris requires 0, 1, 2, etc. > I would have no problem with adding a checkbox to virt-manager that > would have the effect of passing the --nographics flag to virtinst if > you can determine a good place to do it. I don't think we want to > spend a whole ton of time creating a new class to take different PV > guest OSes into account, though. Having said that, have you looked at > the *Installer class family in virtinst? Is there a way we could > extend that to do what you need? > > I'll take another look at the Installer class and see if it can be done there. > Take care, > --Hugh > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdehaan at redhat.com Thu Nov 15 19:50:47 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 15 Nov 2007 14:50:47 -0500 Subject: [et-mgmt-tools] [PATCH] Added with_triggers=True variable to functions that call triggers. In-Reply-To: <473CA20A.4080006@umn.edu> References: <473B5BFF.9090707@umn.edu> <473B5D6C.10401@redhat.com> <473CA20A.4080006@umn.edu> Message-ID: <473CA317.4030209@redhat.com> Riggs, Ben wrote: > Michael DeHaan wrote: > > Ben, > > > > This attachment seems to be zero-length ... > > > > --Michael > > I'm confused, myself. I received this response from > et-mgmt-tools-bounces at redhat.com: No idea, as we were saying on IRC, it might have been the missing message body? Anyhow, I have it now. Will apply. > > > > You are not allowed to post to this mailing list, and your message has > been automatically rejected. If you think that your messages are > being rejected in error, contact the mailing list owner at > et-mgmt-tools-owner at redhat.com. > > --------------------------------------------------------------------- > > Subject: > [PATCH] Added with_triggers=True variable to functions that call > triggers. This allows one to pass with_triggers=False from the API to > bypass triggers. It can be used to prevent infinite recursions caused > by adding a system during a pre/post add trigger. > From: > Ben Riggs > Date: > Wed, 14 Nov 2007 14:27:21 -0600 > > --- > cobbler/collection.py | 6 +++--- > cobbler/collection_distros.py | 6 +++--- > cobbler/collection_profiles.py | 6 +++--- > cobbler/collection_repos.py | 6 +++--- > cobbler/collection_systems.py | 6 +++--- > 5 files changed, 15 insertions(+), 15 deletions(-) > > diff --git a/cobbler/collection.py b/cobbler/collection.py > index 8e6be39..a9364d4 100644 > --- a/cobbler/collection.py > +++ b/cobbler/collection.py > @@ -96,7 +96,7 @@ class Collection(serializable.Serializable): > item = self.factory_produce(self.config,seed_data) > self.add(item) > > - def add(self,ref,with_copy=False): > + def add(self,ref,with_copy=False,with_triggers=True): > """ > Add an object to the collection, if it's valid. Returns True > if the object was added to the collection. Returns False if the > @@ -126,7 +126,7 @@ class Collection(serializable.Serializable): > # perform filesystem operations > if with_copy: > # failure of a pre trigger will prevent the object from > being added > - self._run_triggers(ref,"/var/lib/cobbler/triggers/add/%s/pre/*" % > self.collection_type()) > + if with_triggers: > self._run_triggers(ref,"/var/lib/cobbler/triggers/add/%s/pre/*" % > self.collection_type()) > self.listing[ref.name.lower()] = ref > > # save just this item if possible, if not, save > @@ -146,7 +146,7 @@ class Collection(serializable.Serializable): > print _("Internal error. Object type not recognized: > %s") % type(ref) > > # save the tree, so if neccessary, scripts can examine it. > - self._run_triggers(ref,"/var/lib/cobbler/triggers/add/%s/post/*" % > self.collection_type()) > + if with_triggers: > self._run_triggers(ref,"/var/lib/cobbler/triggers/add/%s/post/*" % > self.collection_type()) > > # update children cache in parent object > parent = ref.get_parent() > diff --git a/cobbler/collection_distros.py > b/cobbler/collection_distros.py > index b696738..b415766 100644 > --- a/cobbler/collection_distros.py > +++ b/cobbler/collection_distros.py > @@ -31,7 +31,7 @@ class Distros(collection.Collection): > """ > return distro.Distro(config).from_datastruct(seed_data) > > - def remove(self,name,with_delete=True): > + def remove(self,name,with_delete=True,with_triggers=True): > """ > Remove element named 'name' from the collection > """ > @@ -43,13 +43,13 @@ class Distros(collection.Collection): > obj = self.find(name=name) > if obj is not None: > if with_delete: > - self._run_triggers(obj, > "/var/lib/cobbler/triggers/delete/distro/pre/*") > + if with_triggers: self._run_triggers(obj, > "/var/lib/cobbler/triggers/delete/distro/pre/*") > lite_sync = action_litesync.BootLiteSync(self.config) > lite_sync.remove_single_profile(name) > del self.listing[name] > self.config.serialize_delete(self, obj) > if with_delete: > - self._run_triggers(obj, > "/var/lib/cobbler/triggers/delete/distro/post/*") > + if with_triggers: self._run_triggers(obj, > "/var/lib/cobbler/triggers/delete/distro/post/*") > return True > raise CX(_("cannot delete object that does not exist")) > > diff --git a/cobbler/collection_profiles.py > b/cobbler/collection_profiles.py > index b878ff9..6892e4e 100644 > --- a/cobbler/collection_profiles.py > +++ b/cobbler/collection_profiles.py > @@ -32,7 +32,7 @@ class Profiles(collection.Collection): > def factory_produce(self,config,seed_data): > return profile.Profile(config).from_datastruct(seed_data) > > - def remove(self,name,with_delete=True): > + def remove(self,name,with_delete=True,with_triggers=True): > """ > Remove element named 'name' from the collection > """ > @@ -43,13 +43,13 @@ class Profiles(collection.Collection): > obj = self.find(name=name) > if obj is not None: > if with_delete: > - self._run_triggers(obj, > "/var/lib/cobbler/triggers/delete/profile/pre/*") > + if with_triggers: self._run_triggers(obj, > "/var/lib/cobbler/triggers/delete/profile/pre/*") > lite_sync = action_litesync.BootLiteSync(self.config) > lite_sync.remove_single_profile(name) > del self.listing[name] > self.config.serialize_delete(self, obj) > if with_delete: > - self._run_triggers(obj, > "/var/lib/cobbler/triggers/delete/profile/post/*") > + if with_triggers: self._run_triggers(obj, > "/var/lib/cobbler/triggers/delete/profile/post/*") > return True > raise CX(_("cannot delete an object that does not exist")) > > diff --git a/cobbler/collection_repos.py b/cobbler/collection_repos.py > index da1a3bd..62d7ff0 100644 > --- a/cobbler/collection_repos.py > +++ b/cobbler/collection_repos.py > @@ -36,7 +36,7 @@ class Repos(collection.Collection): > """ > return repo.Repo(config).from_datastruct(seed_data) > > - def remove(self,name,with_delete=True): > + def remove(self,name,with_delete=True,with_triggers=True): > """ > Remove element named 'name' from the collection > """ > @@ -47,13 +47,13 @@ class Repos(collection.Collection): > obj = self.find(name=name) > if obj is not None: > if with_delete: > - self._run_triggers(obj, > "/var/lib/cobbler/triggers/delete/repo/pre/*") > + if with_triggers: self._run_triggers(obj, > "/var/lib/cobbler/triggers/delete/repo/pre/*") > > del self.listing[name] > self.config.serialize_delete(self, obj) > > if with_delete: > - self._run_triggers(obj, > "/var/lib/cobbler/triggers/delete/repo/post/*") > + if with_triggers: self._run_triggers(obj, > "/var/lib/cobbler/triggers/delete/repo/post/*") > return True > raise CX(_("cannot delete an object that does not exist")) > > diff --git a/cobbler/collection_systems.py > b/cobbler/collection_systems.py > index a871f9a..d31ee2e 100644 > --- a/cobbler/collection_systems.py > +++ b/cobbler/collection_systems.py > @@ -33,7 +33,7 @@ class Systems(collection.Collection): > """ > return system.System(config).from_datastruct(seed_data) > > - def remove(self,name,with_delete=True): > + def remove(self,name,with_delete=True,with_triggers=True): > """ > Remove element named 'name' from the collection > """ > @@ -43,13 +43,13 @@ class Systems(collection.Collection): > if obj is not None: > > if with_delete: > - self._run_triggers(obj, > "/var/lib/cobbler/triggers/delete/system/pre/*") > + if with_triggers: self._run_triggers(obj, > "/var/lib/cobbler/triggers/delete/system/pre/*") > lite_sync = action_litesync.BootLiteSync(self.config) > lite_sync.remove_single_system(name) > del self.listing[name] > self.config.serialize_delete(self, obj) > if with_delete: > - self._run_triggers(obj, > "/var/lib/cobbler/triggers/delete/system/post/*") > + if with_triggers: self._run_triggers(obj, > "/var/lib/cobbler/triggers/delete/system/post/*") > > return True > raise CX(_("cannot delete an object that does not exist")) > -- 1.5.2.4 --------------040405030105090803090001-- > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From robertn at the-nelsons.org Thu Nov 15 20:13:16 2007 From: robertn at the-nelsons.org (Robert Nelson) Date: Thu, 15 Nov 2007 12:13:16 -0800 Subject: [et-mgmt-tools] Virt-Manager: Supporting additional para-virtual OS's In-Reply-To: <1195154069.23538.5.camel@localhost.localdomain> References: <473BFA57.7070601@the-nelsons.org> <20071115141911.GF17977@redhat.com> <1195154069.23538.5.camel@localhost.localdomain> Message-ID: <473CA85C.80305@the-nelsons.org> David Lutterkort wrote: > On Thu, 2007-11-15 at 09:19 -0500, Hugh O. Brock wrote: > >> I would have no problem with adding a checkbox to virt-manager that >> would have the effect of passing the --nographics flag to virtinst if >> you can determine a good place to do it. I don't think we want to >> spend a whole ton of time creating a new class to take different PV >> guest OSes into account, though. Having said that, have you looked at >> the *Installer class family in virtinst? Is there a way we could >> extend that to do what you need? >> > > Another route (though one that takes more effort), is to base install on > virt-image metadata - the idea is that we would ship stock virt-image > files for installable OS's; those files would contain the salient bits > about an OS (such as APIC/ACPI, whether to enable a graphics console, > kernel cmdline for pv) virt-manager would have to modify those files a > little before passing them off to virt-image, mostly to put things like > the ISO location and path to the root disk in. > > I looked at virt-image but it seemed to be based on having an "already installed" version of the source image. Also I didn't see any way to specify different configuration settings for the "install phase" versus the "normal execution". Unfortunately neither virt-image nor virt-install provide the ability to specify the target device. Both Libvirt's XML and xen's xmdomain.cfg formats do provide it. > David > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robertn at the-nelsons.org Thu Nov 15 20:23:24 2007 From: robertn at the-nelsons.org (Robert Nelson) Date: Thu, 15 Nov 2007 12:23:24 -0800 Subject: [et-mgmt-tools] Virt-Manager: Supporting additional para-virtual OS's In-Reply-To: <20071115192049.GB29831@redhat.com> References: <473BFA57.7070601@the-nelsons.org> <20071115141911.GF17977@redhat.com> <1195154069.23538.5.camel@localhost.localdomain> <20071115192049.GB29831@redhat.com> Message-ID: <473CAABC.6080506@the-nelsons.org> Hugh O. Brock wrote: > On Thu, Nov 15, 2007 at 07:14:29PM +0000, David Lutterkort wrote: > >> Another route (though one that takes more effort), is to base install on >> virt-image metadata - the idea is that we would ship stock virt-image >> files for installable OS's; those files would contain the salient bits >> about an OS (such as APIC/ACPI, whether to enable a graphics console, >> kernel cmdline for pv) virt-manager would have to modify those files a >> little before passing them off to virt-image, mostly to put things like >> the ISO location and path to the root disk in. >> >> > > That seems like the right way to do it. We need an image-packager though, right? > > I don't think that will solve the problem. The areas that need to be abstracted are: Distro (OS) detection from install media Currently handled by specializations of the ImageStore class. OS specific XML generation Not available currently OS specific kernel options for both "Install Phase" and "Normal Execution Phase" Not available currently For the last two, the base class could provide the current implementation and specializations could be used to handle those OS's with nonstandard requirements. Currently I'm handling it with manually generated XML templates using "virsh create" to do the install and then "virsh define" to configure the "normal" settings.. > --H > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crobinso at redhat.com Thu Nov 15 21:04:21 2007 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 15 Nov 2007 16:04:21 -0500 Subject: [et-mgmt-tools] [PATCH] catch and report errors during hardware manipulation Message-ID: <473CB455.7010103@redhat.com> The attached patch adds a lot of error catching and reporting for adding hardware in virt-manager. The particulars are: 1) Build virtinst VirtualDisk and VirtualNics as we go through creation wizards to reuse present validation. 2) Added a few cases of using the "install_error" infrastructure if we fail when at the end of the wizard. 3) Added error checking for removing hardware in the 'details' screen. 4) A small cleanup in create.py This stuff will definitely be useful for future bug reports :) - Cole -- Cole Robinson crobinso at redhat.com -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: virt-manager-hardware-manip-errchk-patch URL: From mdehaan at redhat.com Thu Nov 15 21:36:50 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 15 Nov 2007 16:36:50 -0500 Subject: [et-mgmt-tools] Koan on RHEL3 -- fixed Message-ID: <473CBBF2.4020201@redhat.com> As pointed out on IRC, koan wasn't working on RHEL3 (missing a module, etc), so I've updated the source RPM to get things working again. If you have koan 0.6.3 already, this is basically the same, so there is no point in upgrading to 0.6.3-3 unless you want to use "koan --replace-self" on EL3. http://cobbler.et.redhat.com/download/koan-0.6.3-3.src.rpm --Michael From dlutter at redhat.com Thu Nov 15 21:59:37 2007 From: dlutter at redhat.com (David Lutterkort) Date: Thu, 15 Nov 2007 13:59:37 -0800 Subject: [et-mgmt-tools] Virt-Manager: Supporting additional para-virtual OS's In-Reply-To: <473CA85C.80305@the-nelsons.org> References: <473BFA57.7070601@the-nelsons.org> <20071115141911.GF17977@redhat.com> <1195154069.23538.5.camel@localhost.localdomain> <473CA85C.80305@the-nelsons.org> Message-ID: <1195163977.7943.4.camel@localhost.localdomain> On Thu, 2007-11-15 at 12:13 -0800, Robert Nelson wrote: > I looked at virt-image but it seemed to be based on having an "already > installed" version of the source image. The source image would be the install media - you'd have an image.xml that is set to boot off the install CD and gets an additional virtual disk (xvda, hda, ..) that it will install into. Once the install is complete, you'd still need to boot the guest off its own libvirt XML. > Also I didn't see any way to specify different configuration settings > for the "install phase" versus the "normal execution". This would only be for the install phase - virt-install/virt-image still need to know that they are doing an install, and generate 'normal' libvirt XML that the guest boots off after installation. > Unfortunately neither virt-image nor virt-install provide the ability > to specify the target device. virt-image XML does have a mapping of disk files to target devices. You're right though that virt-install will just assign target devices based on the order in which disk files are specified. David From robertn at the-nelsons.org Thu Nov 15 22:10:01 2007 From: robertn at the-nelsons.org (Robert Nelson) Date: Thu, 15 Nov 2007 14:10:01 -0800 Subject: [et-mgmt-tools] Virt-Manager: Supporting additional para-virtual OS's In-Reply-To: <1195163977.7943.4.camel@localhost.localdomain> References: <473BFA57.7070601@the-nelsons.org> <20071115141911.GF17977@redhat.com> <1195154069.23538.5.camel@localhost.localdomain> <473CA85C.80305@the-nelsons.org> <1195163977.7943.4.camel@localhost.localdomain> Message-ID: <473CC3B9.20503@the-nelsons.org> David Lutterkort wrote: > On Thu, 2007-11-15 at 12:13 -0800, Robert Nelson wrote: > >> I looked at virt-image but it seemed to be based on having an "already >> installed" version of the source image. >> > > The source image would be the install media - you'd have an image.xml > that is set to boot off the install CD and gets an additional virtual > disk (xvda, hda, ..) that it will install into. Once the install is > complete, you'd still need to boot the guest off its own libvirt XML. > > >> Also I didn't see any way to specify different configuration settings >> for the "install phase" versus the "normal execution". >> > > This would only be for the install phase - virt-install/virt-image still > need to know that they are doing an install, and generate 'normal' > libvirt XML that the guest boots off after installation. > > >> Unfortunately neither virt-image nor virt-install provide the ability >> to specify the target device. >> > > virt-image XML does have a mapping of disk files to target devices. > You're right though that virt-install will just assign target devices > based on the order in which disk files are specified. > > David > > The virt-image(5) man page doesn't list an option for the target device. The only options listed are: file, use, size and format. > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlutter at redhat.com Thu Nov 15 22:15:31 2007 From: dlutter at redhat.com (David Lutterkort) Date: Thu, 15 Nov 2007 14:15:31 -0800 Subject: [et-mgmt-tools] Virt-Manager: Supporting additional para-virtual OS's In-Reply-To: <20071115192049.GB29831@redhat.com> References: <473BFA57.7070601@the-nelsons.org> <20071115141911.GF17977@redhat.com> <1195154069.23538.5.camel@localhost.localdomain> <20071115192049.GB29831@redhat.com> Message-ID: <1195164931.7943.16.camel@localhost.localdomain> On Thu, 2007-11-15 at 14:20 -0500, Hugh O. Brock wrote: > On Thu, Nov 15, 2007 at 07:14:29PM +0000, David Lutterkort wrote: > > > > Another route (though one that takes more effort), is to base install on > > virt-image metadata - the idea is that we would ship stock virt-image > > files for installable OS's; those files would contain the salient bits > > about an OS (such as APIC/ACPI, whether to enable a graphics console, > > kernel cmdline for pv) virt-manager would have to modify those files a > > little before passing them off to virt-image, mostly to put things like > > the ISO location and path to the root disk in. > > > > That seems like the right way to do it. We need an image-packager though, right? Not necessarily .. I was thinking that virt-manager would edit the stock image.xml to include user-provided information about where the install ISO and the target disk file are. The image.xml we ship would be complete except that it doesn't contain a section, and that the disk/target mapping is missing; those owuld be filled in by virt-manager before kicking off the install. IOW, we'd use it mostly for expressing arch, features, and whether to enable graphics. There's a few problems still though: (1) virt-image doesn't let you assign a MAC from XML and (2) IIRC it doesn't handle LVM volumes. Both shouldn't be too hard to address. The main point is that the OS-specific install information should move out of the code into some data files - and virt-image seems to be pretty close in terms of what needs to be expressed. David From robertn at the-nelsons.org Thu Nov 15 22:13:11 2007 From: robertn at the-nelsons.org (Robert Nelson) Date: Thu, 15 Nov 2007 14:13:11 -0800 Subject: [et-mgmt-tools] Virt-Manager: Supporting additional para-virtual OS's In-Reply-To: <473CC3B9.20503@the-nelsons.org> References: <473BFA57.7070601@the-nelsons.org> <20071115141911.GF17977@redhat.com> <1195154069.23538.5.camel@localhost.localdomain> <473CA85C.80305@the-nelsons.org> <1195163977.7943.4.camel@localhost.localdomain> <473CC3B9.20503@the-nelsons.org> Message-ID: <473CC477.2020802@the-nelsons.org> Robert Nelson wrote: > David Lutterkort wrote: >> On Thu, 2007-11-15 at 12:13 -0800, Robert Nelson wrote: >> >>> I looked at virt-image but it seemed to be based on having an "already >>> installed" version of the source image. >>> >> >> The source image would be the install media - you'd have an image.xml >> that is set to boot off the install CD and gets an additional virtual >> disk (xvda, hda, ..) that it will install into. Once the install is >> complete, you'd still need to boot the guest off its own libvirt XML. >> >> >>> Also I didn't see any way to specify different configuration settings >>> for the "install phase" versus the "normal execution". >>> >> >> This would only be for the install phase - virt-install/virt-image still >> need to know that they are doing an install, and generate 'normal' >> libvirt XML that the guest boots off after installation. >> >> >>> Unfortunately neither virt-image nor virt-install provide the ability >>> to specify the target device. >>> >> >> virt-image XML does have a mapping of disk files to target devices. >> You're right though that virt-install will just assign target devices >> based on the order in which disk files are specified. >> >> David >> >> > > The virt-image(5) man page doesn't list an option for the target > device. The only options listed are: file, use, size and format. > Ah never mind, I missed that the storage declaration is split into two places. >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robertn at the-nelsons.org Thu Nov 15 22:34:59 2007 From: robertn at the-nelsons.org (Robert Nelson) Date: Thu, 15 Nov 2007 14:34:59 -0800 Subject: [et-mgmt-tools] Virt-Manager: Supporting additional para-virtual OS's In-Reply-To: <1195164931.7943.16.camel@localhost.localdomain> References: <473BFA57.7070601@the-nelsons.org> <20071115141911.GF17977@redhat.com> <1195154069.23538.5.camel@localhost.localdomain> <20071115192049.GB29831@redhat.com> <1195164931.7943.16.camel@localhost.localdomain> Message-ID: <473CC993.3020802@the-nelsons.org> David Lutterkort wrote: > On Thu, 2007-11-15 at 14:20 -0500, Hugh O. Brock wrote: > >> On Thu, Nov 15, 2007 at 07:14:29PM +0000, David Lutterkort wrote: >> >>> Another route (though one that takes more effort), is to base install on >>> virt-image metadata - the idea is that we would ship stock virt-image >>> files for installable OS's; those files would contain the salient bits >>> about an OS (such as APIC/ACPI, whether to enable a graphics console, >>> kernel cmdline for pv) virt-manager would have to modify those files a >>> little before passing them off to virt-image, mostly to put things like >>> the ISO location and path to the root disk in. >>> >>> >> That seems like the right way to do it. We need an image-packager though, right? >> > > Not necessarily .. I was thinking that virt-manager would edit the stock > image.xml to include user-provided information about where the install > ISO and the target disk file are. The image.xml we ship would be > complete except that it doesn't contain a section, and that > the disk/target mapping is missing; those owuld be filled in by > virt-manager before kicking off the install. IOW, we'd use it mostly for > expressing arch, features, and whether to enable graphics. > > This doesn't seem to solve the problem that started this thread if virt-manager is specifying the target device. Even if you did allow the target device info to be expressed in the XML, how do you deal with numbering the variable number of devices? For example xvda, xvdb, xvdc versus hda, hdb, hdc versus 0, 1, 2. It seems like you need some sort of code to deal with this OS specific attribute. > There's a few problems still though: (1) virt-image doesn't let you > assign a MAC from XML and (2) IIRC it doesn't handle LVM volumes. Both > shouldn't be too hard to address. > > The main point is that the OS-specific install information should move > out of the code into some data files - and virt-image seems to be pretty > close in terms of what needs to be expressed. > > Why not use libvirt's XML format? It supports everything already. It also should be easier to integrate with virt-manger. > David > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlutter at redhat.com Thu Nov 15 22:43:22 2007 From: dlutter at redhat.com (David Lutterkort) Date: Thu, 15 Nov 2007 14:43:22 -0800 Subject: [et-mgmt-tools] Virt-Manager: Supporting additional para-virtual OS's In-Reply-To: <473CC993.3020802@the-nelsons.org> References: <473BFA57.7070601@the-nelsons.org> <20071115141911.GF17977@redhat.com> <1195154069.23538.5.camel@localhost.localdomain> <20071115192049.GB29831@redhat.com> <1195164931.7943.16.camel@localhost.localdomain> <473CC993.3020802@the-nelsons.org> Message-ID: <1195166602.7943.42.camel@localhost.localdomain> On Thu, 2007-11-15 at 14:34 -0800, Robert Nelson wrote: > This doesn't seem to solve the problem that started this thread if > virt-manager is specifying the target device. > > Even if you did allow the target device info to be expressed in the > XML, how do you deal with numbering the variable number of devices? Ugh .. I somehow only saw the comment about the virtual frame buffer - for the target device naming, you are right, it doesn't solve it. David From berrange at redhat.com Fri Nov 16 11:02:16 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 16 Nov 2007 11:02:16 +0000 Subject: [et-mgmt-tools] Virt-Manager: Supporting additional para-virtual OS's In-Reply-To: <473CA2BD.5020604@the-nelsons.org> References: <473BFA57.7070601@the-nelsons.org> <20071115141911.GF17977@redhat.com> <473CA2BD.5020604@the-nelsons.org> Message-ID: <20071116110215.GB3283@redhat.com> On Thu, Nov 15, 2007 at 11:49:17AM -0800, Robert Nelson wrote: > Hugh O. Brock wrote: > >On Wed, Nov 14, 2007 at 11:50:47PM -0800, Robert Nelson wrote: > > > >>I've been trying to add support for additional para-virtual operating > >>systems (OpenSolaris and Debian) to virt-manager. There is no problem > >>getting the initial kernel and ramdisk, however there is no way to > >>specify the target disk node based on the OS or distro. Also some OS's > >>don't support the virtual frame buffer driver but there is no way to > >>prevent the XML for it being created. > >> > >>I can't see how this could be done without doing some major > >>restructuring of the code and creating a new class to encapsulate all > >>the target specific information. Is there any plan on doing something > >>like this? If someone were to do it, are the changes likely to be > >>incorporated? > >> > > > >Hello Robert, thanks for your interest. > > > >I'm not sure I understand what you mean by "specify the target disk > >node based on the OS or distro"? > > > > > > Virt-Manager names the target disknodes xvda, xvdb, etc. OpenSolaris > requires 0, 1, 2, etc. > > >I would have no problem with adding a checkbox to virt-manager that > >would have the effect of passing the --nographics flag to virtinst if > >you can determine a good place to do it. I don't think we want to > >spend a whole ton of time creating a new class to take different PV > >guest OSes into account, though. Having said that, have you looked at > >the *Installer class family in virtinst? Is there a way we could > >extend that to do what you need? > > > > > > I'll take another look at the Installer class and see if it can be done > there. In the virtinst/FullVirtGuest.py class, there is already a bunch of OS specific metadata, eg what of mouse to use, apic/acpi/pae settings, whether the installer is multi-stage reboots (eg Windows). I'd recommend moving this metadata into virtinst/DistroManager and have a bunch of methods in that module for querying distro specific metadata, from the Installer class. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From tim.verhoeven.be at gmail.com Fri Nov 16 12:13:44 2007 From: tim.verhoeven.be at gmail.com (Tim Verhoeven) Date: Fri, 16 Nov 2007 13:13:44 +0100 Subject: [et-mgmt-tools] [PATCH] Increase length of some fields in the Cobbler webui Message-ID: <2a7fce340711160413t6ce01e25p4ed5a9950316daf9@mail.gmail.com> Hi, This patch increases the lengt of certain fields in the webui of Cobbler. Mostly the fields that in my case contain long entries (paths, URL's, ...). And I presume that that would be the case with more people. This improves the usability of the webui a lot for me. Regards, Tim -- Tim Verhoeven - tim.verhoeven.be at gmail.com - 0479 / 88 11 83 Hoping the problem magically goes away by ignoring it is the "microsoft approach to programming" and should never be allowed. (Linus Torvalds) -------------- next part -------------- A non-text attachment was scrubbed... Name: cobbler_input_field_length.patch Type: text/x-patch Size: 5033 bytes Desc: not available URL: From robertn at the-nelsons.org Fri Nov 16 15:53:18 2007 From: robertn at the-nelsons.org (Robert Nelson) Date: Fri, 16 Nov 2007 07:53:18 -0800 Subject: [et-mgmt-tools] Virt-Manager: Supporting additional para-virtual OS's In-Reply-To: <20071116110215.GB3283@redhat.com> References: <473BFA57.7070601@the-nelsons.org> <20071115141911.GF17977@redhat.com> <473CA2BD.5020604@the-nelsons.org> <20071116110215.GB3283@redhat.com> Message-ID: <473DBCEE.1000401@the-nelsons.org> Daniel P. Berrange wrote: > On Thu, Nov 15, 2007 at 11:49:17AM -0800, Robert Nelson wrote: > >> Hugh O. Brock wrote: >> >>> On Wed, Nov 14, 2007 at 11:50:47PM -0800, Robert Nelson wrote: >>> >>> >>>> I've been trying to add support for additional para-virtual operating >>>> systems (OpenSolaris and Debian) to virt-manager. There is no problem >>>> getting the initial kernel and ramdisk, however there is no way to >>>> specify the target disk node based on the OS or distro. Also some OS's >>>> don't support the virtual frame buffer driver but there is no way to >>>> prevent the XML for it being created. >>>> >>>> I can't see how this could be done without doing some major >>>> restructuring of the code and creating a new class to encapsulate all >>>> the target specific information. Is there any plan on doing something >>>> like this? If someone were to do it, are the changes likely to be >>>> incorporated? >>>> >>>> >>> Hello Robert, thanks for your interest. >>> >>> I'm not sure I understand what you mean by "specify the target disk >>> node based on the OS or distro"? >>> >>> >>> >> Virt-Manager names the target disknodes xvda, xvdb, etc. OpenSolaris >> requires 0, 1, 2, etc. >> >> >>> I would have no problem with adding a checkbox to virt-manager that >>> would have the effect of passing the --nographics flag to virtinst if >>> you can determine a good place to do it. I don't think we want to >>> spend a whole ton of time creating a new class to take different PV >>> guest OSes into account, though. Having said that, have you looked at >>> the *Installer class family in virtinst? Is there a way we could >>> extend that to do what you need? >>> >>> >>> >> I'll take another look at the Installer class and see if it can be done >> there. >> > > In the virtinst/FullVirtGuest.py class, there is already a bunch of > OS specific metadata, eg what of mouse to use, apic/acpi/pae settings, > whether the installer is multi-stage reboots (eg Windows). I'd recommend > moving this metadata into virtinst/DistroManager and have a bunch of > methods in that module for querying distro specific metadata, from the > Installer class. > > Dan. > And so we come full circle :-) If you combine that with the OS specific derived classes of ImageStore you end up with something similar to what I originally proposed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdehaan at redhat.com Fri Nov 16 21:17:18 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 16 Nov 2007 16:17:18 -0500 Subject: [et-mgmt-tools] [PATCH] Increase length of some fields in the Cobbler webui In-Reply-To: <2a7fce340711160413t6ce01e25p4ed5a9950316daf9@mail.gmail.com> References: <2a7fce340711160413t6ce01e25p4ed5a9950316daf9@mail.gmail.com> Message-ID: <473E08DE.9030301@redhat.com> Tim Verhoeven wrote: > Hi, > > This patch increases the lengt of certain fields in the webui of > Cobbler. Mostly the fields that in my case contain long entries > (paths, URL's, ...). And I presume that that would be the case with > more people. > > This improves the usability of the webui a lot for me. > I agree! Applied and thanks! --Michael From crobinso at redhat.com Fri Nov 16 22:16:46 2007 From: crobinso at redhat.com (Cole Robinson) Date: Fri, 16 Nov 2007 17:16:46 -0500 Subject: [et-mgmt-tools] [PATCH] catch and report errors during hardware manipulation In-Reply-To: <473CB455.7010103@redhat.com> References: <473CB455.7010103@redhat.com> Message-ID: <473E16CE.8020108@redhat.com> Cole Robinson wrote: > The attached patch adds a lot of error catching and reporting for adding > hardware in virt-manager. The particulars are: > > 1) Build virtinst VirtualDisk and VirtualNics as we go through creation > wizards to reuse present validation. > > 2) Added a few cases of using the "install_error" infrastructure if we > fail when at the end of the wizard. > > 3) Added error checking for removing hardware in the 'details' screen. > > 4) A small cleanup in create.py > > This stuff will definitely be useful for future bug reports :) > > - Cole > > > I fixed a couple small bugs and committed this: http://hg.et.redhat.com/virt/applications/virt-manager--devel?cs=632472746706 - Cole -- Cole Robinson crobinso at redhat.com From linuxweb at gmail.com Sat Nov 17 17:39:11 2007 From: linuxweb at gmail.com (Johnny Tan) Date: Sat, 17 Nov 2007 12:39:11 -0500 Subject: [et-mgmt-tools] traceback on cobbler import Message-ID: <473F273F.1070003@gmail.com> Running cobbler 0.6.2-2.el5 on centos 5. I've changed /var/lib/cobbler/settings to set "server" and "next server" to my server's IP. I also changed "webdir" to /srv/www/html/cobbler, and "yum_core_mirror_from_server" to 1. In /etc/httpd/conf.d/cobbler.conf, I changed all instances of /var/www/cobbler to /srv/www/html/cobbler. Then I ran the cobbler import command and got these errors/traceback, found here: http://pastebin.com/m498e96a And got all those errors. Two things stick out: 1) it changed my distro name from centos-5-os-x86_64 to centos-5-centos-5-x86_64, but only in some instances, it seems to go back and forth between the two on the rest of that traceback 2) for url, it put "http://@@server@@/cobbler/ks_mirror/...", what is this @@server@@? I have already set a "server" in /var/lib/cobbler/settings Thanks for any help. johnn From linuxweb at gmail.com Sat Nov 17 18:51:48 2007 From: linuxweb at gmail.com (Johnny Tan) Date: Sat, 17 Nov 2007 13:51:48 -0500 Subject: [et-mgmt-tools] Re: traceback on cobbler import In-Reply-To: <473F273F.1070003@gmail.com> References: <473F273F.1070003@gmail.com> Message-ID: <473F3844.6030801@gmail.com> Johnny Tan wrote: > Then I ran the cobbler import command and got these errors/traceback, > found here: > http://pastebin.com/m498e96a Nevermind, brain freeze :). I deleted all the cobbler www subdirectories which caused it to get confused. I guess I thought, like some of the files in /var/lib/cobbler (repos, distros, systems, profiles), things would get regenerated as needed. And the name repeat thing, obviously that is how it names it for the distros/profiles. So, no need for a response. Sorry for the noise. johnn From mdehaan at redhat.com Mon Nov 19 01:51:00 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Sun, 18 Nov 2007 20:51:00 -0500 Subject: [et-mgmt-tools] traceback on cobbler import In-Reply-To: <473F273F.1070003@gmail.com> References: <473F273F.1070003@gmail.com> Message-ID: <4740EC04.4090201@redhat.com> Johnny Tan wrote: > > > In /etc/httpd/conf.d/cobbler.conf, I changed all instances of > /var/www/cobbler to /srv/www/html/cobbler. Unless you've written a new RPM specfile to match and want to keep maintaining it, don't do this. There are directories that the RPM creates a subdirectory of the above and that permissions are managed on. Read this instead: https://hosted.fedoraproject.org/projects/cobbler/wiki/RelocatingYourInstall From jwildebo at redhat.com Mon Nov 19 10:26:03 2007 From: jwildebo at redhat.com (Jan Wildeboer) Date: Mon, 19 Nov 2007 11:26:03 +0100 Subject: [et-mgmt-tools] Simple Q: HOWTO setup automated deployment for different virt variants? Message-ID: <1195467963.769.26.camel@jwcorp.muc.redhat.com> In order to allow simple and automated testing of some stuff, I would like to be able to: - Define a configuration for a runtime environment based on RHEL{4,5} - Deploy this config in all five relevant environments: - Baremetal on normal kernel - Baremetal on dom0 kernel - Paravirtualised - Fully virtualised - Fully virtualised with paravirtualised drivers How would yous tackle this? Cobbler, puppet only? initrd magic? Stateless? I would welcome nay input and experiences ... Jan -- Jan H Wildeboer | Solution Architect, RHCE | Office: +49 (0)89 205071-207 Red Hat GmbH | Mobile: +49 (0)174 33 23 249 Otto-Hahn-Str.20 | Fax: +49 (0)89 205071-111 D-85609 Dornach/Munich | eMail: jan.wildeboer at redhat.com _____________________________________________________________________ GPG-Key-ID: 5DEBAFB0 GPG-Fingerprint: 6104 0F74 8513 F17E DFD5 E820 6F61 A078 5DEB AFB0 _____________________________________________________________________ Reg. Adresse: Red Hat GmbH, Hauptstaetter Strasse 58, 70178 Stuttgart Handelsregister: Amtsgericht Stuttgart HRB 153243 Geschaeftsfuehrer: Brendan Lane, Charlie Peters, Michael Cunningham, Werner Knoblich _____________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From linuxweb at gmail.com Mon Nov 19 14:32:56 2007 From: linuxweb at gmail.com (Johnny Tan) Date: Mon, 19 Nov 2007 09:32:56 -0500 Subject: [et-mgmt-tools] traceback on cobbler import In-Reply-To: <4740EC04.4090201@redhat.com> References: <473F273F.1070003@gmail.com> <4740EC04.4090201@redhat.com> Message-ID: <47419E98.4090502@gmail.com> Michael DeHaan wrote: > There are directories that the RPM creates a subdirectory of the above > and that permissions are managed on. > Read this instead: > https://hosted.fedoraproject.org/projects/cobbler/wiki/RelocatingYourInstall Thanks Michael, I'll create the symlinks. johnn From mdehaan at redhat.com Mon Nov 19 16:14:11 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 19 Nov 2007 11:14:11 -0500 Subject: [et-mgmt-tools] Simple Q: HOWTO setup automated deployment for different virt variants? In-Reply-To: <1195467963.769.26.camel@jwcorp.muc.redhat.com> References: <1195467963.769.26.camel@jwcorp.muc.redhat.com> Message-ID: <4741B653.2010805@redhat.com> Jan Wildeboer wrote: > In order to allow simple and automated testing of some stuff, I would > like to be able to: > > - Define a configuration for a runtime environment based on RHEL{4,5} > - Deploy this config in all five relevant environments: > - Baremetal on normal kernel > - Baremetal on dom0 kernel > - Paravirtualised > - Fully virtualised > - Fully virtualised with paravirtualised drivers > > How would yous tackle this? Cobbler, puppet only? initrd magic? > Stateless? > > I would welcome nay input and experiences ... > > Jan > > Sure... Cobbler/koan covers provisioning all of this right now except fullvirt Xen, which is now installable via PXE if you have F8. Before that AFAIK, there was no fully automatic way to install fullvirt Xen. I'll be adding koan hooks to simply this in the next release. FYI -- koan does do fullvirt KVM (not Xen) out of the box, paravirt Xen is no problem regardless of OS version. --Michael From dlutter at redhat.com Wed Nov 21 03:02:18 2007 From: dlutter at redhat.com (David Lutterkort) Date: Tue, 20 Nov 2007 19:02:18 -0800 Subject: [et-mgmt-tools] [PATCH] virtinst - fix virt-image nad running livecd's Message-ID: <1195614138.19919.5.camel@localhost.localdomain> It seems that checking 271:a94b50696c3d broke both virt-image and running livecd's The attached patch fixes that. I have tried the patch for the various install methods, but would appreciate if somebody else could give it a spin. David -------------- next part -------------- A non-text attachment was scrubbed... Name: image.patch Type: text/x-patch Size: 2114 bytes Desc: not available URL: From rainer at ultra-secure.de Wed Nov 21 11:49:12 2007 From: rainer at ultra-secure.de (Rainer Duffner) Date: Wed, 21 Nov 2007 12:49:12 +0100 (CET) Subject: [et-mgmt-tools] anaconda crashes with cobbler-generated kickstart-file Message-ID: <60757.212.71.112.230.1195645752.squirrel@www.ultra-secure.de> Hi, I'm trying out cobbler. 0.6.4-2 is installed (and configured). I imported the RHEL5.1 repository from the DVD image. I had it create this kickstartfile: [root at vmrhel5 syslog]# cat /var/www/cobbler/kickstarts/RHEL5-i386/ks.cfg #platform=x86, AMD64, or Intel EM64T # System authorization information auth --useshadow --enablemd5 # System bootloader configuration bootloader --location=mbr # Partition clearing information clearpart --all --initlabel # Use text mode install text key --skip # Firewall configuration firewall --enabled # Run the Setup Agent on first boot firstboot --disable # System keyboard keyboard us # System language lang en_US # Use network installation url --url=http://172.16.50.100/cblr/links/RHEL5-i386 # If any cobbler repo definitions were referenced in the kickstart profile, include them here. repo --name=RHEL5-i386-5 --baseurl=http://172.16.50.100/cobbler/ks_mirror/RHEL5-i386/VT repo --name=RHEL5-i386-3 --baseurl=http://172.16.50.100/cobbler/ks_mirror/RHEL5-i386/ClusterStorage repo --name=RHEL5-i386-6 --baseurl=http://172.16.50.100/cobbler/ks_mirror/RHEL5-i386/Cluster repo --name=RHEL5-i386-1 --baseurl=http://172.16.50.100/cobbler/ks_mirror/RHEL5-i386/VT repo --name=RHEL5-i386-7 --baseurl=http://172.16.50.100/cobbler/ks_mirror/RHEL5-i386/ClusterStorage repo --name=RHEL5-i386-4 --baseurl=http://172.16.50.100/cobbler/ks_mirror/RHEL5-i386/Server repo --name=RHEL5-i386-2 --baseurl=http://172.16.50.100/cobbler/ks_mirror/RHEL5-i386/Cluster repo --name=RHEL5-i386-0 --baseurl=http://172.16.50.100/cobbler/ks_mirror/RHEL5-i386/Server # Network information network --bootproto=static --device=eth0 --onboot=on --ip=172.16.50.56 --netmask=255.255.255.0 --gateway=172.16.50.2 --nameserver=172.16.50.2 # Reboot after installation reboot #Root password rootpw --iscrypted yadayadayadayadayadayada. # SELinux configuration selinux --disabled # Do not configure the X Window System skipx # System timezone timezone --utc Europe/Zurich # Install OS instead of upgrade install # Clear the Master Boot Record zerombr # Magically figure out how to partition this thing #SNIPPET::partition_select_normal # or not part /boot --fstype ext3 --size=150 --ondisk=sda --asprimary part swap --fstype swap --size=4096 --ondisk=sda part pv.01 --fstype ext3 --size=2048 --ondisk=sda volgroup rootvol pv.01 --pesize=32768 logvol / --vgname=rootvol --name=root --size=1024 --grow part pv.02 --fstype ext3 --size=4096 --ondisk=sda volgroup usrvol pv.02 --pesize=32768 logvol /usr --vgname=usrvol --name=usr --size=1024 --grow part pv.03 --fstype ext3 --size=2048 --grow --ondisk=sda volgroup varvol pv.03 --pesize=32768 logvol /var --vgname=varvol --name=var --size=1024 --grow part pv.04 --fstype ext3 --size=4096 --ondisk=sda volgroup varlogvol pv.04 --pesize=32768 logvol /var/log --vgname=varlogvol --name=varlog --size=1024 --grow %packages #-s390utils #-bluez-bluefw #-bluez-hcidump #-bluez-libs #-bluez-utils #-bluez-gnome #-bridge-utils #-dhclient #-dhcpv6_client #-irda-utils #-pcmciautils #-rp-pppoe #-sendmail #-mutt #-fetchmail #-mdadm #-wireless-tools #-rhpl #-NetworkManager #lvm2 #grub #e2fsprogs #compat-libstdc++-296 #compat-libstdc++-33 #elinks #ntp #postfix #vim-common #vim-enhanced %post wget http://172.16.50.100/cblr/watcher.py?profile_done=RHEL5-i386 -b wget http://172.16.50.100/cobbler/kickstarts/RHEL5-i386/ks.cfg -O /root/cobbler.ks **** However, anaconda crashes after resolving the packages. Error in anaconda.log says: ... 17:38:42 DEBUG : Matched cups-libs - 1:1.2.4-11.14.el5.i386 to require for libcupsimage.so.2 17:38:42 DEBUG : Matched libXxf86vm - 1.0.1-3.1.i386 to require for libXxf86vm.so.1 17:38:42 DEBUG : Matched libXxf86vm - 1.0.1-3.1.i386 to require for libXxf86vm.so.1 17:38:42 DEBUG : Matched libXxf86vm - 1.0.1-3.1.i386 to require for libXxf86vm.so.1 17:38:42 INFO : adding libXxf86vm for libXxf86vm.so.1, required by mesa-libGL 17:38:42 DEBUG : Matched libdrm - 2.0.2-1.1.i386 to require for libdrm.so.2 17:38:42 DEBUG : Matched libdrm - 2.0.2-1.1.i386 to require for libdrm.so.2 17:38:42 DEBUG : Matched libdrm - 2.0.2-1.1.i386 to require for libdrm.so.2 17:38:42 INFO : adding libdrm for libdrm.so.2, required by mesa-libGL 17:38:43 INFO : Running kickstart %%traceback script(s) 17:38:43 INFO : All kickstart %%traceback script(s) have been run 17:38:43 CRITICAL: Traceback (most recent call first): File "/usr/lib/python2.4/site-packages/yum/packages.py", line 35, in comparePoEVR (e2, v2, r2) = (po2.epoch, po2.ver, po2.rel) File "/usr/lib/python2.4/site-packages/yum/packages.py", line 191, in __eq__ if comparePoEVR(self, other) == 0 and self.arch == other.arch and self.name == other.name: File "/usr/lib/yum-plugins/fedorakmod.py", line 151, in resolveVersions elif sameName == None: File "/usr/lib/yum-plugins/fedorakmod.py", line 222, in installAllKmods rAvaModules = resolveVersions(avaModules) File "/usr/lib/yum-plugins/fedorakmod.py", line 276, in postresolve_hook newKernels + installedKernels) File "/usr/lib/python2.4/site-packages/yum/plugins.py", line 153, in run func(conduitcls(self, self.base, conf, **kwargs)) File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 442, in buildTransaction self.plugins.run('postresolve', rescode=rescode, restring=restring) File "/usr/lib/anaconda/yuminstall.py", line 1267, in doPostSelection (code, msgs) = self.ayum.buildTransaction() File "/usr/lib/anaconda/backend.py", line 177, in doPostSelection return anaconda.backend.doPostSelection(anaconda) File "/usr/lib/anaconda/dispatch.py", line 201, in moveStep rc = stepFunc(self.anaconda) File "/usr/lib/anaconda/dispatch.py", line 124, in gotoNext self.moveStep() File "/usr/lib/anaconda/dispatch.py", line 223, in currentStep self.gotoNext() File "/usr/lib/anaconda/text.py", line 539, in run (step, instance) = anaconda.dispatch.currentStep() File "/usr/bin/anaconda", line 982, in ? anaconda.intf.run(anaconda) AttributeError: 'NoneType' object has no attribute 'epoch' 17:38:43 INFO : in run, screen = What is wrong here? Best Regads, Rainer From tom at ng23.net Wed Nov 21 16:58:23 2007 From: tom at ng23.net (Tom Brown) Date: Wed, 21 Nov 2007 16:58:23 +0000 Subject: [et-mgmt-tools] CentOS 4.5 - cobbler-0.5.0-1.el4.rf - check error Message-ID: <474463AF.7000300@ng23.net> Hi Just trying to setup a new machine and this is my first attempt at a cobbler server. I installed what i need i think but running a cobbler check gives me the folowing error. Can anyone give me hints to this error?? thanks # cobbler check Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/cobbler/cobbler.py", line 719, in main BootCLI(sys.argv).run() File "/usr/lib/python2.3/site-packages/cobbler/cobbler.py", line 42, in __init__ self.api = api.BootAPI() File "/usr/lib/python2.3/site-packages/cobbler/api.py", line 40, in __init__ self.deserialize() File "/usr/lib/python2.3/site-packages/cobbler/api.py", line 170, in deserialize return self._config.deserialize() File "/usr/lib/python2.3/site-packages/cobbler/config.py", line 169, in deserialize if not serializer.deserialize(x,topological=True): File "/usr/lib/python2.3/site-packages/cobbler/serializer.py", line 79, in deserialize datastruct.sort(cmp=__depth_cmp) TypeError: sort() takes no keyword arguments From wright at imageworks.com Wed Nov 21 18:13:58 2007 From: wright at imageworks.com (Peter Wright) Date: Wed, 21 Nov 2007 10:13:58 -0800 Subject: [et-mgmt-tools] anaconda crashes with cobbler-generatedkickstart-file In-Reply-To: <60757.212.71.112.230.1195645752.squirrel@www.ultra-secure.de> References: <60757.212.71.112.230.1195645752.squirrel@www.ultra-secure.de> Message-ID: <47447566.9050508@imageworks.com> Rainer Duffner wrote: > Hi, > > I'm trying out cobbler. > 0.6.4-2 is installed (and configured). > I imported the RHEL5.1 repository from the DVD image. > > > > 17:38:43 CRITICAL: Traceback (most recent call first): > File "/usr/lib/python2.4/site-packages/yum/packages.py", line 35, in > comparePoEVR > (e2, v2, r2) = (po2.epoch, po2.ver, po2.rel) > File "/usr/lib/python2.4/site-packages/yum/packages.py", line 191, in > __eq__ > if comparePoEVR(self, other) == 0 and self.arch == other.arch and > self.name == other.name: > File "/usr/lib/yum-plugins/fedorakmod.py", line 151, in resolveVersions > elif sameName == None: > File "/usr/lib/yum-plugins/fedorakmod.py", line 222, in installAllKmods > rAvaModules = resolveVersions(avaModules) > File "/usr/lib/yum-plugins/fedorakmod.py", line 276, in postresolve_hook > newKernels + installedKernels) > File "/usr/lib/python2.4/site-packages/yum/plugins.py", line 153, in run > func(conduitcls(self, self.base, conf, **kwargs)) > File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 442, in > buildTransaction > self.plugins.run('postresolve', rescode=rescode, restring=restring) > File "/usr/lib/anaconda/yuminstall.py", line 1267, in doPostSelection > (code, msgs) = self.ayum.buildTransaction() > File "/usr/lib/anaconda/backend.py", line 177, in doPostSelection > return anaconda.backend.doPostSelection(anaconda) > File "/usr/lib/anaconda/dispatch.py", line 201, in moveStep > rc = stepFunc(self.anaconda) > File "/usr/lib/anaconda/dispatch.py", line 124, in gotoNext > self.moveStep() > File "/usr/lib/anaconda/dispatch.py", line 223, in currentStep > self.gotoNext() > File "/usr/lib/anaconda/text.py", line 539, in run > (step, instance) = anaconda.dispatch.currentStep() > File "/usr/bin/anaconda", line 982, in ? > anaconda.intf.run(anaconda) > AttributeError: 'NoneType' object has no attribute 'epoch' > > 17:38:43 INFO : in run, screen = 0xb7e20dac> > > > What is wrong here? > have you tried asking anyone on the kickstart or anaconda lists? it looks like a bug in anaconda to me. it would be interesting to see if you get the same errors if you leave out the additional repo sections. but from what you have posted this does not look like a cobbler/koan or lib-virt for that matter issue.... -pete -- Peter Wright Systems Engineer Sony Pictures Imageworks wright at imageworks.com www.imageworks.com From crobinso at redhat.com Wed Nov 21 18:14:17 2007 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 21 Nov 2007 13:14:17 -0500 Subject: [et-mgmt-tools] [PATCH] virtinst - fix virt-image nad running livecd's In-Reply-To: <1195614138.19919.5.camel@localhost.localdomain> References: <1195614138.19919.5.camel@localhost.localdomain> Message-ID: <47447579.5020202@redhat.com> David Lutterkort wrote: > It seems that checking 271:a94b50696c3d broke both virt-image and > running livecd's The attached patch fixes that. I have tried the patch > for the various install methods, but would appreciate if somebody else > could give it a spin. > > David > > Patch looks good to me, and I verified that livecd installs with virt-install. One comment though: might be worth adding a comment where you removed the _prepare_install check saying that it breaks virt-image, so the change isn't reverted again :) - Cole -- Cole Robinson crobinso at redhat.com From crobinso at redhat.com Wed Nov 21 18:28:20 2007 From: crobinso at redhat.com (Cole Robinson) Date: Wed, 21 Nov 2007 13:28:20 -0500 Subject: [et-mgmt-tools] [PATCH] virt-manager reorg common commands, add error reporting Message-ID: <474478C4.3080102@redhat.com> The attached patch is the result of trying to add error reporting to some common tasks in virt-manager: pause, unpause, shutdown, and run, as well as save and destroy. Since the first 4 commands can be called from 3 different locations (console, details, manager), I consolidated their code into engine.py, as had been done in the past with save and destroy. All these commands now show an error dialog if an exception is thrown. I also fixed an associated issue where the pause buttons in console and details can be put out of sync if pause/unpause failed. I tested all these by manually throwing exceptions in the libvirt bindings. It's kind of a lot of churn, but I think it's more maintainable this way. - Cole > console.py | 71 +++++++++------------------------ > details.py | 129 +++++++++++++++++++------------------------------------------ > engine.py | 114 +++++++++++++++++++++++++++++++++++++++++++++++++++-- > manager.py | 32 +++++++++++---- > 4 files changed, 196 insertions(+), 150 deletions(-) -- Cole Robinson crobinso at redhat.com -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: virt-manager-comm-error-catch-patch URL: From tom at ng23.net Wed Nov 21 18:37:48 2007 From: tom at ng23.net (Tom Brown) Date: Wed, 21 Nov 2007 18:37:48 +0000 Subject: [et-mgmt-tools] CentOS 4.5 - cobbler-0.5.0-1.el4.rf - check error In-Reply-To: <474463AF.7000300@ng23.net> References: <474463AF.7000300@ng23.net> Message-ID: <47447AFC.4000903@ng23.net> > > > Just trying to setup a new machine and this is my first attempt at a > cobbler server. I installed what i need i think but running a cobbler > check gives me the folowing error. > > Can anyone give me hints to this error?? > > thanks > > # cobbler check > Traceback (most recent call last): > File "/usr/lib/python2.3/site-packages/cobbler/cobbler.py", line 719, > in main > BootCLI(sys.argv).run() > File "/usr/lib/python2.3/site-packages/cobbler/cobbler.py", line 42, > in __init__ > self.api = api.BootAPI() > File "/usr/lib/python2.3/site-packages/cobbler/api.py", line 40, in > __init__ > self.deserialize() > File "/usr/lib/python2.3/site-packages/cobbler/api.py", line 170, in > deserialize > return self._config.deserialize() > File "/usr/lib/python2.3/site-packages/cobbler/config.py", line 169, > in deserialize > if not serializer.deserialize(x,topological=True): > File "/usr/lib/python2.3/site-packages/cobbler/serializer.py", line > 79, in deserialize > datastruct.sort(cmp=__depth_cmp) > TypeError: sort() takes no keyword arguments anyone help here? This seems to be a similar issue http://www.redhat.com/archives/et-mgmt-tools/2007-July/msg00023.html but i installed from romforge rpm's and so i am unsure about the fix? thanks for any assistance From pnixon at gmail.com Wed Nov 21 19:08:20 2007 From: pnixon at gmail.com (Patrick Nixon) Date: Wed, 21 Nov 2007 14:08:20 -0500 Subject: [et-mgmt-tools] CentOS 4.5 - cobbler-0.5.0-1.el4.rf - check error In-Reply-To: <47447AFC.4000903@ng23.net> References: <474463AF.7000300@ng23.net> <47447AFC.4000903@ng23.net> Message-ID: I know that 0.5 is a very old version, I think it's up to 0.6.3 Check the website, there may be newer packages someplace. On Nov 21, 2007 1:37 PM, Tom Brown wrote: > > > > > > > > Just trying to setup a new machine and this is my first attempt at a > > cobbler server. I installed what i need i think but running a cobbler > > check gives me the folowing error. > > > > Can anyone give me hints to this error?? > > > > thanks > > > > # cobbler check > > Traceback (most recent call last): > > File "/usr/lib/python2.3/site-packages/cobbler/cobbler.py", line 719, > > in main > > BootCLI(sys.argv).run() > > File "/usr/lib/python2.3/site-packages/cobbler/cobbler.py", line 42, > > in __init__ > > self.api = api.BootAPI() > > File "/usr/lib/python2.3/site-packages/cobbler/api.py", line 40, in > > __init__ > > self.deserialize() > > File "/usr/lib/python2.3/site-packages/cobbler/api.py", line 170, in > > deserialize > > return self._config.deserialize() > > File "/usr/lib/python2.3/site-packages/cobbler/config.py", line 169, > > in deserialize > > if not serializer.deserialize(x,topological=True): > > File "/usr/lib/python2.3/site-packages/cobbler/serializer.py", line > > 79, in deserialize > > datastruct.sort(cmp=__depth_cmp) > > TypeError: sort() takes no keyword arguments > > anyone help here? This seems to be a similar issue > > http://www.redhat.com/archives/et-mgmt-tools/2007-July/msg00023.html > > but i installed from romforge rpm's and so i am unsure about the fix? > > thanks for any assistance > > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From linuxweb at gmail.com Wed Nov 21 19:18:23 2007 From: linuxweb at gmail.com (Johnny Tan) Date: Wed, 21 Nov 2007 14:18:23 -0500 Subject: [et-mgmt-tools] CentOS 4.5 - cobbler-0.5.0-1.el4.rf - check error In-Reply-To: References: <474463AF.7000300@ng23.net> <47447AFC.4000903@ng23.net> Message-ID: <4744847F.9050300@gmail.com> Patrick Nixon wrote: > I know that 0.5 is a very old version, I think it's up to 0.6.3 > Check the website, there may be newer packages someplace. Yeah I agree. I'm a big fan of rpmforge and use them whenever possible, but epel does have a newer cobbler -- version 0.6.2, hopefully they'll get 0.6.3 soon. johnn From tom at ng23.net Wed Nov 21 21:45:28 2007 From: tom at ng23.net (Tom Brown) Date: Wed, 21 Nov 2007 21:45:28 +0000 Subject: [et-mgmt-tools] CentOS 4.5 - cobbler-0.5.0-1.el4.rf - check error In-Reply-To: <4744847F.9050300@gmail.com> References: <474463AF.7000300@ng23.net> <47447AFC.4000903@ng23.net> <4744847F.9050300@gmail.com> Message-ID: <4744A6F8.4080108@ng23.net> > >> I know that 0.5 is a very old version, I think it's up to 0.6.3 >> Check the website, there may be newer packages someplace. > > Yeah I agree. I'm a big fan of rpmforge and use them whenever > possible, but epel does have a newer cobbler -- version 0.6.2, > hopefully they'll get 0.6.3 soon. > thanks - i cant find newer for CentOS 4.x so i am trying to build my own. It bombs out here Processing files: cobbler-0.6.4-1 Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.53447 + umask 022 + cd /usr/src/redhat/BUILD + cd cobbler-0.6.4 + DOCDIR=/var/tmp/cobbler-0.6.4-1-root/usr/share/doc/cobbler-0.6.4 + export DOCDIR + rm -rf /var/tmp/cobbler-0.6.4-1-root/usr/share/doc/cobbler-0.6.4 + /bin/mkdir -p /var/tmp/cobbler-0.6.4-1-root/usr/share/doc/cobbler-0.6.4 + cp -pr AUTHORS CHANGELOG COPYING README /var/tmp/cobbler-0.6.4-1-root/usr/share/doc/cobbler-0.6.4 + exit 0 warning: File listed twice: /usr/lib/python2.3/site-packages/cobbler/__init__.pyo warning: File listed twice: /usr/lib/python2.3/site-packages/cobbler/action_check.pyo warning: File listed twice: /usr/lib/python2.3/site-packages/cobbler/action_import.pyo warning: File listed twice: /usr/lib/python2.3/site-packages/cobbler/action_litesync.pyo warning: File listed twice: /usr/lib/python2.3/site-packages/cobbler/action_reposync.pyo -- snip -- and then Provides: config(cobbler) = 0.6.4-1 Requires(interp): /bin/sh /bin/sh /bin/sh Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 Requires(post): /bin/sh Requires(preun): /bin/sh Requires(postun): /bin/sh Requires: /bin/sh /usr/bin/python config(cobbler) = 0.6.4-1 createrepo httpd mod_python python-cheetah python-devel >= 2.3 tftp-server yum-utils Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/cobbler-0.6.4-1-root error: Installed (but unpackaged) file(s) found: /etc/logrotate.d/cobblerd_rotate /usr/share/cobbler/webui_templates/blank.tmpl /usr/share/cobbler/webui_templates/distro_edit.tmpl /usr/share/cobbler/webui_templates/distro_list.tmpl etc Any thoughts? thanks From hyclak at math.ohiou.edu Wed Nov 21 22:24:39 2007 From: hyclak at math.ohiou.edu (Matt Hyclak) Date: Wed, 21 Nov 2007 17:24:39 -0500 Subject: [et-mgmt-tools] CentOS 4.5 - cobbler-0.5.0-1.el4.rf - check error In-Reply-To: <4744A6F8.4080108@ng23.net> References: <474463AF.7000300@ng23.net> <47447AFC.4000903@ng23.net> <4744847F.9050300@gmail.com> <4744A6F8.4080108@ng23.net> Message-ID: <20071121222439.GB12490@math.ohiou.edu> On Wed, Nov 21, 2007 at 09:45:28PM +0000, Tom Brown enlightened us: > >>I know that 0.5 is a very old version, I think it's up to 0.6.3 > >>Check the website, there may be newer packages someplace. > > > >Yeah I agree. I'm a big fan of rpmforge and use them whenever > >possible, but epel does have a newer cobbler -- version 0.6.2, > >hopefully they'll get 0.6.3 soon. > > > > > thanks - i cant find newer for CentOS 4.x so i am trying to build my own. > I have packages available at http://www.math.ohiou.edu/pub/casit/et-tools/ These will eventually make it into CentOS Extras or rpmrepo, after 4.6 and 5.1 are out the door. Currently 0.6.2 is up there, but I'm updating to 0.6.4 now. Matt -- Matt Hyclak Department of Mathematics Department of Social Work Ohio University (740) 593-1263 From tom at ng23.net Wed Nov 21 22:34:42 2007 From: tom at ng23.net (Tom Brown) Date: Wed, 21 Nov 2007 22:34:42 +0000 Subject: [et-mgmt-tools] CentOS 4.5 - cobbler-0.5.0-1.el4.rf - check error In-Reply-To: <20071121222439.GB12490@math.ohiou.edu> References: <474463AF.7000300@ng23.net> <47447AFC.4000903@ng23.net> <4744847F.9050300@gmail.com> <4744A6F8.4080108@ng23.net> <20071121222439.GB12490@math.ohiou.edu> Message-ID: <4744B282.5080706@ng23.net> > I have packages available at http://www.math.ohiou.edu/pub/casit/et-tools/ > > These will eventually make it into CentOS Extras or rpmrepo, after 4.6 and > 5.1 are out the door. > > Currently 0.6.2 is up there, but I'm updating to 0.6.4 now. > > thanks - i used git to get the latest source and built that OK # rpm -qa | grep cobbler cobbler-0.6.5-1 I just grabbed your latest koan though thanks! Tom From Dan at cdChase.com Thu Nov 22 01:23:54 2007 From: Dan at cdChase.com (C. Daniel Chase) Date: Wed, 21 Nov 2007 20:23:54 -0500 Subject: [et-mgmt-tools] Repo Mirroring & Fedora 8 Import Message-ID: <4744DA2A.4000302@cdChase.com> I've recently learned that the latest Fedora 8 online repo contains more files than are included on the DVD I used for import. While I have the Fedora-Updates repository mirrored, the extra files that are included in the original distro, that have not had updates, are not available in either location. My only idea for solving this is to re-import the entire distro from the online repo instead of the DVD. Anyone have a better solution? I suppose I could rsync the files, but the related cache, etc won't be properly updated. Though, I suppose the files would all there. -Dan PS--I'm fine tuning a patch to give better output for use in using reposync in batch mode. Requires a coordinated update to Yum as well. -- C. Daniel Chase (423) 949-4086 http://cdChase.com/ Get Firefox! http://www.spreadfirefox.com/?q=affiliates&id=58708&t=1 From tom at ng23.net Thu Nov 22 01:42:03 2007 From: tom at ng23.net (Tom Brown) Date: Thu, 22 Nov 2007 01:42:03 +0000 Subject: [et-mgmt-tools] cobbler-0.6.5-1 - CentOS 4.5 - adding a profile Message-ID: <4744DE6B.3010107@ng23.net> Hi Since i have now managed to get my install going i can PXE machines (in this case just in vmware) but i have what i imagine is a simple problem. I am import a distro and then add a profile like so # cobbler profile add --name=centos --distro=CentOS-4.5-i386 --kickstart=/var/www/cobbler/kickstarts/CentOS-4.5-i386/ks.cfg # this works fine but then when i do the cobbler sync i get # cobbler sync sync distro: CentOS-4.5-i386 sync distro: CentOS-4.5-xen-i386 sync profile: CentOS-4.5-i386 sync profile: CentOS-4.5-xen-i386 sync profile: centos There appears to be an formatting error in the template file. For completeness, the traceback from Cheetah has been included below. Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/cobbler/action_sync.py", line 372, in validate_kickstart_for_specific_profile self.apply_template(kfile, meta, dest) File "/usr/lib/python2.3/site-packages/cobbler/action_sync.py", line 624, in apply_template data_out = str(t) File "/usr/lib/python2.3/site-packages/Cheetah/Template.py", line 994, in __str__ def __str__(self): return getattr(self, mainMethName)() File "cheetah_DynamicallyCompiledCheetahTemplate_1195695012_33_33067.py", line 169, in respond File "cheetah_DynamicallyCompiledCheetahTemplate_1195695012_33_33067.py", line 85, in __errorCatcher3 File "", line 0, in ? NameError: name 'harddrives' is not defined Error while rendering kickstart file /var/www/cobbler/kickstarts/CentOS-4.5-i386/ks.cfg to /var/www/cobbler/kickstarts/centos/ks.cfg Now if i escape out the part of /var/www/cobbler/kickstarts/CentOS-4.5-i386/ks.cfg causing the issue ie. %pre # Determine how many drives we have set \$(list-harddrives) let numd=\$#/2 d1=\$1 d2=\$3 It still fails but when i look back at the /var/www/cobbler/kickstarts/CentOS-4.5-i386/ks.cfg file the back slashes have been removed! Is there something like a master .ks file thats over writing bits of the custom .ks ? thanks From tom at ng23.net Thu Nov 22 15:22:52 2007 From: tom at ng23.net (Tom Brown) Date: Thu, 22 Nov 2007 15:22:52 +0000 Subject: [et-mgmt-tools] template error on system add Message-ID: <47459ECC.7070607@ng23.net> Hi I am slowly getting further i hope but when i add a system i encounter the following # cobbler system add --name=00:0C:29:71:D7:4D --profile=centos4.4 There appears to be an formatting error in the template file. For completeness, the traceback from Cheetah has been included below. Error templating file /var/www/cobbler/kickstarts/CentOS-4.4-i386/ks.cfg to /var/www/cobbler/kickstarts_sys/00:0C:29:71:D7:4D/ks.cfg Is there any way to get verbose output on what error is being encountered? For completeness the ks.cfg causing the issue is below thanks #platform=x86, AMD64, or Intel EM64T # System authorization information auth --useshadow --enablemd5 # System bootloader configuration bootloader --location=mbr # Partition clearing information clearpart --all --initlabel # Use text mode install text # Firewall configuration firewall --enabled # Run the Setup Agent on first boot firstboot --disable # System keyboard keyboard us # System language lang en_US # Use network installation url --url=http://192.168.10.4/cblr/links/CentOS-4.4-i386 # Network information network --bootproto=dhcp --device=eth0 --onboot=on # Reboot after installation reboot #Root password rootpw --iscrypted $1$mF86/UHC$WvcIcX2t6crBz2onWxyac. # SELinux configuration selinux --disabled # Do not configure the X Window System skipx # System timezone timezone America/New_York # Install OS instead of upgrade install # Clear the Master Boot Record zerombr # Magically figure out how to partition this thing %include /tmp/partinfo %pre # Determine how many drives we have set $(list-harddrives) let numd=$#/2 d1=$1 d2=$3 cat << EOF > /tmp/partinfo part / --fstype ext3 --size=1024 --grow --ondisk=$d1 --asprimary part swap --size=1024 --ondisk=$d1 --asprimary EOF %packages %post wget http://192.168.10.4/cblr/repos_profile/CentOS-4.4-i386/CentOS-4.4-i386-0.repo --output-document=/etc/yum.repos.d/CentOS-4.4-i386-0.repo wget http://192.168.10.4/cblr/watcher.py?profile_done=CentOS-4.4-i386 -b wget http://192.168.10.4/cobbler/kickstarts/CentOS-4.4-i386/ks.cfg -O /root/cobbler.ks From tom at ng23.net Thu Nov 22 17:17:59 2007 From: tom at ng23.net (Tom Brown) Date: Thu, 22 Nov 2007 17:17:59 +0000 Subject: [et-mgmt-tools] Contents of ks.cfg gets overwritten Message-ID: <4745B9C7.80402@ng23.net> Hi Well i get further and then take 2 steps back and i am sure you are getting tired of me but 1 more if i may I put the contents of my ks.cfg in for example /var/www/cobbler/kickstarts/CentOS-4.4-i386/ks.cfg now i can add this profile and set a system against this and do a cobbler sync and all seems fine. When the build starts anaconda may bomb on something and then when i check /var/www/cobbler/kickstarts/CentOS-4.4-i386/ks.cfg again the changes i made have been removed and the changes lost. Can anyone point me to docs that explain this behaviour please as i have searched and cant see where to start. thanks From hhoffman at ip-solutions.net Thu Nov 22 17:26:23 2007 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Thu, 22 Nov 2007 12:26:23 -0500 Subject: [et-mgmt-tools] Contents of ks.cfg gets overwritten In-Reply-To: <4745B9C7.80402@ng23.net> References: <4745B9C7.80402@ng23.net> Message-ID: <4745BBBF.704@ip-solutions.net> Hi Tom, You'll probably want to put your kickstart file in /etc/cobbler When you run cobbler sync, cobbler parses through your kickstart file and takes any templating you've added and transforms it for use by anaconda. For example: network --bootproto=static --ip=$ip_address --netmask=$netmask --gateway=$gatewa y --nameserver=$nameserver --hostname=$hostname --device=eth0 --onboot=on $ip_address, $netmask, etc. are all variables that cobbler will replace with actual values (that's I've provided when I did a "cobbler system add..." Once cobbler has done this it takes the resulting kickstart file and drops it in the directories /var/www/cobbler/kickstarts or /var/www/cobbler/kickstarts_sys This way if you change the template kickstart (e.g. /etc/cobbler/rhel-5-webservers.ks) to add something new then you can just run "cobbler sync". If you had 5 systems setup to use a profile with that kickstart file all 5 would be updated automagically, instead of having to deal with each. HTH, Harry Tom Brown wrote: > Hi > > Well i get further and then take 2 steps back and i am sure you are > getting tired of me but 1 more if i may > > I put the contents of my ks.cfg in for example > > /var/www/cobbler/kickstarts/CentOS-4.4-i386/ks.cfg > > now i can add this profile and set a system against this and do a > cobbler sync and all seems fine. > > When the build starts anaconda may bomb on something and then when i > check /var/www/cobbler/kickstarts/CentOS-4.4-i386/ks.cfg again the > changes i made have been removed and the changes lost. > > Can anyone point me to docs that explain this behaviour please as i have > searched and cant see where to start. > > thanks > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From tom at ng23.net Thu Nov 22 17:47:23 2007 From: tom at ng23.net (Tom Brown) Date: Thu, 22 Nov 2007 17:47:23 +0000 Subject: [et-mgmt-tools] Contents of ks.cfg gets overwritten In-Reply-To: <4745BBBF.704@ip-solutions.net> References: <4745B9C7.80402@ng23.net> <4745BBBF.704@ip-solutions.net> Message-ID: <4745C0AB.4090300@ng23.net> > > > You'll probably want to put your kickstart file in /etc/cobbler > > When you run cobbler sync, cobbler parses through your kickstart file > and takes any templating you've added and transforms it for use by > anaconda. > > For example: > network --bootproto=static --ip=$ip_address --netmask=$netmask > --gateway=$gatewa > y --nameserver=$nameserver --hostname=$hostname --device=eth0 --onboot=on > > $ip_address, $netmask, etc. are all variables that cobbler will > replace with actual values (that's I've provided when I did a "cobbler > system add..." > > Once cobbler has done this it takes the resulting kickstart file and > drops it in the directories /var/www/cobbler/kickstarts or > /var/www/cobbler/kickstarts_sys > > This way if you change the template kickstart (e.g. > /etc/cobbler/rhel-5-webservers.ks) to add something new then you can > just run "cobbler sync". > > If you had 5 systems setup to use a profile with that kickstart file > all 5 would be updated automagically, instead of having to deal with > each. > thanks Harry - that seems to be helping, at least things are not over written now!! Do you know if its possible to add a driver disk as in similar to doing a text dd on the command line as i need to load some driver from a floppy image. thanks! From tom at ng23.net Thu Nov 22 18:27:14 2007 From: tom at ng23.net (Tom Brown) Date: Thu, 22 Nov 2007 18:27:14 +0000 Subject: [et-mgmt-tools] Contents of ks.cfg gets overwritten In-Reply-To: <4745C0AB.4090300@ng23.net> References: <4745B9C7.80402@ng23.net> <4745BBBF.704@ip-solutions.net> <4745C0AB.4090300@ng23.net> Message-ID: <4745CA02.6060804@ng23.net> >> >> >> You'll probably want to put your kickstart file in /etc/cobbler >> >> When you run cobbler sync, cobbler parses through your kickstart file >> and takes any templating you've added and transforms it for use by >> anaconda. >> >> For example: >> network --bootproto=static --ip=$ip_address --netmask=$netmask >> --gateway=$gatewa >> y --nameserver=$nameserver --hostname=$hostname --device=eth0 >> --onboot=on >> >> $ip_address, $netmask, etc. are all variables that cobbler will >> replace with actual values (that's I've provided when I did a >> "cobbler system add..." >> >> Once cobbler has done this it takes the resulting kickstart file and >> drops it in the directories /var/www/cobbler/kickstarts or >> /var/www/cobbler/kickstarts_sys >> >> This way if you change the template kickstart (e.g. >> /etc/cobbler/rhel-5-webservers.ks) to add something new then you can >> just run "cobbler sync". >> >> If you had 5 systems setup to use a profile with that kickstart file >> all 5 would be updated automagically, instead of having to deal with >> each. >> OK thanks all - i have FINALLY got a box installed using cobbler and also rebuilt using koan - Now to fine tune things but so far its excellent. I just wished i could now get the webgui running, i cant get in due to an xmlrpc error but maybe i'll leave that for another day. thanks From tom at ng23.net Thu Nov 22 23:04:27 2007 From: tom at ng23.net (Tom Brown) Date: Thu, 22 Nov 2007 23:04:27 +0000 Subject: [et-mgmt-tools] Re: [SOLVED] webui error In-Reply-To: <1194886207.5439.79.camel@slinky> References: <1194873373.5439.12.camel@slinky> <4738746D.7050304@redhat.com> <1194886207.5439.79.camel@slinky> Message-ID: <47460AFB.2080602@ng23.net> >>> [client 128.141.57.220] configuration error: couldn't check user. No user file?: /cgi-bin/cobbler/webui.cgi >>> >>> >> Hmmm .... I haven't seen this before. >> >> What's your test system? Anything strange in your httpd.conf? >> > > as always, EL4 ;-) > > Good news is, AuthUserFile to AuthDigestFile and I'm smiling again :) > Hi - any chance you can let me know where this is changed as i am experiencing exactly the same issue thanks From robertn at the-nelsons.org Fri Nov 23 07:06:58 2007 From: robertn at the-nelsons.org (Robert Nelson) Date: Thu, 22 Nov 2007 23:06:58 -0800 Subject: [et-mgmt-tools] Virt-Manager: Supporting additional para-virtual OS's In-Reply-To: <20071116110215.GB3283@redhat.com> References: <473BFA57.7070601@the-nelsons.org> <20071115141911.GF17977@redhat.com> <473CA2BD.5020604@the-nelsons.org> <20071116110215.GB3283@redhat.com> Message-ID: <47467C12.7020602@the-nelsons.org> Daniel P. Berrange wrote: > On Thu, Nov 15, 2007 at 11:49:17AM -0800, Robert Nelson wrote: > >> Hugh O. Brock wrote: >> >>> On Wed, Nov 14, 2007 at 11:50:47PM -0800, Robert Nelson wrote: >>> >>> >>>> I've been trying to add support for additional para-virtual operating >>>> systems (OpenSolaris and Debian) to virt-manager. There is no problem >>>> getting the initial kernel and ramdisk, however there is no way to >>>> specify the target disk node based on the OS or distro. Also some OS's >>>> don't support the virtual frame buffer driver but there is no way to >>>> prevent the XML for it being created. >>>> >>>> I can't see how this could be done without doing some major >>>> restructuring of the code and creating a new class to encapsulate all >>>> the target specific information. Is there any plan on doing something >>>> like this? If someone were to do it, are the changes likely to be >>>> incorporated? >>>> >>>> >>> Hello Robert, thanks for your interest. >>> >>> I'm not sure I understand what you mean by "specify the target disk >>> node based on the OS or distro"? >>> >>> >>> >> Virt-Manager names the target disknodes xvda, xvdb, etc. OpenSolaris >> requires 0, 1, 2, etc. >> >> >>> I would have no problem with adding a checkbox to virt-manager that >>> would have the effect of passing the --nographics flag to virtinst if >>> you can determine a good place to do it. I don't think we want to >>> spend a whole ton of time creating a new class to take different PV >>> guest OSes into account, though. Having said that, have you looked at >>> the *Installer class family in virtinst? Is there a way we could >>> extend that to do what you need? >>> >>> >>> >> I'll take another look at the Installer class and see if it can be done >> there. >> > > In the virtinst/FullVirtGuest.py class, there is already a bunch of > OS specific metadata, eg what of mouse to use, apic/acpi/pae settings, > whether the installer is multi-stage reboots (eg Windows). I'd recommend > moving this metadata into virtinst/DistroManager and have a bunch of > methods in that module for querying distro specific metadata, from the > Installer class. > > Dan. > I spent some time reworking the virtinst code to support OpenSolaris and make it much easier to support additional OSes. I've attached the patch file to get some feedback on the work so far. Unfortunately a bunch for the code from virtinst is duplicated in virt-manager in the Add Device code. This means either moving it back to virtinst with the appropriate additional APIs or duplicating work in virt-manager. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: virtinst-0.300.1-robert.patch URL: From martin.minka at gmail.com Fri Nov 23 13:03:15 2007 From: martin.minka at gmail.com (Martin Minka) Date: Fri, 23 Nov 2007 14:03:15 +0100 Subject: [et-mgmt-tools] does CENTOS5 import work in Cobbler ? Message-ID: <4746CF93.5020202@gmail.com> I imported CENTOS5 64bit DVD into Cobbler. cobbler import --mirror=/media/centos5 --name=C5_64 When I am installing it installer stops on error http://xmltvproducer.sourceforge.net/anaconda.png. I would like to prove with somebody who installed CENTOS5 over cobbler that it works for him and that the problem is not cobbler and its import function. Martin From rjones at redhat.com Fri Nov 23 13:47:46 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 23 Nov 2007 13:47:46 +0000 Subject: [et-mgmt-tools] virt-clone bug Message-ID: <4746DA02.1030406@redhat.com> The Debian maintainer of virt-install found this problem which seems to be a bug in virt-clone: # virt-clone -o demo -n demo2 --connect=qemu:///session -f bla2.img libvir: QEMU error : libvir: QEMU error : Cloning from /home/foo/kvm/test/bla.img to bla2.img ERROR: local variable 'b' referenced before assignment I would make a snide comment about dynamic languages at this point, but I won't. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From tom at ng23.net Fri Nov 23 14:17:37 2007 From: tom at ng23.net (Tom Brown) Date: Fri, 23 Nov 2007 14:17:37 +0000 Subject: [et-mgmt-tools] Re: [SOLVED] webui error In-Reply-To: <47460AFB.2080602@ng23.net> References: <1194873373.5439.12.camel@slinky> <4738746D.7050304@redhat.com> <1194886207.5439.79.camel@slinky> <47460AFB.2080602@ng23.net> Message-ID: <4746E101.3090804@ng23.net> Tom Brown wrote: > >>>> [client 128.141.57.220] configuration error: couldn't check user. >>>> No user file?: /cgi-bin/cobbler/webui.cgi >>>> >>> Hmmm .... I haven't seen this before. >>> >>> What's your test system? Anything strange in your httpd.conf? >>> >> >> as always, EL4 ;-) >> >> Good news is, AuthUserFile to AuthDigestFile and I'm smiling again :) >> I am experiencing the same error in my apache logs and would appreciate it if anyone can point me in the direction of the fix as i cant find that string anywhere thanks From tom at ng23.net Fri Nov 23 14:21:48 2007 From: tom at ng23.net (Tom Brown) Date: Fri, 23 Nov 2007 14:21:48 +0000 Subject: [et-mgmt-tools] Re: [SOLVED] webui error In-Reply-To: <4746E101.3090804@ng23.net> References: <1194873373.5439.12.camel@slinky> <4738746D.7050304@redhat.com> <1194886207.5439.79.camel@slinky> <47460AFB.2080602@ng23.net> <4746E101.3090804@ng23.net> Message-ID: <4746E1FC.1000202@ng23.net> > > > I am experiencing the same error in my apache logs and would > appreciate it if anyone can point me in the direction of the fix as i > cant find that string anywhere > i have found the fix - sorry for the noise From rjones at redhat.com Fri Nov 23 14:36:03 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 23 Nov 2007 14:36:03 +0000 Subject: [et-mgmt-tools] virt-clone bug In-Reply-To: <4746DA02.1030406@redhat.com> References: <4746DA02.1030406@redhat.com> Message-ID: <4746E553.9030902@redhat.com> Richard W.M. Jones wrote: > The Debian maintainer of virt-install found this problem which seems to > be a bug in virt-clone: > > # virt-clone -o demo -n demo2 --connect=qemu:///session -f bla2.img > libvir: QEMU error : > libvir: QEMU error : > Cloning from /home/foo/kvm/test/bla.img to bla2.img > ERROR: local variable 'b' referenced before assignment Judging from the error message, I'm guessing that it happens at the line I've marked below (in virtinst/CloneManager.py): while 1: l = os.read(src_fd, design.clone_bs) s = len(l) if s == 0: meter.end(size) break # check sequence of zeros if sparse_copy_mode == True and zeros == l: os.lseek(dst_fd, s, 1) else: b = os.write(dst_fd, l) if s != b: <-------- meter.end(i) break i += s if i < size: meter.update(i) It's a very strange piece of code. AIUI it seems to be saying that if we get a short write, then we should just end the copy without any sort of error indication, which can't be the right thing to do. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From hhoffman at ip-solutions.net Fri Nov 23 15:38:03 2007 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Fri, 23 Nov 2007 10:38:03 -0500 Subject: [et-mgmt-tools] does CENTOS5 import work in Cobbler ? In-Reply-To: <4746CF93.5020202@gmail.com> References: <4746CF93.5020202@gmail.com> Message-ID: <4746F3DB.7020807@ip-solutions.net> I installed CentOS5 i386 without any error. That error seems to indicate a problem with where anaconda is trying to log to (just a guess). Can you post your kickstart file, /var/lib/cobbler/settings and the output of "cobbler report"? Also, what version of cobbler are you using? Cheers, Harry Martin Minka wrote: > I imported CENTOS5 64bit DVD into Cobbler. > cobbler import --mirror=/media/centos5 --name=C5_64 > > When I am installing it installer stops on error > http://xmltvproducer.sourceforge.net/anaconda.png. > > I would like to prove with somebody who installed CENTOS5 over cobbler > that it works for him and that the problem is not cobbler and its import > function. > > Martin > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From tom at ng23.net Fri Nov 23 16:01:05 2007 From: tom at ng23.net (Tom Brown) Date: Fri, 23 Nov 2007 16:01:05 +0000 Subject: [et-mgmt-tools] Contents of ks.cfg gets overwritten In-Reply-To: <4745BBBF.704@ip-solutions.net> References: <4745B9C7.80402@ng23.net> <4745BBBF.704@ip-solutions.net> Message-ID: <4746F941.7070409@ng23.net> > > > You'll probably want to put your kickstart file in /etc/cobbler > > When you run cobbler sync, cobbler parses through your kickstart file > and takes any templating you've added and transforms it for use by > anaconda. > > For example: > network --bootproto=static --ip=$ip_address --netmask=$netmask > --gateway=$gatewa > y --nameserver=$nameserver --hostname=$hostname --device=eth0 --onboot=on > > $ip_address, $netmask, etc. are all variables that cobbler will > replace with actual values (that's I've provided when I did a "cobbler > system add..." > > Once cobbler has done this it takes the resulting kickstart file and > drops it in the directories /var/www/cobbler/kickstarts or > /var/www/cobbler/kickstarts_sys > > This way if you change the template kickstart (e.g. > /etc/cobbler/rhel-5-webservers.ks) to add something new then you can > just run "cobbler sync". > > If you had 5 systems setup to use a profile with that kickstart file > all 5 would be updated automagically, instead of having to deal with > each. > Can anyone help me with adding these variables to the system add command as # cobbler system add --name=00:0C:29:71:D7:4D --profile=CentOS-4.5-i386 HOSTNAME=test IPADDR=192.168.10.23 this command doesn't take an option called 'HOSTNAME' and this is the section from my kickstart.ks network --bootproto=static --device=eth0 --onboot=on --ip=$IPADDR --netmask 255.255.255.0 --gateway 192.168.10.1 --nameserver 192.168.10.4 --hostname=$HOSTNAME thanks for all the help so far From berrange at redhat.com Fri Nov 23 16:39:28 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 23 Nov 2007 16:39:28 +0000 Subject: [et-mgmt-tools] virt-clone bug In-Reply-To: <4746E553.9030902@redhat.com> References: <4746DA02.1030406@redhat.com> <4746E553.9030902@redhat.com> Message-ID: <20071123163928.GC11721@redhat.com> On Fri, Nov 23, 2007 at 02:36:03PM +0000, Richard W.M. Jones wrote: > Richard W.M. Jones wrote: > >The Debian maintainer of virt-install found this problem which seems to > >be a bug in virt-clone: > > > ># virt-clone -o demo -n demo2 --connect=qemu:///session -f bla2.img > >libvir: QEMU error : > >libvir: QEMU error : > >Cloning from /home/foo/kvm/test/bla.img to bla2.img > >ERROR: local variable 'b' referenced before assignment > > Judging from the error message, I'm guessing that it happens at the line > I've marked below (in virtinst/CloneManager.py): > > while 1: > l = os.read(src_fd, design.clone_bs) > s = len(l) > if s == 0: > meter.end(size) > break > # check sequence of zeros > if sparse_copy_mode == True and zeros == l: > os.lseek(dst_fd, s, 1) > else: > b = os.write(dst_fd, l) > if s != b: <-------- > meter.end(i) > break > i += s > if i < size: > meter.update(i) > > It's a very strange piece of code. AIUI it seems to be saying that if > we get a short write, then we should just end the copy without any sort > of error indication, which can't be the right thing to do. Yeah, that looks bogus. Guess that 'if s != b' got mis-indented. It definitely needs to raise an error condition of some sort too. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From hhoffman at ip-solutions.net Fri Nov 23 16:40:08 2007 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Fri, 23 Nov 2007 11:40:08 -0500 Subject: [et-mgmt-tools] Contents of ks.cfg gets overwritten In-Reply-To: <4746F941.7070409@ng23.net> References: <4745B9C7.80402@ng23.net> <4745BBBF.704@ip-solutions.net> <4746F941.7070409@ng23.net> Message-ID: <47470268.2030302@ip-solutions.net> cobbler system add --name=w3.fqdn.com --ksmeta="disks=sda,sdb nameserver=192.168.1.3 netmask=255.255.255.0 gateway=192.168.1.201" man cobbler, and the wiki and doc webpages are great for this. the variables usually correspond with keywords that anaconda considers valid within a kickstart file. so, --hostname=some.host.com, not HOSTNAME HTH, Harry Tom Brown wrote: > >> >> >> You'll probably want to put your kickstart file in /etc/cobbler >> >> When you run cobbler sync, cobbler parses through your kickstart file >> and takes any templating you've added and transforms it for use by >> anaconda. >> >> For example: >> network --bootproto=static --ip=$ip_address --netmask=$netmask >> --gateway=$gatewa >> y --nameserver=$nameserver --hostname=$hostname --device=eth0 --onboot=on >> >> $ip_address, $netmask, etc. are all variables that cobbler will >> replace with actual values (that's I've provided when I did a "cobbler >> system add..." >> >> Once cobbler has done this it takes the resulting kickstart file and >> drops it in the directories /var/www/cobbler/kickstarts or >> /var/www/cobbler/kickstarts_sys >> >> This way if you change the template kickstart (e.g. >> /etc/cobbler/rhel-5-webservers.ks) to add something new then you can >> just run "cobbler sync". >> >> If you had 5 systems setup to use a profile with that kickstart file >> all 5 would be updated automagically, instead of having to deal with >> each. >> > > Can anyone help me with adding these variables to the system add command as > > # cobbler system add --name=00:0C:29:71:D7:4D --profile=CentOS-4.5-i386 > HOSTNAME=test IPADDR=192.168.10.23 > this command doesn't take an option called 'HOSTNAME' > > and this is the section from my kickstart.ks > > network --bootproto=static --device=eth0 --onboot=on --ip=$IPADDR > --netmask 255.255.255.0 --gateway 192.168.10.1 --nameserver 192.168.10.4 > --hostname=$HOSTNAME > > thanks for all the help so far > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From tom at ng23.net Fri Nov 23 17:23:21 2007 From: tom at ng23.net (Tom Brown) Date: Fri, 23 Nov 2007 17:23:21 +0000 Subject: [et-mgmt-tools] Contents of ks.cfg gets overwritten In-Reply-To: <47470268.2030302@ip-solutions.net> References: <4745B9C7.80402@ng23.net> <4745BBBF.704@ip-solutions.net> <4746F941.7070409@ng23.net> <47470268.2030302@ip-solutions.net> Message-ID: <47470C89.4080105@ng23.net> > cobbler system add --name=w3.fqdn.com --ksmeta="disks=sda,sdb > nameserver=192.168.1.3 netmask=255.255.255.0 gateway=192.168.1.201" > > man cobbler, and the wiki and doc webpages are great for this. > > the variables usually correspond with keywords that anaconda considers > valid within a kickstart file. > > so, --hostname=some.host.com, not HOSTNAME > > well the following is accepted by cobbler # cobbler system add --profile=CentOS-4.5-i386 --name=test --ip=192.168.10.23 --mac=00:0C:29:71:D7:4D --hostname=test but when the system boots it sits waiting for me to add IP information but the netmask and gateway are filled - it is getting them from the .ks # cat /etc/cobbler/kickstart_CentOS-4.5-i386.ks | grep network # Use network installation network --bootproto=static --device=eth0 --onboot=on --netmask 255.255.255.0 --gateway 192.168.10.1 --nameserver 192.168.10.4 can you please advise me on what my template file should look like? I have looked here https://hosted.fedoraproject.org/projects/cobbler/wiki/KickstartTemplating but i cant seem to figure it out thanks From martin.minka at gmail.com Fri Nov 23 17:47:04 2007 From: martin.minka at gmail.com (Martin Minka) Date: Fri, 23 Nov 2007 18:47:04 +0100 Subject: [et-mgmt-tools] does CENTOS5 import work in Cobbler ? In-Reply-To: <4746F3DB.7020807@ip-solutions.net> References: <4746CF93.5020202@gmail.com> <4746F3DB.7020807@ip-solutions.net> Message-ID: <47471218.6090906@gmail.com> Harry, files are attached. Cobbler version is 0.602. The error message looks strange for me and maybe it is not related to cobbler. I am not able now to try to install directly from CDROM, because I am far away from that server, so I am not able to exclude cobbler as the reason of this problem. Thank you for your help, Martin Harry Hoffman wrote: > I installed CentOS5 i386 without any error. > > That error seems to indicate a problem with where anaconda is trying > to log to (just a guess). > > Can you post your kickstart file, /var/lib/cobbler/settings and the > output of "cobbler report"? > > Also, what version of cobbler are you using? > > Cheers, > Harry > > > Martin Minka wrote: >> I imported CENTOS5 64bit DVD into Cobbler. >> cobbler import --mirror=/media/centos5 --name=C5_64 >> >> When I am installing it installer stops on error >> http://xmltvproducer.sourceforge.net/anaconda.png. >> >> I would like to prove with somebody who installed CENTOS5 over >> cobbler that it works for him and that the problem is not cobbler and >> its import function. >> >> Martin >> >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: settings URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: k2_simple.ks URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: report URL: From tom at ng23.net Fri Nov 23 18:50:23 2007 From: tom at ng23.net (Tom Brown) Date: Fri, 23 Nov 2007 18:50:23 +0000 Subject: [et-mgmt-tools] Problems adding/removing profiles/systems Message-ID: <474720EF.40908@ng23.net> Hi Sorry to be causing a lot of noise on here but once i get the basics i think i'll be quiet! I appear to have done something wrong, i am trying to add systems using variables. Anyhow i have put everything back to how it was (when it worked) i have only been editing my .ks's and trying to add a few systems. Anyhow whenever i do anything to my system now i am left with the the following. Can anyone help me 'reset' things as a cobbler sync blows up with the following. thanks for any pointers to debug these things! tom # cobbler system delete --name=test Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/cobbler/cobbler.py", line 783, in main BootCLI(sys.argv).run() File "/usr/lib/python2.3/site-packages/cobbler/cobbler.py", line 42, in __init__ self.api = api.BootAPI() File "/usr/lib/python2.3/site-packages/cobbler/api.py", line 43, in __init__ self.deserialize() File "/usr/lib/python2.3/site-packages/cobbler/api.py", line 227, in deserialize return self._config.deserialize() File "/usr/lib/python2.3/site-packages/cobbler/config.py", line 169, in deserialize if not serializer.deserialize(x,topological=True): File "/usr/lib/python2.3/site-packages/cobbler/serializer.py", line 64, in deserialize return storage_module.deserialize(obj,topological) File "/usr/lib/python2.3/site-packages/cobbler/modules/serializer_yaml.py", line 100, in deserialize datastruct = yaml.load(data).next() # first record File "/usr/lib/python2.3/site-packages/cobbler/yaml/load.py", line 84, in next return self.parseLines() File "/usr/lib/python2.3/site-packages/cobbler/yaml/load.py", line 93, in parseLines return self.parse_collection([], self.parse_seq_line) File "/usr/lib/python2.3/site-packages/cobbler/yaml/load.py", line 101, in parse_collection lineParser(items) File "/usr/lib/python2.3/site-packages/cobbler/yaml/load.py", line 107, in parse_seq_line items.append(self.parse_seq_value(value)) File "/usr/lib/python2.3/site-packages/cobbler/yaml/load.py", line 151, in parse_seq_value return self.parse_value(value) File "/usr/lib/python2.3/site-packages/cobbler/yaml/load.py", line 166, in parse_value value = self.parse_unaliased_value(value) File "/usr/lib/python2.3/site-packages/cobbler/yaml/load.py", line 181, in parse_unaliased_value return self.parse_untyped_value(value) File "/usr/lib/python2.3/site-packages/cobbler/yaml/load.py", line 230, in parse_untyped_value return self.parseLines() File "/usr/lib/python2.3/site-packages/cobbler/yaml/load.py", line 95, in parseLines return self.parse_collection(self.dictionary(), self.parse_map_line) File "/usr/lib/python2.3/site-packages/cobbler/yaml/load.py", line 101, in parse_collection lineParser(items) File "/usr/lib/python2.3/site-packages/cobbler/yaml/load.py", line 115, in parse_map_line self.parse_map_line_simple(items, self.line) File "/usr/lib/python2.3/site-packages/cobbler/yaml/load.py", line 134, in parse_map_line_simple items[key] = self.parse_value(value) File "/usr/lib/python2.3/site-packages/cobbler/yaml/load.py", line 166, in parse_value value = self.parse_unaliased_value(value) File "/usr/lib/python2.3/site-packages/cobbler/yaml/load.py", line 181, in parse_unaliased_value return self.parse_untyped_value(value) File "/usr/lib/python2.3/site-packages/cobbler/yaml/load.py", line 230, in parse_untyped_value return self.parseLines() File "/usr/lib/python2.3/site-packages/cobbler/yaml/load.py", line 93, in parseLines return self.parse_collection([], self.parse_seq_line) File "/usr/lib/python2.3/site-packages/cobbler/yaml/load.py", line 101, in parse_collection lineParser(items) File "/usr/lib/python2.3/site-packages/cobbler/yaml/load.py", line 109, in parse_seq_line self.error("missing '-' for seq") File "/usr/lib/python2.3/site-packages/cobbler/yaml/load.py", line 64, in error self.nestedDocs.error(msg, self.line) File "/usr/lib/python2.3/site-packages/cobbler/yaml/stream.py", line 188, in error raise YamlLoaderException(msg, self.lastLineRead(), line, self.filename) YamlLoaderException: missing '-' for seq: near line 19: gateway: '192.168.10.1' From smooge at gmail.com Fri Nov 23 18:54:59 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 23 Nov 2007 11:54:59 -0700 Subject: [et-mgmt-tools] does CENTOS5 import work in Cobbler ? In-Reply-To: <47471218.6090906@gmail.com> References: <4746CF93.5020202@gmail.com> <4746F3DB.7020807@ip-solutions.net> <47471218.6090906@gmail.com> Message-ID: <80d7e4090711231054yaa936b9r5c8c0dd3ad1516e5@mail.gmail.com> On Nov 23, 2007 10:47 AM, Martin Minka wrote: > Harry, > files are attached. > Cobbler version is 0.602. > > The error message looks strange for me and maybe it is not related to > cobbler. > I am not able now to try to install directly from CDROM, because I am > far away from that server, so I am not able to exclude cobbler as the > reason of this problem. I have cobbler imported via mirror cobbler repo add --name=centos-i386-3.9 --mirror=http://mirrors.kernel.org/centos/3.9/os/i386/ cobbler repo add --name=centos-i386-4.5 --mirror=http://mirrors.kernel.org/centos/4.5/os/i386/ cobbler repo add --name=centos-i386-5.0 --mirror=http://mirrors.kernel.org/centos/5.0/os/i386/ cobbler repo add --name=centos-i386-3.9-updates --mirror=http://mirrors.kernel.org/centos/3.9/updates/i386/ cobbler repo add --name=centos-i386-4.5-updates --mirror=http://mirrors.kernel.org/centos/4.5/updates/i386/ cobbler repo add --name=centos-i386-5.0-updates --mirror=http://mirrors.kernel.org/centos/5.0/updates/i386/ Seems to have worked fine. I did do it previously from DVDs and CDroms. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From martin.minka at gmail.com Fri Nov 23 19:37:19 2007 From: martin.minka at gmail.com (Martin Minka) Date: Fri, 23 Nov 2007 20:37:19 +0100 Subject: [et-mgmt-tools] does CENTOS5 import work in Cobbler ? In-Reply-To: <80d7e4090711231054yaa936b9r5c8c0dd3ad1516e5@mail.gmail.com> References: <4746CF93.5020202@gmail.com> <4746F3DB.7020807@ip-solutions.net> <47471218.6090906@gmail.com> <80d7e4090711231054yaa936b9r5c8c0dd3ad1516e5@mail.gmail.com> Message-ID: <47472BEF.8050103@gmail.com> Thank to tip from timverhoeven on IRC to look into pxelinux.cfg I identify the root of my problem and submitted bug report https://bugzilla.redhat.com/show_bug.cgi?id=397201. Thank for your time, Martin Stephen John Smoogen wrote: > On Nov 23, 2007 10:47 AM, Martin Minka wrote: > >> Harry, >> files are attached. >> Cobbler version is 0.602. >> >> The error message looks strange for me and maybe it is not related to >> cobbler. >> I am not able now to try to install directly from CDROM, because I am >> far away from that server, so I am not able to exclude cobbler as the >> reason of this problem. >> > > I have cobbler imported via mirror > > cobbler repo add --name=centos-i386-3.9 > --mirror=http://mirrors.kernel.org/centos/3.9/os/i386/ > cobbler repo add --name=centos-i386-4.5 > --mirror=http://mirrors.kernel.org/centos/4.5/os/i386/ > cobbler repo add --name=centos-i386-5.0 > --mirror=http://mirrors.kernel.org/centos/5.0/os/i386/ > cobbler repo add --name=centos-i386-3.9-updates > --mirror=http://mirrors.kernel.org/centos/3.9/updates/i386/ > cobbler repo add --name=centos-i386-4.5-updates > --mirror=http://mirrors.kernel.org/centos/4.5/updates/i386/ > cobbler repo add --name=centos-i386-5.0-updates > --mirror=http://mirrors.kernel.org/centos/5.0/updates/i386/ > > Seems to have worked fine. I did do it previously from DVDs and CDroms. > > From hhoffman at ip-solutions.net Fri Nov 23 22:17:01 2007 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Fri, 23 Nov 2007 17:17:01 -0500 Subject: [et-mgmt-tools] does CENTOS5 import work in Cobbler ? In-Reply-To: <47472BEF.8050103@gmail.com> References: <4746CF93.5020202@gmail.com> <4746F3DB.7020807@ip-solutions.net> <47471218.6090906@gmail.com> <80d7e4090711231054yaa936b9r5c8c0dd3ad1516e5@mail.gmail.com> <47472BEF.8050103@gmail.com> Message-ID: <4747515D.70403@ip-solutions.net> Hi Martin, Just read the bug report... You may actually want to file this against anaconda and not cobbler. I don't think anaconda will work with anything other than port 80 (standard http). I say this because there was some recent discussion on the kickstart list about trying to kickstart over SSL and that is not supported. It would be nice to have though :-) Cheers, Harry Martin Minka wrote: > Thank to tip from timverhoeven on IRC to look into pxelinux.cfg I > identify the root of my problem and submitted bug report > https://bugzilla.redhat.com/show_bug.cgi?id=397201. > > Thank for your time, > Martin > > > Stephen John Smoogen wrote: >> On Nov 23, 2007 10:47 AM, Martin Minka wrote: >> >>> Harry, >>> files are attached. >>> Cobbler version is 0.602. >>> >>> The error message looks strange for me and maybe it is not related to >>> cobbler. >>> I am not able now to try to install directly from CDROM, because I am >>> far away from that server, so I am not able to exclude cobbler as the >>> reason of this problem. >>> >> >> I have cobbler imported via mirror >> >> cobbler repo add --name=centos-i386-3.9 >> --mirror=http://mirrors.kernel.org/centos/3.9/os/i386/ >> cobbler repo add --name=centos-i386-4.5 >> --mirror=http://mirrors.kernel.org/centos/4.5/os/i386/ >> cobbler repo add --name=centos-i386-5.0 >> --mirror=http://mirrors.kernel.org/centos/5.0/os/i386/ >> cobbler repo add --name=centos-i386-3.9-updates >> --mirror=http://mirrors.kernel.org/centos/3.9/updates/i386/ >> cobbler repo add --name=centos-i386-4.5-updates >> --mirror=http://mirrors.kernel.org/centos/4.5/updates/i386/ >> cobbler repo add --name=centos-i386-5.0-updates >> --mirror=http://mirrors.kernel.org/centos/5.0/updates/i386/ >> >> Seems to have worked fine. I did do it previously from DVDs and CDroms. >> >> > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From smooge at gmail.com Fri Nov 23 22:32:51 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 23 Nov 2007 15:32:51 -0700 Subject: [et-mgmt-tools] does CENTOS5 import work in Cobbler ? In-Reply-To: <4747515D.70403@ip-solutions.net> References: <4746CF93.5020202@gmail.com> <4746F3DB.7020807@ip-solutions.net> <47471218.6090906@gmail.com> <80d7e4090711231054yaa936b9r5c8c0dd3ad1516e5@mail.gmail.com> <47472BEF.8050103@gmail.com> <4747515D.70403@ip-solutions.net> Message-ID: <80d7e4090711231432w9b86dcas9eecc90b70483320@mail.gmail.com> On Nov 23, 2007 3:17 PM, Harry Hoffman wrote: > Hi Martin, > > Just read the bug report... You may actually want to file this against > anaconda and not cobbler. > > I don't think anaconda will work with anything other than port 80 > (standard http). > > I say this because there was some recent discussion on the kickstart > list about trying to kickstart over SSL and that is not supported. > > It would be nice to have though :-) > > Cheers, > Harry > Yes anaconda will only work with HTTP. It doesnt have code to handle SSL certs and probably will not for various reasons that the anaconda people can talk about. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From martin.minka at gmail.com Fri Nov 23 23:04:16 2007 From: martin.minka at gmail.com (Martin Minka) Date: Sat, 24 Nov 2007 00:04:16 +0100 Subject: [et-mgmt-tools] does CENTOS5 import work in Cobbler ? In-Reply-To: <4747515D.70403@ip-solutions.net> References: <4746CF93.5020202@gmail.com> <4746F3DB.7020807@ip-solutions.net> <47471218.6090906@gmail.com> <80d7e4090711231054yaa936b9r5c8c0dd3ad1516e5@mail.gmail.com> <47472BEF.8050103@gmail.com> <4747515D.70403@ip-solutions.net> Message-ID: <47475C70.3070208@gmail.com> Harry, you are right that Anaconda is running only over HTTP, but it is not limited to port 80. It is totally ok to run for example over port 81. I did it successfully many times without Cobbler. The problem is that Cobbler creates wrong kernel option syslog if you set "server" in file settings to server with port. It would not even work if you put "server: 'x.x.x.x:80'. Cobbler is simply adding the syslog_port setting to the kernel option. So it happens that the generated pxelinux.cfg contains: syslog=x.x.x.x:81:25150 or syslog=x.x.x.x:80:25150 if you set port number to "server" variable and it should alway generate syslog=x.x.x.x:25150 Cobbler should replace the port number and not add a new one to it. So I really believe that it is problem of Cobbler and not Anaconda. Anaconda could improve the error message and add the syslog paramer to output. I reported that also to Centos bug tracker: http://bugs.centos.org/view.php?id=2463 Sincerely, Martin Harry Hoffman wrote: > Hi Martin, > > Just read the bug report... You may actually want to file this against > anaconda and not cobbler. > > I don't think anaconda will work with anything other than port 80 > (standard http). > > I say this because there was some recent discussion on the kickstart > list about trying to kickstart over SSL and that is not supported. > > It would be nice to have though :-) > > Cheers, > Harry > > Martin Minka wrote: >> Thank to tip from timverhoeven on IRC to look into pxelinux.cfg I >> identify the root of my problem and submitted bug report >> https://bugzilla.redhat.com/show_bug.cgi?id=397201. >> >> Thank for your time, >> Martin >> >> >> Stephen John Smoogen wrote: >>> On Nov 23, 2007 10:47 AM, Martin Minka wrote: >>> >>>> Harry, >>>> files are attached. >>>> Cobbler version is 0.602. >>>> >>>> The error message looks strange for me and maybe it is not related to >>>> cobbler. >>>> I am not able now to try to install directly from CDROM, because I am >>>> far away from that server, so I am not able to exclude cobbler as the >>>> reason of this problem. >>>> >>> >>> I have cobbler imported via mirror >>> >>> cobbler repo add --name=centos-i386-3.9 >>> --mirror=http://mirrors.kernel.org/centos/3.9/os/i386/ >>> cobbler repo add --name=centos-i386-4.5 >>> --mirror=http://mirrors.kernel.org/centos/4.5/os/i386/ >>> cobbler repo add --name=centos-i386-5.0 >>> --mirror=http://mirrors.kernel.org/centos/5.0/os/i386/ >>> cobbler repo add --name=centos-i386-3.9-updates >>> --mirror=http://mirrors.kernel.org/centos/3.9/updates/i386/ >>> cobbler repo add --name=centos-i386-4.5-updates >>> --mirror=http://mirrors.kernel.org/centos/4.5/updates/i386/ >>> cobbler repo add --name=centos-i386-5.0-updates >>> --mirror=http://mirrors.kernel.org/centos/5.0/updates/i386/ >>> >>> Seems to have worked fine. I did do it previously from DVDs and CDroms. >>> >>> >> >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From hhoffman at ip-solutions.net Sat Nov 24 03:58:17 2007 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Fri, 23 Nov 2007 22:58:17 -0500 Subject: [et-mgmt-tools] does CENTOS5 import work in Cobbler ? In-Reply-To: <47475C70.3070208@gmail.com> References: <4746CF93.5020202@gmail.com> <4746F3DB.7020807@ip-solutions.net> <47471218.6090906@gmail.com> <80d7e4090711231054yaa936b9r5c8c0dd3ad1516e5@mail.gmail.com> <47472BEF.8050103@gmail.com> <4747515D.70403@ip-solutions.net> <47475C70.3070208@gmail.com> Message-ID: <4747A159.7090901@ip-solutions.net> Martin, Aha! thanks for the heads up. I didn't realize that, it's good to know :-) And you are right, it certainly does sound like it belongs in Cobbler and not anaconda. Cheers, Harry Martin Minka wrote: > Harry, > you are right that Anaconda is running only over HTTP, but it is not > limited to port 80. It is totally ok to run for example over port 81. I > did it successfully many times without Cobbler. The problem is that > Cobbler creates wrong kernel option syslog if you set "server" in file > settings to server with port. It would not even work if you put "server: > 'x.x.x.x:80'. Cobbler is simply adding the syslog_port setting to the > kernel option. So it happens that the generated pxelinux.cfg contains: > syslog=x.x.x.x:81:25150 > or > syslog=x.x.x.x:80:25150 > if you set port number to "server" variable and it should alway generate > syslog=x.x.x.x:25150 > > Cobbler should replace the port number and not add a new one to it. > So I really believe that it is problem of Cobbler and not Anaconda. > Anaconda could improve the error message and add the syslog paramer to > output. I reported that also to Centos bug tracker: > http://bugs.centos.org/view.php?id=2463 > > Sincerely, > Martin > > Harry Hoffman wrote: >> Hi Martin, >> >> Just read the bug report... You may actually want to file this against >> anaconda and not cobbler. >> >> I don't think anaconda will work with anything other than port 80 >> (standard http). >> >> I say this because there was some recent discussion on the kickstart >> list about trying to kickstart over SSL and that is not supported. >> >> It would be nice to have though :-) >> >> Cheers, >> Harry >> >> Martin Minka wrote: >>> Thank to tip from timverhoeven on IRC to look into pxelinux.cfg I >>> identify the root of my problem and submitted bug report >>> https://bugzilla.redhat.com/show_bug.cgi?id=397201. >>> >>> Thank for your time, >>> Martin >>> >>> >>> Stephen John Smoogen wrote: >>>> On Nov 23, 2007 10:47 AM, Martin Minka wrote: >>>> >>>>> Harry, >>>>> files are attached. >>>>> Cobbler version is 0.602. >>>>> >>>>> The error message looks strange for me and maybe it is not related to >>>>> cobbler. >>>>> I am not able now to try to install directly from CDROM, because I am >>>>> far away from that server, so I am not able to exclude cobbler as the >>>>> reason of this problem. >>>>> >>>> >>>> I have cobbler imported via mirror >>>> >>>> cobbler repo add --name=centos-i386-3.9 >>>> --mirror=http://mirrors.kernel.org/centos/3.9/os/i386/ >>>> cobbler repo add --name=centos-i386-4.5 >>>> --mirror=http://mirrors.kernel.org/centos/4.5/os/i386/ >>>> cobbler repo add --name=centos-i386-5.0 >>>> --mirror=http://mirrors.kernel.org/centos/5.0/os/i386/ >>>> cobbler repo add --name=centos-i386-3.9-updates >>>> --mirror=http://mirrors.kernel.org/centos/3.9/updates/i386/ >>>> cobbler repo add --name=centos-i386-4.5-updates >>>> --mirror=http://mirrors.kernel.org/centos/4.5/updates/i386/ >>>> cobbler repo add --name=centos-i386-5.0-updates >>>> --mirror=http://mirrors.kernel.org/centos/5.0/updates/i386/ >>>> >>>> Seems to have worked fine. I did do it previously from DVDs and CDroms. >>>> >>>> >>> >>> _______________________________________________ >>> et-mgmt-tools mailing list >>> et-mgmt-tools at redhat.com >>> https://www.redhat.com/mailman/listinfo/et-mgmt-tools >> >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools >> > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From mdehaan at redhat.com Mon Nov 26 15:45:05 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 26 Nov 2007 10:45:05 -0500 Subject: [et-mgmt-tools] anaconda crashes with cobbler-generated kickstart-file In-Reply-To: <60757.212.71.112.230.1195645752.squirrel@www.ultra-secure.de> References: <60757.212.71.112.230.1195645752.squirrel@www.ultra-secure.de> Message-ID: <474AEA01.6020403@redhat.com> Rainer Duffner wrote: > Hi, > > I'm trying out cobbler. > 0.6.4-2 is installed (and configured). > I imported the RHEL5.1 repository from the DVD image. > The duplicate repo entries look wrong to me. However, they shouldn't crash Anaconda. The question is... why are they in there twice? Did you do the import using a previous cobbler version*? I know there were quite a few fixes to repository handling added for 0.6.4. (* = that's supported, but 0.6.3 was a bit glitchy when dealing with the repo aspects) --Michael From mdehaan at redhat.com Mon Nov 26 15:49:54 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 26 Nov 2007 10:49:54 -0500 Subject: [et-mgmt-tools] CentOS 4.5 - cobbler-0.5.0-1.el4.rf - check error In-Reply-To: <4744B282.5080706@ng23.net> References: <474463AF.7000300@ng23.net> <47447AFC.4000903@ng23.net> <4744847F.9050300@gmail.com> <4744A6F8.4080108@ng23.net> <20071121222439.GB12490@math.ohiou.edu> <4744B282.5080706@ng23.net> Message-ID: <474AEB22.5070907@redhat.com> Tom Brown wrote: > >> I have packages available at >> http://www.math.ohiou.edu/pub/casit/et-tools/ >> >> These will eventually make it into CentOS Extras or rpmrepo, after >> 4.6 and >> 5.1 are out the door. >> >> Currently 0.6.2 is up there, but I'm updating to 0.6.4 now. >> >> > > > thanks - i used git to get the latest source and built that OK > > # rpm -qa | grep cobbler > cobbler-0.6.5-1 > > I just grabbed your latest koan though thanks! > > Tom > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools I really should check mail when on vacation :) Glad you worked through it. In general, if using RHEL (or Centos, Scientific Linux, etc) get the latest version of Cobbler and koan from EPEL, as described on the download page. http://cobbler.et.redhat.com/download.php . rpmforge or other similar places can be old. The latest source rpms are also up at http://cobbler.et.redhat.com/download as mentioned on the web site... if you want to rebuild those, that also works. (FYI -- 0.6.5 from git is currently equivalent to 0.6.4-2, seeing 0.6.4-2 just came out) --Michael From mdehaan at redhat.com Mon Nov 26 15:53:01 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 26 Nov 2007 10:53:01 -0500 Subject: [et-mgmt-tools] Repo Mirroring & Fedora 8 Import In-Reply-To: <4744DA2A.4000302@cdChase.com> References: <4744DA2A.4000302@cdChase.com> Message-ID: <474AEBDD.7010700@redhat.com> C. Daniel Chase wrote: > I've recently learned that the latest Fedora 8 online repo contains more > files than are included on the DVD I used for import. That's right, updates aren't on the DVD... > While I have the > Fedora-Updates repository mirrored, the extra files that are included in > the original distro, that have not had updates, are not available in > either location. > > Looks like you need to attach the repo to the profile... cobbler profile edit --name=foo --repos="f8updates repo2 repo3 etc" > Anyone have a better solution? I suppose I could rsync the files, but > the related cache, etc won't be properly updated. Though, I suppose the > files would all there. > See above. > -Dan > > PS--I'm fine tuning a patch to give better output for use in using > reposync in batch mode. Requires a coordinated update to Yum as well. > > Updated yum? Cobbler needs to require stock versions as available in each of the distros. Can you explain more about what this does? From mdehaan at redhat.com Mon Nov 26 15:54:47 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 26 Nov 2007 10:54:47 -0500 Subject: [et-mgmt-tools] template error on system add In-Reply-To: <47459ECC.7070607@ng23.net> References: <47459ECC.7070607@ng23.net> Message-ID: <474AEC47.8010306@redhat.com> Tom Brown wrote: > Hi > > I am slowly getting further i hope but when i add a system i encounter > the following > > # cobbler system add --name=00:0C:29:71:D7:4D --profile=centos4.4 > There appears to be an formatting error in the template file. > For completeness, the traceback from Cheetah has been included below. I'm not seeing the traceback, but it looks like you need to escape the dollar signs in your "iscrypted" password entry. Please read this: https://hosted.fedoraproject.org/projects/cobbler/wiki/KickstartTemplating From mdehaan at redhat.com Mon Nov 26 15:58:30 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 26 Nov 2007 10:58:30 -0500 Subject: [et-mgmt-tools] Contents of ks.cfg gets overwritten In-Reply-To: <47470C89.4080105@ng23.net> References: <4745B9C7.80402@ng23.net> <4745BBBF.704@ip-solutions.net> <4746F941.7070409@ng23.net> <47470268.2030302@ip-solutions.net> <47470C89.4080105@ng23.net> Message-ID: <474AED26.3060202@redhat.com> Tom Brown wrote: > >> cobbler system add --name=w3.fqdn.com --ksmeta="disks=sda,sdb >> nameserver=192.168.1.3 netmask=255.255.255.0 gateway=192.168.1.201" >> >> man cobbler, and the wiki and doc webpages are great for this. >> >> the variables usually correspond with keywords that anaconda >> considers valid within a kickstart file. >> >> so, --hostname=some.host.com, not HOSTNAME >> >> > > well the following is accepted by cobbler > > # cobbler system add --profile=CentOS-4.5-i386 --name=test > --ip=192.168.10.23 --mac=00:0C:29:71:D7:4D --hostname=test > > but when the system boots it sits waiting for me to add IP information > but the netmask and gateway are filled - it is getting them from the .ks > > # cat /etc/cobbler/kickstart_CentOS-4.5-i386.ks | grep network > # Use network installation > network --bootproto=static --device=eth0 --onboot=on --netmask > 255.255.255.0 --gateway 192.168.10.1 --nameserver 192.168.10.4 > > can you please advise me on what my template file should look like? > > I have looked here > > https://hosted.fedoraproject.org/projects/cobbler/wiki/KickstartTemplating > > > but i cant seem to figure it out > > thanks > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools Tom, You might be interested in joining #cobbler on irc.freenode.net. There are lots of folks that can help walk you through the templating stuff. Looks like you are missing the line to "network" that adds your IP address to the kickstart :) That's as simple as adding $ip_address and $mac_address in the right places of the file. At the bottom of the kickstart templating page there are also pointers to how kickstart directives work, and a link to a good presentation from Linux World that explains some advanced stuff also. --Michael From mdehaan at redhat.com Mon Nov 26 16:02:57 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 26 Nov 2007 11:02:57 -0500 Subject: [et-mgmt-tools] does CENTOS5 import work in Cobbler ? In-Reply-To: <4746CF93.5020202@gmail.com> References: <4746CF93.5020202@gmail.com> Message-ID: <474AEE31.4020100@redhat.com> Martin Minka wrote: > I imported CENTOS5 64bit DVD into Cobbler. > cobbler import --mirror=/media/centos5 --name=C5_64 > > When I am installing it installer stops on error > http://xmltvproducer.sourceforge.net/anaconda.png. > > I would like to prove with somebody who installed CENTOS5 over cobbler > that it works for him and that the problem is not cobbler and its > import function. > > Martin > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools Hi Martin, I do imports and installs /quite/ often, as do many of the people who hang out in #cobbler on irc.freenode.net ... it most definitely works :) Perhaps you'd like to stop by and maybe we can help debug your problem? Looks like Anaconda is getting fed something it doesn't like in your kickstart file and/or kernel arguments, but it's hard to be sure with just the information you provided. Kickstart can be a little tricky but with a bit more information about your kickstart file and the profile settings you used, it will probably be very easy to figure out. Thanks! --Michael From mdehaan at redhat.com Mon Nov 26 16:06:43 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 26 Nov 2007 11:06:43 -0500 Subject: [et-mgmt-tools] does CENTOS5 import work in Cobbler ? In-Reply-To: <4747A159.7090901@ip-solutions.net> References: <4746CF93.5020202@gmail.com> <4746F3DB.7020807@ip-solutions.net> <47471218.6090906@gmail.com> <80d7e4090711231054yaa936b9r5c8c0dd3ad1516e5@mail.gmail.com> <47472BEF.8050103@gmail.com> <4747515D.70403@ip-solutions.net> <47475C70.3070208@gmail.com> <4747A159.7090901@ip-solutions.net> Message-ID: <474AEF13.3080907@redhat.com> Harry Hoffman wrote: > Martin, > > Aha! thanks for the heads up. I didn't realize that, it's good to know > :-) > > And you are right, it certainly does sound like it belongs in Cobbler > and not anaconda. Hmm, I see what you're doing now. The field you edited is not a field for port numbers. It's either a hostname or an IP. Cobbler itself adds other ports to the end of that address. So, it sounds like this is actually an RFE for supporting a http port parameter :) --Michael From mdehaan at redhat.com Mon Nov 26 16:11:11 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 26 Nov 2007 11:11:11 -0500 Subject: [et-mgmt-tools] Problems adding/removing profiles/systems In-Reply-To: <474720EF.40908@ng23.net> References: <474720EF.40908@ng23.net> Message-ID: <474AF01F.5040207@redhat.com> Tom Brown wrote: > Hi > > Sorry to be causing a lot of noise on here but once i get the basics i > think i'll be quiet! > > I appear to have done something wrong, i am trying to add systems > using variables. Anyhow i have put everything back to how it was (when > it worked) i have only been editing my .ks's and trying to add a few > systems. > > Anyhow whenever i do anything to my system now i am left with the the > following. Can anyone help me 'reset' things as a cobbler sync blows > up with the following. > > thanks for any pointers to debug these things! > > tom > > Tom, Looks like you've had a fun week. :) I'm not sure what you mean by "adding systems using variables". Anyhow, it looks like you've added some junk to your cobbler data files somehow, and now they aren't formatted correctly. I'm not sure if you hand edited them or just managed to trick the CLI into adding things to them, but the easiest way to fix things is... rm /var/lib/cobbler/distros rm /var/lib/cobbler/profiles rm /var/lib/cobbler/systems rm /var/lib/cobbler/repos This will erase your current cobbler configuration and allow you to start over. You might want to consider keeping backups of /var/lib/cobbler. If you think this is something you've managed to do with the CLI and not by hand-editing the files, you may want to send me a copy of those files off list and maybe I can figure out what happened to them. --Michael From rainer at ultra-secure.de Mon Nov 26 16:22:36 2007 From: rainer at ultra-secure.de (Rainer Duffner) Date: Mon, 26 Nov 2007 17:22:36 +0100 Subject: [et-mgmt-tools] anaconda crashes with cobbler-generated kickstart-file In-Reply-To: <474AEA01.6020403@redhat.com> References: <60757.212.71.112.230.1195645752.squirrel@www.ultra-secure.de> <474AEA01.6020403@redhat.com> Message-ID: <474AF2CC.8040802@ultra-secure.de> Michael DeHaan wrote: > Rainer Duffner wrote: >> Hi, >> >> I'm trying out cobbler. >> 0.6.4-2 is installed (and configured). >> I imported the RHEL5.1 repository from the DVD image. >> > > The duplicate repo entries look wrong to me. However, they > shouldn't crash Anaconda. > > The question is... why are they in there twice? Did you do the > import using a previous cobbler version*? Yes, 0.6.3 IIRC. I've now found that the $yum_repo_stanza tag is responsible for it and it has to be cleared before it works. Then, there was this problem with LVM. See my last post before the weekend for what actually worked in the end. . This was very puzzling for me. It basically seems to work now, and is useful (and looking promising). I must now try koan (because I have some servers that can't do DHCP) I may have more questions in the future ;-) cheers, Rainer From tom at ng23.net Mon Nov 26 16:36:23 2007 From: tom at ng23.net (Tom Brown) Date: Mon, 26 Nov 2007 16:36:23 +0000 Subject: [et-mgmt-tools] Problems adding/removing profiles/systems In-Reply-To: <474AF01F.5040207@redhat.com> References: <474720EF.40908@ng23.net> <474AF01F.5040207@redhat.com> Message-ID: <474AF607.9010205@ng23.net> > Looks like you've had a fun week. :) > > I'm not sure what you mean by "adding systems using variables". > > Anyhow, it looks like you've added some junk to your cobbler data > files somehow, and now they aren't formatted correctly. I'm not sure > if you hand edited them or just managed to trick the CLI into adding > things to them, but the easiest way to fix things is... > > rm /var/lib/cobbler/distros > rm /var/lib/cobbler/profiles > rm /var/lib/cobbler/systems > rm /var/lib/cobbler/repos > > This will erase your current cobbler configuration and allow you to > start over. You might want to consider keeping backups of > /var/lib/cobbler. > > If you think this is something you've managed to do with the CLI and > not by hand-editing the files, you may want to send me a copy of those > files off list and maybe I can figure out what happened to them. Hi Michael Yes - end of last week was interesting for sure!! Thanks for the many replies that you sent. To cut a long story short i have pretty much got things going now so that i can do something along the lines of a # ./buildbox.sh 00:0C:29:71:D7:4D 192.168.10.25 getting-there 192.168.10.1 CentOS-4.5-i386 on the cobbler box and this will do its magic on the target machines - So builds, and rebuilds using koan, are so far working great. I am not sure how i managed to get something into the cobbler config but it was not hand generated as such, i definately introduced it using the cobbler system add command however it was part of the --ksmeta that caused it grief. In the end i hand edited /var/lib/cobbler/systems and figured out the broken bit enough to be able to remove the system cleanly. I am still getting to grips but i have the system running and the gui functional and so far so good - thanks again tom From rabbott at ticom-geo.com Mon Nov 26 17:22:34 2007 From: rabbott at ticom-geo.com (Richard Abbott) Date: Mon, 26 Nov 2007 11:22:34 -0600 Subject: [et-mgmt-tools] cobbler using old IP address Message-ID: <474B00DA.8020108@ticom-geo.com> I am having an issue with cobbler holding onto an old ip address. I have gotten cobbler installed and several systems successfully reimaging themselves on a weekly basis from the cobbler server. Last week it was necessary to change the ip address of the cobbler server from 192.168.1.163 to 192.168.0.163. I have gone through and updated the kickstart file to reflect the change and run a cobbler sync. Then when I tried to reinstall one of the clients with koan I got the following output [root at camaro ~]# koan --server=192.168.0.163 --replace-self - Auto detected: camaro - using kickstart from cobbler: http://192.168.1.163/cblr/kickstarts_sys/camaro/ks.cfg Unable to download kickstart, perhaps cobbler sync was not run recently, Apache is not running, or the server address in the cobbler settings file is wrong. I went through all of the files in the /var/www/cobbler directories(distro, kickstarts, systems, etc.) and found 192.168.1.163 sprinkled in many different files. I went through and hand modified each file to have the correct 0.163 address. When I ran cobbler sync again all of the files reverted back to the 192.168.1.163 address. I am not sure what I need to do to make the cobbler server files have the correct addresses in them. Thanks -- Richard Abbott TICOM Geomatics, Inc. 9130 Jollyville Rd, Ste 300 Austin, TX 78759 Office : (512)610-8340 Fax : (512)345-9992 Cell : (512)422-2352 From mdehaan at redhat.com Mon Nov 26 17:29:23 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 26 Nov 2007 12:29:23 -0500 Subject: [et-mgmt-tools] cobbler using old IP address In-Reply-To: <474B00DA.8020108@ticom-geo.com> References: <474B00DA.8020108@ticom-geo.com> Message-ID: <474B0273.30308@redhat.com> Richard Abbott wrote: > I am having an issue with cobbler holding onto an old ip address. > > I have gotten cobbler installed and several systems successfully > reimaging themselves on a weekly basis from the cobbler server. Last > week it was necessary to change the ip address of the cobbler server > from 192.168.1.163 to 192.168.0.163. I have gone through and updated the > kickstart file to reflect the change and run a cobbler sync. > > Then when I tried to reinstall one of the clients with koan I got the > following output > > [root at camaro ~]# koan --server=192.168.0.163 --replace-self > - Auto detected: camaro > - using kickstart from cobbler: > http://192.168.1.163/cblr/kickstarts_sys/camaro/ks.cfg > Unable to download kickstart, perhaps cobbler sync was not run recently, > Apache is not running, or the server address in the cobbler settings > file is wrong. > > I went through all of the files in the /var/www/cobbler > directories(distro, kickstarts, systems, etc.) and found 192.168.1.163 > sprinkled in many different files. I went through and hand modified each > file to have the correct 0.163 address. When I ran cobbler sync again > all of the files reverted back to the 192.168.1.163 address. > > I am not sure what I need to do to make the cobbler server files have > the correct addresses in them. > > I would first upgrade to 0.6.4 if you haven't already. There's some work done there to make cobbler much easier to migrate between server addresses. If you are running an older version, carefully edit the values in /var/lib/cobbler/distros and you'll be able to migrate it. Once you upgrade to 0.6.4, you can replace the addresses in that file with "@@server@@" and then all you'll ever have to edit is the one field in /var/lib/cobbler/settings. (You shouldn't edit files in /var/www/cobbler because they are output from cobbler sync. They are not input files) From mdehaan at redhat.com Mon Nov 26 17:33:16 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 26 Nov 2007 12:33:16 -0500 Subject: [et-mgmt-tools] anaconda crashes with cobbler-generated kickstart-file In-Reply-To: <474AF2CC.8040802@ultra-secure.de> References: <60757.212.71.112.230.1195645752.squirrel@www.ultra-secure.de> <474AEA01.6020403@redhat.com> <474AF2CC.8040802@ultra-secure.de> Message-ID: <474B035C.9060900@redhat.com> Rainer Duffner wrote: > Michael DeHaan wrote: > >> Rainer Duffner wrote: >> >>> Hi, >>> >>> I'm trying out cobbler. >>> 0.6.4-2 is installed (and configured). >>> I imported the RHEL5.1 repository from the DVD image. >>> >>> >> The duplicate repo entries look wrong to me. However, they >> shouldn't crash Anaconda. >> >> The question is... why are they in there twice? Did you do the >> import using a previous cobbler version*? >> > > Yes, 0.6.3 IIRC. > I've now found that the $yum_repo_stanza tag is responsible for it and > it has to be cleared before it works. > 0.6.3 had some issues with creating some duplicate repo definitions. Should be fixed in 0.6.4 ... you may want to re-import, then do a cobbler reposync, then a cobbler sync. From rabbott at ticom-geo.com Mon Nov 26 17:41:10 2007 From: rabbott at ticom-geo.com (Richard Abbott) Date: Mon, 26 Nov 2007 11:41:10 -0600 Subject: [et-mgmt-tools] cobbler using old IP address In-Reply-To: <474B0273.30308@redhat.com> References: <474B00DA.8020108@ticom-geo.com> <474B0273.30308@redhat.com> Message-ID: <474B0536.2040402@ticom-geo.com> Michael, Was already running 0.6.4-2 so I replaced the addresses in the distros file with @@server@@ and made the necessary changes in the settings file and its working beautifully again. Thanks for the quick response. -- Richard Abbott TICOM Geomatics, Inc. 9130 Jollyville Rd, Ste 300 Austin, TX 78759 Office : (512)610-8340 Fax : (512)345-9992 Cell : (512)422-2352 Michael DeHaan wrote: > Richard Abbott wrote: >> I am having an issue with cobbler holding onto an old ip address. >> >> I have gotten cobbler installed and several systems successfully >> reimaging themselves on a weekly basis from the cobbler server. Last >> week it was necessary to change the ip address of the cobbler server >> from 192.168.1.163 to 192.168.0.163. I have gone through and updated the >> kickstart file to reflect the change and run a cobbler sync. >> >> Then when I tried to reinstall one of the clients with koan I got the >> following output >> >> [root at camaro ~]# koan --server=192.168.0.163 --replace-self >> - Auto detected: camaro >> - using kickstart from cobbler: >> http://192.168.1.163/cblr/kickstarts_sys/camaro/ks.cfg >> Unable to download kickstart, perhaps cobbler sync was not run recently, >> Apache is not running, or the server address in the cobbler settings >> file is wrong. >> >> I went through all of the files in the /var/www/cobbler >> directories(distro, kickstarts, systems, etc.) and found 192.168.1.163 >> sprinkled in many different files. I went through and hand modified each >> file to have the correct 0.163 address. When I ran cobbler sync again >> all of the files reverted back to the 192.168.1.163 address. >> >> I am not sure what I need to do to make the cobbler server files have >> the correct addresses in them. >> >> > > I would first upgrade to 0.6.4 if you haven't already. There's some > work done there to make cobbler much easier to migrate between server > addresses. > > If you are running an older version, carefully edit the values in > /var/lib/cobbler/distros and you'll be able to migrate it. > Once you upgrade to 0.6.4, you can replace the addresses in that file > with "@@server@@" and then all you'll ever have to edit is the one > field in /var/lib/cobbler/settings. > > (You shouldn't edit files in /var/www/cobbler because they are output > from cobbler sync. They are not input files) > > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From mdehaan at redhat.com Mon Nov 26 18:05:48 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 26 Nov 2007 13:05:48 -0500 Subject: [et-mgmt-tools] Thoughts on Cobbler authorization/authentication and access levels in your organization? Message-ID: <474B0AFC.6070904@redhat.com> Hi folks, I'm getting ready to add support for user-level authentication/authorization to Cobbler. While I am going to implement this using Cobbler modules to make it completely customizable in terms of tools and policy, it would be nice if most things "just worked" too, so this is where the call for user opinions comes in. If you have a large organization, how do you want Cobbler to work in that organization? For many people the answer is just "let the admins have full control", which is fine, though I know many of you want finer grained access. That's what I want to enable. We don't want to require a specific workflow, but do want to enable the ones that need to exist. So ... at this point, it's important to understand the ways different people would want to use this, so that we make sure the right things are there and possible. There are two aspects to this. (1) What sort of policy do folks need ... what does a multi-user cobbler workflow look like? (2) What sorts of existing authentication/authorization systems are already in place, or want to be used* (i.e. kerberos, etc). How do you want to maintain user/group information (LDAP, etc?). The simplest example use case (that we have now) looks like this: (A) Admins X, Y, and Z all have different passwords and can do anything. What I see as the more corporate use case looks something like this: (A) Dave and Sammy work for the central IT group of ACME Corp. They create distros and profiles for other people to use, including production boxes. (B) Gary is an admin for Lab A. He can inherit from profiles created by Dave/Sammy, or make up his own. He can also add systems. (C) Eddie is an admin for Lab B. He can also do the same kinds of things as Gary, but cannot muck with Gary's configurations. (D) Alex is an ordinary user. He can use koan against any existing profiles, and can PXE boot, and possibly edit just the profile setting of the systems that he owns (if any). Now there is a /slight/ problem if Gary adds a MAC address that isn't in Eddie's lab, but that should be something an admin can fix. Anyhow, if you have opinions/comments on how you might want to grant tiered access in Cobbler, now is the time to speak up! This is just as much for the WebUI as it is for the software in general, so if you were building another web app on Cobbler that gave a simpler view to users, or so on, it could use these things also. (Replying offline with technical/organizational details is totally fine. The more detail I can get the better ... and I'll try to summarize all of these later). --Michael From tom at ng23.net Mon Nov 26 20:41:25 2007 From: tom at ng23.net (Tom Brown) Date: Mon, 26 Nov 2007 20:41:25 +0000 Subject: [et-mgmt-tools] koan-0.6.3-3.el4.mrh - kix templating - network rebuilt issue Message-ID: <474B2F75.30008@ng23.net> Hi I have been 'improving' my kix and starting to use templating and using variables e.g I use snippets in the network config and that looks like this # cat /var/lib/cobbler/snippets/network_select network --bootproto=static --device=eth0 --onboot=on --ip=$ip_address --netmask=$netmask --gateway=$gateway --nameserver=$nameserver --hostname=$hostname and to build a machine i do something like this # cat buildbox.sh #!/bin/sh cobbler system add --name=$1 --mac=$2 --ksmeta="ip_address=$3 netmask=255.255.255.0 hostname=$4 nameserver=192.168.10.4 gateway=$5" --profile=$6 I would then do something like the following to build a box # ./buildbox.sh 00:0C:29:71:D7:4D 192.168.10.25 foobar 192.168.10.1 CentOS-4.5-i386 These will build fine - but here is the issue. When i use koan to rebuild the box using the same profile then everything is fine eg # koan -r -s build-server Now if i try to rebuild to a different profile that is available on the server e.g # koan -p CentOS-4.4-i386 -r -s build-server the kix details appear correct but on reboot the install stops on the IP configuration screen, ie waiting for manual input Has anyone else seen this or know of workarounds? If i manually put network into into the ks.cfg then the rebuild works as expected? thanks From mdehaan at redhat.com Mon Nov 26 20:51:18 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 26 Nov 2007 15:51:18 -0500 Subject: [et-mgmt-tools] koan-0.6.3-3.el4.mrh - kix templating - network rebuilt issue In-Reply-To: <474B2F75.30008@ng23.net> References: <474B2F75.30008@ng23.net> Message-ID: <474B31C6.1040706@redhat.com> > > Has anyone else seen this or know of workarounds? If i manually put > network into into the ks.cfg then the rebuild works as expected? > Cobbler renders it's kickstart template output in /var/www/cobbler/kickstarts and/or kickstarts_sys depending on whether you're talking about a profile or kickstart level of evaluation. Look in those directories and see if the kickstarts match what you expect them to look like. --Michael From jjneely at ncsu.edu Mon Nov 26 20:57:12 2007 From: jjneely at ncsu.edu (Jack Neely) Date: Mon, 26 Nov 2007 15:57:12 -0500 Subject: [et-mgmt-tools] Thoughts on Cobbler authorization/authentication and access levels in your organization? In-Reply-To: <474B0AFC.6070904@redhat.com> References: <474B0AFC.6070904@redhat.com> Message-ID: <20071126205712.GH8398@anduril.unity.ncsu.edu> Michael, Here at NCSU I have an existing provisioning system that generates kickstarts based on a set of "keyword [value [value...]]" rules. We'd like to continue to use that as it works well for us...and it integrates with Cobbler well. So given that, admins already have the ability to control/alter their profiles in a defined way that scales well and lonely me can support. What I'd like from Cobbler is the ability for a select few admins (like me) to be able to setup all the bits to make Cobbler distros/profiles etc. work. Normal admins should be able to associate a MAC address with a profile and remove said MAC. Actually, it would be great if an admin could associate a hostname/IP address with a profile and Cobbler would run a plugin to translate that into a MAC. Groups of admins as well. Any admin can modify MAC->profile of any other admin provided both are in the same group. Authentication via kerberos (PAM probably) authorization done by auto generated groups of admins (a plugin)? Okay...some half-baked ideas about how I see a workflow here. If you have questions please feel free. Jack Neely -- Jack Neely Linux Czar, OIT Campus Linux Services Office of Information Technology, NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From Greg.Caetano at hp.com Mon Nov 26 20:56:12 2007 From: Greg.Caetano at hp.com (Caetano, Greg) Date: Mon, 26 Nov 2007 20:56:12 +0000 Subject: [et-mgmt-tools] Cobbler import error on kickstart Message-ID: Below is output of a cobbler import using cobbler.6.4-2. I have not been able to figure out why the import fail after the first 2 succeed. Thanks Greg # cobbler import --name=rhel46 --available-as=nfs://192.168.0.1:/var/www/html/kits/RHEL4/i386 --path=/var/www/html/RHEL4/i386 ---------------- (adding distros) - creating new distro: rhel46-i386 - creating new profile: rhel46-i386 - creating new distro: rhel46-xen-i386 - creating new profile: rhel46-xen-i386 ---------------- (associating kickstarts) - finding default kickstart template for redhat 4 - using default kickstart file choice - tree: nfs://192.168.0.1:/var/www/html/kits/RHEL4/i386/ - finding default kickstart template for redhat 4 - using default kickstart file choice - tree: nfs://192.168.0.1:/var/www/html/kits/RHEL4/i386/ ---------------- (syncing) sync distro: rhel46-i386 sync distro: rhel46-xen-i386 sync profile: rhel46-i386 sync profile: rhel46-xen-i386 Shutting down dhcpd: [ OK ] Starting dhcpd: [ OK ] # cobbler import --name=r64el51 --available-as=nfs://192.168.0.1:/var/www/html/kits/RHEL51/x86_64 --path=/var/www/html/RHEL51/x86_64 ---------------- (adding distros) - creating new distro: r64el51-x86_64 - creating new profile: r64el51-x86_64 - creating new distro: r64el51-xen-x86_64 - creating new profile: r64el51-xen-x86_64 ---------------- (associating kickstarts) - skipping distro rhel46-i386 since it wasn't imported this time - finding default kickstart template for redhat 5.0 - tree: nfs://192.168.0.1:/var/www/html/kits/RHEL51/x86_64/ - finding default kickstart template for redhat 5.0 - tree: nfs://192.168.0.1:/var/www/html/kits/RHEL51/x86_64/ - skipping distro rhel46-xen-i386 since it wasn't imported this time ---------------- (syncing) sync distro: rhel46-i386 sync distro: r64el51-x86_64 sync distro: r64el51-xen-x86_64 sync distro: rhel46-xen-i386 sync profile: rhel46-i386 sync profile: r64el51-x86_64 sync profile: r64el51-xen-x86_64 sync profile: rhel46-xen-i386 Shutting down dhcpd: [ OK ] Starting dhcpd: [ OK ] # cobbler import --name=rhel51 --available-as=nfs://192.168.0.1/var/www/html/kits/RHEL51/i386 --path=/var/www/html/RHEL51/i386 ---------------- (adding distros) - creating new distro: rhel51-i386 - creating new profile: rhel51-i386 - creating new distro: rhel51-xen-i386 - creating new profile: rhel51-xen-i386 ---------------- (associating kickstarts) - skipping distro r64el51-x86_64 since it wasn't imported this time - finding default kickstart template for redhat 5.0 - tree: nfs://192.168.0.1/var/www/html/kits/RHEL51/i386/ - skipping distro rhel46-i386 since it wasn't imported this time - skipping distro rhel46-xen-i386 since it wasn't imported this time - skipping distro r64el51-xen-x86_64 since it wasn't imported this time - finding default kickstart template for redhat 5.0 - tree: nfs://192.168.0.1/var/www/html/kits/RHEL51/i386/ ---------------- (syncing) sync distro: r64el51-x86_64 sync distro: rhel51-i386 sync distro: rhel46-i386 sync distro: rhel46-xen-i386 sync distro: r64el51-xen-x86_64 sync distro: rhel51-xen-i386 sync profile: r64el51-x86_64 sync profile: rhel51-i386 Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/cobbler/action_sync.py", line 372, in validate_kickstart_for_specific_profile self.apply_template(kfile, meta, dest) File "/usr/lib/python2.4/site-packages/cobbler/action_sync.py", line 610, in apply_template (server, dir) = rest.split(":",2) ValueError: need more than 1 value to unpack Error while rendering kickstart file /etc/cobbler/kickstart_fc6.ks to /var/www/cobbler/kickstarts/rhel51-i386/ks.cfg # From mdehaan at redhat.com Mon Nov 26 21:08:41 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 26 Nov 2007 16:08:41 -0500 Subject: [et-mgmt-tools] Cobbler import error on kickstart In-Reply-To: References: Message-ID: <474B35D9.8020209@redhat.com> Caetano, Greg wrote: > Below is output of a cobbler import using cobbler.6.4-2. I have not been able to figure out why the import fail after the first 2 succeed. > > Thanks > Greg > It's the second colon, which is missing in one of your imports. Change: --available-as=nfs://192.168.0.1/var/www/html/kits/RHEL51/i386 To: --available-as=nfs://192.168.0.1:/var/www/html/kits/RHEL51/i386 This warrants making an exception that says "your NFS path looks all all weird", rather than letting the import happen, so I'll go ahead and add that upstream. --Michael > > # cobbler import --name=rhel46 --available-as=nfs://192.168.0.1:/var/www/html/kits/RHEL4/i386 --path=/var/www/html/RHEL4/i386 > ---------------- (adding distros) > - creating new distro: rhel46-i386 > - creating new profile: rhel46-i386 > - creating new distro: rhel46-xen-i386 > - creating new profile: rhel46-xen-i386 > ---------------- (associating kickstarts) > - finding default kickstart template for redhat 4 > - using default kickstart file choice > - tree: nfs://192.168.0.1:/var/www/html/kits/RHEL4/i386/ > - finding default kickstart template for redhat 4 > - using default kickstart file choice > - tree: nfs://192.168.0.1:/var/www/html/kits/RHEL4/i386/ > ---------------- (syncing) > sync distro: rhel46-i386 > sync distro: rhel46-xen-i386 > sync profile: rhel46-i386 > sync profile: rhel46-xen-i386 > Shutting down dhcpd: [ OK ] > Starting dhcpd: [ OK ] > # cobbler import --name=r64el51 --available-as=nfs://192.168.0.1:/var/www/html/kits/RHEL51/x86_64 --path=/var/www/html/RHEL51/x86_64 > ---------------- (adding distros) > - creating new distro: r64el51-x86_64 > - creating new profile: r64el51-x86_64 > - creating new distro: r64el51-xen-x86_64 > - creating new profile: r64el51-xen-x86_64 > ---------------- (associating kickstarts) > - skipping distro rhel46-i386 since it wasn't imported this time > - finding default kickstart template for redhat 5.0 > - tree: nfs://192.168.0.1:/var/www/html/kits/RHEL51/x86_64/ > - finding default kickstart template for redhat 5.0 > - tree: nfs://192.168.0.1:/var/www/html/kits/RHEL51/x86_64/ > - skipping distro rhel46-xen-i386 since it wasn't imported this time > ---------------- (syncing) > sync distro: rhel46-i386 > sync distro: r64el51-x86_64 > sync distro: r64el51-xen-x86_64 > sync distro: rhel46-xen-i386 > sync profile: rhel46-i386 > sync profile: r64el51-x86_64 > sync profile: r64el51-xen-x86_64 > sync profile: rhel46-xen-i386 > Shutting down dhcpd: [ OK ] > Starting dhcpd: [ OK ] > # cobbler import --name=rhel51 --available-as=nfs://192.168.0.1/var/www/html/kits/RHEL51/i386 --path=/var/www/html/RHEL51/i386 > ---------------- (adding distros) > - creating new distro: rhel51-i386 > - creating new profile: rhel51-i386 > - creating new distro: rhel51-xen-i386 > - creating new profile: rhel51-xen-i386 > ---------------- (associating kickstarts) > - skipping distro r64el51-x86_64 since it wasn't imported this time > - finding default kickstart template for redhat 5.0 > - tree: nfs://192.168.0.1/var/www/html/kits/RHEL51/i386/ > - skipping distro rhel46-i386 since it wasn't imported this time > - skipping distro rhel46-xen-i386 since it wasn't imported this time > - skipping distro r64el51-xen-x86_64 since it wasn't imported this time > - finding default kickstart template for redhat 5.0 > - tree: nfs://192.168.0.1/var/www/html/kits/RHEL51/i386/ > ---------------- (syncing) > sync distro: r64el51-x86_64 > sync distro: rhel51-i386 > sync distro: rhel46-i386 > sync distro: rhel46-xen-i386 > sync distro: r64el51-xen-x86_64 > sync distro: rhel51-xen-i386 > sync profile: r64el51-x86_64 > sync profile: rhel51-i386 > Traceback (most recent call last): > File "/usr/lib/python2.4/site-packages/cobbler/action_sync.py", line 372, in validate_kickstart_for_specific_profile > self.apply_template(kfile, meta, dest) > File "/usr/lib/python2.4/site-packages/cobbler/action_sync.py", line 610, in apply_template > (server, dir) = rest.split(":",2) > ValueError: need more than 1 value to unpack > Error while rendering kickstart file /etc/cobbler/kickstart_fc6.ks to /var/www/cobbler/kickstarts/rhel51-i386/ks.cfg > # > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From tom at ng23.net Mon Nov 26 21:11:17 2007 From: tom at ng23.net (Tom Brown) Date: Mon, 26 Nov 2007 21:11:17 +0000 Subject: [et-mgmt-tools] koan-0.6.3-3.el4.mrh - kix templating - network rebuilt issue In-Reply-To: <474B31C6.1040706@redhat.com> References: <474B2F75.30008@ng23.net> <474B31C6.1040706@redhat.com> Message-ID: <474B3675.9050107@ng23.net> > > Cobbler renders it's kickstart template output in > /var/www/cobbler/kickstarts and/or kickstarts_sys depending on whether > you're talking about a profile or kickstart level of evaluation. > > Look in those directories and see if the kickstarts match what you > expect them to look like. > the kickstarts in /var/www/cobbler/kickstarts// are what i would expect them to be yes - A new install or reinstall works as it should its just when using koan to rebuild to a different profile, that shows as valid in a koan -l, that causes this issue of halting waiting for manual IP configuration. thanks From mdehaan at redhat.com Mon Nov 26 21:17:40 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 26 Nov 2007 16:17:40 -0500 Subject: [et-mgmt-tools] koan-0.6.3-3.el4.mrh - kix templating - network rebuilt issue In-Reply-To: <474B3675.9050107@ng23.net> References: <474B2F75.30008@ng23.net> <474B31C6.1040706@redhat.com> <474B3675.9050107@ng23.net> Message-ID: <474B37F4.5010305@redhat.com> Tom Brown wrote: > >> >> Cobbler renders it's kickstart template output in >> /var/www/cobbler/kickstarts and/or kickstarts_sys depending on >> whether you're talking about a profile or kickstart level of evaluation. >> >> Look in those directories and see if the kickstarts match what you >> expect them to look like. >> > > the kickstarts in /var/www/cobbler/kickstarts// are what > i would expect them to be yes - A new install or reinstall works as it > should its just when using koan to rebuild to a different profile, > that shows as valid in a koan -l, that causes this issue of halting > waiting for manual IP configuration. > > thanks > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools Ah, simple then. It sounds like you've assigned your IP's and network info to system objects, and are passing a /profile/ name to koan, perhaps? This means that the profile object itself has no idea what those variables should be. Try passing in the system instead, or optionally use a DHCP kickstart for profile based deployments. (Using Cheetah games, if you like, you can detect that the ip isn't set and fall back to DHCP... though I'm not sure if you want that. I'm throwing it out there though). --Michael From tom at ng23.net Mon Nov 26 21:35:58 2007 From: tom at ng23.net (Tom Brown) Date: Mon, 26 Nov 2007 21:35:58 +0000 Subject: [et-mgmt-tools] koan-0.6.3-3.el4.mrh - kix templating - network rebuilt issue In-Reply-To: <474B37F4.5010305@redhat.com> References: <474B2F75.30008@ng23.net> <474B31C6.1040706@redhat.com> <474B3675.9050107@ng23.net> <474B37F4.5010305@redhat.com> Message-ID: <474B3C3E.9070708@ng23.net> > Ah, simple then. > > It sounds like you've assigned your IP's and network info to system > objects, and are passing a /profile/ name to koan, perhaps? > > This means that the profile object itself has no idea what those > variables should be. > > Try passing in the system instead, or optionally use a DHCP kickstart > for profile based deployments. (Using Cheetah games, if you like, > you can detect that the ip isn't set and fall back to DHCP... though > I'm not sure if you want that. I'm throwing it out there though). > to install a box i 'add a system' yes and this is given network information and all works fine. On the reinstall using koan i pass the -p so that the box gets rebuilt to a different profile, ie in my case different OS version. Is that what you suspect i'm doing and is that 'wrong' ? I am afraid i dont get what you mean regarding passing this to the system as when the box is first installed it is assigned to the system? thanks for any ideas From mdehaan at redhat.com Mon Nov 26 21:42:40 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 26 Nov 2007 16:42:40 -0500 Subject: [et-mgmt-tools] koan-0.6.3-3.el4.mrh - kix templating - network rebuilt issue In-Reply-To: <474B3C3E.9070708@ng23.net> References: <474B2F75.30008@ng23.net> <474B31C6.1040706@redhat.com> <474B3675.9050107@ng23.net> <474B37F4.5010305@redhat.com> <474B3C3E.9070708@ng23.net> Message-ID: <474B3DD0.10507@redhat.com> Tom Brown wrote: > >> Ah, simple then. >> >> It sounds like you've assigned your IP's and network info to system >> objects, and are passing a /profile/ name to koan, perhaps? >> >> This means that the profile object itself has no idea what those >> variables should be. >> >> Try passing in the system instead, or optionally use a DHCP kickstart >> for profile based deployments. (Using Cheetah games, if you like, >> you can detect that the ip isn't set and fall back to DHCP... though >> I'm not sure if you want that. I'm throwing it out there though). >> > > to install a box i 'add a system' yes and this is given network > information and all works fine. On the reinstall using koan i pass the > -p so that the box gets rebuilt to a different profile, > ie in my case different OS version. Is that what you suspect i'm doing > and is that 'wrong' ? > Yes, it's wrong because your kickstart is missing IP and MAC information that is present when it's used on a per-system basis ... if you look in /var/www/cobbler/kickstarts I suspect you'll see there are still variables in the kickstart files. If you compare that with the files in /var/www/cobbler/kickstart_sys, you'll see that the variables that correspond to the system object are filled in. # koan --replace-self --system=name_goes_here will make you use the system-specific kickstart, as opposed to the profile specific-kickstart. --Michael From mdehaan at redhat.com Mon Nov 26 21:46:30 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 26 Nov 2007 16:46:30 -0500 Subject: [et-mgmt-tools] koan-0.6.3-3.el4.mrh - kix templating - network rebuilt issue In-Reply-To: <474B3DD0.10507@redhat.com> References: <474B2F75.30008@ng23.net> <474B31C6.1040706@redhat.com> <474B3675.9050107@ng23.net> <474B37F4.5010305@redhat.com> <474B3C3E.9070708@ng23.net> <474B3DD0.10507@redhat.com> Message-ID: <474B3EB6.8030804@redhat.com> Michael DeHaan wrote: > Tom Brown wrote: >> >>> Ah, simple then. >>> >>> It sounds like you've assigned your IP's and network info to system >>> objects, and are passing a /profile/ name to koan, perhaps? >>> >>> This means that the profile object itself has no idea what those >>> variables should be. >>> >>> Try passing in the system instead, or optionally use a DHCP >>> kickstart for profile based deployments. (Using Cheetah games, if >>> you like, you can detect that the ip isn't set and fall back to >>> DHCP... though >>> I'm not sure if you want that. I'm throwing it out there though). >>> >> >> to install a box i 'add a system' yes and this is given network >> information and all works fine. On the reinstall using koan i pass >> the -p so that the box gets rebuilt to a different >> profile, ie in my case different OS version. Is that what you suspect >> i'm doing and is that 'wrong' ? >> > > Yes, it's wrong because your kickstart is missing IP and MAC > information that is present when it's used on a per-system basis ... > if you look in /var/www/cobbler/kickstarts I suspect you'll see there > are still variables > in the kickstart files. If you compare that with the files in > /var/www/cobbler/kickstart_sys, you'll see that the variables that > correspond to the system object are filled in. > > # koan --replace-self --system=name_goes_here > > will make you use the system-specific kickstart, as opposed to the > profile specific-kickstart. > --Michael > > > > > This may be more useful ... The following command syntax will autodetect the system based on the MAC addresses it finds. (So you don't have to specify --system at all, just leave off the profile). # koan --server=bootserver.example.org --replace-self Just run the corresponding cobbler command first to remap the system entry to the appropriate profile, like so: # cobbler system edit --name=name_goes_here --profile=new_profile_name_goes_here --Michael From mdehaan at redhat.com Mon Nov 26 21:51:18 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 26 Nov 2007 16:51:18 -0500 Subject: [et-mgmt-tools] Thoughts on Cobbler authorization/authentication and access levels in your organization? In-Reply-To: <20071126205712.GH8398@anduril.unity.ncsu.edu> References: <474B0AFC.6070904@redhat.com> <20071126205712.GH8398@anduril.unity.ncsu.edu> Message-ID: <474B3FD6.8090000@redhat.com> Jack Neely wrote: > Michael, > > Here at NCSU I have an existing provisioning system that generates > kickstarts based on a set of "keyword [value [value...]]" rules. We'd > like to continue to use that as it works well for us...and it integrates > with Cobbler well. > > So given that, admins already have the ability to control/alter their > profiles in a defined way that scales well and lonely me can support. > > What I'd like from Cobbler is the ability for a select few admins (like > me) to be able to setup all the bits to make Cobbler distros/profiles > etc. work. > > Normal admins should be able to associate a MAC address with a profile > and remove said MAC. Actually, it would be great if an admin could > associate a hostname/IP address with a profile and Cobbler would run a > plugin to translate that into a MAC. > One of the things I thought about doing was creating a simpler page to just edit a systems mapping. Login would work as before, but the page could be as simple as what you mentioned above, a dropbox, and an ok button. CLI equivalents should work too... > Groups of admins as well. Any admin can modify MAC->profile of any > other admin provided both are in the same group. > > Authentication via kerberos (PAM probably) authorization done by auto > generated groups of admins (a plugin)? > Sounds reasonable. > Okay...some half-baked ideas about how I see a workflow here. If you > have questions please feel free. > Thanks! I've got some good feedback so far, so I'll try to summarize findings/plans shortly. If anyone else wants to share their thoughts on how they'd ideally like their site to work, please do. > Jack Neely > From tom at ng23.net Mon Nov 26 22:05:58 2007 From: tom at ng23.net (Tom Brown) Date: Mon, 26 Nov 2007 22:05:58 +0000 Subject: [et-mgmt-tools] koan-0.6.3-3.el4.mrh - kix templating - network rebuilt issue In-Reply-To: <474B3DD0.10507@redhat.com> References: <474B2F75.30008@ng23.net> <474B31C6.1040706@redhat.com> <474B3675.9050107@ng23.net> <474B37F4.5010305@redhat.com> <474B3C3E.9070708@ng23.net> <474B3DD0.10507@redhat.com> Message-ID: <474B4346.7020506@ng23.net> > > Yes, it's wrong because your kickstart is missing IP and MAC > information that is present when it's used on a per-system basis ... > if you look in /var/www/cobbler/kickstarts I suspect you'll see there > are still variables > in the kickstart files. If you compare that with the files in > /var/www/cobbler/kickstart_sys, you'll see that the variables that > correspond to the system object are filled in. > > # koan --replace-self --system=name_goes_here > > will make you use the system-specific kickstart, as opposed to the > profile specific-kickstart. ah ok yes - /var/www/cobbler/kickstart still has the variables but /var/www/cobbler/kickstart_sys has system specific kickstarts in there. I have tried a # koan -r -p CentOS-4.4-i386 -y box-2 -s 192.168.10.4 as CentOS-4.4-i386 is the new profile i want to build and box-2 is the name of the machine i want to rebuild. I was rathing expecting that to work but alas no. I have to manage 4000+ boxes so i need to be able to rebuild them to a different profile as easy as possible and koan would be perfect. From mdehaan at redhat.com Mon Nov 26 22:09:05 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 26 Nov 2007 17:09:05 -0500 Subject: [et-mgmt-tools] koan-0.6.3-3.el4.mrh - kix templating - network rebuilt issue In-Reply-To: <474B4346.7020506@ng23.net> References: <474B2F75.30008@ng23.net> <474B31C6.1040706@redhat.com> <474B3675.9050107@ng23.net> <474B37F4.5010305@redhat.com> <474B3C3E.9070708@ng23.net> <474B3DD0.10507@redhat.com> <474B4346.7020506@ng23.net> Message-ID: <474B4401.2030302@redhat.com> > > I have to manage 4000+ boxes so i need to be able to rebuild them to a > different profile as easy as possible and koan would be perfect. > Good deal. I'd suggest writing a minimal script that calls the cobbler edit command locally, and then runs koan on the remote system as: koan --replace-self --server=bootserver.example.org (no arguments) then reboots the box. --Michael From tom at ng23.net Mon Nov 26 22:34:00 2007 From: tom at ng23.net (Tom Brown) Date: Mon, 26 Nov 2007 22:34:00 +0000 Subject: [et-mgmt-tools] koan-0.6.3-3.el4.mrh - kix templating - network rebuilt issue In-Reply-To: <474B4401.2030302@redhat.com> References: <474B2F75.30008@ng23.net> <474B31C6.1040706@redhat.com> <474B3675.9050107@ng23.net> <474B37F4.5010305@redhat.com> <474B3C3E.9070708@ng23.net> <474B3DD0.10507@redhat.com> <474B4346.7020506@ng23.net> <474B4401.2030302@redhat.com> Message-ID: <474B49D8.1000208@ng23.net> > Good deal. > > I'd suggest writing a minimal script that calls the cobbler edit > command locally, and then runs koan on the remote system as: > > koan --replace-self --server=bootserver.example.org (no arguments) > > then reboots the box. would there be any chance the functionality of using the contents of kickstart_sys for rebuilding using koan rather than kickstart? Alas things are not as simple as scripting a cobbler edit as once deployed into the stack, these machines are basically application stacks, then when and what they get rebuilt to is handled by another process that is local to a box on the stack and so only has access to koan. It seems to me that koan/cobbler has the info available to it, ie kickstart_sys, however it seems to not make use of it? thanks From mdehaan at redhat.com Mon Nov 26 22:46:42 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 26 Nov 2007 17:46:42 -0500 Subject: [et-mgmt-tools] koan-0.6.3-3.el4.mrh - kix templating - network rebuilt issue In-Reply-To: <474B49D8.1000208@ng23.net> References: <474B2F75.30008@ng23.net> <474B31C6.1040706@redhat.com> <474B3675.9050107@ng23.net> <474B37F4.5010305@redhat.com> <474B3C3E.9070708@ng23.net> <474B3DD0.10507@redhat.com> <474B4346.7020506@ng23.net> <474B4401.2030302@redhat.com> <474B49D8.1000208@ng23.net> Message-ID: <474B4CD2.8020804@redhat.com> Tom Brown wrote: > >> Good deal. >> >> I'd suggest writing a minimal script that calls the cobbler edit >> command locally, and then runs koan on the remote system as: >> >> koan --replace-self --server=bootserver.example.org (no arguments) >> >> then reboots the box. > > would there be any chance the functionality of using the contents of > kickstart_sys for rebuilding using koan rather than kickstart? koan is designed to deploy what is specified in Cobbler. It's designed around centralized management. > Alas things are not as simple as scripting a cobbler edit as once > deployed into the stack, these machines are basically application > stacks, then when and what they get rebuilt to is handled by another > process that is local to a box on the stack and so only has access to > koan. It seems to me that koan/cobbler has the info available to it, > ie kickstart_sys, however it seems to not make use of it? > That doesn't work because the kickstart_sys file without doing the associated cobbler edit points to the /old/ cobbler profile, not the new one. Once you issue the cobbler command to remap it, the kickstart is then correct, and you can use koan with the --system flag (or leave it off and let things be autodetected). Really the easiest option here is to just use the profiles with DHCP. Failing that, you should just issue the cobbler commands to remap systems to new profiles. We're not going to do client-side templating of kickstart files in koan because we already do that Cobbler side, and also because to support older distros (EL3), we can't use the same templating engine... which adds way too much complexity, and it is also hard to explain why we'd actually need that feature if we already have a cobbler command that does the same thing :) In conclusion ... (A) use profiles with DHCP, or (B) run cobbler edit command before using koan. Those are the two suggestions. > thanks > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From tom at ng23.net Mon Nov 26 22:57:09 2007 From: tom at ng23.net (Tom Brown) Date: Mon, 26 Nov 2007 22:57:09 +0000 Subject: [et-mgmt-tools] koan-0.6.3-3.el4.mrh - kix templating - network rebuilt issue In-Reply-To: <474B4CD2.8020804@redhat.com> References: <474B2F75.30008@ng23.net> <474B31C6.1040706@redhat.com> <474B3675.9050107@ng23.net> <474B37F4.5010305@redhat.com> <474B3C3E.9070708@ng23.net> <474B3DD0.10507@redhat.com> <474B4346.7020506@ng23.net> <474B4401.2030302@redhat.com> <474B49D8.1000208@ng23.net> <474B4CD2.8020804@redhat.com> Message-ID: <474B4F45.9030005@ng23.net> > > koan is designed to deploy what is specified in Cobbler. It's > designed around centralized management. fair enough - can i ask then what is the intended purpose of "--profile=PROFILE cobbler profile to install" as that would do exactly as i want but as you state it does not handle the IP issues i have > >> Alas things are not as simple as scripting a cobbler edit as once >> deployed into the stack, these machines are basically application >> stacks, then when and what they get rebuilt to is handled by another >> process that is local to a box on the stack and so only has access to >> koan. It seems to me that koan/cobbler has the info available to it, >> ie kickstart_sys, however it seems to not make use of it? >> > That doesn't work because the kickstart_sys file without doing the > associated cobbler edit points to the /old/ cobbler profile, not the > new one. Once you issue the cobbler command to remap it, the kickstart > is then correct, and you can use koan with the --system flag (or leave > it off and let things be autodetected). > > Really the easiest option here is to just use the profiles with > DHCP. Failing that, you should just issue the cobbler commands to > remap systems to new profiles. > for me dhcp in production is not really an option. i can get away with it for bare metal but alas not for rebuilds > We're not going to do client-side templating of kickstart files in > koan because we already do that Cobbler side, and also because to > support older distros (EL3), we can't use the same templating > engine... which > adds way too much complexity, and it is also hard to explain why we'd > actually need that feature if we already have a cobbler command that > does the same thing :) > > In conclusion ... (A) use profiles with DHCP, or (B) run cobbler edit > command before using koan. Those are the two suggestions. thanks for your advice regarding this issue - i'll see what i can come up with. From lippold at gmail.com Tue Nov 27 07:49:12 2007 From: lippold at gmail.com (Aaron Lippold) Date: Tue, 27 Nov 2007 02:49:12 -0500 Subject: [et-mgmt-tools] Thoughts on Cobbler authorization/authentication and access levels in your organization? In-Reply-To: <474B3FD6.8090000@redhat.com> References: <474B0AFC.6070904@redhat.com> <20071126205712.GH8398@anduril.unity.ncsu.edu> <474B3FD6.8090000@redhat.com> Message-ID: <39d2723b0711262349pe5797e2nab9ba9e30404550b@mail.gmail.com> Hi, One of the features that would be good would be the abllity to intagrate with NSS. Fedora / RedHat Directory server etc. I think looking at mod_nss and the already existing pam, pam_pkcs11 etc would really expand overall enterprise usage, at least for my use. I think that usage of PAM, NSS, kerberos would provide a good baseline for the largest set of use cases. Just my thoughts. Yours, Aaron On Nov 26, 2007 4:51 PM, Michael DeHaan wrote: > Jack Neely wrote: > > Michael, > > > > Here at NCSU I have an existing provisioning system that generates > > kickstarts based on a set of "keyword [value [value...]]" rules. We'd > > like to continue to use that as it works well for us...and it integrates > > with Cobbler well. > > > > So given that, admins already have the ability to control/alter their > > profiles in a defined way that scales well and lonely me can support. > > > > What I'd like from Cobbler is the ability for a select few admins (like > > me) to be able to setup all the bits to make Cobbler distros/profiles > > etc. work. > > > > Normal admins should be able to associate a MAC address with a profile > > and remove said MAC. Actually, it would be great if an admin could > > associate a hostname/IP address with a profile and Cobbler would run a > > plugin to translate that into a MAC. > > > > One of the things I thought about doing was creating a simpler page to > just edit a systems mapping. > > Login would work as before, but the page could be as simple as what you > mentioned above, a dropbox, > and an ok button. CLI equivalents should work too... > > Groups of admins as well. Any admin can modify MAC->profile of any > > other admin provided both are in the same group. > > > > Authentication via kerberos (PAM probably) authorization done by auto > > generated groups of admins (a plugin)? > > > Sounds reasonable. > > Okay...some half-baked ideas about how I see a workflow here. If you > > have questions please feel free. > > > > Thanks! I've got some good feedback so far, so I'll try to summarize > findings/plans shortly. > If anyone else wants to share their thoughts on how they'd ideally like > their site to work, please do. > > Jack Neely > > > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From tom at ng23.net Tue Nov 27 14:19:58 2007 From: tom at ng23.net (Tom Brown) Date: Tue, 27 Nov 2007 14:19:58 +0000 Subject: [et-mgmt-tools] network configuration - Cobbler add versus ksmeta Message-ID: <474C278E.5090408@ng23.net> Hi - i am experimenting on how to pass network configuration to cobbler - i do it either by adding most information directly to the cobbler add command or passing it within the --ksmeta. Below are 2 examples, the first is populated with information mainly from within ksmeta, only the name, mac and profile to use is passed to cobbler add the rest is within ksmeta. This installs fine. The second example is where only the nameserver info is passed using ksmeta everything else comes from the cobbler add directly. The issue is the second example boots, gets an IP but then fails trying to retrieve the netstg2.img. Anyone got any thoughts as to why this may be ? thanks this works depth: 2 interfaces: intf0: dhcp_tag: '' gateway: '' hostname: '' ip_address: '' mac_address: '00:0C:29:71:D7:4D' subnet: '' virt_bridge: '' kernel_options: {} kickstart: <> ks_meta: gateway: '192.168.10.1' hostname: box-2 ip_address: '192.168.10.20' nameserver: '192.168.10.4' netmask: '255.255.255.0' name: box-2 netboot_enabled: True parent: '' profile: CentOS-4.5-i386 server: <> virt_path: <> virt_type: <> but this does not work depth: 2 interfaces: intf0: dhcp_tag: '' gateway: '192.168.10.1' hostname: box-2 ip_address: '192.168.10.20' mac_address: '00:0C:29:71:D7:4D' subnet: '255.255.255.0' virt_bridge: '' kernel_options: {} kickstart: <> ks_meta: nameserver: '192.168.10.4' name: box-2 netboot_enabled: True parent: '' profile: CentOS-4.5-i386 server: <> virt_path: <> virt_type: <> From mdehaan at redhat.com Tue Nov 27 15:39:58 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 27 Nov 2007 10:39:58 -0500 Subject: [et-mgmt-tools] network configuration - Cobbler add versus ksmeta In-Reply-To: <474C278E.5090408@ng23.net> References: <474C278E.5090408@ng23.net> Message-ID: <474C3A4E.4090401@redhat.com> Tom Brown wrote: > > Hi - i am experimenting on how to pass network configuration to > cobbler - i do it either by adding most information directly to the > cobbler add command or passing it within the --ksmeta. Below are 2 > examples, the first is populated with information mainly from within > ksmeta, only the name, mac and profile to use is passed to cobbler add > the rest is within ksmeta. This installs fine. The second example is > where only the nameserver info is passed using ksmeta everything else > comes from the cobbler add directly. The issue is the second example > boots, gets an IP but then fails trying to retrieve the netstg2.img. > You should just use the variables that are part of the interface since they are already made available for that purpose. As for why that is not working for you, a good place to start looking is at /var/www/cobbler/profiles/$name and /var/www/cobbler/systems/$name for a file that shows you all the variables expanded, just like they would be available in your templates. Then make sure you are using those same variables in your templates. Also look at the rendered kickstarts in /var/www/cobbler/kickstarts/$name and /var/www/cobbler/kickstarts_sys/$name and compare those to the templates you are using. Make sure that they look like you want in both cases. By looking at what variables you have available to use, and seeing how the kickstarts are actually rendered, it will become much more clear what is going on. You shouldn't have to do an install to debug the kickstart. Try "cobbler validateks" first, which will do a quick scan of your rendered kickstarts to see if they have the right syntax. After that, look at them manually and compare the two, to understand what cobbler is generating from the templates. --Michael From crobinso at redhat.com Tue Nov 27 16:37:29 2007 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 27 Nov 2007 11:37:29 -0500 Subject: [et-mgmt-tools] [PATCH] virt-manager reorg common commands, add error reporting In-Reply-To: <474478C4.3080102@redhat.com> References: <474478C4.3080102@redhat.com> Message-ID: <474C47C9.2070603@redhat.com> Cole Robinson wrote: > The attached patch is the result of trying to add error reporting > to some common tasks in virt-manager: pause, unpause, shutdown, and run, > as well as save and destroy. > I just committed this: http://hg.et.redhat.com/virt/applications/virt-manager--devel?cs=a52007787308 - Cole -- Cole Robinson crobinso at redhat.com From tom at ng23.net Tue Nov 27 16:52:22 2007 From: tom at ng23.net (Tom Brown) Date: Tue, 27 Nov 2007 16:52:22 +0000 Subject: [et-mgmt-tools] network configuration - Cobbler add versus ksmeta In-Reply-To: <474C3A4E.4090401@redhat.com> References: <474C278E.5090408@ng23.net> <474C3A4E.4090401@redhat.com> Message-ID: <474C4B46.4030706@ng23.net> > You should just use the variables that are part of the interface since > they are already made available for that purpose. > As for why that is not working for you, a good place to start looking > is at /var/www/cobbler/profiles/$name and > /var/www/cobbler/systems/$name for a file that shows you all the > variables expanded, just like they would be available in your templates. > > Then make sure you are using those same variables in your templates. > > Also look at the rendered kickstarts in > /var/www/cobbler/kickstarts/$name and > /var/www/cobbler/kickstarts_sys/$name and compare those to the > templates you are using. > > Make sure that they look like you want in both cases. > > By looking at what variables you have available to use, and seeing how > the kickstarts are actually rendered, it will become much more clear > what is going on. > > You shouldn't have to do an install to debug the kickstart. > > Try "cobbler validateks" first, which will do a quick scan of your > rendered kickstarts to see if they have the right syntax. > > After that, look at them manually and compare the two, to understand > what cobbler is generating from the templates. thanks - below is what the rendered kix looks like for that system from the /var/www/cobbler/systems/ to me that looks correct as in the template the variables used are network --bootproto=static --device=eth0 --onboot=on --ip=$ip_address --netmask=$netmask --gateway=$gateway --nameserver=$nameserver --hostname=$hostname and the rendered kix looks like the below - is there anything else i can check ? arch: x86 bootloaders: ia64: /var/lib/cobbler/elilo-3.6-ia64.efi standard: /usr/lib/syslinux/pxelinux.0 breed: redhat default_kickstart: /etc/cobbler/default.ks default_virt_bridge: xenbr0 default_virt_type: auto depth: 2 dhcp_tag: default dhcp_tag_intf0: '' dhcpd_bin: /usr/sbin/dhcpd dhcpd_conf: /etc/dhcpd.conf distro: CentOS-4.5-i386 dnsmasq_bin: /usr/sbin/dnsmasq dnsmasq_conf: /etc/dnsmasq.conf gateway: '192.168.10.1' gateway_intf0: '192.168.10.1' hostname: box-2 hostname_intf0: box-2 httpd_bin: /usr/sbin/httpd initrd: /var/www/cobbler/ks_mirror/CentOS-4.5-i386/images/pxeboot/initrd.img interfaces: intf0: dhcp_tag: '' gateway: '192.168.10.1' hostname: box-2 ip_address: '192.168.10.20' mac_address: '00:0C:29:71:D7:4D' subnet: '255.255.255.0' virt_bridge: '' ip_address: '192.168.10.20' ip_address_intf0: '192.168.10.20' kernel: /var/www/cobbler/ks_mirror/CentOS-4.5-i386/images/pxeboot/vmlinuz kernel_options: 'ksdevice=eth0 lang= kssendmac syslog=192.168.10.4:25150 text ' kickstart: /etc/cobbler/kickstart_CentOS-4.5-i386.ks ks_meta: 'nameserver=192.168.10.4 tree=http://@@server@@/cblr/links/CentOS-4.5-i386 ' mac_address: '00:0C:29:71:D7:4D' mac_address_intf0: '00:0C:29:71:D7:4D' manage_dhcp: 1 manage_dhcp_mode: isc name: box-2 netboot_enabled: True next_server: '192.168.10.4' parent: '' profile: CentOS-4.5-i386 pxe_just_once: 0 repos: '' server: '192.168.10.4' snippetsdir: /var/lib/cobbler/snippets source_repos: - - 'http://192.168.10.4/cobbler/ks_mirror/config/CentOS-4.5-i386-0.repo' - 'http://192.168.10.4/cobbler/ks_mirror/CentOS-4.5-i386/CentOS' subnet: '255.255.255.0' subnet_intf0: '255.255.255.0' syslog_port: 25150 tftpboot: /tftpboot tftpd_bin: /usr/sbin/in.tftpd tftpd_conf: /etc/xinetd.d/tftp virt_bridge: xenbr0 virt_bridge_intf0: '' virt_cpus: 1 virt_file_size: 5 virt_path: '' virt_ram: 512 virt_type: auto webdir: /var/www/cobbler xmlrpc_port: 25151 xmlrpc_rw_enabled: 1 xmlrpc_rw_port: 25152 yum_post_install_mirror: 0 yumdownloader_flags: -resolve From mdehaan at redhat.com Tue Nov 27 17:00:10 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 27 Nov 2007 12:00:10 -0500 Subject: [et-mgmt-tools] network configuration - Cobbler add versus ksmeta In-Reply-To: <474C4B46.4030706@ng23.net> References: <474C278E.5090408@ng23.net> <474C3A4E.4090401@redhat.com> <474C4B46.4030706@ng23.net> Message-ID: <474C4D1A.3000809@redhat.com> Tom Brown wrote: > >> You should just use the variables that are part of the interface >> since they are already made available for that purpose. As for why >> that is not working for you, a good place to start looking is at >> /var/www/cobbler/profiles/$name and /var/www/cobbler/systems/$name >> for a file that shows you all the variables expanded, just like they >> would be available in your templates. >> >> Then make sure you are using those same variables in your templates. >> >> Also look at the rendered kickstarts in >> /var/www/cobbler/kickstarts/$name and >> /var/www/cobbler/kickstarts_sys/$name and compare those to the >> templates you are using. >> >> Make sure that they look like you want in both cases. >> >> By looking at what variables you have available to use, and seeing >> how the kickstarts are actually rendered, it will become much more >> clear what is going on. >> >> You shouldn't have to do an install to debug the kickstart. >> >> Try "cobbler validateks" first, which will do a quick scan of your >> rendered kickstarts to see if they have the right syntax. >> >> After that, look at them manually and compare the two, to understand >> what cobbler is generating from the templates. > > > thanks - below is what the rendered kix looks like for that system > from the /var/www/cobbler/systems/ I'm not seeing it in the email or attached. > > to me that looks correct as in the template the variables used are > > network --bootproto=static --device=eth0 --onboot=on --ip=$ip_address > --netmask=$netmask --gateway=$gateway --nameserver=$nameserver > --hostname=$hostname > > and the rendered kix looks like the below - is there anything else i > can check ? Same here. If a rendered kickstart looks normal to you then it's just a kickstart problem (outside of Cobbler), where you could possibly ask kickstart-list at redhat.com From tom at ng23.net Tue Nov 27 17:06:53 2007 From: tom at ng23.net (Tom Brown) Date: Tue, 27 Nov 2007 17:06:53 +0000 Subject: [et-mgmt-tools] network configuration - Cobbler add versus ksmeta In-Reply-To: <474C4D1A.3000809@redhat.com> References: <474C278E.5090408@ng23.net> <474C3A4E.4090401@redhat.com> <474C4B46.4030706@ng23.net> <474C4D1A.3000809@redhat.com> Message-ID: <474C4EAD.5060608@ng23.net> > > I'm not seeing it in the email or attached. does the below look syntactically correct? # cat /var/www/cobbler/systems/box-2 --- arch: x86 bootloaders: ia64: /var/lib/cobbler/elilo-3.6-ia64.efi standard: /usr/lib/syslinux/pxelinux.0 breed: redhat default_kickstart: /etc/cobbler/default.ks default_virt_bridge: xenbr0 default_virt_type: auto depth: 2 dhcp_tag: default dhcp_tag_intf0: '' dhcpd_bin: /usr/sbin/dhcpd dhcpd_conf: /etc/dhcpd.conf distro: CentOS-4.5-i386 dnsmasq_bin: /usr/sbin/dnsmasq dnsmasq_conf: /etc/dnsmasq.conf gateway: '192.168.10.1' gateway_intf0: '192.168.10.1' hostname: box-2 hostname_intf0: box-2 httpd_bin: /usr/sbin/httpd initrd: /var/www/cobbler/ks_mirror/CentOS-4.5-i386/images/pxeboot/initrd.img interfaces: intf0: dhcp_tag: '' gateway: '192.168.10.1' hostname: box-2 ip_address: '192.168.10.20' mac_address: '00:0C:29:71:D7:4D' subnet: '255.255.255.0' virt_bridge: '' ip_address: '192.168.10.20' ip_address_intf0: '192.168.10.20' kernel: /var/www/cobbler/ks_mirror/CentOS-4.5-i386/images/pxeboot/vmlinuz kernel_options: 'ksdevice=eth0 lang= kssendmac syslog=192.168.10.4:25150 text ' kickstart: /etc/cobbler/kickstart_CentOS-4.5-i386.ks ks_meta: 'nameserver=192.168.10.4 tree=http://@@server@@/cblr/links/CentOS-4.5-i386 ' mac_address: '00:0C:29:71:D7:4D' mac_address_intf0: '00:0C:29:71:D7:4D' manage_dhcp: 1 manage_dhcp_mode: isc name: box-2 netboot_enabled: True next_server: '192.168.10.4' parent: '' profile: CentOS-4.5-i386 pxe_just_once: 0 repos: '' server: '192.168.10.4' snippetsdir: /var/lib/cobbler/snippets source_repos: - - 'http://192.168.10.4/cobbler/ks_mirror/config/CentOS-4.5-i386-0.repo' - 'http://192.168.10.4/cobbler/ks_mirror/CentOS-4.5-i386/CentOS' subnet: '255.255.255.0' subnet_intf0: '255.255.255.0' syslog_port: 25150 tftpboot: /tftpboot tftpd_bin: /usr/sbin/in.tftpd tftpd_conf: /etc/xinetd.d/tftp virt_bridge: xenbr0 virt_bridge_intf0: '' virt_cpus: 1 virt_file_size: 5 virt_path: '' virt_ram: 512 virt_type: auto webdir: /var/www/cobbler xmlrpc_port: 25151 xmlrpc_rw_enabled: 1 xmlrpc_rw_port: 25152 yum_post_install_mirror: 0 yumdownloader_flags: -resolve From mdehaan at redhat.com Tue Nov 27 17:27:35 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 27 Nov 2007 12:27:35 -0500 Subject: [et-mgmt-tools] network configuration - Cobbler add versus ksmeta In-Reply-To: <474C4EAD.5060608@ng23.net> References: <474C278E.5090408@ng23.net> <474C3A4E.4090401@redhat.com> <474C4B46.4030706@ng23.net> <474C4D1A.3000809@redhat.com> <474C4EAD.5060608@ng23.net> Message-ID: <474C5387.3040209@redhat.com> Tom Brown wrote: > >> >> I'm not seeing it in the email or attached. > does the below look syntactically correct? That's not a kickstart file, which is what I wanted to look at... From tom at ng23.net Tue Nov 27 17:34:42 2007 From: tom at ng23.net (Tom Brown) Date: Tue, 27 Nov 2007 17:34:42 +0000 Subject: [et-mgmt-tools] network configuration - Cobbler add versus ksmeta In-Reply-To: <474C5387.3040209@redhat.com> References: <474C278E.5090408@ng23.net> <474C3A4E.4090401@redhat.com> <474C4B46.4030706@ng23.net> <474C4D1A.3000809@redhat.com> <474C4EAD.5060608@ng23.net> <474C5387.3040209@redhat.com> Message-ID: <474C5532.7090002@ng23.net> > > That's not a kickstart file, which is what I wanted to look at... > apologies - # cat /var/www/cobbler/kickstarts/CentOS-4.5-i386/ks.cfg #platform=x86, AMD64, or Intel EM64T # System authorization information auth --useshadow --enablemd5 # System bootloader configuration bootloader --location=mbr # Partition clearing information clearpart --all --initlabel part /boot --fstype "ext3" --size=100 part swap --size=500 part / --fstype "ext3" --size=1 --grow # Use text mode install text # Firewall configuration firewall --disabled # Run the Setup Agent on first boot firstboot --disable # System keyboard keyboard uk # System language lang en_US.UTF-8 langsupport --default=en_US.UTF-8 en_US.UTF-8 # Use network installation url --url=http://192.168.10.4/cblr/links/CentOS-4.5-i386 # Network information network --bootproto=static --device=eth0 --onboot=on --ip=$ip_address --netmask=$netmask --gateway=$gateway --nameserver=$nameserver --hostname=$hostname # Reboot after installation reboot #Root password rootpw --iscrypted $1$x/U4oYmQ$wJe6pZ4DwD9SEDnh6DHks/ # SELinux configuration selinux --disabled # Do not configure the X Window System skipx # System timezone timezone GMT # Install OS instead of upgrade install # Clear the Master Boot Record zerombr %packages %post From mdehaan at redhat.com Tue Nov 27 17:55:06 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 27 Nov 2007 12:55:06 -0500 Subject: [et-mgmt-tools] network configuration - Cobbler add versus ksmeta In-Reply-To: <474C5532.7090002@ng23.net> References: <474C278E.5090408@ng23.net> <474C3A4E.4090401@redhat.com> <474C4B46.4030706@ng23.net> <474C4D1A.3000809@redhat.com> <474C4EAD.5060608@ng23.net> <474C5387.3040209@redhat.com> <474C5532.7090002@ng23.net> Message-ID: <474C59FA.8000302@redhat.com> Tom Brown wrote: > >> >> That's not a kickstart file, which is what I wanted to look at... >> > > apologies - > > # cat /var/www/cobbler/kickstarts/CentOS-4.5-i386/ks.cfg I just did the following and $nameserver evaluated fine in /var/www/cobbler/kickstarts_sys/X/ks.cfg cobbler system edit --name=X --ksmeta="nameserver=foo.example.org" cat /var/www/cobbler/kickstarts_sys/X.ks.cfg | grep foo.example.org Obviously it won't be evaluated in the profile kickstart because that data was tacked on to the system, not the profile... From mdehaan at redhat.com Tue Nov 27 19:28:19 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 27 Nov 2007 14:28:19 -0500 Subject: [et-mgmt-tools] network configuration - Cobbler add versus ksmeta In-Reply-To: <474C59FA.8000302@redhat.com> References: <474C278E.5090408@ng23.net> <474C3A4E.4090401@redhat.com> <474C4B46.4030706@ng23.net> <474C4D1A.3000809@redhat.com> <474C4EAD.5060608@ng23.net> <474C5387.3040209@redhat.com> <474C5532.7090002@ng23.net> <474C59FA.8000302@redhat.com> Message-ID: <474C6FD3.6030006@redhat.com> Michael DeHaan wrote: > Tom Brown wrote: >> We figured this out on IRC. The issue was that the kickstart template was using $subnet, not $netmask. So, not that complicated. Yipeee! --Michael From tom at ng23.net Tue Nov 27 19:30:38 2007 From: tom at ng23.net (Tom Brown) Date: Tue, 27 Nov 2007 19:30:38 +0000 Subject: [et-mgmt-tools] network configuration - Cobbler add versus ksmeta In-Reply-To: <474C59FA.8000302@redhat.com> References: <474C278E.5090408@ng23.net> <474C3A4E.4090401@redhat.com> <474C4B46.4030706@ng23.net> <474C4D1A.3000809@redhat.com> <474C4EAD.5060608@ng23.net> <474C5387.3040209@redhat.com> <474C5532.7090002@ng23.net> <474C59FA.8000302@redhat.com> Message-ID: <474C705E.1050600@ng23.net> > > I just did the following and $nameserver evaluated fine in > /var/www/cobbler/kickstarts_sys/X/ks.cfg > > cobbler system edit --name=X --ksmeta="nameserver=foo.example.org" > > cat /var/www/cobbler/kickstarts_sys/X.ks.cfg | grep foo.example.org > > Obviously it won't be evaluated in the profile kickstart because that > data was tacked on to the system, not the profile... > for the record the issue here was that my network snippet looked like network --bootproto=static --device=eth0 --onboot=on --ip=$ip_address --netmask=$netmask --gateway=$gateway --nameserver=$nameserver --hostname=$hostname and it should have been network --bootproto=static --device=eth0 --onboot=on --ip=$ip_address --netmask=$subnet --gateway=$gateway --nameserver=$nameserver --hostname=$hostname thanks From crobinso at redhat.com Tue Nov 27 20:29:44 2007 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 27 Nov 2007 15:29:44 -0500 Subject: [et-mgmt-tools] Virt-Manager: Supporting additional para-virtual OS's In-Reply-To: <47467C12.7020602@the-nelsons.org> References: <473BFA57.7070601@the-nelsons.org> <20071115141911.GF17977@redhat.com> <473CA2BD.5020604@the-nelsons.org> <20071116110215.GB3283@redhat.com> <47467C12.7020602@the-nelsons.org> Message-ID: <474C7E38.8070504@redhat.com> Robert Nelson wrote: > I spent some time reworking the virtinst code to support OpenSolaris and > make it much easier to support additional OSes. I've attached the patch > file to get some feedback on the work so far. > > Unfortunately a bunch for the code from virtinst is duplicated in > virt-manager in the Add Device code. This means either moving it back > to virtinst with the appropriate additional APIs or duplicating work in > virt-manager. > > > Hi Robert, Could you take a couple paragraphs explaining exactly how you reorganized everything? And also I think posting the patch to its own thread will get it more attention. One small thing before you repost: __init__.py had ::LOCALEDIR:: replaced with /usr/share/locale. This shouldn't be hardcoded and is filled in as appropriate at build time by setup.py. Thanks, Cole -- Cole Robinson crobinso at redhat.com From lippold at gmail.com Tue Nov 27 22:41:56 2007 From: lippold at gmail.com (Aaron Lippold) Date: Tue, 27 Nov 2007 17:41:56 -0500 Subject: [et-mgmt-tools] Thoughts on Cobbler authorization/authentication and access levels in your organization? In-Reply-To: <39d2723b0711262349pe5797e2nab9ba9e30404550b@mail.gmail.com> References: <474B0AFC.6070904@redhat.com> <20071126205712.GH8398@anduril.unity.ncsu.edu> <474B3FD6.8090000@redhat.com> <39d2723b0711262349pe5797e2nab9ba9e30404550b@mail.gmail.com> Message-ID: <39d2723b0711271441m13a413f7gd8414ae21cdca2a1@mail.gmail.com> Hi, Could http://www.freeipa.org/ offer up any quick wins? Yours, Aaron On Nov 27, 2007 2:49 AM, Aaron Lippold wrote: > Hi, > > One of the features that would be good would be the abllity to > intagrate with NSS. Fedora / RedHat Directory server etc. I think > looking at mod_nss and the already existing pam, pam_pkcs11 etc would > really expand overall enterprise usage, at least for my use. I think > that usage of PAM, NSS, kerberos would provide a good baseline for the > largest set of use cases. Just my thoughts. > > Yours, > > Aaron > > > On Nov 26, 2007 4:51 PM, Michael DeHaan wrote: > > Jack Neely wrote: > > > Michael, > > > > > > Here at NCSU I have an existing provisioning system that generates > > > kickstarts based on a set of "keyword [value [value...]]" rules. We'd > > > like to continue to use that as it works well for us...and it integrates > > > with Cobbler well. > > > > > > So given that, admins already have the ability to control/alter their > > > profiles in a defined way that scales well and lonely me can support. > > > > > > What I'd like from Cobbler is the ability for a select few admins (like > > > me) to be able to setup all the bits to make Cobbler distros/profiles > > > etc. work. > > > > > > Normal admins should be able to associate a MAC address with a profile > > > and remove said MAC. Actually, it would be great if an admin could > > > associate a hostname/IP address with a profile and Cobbler would run a > > > plugin to translate that into a MAC. > > > > > > > One of the things I thought about doing was creating a simpler page to > > just edit a systems mapping. > > > > Login would work as before, but the page could be as simple as what you > > mentioned above, a dropbox, > > and an ok button. CLI equivalents should work too... > > > Groups of admins as well. Any admin can modify MAC->profile of any > > > other admin provided both are in the same group. > > > > > > Authentication via kerberos (PAM probably) authorization done by auto > > > generated groups of admins (a plugin)? > > > > > Sounds reasonable. > > > Okay...some half-baked ideas about how I see a workflow here. If you > > > have questions please feel free. > > > > > > > Thanks! I've got some good feedback so far, so I'll try to summarize > > findings/plans shortly. > > If anyone else wants to share their thoughts on how they'd ideally like > > their site to work, please do. > > > Jack Neely > > > > > > > > > _______________________________________________ > > et-mgmt-tools mailing list > > et-mgmt-tools at redhat.com > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > > From mdehaan at redhat.com Tue Nov 27 22:56:54 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 27 Nov 2007 17:56:54 -0500 Subject: [et-mgmt-tools] Thoughts on Cobbler authorization/authentication and access levels in your organization? In-Reply-To: <39d2723b0711271441m13a413f7gd8414ae21cdca2a1@mail.gmail.com> References: <474B0AFC.6070904@redhat.com> <20071126205712.GH8398@anduril.unity.ncsu.edu> <474B3FD6.8090000@redhat.com> <39d2723b0711262349pe5797e2nab9ba9e30404550b@mail.gmail.com> <39d2723b0711271441m13a413f7gd8414ae21cdca2a1@mail.gmail.com> Message-ID: <474CA0B6.9070801@redhat.com> Aaron Lippold wrote: > Hi, > > Could http://www.freeipa.org/ offer up any quick wins? > > Yours, > > Aaron > Supporting kerberos and LDAP generically, and /enabling/ that kind of support (probably including tutorial instructions for doing that with the IPA stuff) is certaintly the plan. We're not going to require Free IPA setup, however, as we want to support existing installations, which probably have something they already want to use. The other (and slightly more interesting) part of course is getting the permissions/ownership workflows right, and I've gotten some good feedback on that so far as well. --Michael > On Nov 27, 2007 2:49 AM, Aaron Lippold wrote: > >> Hi, >> >> One of the features that would be good would be the abllity to >> intagrate with NSS. Fedora / RedHat Directory server etc. I think >> looking at mod_nss and the already existing pam, pam_pkcs11 etc would >> really expand overall enterprise usage, at least for my use. I think >> that usage of PAM, NSS, kerberos would provide a good baseline for the >> largest set of use cases. Just my thoughts. >> >> Yours, >> >> Aaron >> >> >> On Nov 26, 2007 4:51 PM, Michael DeHaan wrote: >> >>> Jack Neely wrote: >>> >>>> Michael, >>>> >>>> Here at NCSU I have an existing provisioning system that generates >>>> kickstarts based on a set of "keyword [value [value...]]" rules. We'd >>>> like to continue to use that as it works well for us...and it integrates >>>> with Cobbler well. >>>> >>>> So given that, admins already have the ability to control/alter their >>>> profiles in a defined way that scales well and lonely me can support. >>>> >>>> What I'd like from Cobbler is the ability for a select few admins (like >>>> me) to be able to setup all the bits to make Cobbler distros/profiles >>>> etc. work. >>>> >>>> Normal admins should be able to associate a MAC address with a profile >>>> and remove said MAC. Actually, it would be great if an admin could >>>> associate a hostname/IP address with a profile and Cobbler would run a >>>> plugin to translate that into a MAC. >>>> >>>> >>> One of the things I thought about doing was creating a simpler page to >>> just edit a systems mapping. >>> >>> Login would work as before, but the page could be as simple as what you >>> mentioned above, a dropbox, >>> and an ok button. CLI equivalents should work too... >>> >>>> Groups of admins as well. Any admin can modify MAC->profile of any >>>> other admin provided both are in the same group. >>>> >>>> Authentication via kerberos (PAM probably) authorization done by auto >>>> generated groups of admins (a plugin)? >>>> >>>> >>> Sounds reasonable. >>> >>>> Okay...some half-baked ideas about how I see a workflow here. If you >>>> have questions please feel free. >>>> >>>> >>> Thanks! I've got some good feedback so far, so I'll try to summarize >>> findings/plans shortly. >>> If anyone else wants to share their thoughts on how they'd ideally like >>> their site to work, please do. >>> >>>> Jack Neely >>>> >>> _______________________________________________ >>> et-mgmt-tools mailing list >>> et-mgmt-tools at redhat.com >>> https://www.redhat.com/mailman/listinfo/et-mgmt-tools >>> >>> > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From mdehaan at redhat.com Wed Nov 28 20:14:35 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 28 Nov 2007 15:14:35 -0500 Subject: [et-mgmt-tools] Cobbler/koan can now do Xen fullvirt installs Message-ID: <474DCC2B.2040605@redhat.com> Hi folks, For those of you wishing to do fully-automated fully-virtualized Xen installations (as opposed to Xen paravirt, qemu, or KVM which it did already), that is now doable from koan. It requires the virt install libraries that are in Fedora 8. The process is pretty simple. You first need to be running Cobbler from git (development branch) and koan from git also (there is no development branch yet for koan). From the bootserver, tell cobbler to set up a virtual system. This assumes that cobbler is also managing your PXE configuration, as this installation will happen via PXE. # cobbler system add --name=virttest --mac=AA:BB:CC:DD:EE:FF --profile=rhel4-i386 --virt-type=xenfv [...] # cobbler sync (to restart DHCP) Now, request the new virtual installation from koan. # koan --server=bootserver.example.org --virt --system=virttest The installation will take place over a hybrid of PXE and Cobbler XMLRPC, resulting in a fully virtualized Xen install, fully automated all the way through. That's it! I'll add some docs on this to the Wiki ( https://hosted.fedoraproject.org/projects/cobbler/ ). --Michael From mdehaan at redhat.com Wed Nov 28 20:46:38 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 28 Nov 2007 15:46:38 -0500 Subject: [et-mgmt-tools] Cobbler command line is now pluggable Message-ID: <474DD3AE.2070501@redhat.com> This is kind of a development specific topic, but one many of you have been asking about, so I'm sharing here for those not on IRC. Summary: Cobbler command line functions are now driven by modules on the 0.7.X branch, and also now all use "optparse", so the commmand line parsing is better too. Main feature: This means that it is now very easy to add new functions to cobbler, specific to /your/ site. Just drop them in /usr/lib/python2.X/site-packages/cobbler/modules following the pattern of the CLI modules that are already in that directory. These functions could be packaged in a separate RPM, for instance. This may sound like stuff you could already do with the cobbler API (you could), but the module interface makes it much easier, as all the API and parser stuff is already set up for you. The old trigger system is there too, but this allows for even more customization potential. This also makes it much easier to add new options to the existing commands (if you're writing a patch), as it should be a lot easier to understand. This also means things like the following work: # cobbler distro add --help That will show you all the commands that "distro add" takes. Just typing "cobbler" will also show you a cheat sheet of the valid commands. This is all part of the drive to make cobbler even more modular (and adaptable to complex site-specific configurations) than it already is. I'm trying to blur the line between "simple provisioning in a box" and "uber-flexible deployment framework" and you get to pick where you want to be along that line. It starts out very simple, but if you want to customize it to do things that are not doable in the "core" distribution, that should be very easy to do as well. So cobbler is going to enable doing a lot more things outside of "core". Another part of this is initiative is making everything template driven, and also adding in the authentication modules previously mentioned for choosing your workflow. It should all remain completely simple (like now) by default... with the advanced info on the Wiki for those that want it. This is in the git "devel" branch for those that want to check it out. Instructions for working with the devel branch are here: https://hosted.fedoraproject.org/projects/cobbler/wiki/PatchProcess --Michael From jjneely at ncsu.edu Wed Nov 28 23:40:16 2007 From: jjneely at ncsu.edu (Jack Neely) Date: Wed, 28 Nov 2007 18:40:16 -0500 Subject: [et-mgmt-tools] Thoughts on Cobbler authorization/authentication and access levels in your organization? In-Reply-To: <474B3FD6.8090000@redhat.com> References: <474B0AFC.6070904@redhat.com> <20071126205712.GH8398@anduril.unity.ncsu.edu> <474B3FD6.8090000@redhat.com> Message-ID: <20071128234016.GO8398@anduril.unity.ncsu.edu> Michael, While things are floating across my mind... I know I've heard mention of a SQL backend for the configuration. That's pretty much a requirement for me as I need to duplicate the service (2 boxes) for that disaster recovery policy. My shared storage is AFS (mostly) which..well..likes to eat files that two servers/people are editing at the same time. And bdb just falls on its face. Who needs POSIX? I'm really using Cobbler to glue together a lot of pre-existing services: profile management, yum repos, web apps that collect/display status information, etc. Its been fun so far...now to find more time. :-) Jack -- Jack Neely Linux Czar, OIT Campus Linux Services Office of Information Technology, NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From tim.verhoeven.be at gmail.com Thu Nov 29 15:28:20 2007 From: tim.verhoeven.be at gmail.com (Tim Verhoeven) Date: Thu, 29 Nov 2007 16:28:20 +0100 Subject: [et-mgmt-tools] [PATCH] Cobbler - add post install trigger Message-ID: <2a7fce340711290728h10577512h5238eef45952bc4e@mail.gmail.com> Hi, Attached patch creates a extra trigger (install/post) that is triggers by a cgi script (like nopxe.cgi) at the end of a installation. I've think I've covered all bases here but let me know if I missed something. Regards, Tim -- Tim Verhoeven - tim.verhoeven.be at gmail.com - 0479 / 88 11 83 Hoping the problem magically goes away by ignoring it is the "microsoft approach to programming" and should never be allowed. (Linus Torvalds) -------------- next part -------------- A non-text attachment was scrubbed... Name: cobbler-postinstalltrigger.patch Type: text/x-patch Size: 9244 bytes Desc: not available URL: From mdehaan at redhat.com Thu Nov 29 15:27:45 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 29 Nov 2007 10:27:45 -0500 Subject: [et-mgmt-tools] Thoughts on Cobbler authorization/authentication and access levels in your organization? In-Reply-To: <20071128234016.GO8398@anduril.unity.ncsu.edu> References: <474B0AFC.6070904@redhat.com> <20071126205712.GH8398@anduril.unity.ncsu.edu> <474B3FD6.8090000@redhat.com> <20071128234016.GO8398@anduril.unity.ncsu.edu> Message-ID: <474EDA71.7040102@redhat.com> Jack Neely wrote: > Michael, > > While things are floating across my mind... > > I know I've heard mention of a SQL backend for the configuration. > That's pretty much a requirement for me as I need to duplicate the > service (2 boxes) for that disaster recovery policy. My shared storage > is AFS (mostly) which..well..likes to eat files that two servers/people > are editing at the same time. And bdb just falls on its face. Who > needs POSIX? > I haven't been all that happy with the bdb/gdb/shelve prototype module myself, namely, I've seen it glitch once and that makes me not trust it. While I was hoping to get out of schema writing/updating, it seems that's going to be important. Thanks for bringing this up again... I'll resurrect plans in that area. --Michael From clalance at redhat.com Thu Nov 29 15:38:26 2007 From: clalance at redhat.com (Chris Lalancette) Date: Thu, 29 Nov 2007 10:38:26 -0500 Subject: [et-mgmt-tools] [PATCH]: Add the domain name to virt-viewer Message-ID: <474EDCF2.1010205@redhat.com> All, When using virt-viewer for multiple different virtual machines, you can't easily distinguish between them. Attached is a simple patch to add the domain name to the title bar so that you can distinguish between multiple windows at a glance. Signed-off-by: Chris Lalancette -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-viewer-add-dom-name.patch Type: text/x-patch Size: 1116 bytes Desc: not available URL: From csahut at nogoa.org Thu Nov 29 16:31:19 2007 From: csahut at nogoa.org (Christophe Sahut) Date: Thu, 29 Nov 2007 17:31:19 +0100 Subject: [et-mgmt-tools] [PATCH] Add yum priorities support to cobbler repositories Message-ID: <474EE957.607@nogoa.org> From mdehaan at redhat.com Thu Nov 29 17:57:04 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 29 Nov 2007 12:57:04 -0500 Subject: [Fwd: [et-mgmt-tools] [PATCH] Add yum priorities support to cobbler repositories] Message-ID: <474EFD70.1060805@redhat.com> Here's a patch from Christophe that the mailing list ate initially... To avoid this, I think if you include some comments in the email versus just the git patch details, the mailing list stays happy. -------------- next part -------------- An embedded message was scrubbed... From: Christophe Sahut Subject: [et-mgmt-tools] [PATCH] Add yum priorities support to cobbler repositories Date: Thu, 29 Nov 2007 17:31:19 +0100 Size: 4326 URL: From mdehaan at redhat.com Thu Nov 29 18:03:34 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 29 Nov 2007 13:03:34 -0500 Subject: [et-mgmt-tools] [PATCH] Cobbler - add post install trigger In-Reply-To: <2a7fce340711290728h10577512h5238eef45952bc4e@mail.gmail.com> References: <2a7fce340711290728h10577512h5238eef45952bc4e@mail.gmail.com> Message-ID: <474EFEF6.8090207@redhat.com> Tim Verhoeven wrote: > Hi, > > Attached patch creates a extra trigger (install/post) that is triggers > by a cgi script (like nopxe.cgi) at the end of a installation. I've > think I've covered all bases here but let me know if I missed > something. > > Regards, > Tim > > > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools Looks solid. Testing shortly and I'll apply it. Some Wiki content on the triggers page would be great if you'd like to add it. I've been thinking about whether it's useful to make everything doable now from triggers (which can be done in any language) also doable in modules. Any interest? This would likely be a bit on the back burner behind some other module-oriented stuff (auth, logging, looking at SQL again, etc). (Modules would slightly easier because they can pass Python objects around, and are also faster if you have a boatload of systems...) --Michael From rjones at redhat.com Thu Nov 29 19:53:20 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 29 Nov 2007 19:53:20 +0000 Subject: [et-mgmt-tools] [PATCH] virt-manager: Basic compile environment for Windows (Cygwin) Message-ID: <474F18B0.2020500@redhat.com> The attached patch just fixes a few basic compile environment problems for virt-manager under Windows (Cygwin). It doesn't actually run after this, but it does at least compile without any errors. (1) Added a package check for cairo. (2) Add cairo CFLAGS and LIBS. (3) Include , which is needed because the code uses 'cairo_t'. Goodness knows how this works under Linux. (4) Make scrollkeeper optional - it's a PITA to compile it under Cygwin, and it seems to be only needed for the help menus. - - - Note that to use this you will first need to follow my instructions for compiling libvirt for Windows: http://libvirt.org/windows.html Then you will need to install urlgrabber and virtinst from source (both compile fine). Then you should install the Cygwin packages 'atk-devel', 'cairo' and 'glitz'. After applying the patch attached below to the Mercurial version of virt-manager, you can do: autoreconf ./configure make Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-manager-windows-basic-compile.patch Type: text/x-patch Size: 2659 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From berrange at redhat.com Thu Nov 29 19:58:50 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 29 Nov 2007 19:58:50 +0000 Subject: [et-mgmt-tools] [PATCH] virt-manager: Basic compile environment for Windows (Cygwin) In-Reply-To: <474F18B0.2020500@redhat.com> References: <474F18B0.2020500@redhat.com> Message-ID: <20071129195850.GB21587@redhat.com> On Thu, Nov 29, 2007 at 07:53:20PM +0000, Richard W.M. Jones wrote: > The attached patch just fixes a few basic compile environment problems > for virt-manager under Windows (Cygwin). It doesn't actually run after > this, but it does at least compile without any errors. > > (1) Added a package check for cairo. > > (2) Add cairo CFLAGS and LIBS. > > (3) Include , which is needed because the code uses 'cairo_t'. > Goodness knows how this works under Linux. GTK on modern Linux uses cairo for all rendering. Guess Cygwin doesn't use Cairo. Just as well I didn't remove the non-Cairo fallback in the sparkline widget :-) $ find /usr/include/gtk-2.0 | xargs grep cairo.h /usr/include/gtk-2.0/gdk/gdkscreen.h:#include /usr/include/gtk-2.0/gdk/gdkdrawable.h:#include /usr/include/gtk-2.0/gdk/gdk.h:#include /usr/include/gtk-2.0/gdk/gdkpixbuf.h:#include /usr/include/gtk-2.0/gdk/gdkcairo.h:#include /usr/include/gtk-2.0/gdk/gdkcolor.h:#include /usr/include/gtk-2.0/gtk/gtkprintoperation.h:#include /usr/include/gtk-2.0/gtk/gtkprintoperationpreview.h:#include Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From berrange at redhat.com Thu Nov 29 20:11:42 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 29 Nov 2007 20:11:42 +0000 Subject: [et-mgmt-tools] [PATCH]: Add the domain name to virt-viewer In-Reply-To: <474EDCF2.1010205@redhat.com> References: <474EDCF2.1010205@redhat.com> Message-ID: <20071129201142.GC21587@redhat.com> On Thu, Nov 29, 2007 at 10:38:26AM -0500, Chris Lalancette wrote: > All, > When using virt-viewer for multiple different virtual machines, you can't > easily distinguish between them. Attached is a simple patch to add the domain > name to the title bar so that you can distinguish between multiple windows at a > glance. The VNC server provided title is actually pretty much useless, so I just removed it completely. We now always use the libvirt provided domain name as per your patch. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From tim.verhoeven.be at gmail.com Thu Nov 29 20:38:11 2007 From: tim.verhoeven.be at gmail.com (Tim Verhoeven) Date: Thu, 29 Nov 2007 21:38:11 +0100 Subject: [et-mgmt-tools] [PATCH] Cobbler - add post install trigger In-Reply-To: <474EFEF6.8090207@redhat.com> References: <2a7fce340711290728h10577512h5238eef45952bc4e@mail.gmail.com> <474EFEF6.8090207@redhat.com> Message-ID: <2a7fce340711291238rfcfc3b4i59f3958569b5ae44@mail.gmail.com> On Nov 29, 2007 7:03 PM, Michael DeHaan wrote: > > Some Wiki content on the triggers page would be great if you'd like to > add it. No problem, I'll add something tomorrow. > I've been thinking about whether it's useful to make everything doable > now from triggers (which can be done in any language) also doable in > modules. > Any interest? This would likely be a bit on the back burner behind > some other module-oriented stuff (auth, logging, looking at SQL again, etc). > > (Modules would slightly easier because they can pass Python objects > around, and are also faster if you have a boatload of systems...) It sounds like something usefull. Not for me immediately. I'm more into writing shell scripts first and move to something else if shells script don't cut it anymore. So for the iSCSI thing I'll probably write a something in python (since I need the API to create the Xen config files). Also generaly speaking at the moment I most likely need/use the sync and install triggers. I don't see a immediate use for the add/remove triggers for the different objects in Cobbler. Thanks for all your help, Tim -- Tim Verhoeven - tim.verhoeven.be at gmail.com - 0479 / 88 11 83 Hoping the problem magically goes away by ignoring it is the "microsoft approach to programming" and should never be allowed. (Linus Torvalds) From berrange at redhat.com Thu Nov 29 20:42:02 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 29 Nov 2007 20:42:02 +0000 Subject: [et-mgmt-tools] Virt-Manager: Supporting additional para-virtual OS's In-Reply-To: <47467C12.7020602@the-nelsons.org> References: <473BFA57.7070601@the-nelsons.org> <20071115141911.GF17977@redhat.com> <473CA2BD.5020604@the-nelsons.org> <20071116110215.GB3283@redhat.com> <47467C12.7020602@the-nelsons.org> Message-ID: <20071129204202.GD21587@redhat.com> On Thu, Nov 22, 2007 at 11:06:58PM -0800, Robert Nelson wrote: > Daniel P. Berrange wrote: > > > >In the virtinst/FullVirtGuest.py class, there is already a bunch of > >OS specific metadata, eg what of mouse to use, apic/acpi/pae settings, > >whether the installer is multi-stage reboots (eg Windows). I'd recommend > >moving this metadata into virtinst/DistroManager and have a bunch of > >methods in that module for querying distro specific metadata, from the > >Installer class. > > > >Dan. > > > I spent some time reworking the virtinst code to support OpenSolaris and > make it much easier to support additional OSes. I've attached the patch > file to get some feedback on the work so far. Thanks for this. Took me a little while to get to grips with it, but I like the resulting structure. I'm going todo a few tests and if it works I'll commit it to the repo. BTW, for any large patches in the future, its handy for review if you do separate patches for re-factoring existing code, vs adding new capabilities. It would have made it easier to review if the splitting up of the DistroManager.py file were a simple no-functional-change refactoring. Also helps people browsing the SCM history in the future to distinguish the changes. No need to change this existing patch though, I'll just add as is... > Unfortunately a bunch for the code from virtinst is duplicated in > virt-manager in the Add Device code. This means either moving it back > to virtinst with the appropriate additional APIs or duplicating work in > virt-manager. We should make virt-manager call into the virtinst APIs really. virtinst is intended as the library for virt-manager to get all OS install/setup logic from. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From clalance at redhat.com Thu Nov 29 21:06:51 2007 From: clalance at redhat.com (Chris Lalancette) Date: Thu, 29 Nov 2007 16:06:51 -0500 Subject: [et-mgmt-tools] [PATCH]: Add the domain name to virt-viewer In-Reply-To: <20071129201142.GC21587@redhat.com> References: <474EDCF2.1010205@redhat.com> <20071129201142.GC21587@redhat.com> Message-ID: <474F29EB.2070703@redhat.com> Daniel P. Berrange wrote: > The VNC server provided title is actually pretty much useless, so I just > removed it completely. We now always use the libvirt provided domain name > as per your patch. Yeah, I wasn't sure how useful the VNC part was, so I choose safe and left it. Anyway, thanks! Chris Lalancette From tobert at gmail.com Thu Nov 29 22:28:35 2007 From: tobert at gmail.com (Al Tobey) Date: Thu, 29 Nov 2007 14:28:35 -0800 Subject: [et-mgmt-tools] koan --autonet patch [resend] Message-ID: <5ac7acb10711291428k55d579c0ve6c18835e7483f2f@mail.gmail.com> Attached is an updated version of my --autonet/-A patch for koan. This makes koan able to set up kernel command line options (ip=,netmask=,etc.) to set up networking in a kickstart without DHCP. It currently does not look at multiple interfaces in cobbler or the new fields for extended information beyond IP (yet). If you specify --replace-self --autonet, koan will use iproute2 to pull the primary network configuration from the running system. Otherwise, it'll pull down the kickstart file and look for a network --bootproto=static and use whatever that specifies. -Al Tobey -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Autonet-option-for-network-configuration.patch Type: text/x-patch Size: 15182 bytes Desc: not available URL: From mdehaan at redhat.com Thu Nov 29 22:41:20 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 29 Nov 2007 17:41:20 -0500 Subject: [et-mgmt-tools] [PATCH] Add yum priorities support to cobbler repositories In-Reply-To: <474EE957.607@nogoa.org> References: <474EE957.607@nogoa.org> Message-ID: <474F4010.6010206@redhat.com> Christophe Sahut wrote: > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools Applied (with just a few tweaks -- changed the default priority for repos to be the default priority of the plugin, and added some error handling on input type). Thanks! and a very nice feature too... http://git.fedoraproject.org/?p=hosted/cobbler;a=commitdiff;h=248b28b0181d87069364a87f4762086206781d38 --Michael From mdehaan at redhat.com Thu Nov 29 23:05:42 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 29 Nov 2007 18:05:42 -0500 Subject: [et-mgmt-tools] koan --autonet patch [resend] In-Reply-To: <5ac7acb10711291428k55d579c0ve6c18835e7483f2f@mail.gmail.com> References: <5ac7acb10711291428k55d579c0ve6c18835e7483f2f@mail.gmail.com> Message-ID: <474F45C6.5060901@redhat.com> Al Tobey wrote: > Attached is an updated version of my --autonet/-A patch for koan. > This makes koan able to set up kernel command line options > (ip=,netmask=,etc.) to set up networking in a kickstart without DHCP. > It currently does not look at multiple interfaces in cobbler or the > new fields for extended information beyond IP (yet). > > If you specify --replace-self --autonet, koan will use iproute2 to > pull the primary network configuration from the running system. > Otherwise, it'll pull down the kickstart file and look for a network > --bootproto=static and use whatever that specifies. > > -Al Tobey > Applied! Thanks! > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From mdehaan at redhat.com Thu Nov 29 23:07:44 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 29 Nov 2007 18:07:44 -0500 Subject: [et-mgmt-tools] koan-0.6.3-3.el4.mrh - kix templating - network rebuilt issue In-Reply-To: <474B4F45.9030005@ng23.net> References: <474B2F75.30008@ng23.net> <474B31C6.1040706@redhat.com> <474B3675.9050107@ng23.net> <474B37F4.5010305@redhat.com> <474B3C3E.9070708@ng23.net> <474B3DD0.10507@redhat.com> <474B4346.7020506@ng23.net> <474B4401.2030302@redhat.com> <474B49D8.1000208@ng23.net> <474B4CD2.8020804@redhat.com> <474B4F45.9030005@ng23.net> Message-ID: <474F4640.3000008@redhat.com> Tom Brown wrote: > > for me dhcp in production is not really an option. i can get away with > it for bare metal but alas not for rebuilds > >> We're not going to do client-side templating of kickstart files in >> koan because we already do that Cobbler side, and also because to >> support older distros (EL3), we can't use the same templating >> engine... which >> adds way too much complexity, and it is also hard to explain why we'd >> actually need that feature if we already have a cobbler command that >> does the same thing :) >> >> In conclusion ... (A) use profiles with DHCP, or (B) run cobbler >> edit command before using koan. Those are the two suggestions. > > thanks for your advice regarding this issue - i'll see what i can come > up with. > > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools Tom, I've applied Al Tobey's --autonet patch to koan upstream. This seems like it will fix your problem for profile based reinstalls, because it will add in the IP info on the kernel command line based on what you are currently using. Might be worth checking out. You should be able to use koan 0.6.4 from git with your existing Cobbler install. --Michael From robertn at the-nelsons.org Fri Nov 30 04:14:50 2007 From: robertn at the-nelsons.org (Robert Nelson) Date: Thu, 29 Nov 2007 20:14:50 -0800 Subject: [et-mgmt-tools] Virt-Manager: Supporting additional para-virtual OS's In-Reply-To: <20071129204202.GD21587@redhat.com> References: <473BFA57.7070601@the-nelsons.org> <20071115141911.GF17977@redhat.com> <473CA2BD.5020604@the-nelsons.org> <20071116110215.GB3283@redhat.com> <47467C12.7020602@the-nelsons.org> <20071129204202.GD21587@redhat.com> Message-ID: <474F8E3A.6060709@the-nelsons.org> Daniel P. Berrange wrote: > On Thu, Nov 22, 2007 at 11:06:58PM -0800, Robert Nelson wrote: > >> Daniel P. Berrange wrote: >> >>> In the virtinst/FullVirtGuest.py class, there is already a bunch of >>> OS specific metadata, eg what of mouse to use, apic/acpi/pae settings, >>> whether the installer is multi-stage reboots (eg Windows). I'd recommend >>> moving this metadata into virtinst/DistroManager and have a bunch of >>> methods in that module for querying distro specific metadata, from the >>> Installer class. >>> >>> Dan. >>> >>> >> I spent some time reworking the virtinst code to support OpenSolaris and >> make it much easier to support additional OSes. I've attached the patch >> file to get some feedback on the work so far. >> > > Thanks for this. Took me a little while to get to grips with it, but I > like the resulting structure. I'm going todo a few tests and if it > works I'll commit it to the repo. > > BTW, for any large patches in the future, its handy for review if you > do separate patches for re-factoring existing code, vs adding new > capabilities. It would have made it easier to review if the splitting > up of the DistroManager.py file were a simple no-functional-change > refactoring. Also helps people browsing the SCM history in the future > to distinguish the changes. No need to change this existing patch > though, I'll just add as is... > > Please hold off on committing this patch. I have an updated and better version coming shortly. I'll post it as two patches to make the SCM history more readable. I'll also post it to a new thread. >> Unfortunately a bunch for the code from virtinst is duplicated in >> virt-manager in the Add Device code. This means either moving it back >> to virtinst with the appropriate additional APIs or duplicating work in >> virt-manager. >> > > We should make virt-manager call into the virtinst APIs really. virtinst > is intended as the library for virt-manager to get all OS install/setup > logic from. > > If you don't mind, I'll put together a prototype of this for review. > Regards, > Dan. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robertn at the-nelsons.org Fri Nov 30 04:17:59 2007 From: robertn at the-nelsons.org (Robert Nelson) Date: Thu, 29 Nov 2007 20:17:59 -0800 Subject: [et-mgmt-tools] Virt-Manager: Supporting additional para-virtual OS's In-Reply-To: <474C7E38.8070504@redhat.com> References: <473BFA57.7070601@the-nelsons.org> <20071115141911.GF17977@redhat.com> <473CA2BD.5020604@the-nelsons.org> <20071116110215.GB3283@redhat.com> <47467C12.7020602@the-nelsons.org> <474C7E38.8070504@redhat.com> Message-ID: <474F8EF7.1020304@the-nelsons.org> Cole Robinson wrote: > Robert Nelson wrote: > >> I spent some time reworking the virtinst code to support OpenSolaris and >> make it much easier to support additional OSes. I've attached the patch >> file to get some feedback on the work so far. >> >> Unfortunately a bunch for the code from virtinst is duplicated in >> virt-manager in the Add Device code. This means either moving it back >> to virtinst with the appropriate additional APIs or duplicating work in >> virt-manager. >> >> >> >> > > Hi Robert, > > Could you take a couple paragraphs explaining exactly how you reorganized > everything? And also I think posting the patch to its own thread will get > it more attention. > > I'll put more explanation in the next version of the patch. > One small thing before you repost: __init__.py had ::LOCALEDIR:: replaced > with /usr/share/locale. This shouldn't be hardcoded and is filled in as > appropriate at build time by setup.py. > > This happens during the build. Since I diffed against my built version it had been updated. Usually I delete that diff from the patch but I guess I missed it in that version. > Thanks, > Cole > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at ng23.net Fri Nov 30 10:56:56 2007 From: tom at ng23.net (Tom Brown) Date: Fri, 30 Nov 2007 10:56:56 +0000 Subject: [et-mgmt-tools] koan-0.6.3-3.el4.mrh - kix templating - network rebuilt issue In-Reply-To: <474F4640.3000008@redhat.com> References: <474B2F75.30008@ng23.net> <474B31C6.1040706@redhat.com> <474B3675.9050107@ng23.net> <474B37F4.5010305@redhat.com> <474B3C3E.9070708@ng23.net> <474B3DD0.10507@redhat.com> <474B4346.7020506@ng23.net> <474B4401.2030302@redhat.com> <474B49D8.1000208@ng23.net> <474B4CD2.8020804@redhat.com> <474B4F45.9030005@ng23.net> <474F4640.3000008@redhat.com> Message-ID: <474FEC78.4040506@ng23.net> > > > I've applied Al Tobey's --autonet patch to koan upstream. > > This seems like it will fix your problem for profile based reinstalls, > because it will add in the IP info on the kernel command line based on > what you are currently using. > > Might be worth checking out. You should be able to use koan 0.6.4 > from git with your existing Cobbler install. > thanks for the effort here - alas it does not work for me as it makes grub look like this kernel /vmlinuz ro root=LABEL=/1 ksdevice=eth0 lang= kssendmac syslog=19 2.168.10.4:25150 text ks=file:ks.cfg ip=$ip_address netmask=$subnet hostname=$ho stname nameserver=$nameserver gateway=$gateway So its not getting the values, its getting the info from the ks template - Is there no way to get these values from the currently running OS ? thanks From berrange at redhat.com Fri Nov 30 14:57:16 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 30 Nov 2007 14:57:16 +0000 Subject: [et-mgmt-tools] Virt-Manager: Supporting additional para-virtual OS's In-Reply-To: <474F8E3A.6060709@the-nelsons.org> References: <473BFA57.7070601@the-nelsons.org> <20071115141911.GF17977@redhat.com> <473CA2BD.5020604@the-nelsons.org> <20071116110215.GB3283@redhat.com> <47467C12.7020602@the-nelsons.org> <20071129204202.GD21587@redhat.com> <474F8E3A.6060709@the-nelsons.org> Message-ID: <20071130145708.GB10398@redhat.com> On Thu, Nov 29, 2007 at 08:14:50PM -0800, Robert Nelson wrote: > Daniel P. Berrange wrote: > >>I spent some time reworking the virtinst code to support OpenSolaris and > >>make it much easier to support additional OSes. I've attached the patch > >>file to get some feedback on the work so far. > >> > > > >Thanks for this. Took me a little while to get to grips with it, but I > >like the resulting structure. I'm going todo a few tests and if it > >works I'll commit it to the repo. > > > >BTW, for any large patches in the future, its handy for review if you > >do separate patches for re-factoring existing code, vs adding new > >capabilities. It would have made it easier to review if the splitting > >up of the DistroManager.py file were a simple no-functional-change > >refactoring. Also helps people browsing the SCM history in the future > >to distinguish the changes. No need to change this existing patch > >though, I'll just add as is... > > Please hold off on committing this patch. I have an updated and better > version coming shortly. I'll post it as two patches to make the SCM > history more readable. I'll also post it to a new thread. So it turned out to be a little more complicated than I expected. At first I liked the idea of having OSDistro create & use the ImageFetcher class directly, however, there are circumstances where we need to use the OSDistro class without the ImageFetcher, so this dependancy causes problems. Second, the FullVirtGuest/ParaVirtGuest classes now call into the installer class to get the disk target - this is a problem because this code is only relevant for the DistroInstaller class - the ImageInstaller works in a different way. Really, theFullVirt/ParaVirt guest class should not try todo any assignement of disk targets at all. The 'prepare' method fo the DistroInstaller class should contain the code to assign disk targets directly. This simplifies the get_disk_xml methods in the Full/ParaVirtGuest classes, and avoids the hard dependancy. So, in the end I just committed two small parts. I pulled the ImageFetcher classes out into a separate python module, and pulled the OSDistro classes out into a separate python module. So just 2 no-functional-change refactorings for now. If you post your latest patches I'll give them another try & see if there's more bits we can safely commit as we go. > >>Unfortunately a bunch for the code from virtinst is duplicated in > >>virt-manager in the Add Device code. This means either moving it back > >>to virtinst with the appropriate additional APIs or duplicating work in > >>virt-manager. > >> > > > >We should make virt-manager call into the virtinst APIs really. virtinst > >is intended as the library for virt-manager to get all OS install/setup > >logic from. > > > > > > If you don't mind, I'll put together a prototype of this for review. Sure. The complicated thing about the 'Add device' code is that we no longer have any record of the OS Distro type at that point - this info is only available at install time. So its not clear how we'd be able to get an instance of the OSDistro class neccessary to figure out the disk target names here. Also this is one use case I mentioned where you need OSDistro to be independant of the ImageFetcher class. BTW, I'm not convinced the Solaris distro class is correct. I know the paravirt guests have to name their disk targets 0, 1, 2 ... etc isntead of xvda, xvdb, etc. For fully-virt Solaris installs though it must still use hda, hdb, hdc, etc as per Linux. This is because the hda, hdb, etc names translate directly to QEMU command line args - they have no resemblance to what the guest OS calls its disks - indeed modern Linux will call them sda, sdb, sdc, etc regardless of what QEMU calls tem. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From johnson.nh at gmail.com Fri Nov 30 16:13:03 2007 From: johnson.nh at gmail.com (Mark Johnson) Date: Fri, 30 Nov 2007 11:13:03 -0500 Subject: [et-mgmt-tools] solaris virt-install patches Message-ID: <521a4d120711300813q60f4b5dfn753b988e9efac255@mail.gmail.com> from conversation on #xen.... current Solaris virt-install patches attached. Disclaimers :-) This are informational only (e.g. not proposing they be applied).. They still need cleanup etc.. These patches are what are in the current solaris builds. We are currently still working on the lastest version of virt-install. For the interested, the source is generally available @ the following until we move the gate on the other side of the firewall, you can download the xvm specific source @ http://dlc.sun.com/osol/on/downloads/b77/xvm-src.tar.bz2 (where b77 is the OpenSolaris build). You'll see the following dirs in there, libvirt, sunos, and urlgrabber are hg gates, urlgrabber and xen are hg mq gates (long story)... :-) libvirt.hg/ sunos.hg/ virtinst.hg/ urlgrabber.hg/ xen.hg/ MRJ -------------- next part -------------- A non-text attachment was scrubbed... Name: mac-address-parse Type: application/octet-stream Size: 799 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: outgoing Type: application/octet-stream Size: 7848 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: series Type: application/octet-stream Size: 52 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: solaris-support Type: application/octet-stream Size: 24602 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: use-virsh-console Type: application/octet-stream Size: 1263 bytes Desc: not available URL: From mdehaan at redhat.com Fri Nov 30 16:23:15 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 30 Nov 2007 11:23:15 -0500 Subject: [et-mgmt-tools] koan-0.6.3-3.el4.mrh - kix templating - network rebuilt issue In-Reply-To: <474FEC78.4040506@ng23.net> References: <474B2F75.30008@ng23.net> <474B31C6.1040706@redhat.com> <474B3675.9050107@ng23.net> <474B37F4.5010305@redhat.com> <474B3C3E.9070708@ng23.net> <474B3DD0.10507@redhat.com> <474B4346.7020506@ng23.net> <474B4401.2030302@redhat.com> <474B49D8.1000208@ng23.net> <474B4CD2.8020804@redhat.com> <474B4F45.9030005@ng23.net> <474F4640.3000008@redhat.com> <474FEC78.4040506@ng23.net> Message-ID: <475038F3.1060905@redhat.com> Tom Brown wrote: > >> >> >> I've applied Al Tobey's --autonet patch to koan upstream. >> >> This seems like it will fix your problem for profile based >> reinstalls, because it will add in the IP info on the kernel command >> line based on what you are currently using. >> >> Might be worth checking out. You should be able to use koan 0.6.4 >> from git with your existing Cobbler install. >> > > thanks for the effort here - alas it does not work for me as it makes > grub look like this > > kernel /vmlinuz ro root=LABEL=/1 ksdevice=eth0 lang= kssendmac syslog=19 > 2.168.10.4:25150 text ks=file:ks.cfg ip=$ip_address netmask=$subnet > hostname=$ho > stname nameserver=$nameserver gateway=$gateway > > So its not getting the values, its getting the info from the ks > template - Is there no way to get these values from the currently > running OS ? > From the manpage for the new feature: --autonet "First, koan will download the kickstart configuration and check for a network --bootproto=static method. If that fails and --replace-self has been specified, koan will use the current system's network configuration, as found using iproute2. " What it looks like is it's finding the first thing (your template line), and not going to iproute2. So you'll need to modify your kickstart to only include the network line when you are doing per-system (and not per-profile) installations. The question then remains (and this is perhaps more suited for kickstart-list at redhat.com), if you have all the network setup arguments on the kernel command line, do you still need the entry in the kickstart file? Here's what your template might look like (untested, see https://hosted.fedoraproject.org/projects/cobbler/wiki/KickstartTemplating for pointers) #if $getVar("ip_address","none") != "none" ## this is a per-system kickstart, not a per-profile kickstart network ... etc ... etc ... #else ## possibly might need something here to build the network line in the kickstart based on kernel parameters ## using a hack in %pre, though I am not entirely sure. Hopefully Anaconda can just figure it out from kernel ## args automatically #end if Make sense? Sort of? It is a bit of a messy corner case but you're really close. --Michael > thanks > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From Greg.Caetano at hp.com Fri Nov 30 16:54:08 2007 From: Greg.Caetano at hp.com (Caetano, Greg) Date: Fri, 30 Nov 2007 16:54:08 +0000 Subject: [et-mgmt-tools] Watcher.py? Message-ID: The watcher.py URL is included in the kickstart file generation ($kickstart_done) of cobbler-0.6.4, but I don't appear to find the watcher.py script included in the src rpm. Should the $kickstart_done directive not be included in the kickstart_fc6.ks files? Regards Greg Greg Caetano greg.caetano at hp.com From mdehaan at redhat.com Fri Nov 30 17:04:11 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 30 Nov 2007 12:04:11 -0500 Subject: [et-mgmt-tools] Watcher.py? In-Reply-To: References: Message-ID: <4750428B.3000303@redhat.com> Caetano, Greg wrote: > The watcher.py URL is included in the kickstart file generation ($kickstart_done) of cobbler-0.6.4, but I don't appear to find the watcher.py script included in the src rpm. > > Should the $kickstart_done directive not be included in the kickstart_fc6.ks files? > Watcher.py is not a real file, it is just something we look for in the Apache logs for "cobbler check". There /used/ to be a watcher.py, so that is largely historical. I have been tempted to change it to "THIS_FILE_DOES_NOT_EXIST" so people don't have to ask the question :) > Regards > Greg > > > Greg Caetano > greg.caetano at hp.com > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From Greg.Caetano at hp.com Fri Nov 30 17:27:17 2007 From: Greg.Caetano at hp.com (Caetano, Greg) Date: Fri, 30 Nov 2007 17:27:17 +0000 Subject: [et-mgmt-tools] Watcher.py? In-Reply-To: <4750428B.3000303@redhat.com> References: <4750428B.3000303@redhat.com> Message-ID: Ok... I thought that might be the issue why "cobbler status" does not appear to complete the status field ... [root at hpmgmt ~]# cobbler status Name | State | Last Request | Started | Seconds | Log Entries 192.168.0.1 | ? | ? | Fri Nov 30 10:54:36 2007 | ? | 5 192.168.0.2 | ? | Thu Nov 29 13:41:33 2007 | Thu Nov 29 13:52:22 2007 | 649 | 72 192.168.0.3 | ? | Thu Nov 29 13:42:38 2007 | Thu Nov 29 13:51:34 2007 | 536 | 61 192.168.0.4 | ? | Thu Nov 29 13:54:40 2007 | Thu Nov 29 14:03:49 2007 | 549 | 59 -----Original Message----- From: et-mgmt-tools-bounces at redhat.com [mailto:et-mgmt-tools-bounces at redhat.com] On Behalf Of Michael DeHaan Sent: Friday, November 30, 2007 11:04 AM To: Fedora/Linux Management Tools Subject: Re: [et-mgmt-tools] Watcher.py? Caetano, Greg wrote: > The watcher.py URL is included in the kickstart file generation ($kickstart_done) of cobbler-0.6.4, but I don't appear to find the watcher.py script included in the src rpm. > > Should the $kickstart_done directive not be included in the kickstart_fc6.ks files? > Watcher.py is not a real file, it is just something we look for in the Apache logs for "cobbler check". There /used/ to be a watcher.py, so that is largely historical. I have been tempted to change it to "THIS_FILE_DOES_NOT_EXIST" so people don't have to ask the question :) > Regards > Greg > > > Greg Caetano > greg.caetano at hp.com > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > _______________________________________________ et-mgmt-tools mailing list et-mgmt-tools at redhat.com https://www.redhat.com/mailman/listinfo/et-mgmt-tools From mdehaan at redhat.com Fri Nov 30 17:44:09 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 30 Nov 2007 12:44:09 -0500 Subject: [et-mgmt-tools] Watcher.py? In-Reply-To: References: <4750428B.3000303@redhat.com> Message-ID: <47504BE9.30104@redhat.com> Caetano, Greg wrote: > Ok... > > I thought that might be the issue why "cobbler status" does not appear to complete the status field ... > > [root at hpmgmt ~]# cobbler status > Name | State | Last Request | Started | Seconds | Log Entries > 192.168.0.1 | ? | ? | Fri Nov 30 10:54:36 2007 | ? | 5 > 192.168.0.2 | ? | Thu Nov 29 13:41:33 2007 | Thu Nov 29 13:52:22 2007 | 649 | 72 > 192.168.0.3 | ? | Thu Nov 29 13:42:38 2007 | Thu Nov 29 13:51:34 2007 | 536 | 61 > 192.168.0.4 | ? | Thu Nov 29 13:54:40 2007 | Thu Nov 29 14:03:49 2007 | 549 | 59 > > > Previously there was a fancy (relatively speaking) mod_python solution I wrote that gave really good kickstart status. The problem was it didn't work very well on older RHEL, which we wanted to support. So I took it out, and I'm not quite as happy with what we have now. It's on the list of things to overhaul in the future, but I hadn't got many requests for better status tracking recently, so it's been a bit down on the priority list as compared to some new features. We could possibly just show Last Request and "Started" times, which might be enough. > -----Original Message----- > From: et-mgmt-tools-bounces at redhat.com [mailto:et-mgmt-tools-bounces at redhat.com] On Behalf Of Michael DeHaan > Sent: Friday, November 30, 2007 11:04 AM > To: Fedora/Linux Management Tools > Subject: Re: [et-mgmt-tools] Watcher.py? > > Caetano, Greg wrote: > >> The watcher.py URL is included in the kickstart file generation ($kickstart_done) of cobbler-0.6.4, but I don't appear to find the watcher.py script included in the src rpm. >> >> Should the $kickstart_done directive not be included in the kickstart_fc6.ks files? >> >> > > Watcher.py is not a real file, it is just something we look for in the Apache logs for "cobbler check". > > There /used/ to be a watcher.py, so that is largely historical. > > I have been tempted to change it to "THIS_FILE_DOES_NOT_EXIST" so people don't have to ask the question :) > > >> Regards >> Greg >> >> >> Greg Caetano >> greg.caetano at hp.com >> >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools >> >> > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From swissslinky at gmail.com Fri Nov 30 18:51:14 2007 From: swissslinky at gmail.com (Dan) Date: Fri, 30 Nov 2007 19:51:14 +0100 Subject: [et-mgmt-tools] Watcher.py? In-Reply-To: <47504BE9.30104@redhat.com> References: <4750428B.3000303@redhat.com> <47504BE9.30104@redhat.com> Message-ID: <1196448674.5709.2.camel@slinky> On Fri, 2007-11-30 at 12:44 -0500, Michael DeHaan wrote: > Caetano, Greg wrote: > > Ok... > > > > I thought that might be the issue why "cobbler status" does not appear to complete the status field ... > > > > [root at hpmgmt ~]# cobbler status > > Name | State | Last Request | Started | Seconds | Log Entries > > 192.168.0.1 | ? | ? | Fri Nov 30 10:54:36 2007 | ? | 5 > > 192.168.0.2 | ? | Thu Nov 29 13:41:33 2007 | Thu Nov 29 13:52:22 2007 | 649 | 72 > > 192.168.0.3 | ? | Thu Nov 29 13:42:38 2007 | Thu Nov 29 13:51:34 2007 | 536 | 61 > > 192.168.0.4 | ? | Thu Nov 29 13:54:40 2007 | Thu Nov 29 14:03:49 2007 | 549 | 59 > > > > > > > Previously there was a fancy (relatively speaking) mod_python solution I > wrote that gave really good kickstart status. The problem was it didn't > work very well > on older RHEL, which we wanted to support. So I took it out, and I'm not > quite as happy with what we have now. > > It's on the list of things to overhaul in the future, but I hadn't got > many requests for better status tracking recently, so it's been a bit > down on the priority list > as compared to some new features. We'd love this feature. Tracking is high on our list of requirements. I have put it in my lengthy email regarding thoughts on author/authen which should appear in your inbox shortly. Just saw this and thought I'd highlight it whilst it was on your mind =) > > We could possibly just show Last Request and "Started" times, which > might be enough. > > > > > > > -----Original Message----- > > From: et-mgmt-tools-bounces at redhat.com [mailto:et-mgmt-tools-bounces at redhat.com] On Behalf Of Michael DeHaan > > Sent: Friday, November 30, 2007 11:04 AM > > To: Fedora/Linux Management Tools > > Subject: Re: [et-mgmt-tools] Watcher.py? > > > > Caetano, Greg wrote: > > > >> The watcher.py URL is included in the kickstart file generation ($kickstart_done) of cobbler-0.6.4, but I don't appear to find the watcher.py script included in the src rpm. > >> > >> Should the $kickstart_done directive not be included in the kickstart_fc6.ks files? > >> > >> > > > > Watcher.py is not a real file, it is just something we look for in the Apache logs for "cobbler check". > > > > There /used/ to be a watcher.py, so that is largely historical. > > > > I have been tempted to change it to "THIS_FILE_DOES_NOT_EXIST" so people don't have to ask the question :) > > > > > >> Regards > >> Greg > >> > >> > >> Greg Caetano > >> greg.caetano at hp.com > >> > >> _______________________________________________ > >> et-mgmt-tools mailing list > >> et-mgmt-tools at redhat.com > >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools > >> > >> > > > > _______________________________________________ > > et-mgmt-tools mailing list > > et-mgmt-tools at redhat.com > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > > > _______________________________________________ > > et-mgmt-tools mailing list > > et-mgmt-tools at redhat.com > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From mdehaan at redhat.com Fri Nov 30 20:25:12 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 30 Nov 2007 15:25:12 -0500 Subject: [et-mgmt-tools] Watcher.py? In-Reply-To: <1196448674.5709.2.camel@slinky> References: <4750428B.3000303@redhat.com> <47504BE9.30104@redhat.com> <1196448674.5709.2.camel@slinky> Message-ID: <475071A8.2040600@redhat.com> Dan wrote: > On Fri, 2007-11-30 at 12:44 -0500, Michael DeHaan wrote: > >> Caetano, Greg wrote: >> >>> Ok... >>> >>> I thought that might be the issue why "cobbler status" does not appear to complete the status field ... >>> >>> [root at hpmgmt ~]# cobbler status >>> Name | State | Last Request | Started | Seconds | Log Entries >>> 192.168.0.1 | ? | ? | Fri Nov 30 10:54:36 2007 | ? | 5 >>> 192.168.0.2 | ? | Thu Nov 29 13:41:33 2007 | Thu Nov 29 13:52:22 2007 | 649 | 72 >>> 192.168.0.3 | ? | Thu Nov 29 13:42:38 2007 | Thu Nov 29 13:51:34 2007 | 536 | 61 >>> 192.168.0.4 | ? | Thu Nov 29 13:54:40 2007 | Thu Nov 29 14:03:49 2007 | 549 | 59 >>> >>> >>> >>> >> Previously there was a fancy (relatively speaking) mod_python solution I >> wrote that gave really good kickstart status. The problem was it didn't >> work very well >> on older RHEL, which we wanted to support. So I took it out, and I'm not >> quite as happy with what we have now. >> >> It's on the list of things to overhaul in the future, but I hadn't got >> many requests for better status tracking recently, so it's been a bit >> down on the priority list >> as compared to some new features. >> > > We'd love this feature. Tracking is high on our list of requirements. I > have put it in my lengthy email regarding thoughts on author/authen > which should appear in your inbox shortly. Just saw this and thought I'd > highlight it whilst it was on your mind =) > Interested enough to implement something, perhaps? Wink, wink, nudge nudge?