From mail-lists at karan.org Fri Dec 1 10:34:57 2006 From: mail-lists at karan.org (Karanbir Singh) Date: Fri, 01 Dec 2006 10:34:57 +0000 Subject: [et-mgmt-tools] Cobbler usage survey / needs In-Reply-To: <1164817442.18979.14.camel@localhost.localdomain> References: <456C539A.5020007@redhat.com> <3cc2cbc40611281533y396b137ag1addb341cb35c0b9@mail.gmail.com> <456DA1F1.3000401@redhat.com> <456DA4E2.2040906@karan.org> <1164817442.18979.14.camel@localhost.localdomain> Message-ID: <45700551.9030800@karan.org> David Lutterkort wrote: > On Wed, 2006-11-29 at 15:18 +0000, Karanbir Singh wrote: > >> fwiw, over the next few weeks I intend to look at some puppet+cobbler >> integration, which might solve the first part of this issue. > > Interesting. How exactly are you planning on integrating them ? If it's > just having kickstart set up puppet, I have some ks snippets floating > around. Or are you thinking about something more ambitious ? the essential idea is to have a post-install payload that drops off a few bits, puppet included - that in turn can then hookup with a central puppetier which in turn hosts its config's in a db backend, with a sort of web interface to manage state and role. contributions are welcome - and I am sure there are others on this list who'd like to see some ks samples too :) so go ahead and post here, or post elsewhere, and url here. -- Karanbir Singh : http://www.karan.org/ : 2522219 at icq From mdehaan at redhat.com Fri Dec 1 15:17:22 2006 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 01 Dec 2006 10:17:22 -0500 Subject: [et-mgmt-tools] Re: cobbler 2 go. In-Reply-To: <1afe67380611301532n1bd6a280w4bb1db46d95b7221@mail.gmail.com> References: <1afe67380611301529j204088c5v9d0f5ecefa28e381@mail.gmail.com> <1afe67380611301532n1bd6a280w4bb1db46d95b7221@mail.gmail.com> Message-ID: <45704782.4030606@redhat.com> Anton wrote: > > > # koan -x -p vm_CentOS-4.4-x86_64_images_pxeboot -s 10.147.105.6 > > - processing profile: vm_CentOS-4.4-x86_64_images_pxeboot > > libvir: Xen Daemon error : POST operation failed: (xend.err "Error > creating domain: (22, 'Invalid argument')") > Failed to create domain vm_CentOS-4.4-x86_64_images_pxeboot > Traceback (most recent call last): > File "/usr/lib/python2.4/site-packages/koan/app.py", line 96, in main > k.run() > File "/usr/lib/python2.4/site-packages/koan/app.py", line 154, in run > self.do_virt() > File "/usr/lib/python2.4/site-packages/koan/app.py", line 295, in > do_virt > return self.do_net_install("/tmp",after_download) > File "/usr/lib/python2.4/site-packages/koan/app.py", line 253, in > do_net_install > after_download(self, distro_data, profile_data) > File "/usr/lib/python2.4/site-packages/koan/app.py", line 294, in > after_download > self.do_virt_net_install(profile_data, distro_data) > File "/usr/lib/python2.4/site-packages/koan/app.py", line 574, in > do_virt_net_install > extra=kextra > File "/usr/lib/python2.4/site-packages/koan/virtcreate.py", line > 196, in start_paravirt_install > dom = conn.createLinux(cfgxml, 0) > File "/usr/lib64/python2.4/site-packages/libvirt.py", line 249, in > createLinux > if ret is None:raise libvirtError('virDomainCreateLinux() failed') > libvirtError: virDomainCreateLinux() failed > I have no idea of the State of Xen on Centos, though the most common reason for this failure in Fedora/RHEL5 is that a non-Xen kernel and initrd pair were used for installation. Judging from the profile you used, this looks to be what happened. Usually xen images come from a directory labelled "xen" not "pxeboot". If you follow the same steps with the same images using xenguest-install, I expect you would see the same error. --Michael From mdehaan at redhat.com Tue Dec 5 16:21:29 2006 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 05 Dec 2006 11:21:29 -0500 Subject: [et-mgmt-tools] Pruning kickstart trees in "cobbler import" Message-ID: <45759C89.1010101@redhat.com> As some of you know, Cobbler has a feature where it can import a rsync:// mirror and make all of the distributions on it near-instantaneously installable over the local network -- not only do you not have to run the "distro add" commands, but it will be using a local copy of the kickstart tree to avoid going out on the net, etc. The workflow is basically: "cobbler import --mirror=rsync://foo.example.com --mirror-name=foo" "cobbler list" # to find what the profile name is # optionally edit the kickstart template in /etc/cobbler if you want more than @base "cobbler system add --name=AA:BB:CC:DD:EE:FF --profile=blah" "cobbler sync' One thing I've noticed though, is that something like an FC-6 mirror is rather huge, and many users won't have enough disk space to import a lot of distributions this way. I am also wanting to limit bandwidth to the mirrors so users won't be pulling down more than they need. So, I've created a rsync excludes file that removes some of the content I don't need ("rsync ... --exclude-from=rsync.exclude"), and in 0.3.4 this is installed automatically as /etc/cobbler/rsync.exclude -- it's only used for the import command. The default files to _not_ rsync are... **/debug/** **/ppc/** **/source/** **/iso/** Before, import would rsync everything, including ISO's. This was lame, so I've decided to prune the list a good bit. Since the file is user customizable, if you didn't have any x86_64 machines, you could add a line that said "**/x86_64/**" and skip a good amount of data there also. I'm not sure how common it is to install debug RPM's or source RPM's from a kickstart tree, so does anyone think those should be _enabled_ by default for the rsync import? Anyhow, a heads up on the new feature if no one was using "import" before due to space requirements. It's already pushed to the hg repository and if there aren't any complaints, I'll probably release this in a few days after it gets added to the documentation. If anyone else has any other comments on the import feature, fire away... Thanks, --Michael From dmourati at gmail.com Tue Dec 5 18:49:37 2006 From: dmourati at gmail.com (Demetri Mouratis) Date: Tue, 5 Dec 2006 10:49:37 -0800 Subject: [et-mgmt-tools] Pruning kickstart trees in "cobbler import" In-Reply-To: <45759C89.1010101@redhat.com> References: <45759C89.1010101@redhat.com> Message-ID: <3cc2cbc40612051049o5cdc5ae0qa5d10d62e5878fc6@mail.gmail.com> Michael, Great! I'm doing the same rsync exclude tricks myself and will probably ditch my setup in favor of an all cobbler solution. I ran into a source RPM issue* recently and was able to solve it with yumdownloader. I think yum/yumdownloader is the right tool for that job. -D * The source RPM issue was and is an interesting one, patching/upgrading openssh server to support SFTP logging. Contact me off list if you have any experience with SFTP file logging. From dlutter at redhat.com Wed Dec 6 02:40:19 2006 From: dlutter at redhat.com (David Lutterkort) Date: Tue, 05 Dec 2006 18:40:19 -0800 Subject: [et-mgmt-tools] Cobbler usage survey / needs In-Reply-To: <45700551.9030800@karan.org> References: <456C539A.5020007@redhat.com> <3cc2cbc40611281533y396b137ag1addb341cb35c0b9@mail.gmail.com> <456DA1F1.3000401@redhat.com> <456DA4E2.2040906@karan.org> <1164817442.18979.14.camel@localhost.localdomain> <45700551.9030800@karan.org> Message-ID: <1165372819.30810.23.camel@localhost.localdomain> On Fri, 2006-12-01 at 10:34 +0000, Karanbir Singh wrote: > David Lutterkort wrote: > > On Wed, 2006-11-29 at 15:18 +0000, Karanbir Singh wrote: > > > >> fwiw, over the next few weeks I intend to look at some puppet+cobbler > >> integration, which might solve the first part of this issue. > > > > Interesting. How exactly are you planning on integrating them ? If it's > > just having kickstart set up puppet, I have some ks snippets floating > > around. Or are you thinking about something more ambitious ? > > > the essential idea is to have a post-install payload that drops off a > few bits, puppet included - that in turn can then hookup with > a central puppetier which in turn hosts its config's in a db backend, > with a sort of web interface to manage state and role. > > contributions are welcome - and I am sure there are others on this list > who'd like to see some ks samples too :) so go ahead and post here, or > post elsewhere, and url here. Blogged about what I have: http://watzmann.net/blog/index.php?title=kickstarting_into_puppet&more=1&c=1&tb=1&pb=1 David From mdehaan at redhat.com Thu Dec 7 22:54:42 2006 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 07 Dec 2006 17:54:42 -0500 Subject: [et-mgmt-tools] Old Stuff Needs To Work Too: Lilo compatibility / Koan and RHEL3 Message-ID: <45789BB2.6060607@redhat.com> Two things: === One. Koan had some lilo support before, though I've discovered a few things about it recently, and they are now fixed in mercurial. So, if you were playing with koan before (either via "cobbler enchant/transmogrify" or directly ("koan --replace-self") and had systems using lilo, they will be a lot happier now. Changes are available in hg and will probably be pushed out to Fedora sometime next week. (Cobbler 0.3.4, Koan 0.2.5) Lilo changes: (1) Before, one had to run lilo manually after running koan to apply the config. Koan now does this automagically if lilo is being used as the bootloader. (2) It turns out that Lilo can't deal with multiple boot images having the same display value (ex: "kickstart" and "kickstart"), so if you run koan multiple times by accident, you're out of luck. Now they are labelled as "kick%s" where %s is the number of seconds since epoch (Jan 1, 1970). I had limited space to work with :) (3) while koan would correctly modify the lilo or grub config based on what was installed, it got confused if both grub and lilo were installed, and would only edit grub, even if lilo was the active bootloader. It now probes to see which bootloader is active and modifies the correct one. === Two. The other thing I'm going to be doing shortly is making koan compilable with RHEL3 -- some users don't have PXE setups (cobbler can provision RHEL3 via PXE fine), and currently koan and "enchant" won't work for them there. So, when this gets done, Cobbler will support RHEL4+, derivatives, and FC5+ -- and koan will support all of that with the addition of RHEL 3. Obviously, no virtualization support on RHEL 3... --Michael From mdehaan at redhat.com Fri Dec 8 16:35:05 2006 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 08 Dec 2006 11:35:05 -0500 Subject: [et-mgmt-tools] Old Stuff Needs To Work Too: Lilo compatibility / Koan and RHEL3 In-Reply-To: <45789BB2.6060607@redhat.com> References: <45789BB2.6060607@redhat.com> Message-ID: <45799439.5030701@redhat.com> Michael DeHaan wrote: > Two things: > > === > > One. > > Koan had some lilo support before, though I've discovered a few things > about it recently, and they are now fixed in mercurial. > > So, if you were playing with koan before (either via "cobbler > enchant/transmogrify" or directly ("koan --replace-self") and had > systems using lilo, they will be a lot happier now. Changes are > available in hg and will probably be pushed out to Fedora sometime > next week. (Cobbler 0.3.4, Koan 0.2.5) > > Lilo changes: > > (1) Before, one had to run lilo manually after running koan to apply > the config. Koan now does this automagically if lilo is being used > as the bootloader. > > (2) It turns out that Lilo can't deal with multiple boot images > having the same display value (ex: "kickstart" and "kickstart"), so if > you run koan multiple times by accident, you're out of luck. Now they > are labelled as "kick%s" where %s is the number of seconds since epoch > (Jan 1, 1970). I had limited space to work with :) > > (3) while koan would correctly modify the lilo or grub config based > on what was installed, it got confused if both grub and lilo were > installed, and would only edit grub, even if lilo was the active > bootloader. It now probes to see which bootloader is active and > modifies the correct one. > > === > > Two. > > The other thing I'm going to be doing shortly is making koan > compilable with RHEL3 -- some users don't have PXE setups (cobbler can > provision RHEL3 via PXE fine), and currently koan and "enchant" won't > work for them there. So, when this gets done, Cobbler will support > RHEL4+, derivatives, and FC5+ -- and koan will support all of that > with the addition of RHEL 3. Obviously, no virtualization support on > RHEL 3... > > --Michael > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools Much to my suprise, it turns out that koan works on RHEL3 out of the box. After the release of koan 0.2.5 and cobbler 0.3.4 (which is going to happen today, now that this already works), I'll add RHEL3 to the "supported" list for things that can run koan. If anyone would like to test Centos 3 with koan's existing noarch RPM, be my guest. Just do a "rpm -i koan*.rpm --force --nodeps". I did modify the python manifest file so koan can be built _on_ RHEL3, and this is part of 0.2.5. From tdiehl at rogueind.com Fri Dec 8 18:14:23 2006 From: tdiehl at rogueind.com (Tom Diehl) Date: Fri, 8 Dec 2006 13:14:23 -0500 (EST) Subject: [et-mgmt-tools] cobbler check question Message-ID: Hi, I am just starting to use cobbler and so far it is working well. One thing I have noticed is that cobbler check gets confused by the fact that I have "server_args -s /tftpboot" the xinetd config and tftpboot: /tftpboot/pxe in /var/lib/cobbler/services. I have a /tftpboot that looks something like this: (rocky pts4) # ls -d /tftpboot/* /tftpboot/cisco/ /tftpboot/pxe/ (rocky pts4) # Is there a better way to do this or should I just continue to ignore the cobbler error? Regards, -- Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com From mdehaan at redhat.com Fri Dec 8 18:53:03 2006 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 08 Dec 2006 13:53:03 -0500 Subject: [et-mgmt-tools] cobbler check question In-Reply-To: References: Message-ID: <4579B48F.2000603@redhat.com> Tom Diehl wrote: > Hi, > > I am just starting to use cobbler and so far it is working well. One > thing > I have noticed is that cobbler check gets confused by the fact that I > have > "server_args -s /tftpboot" the xinetd config and tftpboot: /tftpboot/pxe > in /var/lib/cobbler/services. > > I have a /tftpboot that looks something like this: > > (rocky pts4) # ls -d /tftpboot/* > /tftpboot/cisco/ /tftpboot/pxe/ > (rocky pts4) # > > Is there a better way to do this or should I just continue to ignore the > cobbler error? > > > Regards, > The PXE components shouldn't work with the way you have it configured, so the check result seems correct based on what information you've given so far. Explanation -- TFTP runs chroot, so your tftp root is configured as "/tftpboot". However, you're telling cobbler to write files in "/tftpboot/pxe", so files in pxelinux.cfg referencing "/images/blah" would be looking in "/tftpboot/blah" on your filesystem when the files are actually being stored in "/tftpboot/pxe/blah". Recent versions of cobbler do not delete contents of "/tftpboot" they do not own when syncing, so if you set tftpboot in /var/lib/cobbler/settings back to the value you are using in xinetd.d, it should be good to go. Cobbler will write the files where it needs to write them relative to TFTP root, and you're free to use the rest of the directory for other things. The reason the tftpboot setting is there at all in settings is to accomodate for TFTP installs that might not want to use the partition mounted on "/" for hosting tftp content. FYI, The directories/items cobbler will modify in /tftpboot are: pxelinux.cfg (directory) images (directory) pxelinux.0 (file) elilo-3.6-ia64.efi (file) --Michael From mdehaan at redhat.com Fri Dec 8 18:59:01 2006 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 08 Dec 2006 13:59:01 -0500 Subject: [et-mgmt-tools] cobbler check question In-Reply-To: <4579B48F.2000603@redhat.com> References: <4579B48F.2000603@redhat.com> Message-ID: <4579B5F5.2030209@redhat.com> Michael DeHaan wrote: > Tom Diehl wrote: >> Hi, >> >> I am just starting to use cobbler and so far it is working well. One >> thing >> I have noticed is that cobbler check gets confused by the fact that I >> have >> "server_args -s /tftpboot" the xinetd config and tftpboot: /tftpboot/pxe >> in /var/lib/cobbler/services. >> >> I have a /tftpboot that looks something like this: >> >> (rocky pts4) # ls -d /tftpboot/* >> /tftpboot/cisco/ /tftpboot/pxe/ >> (rocky pts4) # >> >> Is there a better way to do this or should I just continue to ignore the >> cobbler error? >> >> >> Regards, >> > The PXE components shouldn't work with the way you have it configured, > so the check result seems correct based on what information you've > given so far. > > Explanation -- TFTP runs chroot, so your tftp root is configured as > "/tftpboot". However, you're telling cobbler to write files in > "/tftpboot/pxe", so files in pxelinux.cfg referencing "/images/blah" > would be looking in "/tftpboot/blah" on your filesystem when the files > are actually being stored in "/tftpboot/pxe/blah". > > Recent versions of cobbler do not delete contents of "/tftpboot" they > do not own when syncing, so if you set tftpboot in > /var/lib/cobbler/settings back to the value you are using in xinetd.d, > it should be good to go. Cobbler will write the files where it needs > to write them relative to TFTP root, and you're free to use the rest > of the directory for other things. The reason the tftpboot setting is > there at all in settings is to accomodate for TFTP installs that might > not want to use the partition mounted on "/" for hosting tftp content. > > FYI, The directories/items cobbler will modify in /tftpboot are: > > pxelinux.cfg (directory) > images (directory) > pxelinux.0 (file) > elilo-3.6-ia64.efi (file) > > --Michael > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools I should add, namespacing files used by PXE by creating a subdirectory under /tftpboot is a really good idea, and I'll make that "cobbler sync" do that in the future. From mdehaan at redhat.com Fri Dec 8 20:57:10 2006 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 08 Dec 2006 15:57:10 -0500 Subject: [et-mgmt-tools] cobbler check question In-Reply-To: <4579B5F5.2030209@redhat.com> References: <4579B48F.2000603@redhat.com> <4579B5F5.2030209@redhat.com> Message-ID: <4579D1A6.4040407@redhat.com> Michael DeHaan wrote: > Michael DeHaan wrote: >> Tom Diehl wrote: >>> Hi, >>> >>> I am just starting to use cobbler and so far it is working well. One >>> thing >>> I have noticed is that cobbler check gets confused by the fact that >>> I have >>> "server_args -s /tftpboot" the xinetd config and tftpboot: >>> /tftpboot/pxe >>> in /var/lib/cobbler/services. >>> >>> I have a /tftpboot that looks something like this: >>> >>> (rocky pts4) # ls -d /tftpboot/* >>> /tftpboot/cisco/ /tftpboot/pxe/ >>> (rocky pts4) # >>> >>> Is there a better way to do this or should I just continue to ignore >>> the >>> cobbler error? >>> >>> >>> Regards, >>> >> The PXE components shouldn't work with the way you have it >> configured, so the check result seems correct based on what >> information you've given so far. >> >> Explanation -- TFTP runs chroot, so your tftp root is configured as >> "/tftpboot". However, you're telling cobbler to write files in >> "/tftpboot/pxe", so files in pxelinux.cfg referencing "/images/blah" >> would be looking in "/tftpboot/blah" on your filesystem when the >> files are actually being stored in "/tftpboot/pxe/blah". >> >> Recent versions of cobbler do not delete contents of "/tftpboot" they >> do not own when syncing, so if you set tftpboot in >> /var/lib/cobbler/settings back to the value you are using in >> xinetd.d, it should be good to go. Cobbler will write the files where >> it needs to write them relative to TFTP root, and you're free to use >> the rest of the directory for other things. The reason the tftpboot >> setting is there at all in settings is to accomodate for TFTP >> installs that might not want to use the partition mounted on "/" for >> hosting tftp content. >> >> FYI, The directories/items cobbler will modify in /tftpboot are: >> >> pxelinux.cfg (directory) >> images (directory) >> pxelinux.0 (file) >> elilo-3.6-ia64.efi (file) >> >> --Michael >> >> >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools > I should add, namespacing files used by PXE by creating a subdirectory > under /tftpboot is a really good idea, and I'll make that "cobbler > sync" do that > in the future. > > > > Actually, I probably don't want to namespace files in /tftpboot after all, now that I think about it. One reason for this is that most folks when setting up dhcpd.conf assume pxelinux.0 is in tftproot, and probably wouldn't know to change that -- it would break users already using the dhcp templating features, for instance. Just dropping the bootloaders in "/" and leaving everything else in the two image directories is enough to keep from clobbering other uses of the tftp root. From tdiehl at rogueind.com Fri Dec 8 21:25:53 2006 From: tdiehl at rogueind.com (Tom Diehl) Date: Fri, 8 Dec 2006 16:25:53 -0500 (EST) Subject: [et-mgmt-tools] Re: cobbler check question In-Reply-To: <4579B48F.2000603@redhat.com> References: <4579B48F.2000603@redhat.com> Message-ID: On Fri, 8 Dec 2006, Michael DeHaan wrote: > Tom Diehl wrote: >> Hi, >> >> I am just starting to use cobbler and so far it is working well. One thing >> I have noticed is that cobbler check gets confused by the fact that I have >> "server_args -s /tftpboot" the xinetd config and tftpboot: /tftpboot/pxe >> in /var/lib/cobbler/services. >> >> I have a /tftpboot that looks something like this: >> >> (rocky pts4) # ls -d /tftpboot/* >> /tftpboot/cisco/ /tftpboot/pxe/ >> (rocky pts4) # >> >> Is there a better way to do this or should I just continue to ignore the >> cobbler error? >> >> >> Regards, >> > The PXE components shouldn't work with the way you have it configured, so the > check result seems correct based on what information you've given so far. But it is working here. Unless I do not understand what cobbler is supposed to do and I am missing some key feature. Right now I have a test box that I tell to pxe boot and modulo some error in the kickstart.cfg file, I come back in about 30 minutes and I have a machine that is installed and configured. Is there more to cobbler than that?? Below is the output of cobbler list cobbler check and the services file: (rocky pts6) # cobbler list defaults kernel options : append devfs=nomount ramdisk_size=16438 lang= ksdevice=link distro 1 : fc6-x86_64 kernel : /fc6/x86_64/os/images/pxeboot/vmlinuz initrd : /fc6/x86_64/os/images/pxeboot/initrd.img kernel options : architecture : x86 ks metadata : distro 2 : fc6-i386 kernel : /fc6/i386/os/images/pxeboot/vmlinuz initrd : /fc6/i386/os/images/pxeboot/initrd.img kernel options : architecture : x86 ks metadata : profile 1 : tigger2-x86_64-ks distro : fc6-x86_64 kickstart : /home/www/kickstart/tigger2-ks.cfg kernel options : ks metadata : virt name : tigger2-x86_64-ks virt file size : virt ram : virt paravirt : profile 2 : tigger2-i386-ks distro : fc6-i386 kickstart : /home/www/kickstart/tigger2-ks.cfg kernel options : ks metadata : virt name : tigger2-i386-ks virt file size : virt ram : virt paravirt : profile 3 : fc6-x86_64-noks distro : fc6-x86_64 kickstart : /etc/cobbler/default.ks kernel options : ks metadata : virt name : fc6-x86_64-noks virt file size : virt ram : virt paravirt : system 1 : 00:0f:fe:44:51:b2 profile : tigger2-i386-ks kernel options : noipv6 ks metadata : pxe address : (rocky pts6) # (rocky pts6) # cobbler check the following potential problems were detected: #0: need to change field 'server_args' value to '-s /tftpboot/pxe' in file '/etc/xinetd.d/tftp' (rocky pts6) # -- bootloaders: ia64: /var/lib/cobbler/elilo-3.6-ia64.efi standard: /usr/lib/syslinux/pxelinux.0 default_kickstart: /etc/cobbler/default.ks dhcpd_bin: /usr/sbin/dhcpd dhcpd_conf: /etc/dhcpd.conf httpd_bin: /usr/sbin/httpd kernel_options: append devfs=nomount ramdisk_size=16438 lang= ksdevice=link koan_path: '' manage_dhcp: 0 next_server: '192.168.0.16' server: '192.168.0.16' tftpboot: /tftpboot/pxe tftpd_bin: /usr/sbin/in.tftpd tftpd_conf: /etc/xinetd.d/tftp webdir: /home/www/cobbler > > Explanation -- TFTP runs chroot, so your tftp root is configured as > "/tftpboot". However, you're telling cobbler to write files in > "/tftpboot/pxe", so files in pxelinux.cfg referencing "/images/blah" would be > looking in "/tftpboot/blah" on your filesystem when the files are actually > being stored in "/tftpboot/pxe/blah". Well that does make sense, except now that I think about it, I have "filename "/pxe/pxelinux.0";" in my dhcpd.conf file. I had forgotten about that as I set pxe booting up several years ago. > Recent versions of cobbler do not delete contents of "/tftpboot" they do not > own when syncing, so if you set tftpboot in /var/lib/cobbler/settings back to > the value you are using in xinetd.d, it should be good to go. Cobbler will > write the files where it needs to write them relative to TFTP root, and > you're free to use the rest of the directory for other things. The reason the > tftpboot setting is there at all in settings is to accomodate for TFTP > installs that might not want to use the partition mounted on "/" for hosting > tftp content. > > FYI, The directories/items cobbler will modify in /tftpboot are: > > pxelinux.cfg (directory) > images (directory) > pxelinux.0 (file) > elilo-3.6-ia64.efi (file) To me, having the config files for multiple devices in the same directory is ugly and if there are enough different devices it can be confusing. Maybe it is just me but... Thanks, for at least thinking about this and the quick response. Regards, -- Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com From tdiehl at rogueind.com Fri Dec 8 21:31:48 2006 From: tdiehl at rogueind.com (Tom Diehl) Date: Fri, 8 Dec 2006 16:31:48 -0500 (EST) Subject: [et-mgmt-tools] Re: cobbler check question In-Reply-To: <4579D1A6.4040407@redhat.com> References: <4579B48F.2000603@redhat.com> <4579B5F5.2030209@redhat.com> <4579D1A6.4040407@redhat.com> Message-ID: On Fri, 8 Dec 2006, Michael DeHaan wrote: > Michael DeHaan wrote: >> Michael DeHaan wrote: >>> Tom Diehl wrote: >>>> Hi, >>>> >>>> I am just starting to use cobbler and so far it is working well. One >>>> thing >>>> I have noticed is that cobbler check gets confused by the fact that I >>>> have >>>> "server_args -s /tftpboot" the xinetd config and tftpboot: /tftpboot/pxe >>>> in /var/lib/cobbler/services. >>>> >>>> I have a /tftpboot that looks something like this: >>>> >>>> (rocky pts4) # ls -d /tftpboot/* >>>> /tftpboot/cisco/ /tftpboot/pxe/ >>>> (rocky pts4) # >>>> >>>> Is there a better way to do this or should I just continue to ignore the >>>> cobbler error? >>>> >>>> >>>> Regards, >>>> >>> The PXE components shouldn't work with the way you have it configured, so >>> the check result seems correct based on what information you've given so >>> far. >>> >>> Explanation -- TFTP runs chroot, so your tftp root is configured as >>> "/tftpboot". However, you're telling cobbler to write files in >>> "/tftpboot/pxe", so files in pxelinux.cfg referencing "/images/blah" would >>> be looking in "/tftpboot/blah" on your filesystem when the files are >>> actually being stored in "/tftpboot/pxe/blah". >>> >>> Recent versions of cobbler do not delete contents of "/tftpboot" they do >>> not own when syncing, so if you set tftpboot in /var/lib/cobbler/settings >>> back to the value you are using in xinetd.d, it should be good to go. >>> Cobbler will write the files where it needs to write them relative to TFTP >>> root, and you're free to use the rest of the directory for other things. >>> The reason the tftpboot setting is there at all in settings is to >>> accomodate for TFTP installs that might not want to use the partition >>> mounted on "/" for hosting tftp content. >>> >>> FYI, The directories/items cobbler will modify in /tftpboot are: >>> >>> pxelinux.cfg (directory) >>> images (directory) >>> pxelinux.0 (file) >>> elilo-3.6-ia64.efi (file) >>> >>> --Michael >>> >>> >>> _______________________________________________ >>> et-mgmt-tools mailing list >>> et-mgmt-tools at redhat.com >>> https://www.redhat.com/mailman/listinfo/et-mgmt-tools >> I should add, namespacing files used by PXE by creating a subdirectory >> under /tftpboot is a really good idea, and I'll make that "cobbler sync" do >> that >> in the future. >> >> >> >> > Actually, I probably don't want to namespace files in /tftpboot after all, > now that I think about it. Would you please explain the term "namespacing files"? I do not understand that. > One reason for this is that most folks when setting up dhcpd.conf assume > pxelinux.0 is in tftproot, and probably wouldn't know to change that -- it > would break users already using the dhcp templating features, for instance. > Just dropping the bootloaders in "/" and leaving everything else in the two > image directories is enough to keep from clobbering other uses of the tftp > root. As I said in my previous message, a long time ago when I first setup pxe I configured dhcpd to look for pxelinux.0 in /pxe. I guess I am the exception. :-) Maybe cobbler should check dhcpd.conf to be sure what is the correct place for pxelinux.0? Then again if the dhcp server is not on the cobbler machine that might not be possible. Oh, well, for now I will ignore the warning. At least now, I understand what is happening. Regards, -- Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com From mdehaan at redhat.com Fri Dec 8 21:40:44 2006 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 08 Dec 2006 16:40:44 -0500 Subject: [et-mgmt-tools] Re: cobbler check question In-Reply-To: References: <4579B48F.2000603@redhat.com> <4579B5F5.2030209@redhat.com> <4579D1A6.4040407@redhat.com> Message-ID: <4579DBDC.5030808@redhat.com> Tom Diehl wrote: > On Fri, 8 Dec 2006, Michael DeHaan wrote: > >> Michael DeHaan wrote: >>> Michael DeHaan wrote: >>>> Tom Diehl wrote: >>>>> Hi, >>>>> >>>>> I am just starting to use cobbler and so far it is working well. >>>>> One thing >>>>> I have noticed is that cobbler check gets confused by the fact >>>>> that I have >>>>> "server_args -s /tftpboot" the xinetd config and tftpboot: >>>>> /tftpboot/pxe >>>>> in /var/lib/cobbler/services. >>>>> >>>>> I have a /tftpboot that looks something like this: >>>>> >>>>> (rocky pts4) # ls -d /tftpboot/* >>>>> /tftpboot/cisco/ /tftpboot/pxe/ >>>>> (rocky pts4) # >>>>> >>>>> Is there a better way to do this or should I just continue to >>>>> ignore the >>>>> cobbler error? >>>>> >>>>> >>>>> Regards, >>>>> >>>> The PXE components shouldn't work with the way you have it >>>> configured, so the check result seems correct based on what >>>> information you've given so far. >>>> >>>> Explanation -- TFTP runs chroot, so your tftp root is configured as >>>> "/tftpboot". However, you're telling cobbler to write files in >>>> "/tftpboot/pxe", so files in pxelinux.cfg referencing >>>> "/images/blah" would be looking in "/tftpboot/blah" on your >>>> filesystem when the files are actually being stored in >>>> "/tftpboot/pxe/blah". >>>> >>>> Recent versions of cobbler do not delete contents of "/tftpboot" >>>> they do not own when syncing, so if you set tftpboot in >>>> /var/lib/cobbler/settings back to the value you are using in >>>> xinetd.d, it should be good to go. Cobbler will write the files >>>> where it needs to write them relative to TFTP root, and you're free >>>> to use the rest of the directory for other things. The reason the >>>> tftpboot setting is there at all in settings is to accomodate for >>>> TFTP installs that might not want to use the partition mounted on >>>> "/" for hosting tftp content. >>>> >>>> FYI, The directories/items cobbler will modify in /tftpboot are: >>>> >>>> pxelinux.cfg (directory) >>>> images (directory) >>>> pxelinux.0 (file) >>>> elilo-3.6-ia64.efi (file) >>>> >>>> --Michael >>>> >>>> >>>> _______________________________________________ >>>> et-mgmt-tools mailing list >>>> et-mgmt-tools at redhat.com >>>> https://www.redhat.com/mailman/listinfo/et-mgmt-tools >>> I should add, namespacing files used by PXE by creating a >>> subdirectory under /tftpboot is a really good idea, and I'll make >>> that "cobbler sync" do that >>> in the future. >>> >>> >>> >>> >> Actually, I probably don't want to namespace files in /tftpboot after >> all, now that I think about it. > > Would you please explain the term "namespacing files"? I do not > understand > that. Making a "/cobbler" subdirectory under tftproot. > >> One reason for this is that most folks when setting up dhcpd.conf >> assume pxelinux.0 is in tftproot, and probably wouldn't know to >> change that -- it would break users already using the dhcp templating >> features, for instance. Just dropping the bootloaders in "/" and >> leaving everything else in the two image directories is enough to >> keep from clobbering other uses of the tftp root. > > As I said in my previous message, a long time ago when I first setup > pxe I > configured dhcpd to look for pxelinux.0 in /pxe. I guess I am the > exception. :-) Righto, namely I do like the idea, though I don't want to break all of the non-exceptions. > > Maybe cobbler should check dhcpd.conf to be sure what is the correct > place for > pxelinux.0? Then again if the dhcp server is not on the cobbler > machine that > might not be possible. Right. Cobbler can generate dhcpd.conf too -- see the part about "manage_dhcp" in the manpages, which is off by default (disclaimer: do backup your existing copy before turning this on). In the case of IA64 support, cobbler will write out system-specific configurations that use elilo. Cobbler knows the right location for pxelinux.0, elilo's IA64 port, and so forth -- and fills in the URLs for each system based on what they need to PXE. > > Oh, well, for now I will ignore the warning. At least now, I > understand what is > happening. Yes, it sounds like you're fine in this case. Cobbler check is there to make a good guess as to whether your initial config is set up correctly, and you're free to not run "check" at all if you like. > Regards, > From mdehaan at redhat.com Tue Dec 12 16:55:02 2006 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 12 Dec 2006 11:55:02 -0500 Subject: [et-mgmt-tools] Thoughts on repo mirroring... Message-ID: <457EDEE6.70704@redhat.com> A few thoughts on mirroring... "Cobbler import" provides a way of keeping the network demands of running a large install farm under control -- that is, kickstart tree content doesn't have to come from public mirrors. This means faster installs, less bandwidth, and in general being nice to community provided mirrors. One thing that cobbler hasn't been doing is to integrate this with a good repository mirroring strategy. Installs from public and private data ought to come in through the boot server, not the local university every time. I'm looking fairly closely at reposync and plain rsync right now... rsync would have some disadvantage in that it would generally bring down too much content, for instance, say you weren't interested in KDE. Comments? Thoughts? What tools are folks already using to do this? Tenatively, I see this looking something like cobbler repo add --name=foo --mirror=URL and putting something like "cobbler repo sync" on a crontab. Then, each cobbler profile would have a new optional property ("--repos") that would give information about what repositories to use by default. cobbler profile add --name=p1 --distro=d1 --repos="fc6updates fc6extras myspecialfc6repo" If a distribution being detected in an import is greater than "FC6", we know that we can add repo's directly in the kickstart based on the "repo" directive, otherwise, we'll have to tweak the kickstarts slightly differently. All of the repo assignment could be automagically filled in during kickstart templating (which is done at "cobbler sync" time). --Michael From mdehaan at redhat.com Tue Dec 12 21:58:30 2006 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 12 Dec 2006 16:58:30 -0500 Subject: [et-mgmt-tools] Thoughts on repo mirroring... In-Reply-To: <457EDEE6.70704@redhat.com> References: <457EDEE6.70704@redhat.com> Message-ID: <457F2606.5010409@redhat.com> Added some preliminary support for making local mirrors of yum repositories (rsync mirrors only thus far). Nothing incredibly magical, but it could prove useful to some as it evolves. It's checked in, but not documented (except here). Example: # cobbler repo add --name=fc6i386updates --mirror=rsync://distro.ibiblio.org/fedora-linux-core/updates/6/i386 # cobbler reposync # cobbler profile add --name=blah --distro=blah --kickstart=/tmp/foo.ks --repos="fc6i386updates" The "reposync" command would rsync any repo's cobbler knew about, and is called independently from sync. It's suitable for usage on cron, though cobbler doesn't install a crontab yet. Later, it will probably be expanded to support more types of mirroring than just rsync (i.e. reposync or using the yum API). Now, the first two commands just provide basic mirroring. The last command includes the "--repos" bit, which is only useful on FC6 and later (not sure about RHEL5?). If the foo.ks assigned to the profile contains the template line "TEMPLATE::yum_repo_stanza", that spot in the template would be replaced with the code to let Anaconda install from any repos assigned to that profile. The value of the replaced "TEMPLATE::yum_repo_stanza" entry would be ... repo --name=fc6updates --baseurl=http://172.16.57.21/repo_mirror/fc6updatesi386 The "/etc/cobbler/kickstart_fc6.ks" that ships with cobbler (from now on) has that TEMPLATE::yum_repo_stanza line in there to be used if any repos are configured. You can also specify more than one repo, i.e. "cobbler profile add ... --repos="fc6i386updates fc6i386extras mycompanyrepo" and so forth. . This is just a start, but it's a logical progression of mirroring, since the point of having a local boot server is partially to have speedy OS installs -- that should apply to upgrades too. Note that this doesn't configure yum.repos.d on the installed machine -- you'll still have to do that on your own (for now). Cobbler really shouldn't force puppet or cfengine at anyone who doesn't want it (yet) and those that are already using one can use those tools to push out the mirror configurations. Michael DeHaan wrote: > > A few thoughts on mirroring... > > "Cobbler import" provides a way of keeping the network demands of > running a large install farm under control -- that is, kickstart tree > content doesn't have to come from public mirrors. This means faster > installs, less bandwidth, and in general being nice to community > provided mirrors. One thing that cobbler hasn't been doing is to > integrate this with a good repository mirroring strategy. Installs > from public and private data ought to come in through the boot server, > not the local university every time. > > I'm looking fairly closely at reposync and plain rsync right now... > rsync would have some disadvantage in that it would generally bring > down too much content, for instance, say you weren't interested in > KDE. Comments? Thoughts? What tools are folks already using to > do this? > > Tenatively, I see this looking something like > > cobbler repo add --name=foo --mirror=URL > and putting something like > "cobbler repo sync" on a crontab. > > Then, each cobbler profile would have a new optional property > ("--repos") that would give information about what repositories to use > by default. > > cobbler profile add --name=p1 --distro=d1 --repos="fc6updates > fc6extras myspecialfc6repo" > > If a distribution being detected in an import is greater than "FC6", > we know that we can add repo's directly in the kickstart based on the > "repo" directive, otherwise, we'll have to tweak the kickstarts > slightly differently. All of the repo assignment could be > automagically filled in during kickstart templating (which is done at > "cobbler sync" time). > > --Michael > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From mdehaan at redhat.com Tue Dec 12 22:01:52 2006 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 12 Dec 2006 17:01:52 -0500 Subject: [et-mgmt-tools] Thoughts on repo mirroring... In-Reply-To: <457F2606.5010409@redhat.com> References: <457EDEE6.70704@redhat.com> <457F2606.5010409@redhat.com> Message-ID: <457F26D0.4030006@redhat.com> Formatting fixed (somewhat) below... Michael DeHaan wrote: > Added some preliminary support for making local mirrors of yum > repositories (rsync mirrors only thus far). Nothing incredibly > magical, but it could prove useful to some as it evolves. > It's checked in, but not documented (except here). > > Example: > > # cobbler repo add --name=fc6i386updates > --mirror=rsync://distro.ibiblio.org/fedora-linux-core/updates/6/i386 > # cobbler reposync > # cobbler profile add --name=blah --distro=blah > --kickstart=/tmp/foo.ks --repos="fc6i386updates" > > The "reposync" command would rsync any repo's cobbler knew about, and > is called independently from sync. It's suitable for usage on cron, > though cobbler doesn't install a crontab yet. Later, it will > probably be expanded > to support more types of mirroring than just rsync (i.e. reposync or > using the yum API). > Now, the first two commands just provide basic mirroring. The last > command includes the "--repos" bit, which is only useful on FC6 and > later (not sure about RHEL5?). If the foo.ks assigned to the profile > contains the template line "TEMPLATE::yum_repo_stanza", that spot in > the template would be replaced with the code to let Anaconda install > from any repos assigned to that profile. The value of the replaced > "TEMPLATE::yum_repo_stanza" entry would be ... > repo --name=fc6updates > --baseurl=http://172.16.57.21/repo_mirror/fc6updatesi386 > > The "/etc/cobbler/kickstart_fc6.ks" that ships with cobbler (from now > on) has that TEMPLATE::yum_repo_stanza line in there to be used if any > repos are configured. > You can also specify more than one repo, i.e. "cobbler profile add ... > --repos="fc6i386updates fc6i386extras mycompanyrepo" and so forth. . > This is just a start, but it's a logical progression of mirroring, > since the point of having a local boot server is partially to have > speedy OS installs -- that should apply to upgrades too. > > Note that this doesn't configure yum.repos.d on the installed machine > -- you'll still have to do that on your own (for now). Cobbler > really shouldn't force puppet or cfengine at anyone who doesn't want > it (yet) and those that > are already using one can use those tools to push out the mirror > configurations. > > Michael DeHaan wrote: > >> >> A few thoughts on mirroring... >> >> "Cobbler import" provides a way of keeping the network demands of >> running a large install farm under control -- that is, kickstart tree >> content doesn't have to come from public mirrors. This means faster >> installs, less bandwidth, and in general being nice to community >> provided mirrors. One thing that cobbler hasn't been doing is to >> integrate this with a good repository mirroring strategy. Installs >> from public and private data ought to come in through the boot >> server, not the local university every time. >> >> I'm looking fairly closely at reposync and plain rsync right now... >> rsync would have some disadvantage in that it would generally bring >> down too much content, for instance, say you weren't interested in >> KDE. Comments? Thoughts? What tools are folks already using to >> do this? >> >> Tenatively, I see this looking something like >> >> cobbler repo add --name=foo --mirror=URL >> and putting something like >> "cobbler repo sync" on a crontab. >> >> Then, each cobbler profile would have a new optional property >> ("--repos") that would give information about what repositories to >> use by default. >> >> cobbler profile add --name=p1 --distro=d1 --repos="fc6updates >> fc6extras myspecialfc6repo" >> >> If a distribution being detected in an import is greater than "FC6", >> we know that we can add repo's directly in the kickstart based on the >> "repo" directive, otherwise, we'll have to tweak the kickstarts >> slightly differently. All of the repo assignment could be >> automagically filled in during kickstart templating (which is done at >> "cobbler sync" time). >> >> --Michael >> >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From mdehaan at redhat.com Wed Dec 13 21:07:43 2006 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 13 Dec 2006 16:07:43 -0500 Subject: [et-mgmt-tools] Re: strange email server message (email refused from redhat.com) In-Reply-To: <1be610000612131230m6d03883eu69fdc6c239b24fc2@mail.gmail.com> References: <1be610000612131230m6d03883eu69fdc6c239b24fc2@mail.gmail.com> Message-ID: <45806B9F.1060607@redhat.com> Hmmm ... it appears the redhat.com spam blocker is starting to be aggressive. Sorry about that. Thanks for the work. Downside: I can't take this patch with explicit python2.3 usage in spec and Makefiles, though if you want to maintain a Centos port, that's great. I could possibly check in a patchset and add it to README if you want to leave it in the tree under "contrib" or the like. Mind if I CC this to et-mgmt-dev at redhat.com? --Michael Tru wrote: > Hi, > > I get the following email server refusal on the last email I tried to > send you from my office account, thus this mail from gmail. > > > The original message was received at Thu, 7 Dec 2006 18:43:48 -0500 > from electre.pasteur.fr [157.99.64.120] > > ----- The following addresses had permanent fatal errors ----- > > (reason: 451 4.1.8 Domain of sender address tru at pasteur.fr does not > resolve) > (expanded from: ) > > (reason: 451 4.1.8 Domain of sender address tru at pasteur.fr does not > resolve) > (expanded from: ) > > ----- Transcript of session follows ----- > ... while talking to int-mx2.corp.redhat.com.: >>>> MAIL From: SIZE=3659 BODY=8BITMIME > <<< 451 4.1.8 Domain of sender address tru at pasteur.fr does not resolve > ,... Deferred: 451 4.1.8 > Domain of sender address tru at pasteur.fr does not resolve > Message could not be delivered for 5 days > Message will be deleted from queue > > Reporting-MTA: dns; mx2.redhat.com > Arrival-Date: Thu, 7 Dec 2006 18:43:48 -0500 > > Final-Recipient: RFC822; mdehaan at redhat.com > Action: failed > Status: 4.4.7 > Diagnostic-Code: SMTP; 451 4.1.8 Domain of sender address > tru at pasteur.fr does not resolve > Last-Attempt-Date: Tue, 12 Dec 2006 18:52:47 -0500 > > Final-Recipient: RFC822; et-mgmt-tools at redhat.com > Action: failed > Status: 4.4.7 > Diagnostic-Code: SMTP; 451 4.1.8 Domain of sender address > tru at pasteur.fr does not resolve > Last-Attempt-Date: Tue, 12 Dec 2006 18:52:47 -0500 > > Date: Fri, 8 Dec 2006 00:42:32 +0100 > From: Tru Huynh > To: Michael DeHaan > Cc: et-mgmt-tools at redhat.com > Subject: Re: [et-mgmt-tools] Old Stuff Needs To Work Too: Lilo > compatibility / Koan and RHEL3 > User-Agent: Mutt/1.5.11 > > On Thu, Dec 07, 2006 at 05:54:42PM -0500, Michael DeHaan wrote: >> Two things: >> >> === >> >> One. >> > [...] >> Two. >> >> The other thing I'm going to be doing shortly is making koan compilable >> with RHEL3 -- some users don't have PXE setups (cobbler can provision >> RHEL3 via PXE fine), and currently koan and "enchant" won't work for >> them there. So, when this gets done, Cobbler will support RHEL4+, >> derivatives, and FC5+ -- and koan will support all of that with the >> addition of RHEL 3. Obviously, no virtualization support on RHEL 3... >> > > two.1 ;) > > cobbler for RHEL3/CentOS-3 would need python2.3 (not overwritting the > system > python2.2) and the following patch :) > > [tru at sillage cobbler]$ hg diff Makefile > diff -r 791cb0e080da Makefile > --- a/Makefile Tue Dec 05 11:04:38 2006 -0500 > +++ b/Makefile Wed Nov 15 19:47:47 2006 +0100 > @@ -5,15 +5,15 @@ clean: > -rm -rf cobbler-* dist build > > manpage: > - pod2man --center="cobbler" --release="" cobbler.pod | gzip -c >> cobbler.1.gz > + pod2man --center="cobbler" --release="`grep '^Version' > cobbler.spec| awk '{print $2}'`" cobbler.pod | gzip -c > cobbler.1.gz > pod2html cobbler.pod > cobbler.html > > test: > - python tests/tests.py > + python2.3 tests/tests.py > -rm -rf /tmp/_cobbler-* > > rpm: clean manpage > - python setup.py sdist > + python2.3 setup.py sdist > cp dist/*.gz . > rpmbuild --define "_topdir %(pwd)" \ > --define "_builddir %{_topdir}" \ > @@ -22,4 +22,5 @@ rpm: clean manpage > --define '_rpmfilename > %%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm' \ > --define "_specdir %{_topdir}" \ > --define "_sourcedir %{_topdir}" \ > + --define "__python python2.3" \ > -ba cobbler.spec > > > > [tru at sillage cobbler]$ hg diff cobbler.spec > diff -r 791cb0e080da cobbler.spec > --- a/cobbler.spec Tue Dec 05 11:04:38 2006 -0500 > +++ b/cobbler.spec Fri Dec 08 00:37:31 2006 +0100 > @@ -7,7 +7,7 @@ Source0: %{name}-%{version}.tar.gz > Source0: %{name}-%{version}.tar.gz > License: GPL > Group: Applications/System > -Requires: python >= 2.3 > +Requires: python2.3 > Requires: httpd > Requires: tftp-server > BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot > @@ -53,6 +53,9 @@ test "x$RPM_BUILD_ROOT" != "x" && rm -rf > %doc AUTHORS CHANGELOG NEWS README COPYING > > %changelog > +* Fri Dec 8 2006 Tru Huynh - > +- CentOS-3 build > +- python2.3 ... > > * Tue Dec 05 2006 Michael DeHaan - 0.3.4-1 > - Upstream changes (see CHANGELOG) > > > Cheers. > > Tru > -- > Dr Tru Huynh | http://www.pasteur.fr/recherche/unites/Binfs/ > mailto:tru at pasteur.fr | tel/fax +33 1 45 68 87 37/19 > Institut Pasteur, 25-28 rue du Docteur Roux, 75724 Paris CEDEX 15 > France > From mdehaan at redhat.com Wed Dec 13 21:10:09 2006 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 13 Dec 2006 16:10:09 -0500 Subject: [et-mgmt-tools] Re: strange email server message (email refused from redhat.com) In-Reply-To: <45806B9F.1060607@redhat.com> References: <1be610000612131230m6d03883eu69fdc6c239b24fc2@mail.gmail.com> <45806B9F.1060607@redhat.com> Message-ID: <45806C31.2070609@redhat.com> Already added et-mgmt-tools accidentally w/o asking ... my apologies on that. Folks -- apparently Cobbler is happy on RHEL 3 and Centos 3.X with some build modifications. For those wanting to use that as boot server, the content below may be interesting. Michael DeHaan wrote: > Hmmm ... it appears the redhat.com spam blocker is starting to be > aggressive. Sorry about that. > > Thanks for the work. > Downside: I can't take this patch with explicit python2.3 usage in > spec and Makefiles, though if you want to maintain a Centos port, > that's great. > > I could possibly check in a patchset and add it to README if you want > to leave it in the tree under "contrib" or the like. Mind if I CC > this to et-mgmt-dev at redhat.com? > > --Michael > > > > Tru wrote: >> Hi, >> >> I get the following email server refusal on the last email I tried to >> send you from my office account, thus this mail from gmail. >> >> >> The original message was received at Thu, 7 Dec 2006 18:43:48 -0500 >> from electre.pasteur.fr [157.99.64.120] >> >> ----- The following addresses had permanent fatal errors ----- >> >> (reason: 451 4.1.8 Domain of sender address tru at pasteur.fr does >> not resolve) >> (expanded from: ) >> >> (reason: 451 4.1.8 Domain of sender address tru at pasteur.fr does >> not resolve) >> (expanded from: ) >> >> ----- Transcript of session follows ----- >> ... while talking to int-mx2.corp.redhat.com.: >>>>> MAIL From: SIZE=3659 BODY=8BITMIME >> <<< 451 4.1.8 Domain of sender address tru at pasteur.fr does not resolve >> ,... Deferred: 451 4.1.8 >> Domain of sender address tru at pasteur.fr does not resolve >> Message could not be delivered for 5 days >> Message will be deleted from queue >> >> Reporting-MTA: dns; mx2.redhat.com >> Arrival-Date: Thu, 7 Dec 2006 18:43:48 -0500 >> >> Final-Recipient: RFC822; mdehaan at redhat.com >> Action: failed >> Status: 4.4.7 >> Diagnostic-Code: SMTP; 451 4.1.8 Domain of sender address >> tru at pasteur.fr does not resolve >> Last-Attempt-Date: Tue, 12 Dec 2006 18:52:47 -0500 >> >> Final-Recipient: RFC822; et-mgmt-tools at redhat.com >> Action: failed >> Status: 4.4.7 >> Diagnostic-Code: SMTP; 451 4.1.8 Domain of sender address >> tru at pasteur.fr does not resolve >> Last-Attempt-Date: Tue, 12 Dec 2006 18:52:47 -0500 >> >> Date: Fri, 8 Dec 2006 00:42:32 +0100 >> From: Tru Huynh >> To: Michael DeHaan >> Cc: et-mgmt-tools at redhat.com >> Subject: Re: [et-mgmt-tools] Old Stuff Needs To Work Too: Lilo >> compatibility / Koan and RHEL3 >> User-Agent: Mutt/1.5.11 >> >> On Thu, Dec 07, 2006 at 05:54:42PM -0500, Michael DeHaan wrote: >>> Two things: >>> >>> === >>> >>> One. >>> >> [...] >>> Two. >>> >>> The other thing I'm going to be doing shortly is making koan compilable >>> with RHEL3 -- some users don't have PXE setups (cobbler can provision >>> RHEL3 via PXE fine), and currently koan and "enchant" won't work for >>> them there. So, when this gets done, Cobbler will support RHEL4+, >>> derivatives, and FC5+ -- and koan will support all of that with the >>> addition of RHEL 3. Obviously, no virtualization support on RHEL 3... >>> >> >> two.1 ;) >> >> cobbler for RHEL3/CentOS-3 would need python2.3 (not overwritting the >> system >> python2.2) and the following patch :) >> >> [tru at sillage cobbler]$ hg diff Makefile >> diff -r 791cb0e080da Makefile >> --- a/Makefile Tue Dec 05 11:04:38 2006 -0500 >> +++ b/Makefile Wed Nov 15 19:47:47 2006 +0100 >> @@ -5,15 +5,15 @@ clean: >> -rm -rf cobbler-* dist build >> >> manpage: >> - pod2man --center="cobbler" --release="" cobbler.pod | gzip -c >>> cobbler.1.gz >> + pod2man --center="cobbler" --release="`grep '^Version' >> cobbler.spec| awk '{print $2}'`" cobbler.pod | gzip -c > cobbler.1.gz >> pod2html cobbler.pod > cobbler.html >> >> test: >> - python tests/tests.py >> + python2.3 tests/tests.py >> -rm -rf /tmp/_cobbler-* >> >> rpm: clean manpage >> - python setup.py sdist >> + python2.3 setup.py sdist >> cp dist/*.gz . >> rpmbuild --define "_topdir %(pwd)" \ >> --define "_builddir %{_topdir}" \ >> @@ -22,4 +22,5 @@ rpm: clean manpage >> --define '_rpmfilename >> %%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm' \ >> --define "_specdir %{_topdir}" \ >> --define "_sourcedir %{_topdir}" \ >> + --define "__python python2.3" \ >> -ba cobbler.spec >> >> >> >> [tru at sillage cobbler]$ hg diff cobbler.spec >> diff -r 791cb0e080da cobbler.spec >> --- a/cobbler.spec Tue Dec 05 11:04:38 2006 -0500 >> +++ b/cobbler.spec Fri Dec 08 00:37:31 2006 +0100 >> @@ -7,7 +7,7 @@ Source0: %{name}-%{version}.tar.gz >> Source0: %{name}-%{version}.tar.gz >> License: GPL >> Group: Applications/System >> -Requires: python >= 2.3 >> +Requires: python2.3 >> Requires: httpd >> Requires: tftp-server >> BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot >> @@ -53,6 +53,9 @@ test "x$RPM_BUILD_ROOT" != "x" && rm -rf >> %doc AUTHORS CHANGELOG NEWS README COPYING >> >> %changelog >> +* Fri Dec 8 2006 Tru Huynh - >> +- CentOS-3 build >> +- python2.3 ... >> >> * Tue Dec 05 2006 Michael DeHaan - 0.3.4-1 >> - Upstream changes (see CHANGELOG) >> >> >> Cheers. >> >> Tru >> -- >> Dr Tru Huynh | http://www.pasteur.fr/recherche/unites/Binfs/ >> mailto:tru at pasteur.fr | tel/fax +33 1 45 68 87 37/19 >> Institut Pasteur, 25-28 rue du Docteur Roux, 75724 Paris CEDEX 15 >> France >> > > From mdehaan at redhat.com Wed Dec 13 22:45:36 2006 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 13 Dec 2006 17:45:36 -0500 Subject: [et-mgmt-tools] Thoughts on repo mirroring... In-Reply-To: <457F26D0.4030006@redhat.com> References: <457EDEE6.70704@redhat.com> <457F2606.5010409@redhat.com> <457F26D0.4030006@redhat.com> Message-ID: <45808290.6050403@redhat.com> Michael DeHaan wrote: First off, if this sounds like greek, let me know, and I'll try to explain something differently. I'm as guilty as speaking tech lingo as anyone. This is probably starting to sound like "cobbler-dev" lately and not a user list, though repo mirroring is starting to evolve some and some folks may have thoughts on it -- so I wanted to bring these items up rather than just secretly implement them and have to explain them later. Imagine you can do this: # mirror a kickstart tree (this will take a while, but you only have to do it once per distro) cobbler import --mirror-name="ibiblio_fedora6_i386" --mirror="rsync://distro.ibiblio.org/fedora-linux-core/6/i386" # also add some additional repos to mirror cobbler repo add --name="fc6i386updates" --mirror="rsync://distro.ibiblio.org/fedora-linux-core/updates/6/i386" --local-filename="fedora-extras" # create a profile that says "use this distro and these repos" cobbler profile add --name="fc6i386" --distro="var_www_cobbler_ks_mirror_ibiblio_i386_os_images_pxeboot" --repos="fc6i386updates" # tell systems how to boot by default cobbler system add --name=default --profile="fc6i386" # update/copy the repos via rsync (this will take a while the first time, and then will be pretty fast) cobbler reposync # you'll probably want to add this to cron # apply the cobbler configuration cobbler sync Ok, so in upstream mercurial code (though it needs a good deal of testing) -- you can do exactly that. What do these commands do? They create a local mirror of Fedora Core 6 and Extras, from a public rsync mirror, that you can provision off of. That was there previously -- it's not news. In addition, you've just configured an FC6 update mirror (that you can update at will) that any boxes you provision off of that profile will use for updates, by default -- this IS new. So, if you get a 1000 baremetal machines in on a truck (Merry Christmas?) and want to set up a boot server for all of them -- and never have them ask the outside world for package updates, that's one way you could do it. This is a good way to set up boxes that know about custom repositories as well. Before cobbler mirrored the kickstart tree, which was nice, but there was no concept of mirroring packages not in that original tree -- which is very closely related and just as important when we are talking about "mirroring" as opposed to just finding some way to make installs happen. This _will_ probably change some, but I wanted to pass along the direction of where I wanted to take the boot server. I may be looking at Pungi (http://jkeating.livejournal.com/32250.html) some also, though support for non-Pungi compatible distros needs to be maintained in some form. Pungi would be interesting in that we could define a cobbler distribution as a set of repository URLs and packages, rather than defining it as a kernel, initrd, kickstart tree, and other repos (basically it would be a lot simpler). Basically it's a custom repo and install CD composing tool. Again though, non-Pungi compatible distros need to have some support too, and that _might_ not extend far beyond the rsync:// support that is there now. Fire away if you have any comments/ideas/questions on this... "I'm confused" is ok too :) --Michael From dmourati at gmail.com Wed Dec 13 23:03:28 2006 From: dmourati at gmail.com (Demetri Mouratis) Date: Wed, 13 Dec 2006 15:03:28 -0800 Subject: [et-mgmt-tools] Thoughts on repo mirroring... In-Reply-To: <45808290.6050403@redhat.com> References: <457EDEE6.70704@redhat.com> <457F2606.5010409@redhat.com> <457F26D0.4030006@redhat.com> <45808290.6050403@redhat.com> Message-ID: <3cc2cbc40612131503n1bf813e9y2d1d8cca2c913de0@mail.gmail.com> On 12/13/06, Michael DeHaan wrote: > Michael DeHaan wrote: > > First off, if this sounds like greek, let me know, and I'll try to > explain something differently. I'm as guilty as speaking tech lingo as > anyone. > > This is probably starting to sound like "cobbler-dev" lately and not a > user list, though repo mirroring is starting to evolve some and some > folks may have thoughts on it -- so I wanted to bring these items up > rather than just secretly implement them and have to explain them later. > > Imagine you can do this: Michael, For the first time, I'm starting to feel like the target of the saying "Go away, or I will replace you with a very small shell script." As I've said, I work with repository mirroring quite a bit so this new direction and the completeness with which you have addressed the requirements is appreciated. Some notes. Not sure whether you have thought about this, but the rsync out of cron has the potential to blow up if not locked correctly. I'm not too sure of the pungi direction. It seems to me comps.xml is not meant to be mucked with. I've gone down that road before and came away quite scathed. Thanks. -D From mdehaan at redhat.com Wed Dec 13 23:08:10 2006 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 13 Dec 2006 18:08:10 -0500 Subject: [et-mgmt-tools] Thoughts on repo mirroring... In-Reply-To: <3cc2cbc40612131503n1bf813e9y2d1d8cca2c913de0@mail.gmail.com> References: <457EDEE6.70704@redhat.com> <457F2606.5010409@redhat.com> <457F26D0.4030006@redhat.com> <45808290.6050403@redhat.com> <3cc2cbc40612131503n1bf813e9y2d1d8cca2c913de0@mail.gmail.com> Message-ID: <458087DA.1050200@redhat.com> Demetri Mouratis wrote: > On 12/13/06, Michael DeHaan wrote: >> Michael DeHaan wrote: >> >> First off, if this sounds like greek, let me know, and I'll try to >> explain something differently. I'm as guilty as speaking tech lingo as >> anyone. >> >> This is probably starting to sound like "cobbler-dev" lately and not a >> user list, though repo mirroring is starting to evolve some and some >> folks may have thoughts on it -- so I wanted to bring these items up >> rather than just secretly implement them and have to explain them later. >> >> Imagine you can do this: > > > Michael, > > For the first time, I'm starting to feel like the target of the saying > "Go away, or I will replace you with a very small shell script." > Or a really big python script? :) > As I've said, I work with repository mirroring quite a bit so this new > direction and the completeness with which you have addressed the > requirements is appreciated. Thanks! > Some notes. Not sure whether you have thought about this, but the > rsync out of cron has the potential to blow up if not locked > correctly. > I could probably leverage your experience in that direction -- if you'd like to contribute to the codebase, your input would be very welcome. By "blow up", perhaps you mean simultaneous rsync's to the same locations? Yeah, that _does_ need to be locked. Cobbler has some built-in locking that I haven't turned on in production, that I probably should turn on. Duplicate cobbler sync's at the same time aren't nice either. > I'm not too sure of the pungi direction. It seems to me comps.xml is > not meant to be mucked with. I've gone down that road before and came > away quite scathed. I've heard that before, oddly enough -- though I'm not very familiar with it yet. If it seems bizarre, I'll stop. > > Thanks. > > -D From tru.huynh at gmail.com Wed Dec 13 21:39:59 2006 From: tru.huynh at gmail.com (Tru) Date: Wed, 13 Dec 2006 22:39:59 +0100 Subject: [et-mgmt-tools] Re: strange email server message (email refused from redhat.com) In-Reply-To: <45806C31.2070609@redhat.com> References: <1be610000612131230m6d03883eu69fdc6c239b24fc2@mail.gmail.com> <45806B9F.1060607@redhat.com> <45806C31.2070609@redhat.com> Message-ID: <1be610000612131339h7d01a420jeb0ce75e2735f421@mail.gmail.com> On 12/13/06, Michael DeHaan wrote: > Already added et-mgmt-tools accidentally w/o asking ... my apologies on > that. No problem, and concerning python2.3 for CentOS-3, it's an easy (so far) backport from CentOS-4. I haven't really start playing with cobbler, but it builds and installs fine and run the basic commands. Cheers, Tru From mdehaan at redhat.com Wed Dec 20 21:35:47 2006 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 20 Dec 2006 16:35:47 -0500 Subject: [et-mgmt-tools] Cobbler 0.3.5 going out Message-ID: <4589ACB3.80708@redhat.com> Changelog below -- what I intend to ship for 0.3.5 is already checked in upstream. This should hit cobbler.et.redhat.com shortly, and Fedora Extras shortly after that (maybe tomorrow). The main point of this release is to include the new repo mirroring features and the associated integration with kickstart, as mentioned previously on this mailing list. However there were some bugs fixed a long the way that most people should be interested in. I noticed a Xen provisioning bug in a post to Fedora-Xen back in November -- which kind of indicates not too many folks are interested in deploying Xen automatically. That's ok. * Mon Dec 18 2006 - 0.3.5-1 - Fixed bug in cobbler import related to orphan detection - Made default rsync.exclude more strict (OO langpacks and KDE translation) - Now runs createrepo during "cobbler import" to build more correct repodata - Added additional repo mirroring commands: "cobbler repo add", etc - Documentation on repo mirroring features. - fix bug in rsync:// import code that saved distributions in the wrong path - The --dryrun option on "cobbler sync" is now unsupported. - Fixed bug in virt specific profile information not being used with koan - import now takes --name in addition to --mirror-name to be more consistant - rsync repo import shouldn't assume SSH unless no rsync:// in mirror URL - strict host key checking disabled for "cobbler enchant" feature Repo mirroring in 0.3.5 is limited to rsync, whether rsync protocol (rsync://foo) or SSH (root at address:/directory). I may add support for yum-util's reposync later -- I had it working at one point and unfortunately clobbered the code, so I'll have to re add it. repotrack will add support for mirroring yum repos over http://. Not to be confused with the cobbler "reposync" command, of course, which is the generic version. Please pound on the rsync support in the near term to see if anything needs improvement. A few things on my shortlist include (A) the ability to provision Xen as "enchant" currently works now and (B) kickstart tracking (probably by serving kickstart files and the like through an Apache proxy) -- so you'll be able to watch your systems kickstart remotely, or at least, see what files they transfer. As usual, feedback/comments/questions welcome. --Michael From mdehaan at redhat.com Wed Dec 20 21:41:27 2006 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 20 Dec 2006 16:41:27 -0500 Subject: [et-mgmt-tools] Fully automated kickstarts for your distro Message-ID: <4589AE07.4070002@redhat.com> I've just noticed that the kickstarts that ship in /etc/cobbler/, (ex: /etc/cobbler/kickstart_fc5.ks) aren't fully automatic as they pause at the partitioning screen. If anyone has any fully automatic kickstarts or refinements to the existing one they would like to contribute (for your distro or across the board), they would be appreciated. I'll mention you in AUTHORS if that works as a bribe :) Thanks, --Michael From dlutter at redhat.com Thu Dec 21 00:31:33 2006 From: dlutter at redhat.com (David Lutterkort) Date: Wed, 20 Dec 2006 16:31:33 -0800 Subject: [et-mgmt-tools] cft through changes - sabayon-like tool for sysadmins Message-ID: <1166661093.18520.106.camel@localhost.localdomain> I've started working on a new tool that helps tracking changes to a system's configuration, especially when it is controlled by puppet[1]. The tool is called cft (pronounced 'sift') and is inspired by Gnome's Sabayon[2] in that it watches how an admin changes a system and spits out a puppet manifest based on its observations. Cft's website is http://cft.et.redhat.com/ , sources can be found in the mercurial repo at http://hg.et.redhat.com/hg/emd/applications/cft (the README and TODO files contain juicier details on how cft does what it does and possible future direction) For discussions, please use this list. Enjoy, David [1] http://reductivelabs.com/projects/puppet [2] http://www.gnome.org/~seth/blog/sabayon From David.Mackintosh at xdroop.com Thu Dec 21 16:40:46 2006 From: David.Mackintosh at xdroop.com (David Mackintosh) Date: Thu, 21 Dec 2006 11:40:46 -0500 Subject: [et-mgmt-tools] Cobbler 0.3.4-1 comments Message-ID: <20061221164046.GC6613@xdroop.com> Hi there, I've just done a moderate sized cobbler installation (currently twelve distros with more to come, eventually more than a hundred systems) and have a few comments based on what I have seen so far. These are probably minor quibbles. This is installed from the 0.3.4-1.src.rpm 1. Cobbler doesn't appear to understand -v, -V, or --version ...which isn't entirely necessary if it is installed from rpm (rpm -qa | grep cobbler gets me the info I needed) but it would still be nice. 2. Brief output should at least be an option, if not a default. I want the equivilent of # cobbler list --profiles | grep profile ...since the vast majority of the time I don't care about the details of a profile, I only want to see the list of names because I have so many of them I've forgotten what I called the one I want. Yes this is mostly my fault for frequently forgetting/changing my "standards" but it would be nice if the tool could help. 3. Semantically, since cobbler uses # cobbler system add [...] ...cobbler should therefore understand # cobbler system list ...instead of requiring # cobbler list --systems I have nothing against the latter, but the former fits more semantically into the COMMAND OBJECT ACTION model I like to use. Perhaps this form of the command would be a good place to put the brief output. Or maybe you want to change the other commands to the form # cobbler add --system ...but either way it should be more consistant. 4. Sorted output would be nice. The output of the various lists are not sorted by either order-added or some kind of alpha-numerical sort; either would be adequate, and the latter obviously preferred. One could even argue that since the "index" of a profile/distro/name which preceeds the name will probably change as other things are added and removed, and are not used anywhere (ie you can't refer to a profile as "profile #3" anywhere) it should be dropped entirely from the output. 5. Unless I misunderstand something, if I define my profiles with URLs to ks.cfg files instead of file references, there is nothing served through httpd by cobbler. In this case it would be nice if cobbler didn't restart my httpd every time I ran cobbler sync. 6. If manage_dhcp is set to 0, cobbler check should not complain about missing dhcpd pieces. In my case dhcpd is on another system under another set of script's control, so cobbler needn't be bothered about those details. Maybe an option to tell it not to warn about those kinds of things would be in order (squelch_dhcp_warnings or something). END COMMENTS All that said, these are exceedingly minor quibbles. Cobbler has already saved me a ton of time and made me look good in front of two moderately-sized customers (always a plus). I do have a question about the implementation -- is there anything that would prevent cobbler from running on, say, a Solaris system? I ask because I already have a fairly extensive host-management system set up that runs on Solaris, and it would be reasonably straight-forward to integrate cobbler into it so that a user could say # need_shoes --system="text-name" --profile="profile-name" (ie need_shoes asks the cobbler for boots, or maybe you'd name it after a shoe vendor or something... to beat a naming convention to death :) ...and have that script dig the IP address and MAC out of NIS, doctor dhcpd (if necessary -- I'm already doing much of that, which is why in my past comments I was resistant to cobbler doing it as well), and do the final "cobbler sync" automatically, making it a one-stop for my administrators. A second question -- while thinking about #5 above, it occured to me that I don't immediately understand why cobbler copies the vmlinuz and initrd.img files into the httpd tree. Why do you do that? Thanks again for cobbler. -- /\oo/\ / /()\ \ David Mackintosh | dave at xdroop.com | http://www.xdroop.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mdehaan at redhat.com Thu Dec 21 17:13:08 2006 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 21 Dec 2006 12:13:08 -0500 Subject: [et-mgmt-tools] Cobbler 0.3.4-1 comments In-Reply-To: <20061221164046.GC6613@xdroop.com> References: <20061221164046.GC6613@xdroop.com> Message-ID: <458AC0A4.20303@redhat.com> David, Thanks for the feedback, a few comments below... I'll look into incorporating some of this into 0.3.6. David Mackintosh wrote: > Hi there, > > I've just done a moderate sized cobbler installation (currently > twelve distros with more to come, eventually more than a hundred > systems) and have a few comments based on what I have seen so far. > These are probably minor quibbles. > > This is installed from the 0.3.4-1.src.rpm > > 1. Cobbler doesn't appear to understand -v, -V, or --version > > ...which isn't entirely necessary if it is installed from rpm > (rpm -qa | grep cobbler gets me the info I needed) but it would > still be nice. > That's valid, though I would hope everyone is always installing from the RPM. > 2. Brief output should at least be an option, if not a default. > > I want the equivilent of > > # cobbler list --profiles | grep profile > > ...since the vast majority of the time I don't care about the details > of a profile, I only want to see the list of names because I have so > many of them I've forgotten what I called the one I want. Yes this > is mostly my fault for frequently forgetting/changing my "standards" > but it would be nice if the tool could help. > This would be a good add. > 3. Semantically, since cobbler uses > > # cobbler system add [...] > > ...cobbler should therefore understand > > # cobbler system list > > ...instead of requiring > > # cobbler list --systems > > I have nothing against the latter, but the former fits more > semantically into the COMMAND OBJECT ACTION model I like to use. > Perhaps this form of the command would be a good place to put the > brief output. > I find myself typing the same things occasionally and wondering why I didn't do it that way :) Perhaps "cobbler system list" and "cobbler system list --full". > Or maybe you want to change the other commands to the form > > # cobbler add --system > > ...but either way it should be more consistant. > > 4. Sorted output would be nice. > > The output of the various lists are not sorted by either order-added > or some kind of alpha-numerical sort; either would be adequate, and > the latter obviously preferred. > This makes good sense and is an easy fix. > One could even argue that since the "index" of a profile/distro/name > which preceeds the name will probably change as other things are > added and removed, and are not used anywhere (ie you can't refer to a > profile as "profile #3" anywhere) it should be dropped entirely from > the output. > True. > 5. Unless I misunderstand something, if I define my profiles with > URLs to ks.cfg files instead of file references, there is nothing > served through httpd by cobbler. In this case it would be nice > if cobbler didn't restart my httpd every time I ran cobbler sync. > Yes and no. The restart /is/ unneccessary. As to why the web directory is there, cobbler's web directory is also used to serve up configuration files for koan as well as to mirror kickstart trees and (in 0.3.5) yum repositories. Adding some logic to know when a restart is required does make sense, though. Basically once cobbler is used beyond minimal PXE support, the web directory starts to grow increasingly important. > 6. If manage_dhcp is set to 0, cobbler check should not complain > about missing dhcpd pieces.In my case dhcpd is on another system under another set of script'scontrol, so cobbler needn't be bothered about those details. Maybe an option to tell it not to warn about those kinds of things would > be in order (squelch_dhcp_warnings or something). > > END COMMENTS > > Cobbler check is there for people who really don't know what setting up a PXE environment entails (i.e. whether or not they set up next-server or not), and can use those pointers. Those that understand the warnings should be able to know when they don't apply. They do apply when manage_dhcp is not set and the user is running a local DHCP server. This should probably stay as is, though if the warnings are confusing, they definitely should be amended, and I could use some suggestions as to how they were confusing and what you think they ought to say instead. > All that said, these are exceedingly minor quibbles. Cobbler has > already saved me a ton of time and made me look good in front of two > moderately-sized customers (always a plus). > > I do have a question about the implementation -- is there anything > that would prevent cobbler from running on, say, a Solaris system? I > ask because I already have a fairly extensive host-management system > set up that runs on Solaris, and it would be reasonably > straight-forward to integrate cobbler into it so that a user could > say > > # need_shoes --system="text-name" --profile="profile-name" > > (ie need_shoes asks the cobbler for boots, or maybe you'd name it after > a shoe vendor or something... to beat a naming convention to death :) > > ...and have that script dig the IP address and MAC out of NIS, doctor > dhcpd (if necessary -- I'm already doing much of that, which is why in > my past comments I was resistant to cobbler doing it as well), and > do the final "cobbler sync" automatically, making it a one-stop for > my administrators. > Cobbler's rather RHEL/Fedora/Centos centric at this point, and I really don't intend on changing that. Namely it knows the job it needs to do and wants to do that job well. I _do_ think it is reasonable to be able to provision other forms of targets, similarly to the steps cobbler already takes to allow PXE provisioning of IA64 Linux systems (which require different bootloader configuration files). So if it's just something that involves some minor support in action_sync.py to build a slightly different bootloader config, that might be a good patch candidate. > A second question -- while thinking about #5 above, it occured to me > that I don't immediately understand why cobbler copies the vmlinuz > and initrd.img files into the httpd tree. Why do you do that? > It's all about koan. Koan allows for provisioning of remote systems when a PXE environment is not available. For instance: "yum install koan" "koan --replace-self --server=cobbler.example.com --profile=fc6test" /sbin/reboot Koan also does virtual image installs (currently it only supports Xen, though this will probably expand later): "yum install koan" "koan --virt --server=cobbler.example.com --profile=myvirtualwebserver" > Thanks again for cobbler. > > You're welcome! Thanks again for the comments! > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From mdehaan at redhat.com Thu Dec 21 17:26:49 2006 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 21 Dec 2006 12:26:49 -0500 Subject: [et-mgmt-tools] Cobbler 0.3.4-1 comments In-Reply-To: <458AC0A4.20303@redhat.com> References: <20061221164046.GC6613@xdroop.com> <458AC0A4.20303@redhat.com> Message-ID: <458AC3D9.4050505@redhat.com> Michael DeHaan wrote: > >> A second question -- while thinking about #5 above, it occured to me >> that I don't immediately understand why cobbler copies the vmlinuz >> and initrd.img files into the httpd tree. Why do you do that? >> > It's all about koan. Koan allows for provisioning of remote systems > when a PXE environment is not available. > > For instance: > > "yum install koan" > "koan --replace-self --server=cobbler.example.com --profile=fc6test" > /sbin/reboot > > Koan also does virtual image installs (currently it only supports Xen, > though this will probably expand later): > > "yum install koan" > "koan --virt --server=cobbler.example.com --profile=myvirtualwebserver" > Here's another use case that might be more illustrative of koan's capabilities. Suppose you have a running machine "foo" on your network, running Linux, and you want to re-provision it (say the box is sick, or you just want to do something else with it -- maybe it's in a university lab or render-farm and gets re-provisioned every night, even). Cobbler has a build in feature called "enchant", where that system can be automatically re-provisioned from the cobbler server, without manually logging on the remote to run "koan". cobbler enchant --address=foo.example.com --profile=fc6test For this to work best, one would have the ssh public key of the cobbler server in authorized_keys on the provisioned box. The best time to place the key there, of course, is during the provisioning process using kickstart %post. If the ssh key isn't on there, you'll have to enter password information, in which case, ssh-agent might be handy. It works either way. Enchant logs into the remote system, installs the prereqs for koan (using yum or up2date as appropriate), installs the koan noarch RPM (by grabbing it from the cobbler server), and then runs the "koan --replace-self" command. That command in turn downloads the cobbler profile information (including already templated kickstarts, the kernel, initrd, and so forth, and edits the boot-loader config (lilo or grub, as detected) and adds a kickstart entry in the top of the boot list. Then it reboots the system. So, with one remote command on the cobbler server, you can re-provision an existing Linux system, sans PXE. This is especially important in places that don't have PXE setups, for whatever reason -- including older hardware that isn't PXEable and IT environments that, for whatever reason, won't allow proper DHCP configuration. I use this in my office all the time, as it's lot easier than keeping media around, and I don't have to worry about BIOS idiosyncrasies. --Michael From mdehaan at redhat.com Thu Dec 21 20:33:09 2006 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 21 Dec 2006 15:33:09 -0500 Subject: [et-mgmt-tools] Cobbler 0.3.4-1 comments In-Reply-To: <77abe410612211149p3992e0adl82b56e6d5bebaa83@mail.gmail.com> References: <20061221164046.GC6613@xdroop.com> <458AC0A4.20303@redhat.com> <77abe410612211149p3992e0adl82b56e6d5bebaa83@mail.gmail.com> Message-ID: <458AEF85.7070605@redhat.com> Florian Heigl wrote: > Hi Michael, > > 2006/12/21, Michael DeHaan : >> David, > ... SNIP ... > > I think the other tasks could be worked around by having boot_shoes a > frontend pointing to either of cobbler / jumpstart / ignite / > 'whatever' call or config change. on the other hand one could still do > that while running cobbler on a RHEL host, I think. > Basically, I don't want to see "if this is Solaris, do this" all over Cobbler without there being a pluggable system in place for allowing cobbler to be able to provision anything, in an abstract way. If such a system existed, it would need to be able to support things like the inclusion of the BSD's, Debian, Gentoo, and so on over time. I'm ok with the short hacks that I made to support IA64 as they aren't incredibly invasive, but foreign distro support would be much more involved. Previously someone asked about FreeBSD provisioning, and yes, it would be nice ... but I didn't get any volunteers to implement it. Here's the real reason to say no to Solaris -- the complexity of maintaining such an abstract multi-OS provisioning framework is immense, and it will result in less feature development on things that can help those who want to manage boot and update servers for RHEL and Fedora based distributions. This is where I want to concentrate work on cobbler -- where it can make the most impact. I think it would be a major oversight to spend time to add halfway-working PXE-only Solaris support when the same amount of time could be used creating a superior provisioning solution for Fedora, RHEL, and Centos environments. Namely cobbler should be acting as a central hub for deployment (and yum update) needs, and it should be concentrating on how it can do that task better. As for things like integration with NIS (or LDAP), yes, wrapper scripts sound like a good solution. Hope that at least provides some insight into my thought process there and what I see cobbler's role as. --Michael > besides, the original mail showed how good cobbler already is at what > it does :> > > regards, > florian From David.Mackintosh at xdroop.com Thu Dec 21 20:36:22 2006 From: David.Mackintosh at xdroop.com (David Mackintosh) Date: Thu, 21 Dec 2006 15:36:22 -0500 Subject: [et-mgmt-tools] Cobbler 0.3.4-1 comments In-Reply-To: <458AC3D9.4050505@redhat.com> References: <20061221164046.GC6613@xdroop.com> <458AC0A4.20303@redhat.com> <458AC3D9.4050505@redhat.com> Message-ID: <20061221203622.GD6613@xdroop.com> On Thu, Dec 21, 2006 at 12:26:49PM -0500, Michael DeHaan wrote: > >It's all about koan. Koan allows for provisioning of remote systems > >when a PXE environment is not available. Ahh, when you explain it that way it sounds exactly like something I want to be able to do. -- /\oo/\ / /()\ \ David Mackintosh | dave at xdroop.com | http://www.xdroop.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From David.Mackintosh at xdroop.com Thu Dec 21 20:40:54 2006 From: David.Mackintosh at xdroop.com (David Mackintosh) Date: Thu, 21 Dec 2006 15:40:54 -0500 Subject: [et-mgmt-tools] Cobbler 0.3.4-1 comments In-Reply-To: <458AC0A4.20303@redhat.com> References: <20061221164046.GC6613@xdroop.com> <458AC0A4.20303@redhat.com> Message-ID: <20061221204054.GE6613@xdroop.com> On Thu, Dec 21, 2006 at 12:13:08PM -0500, Michael DeHaan wrote: > >I do have a question about the implementation -- is there anything > >that would prevent cobbler from running on, say, a Solaris system? I > >ask because I already have a fairly extensive host-management system > >set up that runs on Solaris, and it would be reasonably > >straight-forward to integrate cobbler into it so that a user could > >say > > > ># need_shoes --system="text-name" --profile="profile-name" > > > >(ie need_shoes asks the cobbler for boots, or maybe you'd name it after > >a shoe vendor or something... to beat a naming convention to death :) > > > >...and have that script dig the IP address and MAC out of NIS, doctor > >dhcpd (if necessary -- I'm already doing much of that, which is why in > >my past comments I was resistant to cobbler doing it as well), and > >do the final "cobbler sync" automatically, making it a one-stop for > >my administrators. > > > Cobbler's rather RHEL/Fedora/Centos centric at this point, and I really > don't intend on changing that. Namely it knows > the job it needs to do and wants to do that job well. I think perhaps I was unclear in my question -- I don't want it to provision non-RH-family OSs (since we have spent fa-a-a-r too much time getting the Solaris Kickstart to work reasonably); I merely want it to run on a Solaris system because it will make access to things like ethers, hostnames and IP addresses much easier, and I already have a tftp server running on said Solaris system. I was asking if there is any dependancy in the code itself that would preclude it running on Solaris. -- /\oo/\ / /()\ \ David Mackintosh | dave at xdroop.com | http://www.xdroop.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mdehaan at redhat.com Thu Dec 21 20:45:36 2006 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 21 Dec 2006 15:45:36 -0500 Subject: [et-mgmt-tools] Cobbler 0.3.4-1 comments In-Reply-To: <20061221204054.GE6613@xdroop.com> References: <20061221164046.GC6613@xdroop.com> <458AC0A4.20303@redhat.com> <20061221204054.GE6613@xdroop.com> Message-ID: <458AF270.6040303@redhat.com> David Mackintosh wrote: > On Thu, Dec 21, 2006 at 12:13:08PM -0500, Michael DeHaan wrote: > > >>> I do have a question about the implementation -- is there anything >>> that would prevent cobbler from running on, say, a Solaris system? I >>> ask because I already have a fairly extensive host-management system >>> set up that runs on Solaris, and it would be reasonably >>> straight-forward to integrate cobbler into it so that a user could >>> say >>> >>> # need_shoes --system="text-name" --profile="profile-name" >>> >>> (ie need_shoes asks the cobbler for boots, or maybe you'd name it after >>> a shoe vendor or something... to beat a naming convention to death :) >>> >>> ...and have that script dig the IP address and MAC out of NIS, doctor >>> dhcpd (if necessary -- I'm already doing much of that, which is why in >>> my past comments I was resistant to cobbler doing it as well), and >>> do the final "cobbler sync" automatically, making it a one-stop for >>> my administrators. >>> >>> >> Cobbler's rather RHEL/Fedora/Centos centric at this point, and I really >> don't intend on changing that. Namely it knows >> the job it needs to do and wants to do that job well. >> > > I think perhaps I was unclear in my question -- I don't want it to > provision non-RH-family OSs (since we have spent fa-a-a-r too much > time getting the Solaris Kickstart to work reasonably); I merely want > it to run on a Solaris system because it will make access to things > like ethers, hostnames and IP addresses much easier, and I already > have a tftp server running on said Solaris system. I was asking if > there is any dependancy in the code itself that would preclude it > running on Solaris. > > Ah, I understand now. I seriously have no idea what would be involved -- I'm not a Solaris expert, but you'll undoubtedly find things like paths that need to change. If you'd like to try porting it, be my guest... --Michael From mdehaan at redhat.com Thu Dec 21 23:01:56 2006 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 21 Dec 2006 18:01:56 -0500 Subject: [et-mgmt-tools] Cobbler 0.3.4-1 comments In-Reply-To: <458AC0A4.20303@redhat.com> References: <20061221164046.GC6613@xdroop.com> <458AC0A4.20303@redhat.com> Message-ID: <458B1264.3000106@redhat.com> Michael DeHaan wrote: > David, > > Thanks for the feedback, a few comments below... I'll look into > incorporating some of this into 0.3.6. > > David Mackintosh wrote: >> Hi there, >> >> I've just done a moderate sized cobbler installation (currently >> twelve distros with more to come, eventually more than a hundred >> systems) and have a few comments based on what I have seen so far. >> These are probably minor quibbles. >> This is installed from the 0.3.4-1.src.rpm >> 1. Cobbler doesn't appear to understand -v, -V, or --version >> >> ...which isn't entirely necessary if it is installed from rpm >> (rpm -qa | grep cobbler gets me the info I needed) but it would >> still be nice. >> > That's valid, though I would hope everyone is always installing from > the RPM. >> 2. Brief output should at least be an option, if not a default. >> >> I want the equivilent of >> # cobbler list --profiles | grep profile >> >> ...since the vast majority of the time I don't care about the details >> of a profile, I only want to see the list of names because I have so >> many of them I've forgotten what I called the one I want. Yes this >> is mostly my fault for frequently forgetting/changing my "standards" >> but it would be nice if the tool could help. >> > This would be a good add. >> 3. Semantically, since cobbler uses >> >> # cobbler system add [...] >> >> ...cobbler should therefore understand >> >> # cobbler system list >> >> ...instead of requiring >> >> # cobbler list --systems >> >> I have nothing against the latter, but the former fits more >> semantically into the COMMAND OBJECT ACTION model I like to use. >> Perhaps this form of the command would be a good place to put the >> brief output. > I find myself typing the same things occasionally and wondering why I > didn't do it that way :) > > Perhaps "cobbler system list" and "cobbler system list --full". > >> Or maybe you want to change the other commands to the form >> >> # cobbler add --system >> >> ...but either way it should be more consistant. >> >> 4. Sorted output would be nice. >> >> The output of the various lists are not sorted by either order-added >> or some kind of alpha-numerical sort; either would be adequate, and >> the latter obviously preferred. >> > This makes good sense and is an easy fix. >> One could even argue that since the "index" of a profile/distro/name >> which preceeds the name will probably change as other things are >> added and removed, and are not used anywhere (ie you can't refer to a >> profile as "profile #3" anywhere) it should be dropped entirely from >> the output. > True. >> 5. Unless I misunderstand something, if I define my profiles with >> URLs to ks.cfg files instead of file references, there is nothing >> served through httpd by cobbler. In this case it would be nice >> if cobbler didn't restart my httpd every time I ran cobbler sync. >> > Yes and no. The restart /is/ unneccessary. As to why the web > directory is there, cobbler's web directory is also used to serve up > configuration files for koan as well as to mirror kickstart trees and > (in 0.3.5) yum repositories. Adding some logic to know when a > restart is required does make sense, though. Basically once cobbler > is used beyond minimal PXE support, the web directory starts to grow > increasingly important. >> 6. If manage_dhcp is set to 0, cobbler check should not complain >> about missing dhcpd pieces.In my case dhcpd is on another system >> under another set of script'scontrol, so cobbler needn't be bothered >> about those details. Maybe an option to tell it not to warn about >> those kinds of things would >> be in order (squelch_dhcp_warnings or something). >> >> END COMMENTS >> >> > Cobbler check is there for people who really don't know what setting > up a PXE environment entails (i.e. whether or not they set up > next-server or not), and can use those pointers. Those that > understand the warnings should be able to know when they don't > apply. They do apply when manage_dhcp is not set and the user is > running a local DHCP server. This should probably stay as is, though > if the warnings are confusing, they definitely should be amended, and > I could use some suggestions as to how they were confusing and what > you think they ought to say instead. > >> All that said, these are exceedingly minor quibbles. Cobbler has >> already saved me a ton of time and made me look good in front of two >> moderately-sized customers (always a plus). >> I do have a question about the implementation -- is there anything >> that would prevent cobbler from running on, say, a Solaris system? I >> ask because I already have a fairly extensive host-management system >> set up that runs on Solaris, and it would be reasonably >> straight-forward to integrate cobbler into it so that a user could >> say >> # need_shoes --system="text-name" --profile="profile-name" >> >> (ie need_shoes asks the cobbler for boots, or maybe you'd name it after >> a shoe vendor or something... to beat a naming convention to death :) >> >> ...and have that script dig the IP address and MAC out of NIS, doctor >> dhcpd (if necessary -- I'm already doing much of that, which is why in >> my past comments I was resistant to cobbler doing it as well), and >> do the final "cobbler sync" automatically, making it a one-stop for >> my administrators. >> > Cobbler's rather RHEL/Fedora/Centos centric at this point, and I > really don't intend on changing that. Namely it knows > the job it needs to do and wants to do that job well. > I _do_ think it is reasonable to be able to provision other forms of > targets, similarly to the steps cobbler already takes to allow PXE > provisioning of IA64 > Linux systems (which require different bootloader configuration > files). So if it's just something that involves some minor support > in action_sync.py to build a slightly different bootloader config, > that might be a good patch candidate. > > >> A second question -- while thinking about #5 above, it occured to me >> that I don't immediately understand why cobbler copies the vmlinuz >> and initrd.img files into the httpd tree. Why do you do that? >> > It's all about koan. Koan allows for provisioning of remote systems > when a PXE environment is not available. > > For instance: > > "yum install koan" > "koan --replace-self --server=cobbler.example.com --profile=fc6test" > /sbin/reboot > > Koan also does virtual image installs (currently it only supports Xen, > though this will probably expand later): > > "yum install koan" > "koan --virt --server=cobbler.example.com --profile=myvirtualwebserver" > > >> Thanks again for cobbler. >> >> > You're welcome! Thanks again for the comments! >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools Incidentally, I've added the following features today, since they were such good ideas for usability improvements. I'll wait awhile on the official release as 0.3.5 is just out, and I want to give folks a chance to play with the repository features. The list of newness: cobbler list now just list the names of the various items, so it's easier to read and find the name of a profile you might want to use. cobbler report now does what "cobbler list" used to do, that is, output a ton of information cobbler list works, as does "cobbler report", this conforms to the subject verb form that is used for most other commands cobbler list and report are now sorted by name "cobbler repo sync" does the same as "cobbler reposync" (again, subject verb compliance), not to be confused with just plain "cobbler sync" Apache is only restarted when it needs to be (i.e. the config needs to be changed)