cobbler November 2008

cobbler@lists.fedorahosted.org

41 participants
119 discussions

Re: [Fwd: Re: Scalable Cobbler Architecture]
by Christopher Johnston 10 Nov '08

10 Nov '08

On Fri, Nov 7, 2008 at 9:27 AM, Christopher Johnston <cjohnston(a)ewtllc.com>wrote: > > Do you have any "image" objects in Cobbler? I have some changes in > cobbler's devel branch that > deal with pxegen.py and images. > > > This doesn't quite seem to make sense to me, because if the hostname is > not defined, > it's actually stored as an empty string. Do you see any tracebacks? Also > check > > Mike, Should I be importing a LiveCD as a cobbler image instead of as a distro/profile? I am not quite clear on how that works since I dont see anything added into /tftpboot to tell the host what to boot (no pxe file created even with --netboot=1). I can try to recreate the issue I was having with system records replicating again, I dont exactly recall what I had to do to fix it. Anyways here are the logs and the traceback I am getting from when the profile/distro replicates. Logs look clean to me.. root@xenguest01:/var/log/cobbler# tail -0f cobbler.log 2008-11-07 08:34:09,195 - remote - get_distros; user(?) 2008-11-07 08:34:10,723 - remote - get_repos; user(?) 2008-11-07 08:34:10,727 - remote - get_profiles; user(?) root@xenguest02:/# cobbler replicate --master=xenguest01.lax02.mtt --full-data-sync Failed to copy profile Fedora-9-LiveCD-x86_64. Importing remote profile Fedora-9-x86_64 'NoneType' object has no attribute 'arch' File "/usr/lib/python2.4/site-packages/cobbler/action_replicate.py", line 158, in replicate_data self.api.profiles().add(new_profile, save=True) File "/usr/lib/python2.4/site-packages/cobbler/collection.py", line 249, in add self.lite_sync.add_single_profile(ref.name) File "/usr/lib/python2.4/site-packages/cobbler/action_litesync.py", line 110, in add_single_profile self.sync.pxegen.make_pxe_menu() File "/usr/lib/python2.4/site-packages/cobbler/pxegen.py", line 210, in make_pxe_menu self.make_s390_pseudo_pxe_menu() File "/usr/lib/python2.4/site-packages/cobbler/pxegen.py", line 226, in make_s390_pseudo_pxe_menu if distro.arch == "s390x":

2 4

Repo sync question
by Jolynn Schmidt 07 Nov '08

07 Nov '08

I imported centOS 5.2 with the following commands a couple of months ago: cobbler import --path=rsync://pubmirrors.reflected.net/centos/5.2/updates/x86_64 --name=CentOS5.2updates cobbler import --path=rsync://pubmirrors.reflected.net/centos/5.2/os/x86_64 --name=CentOS5.2os cobbler import --path=rsync://pubmirrors.reflected.net/centos/5.2/centosplus/x86_64 --name=CentOS5.2osplus Now I want to update CentOS5.2updates with the latest set of RPMS from the mirror. Reposync does not work since it is not considered a repo, what is the proper cobbler way of doing this? Thanks Jolynn ________________________________ This e-mail and its attachments are intended only for the individual or entity to whom it is addressed and may contain information that is confidential, privileged, inside information, or subject to other restrictions on use or disclosure. Any unauthorized use, dissemination or copying of this transmission or the information in it is prohibited and may be unlawful. If you have received this transmission in error, please notify the sender immediately by return e-mail, and permanently delete or destroy this e-mail, any attachments, and all copies (digital or paper). Unless expressly stated in this e-mail, nothing in this message should be construed as a digital or electronic signature.

2 1

generating mac's for Xen vm's
by Tom Brown 07 Nov '08

07 Nov '08

Is there a way to 'generate' a random mac for a Xen guest apart from using the GUI ? I want to pretty much script the deployment of a Xen host and along with it deploy 20 domU's in 1 swoop - Is there a way to ask cobbler for a bunch of mac's without using the GUI? thanks

5 8

cobbler-1.2.8-1.fc9.noarch - dual homed - tftp issue
by Tom Brown 07 Nov '08

07 Nov '08

