cobbler November 2008

cobbler@lists.fedorahosted.org

41 participants
119 discussions

Re: user tracking question?
by Joseph Boyer Jr. 13 Nov '08

13 Nov '08

Thanks. I will add the trac ticket Fyi: I am current have my folks loging in with there kerberos crential and diffing the changes to the systems file to track changes. This is all that reliable so if this is automated that would be great ------------------- Joseph Boyer Jr. Liquidnet Holdings Inc. Enterprise Technology Services Joseph.Boyer(a)liquidnet.com T: +1 646.660.8352 C: +1 646.284.8394 -----Original Message----- From: Michael DeHaan [mailto:mdehaan@redhat.com] Sent: Thursday, November 13, 2008 01:27 PM Eastern Standard Time To: cobbler mailing list Subject: Re: user tracking question? Joseph Boyer Jr. wrote: > Question, > > I know that you have enable timestamps of parameters enter into cobbler; is it possible to track what user added or updated these entries as well? > > I only ask because that would make my auditing of the cobbler system that much easier, as I need to track who, what and when. I am primarily interested in what is entered through the WebGUI, as I only give the install team access to that. > > > Thanks > joe > > Joseph Boyer Jr. > Liquidnet Holdings, Inc. > E joseph.boyer(a)liquidnet.com > T +1 646.660.8352 > C +1 646.284.8394 > That's a good request. You could also use that to do audits by backing up the metadata. If you do this though I think you also want to keep track of the local users so the mtimes are not misleading. (Don't want webuser1 blamed for a change made by root this week when webuser1 edited it last month). If you did this too, you could also possibly but /var/lib/cobbler/config under version control and git-commit it to get RSS feeds of deltas. Can you file an RFE in Trac so we can remember this idea? (fedorahosted.org/cobbler ?) --Michael > > _______________________________________________ > cobbler mailing list > cobbler(a)lists.fedorahosted.org > https://fedorahosted.org/mailman/listinfo/cobbler > _______________________________________________ cobbler mailing list cobbler(a)lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler

1 0

koan - Xen enterprise
by Tom Brown 13 Nov '08

13 Nov '08

I know i asked this before in that currently koan cant be used to provision Xen Enterprise guests but is there any possibility this functionality would make it into a future release? thanks

2 1

[PATCH] more flexible cobblerd startup/logging config
by Charles Duffy 13 Nov '08

13 Nov '08

We use runit, a daemontools-alike init process which doesn't like processes to daemonize. cobblerd doesn't play well in this environment; the attached patch is one proposed fix, and also adds -h/--help and some customization to logging behavior to cobblerd. (runit and daemontools also prefer that processes log to stdout/stderr; allowing an arbitrary filename means that /dev/stdout is an option). This hasn't been well-tested -- and isn't slated for internal QA for a significant while -- but it seemed sensible to submit what I have rather than sitting on it interminably. Feedback welcome.

2 6

(devel) bonding patches
by Henry Kemp 13 Nov '08

13 Nov '08

