Getting rid of bad cobbler metavariables
by Adam Rosenwald
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.
14 years, 2 months
cobbler / koan - dhcp leases consumed
by Terry McIntyre
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
14 years, 3 months
Cobbler with IBM BladeCenter E and JS12 (Power6) blades
by Bryson Lee
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
14 years, 5 months
mod_python error in web gui
by Léon Keijser
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
14 years, 5 months
PXE boot menus, per cobbler profile, is or is not possible?
by Mark Ellerby
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
14 years, 5 months
Web UI PythonAuthenHandler Error after 2.0 Upgrade
by Pete Eby
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
14 years, 5 months
If I leave here tomorrow, would you still remember me?
by Michael DeHaan
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 years, 5 months
Cobbler "push"?
by Glenn Bailey
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
14 years, 5 months
Cobbler 2.0.1-1.el4 "dictionary key must be string" while adding an interface
by Andrew Rankin
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
14 years, 5 months
Rubygem-cobbler is unmaintained, path forward?
by Michael DeHaan
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
14 years, 5 months