Hi I am setting up a new cobbler box and for this test the box is Fedora 9, it also has 2 networks, 1 on the LAN and 1 on a 'lab' network in that there are only 2 things on this network and that is the cobbler server and the client connected with a switch. When i boot the client it gets an IP via DHCP but then just sits there for a few seconds until it stops with a TFTP open timeout - nothing at all is shown on the server after the DHCP request. Nov 6 16:49:10 xxxxxx dhcpd: Sending on Socket/fallback/fallback-net Nov 6 16:49:31 xxxxxx dhcpd: DHCPDISCOVER from 00:21:5a:10:3a:96 via eth1 Nov 6 16:49:31 xxxxxx dhcpd: DHCPOFFER on 192.168.11.2 to 00:21:5a:10:3a:96 via eth1 Nov 6 16:49:35 xxxxxx dhcpd: DHCPREQUEST for 192.168.11.2 (192.168.11.1) from 00:21:5a:10:3a:96 via eth1 Nov 6 16:49:35 xxxxxx dhcpd: DHCPACK on 192.168.11.2 to 00:21:5a:10:3a:96 via eth1 Thats all - i have disable = no in my xinetd.d/tftp and i have reloaded xinetd - There is no firewall running on the server. In my settings i have the 'lab' IP of the server and this seems fine as its getting a DHCP address. Below is my dhcp template ddns-update-style interim; allow booting; allow bootp; #if $omapi_enabled omapi-port $omapi_port; #end if ignore client-updates; set vendorclass = option vendor-class-identifier; subnet 192.168.11.0 netmask 255.255.255.0 { option routers 192.168.11.1; option subnet-mask 255.255.255.0; option domain-name-servers 10.5.216.215, 10.5.216.216; filename "/pxelinux.0"; default-lease-time 21600; max-lease-time 43200; next-server $next_server; } and here is the bit from dhcpd.conf that cobbler generates # group for Cobbler DHCP tag: default group { host testbox { hardware ethernet 00:21:5A:10:3A:96; fixed-address 192.168.11.2; option subnet-mask 255.255.255.0; option routers 192.168.11.1; filename "/pxelinux.0"; next-server 10.50.16.179; } any ideas ?? thanks

2 9

Scalable Cobbler Architecture
by Christopher Johnston 07 Nov '08

07 Nov '08

Does Cobbler currently support a more scalable architecture? I would like the idea of keeping a centralized Cobbler server that contains all of the meta-data records for our systems, distros and profiles (could also house the golden copies of our repos we want distributed to remote sattelites). If the "master" cobbler instance gets a new record for a system, when a cobbler sync is ran having it sync the changes out to a remote sattelite that is sitting in a different datacenter/region would make global management of our provisioning environment scalable. As well as managing our servers as a whole alot more convenient. My concern is that we dont want to have multiple cobbler servers running in every datacenter with different configurations, system, distros and profile records. You could also get into ACL'ing certain repositories for different datacenters and networks (ie, lab networks only see development repositories and production networks only see production repositories). If this is something thats possible today, thats great! If not what are some thoughts around this topic. Thanks, Christopher Johnston Senior Systems Enginer, IT EWT, LLC | Madison Tyler, LLC e: cjohnston(a)ewtllc.com

2 6

(devel) Performance under 1.3.X with a very large number of systems
by Michael DeHaan 06 Nov '08

06 Nov '08

