cobbler October 2009

cobbler@lists.fedorahosted.org

32 participants
26 discussions

Getting rid of bad cobbler metavariables
by Adam Rosenwald 22 Jan '10

22 Jan '10

A FAQ that I have brought up on numerous occasions on IRC involves 'getting rid of bad cobbler metavariables'. If I were to set a wrong ks_meta variable NAME, how do I get rid of the NAME without taking out ks_meta entirely. E.g. `cobbler system add --name=NAME --ksmeta='arg0=val0 arg1=val1 *art2*=val2 ... argN=valN' ...` There are quite a number of scenarios where I don't want to remove all of ksmeta, but only a mistyped variable name. I have heard about the '!ARG' syntax: E.g. `cobbler system edit --in-place --name=NAME --ksmeta='*!art2*'` Supposedly this syntax will, upon deserialization of the JSON, clear the ks_meta namespace of *art2*; however, upon issuing a report on a given entity, the flawed variable will still appear along with the negated variable. I.e. ks_meta : 'arg0=val0 arg1=val1 *art2*=*val2* ... argN=valN *!art2*' For those who make use of this data for inventory or other purposes, the '!VAR' notation does not cut it. I would like a definitive explanation of how to remove bad metavariables irrespective of deserialization. Thanks, - A.

6 14

cobbler / koan - dhcp leases consumed
by Terry McIntyre 18 Dec '09

18 Dec '09

I wish to provision several virtual clients on a single virtual server. Tried the following: cobbler system add --name=test1 --profile=centos-5.3-xen-x86_64 --virt-type=xenpv --ip=192.168.62.75 --static=yes --subnet=255.255.254.0 --gateway=192.168.62.40 --virt-cpus=2 --virt-ram=4096 cobbler system add --name=test2 --profile=centos-5.3-xen-x86_64 --virt-type=xenpv --ip=192.168.62.76 --static=yes --subnet=255.255.254.0 --gateway=192.168.62.40 --virt-cpus=2 --virt-ram=4096 cobbler system add --name=test3 --profile=centos-5.3-xen-x86_64 --virt-type=xenpv --ip=192.168.62.77 --static=yes --subnet=255.255.254.0 --gateway=192.168.62.40 --virt-cpus=2 --virt-ram=4096 On the virtual server: koan --server=admin --virt --system=test1 koan --server=admin --virt --system=test2 koan --server=admin --virt --system=test3 Discovered failures during testing -- which eventually were traced to the exhaustion of all available DHCP client leases. Specifying the MAC address of the physical host fails. If I pick some other MAC address, how do I avoid picking one already in use? Is there a way to tell koan to begin the kickstart using a specified IP address, instead of acquiring the initial address via DHCP? -- Terry McIntyre UNIX for hire Software Development, Systems Administration, Security terry.mcintyre(a)gmail.com

2 2

Cobbler with IBM BladeCenter E and JS12 (Power6) blades
by Bryson Lee 30 Oct '09

30 Oct '09

Hi, I'm new to Cobbler, and am trying to set up provisioning for a group of JS12 blades using an i386 Dell server with Fedora 10 and the cobbler-1.6.6-1.fc10 RPM. There are, apparently, problems with NetworkManager activating the EHEA interfaces on JS12/JS22 blades, arising from updates needed in hal. See https://bugzilla.redhat.com/show_bug.cgi?id=496820, for example. I can get a blade to netboot by setting up a static IP address on eth0 through SMS, but eventually Ananconda gets into a loop failing to ifconfig the adapter to continue the installation. I'm curious if anyone has some suggestions on how to proceed. I've tried using `cobbler buildiso`, but the resulting image isn't bootable by the power6 systems. Thanks, -Bryson

1 0

mod_python error in web gui
by Léon Keijser 28 Oct '09

28 Oct '09

