Hello, I have only one, but big server where I'm experimenting many things. It is a Fedora 11 x86_64 host. At first I configured it as a host for qemu/kvm guests, managing them with the virt-manager gui tool. I successfully had dnsmasq instance run by libvirt layer coexist with the system provided dnsmasq daemon This way I could manually PXE boot and install guests configured with shared physical networks (bridge br0 on the host). (I have two dnsmasq processes listening on different interfaces, br0 and virbr0)
Now I'm looking at cobbler/koan to glue together things and provide also provisioning for physical and virtual servers. Unfortunately I have to configure/manage it on the same big box....
I configured cobbler to use dnsmasq and I thought that this way it would pick up the already configured one. Instead it seems to me that it overwrote completely my previous /etc/dnsmasq.conf file .... Is there any way to let cobbler use an externally configured dnsmasq or by design it has to manage it? At this moment I have
in /etc/cobbler/modules.conf: [dhcp] module = manage_dnsmasq
in /etc/cobbler/settings: manage_dhcp: 1
Is it correct that I can preserve my already setup configs and settings only putting manage_dhcp: 0? this way cobbler will take advantage (or disadvantage if I scrumble things.. ;-) and not interfere?
cobbler check gives: [root@virtfed etc]# cobbler check /usr/lib64/python2.6/site-packages/Cheetah/CacheRegion.py:30: DeprecationWarning: the md5 module is deprecated; use hashlib instead import md5 The following potential problems were detected: #0: change 'disable' to 'no' in /etc/xinetd.d/tftp #1: since iptables may be running, ensure 69, 80, and 25151 are unblocked #2: The default password used by the sample templates for newly installed machines (default_password_crypted in /etc/cobbler/settings) is still set to 'cobbler' and should be changed #3: fencing tools were not found, and are required to use the (optional) power management features. install cman to use them
In particular, I see that it configured this way
[root@virtfed etc]# cat /etc/dnsmasq.conf # Cobbler generated configuration file for dnsmasq # Wed Jul 1 10:02:47 2009
# resolve.conf .. ? #no-poll #enable-dbus read-ethers addn-hosts = /var/lib/cobbler/cobbler_hosts
dhcp-range=192.168.1.5,192.168.1.200 dhcp-option=3,10.4.5.152 dhcp-lease-max=1000 dhcp-authoritative dhcp-boot=pxelinux.0 dhcp-boot=net:normalarch,pxelinux.0 dhcp-boot=net:ia64,/var/lib/cobbler/elilo-3.6-ia64.efi
Where does it pick the 192.168 address range....? Suppose I want to have cobbler manage dhcp, where I configure the range? If I modify dnsmasq.conf and then run "cobbler sync" do I risk to overwrite again my changes?
Eventually it could be nice to have cobbler making a backup copy (luckily I had it) before overwrite....
I think that overwrite happened when I ran cobbler import --path=/mnt --name=rhel4.8 --arch=x86 after mounting an iso of rhel4.8 x86....
btw: what is the difference between --path and --mirror? Perhaps the former can only manage local paths, while the latter also Uri such as http/nfs...? I didn't find clear answer...
I'm glad to say that anyway I was then able to install a guest on the same host provinding cobbler with the command koan --server=10.4.5.152 --virt --profile=rhel4.8-i386-virt --virt-name=koantest and then access it form within virt-manager. My compliments to you guys!
some annotations:
- even if in my kickstart I had network --device=eth0 --bootproto static --ip 10.4.5.154 --netmask 255.255.255.0 --gateway 10.4.5.250 --nameserver 10.4.1.120 --hostname koantest It asked the network parameters in anaconda...... I presume because the kernel command line "automatically" contained "ksdevice=link" but I'm not sure. Also, this is a constraint with network installs and my line above is parsed only to configure network for the system but not used at the initial steps.... After putting the static network information, the installation proceeded successfully.
- in /etc/cobbler settings I have default_virt_type: qemu but it seems cobbler configured the guest with the mac address used for xen (initial 00:16:3e) instead of the one for qemu (52:54:00)
Thanks for your time, Gianluca
Hi,
not including the list as recipient of this mail since its more kvm-related,
On Thu, Jul 02, 2009 at 04:38:34PM +0200, Gianluca Cecchi wrote:
At first I configured it as a host for qemu/kvm guests, managing them with the virt-manager gui tool.
So cobbler running on host not itself as guest, right? Running debian/sid here on host for my experiements the cobbler-server also is kvm-virtualguested and i discovered it cannot transfer files to other booted guests via tftp, had to offer that service from the (debianish) host. Maybe you also come around to virtualize the cobbler and share your experiences.
Christian
On *Thu Jul 2 14:45:59 UTC 2009 Christian Horn wrote:*
Hi,
not including the list as recipient of this mail since its more kvm-related,
Probably not what intended.... ;-)
Maybe you also come around to virtualize the cobbler and share your experiences.
Christian
No actually my cobbler server is the physical host, not a guest itself.... Gianluca
Now I'm looking at cobbler/koan to glue together things and provide also provisioning for physical and virtual servers. Unfortunately I have to configure/manage it on the same big box....
I configured cobbler to use dnsmasq and I thought that this way it would pick up the already configured one. Instead it seems to me that it overwrote completely my previous /etc/dnsmasq.conf file .... Is there any way to let cobbler use an externally configured dnsmasq or by design it has to manage it? At this moment I have
Cobbler writes DHCP and DNS management via templates in /etc/cobbler, which /should/ be documented on the Wiki. If you think that information can be improved and have suggestions, let us know. You can add your own content to the templates and it will continue to write them, but Cobbler is not intelligent enough to know how to manipulate existing config files.
Where does it pick the 192.168 address range....? Suppose I want to have cobbler manage dhcp, where I configure the range? If I modify dnsmasq.conf and then run "cobbler sync" do I risk to overwrite again my changes?
You can choose any range in the template you like.
Eventually it could be nice to have cobbler making a backup copy (luckily I had it) before overwrite....
I think that overwrite happened when I ran cobbler import --path=/mnt --name=rhel4.8 --arch=x86 after mounting an iso of rhel4.8 x86....
btw: what is the difference between --path and --mirror? Perhaps the former can only manage local paths, while the latter also Uri such as http/nfs...? I didn't find clear answer...
Let's keep one discussion topic per email thread please, it makes easier to follow.
--path and --mirror are just aliases to support backwards compatibility actually.
- in /etc/cobbler settings I have
default_virt_type: qemu but it seems cobbler configured the guest with the mac address used for xen (initial 00:16:3e) instead of the one for qemu (52:54:00)
Newer versions of Cobbler will use one of the private ranges. I thought 1.6.6 did but it's been a while so I can't remember. That won't hurt anything though.
On Thu Jul 2 15:51:30 UTC 2009 Michael DeHaan wrote:
Cobbler writes DHCP and DNS management via templates in /etc/cobbler, which /should/ be documented on the Wiki.
Ok, I merged the file /etc/cobbler/dnsmasq.template with my previous system config and now it works like a champ and automatically install my guest in less than 3 minutes! So if I have to do changes to my overall dnsmasq I can modify the template and run a "cobbler sync". One question: do I have to leave the system dnsmasq in chkconfig on or does cobbler need to start it automatically during the cobblerd service startup and so I have to leave dnsmasq off?
And also, as in /etc/cobbler directory there is the tftp template too, is it a must to have tftp provided by xinetd or can I use tftp functionality provided by dnsmasq itself? the "cobbler check" command issues the warning
#0: change 'disable' to 'no' in /etc/xinetd.d/tftp
as I'm not enabling tftpd via xinetd....
Let's keep one discussion topic per email thread please, it makes easier to follow.
Ok, sorry. And thanks for your answer anyway.
Now I have to fix something (proposing to dnsmasq owner via bugzilla) because a cobbler sync makes a restart of dnsmasq service and this kills also the libvirtd one as it makes a killproc instead of a killproc -p ...
Cheers, Gianluca
On 07/02/2009 01:17 PM, Gianluca Cecchi wrote:
On Thu Jul 2 15:51:30 UTC 2009 Michael DeHaan wrote:
Cobbler writes DHCP and DNS management via templates in /etc/cobbler, which /should/ be documented on the Wiki.
Ok, I merged the file /etc/cobbler/dnsmasq.template with my previous system config and now it works like a champ and automatically install my guest in less than 3 minutes! So if I have to do changes to my overall dnsmasq I can modify the template and run a "cobbler sync". One question: do I have to leave the system dnsmasq in chkconfig on or does cobbler need to start it automatically during the cobblerd service startup and so I have to leave dnsmasq off?
You need to leave it in chkconfig, as cobbler will only do a service restart when sync is run.
And also, as in /etc/cobbler directory there is the tftp template too, is it a must to have tftp provided by xinetd or can I use tftp functionality provided by dnsmasq itself? the "cobbler check" command issues the warning
What cobbler version are you running? No, we do not auto-generate tftp configs... though there was an artifact of that left over from some uncompleted development, it is not something that is used.
#0: change 'disable' to 'no' in /etc/xinetd.d/tftp
as I'm not enabling tftpd via xinetd....
Yes, you need to change this one yourself.
(Apparently chkconfig can do it for you if you don't want to edit the file)
On Thu Jul 2 17:28:25 UTC 2009, Michael DeHaan wrote:
What cobbler version are you running? No, we do not auto-generate tftp configs... though there was an artifact of that left over from some uncompleted development, it is not something that is used.
The one provided with F11 x86_64 up2date: 1.6.6-1.fc11.x86_64
The rpm itself contains (rpm -ql cobbler): /etc/cobbler/tftpd-rules.template /etc/cobbler/tftpd.template
So, finding these files in place, I thought that the same effect would be in place for tftp as for dnsmasq with a "cobbler sync"... But I've not understood if I can use tftp functionality embedded in dnsmasq or if it is a must for cobbler to use tftp daemon via xinetd though..... (I know chkconfig command suitable also for xinetd based services... thanks anyway)
Gianluca
On 07/03/2009 04:50 AM, Gianluca Cecchi wrote:
On Thu Jul 2 17:28:25 UTC 2009, Michael DeHaan wrote:
What cobbler version are you running? No, we do not auto-generate tftp configs... though there was an artifact of that left over from some uncompleted development, it is not something that is used.
The one provided with F11 x86_64 up2date: 1.6.6-1.fc11.x86_64
The rpm itself contains (rpm -ql cobbler): /etc/cobbler/tftpd-rules.template /etc/cobbler/tftpd.template
These aren't being used. They are artifacts of some work that we decided not to use.
So, finding these files in place, I thought that the same effect would be in place for tftp as for dnsmasq with a "cobbler sync"... But I've not understood if I can use tftp functionality embedded in dnsmasq or if it is a must for cobbler to use tftp daemon via xinetd though.....
Cobbler likes to use the one in xinetd. The dnsmasq templates that ship with Cobbler, in particular, do not set up TFTP.
(I know chkconfig command suitable also for xinetd based services... thanks anyway)
Gianluca _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
cobbler@lists.fedorahosted.org