I've been asked before how well Cobbler scales for a very large server farm on several occassions, but it's been a while since I've talked about numbers in depth. As recent test upgrades have changed the way some internals are handled, I wanted to rebenchmark the code. It turns out that for what I'd call an easy 95% or more of the /potential/ Cobbler user base, we're doing awesome and no changes are needed. However, it's worth exploring what some of the limits are. Note that the performance limits of Cobbler really are small -- it's largely about how fast we can read our configuration in memory, compute potential conflicts, and save it back. Easy stuff. Most of the load actually hits Apache. And honestly, most of these questions probably would not have come up if we were database backed by default -- though being databased backed has other disadvantages in terms of updates and maintaince pain. So, some data: On my laptop (2 GB RAM, ~2 GHz), using serializer_catalog (the default module in Cobbler for new installs in 1.2) Time to add or edit 1000 systems via the API -- ~8 seconds Time to add 10,000 systems via the API -- ~115 seconds Time to edit 10,000 systems via the API -- ~95 seconds With 10,000 systems: time cobbler system list -- ~64 seconds time cobbler distro list -- ~64 seconds Basically this shows that you pay for access largely up front when accessing the objects. It's (almost) linear. The linear performance is important... one common scenario is if we want to reprovision a very large block of systems and that block of systems is set to PXE first in the BIOS order, and we have pxe_just_once enabled -- we want edits made by mod_python to be very fast so we can attend to all the systems as they check in to disable their PXE (and also run triggers) Additionally: time to view the distro list page -- ~60 seconds time to view the page for a single distro -- just a couple of seconds I know I've danced around including a database-backed serializer before (my main concern is the lack of an upgrade path for existing installations -- though cobbler replicate should be good enough), though I believe we can get this down if needed. The trick will be making sure the code throughout cobbler uses api.find_* as much as possible and functions like api.distros() and api.systems() as little as possible. If you have more than 1000 systems in Cobbler, I want to hear from you (off list is fine). Performance in the 3000 or so system range seems decent. While I also want to make the WebUI usable for very large numbers of systems (offering built-in search was an item I initially planned for 1.3), it would seem we'd want to persue the serializer first so we can access the WebUI faster. I also seem to think a very large number of folks with a large number of systems would be content to do things like: cobbler system add --name=foo --ip=192.168.0.0./24 --profile=x And in that case rather than defining all systems you can assign certain machines to certain profiles using CIDR notation. Also for large server installations, usage of cobbler replicate can be helpful.... all system records don't have to be replicated from a central server. Anyhow, it's a recurring theme -- but if anyone has any requests about performance or managing large numbers of systems please bring those items up. It will probably effect what we want to do for the next release. Comments? Do we need to soup this up some, or are most people ok with the above? --Michael

2 2

RFE: Record Timestamps
by Christopher Johnston 06 Nov '08

06 Nov '08

Possible feature request would be to put some stats on objects that are loaded into cobbler for the following: * timestamp of when the distro/profile/system records were added into cobbler * timestamp of when the distro/profile/system records are last updated (modified) in cobbler Christopher Johnston Senior Systems Engineer, IT EWT, LLC | Madison Tyler, LLC e: cjohnston(a)ewtllc.com

2 1

(devel) more XMLRPC tests, and potentially better XMLRPC examples
by Michael DeHaan 05 Nov '08

05 Nov '08

I've added (and am still working on) a fair amount of XMLRPC tests at the bottom of remote.py. For those that are curious about how to use the XMLRPC interfaces in either read-only or read-write mode, those examples may be easier to follow than CobblerWeb.py. It shows how to log in, create objects remotely, modify them, and rename/copy/delete them -- this is useful not only for remote apps but also non-Python apps that can't use the Python API -- so they don't have to parse cobbler's command line (which would be a bad idea for numerous reasons that should be self-evident). The XMLRPC code is all solid (since CobblerWeb uses it), though this can ensure we can make changes to cobbler without having to do as much manual testing. Automated tests for the import code are next on the list. I have an advantage of having a very large NFS server full of trees to pull from, though I'll try to find a way to make a config file that allows other users to run the same tests more easily. Since the feature requests have started to die down, I think we're getting pretty close to being able to have a test release -- which should come out next week. Since I /do/ want to have move test code in before then however (including tests on the URLs cobbler serves as well), we probably wont' release right on that mark, however. Having more automated tests means we can also update stable releases faster when we /do/ hit bugs so I want that infrastructure in place first. --Michael

1 0

Deploying images via koan and virt-image
by Bryan Kearney 05 Nov '08

05 Nov '08

Michael: Looks like there is no current support for doing images via virt-image. Is that correct? If so... are you open to looking at that type of integration? -- bk

2 15

Strange behaviour after cobbler import
by Mark Brandis 05 Nov '08

05 Nov '08

Hi! I have a strange problem after a cobbler import. I do the following: cobbler import --arch=i386 --path=/mnt/cdrom --name=foo This works without problems. When I want to install with pxe after that command finishes the boot stops after the pxe lines with the error: unable to locate configuration file A "cobber sync" on the command line does not help, a sync in the webui makes the problem go away. Strange!?! Mark

2 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

cobbler November 2008