Hi, I've upgraded from cobbler 1.6.uh..6..i.think to 2.0.1. Running on Fedora 11 locally. Web gui looks slick, really nice work. Just every now and then (not always) i get a mod_python error. It happens for all menu items (systems, distro, profiles) and i can't seem to reliably reproduce it, other than saying it happens every now and then. Any ideas? MOD_PYTHON ERROR ProcessId: 18027 Interpreter: 'localhost.localdomain' ServerName: 'localhost.localdomain' DocumentRoot: '/var/www/html' URI: '/cobbler_web/system/list' Location: '/cobbler_web' Directory: None Filename: '/var/www/cobbler_web' PathInfo: '/system/list' Phase: 'PythonHandler' Handler: 'django.core.handlers.modpython' Traceback (most recent call last): File "/usr/lib64/python2.6/site-packages/mod_python/importer.py", line 1537, in HandlerDispatch default=default_handler, arg=req, silent=hlist.silent) File "/usr/lib64/python2.6/site-packages/mod_python/importer.py", line 1229, in _process_target result = _execute_target(config, req, object, arg) File "/usr/lib64/python2.6/site-packages/mod_python/importer.py", line 1128, in _execute_target result = object(arg) File "/usr/lib/python2.6/site-packages/django/core/handlers/modpython.py", line 228, in handler return ModPythonHandler()(req) File "/usr/lib/python2.6/site-packages/django/core/handlers/modpython.py", line 201, in __call__ response = self.get_response(request) File "/usr/lib/python2.6/site-packages/django/core/handlers/base.py", line 73, in get_response response = middleware_method(request) File "/usr/lib/python2.6/site-packages/django/middleware/common.py", line 56, in process_request if (not _is_valid_path(request.path_info) and File "/usr/lib/python2.6/site-packages/django/middleware/common.py", line 142, in _is_valid_path urlresolvers.resolve(path) File "/usr/lib/python2.6/site-packages/django/core/urlresolvers.py", line 303, in resolve return get_resolver(urlconf).resolve(path) File "/usr/lib/python2.6/site-packages/django/utils/functional.py", line 130, in wrapper result = func(*args) File "/usr/lib/python2.6/site-packages/django/core/urlresolvers.py", line 72, in get_resolver urlconf = settings.ROOT_URLCONF File "/usr/lib/python2.6/site-packages/django/utils/functional.py", line 273, in __getattr__ return getattr(self._wrapped, name) AttributeError: 'Settings' object has no attribute 'ROOT_URLCONF' -- Léon

5 6

PXE boot menus, per cobbler profile, is or is not possible?
by Mark Ellerby 28 Oct '09

28 Oct '09

Hi there, I have a load of machines that have PXE entries in /tftpboot/pxelinux.cfg/<ethernet address> which I can see get generated by cobbler from files in /etc/cobbler/pxe. Some magic happens within cobbler, so that from those template files, PXE boot files are generated. That's how I see it, and having looked through cobbler man pages, and the accumulated wisdom of "the internet", I am none the wiser as to how it does it. I would really like to be able to create different PXE boot files for different cobbler profiles. So that I can install a load of machines with, for example, profile=centos53, and another load with profile=fedora11, and have different PXE boot menus for these machines once they're installed, so I can boot them with PXE rather than Grub. I cannot work out whether this is possible or not. Could someone advise me of how to do this? Or, if it's not possible, just tell me so, so I am relieved of my mental turmoil. I hope I am not duplicated what other people have asked for. I have, as I say, done lots of looking around for my answers already. I do hope also that what I said above makes sense. Many thanks, Mark

1 0

Web UI PythonAuthenHandler Error after 2.0 Upgrade
by Pete Eby 27 Oct '09

27 Oct '09

Howdy all, I decided to update from 1.6 to 2.0 and have encountered the following odd error below when attempting to access the new Django web interface at cobbler_web. I've looked back through the mailing list but have not quite figured out what the deal is. (The error I'm getting is posted in full at the end.) I've updated /etc/cobbler/settings.rpmnew to /etc/cobbler/settings and /etc/cobbler/modules.conf.rpmnew to /etc/cobbler/modules The file /usr/share/cobbler/web/settings.py exists and is has permissions of the web server, etc. Restarting httpd and cobbler look fine: [root@cobbler conf.d]# /etc/init.d/cobblerd restart Stopping cobbler daemon: [ OK ] Starting cobbler daemon: SERVING! [ OK ] The Apache config file for the web ui looks okay: [root@cobbler]# cat /etc/httpd/conf.d/cobbler_web.conf # This configuration file enables the cobbler web # interface (django version) <VirtualHost *:80> # Do not log the requests generated from the event notification system SetEnvIf Request_URI ".*/op/events/user/.*" dontlog # Log only what remains CustomLog logs/access_log combined env=!dontlog <Location "/cobbler_web"> SetHandler python-program PythonHandler django.core.handlers.modpython SetEnv DJANGO_SETTINGS_MODULE settings # PythonOption django.root /cobbler_web PythonDebug On PythonPath "['/usr/share/cobbler/web/'] + sys.path" AuthBasicAuthoritative Off AuthType basic AuthName "Cobbler" Require valid-user PythonAuthenHandler cobbler_web.views </Location> </VirtualHost> Any hints? Thanks, Pete Eby * * * Mod_python error: "PythonAuthenHandler cobbler_web.views" Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line 287, in HandlerDispatch log=debug) File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line 464, in import_module module = imp.load_module(mname, f, p, d) File "/usr/share/cobbler/web/cobbler_web/views.py", line 1, in ? from django.template.loader import get_template File "/usr/lib/python2.4/site-packages/django/template/__init__.py", line 918, in ? add_to_builtins('django.template.defaultfilters') File "/usr/lib/python2.4/site-packages/django/template/__init__.py", line 915, in add_to_builtins builtins.append(get_library(module_name)) File "/usr/lib/python2.4/site-packages/django/template/__init__.py", line 904, in get_library mod = __import__(module_name, {}, {}, ['']) File "/usr/lib/python2.4/site-packages/django/template/defaultfilters.py", line 5, in ? from django.utils.translation import gettext File "/usr/lib/python2.4/site-packages/django/utils/translation/__init__.py", line 3, in ? if settings.USE_I18N: File "/usr/lib/python2.4/site-packages/django/conf/__init__.py", line 28, in __getattr__ self._import_settings() File "/usr/lib/python2.4/site-packages/django/conf/__init__.py", line 55, in _import_settings self._target = Settings(settings_module) File "/usr/lib/python2.4/site-packages/django/conf/__init__.py", line 83, in __init__ raise EnvironmentError, "Could not import settings '%s' (Is it on sys.path? Does it have syntax errors?): %s" % (self.SETTINGS_MODULE, e) EnvironmentError: Could not import settings '/usr/share/cobbler/web/settings.py' (Is it on sys.path? Does it have syntax errors?): No module named /usr/share/cobbler/web/settings.py

