[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
Proposed change in behavior for --netboot-enabled=0/1, pxe_just_once
by Michael DeHaan
When pxe_just_once is enabled, Cobbler is smart enough to remove the
per-mac-address PXE config file of a system once it is installed to
prevent infinite PXE boot loops.
Currently Cobbler does this by removing the TFTP config file for that
particular MAC address, falling back to whatever is the default. But
what happens if your default system is configured, as in something like
this:
cobbler system add --name=default --profile=default-profile OR
cobbler system add --name=192.168.0.0./24
--profile=default-profile-for-network
You'd reinstall that system.
It's been suggested that a better behavior for this is to change the
template the system uses and save it instead as a PXE config that
explicitly local boots the system.
I can't see this breaks anyone but I figured it would be important
enough to mention here. (If it does, let me know, and we can talk
about making a config option, otherwise I'm not going to worry about it).
This will be included in 1.2
--Michael.
15 years, 7 months
More details on system imaging -- livecd based proposal
by Michael DeHaan
I've been talking with Andrew Brown from NCSU, and we have some ideas on
how to implement a cobbler imaging solution utilizing livecd's and
partimage. He's going to be taking a crack at implementing this for a
future cobbler release. I've included basic details here so others
could see what we are thinking and weigh in. The use case is for the
Virtual Compute Lab (http://vcl.ncsu.edu/) though this should be
extensible to any other place that needs to clone images and might have
mixed Linux/other deployments. Naturally, if you can do kickstart (or
preseed, or autoyast, or ...), it's always preferable to do kickstart
(or equivalents) -- maintaining security updates on images and so forth
and dealing with hardware differences is an additional layer of complexity.
This is somewhat based around some capabilities of IBM's xcat, though
we're going to rework it to make it work idiomatically in cobbler where
there is much less setup involved.
The following instructions assume pxe_just_once is turned on in
/etc/cobbler/settings and the systems PXE first in BIOS order. That
makes some things simpler as the live images can simply reboot when done.
The idea/syntax is as follows:
# from a base of the imported RHEL5 distro, use livecd-tools to create a
livecd and convert it to a PXE-able image.
# this livecd image will contain a post script that uses partimage to
export partitions to a configured NFS share (in cobbler)
# and/or load the image based on kernel arguments configured via flags
below.
cobbler distro make-cloner --name=RHEL5-cloner --distro=RHEL5
# here we make a profile for what is being cloned. For example,
"RHEL5-image-myclassproject37", this name will be used
# by the NFS share, and because it is parented by a cloner image, it
will have special symantics in terms of what kernel
# arguments get fed to it, such that our special live image (or modified
initrd, TBD) knows what to do.
cobbler profile add --name=RHEL5-image-projectX --distro=RHEL5-cloner
# now we assign a system via PXE boot to be cloned. Note that we are
assigning it to a live image not to be installed, but to
# be netbooted and then cloned.
cobbler system edit --name=foo --profile=RHEL5-image-projectX
--save-clone [--netboot-enabled=1]
# to clone the image, we assign another system to the cloner profile,
like so, and reboot it once finished
cobbler system edit --name=bar --profile=RHEL5-image-projectX
--load-clone [--netboot-enabled=1]
This should cover all partition types supported by partimage but not the
"weird stuff".
This also seems to imply that we would have a settting in
/etc/cobbler/settings to configure the address info of the NFS
server to save things to.
Comments? Questions?
--Michael
15 years, 7 months
custom menu_label
by Axel Thimm
Hi,
ist it possible to pass a custom, human eyes friendly menu_label to
pxeprofiles? Currently it just takes the profile name which is bound
to certain restrictions. E.g. I'd like to call a profile in the PXE
menu "Install Fedora 9 32 bits" or "Rescue system from Fedora
9/x86_64".
--
Axel.Thimm at ATrpms.net
15 years, 7 months
NIC for Installation and their order
by Andreas Zuber
Hi
Like many others, we had some problems with the order of the network cards
during and after the installation. We found a way to workaround that problem,
i'll try to explain how we did that:
- Device for Installation:
There are several points during installation where the network card is
configured. There is a way to ensure that always the same card is used.
First, enable pxe only on the device you want to use for the installation.
After that, we tell the install kernel that we want to use the same device to
fetch the kickstart.
/etc/cobbler/setting:
---------8<------------
kernel_options:
ksdevice: bootif
---------8<------------
We change the value of ksdevice to bootif. bootif is a variable.
/etc/cobbler/pxesystem.template:
---------8<------------
default linux
prompt 0
timeout 1
label linux
kernel $kernel_path
$append_line
IPAPPEND 2
---------8<------------
We add IPAPPEND 2 to the template file. This adds the bootif variable which
contains the network device information to the append line.
Finally we need to ensure that anaconda uses the same device. Simply remove
all network commands from your kickstart template/snippets and replace it
with:
network --bootproto=dhcp
- Configure the network cards with the information from cobbler
We found that anaconda is not able to create the configuration of the network
devices related to their MAC/hardware address. We decided to write a cheetah
template, that uses the information form cobbler to write the network
configuration directly to /etc/sysconfig/network-scripts/
/var/lib/cobbler/snippets/post_baremetal
---------8<------------
# Network information
#set $network_baremetal_file = '/etc/sysconfig/network'
echo "NETWORKING=yes" > $network_baremetal_file
echo "NETWORKING_IPV6=no" >> $network_baremetal_file
#for $n in $range(8, -1, -1)
#set $ns = str($n)
#if $getVar('mac_address_intf' + $ns, '')
#set $network_baremetal_device = 'eth' + $ns
#set $network_baremetal_mac = $getVar('mac_address_intf' + $ns, '')
#set $network_baremetal_devfile = '/etc/sysconfig/network-scripts/ifcfg-'
+ $network_baremetal_device
echo "DEVICE=$network_baremetal_device" > $network_baremetal_devfile
echo "HWADDR=$network_baremetal_mac" >> $network_baremetal_devfile
echo "ONBOOT=yes" >> $network_baremetal_devfile
#if $getVar('ip_address_intf' + $ns, '')
#if $getVar('ip_address_intf' + $ns, '')
#set $network_baremetal_ip = $getVar('ip_address_intf' + $ns, '')
echo "BOOTPROTO=static" >> $network_baremetal_devfile
echo "IPADDR=$network_baremetal_ip" >> $network_baremetal_devfile
#if $getVar('subnet_intf' + $ns, '')
#set $network_baremetal_netmask = $getVar('subnet_intf' + $ns, '')
echo "NETMASK=$network_baremetal_netmask" >>
$network_baremetal_devfile
#else
echo "NETMASK=255.255.255.0" >> $network_baremetal_devfile
#end if
#if $getVar('gateway_intf' + $ns, '')
#set $network_baremetal_gateway = $getVar('gateway_intf' + $ns, '')
#set $network_baremetal_hostname = $getVar('hostname_intf' +
$ns, 'not-found.example.com')
echo "HOSTNAME=$network_baremetal_hostname" >>
$network_baremetal_file
echo "GATEWAY=$network_baremetal_gateway" >> $network_baremetal_file
#end if
#end if
#else
echo "BOOTPROTO=dhcp" >> $network_baremetal_devfile
#end if
#end if
#end for
---------8<------------
We hope this helps someone else too.
Greetings
Puzzle Operations Team
15 years, 7 months
[PATCH] initial patch for cobbler report
by Anderson Silva
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This is my first patch, and I had limited resources for testing.
Consider this a 'working in progress'
Feel free to submit feedback. One thing I still would like to do is:
cobbler report --what=system --list-all-fields
Which would provide a list of all available fields to anyone who would
like use customize the report with the --fields options.
AS
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFIsu4eECmX3C4JWKgRAvXHAJ9fjchsN4HZGP1nRxRSc61D4MpvAwCgmaEU
DxxxfgJWaV6mDwl5qQOqwHg=
=kKk1
-----END PGP SIGNATURE-----
15 years, 7 months
[ANNOUNCE] Cobbler and Koan 1.2
by Michael DeHaan
I'm happy to announce that Cobbler and Koan 1.2 are now available.
These releases include all development work on the 1.1.X branch over the
last month and a half or so and are documented here:
https://fedorahosted.org/cobbler/wiki/WhatsNewInEleven
Major features like the "cobbler find" command, "cobbler getks", and an
improved "cobbler replicate" for multiple cobbler server synchronization
should be useful to a wide variety of users. This also includes
preliminary support for "cobbler image add" and doing ISO based installs
from koan. There is also support added for VMware workstation (in
addition to previous support for server) which has it's own virt-type --
I'm still hoping someone else will contribute support for ESX later.
Other cool features include being able to assign a default profile to
just a specific subnet and an easy way to set up post-install kickstart
parameters on installed systems.
Releases can be downloaded at http://cobbler.et.redhat.com/download/ and
should hit the mirrors shortly (F-7+, EL4, EL5).
A huge thanks goes out to everyone who has helped with this release in
terms of sharing ideas here and on IRC, testing, or contributing
code. You all know who you are and this is your release just as much
as mine. Thank you.
As with all releases, we'll do maintaince releases to fix anything
serious that comes up in this one and look at doing 1.4 in about another
month or so. As I've mentioned before, we want to include more web
features for 1.4, including ACLs and probably search. Better Puppet
integration is also on the list. The full details of current plans are
at https://fedorahosted.org/cobbler/wiki/TheRoadmap though I'm always
happy to hear your feedback and other ideas you are interested in.
Upgrades to 1.2 should be seamless and there are no additional
instructions. If you still have something pre-1.0, run "cobbler check
to see what you need to do once upgrading" and follow the WebUI
instructions on the Wiki as that was a major release. That should be
fairly simple.
Happy Labor Day from this side of the pond and I hope you all enjoy 1.2!
Thanks again,
--Michael
15 years, 7 months
More ACL development thoughts, comments?
by Michael DeHaan
I've updated this to reflect current plans
https://fedorahosted.org/cobbler/wiki/AclFeature
A sample version of the ACL config as documented above is:
(Again, this is a list of fields/methods to deny access to)
---
admin: {} # no denials
admins: {}
jradmin:
copy_distro: *
copy_image: *
copy_profile: *
copy_repo: *
modify_distro: *
modify_image: *
modify_profile: *
modify_repo: *
new_distro: *
new_image: *
new_profile: *
new_repo: *
remove_distro: *
remove_image: *
remove_profile: *
remove_repo: *
write_kickstart_templates: *
lesstrusted:
copy_*: *
modify_distro: *
modify_image: *
modify_profile: *
modify_repo: *
modify_system:
gateway-*: ~
hostname-*: ~
ip-address-*: ~
mac-address-*: ~
subnet-*: ~
new_*: *
remove_*: *
rename_*: *
save_distro: *
save_image: *
save_profile: *
save_repo: *
sync: *
write_kickstart_templates: *
unmatched: {}
Basically that's just denials of various fields. This should be easy
to show in the WebUI when someone logs in what they can and can't
tweak. Combined with a toggle option in the webapp for "Hide Advanced
Fields", and also grey out systems people don't own or fields they can't
access this seems to be rather workable and not terrible to implement.
Ideally we have a way a toggle on the list view to list things I own or
to list all things.
So the question to you is (and I've kind of asked this before), what
sort of user restrictions and roles would you want in Cobbler?
Does that kind of denial system seem to make sense?
This doesn't preclude having an ACL editor in the Wiki for admin users,
but I don't plan to write one. The goal here is to make things very
workable for folks with specific use cases now, which they'll probably
set up once and leave alone, rather than building a large
overcomplicated web system.
The end goal is to be able to hand your cobbler web app to users who
just need to tweak certain things and feel complicated they won't blow
something up.... being able to delegate basic installations to users,
and allow them to control just certain aspects of the configuration
without breaking too much.
In the most extreme use cases (very large sites) you will probably still
want to implement your own view into Cobbler's XMLRPC, in which case
this feature can still be used to enforce security for those communications.
Anyhow, comments welcome. If you'd rather have something different,
now's the time to say that too. If this feature is not for you, don't
worry though, as it is optional and not in your way by default -- but I
would never much like to hear from people who do want ACL controls and
to know if that's the kind of access control they are looking for.
Thanks!
--Michael
15 years, 7 months
Better security documentation now on the Wiki
by Michael DeHaan
==
Topic 1
I've organized the Wiki a bit so it's easier to understand the security
section.
Particularly each security related option is detailed in
/etc/cobbler/modules.conf.
Visit https://fedorahosted.org/cobbler/wiki/UserDocs and search for
Security.
If you have wondered more about access controls around the Web app (or
have never set up the web app), or XMLRPC, you might find that info useful.
===
Topic 2
I've also started a new page on the AclFeature which is going to be an
optional upgrade to the various Authorization modules, that change them
from "shoot-self-in-foot" prevention to something much more robust...
eventually building into being able to offer up a simpler cobbler web
views for folks being able to edit only what they are supposed to edit.
i.e. "I am a regular user person who has 50 lab systems and I want to
reinstall one of the ones I own to a different profile, but I shouldn't
be allowed to change the MAC, IP, or hostname information in Cobbler
because I'm not in IT".
By default ACLs will not be enabled, they will be there for those
installations that want to use them. It will be also possible (like
with other Cobbler modules) to source acl data from sources like LDAP,
if you want to write your own acl module for cobbler's modules system.
--Michael
15 years, 7 months