I just checked out the most recent cobbler source code and did a "make devinstall" on the devel branch and got some strange behavior when I tried to follow Jasper's worked example for getting bonding working. I've pasted the cobbler commands I used below. cobbler system add --name=build-test1 --profile=CentOS-5.2-i386 cobbler system edit --name=build-test1 --interface=eth0 --mac=00:0c:29:27:2f:e2 --bonding=slave --bonding-master=bond0 cobbler system edit --name=build-test1 --interface=eth1 --mac=00:0c:29:27:2f:ec --bonding=slave --bonding-master=bond0 cobbler system edit --name=build-test1 --interface=bond0 --bonding=master --bonding-opts="mode=active-backup miimon=100" --ip=x.x.x.x --subnet=255.255.255.224 --gateway=y.y.y.y --static=1 * It looks as though the dhcp entries it creates are as follows (eg. no fixed-address entry so it won't get an IP address). host generic1 { hardware ethernet 00:0c:29:27:2f:ec; filename "/pxelinux.0"; next-server 172.16.33.69; } host generic2 { hardware ethernet 00:0c:29:27:2f:e2; filename "/pxelinux.0"; next-server 172.16.33.69; } * To get around this I tried specifying an IP address for eth0 and that then PXE booted ok but anaconda then crashed because the kickstart file cobbler created is referring to eth2 and eth3 for some reason. This is the relevant part of the rendered kickstart file. # Network information # Using "old" style networking config. Make sure all MAC-addresses are in cobbler to use the new-style config network $network_str --device=eth0 --onboot=on network --bootproto=static --ip=172.16.33.71 --netmask=255.255.255.224 --gateway=172.16.33.65 --device=eth1 --onboot=on network --bootproto=dhcp --device=eth2 --onboot=on network --bootproto=dhcp --device=eth3 --onboot=on * And this is the system configuration just to make sure there aren't any references to eth2 or eth3. # cobbler system dumpvars --name=build-test2 | egrep "eth|bond" 'bonding': '', 'bonding_bond0': 'master', 'bonding_eth0': 'slave', 'bonding_eth1': 'slave', 'bonding_intf0': '', 'bonding_master': '', 'bonding_master_bond0': '', 'bonding_master_eth0': 'bond0', 'bonding_master_eth1': 'bond0', 'bonding_master_intf0': '', 'bonding_opts': '', 'bonding_opts_bond0': 'mode=active-backup miimon=100', 'bonding_opts_eth0': '', 'bonding_opts_eth1': '', 'bonding_opts_intf0': '', 'dhcp_tag_bond0': '', 'dhcp_tag_eth0': '', 'dhcp_tag_eth1': '', 'gateway_bond0': 'y.y.y.y', 'gateway_eth0': '', 'gateway_eth1': '', 'hostname_bond0': '', 'hostname_eth0': '', 'hostname_eth1': '', 'interfaces': {'bond0': {'bonding': 'master', 'bonding_master': '', 'bonding_opts': 'mode=active-backup miimon=100', 'eth0': {'bonding': 'slave', 'bonding_master': 'bond0', 'bonding_opts': '', 'eth1': {'bonding': 'slave', 'bonding_master': 'bond0', 'bonding_opts': '', 'intf0': {'bonding': '', 'bonding_master': '', 'bonding_opts': '', 'ip_address_bond0': 'x.x.x.x', 'ip_address_eth0': 'x.x.x.x', 'ip_address_eth1': '', 'kernel_options': {'ksdevice': 'eth0', 'mac_address_bond0': '', 'mac_address_eth0': '00:0c:29:27:2f:e2', 'mac_address_eth1': '00:0c:29:27:2f:ec', 'static_bond0': 'True', 'static_eth0': 'False', 'static_eth1': 'False', 'subnet_bond0': '255.255.255.224', 'subnet_eth0': '', 'subnet_eth1': '', 'virt_bridge_bond0': '', 'virt_bridge_eth0': '', 'virt_bridge_eth1': '', I've not been able to dig into the bonding patches to work out why this is happening (assuming I'm not doing something wrong)! Rgds, Henry

3 4

(devel) internal storage of interfaces on system records & renaming
by Michael DeHaan 12 Nov '08

12 Nov '08

I'm sharing this because some folks were initially confused with why cobbler stored interfaces as "intf0" before instead of eth0 -- the reason was, before, we did not have code in place to ensure the order was described -- now we do. API users and folks who have triggers probably need to know about this. Cobbler 1.3.X will rename all interfaces named "intfN" to "ethN" to better accomodate the new "network auto setup code". It now does this, in fact. This change will happen on disk whenever an object is saved -- and will happen immediately on loading the objects into memory regardless -- so this is not something the user will have to do. The cobbler commands will work as follows: cobbler system edit --name=S1 --interface=0 --mac=AA:BB:CC:DD:EE:FF This creates or edits eth0 cobbler system edit --name=S1 --interface=eth0 --mac=AA:BB:CC:DD:EE:FF This (trivially) creates or edits eth0 cobbler system edit --name=S1 --interface=intf0 --mac=AA:BB:CC:DD:EE:FF For implementation reasons, this creates or edits eth0 also cobbler system edit --name=S1 --interface=foo0 --mac=AA:BB:CC:DD:EE:FF This creates an interface named foo0, since it's not named eth0, and is not a simple integer, cobbler will let it be whatever you want to name it, and will refer to it in Anaconda and /etc/sysconfig as such. If you have any API code (local or remote) expect to refer to interfaces named as "eth0" not "intf0". --Michael

1 0

Image Cloning Patches
by Bryan Kearney 12 Nov '08

12 Nov '08

Michael asked that I post a summary about the patches from yesterday. Here is a quick summary. The pacthes allow the user to import a pre-configured image (virtual appliance) into cobbler, and to provision it via koan. Outside of koan, the process would be something akin to: I) Create the appliance from a kickstart file using he appliance-creator [1] tool. This creates a raw image file and a virt-image xml [2] file which is the metadata about the appliance. II) Locate a VMWare appliance and convert it the virt-image file using the virt-convert [3]tooling. Again, this gives you a raw disk and appliance metadata in the form of an XML File. III) Install the appliance into your hypervisor of choice using virt-image tool. These patches allow the metadata in the appliance xml file (output of I or II) to be stored within cobbler. The mapping for this information is below. Koan then uses this data on the client machine to copy the image file and to install it using virt-image libraries. In effect, this is step III above. The process for this is then: A) Assume you have an image which is located on network accessable storage B) Add the image to cobbler using "cobbler add image -name FOO ..... " or one of the APIs. The image-type should be virt-clone. C) Using koan, deploy the image using a command such as "koan --server localhost --image base --virt --virt-path /tmp" D) During deployment, koan will create one NIC based on the new network_count attribute. These are filled either with bridges defined in the image or with the default network connection. The image type of "virt-clone" will tell koan to use the virt-image driver. The --virt-path argument says where to copy the image to locally.. since this is a clone. The --virt-type argument can be used, or virt-image will detect your hypervisor. I would like to see a tool which does all of step B based off of the existing xml file, but that is not written yet. I also noticed I need to add network_count to the cli add function. Any comments or concerns are appreciated. -- bk [1] http://www.thincrust.net/tooling.html [2] http://people.redhat.com/dlutter/kronolith-appliance/virt-image-xml.html [3] http://www.thincrust.net/tooling-conversion.html Mapping between Cobbler and virt-image xml =========================================== Cobbler :: Virt-Image-XML :: Notes CobblerImage.name :: image.name :: Overridden at command line CobblerImage.arch :: None :: Need to translate this since virt-image seems to use i686 not i386 CobblerImage.file :: image.domain.boot.drive | image.storage.disk@file :: What is lost is the ability to denote boot drives CobblerImage.parent :: None :: Not needed as this is internal cobbler logic CobblerImage.depth :: None :: Not needed as this is internal cobbler logic CobblerImage.owners :: None :: Not needed as this is internal cobbler logic CobblerImage.virt_ram :: image.domain.devices.memory :: CobblerImage.virt_file_size :: None :: CobblerImage.virt_path :: None :: Used to denote where to copy the image on the local filesystem CobblerImage.virt_cpus :: image.domain.devices.vcpu :: CobblerImae.network_count :: image.domain.networks :: CobblerImage.virt_type :: image.domain.boot@type | image.domain.boot.os.loader@dev :: See Issue 2 CobblerImage.virt_bridge :: :: Creates one nic on the guest for each entry CobblerImage.xml_file :: None :: No need to store the file, virt-image is called directlry CobblerImage.image_type :: virt-clone :: May need to break this down once we resolve the issues below CobblerImage.breed, :: None :: CobblerImage.os_version, :: None ::