1 3

If I leave here tomorrow, would you still remember me?
by Michael DeHaan 27 Oct '09

27 Oct '09

Hello everyone, With apologies to Lynyrd Skynyrd, I am not actually leaving tomorrow. Though I must unfortunately say I am in fact leaving Cobbler-land and Red Hat to persue other exciting ventures in the land of software that I am interested in. I'll be around on and off throughout the end of the month. Folks, it has been an outstanding almost 4 years with Cobbler and everyone here. I hope you have had a lot of fun. Working with all of you online (and meeting folks at FudCONs, Tech Forums, BarCamps, and Summits) has been a fantastic experience that you just don't get most places. We've had people share Cobbler with LUGs and Conferences on multiple continents and even write magazine articles and chapters in books about us. Hundreds of folks have contributed ideas, code, testing, helped other users, helped market the project, and provided feedback. It is almost impossible to measure the userbase (since this is free software), but we know it is very very large and the world would most certainly implode without it (ok, perhaps not, but we can dream?). Everyone here on the mailing list helped make that possible by being a part of things. I can't say thanks to you enough. We've achieved a lot -- Now when someone starts a new Linux job, they don't have to write their own automation system -- they have one on the shelf that they know well, and maybe even helped build. Crazy complicated things like virtualization are hopefully simplified and annoying things like editing DHCP/DNS configurations and managing tons of repositories and kickstarts are hopefully made a lot faster and simpler. Folks have a simple place to store their deployment configuration that doesn't get in their way, and have lots of different ways to access it. As with many other open source management frameworks, we've shown that it's possible to collaborate across company boundaries and share infrastructure. This all can clearly carry on, and should also be the way more future projects like it are spawned and run ... by absorbing the good ideas of everyone in the user community, borrowing the features people have and like from their own in-house systems, and working with those users to build the software they want together. Collectively you are smarter than any one person or group, and that is why Cobbler works. The philosophy is very much "by sysadmins, for sysadmins" and is how we made sure Cobbler did the right thing and kept moving forward so fast. Except I am not really a sysadmin, I just play one on TV :) We have also shown, I hope, that simple software works, and there is a need for things that make things easy. We've kept our code simple on purpose -- to encourage any user to become a contributor. As time goes on, I expect things to get even more simpler and to see that contribution expand even farther. That is key to what we do. As I'm sure you are wondering, Cobbler will be left in good capable hands. It is being taken over by not one, but several folks -- including two frequent collaborators of mine -- Scott Henson and John Eckersberg from Red Hat IT. They'll be joined by Devan Goodwin (of Spacewalk/Satellite fame) and Alex Wood, also of Red Hat IT. They are all extremely sharp folks who care about Cobbler and community projects. We are meeting next week to get things transitioned over and put in proper gear -- and to figure out plans for future features and the 2.0.X and 2.2.X roadmaps. I'd call upon everyone here to be as awesome to them as they were to me, and continue to share the ideas you've had with them on this list and on places like #cobbler. Also, be sure to continue to help each other too, as you've been great at doing in the past. Again, thank you, and it has been an honor. Sincerely, Michael DeHaan ( contact info: michael.dehaan on gmail, http://michaeldehaan.net/ ) ==== Note 1 -- I'm not quite done yet, so I may still respond to a few more emails, bug reports and such :) Note 2 -- The official home of Cobbler remains at http://fedorahosted.org/cobbler and the source at git.fedorahosted.org. My personal github may not stay up to date (probably won't), so you if you have any external branches you might want to make sure they aren't forked off mine -- or otherwise that you frequently rebase off of git.fedorahosted.org. My copy will remain in place though.

