Cobbler and Templating/Built In Config Mgmt
by Harry Hoffman
Hi All,
I'm starting to look at the built in Config Mgmt with templates for
situations where cfengine/puppet cannot (for whatever reasons) be used.
I guess the first thing that came to mind is to have a default location
for templates so that it would be available via variables to cobbler.
Seems like: /var/lib/cobbler/templates might be a good choice, any thoughts?
We do things (maybe a bit) different so I don't know if something as
generic as webserver.template might work... but we could certainly take
a standard httpd.conf file and replace all of the things you'd normally
fill in with variables defined via ksopts (or some other mechanism).
I'm trying to come up with some real world examples and would appreciate
any ideas you might have.
In cfengine, we do simply things like replace "#ServerName
www.example.com:80" with "ServerName www.my.tld:80". Perhaps this works,
perhaps it doesn't. As a small scale config-mgmt system I think it would
work for us, but would it work for anyone else?
We'd also use func, and func-inventory to trac changes over time...
func-inventory creates a file-tracker directory in each system repo so
I'm guessing that we can use it to at least allow for browsing of changes.
Also, if your backup system is a large as our's then you realize it can
sometimes take a long time to pull stuff off of the backup server and
compare.
Using a file tracker would allow us to check the repo 1st and then move
on to the backup tapes afterward.
I'd appreciate any thoughts, criticisms, suggestions that you might have.
I also would love to see some real world examples that ppl might have.
I'm happy to share ours, in a personally redacted way.
Cheers,
Harry
15 years, 6 months
remove options in kopts
by Shuichi Ihara
Hi,
We can add or modify kernel options to --kopts="..." by "edit"
command, but how can I remove that options from --kopts=""?
Thanks
-Ihara
15 years, 6 months
Symbolic-Func-Cobbler Integration
by Marco Mornati
Hello everybody,
we are starting developing a complete integration from this three
technologies: Symbolic, Func and Cobbler, and we want to have any
comments from you, suggestions about our plan of implementation and/or
help for developing! ;)
Here is shown a "use case" to explain our "integration" idea.
Inside Symbolic (so inside you browser) you can create a new "Machine"
that you have just attached to your network. You need to configure
"hardware" on that machine (fence device for example), so you can choose
"hp fence device" and func (with a fence-module) know which is the
command to startup-shotdown machine with "hp fence device".
After this step you have a "cobbler configuration console", that is
something like actual cobbler console, where you can choose cobbler
configuration for you machine: distro, kickstart information, packages
to install ecc. ecc., flag to choose "func installation on machine" and,
in this case, you need to select a certmaster for that machine (who is
the controller for the newest machine).
Submitting all this data I'll start machine (using func-fence module)
and installation will begin (in future we may produce something that
shown on webpage the installation progress).
When all will be ready you will receive on web interface (in symbolic) a
message from certmasterX (the one where you have attached your new func
minion) whith message: "I receive a new certificate from this machine,
do you want to sign this one"... so you can run (from xmlrpc calls from
symbolic to certmaster) you certificate (cartmaster-ca --sign hostname)
and then you could see your machine in symbolic and you can control it.
Another step will be provisioning for "virtual machine" (using koan)
where you need to do something like previous steps but you will see on
your web-browser (via a java applet?) a vnc connection to your virtual
machine installation.
This is the start point for integration... but the final result shoud be
something like: I've many new servers, I configure one with
cobbler/symbolic and then I could create all my network using browser!
Comments?
Bye
Marco
--
Dott. Ing. Mornati Marco
Byte-Code s.r.l
via Antonio Cechov, 1
San Giuliano Milanese (MI)
E-Mail: mmornati(a)byte-code.com
15 years, 6 months
Re: More details on system imaging -- livecd based proposal
by Andrew Brown
Michael,
I made a few changes to my script. I changed the kernel parameter from
being "save" or "load" to "cloneraction=save" or "cloneraction=load". That
way it inherits properly with cobbler profiles and such.
Testing things out, it seems to work very well with cobbler. I have my
distro set up with the basic kernel parameters:
rootflags=loop rootfstype=iso9660 root=/cloner-live-cd.iso
The profile is per image. So I set my profile parameters to this:
cloneraction=load image=blade13 nfs=10.10.10.1:/export drive=/dev/sda
And then for each system that should have that image, I just assign it to
that profile. If I want to load an image, I just netboot it. If I want to
save an image, I set cloneraction=save for the system and then netboot it.
Of course, that's only one way to do it. I believe what you described on
the wiki was slightly different but still works. That's what I like about
this.
Two things:
First, how can I get netboot to go back to disabled after an image is
loaded/saved?
And second, I changed the script to restart automatically when done, but the
shutdown procedure seems to hang on the "Turning off quotas" step. Any
ideas why it doesn't go ahead an restart there? I'm looking into it, just
wondering if you've seen this before or something.
-Andrew
On Wed, Sep 17, 2008 at 12:03 PM, Andrew Brown <ambrown4(a)ncsu.edu> wrote:
> Here's my latest version of my build script (it's GPL), as well as a SRPM I
> built for partimage-ng.
>
> The script takes arguments from the kernel parameters. Here's my append
> line for a PXE boot:
>
> APPEND initrd=initrd0.img root=/cloner-live-cd.iso rootfstype=iso9660
> rootflags=loop nfs=10.10.10.1:/export image=blade13 drive=/dev/sda save
> ONERROR LOCALBOOT 0
>
> Note, I haven't actually tried this version since I built partimage-ng into
> an rpm, but it should work. I just haven't had time yet to try it.
> -Andrew
>
>
> On Thu, Sep 11, 2008 at 9:21 PM, Andrew Brown <ambrown4(a)ncsu.edu> wrote:
>
>>
>>
>> On Thu, Sep 11, 2008 at 9:03 PM, Michael DeHaan <mdehaan(a)redhat.com>wrote:
>>
>>>
>>> I think trying to do this securely in the NFS realm is going to be
>>> difficult if not impossible, indeed.
>>>
>>> Maybe we just document it with scary blinking lights on the page that
>>> (when using this feature) it's very easy to replace disk images without
>>> hosts.allow, hosts.deny, /etc/exports, and/or iptables locked down to
>>> specify what machines can write to that NFS share. The vulnerability
>>> is the option to replace someone's partition before they clone it to
>>> lots of other machines, basically injecting new content. However if
>>> this is limited such that only machines in the datacenter can access
>>> this content, then the problem becomes ensuring users can't access
>>> /those/ machines.
>>>
>>> Doing any sort of better locked down NFS install is a huge problem for
>>> rw NFS, especially when the user is a CD -- we can't just stick the
>>> password in the cloner image as the cloner image is public.
>>>
>>> Other proposals welcome, perhaps ok for now.
>>>
>>> Naturally since this NFS feature is not available until someone turns it
>>> on and so configures their cloner images, we aren't exposing a
>>> vulnerability in a place where users can't see that message about
>>> limitations -- they'll know the implications when using the feature.
>>>
>>> This may in fact be fine for most secured lab setups, just definitely
>>> not something you'd want on an open college network.
>>>
>>> --Michael
>>>
>>>
>> I was thinking of some setup with ssh and host keys, but any host key
>> would need to be on the livecd image itself. I can't think of a good way to
>> secure this system, NFS or not. I suppose it's okay if this feature is only
>> practical inside of a secure lab setup though.
>>
>>
>>
>>
>
15 years, 6 months
Koan appears to ignore --kopts
by Ronald J. Yacketta
Hello all!
Finally have cobbler setup and running :) Set off to-do several koan
(xenpv) installs today and noticed that the 'kernel Options' listed in
one of my profiles did not make its way into grub.conf.
Here is the cobbler profile in question
profile : f9-xen-i386
distro : f9-xen-i386
dhcp tag : default
kernel options : {'console': ['ttyS1,57600', 'tty1']}
post kernel options : {}
kickstart : /etc/cobbler/fc9.ks
ks metadata : {}
owners : ['admin']
repos : []
server : <<inherit>>
virt bridge : eth0
virt cpus : 1
virt file size : 30
virt path :
virt ram : 1024
virt type : xenpv
Here is what my grub.conf looks like after koan / kickstart:
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Fedora (2.6.25.3-2.fc9.i686.xen)
root (hd0,0)
kernel /vmlinuz-2.6.25.3-2.fc9.i686.xen ro
root=/dev/VolGroup00/LogVol00 rhgb quiet
initrd /initrd-2.6.25.3-2.fc9.i686.xen.img
title Fedora (2.6.25-2.fc9.i686.xen)
root (hd0,0)
kernel /vmlinuz-2.6.25-2.fc9.i686.xen ro
root=UUID=024248f7-4042-4a54-874e-512ecbf871d5 rhgb quiet
initrd /initrd-2.6.25-2.fc9.i686.xen.img
Also,
has anyone ran into the following error when setting up the cobbler
server to be on 3 VLAN's and restricting apache to Listen to a specific IP?
[Wed Oct 08 10:52:48 2008] [error] field op
[Wed Oct 08 10:52:48 2008] [error] adding op to ks
[Wed Oct 08 10:52:48 2008] [error] field profile
[Wed Oct 08 10:52:48 2008] [error] adding profile to f9-i386
[Wed Oct 08 10:52:48 2008] [error] [client 137.143.212.33] mod_python
(pid=29995, interpreter='eden.potsdam.edu', phase='PythonHandler',
handler='services'): Application error
[Wed Oct 08 10:52:48 2008] [error] [client 137.143.212.33] ServerName:
'eden.potsdam.edu'
[Wed Oct 08 10:52:48 2008] [error] [client 137.143.212.33] DocumentRoot:
'/var/www/html'
[Wed Oct 08 10:52:48 2008] [error] [client 137.143.212.33] URI:
'/cblr/svc/op/ks/profile/f9-i386'
[Wed Oct 08 10:52:48 2008] [error] [client 137.143.212.33] Location: None
[Wed Oct 08 10:52:48 2008] [error] [client 137.143.212.33] Directory:
'/var/www/cobbler/svc/'
[Wed Oct 08 10:52:48 2008] [error] [client 137.143.212.33] Filename:
'/var/www/cobbler/svc/op'
[Wed Oct 08 10:52:48 2008] [error] [client 137.143.212.33] PathInfo:
'/ks/profile/f9-i386'
[Wed Oct 08 10:52:48 2008] [error] [client 137.143.212.33] Traceback
(most recent call last):
[Wed Oct 08 10:52:48 2008] [error] [client 137.143.212.33] File
"/usr/lib/python2.5/site-packages/mod_python/importer.py", line 1537, in
HandlerDispatch\n default=default_handler, arg=req, silent=hlist.silent)
[Wed Oct 08 10:52:48 2008] [error] [client 137.143.212.33] File
"/usr/lib/python2.5/site-packages/mod_python/importer.py", line 1229, in
_process_target\n result = _execute_target(config, req, object, arg)
[Wed Oct 08 10:52:48 2008] [error] [client 137.143.212.33] File
"/usr/lib/python2.5/site-packages/mod_python/importer.py", line 1128, in
_execute_target\n result = object(arg)
[Wed Oct 08 10:52:48 2008] [error] [client 137.143.212.33] File
"/var/www/cobbler/svc/services.py", line 86, in handler\n content =
func( **form )
[Wed Oct 08 10:52:48 2008] [error] [client 137.143.212.33] File
"/usr/lib/python2.5/site-packages/cobbler/services.py", line 76, in
ks\n self.__xmlrpc_setup()
[Wed Oct 08 10:52:48 2008] [error] [client 137.143.212.33] File
"/usr/lib/python2.5/site-packages/cobbler/services.py", line 61, in
__xmlrpc_setup\n self.remote.update()
[Wed Oct 08 10:52:48 2008] [error] [client 137.143.212.33] File
"/usr/lib/python2.5/xmlrpclib.py", line 1150, in __call__\n return
self.__send(self.__name, args)
[Wed Oct 08 10:52:48 2008] [error] [client 137.143.212.33] File
"/usr/lib/python2.5/xmlrpclib.py", line 1440, in __request\n
verbose=self.__verbose
[Wed Oct 08 10:52:48 2008] [error] [client 137.143.212.33] File
"/usr/lib/python2.5/xmlrpclib.py", line 1186, in request\n
self.send_content(h, request_body)
[Wed Oct 08 10:52:48 2008] [error] [client 137.143.212.33] File
"/usr/lib/python2.5/xmlrpclib.py", line 1300, in send_content\n
connection.endheaders()
[Wed Oct 08 10:52:48 2008] [error] [client 137.143.212.33] File
"/usr/lib/python2.5/httplib.py", line 856, in endheaders\n
self._send_output()
[Wed Oct 08 10:52:48 2008] [error] [client 137.143.212.33] File
"/usr/lib/python2.5/httplib.py", line 728, in _send_output\n
self.send(msg)
[Wed Oct 08 10:52:48 2008] [error] [client 137.143.212.33] File
"/usr/lib/python2.5/httplib.py", line 695, in send\n self.connect()
[Wed Oct 08 10:52:48 2008] [error] [client 137.143.212.33] File
"/usr/lib/python2.5/httplib.py", line 679, in connect\n raise
socket.error, msg
*[Wed Oct 08 10:52:48 2008] [error] [client 137.143.212.33] error: (111,
'Connection refused')
*-Ron
15 years, 6 months
koan livecd issue
by mathias.herzog＠postfinance.ch
Hi
Since the upgrade to koan-1.2.5-1.el5, I get some a really odd grub.conf using koan livecd feature
[...]
title kick1223468404
root (hd1,0)
-> kernel inuz root=/ nostorage ksdevice=eth0 ...
initrd.img
-> initrd trd.img
[...]
I'm booting the livecd from a virutal cdrom device and there is a usb stick plugged in. So the device special of the usb stick is /dev/sda1
The problem is caused from the follwing entry in app.py, line 695
[...]
cmd.append("--boot-filesystem=/dev/sda1")
[...]
This command adds --boot-filesystem=/dev/sda1 to grubby and leads to the strange grub.conf since sda1 is not my livecd..
Without the "boot-filesystem" option, everything would be ok.
Basically, the only option I need is "--bad-image-okay". Would it be possible to extend koan with a new option or let koan fiugure out the correct device instead of hardcoding /dev/sda1?
Regards Mathias
Sicherheitshinweis:
Dieses E-Mail von PostFinance ist signiert. Weitere Informationen finden Sie unter:
https://www.postfinance.ch/e-signature.
Geben Sie Ihre Sicherheitselemente niemals Dritten bekannt.
15 years, 6 months
Using "rhnget" with cobbler
by Chris O'Regan
Looking at the source of action_reposync.py, it seems relatively easy to
replace "reposync" with "rhnget" (from mrepo) in the section that
mirrors from RHN. Having said that, I wonder if others would find this a
useful feature.
If so, I would be willing to write a patch however I will need some
guidance as to how to implement this. First, we need a way of telling
cobbler to use rhnget instead of reposync. Second, rhnget needs the path
to the systemid file for this particular repo. Since there are already
restrictions on the name of the repo, this path can possibly be
hard-coded. Third, it might be desirable to pass options to rhnget, such
as "--download-all". Should this be global or per repo or both? Fourth
and finally, rhnget provides a "--filter" which could provide the
functionality of "rpm-list" (though it expects a regex).
Is there any interest?
Chris
15 years, 6 months
Update on --template-files support
by Michael DeHaan
For those following the devel branch, I've added the bits to koan to
allow koan to pull down files and keep them updated.
This is all rather rough/experimental at this point, so I'd welcome
suggestions for upgrades.
I described this a bit more here: http://www.michaeldehaan.net/?p=741
The key part is the new syntax that allows a system to request new
config files be dynamically re-generated and downloaded:
|
koan --update-files --server=cobbler.example.org --system=hostname
|
--Michael
15 years, 6 months
Managing debian repos
by Javier Palacios
Hello,
I send attached a couple of patches to prepare the addition of debian
repositories.
The first one is a modification to item_repo, to add a breed name to
the repo. Currently
it is just "redhat", but as fas as I see, in the mid term should be
moved to something
like ( rsync | rhn | yum | apt ).
The second one changes action_reposync, reorganizing some methods and including
a couple of classes to manage specific repo types.
I've run `make test` and tried against a real f9 updates repository
with success.
I've not started to work with real debian repos yet, but as far as I
see, now any debian
related change will be completelly isolated from redhat workflow.
Javier Palacios
15 years, 6 months
FYI: cobbler reposync and Fedora 9
by Michael DeHaan
There's a bug in /usr/bin/reposync in Fedora 9 that gives an error when
using cobbler to synchronize an http (and possibly other types) of repo.
If you are running Cobbler and have cobbler repo objects on that
platform, the newer reposync is in updates-testing but is not in
"updates" yet.
To get the new version:
# yum update yum-utils --enablerepo-updates-testing-newkey
--Michael
15 years, 6 months
