Support for bonding and other advanced networking topics
by Michael DeHaan
Just recently on IRC (join #cobbler on irc.freenode.net if you aren't
there already) we were discussing whether we could use Cobbler's concept
of interfaces to describe more complicated setups and then use a Cobbler
snippet called in %post to set everything up.
We initially were thinking we could describe an interface like this:
cobbler system edit --name=foo --interface=1 --bond-group=asdf
--bond-opts="a=1 b=2 ..." --bond-alias="..."
cobbler system edit --name=foo --interface=2 --bond-group=asdf
--bond-opts="a=2 b=3 ..." --bond-alias="..."
And the %post section snippet (this would be new) would insure that the
order of NICs booted is the same as those installed and everything is
configured. This would also set up things that Anaconda could not set up.
In the above example, eth1 and eth2 would be bonded as "asdf".
In the above proposal, I'd be willing to add the bits to Cobbler to
store the above kind of data, though I'd like for someone with more
networking skills to write the network configuration snippet.
We also talked a bit about IP "aliases" / VIPs and bridging. I will
admit at this point that networking is /not/ my area, so what are
everyone's thoughts to the implementation of the above?
What fields do we need to store to make this all possible to be defined
at provisioning time and "just work"?
--Michael
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
[PATCH] preliminary patch for template-files
by James Cammarata
Available via git hub: git://github.com/jimi1283/cobbler-template-files.git
I've done some testing on this, but I'm not sure if it's 100% so I'd like
for some others to play with it if they'd like. For those who don't follow
IRC, this patch allows for the templating of random config files via the
--template-files command. This command has the same syntax as the
ksmeta/kopts (space separated list) and honors the --in-place option.
Example:
cobbler profile edit --name test
--template-files="/path/to/template=/path/to/output"
Both the source and destination paths can have variables in them (ie.
$name, $arch, etc.), just don't forget to escape them if you're using
double quotes in the command. If the destination is not an absolute path,
the rendered file will be placed relative to /var/www/cobbler/rendered.
This is currently added on to distros/profiles/systems, though it should
probably be extended to images too.
Let me know if there are any questions/problems.
James C.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
15 years, 6 months
[PATCH] - importing debian based distros
by Javier Palacios
Hi,
I've started to work in order to allow debian provisioning with
cobbler. I send attached two patches.
The first on is actually not strictly related to debian, and it's a
reorganization of the archs management,
to simplify it and ease smooth addition of other distros: debian calls
amd64 to x86_64, and the idea is
to keep the RedHat names as canonical ones.
The second one does actually allow to import the content of a debian
CD/DVD and create the corresponding
distro. It also creates the profile breeded as debian, although it
might not be usable yet.
There are a couple of open questions that might affect other parts of
cobbler or where just ideas are required.
- the kickstarts for debian. They are called "preseed", and are by far
much more complex than a standard
kickstart. Although not strictly required, it might be better to
have new names for both ks files and directories,
but I think that they can be easyly added to PXE boot options. To
make things worst, ubuntu does allow both
the standard debian preseed and kickstart files.
- the package repositories. Debian follows a quite different approach,
and a single tree can hold many versions
and different architectures. Allowing a cobbler distro to have
multiple architectures might reduce the disk usage
and simplify the repository updating. Due to this fact, a single
debian media can install multiple archs, complexing
a little bit to import the media.
These are the only two points I see on the close horizon, but there
are probably more. It anyone has concerns
or ideas, they are welcome. And if anyone can actually test the
deployment (when it matures a little bit), much better.
Javier Palacios
15 years, 6 months
[PATCH 1/1] Fix config to disable restarting of dns-server
by mh
From: Marcel Haerry <haerry(a)puzzle.ch>
If you just "and" the string-variable it will always be true,
threfor we need to compare it as a string.
Signed-off-by: Marcel Haerry <haerry(a)puzzle.ch>
---
triggers/restart-services.trigger | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/triggers/restart-services.trigger b/triggers/restart-services.trigger
index 6eac017..38e94e7 100644
--- a/triggers/restart-services.trigger
+++ b/triggers/restart-services.trigger
@@ -33,7 +33,7 @@ if manage_dhcp != "0":
print "- error: unknown DHCP engine: %s" % bootapi.dhcp.what()
rc = 411
-if manage_dns != "0" and restart_dns:
+if manage_dns != "0" and restart_dns != "0":
if bootapi.dns.what() == "bind":
rc = os.system("/sbin/service named restart")
elif bootapi.dns.what() == "dnsmasq" and not has_restarted_dnsmasq:
--
1.5.5.1
15 years, 6 months
Best place to put extra files
by Chris O'Regan
I would like to distribute some post scripts via the Cobbler web server
and I am wondering where to place them. Any suggestions?
Looking at the man page, there is some mention of Kickstart tracking and
the "localmirror" directory. It would be great if I could use this to
track the progress of my post scripts. I am not certain how this works
or even if it is still available. Grepping through the source, I don't
see anything significant.
# rpm -q cobbler
cobbler-1.2.4-1.el5
Thanks,
Chris
15 years, 6 months
Failed to copy system
by Chris O'Regan
Hello,
I am trying to replicate with --include-systems, but I am getting this
error message:
# cobbler replicate --master=courage --include-systems
[...]
----- Copying Systems
Importing remote system pride.encs
image and profile are mutually exclusive (rhel-3-u9-i386,~)
Failed to copy system pride.encs
[...]
I do not see anything obvious in the log files. Any idea what this means
and how I can fix it?
# rpm -q cobbler
cobbler-1.2.4-1.el5
Thanks,
Chris
15 years, 6 months
(devel branch) new NIC editor panels in Cobbler Web, more networking details
by Michael DeHaan
John Eckersberg's recent patches allow cobbler to support multiple
arbitrary interfaces, each having their own name:
cobbler system edit --name=foo --interface=foosball
--mac=AA:BB:CC:DD:EE:FF --ip=192.168.10.50 #etc
In order to support this, I've had to overhaul the webapp some. The
new interface presents a select box ("drop down") of all of your interfaces
and lets you edit them one at a time. There is also a button to delete
the selected interface and to add one (after providing the name).
Testing on this would be much appreciated, though it seems pretty solid
at the moment.
This now opens up the possibility of adding additional parameters, such
as in support of the bonding use cases, as we can now support interfaces
with arbitrary names. If this is still desired we need (A) a list of
new parameters to "cobbler system add" that we would require, and (B)
upgrades to the $post_network_config snippet modification (on top of
what we already have in /var/lib/cobbler/snippets on the devel branch)
that understands these additional per-interface variables.
Also note that in the new editor there is a checkbox (and there is a CLI
field as well) for editing static interface details. This is leveraged
by the network_config snippet in $pre so your kickstart templates no
longer have to mention the networking details for which interfaces are
dhcp and which are static.
Longer term, we're going to have a first-class "network" object in
Cobbler, where we can make addition of new interfaces even easier by
assigning them to a network and have Cobbler manage their reservations
(optional) and/or static info. Of course the existing method will
still work.
Comments/questions?
After testing this feature, let's move forward with the other network
details, starting with the bonding options (still need input/consensus
on this, I think) and then moving towards the (optional) network object.
--Michael
15 years, 6 months
pre-install triggers not working
by Léon Keijser
Hi,
I noticed that triggers placed in /var/lib/cobbler/triggers/install/pre
aren't being executed. The same (very basic) trigger i created placed in
the install/post directory gets executed perfectly though.
regards,
Léon
15 years, 6 months
Profile Function without system Entry
by Mackell, Thomas O
I have a small problem.
Our current Cobbler setup works fine, with the exception of one item.
With some of our servers, we have to use the buildiso to create a bootable disk.
That's works fine, with the exception of the system profile not being used by the booting system.
It would appear that only the distro "profile" defined kickstart file is being used.
I noticed that the network devices do not get defined. Which make sense as there is no network devices in the profile, only the system profile has the devices.
The snippet returns nothing all blanks.
My setup has the high level profile with the kickstart file having the filesystems, software packages wanted...
The system profile would have the IP address/mac addresses, etc..
I figure I have forgotten something real basic, not sure at this point.
My first thought was to name the "system" the same as the mac address, as in 00:0d:04... That didn't appear to work, not sure on that either, yet if I show the rendered kickstart the devices are there as defined in the "system" entry. That's how I figured that the "system" entry is not getting used.
Is there a way I can supply the "system" profile from the server being rebuilt end? Or Do I have something else not set up right.
I am running cobbler-1.2.4-1 version, under RH V5.2 x86_64...
Thanks in advance,
Tom Mackell
15 years, 6 months