14 13

Cobbler "push"?
by Glenn Bailey 26 Oct '09

26 Oct '09

Howdy, I was curious about doing a Cobbler "push" from a dev environment to a production environment. My dev env can push data out to production, but the production server can not sync back up to the dev env. Can I just rsync /var/lib/cobbler and /var/www/cobbler from the dev to production and restart cobblerd? Seems logical ;-) glenn terremark worldwide

2 2

Cobbler 2.0.1-1.el4 "dictionary key must be string" while adding an interface
by Andrew Rankin 23 Oct '09

23 Oct '09

Hello - I've been testing the newest version of Cobbler on EPEL testing (v2.0.1-1.el4) on our of my clusters, I upgraded the install from 1.6.6. After a little playing around I was able to get it to generally work, however I'm getting a "dictionary key must be string" while adding an interface to a system in the web interface - no issues adding one in the CLI though. Now if I add a network interface using the CLI I'm no longer able to save edits to the system in the web interface and get the error noted above (presumably because its trying to save the network settings). Ideas? ----------- The system is Centos 4.7 x86_64: Linux blah.blah.com 2.6.9-78.ELsmp #1 SMP Thu Jul 24 23:54:48 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux python-2.3.4-14.7.el4 Django-1.1.1-1.el4 httpd-2.0.52-41.ent.2.centos4 cobbler-2.0.1-1.el4 cobbler-web-2.0.1-1.el4 ----------- Thanks, Andrew

1 0

Rubygem-cobbler is unmaintained, path forward?
by Michael DeHaan 22 Oct '09

22 Oct '09

Daryl Pierce indicated to me today that rubygem-cobbler is unmaintained and is not going to be keeping up with the new Cobbler versions as ovirt is not needing the new features. As a result, I think there are several options (A) eliminate it altogether and those using it can use the XMLRPC APIs directly. (B) code-generate bindings from the source (I have started some work to do this for java, but results are TBD) (C) use something like Thrift for everything, and insert this between the XMLRPC layers and cobblerd (so the XMLRPC fork of cobblerd essentially just re-exposes what is available over Thrift, as a form of proxy-client to cobblerd). (D) find a new community owner for the package who wants to make it 2.0 compatible. In doing this, it should surface all cobbler objects and methods. I would generally think B and C might be better options in this case, but are non-trivial. I'm not going to be around to see this through, but thought it important to notify users of rubygem-cobbler, as it does appear in the listings when you do yum search. If we decide to eliminate this package, we should follow the Fedora process for orphaning and create the dead.package file and so forth. --Michael

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

cobbler October 2009