2 6

(slightly OT) yum command guides
by Michael DeHaan 12 Nov '08

12 Nov '08

Seth Vidal wrote up some details on the various yum commands at the link below. When talking with various users, it's clear that a lot of folks could benefit more from knowing a bit more about some of the advanced tools/options available in yum, so you may find this useful. It may also help you to better understand a bit about what Cobbler is doing behind the scenes. http://yum.baseurl.org/wiki/Guides Cobbler reposync automates "/usr/bin/reposync" for the most part -- though it also supports rsync://. It also relies heavily on "createrepo" regardless of which mirroring mode you use. Furthermore, Cobbler also creates the yum config files for the installed system if yum_post_install_mirror is turned on in /etc/cobbler/settings. We also use yum repos for RHEL 5 and later to provide packages at installer time (so you don't have to wait until %post or later to install things). Read more about cobbler's automation of yum here: https://fedorahosted.org/cobbler/wiki/ManageYumRepos --Michael

1 0

[PATCH] Network count was accepting strings, and this caused issues with koan
by Bryan Kearney 12 Nov '08

12 Nov '08

--- cobbler/item_image.py | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/cobbler/item_image.py b/cobbler/item_image.py index 105432a..f9c53f0 100644 --- a/cobbler/item_image.py +++ b/cobbler/item_image.py @@ -138,7 +138,7 @@ class Image(item.Item): return utils.set_virt_cpus(self,num) def set_network_count(self, num): - self.network_count = num + self.network_count = int(str(num)) return True def set_virt_file_size(self,num): -- 1.5.6.5

1 0

Re: Allow for COBBLER_SERVER environment variable
by Robert Lazzurs 12 Nov '08

12 Nov '08

I do something similar in my kickstarts for the puppet server and I would suggest that is where this should be done. However if this does not work in your environment would the avahi service discover be an option? Take care. -- Rob Lazzurs On 12 Nov 2008, 3:40 PM, "James Laska" <jlaska(a)redhat.com> wrote: SNAKE writes out /etc/profile.d/snake.sh after each install to point back to the snake-server used by the client. I'd like to extend this for my cobbler kickstarts. A quick fix on the koan side would set the default --server value to the environment variable COBBLER_SERVER. Thoughts? Thanks, James _______________________________________________ cobbler mailing list cobbler(a)lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler

2 1

Illustrated changelogs (WIP) for Cobbler 1.3/1.4x
by Michael DeHaan 12 Nov '08

12 Nov '08

Hi everyone, Here's a breakdown of what's going into 1.3.X/1.4 so far: https://fedorahosted.org/cobbler/wiki/WhatsNewInThirteen This will give you a bit better idea of what's new and what to expect. Comments/questions welcome... I've tried to link to Wiki pages on specific features where they exist -- though I might have missed a few. If something isn't clear let me know and I'll update it. Thanks! --Michael

1 0

← Newer
1
...
5
6
7
8
9
10
11
12
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

cobbler November 2008