From mdehaan at redhat.com Tue Jan 2 22:03:57 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 02 Jan 2007 17:03:57 -0500 Subject: [et-mgmt-tools] Kickstart tracking in 0.3.6 Message-ID: <459AD6CD.3020902@redhat.com> Friendly Neighborhood Cobbler Users, One of the things I've wanted to do with cobbler for some time was be able to keep track of systems as they kickstart, so that higher level applications and scripts could, if they wanted, try to detect which machines had stalled or otherwise failed to complete. Some rudimentary support for this is going into upstream now, and I'll be refining it some more over the next few days. How does it work? Well, it only works for kickstart trees that come out of /var/www/cobbler -- local content -- so if you're installing off of a Fedora mirror, this gives you more reason to let Cobbler mirror that distro and serve it locally (plus, it's nicer to the guy running the mirror). This means kickstart tracking will work for any distros that have been pulled down via "cobbler import" or any distributions you have created yourself in that directory (/var/www/cobbler/localmirror/foo is the preferred destination for such content). If you already have a kickstart tree elsewhere, symlinking it should be good enough if you configure Apache appropriately. So, how it works -- this new release installs a mod_python filter handler automagically for /var/www/cobbler, and access to certain files in that directory are logged with the IP address of the requester, the time, and the file requested. From this, it is possible to tell what profiles are being requested, what RPM's they've requested, and when they are done (they request a special filename at the bottom of their kickstarts when they are done). This all currently goes into /var/log/cobbler/cobbler.log and there is a logrotate script in /etc/logrotate.d that keeps the logfile manageable. This is all done from the RPM basically, so there isn't any added pain on the user. This will probably require some more advanced tools to understand the logfiles and report on the status of the kickstarts. Some things this tool might need to look at would be things like produce reports that provide information such as "this machine hasn't requested an file in 30 minutes and is not yet finished" and so on. If anybody is already doing this sort of thing, or has ideas on what sort of form factor reporting tools should take, I'd love to hear your opinion. I may end up keeping the log data itself as YAML, so that it is more easily read back by cobbler to produce a report. Imagine: cobbler showkickstarting 192.168.1.10 IN PROGRESS | 50 rpms requested | 35 minutes elapsed 192.168.1.11 FINISHED | 250 rpms requested | 55 minutes elapsed 192.168.1.12 STALLED? | 15 rpms requested | 250 minutes elapsed and so on. Comments? --Michael From David.Mackintosh at xdroop.com Thu Jan 4 13:35:21 2007 From: David.Mackintosh at xdroop.com (David Mackintosh) Date: Thu, 4 Jan 2007 08:35:21 -0500 Subject: [et-mgmt-tools] Cobbler on Solaris 9 Message-ID: <20070104133521.GB6515@xdroop.com> Although firmly filed under "stupid computer trick", it may amuse you to know that the .tar.gz of cobbler 0.3.5 will install correctly on a SPARC Solaris 9 system with the csw python installed. Predictably it isn't happy about not being able to find httpd, but the setup of distros, profiles, and systems works correctly, and from this platform I have installed several flavors of CentOS, RHEL-3ES and RHEL-4ES to i386-family systems. (Importing distros (via rsync) has not been tested as I manage my distros through other methods, but offhand there isn't really any reason why this wouldn't work.) Why might this be useful? Well I already have a set of scripts for managing my hosts infrastructure (DNS, NIS, DHCP) plus a tftp server for Solaris Kickstarts already in existance, and this lets me do everything from one server. So I can now say: # cobbler_byname --host tpx18 --profile RHEL-3ES-U6-i386-ws ...and it generates and runs the appropriate cobbler command for me, instead of me having to dig out the MAC and IP address for the system manually. cobbler_byname is a perl script which I can provide if anyone is interested. -- /\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 Jan 4 15:22:46 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 04 Jan 2007 10:22:46 -0500 Subject: [et-mgmt-tools] Cobbler on Solaris 9 In-Reply-To: <20070104133521.GB6515@xdroop.com> References: <20070104133521.GB6515@xdroop.com> Message-ID: <459D1BC6.9080908@redhat.com> David Mackintosh wrote: > Although firmly filed under "stupid computer trick", it may amuse > you to know that the .tar.gz of cobbler 0.3.5 will install correctly > on a SPARC Solaris 9 system with the csw python installed. > > Predictably it isn't happy about not being able to find httpd, but > the setup of distros, profiles, and systems works correctly, and > from this platform I have installed several flavors of CentOS, > RHEL-3ES and RHEL-4ES to i386-family systems. > Neat. For things like getting "cobbler check" to behave better, you might be able to get away by changing http_bin and so forth in /var/lib/cobbler/settings. Things like the http restart probably don't work though. > (Importing distros (via rsync) has not been tested as I manage my > distros through other methods, but offhand there isn't really any > reason why this wouldn't work.) > > Why might this be useful? Well I already have a set of scripts for > managing my hosts infrastructure (DNS, NIS, DHCP) plus a tftp server > for Solaris Kickstarts already in existance, and this lets me do > everything from one server. > > So I can now say: > > # cobbler_byname --host tpx18 --profile RHEL-3ES-U6-i386-ws > > ...and it generates and runs the appropriate cobbler command for > me, instead of me having to dig out the MAC and IP address for > the system manually. > > cobbler_byname is a perl script which I can provide if anyone is > interested. > Definitely, I'd like to see it. > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Jan 4 22:25:59 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 04 Jan 2007 17:25:59 -0500 Subject: [et-mgmt-tools] Kickstart tracking in 0.3.6 In-Reply-To: <459AD6CD.3020902@redhat.com> References: <459AD6CD.3020902@redhat.com> Message-ID: <459D7EF7.3050609@redhat.com> Ok, kickstart tracking is implemented and pushed, so if anyone wants to play with this, please check out the Mercurial repository. Just run a "cobbler sync" after the upgrade to get Apache configured correctly. I probably won't release this (along with the rest of 0.3.6) until mid-next week. Manpage docs have to be written first :) In order to see when machines have truly finished, the kickstart files need to contain the following somewhere in post: %post TEMPLATE::kickstart_done I have updated the default kickstarts that come with cobbler, so you can see what is done there. And then, at any time, one can run the following and see following for all distros in their system: [root at mdehaan cobbler]# cobbler status Address | State | Started | Last Request | Seconds | File Count 172.16.56.91 | notdone | Thu Jan 4 16:23:16 2007 | Thu Jan 4 17:13:32 2007 | 3016 | 1422 Individual status of files transferred is stored in /var/log/cobbler/kicklog/$IPADDR. Right now, these files are not pruned, though in future versions I might decide to delete them if they haven't been modified in 30 days, or something like that. This really shouldn't be a problem as the files won't be huge. If you're using kickstart trees on another partition, you'll only see a few files transferred, if at all, and will have less resolution into kickstart status. To fix this, just create a symlink to /var/www/cobbler/localmirror/$foo for each kickstart tree $foo you have, and provision from http://$server/cobbler_track/localmirror/$foo as source URL in the kickstart. The "track" in the URL is a bit of magic, and if you're using "cobbler import" that will be done automatically for you. As usual, this feature can be ignored for those that don't need to understand it. It will still be there, though :) For all those with suggestions (or better, patches) to improve the tracking information, those are definitely welcome. I intend to add some YAML and/or XML output in the future to supplement the existing command. (i.e. "cobbler status --mode=yaml"). --Michael Michael DeHaan wrote: > Friendly Neighborhood Cobbler Users, > > One of the things I've wanted to do with cobbler for some time was be > able to keep track of systems as they kickstart, so that higher level > applications and scripts could, if they wanted, try to detect which > machines had stalled or otherwise failed to complete. Some > rudimentary support for this is going into upstream now, and I'll be > refining it some more over the next few days. > > How does it work? > > Well, it only works for kickstart trees that come out of > /var/www/cobbler -- local content -- so if you're installing off of a > Fedora mirror, this gives you more reason to let Cobbler mirror that > distro and serve it locally (plus, it's nicer to the guy running the > mirror). This means kickstart tracking will work for any distros > that have been pulled down via "cobbler import" or any distributions > you have created yourself in that directory > (/var/www/cobbler/localmirror/foo is the preferred destination for > such content). If you already have a kickstart tree elsewhere, > symlinking it should be good enough if you configure Apache > appropriately. > > So, how it works -- this new release installs a mod_python filter > handler automagically for /var/www/cobbler, and access to certain > files in that directory are logged with the IP address of the > requester, the time, and the file requested. From this, it is > possible to tell what profiles are being requested, what RPM's they've > requested, and when they are done (they request a special filename at > the bottom of their kickstarts when they are done). This all > currently goes into /var/log/cobbler/cobbler.log and there is a > logrotate script in /etc/logrotate.d that keeps the logfile > manageable. This is all done from the RPM basically, so there isn't > any added pain on the user. > > This will probably require some more advanced tools to understand the > logfiles and report on the status of the kickstarts. Some things > this tool might need to look at would be things like produce reports > that provide information such as "this machine hasn't requested an > file in 30 minutes and is not yet finished" and so on. > > If anybody is already doing this sort of thing, or has ideas on what > sort of form factor reporting tools should take, I'd love to hear your > opinion. I may end up keeping the log data itself as YAML, so that > it is more easily read back by cobbler to produce a report. > > Imagine: > > cobbler showkickstarting > > 192.168.1.10 IN PROGRESS | 50 rpms requested | 35 minutes > elapsed 192.168.1.11 FINISHED | 250 rpms requested | 55 > minutes elapsed > 192.168.1.12 STALLED? | 15 rpms requested | 250 minutes elapsed > > and so on. > > Comments? > > --Michael > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From David.Mackintosh at xdroop.com Thu Jan 4 23:09:36 2007 From: David.Mackintosh at xdroop.com (David Mackintosh) Date: Thu, 4 Jan 2007 18:09:36 -0500 Subject: [et-mgmt-tools] Cobbler on Solaris 9 In-Reply-To: <459D1BC6.9080908@redhat.com> References: <20070104133521.GB6515@xdroop.com> <459D1BC6.9080908@redhat.com> Message-ID: <20070104230936.GD6515@xdroop.com> On Thu, Jan 04, 2007 at 10:22:46AM -0500, Michael DeHaan wrote: > Neat. For things like getting "cobbler check" to behave better, you > might be able to get away by changing > http_bin and so forth in /var/lib/cobbler/settings. Things like the > http restart probably don't work though. Service handling would either have to be abstracted in cobbler, or dummied up on the sun to make it pretend to be more like a RedHat system, neither of which is probably worth the effort it would take. > Definitely, I'd like to see it. Attached to this page: http://wiki.xdroop.com/space/RedHat/kickstart/Cobbler/cobbler_byname -- /\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 Jan 4 23:19:12 2007 From: David.Mackintosh at xdroop.com (David Mackintosh) Date: Thu, 4 Jan 2007 18:19:12 -0500 Subject: [et-mgmt-tools] Two other comments In-Reply-To: <459D1BC6.9080908@redhat.com> References: <20070104133521.GB6515@xdroop.com> <459D1BC6.9080908@redhat.com> Message-ID: <20070104231912.GE6515@xdroop.com> In the process of looking at this, I had two other comments: 1. It would be nice if there was a quiet mode for cobbler sync. Twelve distros generate a lot of noise. 2. The "name" parameter should be a descriptive (possibly optional) field and the MAC address a separate parameter (which might possibly be plugged into the "name" field if the "name" field was not explicitly provided). Specifically -- figuring out which "system" is my target when all you have is a listing of MAC addresses is even more tedious than figuring out what their MAC addresses were in the first place; ie: [root at router /]$ cobbler list | grep system system 1 : 00:11:43:cd:81:f8 system 2 : 00:04:23:0A:14:04 system 3 : 00:04:23:a6:a0:86 system 4 : 00:06:5B:B1:7D:7B system 5 : 00:30:1B:AD:90:9B system 6 : 00:d0:b7:7a:90:b0 The "name" should probably be a descriptive label and have the MAC address as a separate parameter as so: # cobbler system add --name="tpx18" --mac=00:04:23:a6:a0:86 --profile=[...] --pxe-address=[...] Of course if "name" was a hostname that was resolvable, that would make putting in the functionality of cobbler_byname easy... :) -- /\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 Jan 4 23:45:17 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 04 Jan 2007 18:45:17 -0500 Subject: [et-mgmt-tools] Re: Two other comments In-Reply-To: <20070104231912.GE6515@xdroop.com> References: <20070104133521.GB6515@xdroop.com> <459D1BC6.9080908@redhat.com> <20070104231912.GE6515@xdroop.com> Message-ID: <459D918D.7020208@redhat.com> David Mackintosh wrote: > In the process of looking at this, I had two other comments: > > 1. It would be nice if there was a quiet mode for cobbler sync. > Twelve distros generate a lot of noise. > Believe it or not, it used to be louder. Point taken. > 2. The "name" parameter should be a descriptive (possibly optional) > field and the MAC address a separate parameter (which might possibly > be plugged into the "name" field if the "name" field was not explicitly > provided). > > Specifically -- figuring out which "system" is my target when all you > have is a listing of MAC addresses is even more tedious than figuring > out what their MAC addresses were in the first place; ie: > > [root at router /]$ cobbler list | grep system > system 1 : 00:11:43:cd:81:f8 > system 2 : 00:04:23:0A:14:04 > system 3 : 00:04:23:a6:a0:86 > system 4 : 00:06:5B:B1:7D:7B > system 5 : 00:30:1B:AD:90:9B > system 6 : 00:d0:b7:7a:90:b0 > > The "name" should probably be a descriptive label and have the MAC > address as a separate parameter as so: > > # cobbler system add --name="tpx18" --mac=00:04:23:a6:a0:86 --profile=[...] --pxe-address=[...] > Name is already in use in the field and can't change, though I understand your point. A perhaps better solution is to add an optional --description field for each object (including distros and systems) and show that information next to the "cobbler list" data. > Of course if "name" was a hostname that was resolvable, that would make > putting in the functionality of cobbler_byname easy... :) > Yes, the name has to be resolveable in order to use it with pxelinux. Hostnames aren't requested by pxelinux when it's asking for files over TFTP, just IP's and MAC's. And if you are using MAC's, you can let cobbler manage a dhcpd.conf file and generate reservations for you, using --pxe-address=ip. From matts at hostingsupport.com Fri Jan 5 18:54:38 2007 From: matts at hostingsupport.com (Matt S Unix Administrator) Date: Fri, 05 Jan 2007 12:54:38 -0600 Subject: [et-mgmt-tools] RHEL4 Cobbler Setup Message-ID: <459E9EEE.7010300@hostingsupport.com> How might one import RHEL 4 into cobbler from the installation media. Such that the installation can be completed over the network. I've got a functional cobbler install already with several distributions. From mdehaan at redhat.com Fri Jan 5 19:13:57 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 05 Jan 2007 14:13:57 -0500 Subject: [et-mgmt-tools] RHEL4 Cobbler Setup In-Reply-To: <459E9EEE.7010300@hostingsupport.com> References: <459E9EEE.7010300@hostingsupport.com> Message-ID: <459EA375.9040401@redhat.com> Matt S Unix Administrator wrote: > How might one import RHEL 4 into cobbler from the installation media. > Such that the installation can be completed over the network. I've got a > functional cobbler install already with several distributions. > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > All you have to do is copy over the files from each CD into a directory somewhere on your cobbler server. You'll want to preserve the directory layout that was on the CD. A good place to put this tree is /var/lib/cobbler/localmirror/rhel4$type$arch, though if you don't want to take up space in /var, you could just create a symlink to that point and put the files somewhere else. (Note: If not running Cobbler 0.3.6, this would require manually configuring Apache to follow symlinks, 0.3.5 sets this up for you automatically). The name "localmirror" is special, if you name it something else, cobbler will probably delete it for you, thinking it's content that shouldn't live in /var/lib/cobbler. These files really don't have to be on the cobbler server, either. In my setup, I just symlink a path to the kickstart trees that Red Hat stores on NFS shares, i.e. /mnt/foo/something/RHEL4/AS/tree. Samba would technically work too if you are so inclined. With the content already accessible from /var/lib/cobbler, you just use the following URL in your kickstart file: url --url=http://$server/cobbler/localmirror/RHEL4/AS/i386/tree (for cobbler 0.3.6, use "cobbler_track" instead of "cobbler" in the URL if you want to use kickstart tracking) --Michael From mdehaan at redhat.com Fri Jan 5 19:23:17 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 05 Jan 2007 14:23:17 -0500 Subject: [et-mgmt-tools] RHEL4 Cobbler Setup In-Reply-To: <459EA375.9040401@redhat.com> References: <459E9EEE.7010300@hostingsupport.com> <459EA375.9040401@redhat.com> Message-ID: <459EA5A5.7060202@redhat.com> Michael DeHaan wrote: > Matt S Unix Administrator wrote: >> How might one import RHEL 4 into cobbler from the installation media. >> Such that the installation can be completed over the network. I've got a >> functional cobbler install already with several distributions. >> >> >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools >> > All you have to do is copy over the files from each CD into a > directory somewhere on your cobbler server. You'll want to preserve > the directory layout that was on the CD. > A good place to put this tree is > /var/lib/cobbler/localmirror/rhel4$type$arch, though if you don't want > to take up space in /var, you could just create a symlink to that > point and put the files somewhere else. (Note: If not running > Cobbler 0.3.6, this would require manually configuring Apache to > follow symlinks, 0.3.5 sets this up for you automatically). The name > "localmirror" is special, if you name it something else, cobbler will > probably delete it for you, thinking it's content that shouldn't live > in /var/lib/cobbler. > > These files really don't have to be on the cobbler server, either. > In my setup, I just symlink a path to the kickstart trees that Red Hat > stores on NFS shares, i.e. /mnt/foo/something/RHEL4/AS/tree. Samba > would technically work too if you are so inclined. > > With the content already accessible from /var/lib/cobbler, you just > use the following URL in your kickstart file: > > url --url=http://$server/cobbler/localmirror/RHEL4/AS/i386/tree > (for cobbler 0.3.6, use "cobbler_track" instead of "cobbler" in the > URL if you want to use kickstart tracking) > > --Michael > > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools Sorry for the incomplete follow-up. You asked about "import", which probably means how do I create cobbler distribution and profile entries in cobbler, as well as just how to do I get the kickstart tree copied over. after doing the above to copy the kickstart tree, do the following. Your kernel/initrd paths might be slightly different: cobbler distro add --name=rhel4asi386 --kernel=/var/www/cobbler/localmirror/RHEL4/AS/i386/tree/images/pxeboot/vmlinuz --initrd=/var/www/cobbler/localmirror/RHEL4/AS/i386/tree/images/pxeboot/initrd.img cobbler profile add --name=rhel4asi386foo --distro=rhel4asi386 --kickstart=/path/to/kickstart.ks (with the kickstart file of course including the URL as referenced above) Adding a "import from ISO's" feature sounds like a good idea for future revisions. If anyone feeling creative wants to play around with action_import.py and add this feature and submit a patch, be my guest. If not, I'll put it in the queue. It would be rather nice to have. --Michael From dlutter at redhat.com Fri Jan 12 23:27:22 2007 From: dlutter at redhat.com (David Lutterkort) Date: Fri, 12 Jan 2007 23:27:22 +0000 Subject: [et-mgmt-tools] cft version 0.1.0 Message-ID: <1168644442.21083.153.camel@localhost.localdomain> Hi, I just made the very first release of cft [1], the config file tracker. This version supports almost all the types that puppet understands natively, except for cron, sshkey and package. Doing some sort of package support will be the focus for the next release, i.e. understanding what package operations the sysadmin has made. enjoy, David [1] http://cft.et.redhat.com/#news From rrv1544 at rit.edu Sat Jan 13 00:18:49 2007 From: rrv1544 at rit.edu (Ronald Valente) Date: Fri, 12 Jan 2007 19:18:49 -0500 Subject: [et-mgmt-tools] Cluster Provisioning Message-ID: Cobbler Community. I am currently working on an independent study to bring up a cluster every night and tear it down before the labs re-open in the morning. Here is a quick run down. The labs have PXE boot as the first option as the motherboard because the students use it to select which OS they need to use. The lab has 80 computers 40 on each subnet. Two head nodes one for each subnet. It would be nice to use cobble in conjunction with a distributed file system. Then each computer would boot via PXE on started, install the OS and store the files on a distributed file system. Then after the initial install sequence there would be no more boot time other than booting from the distributed file system. We are currently try Rocks clusters and its giving us more headaches then if we just rolled our own distro. The only requirement is that we run condor. Regards, Ron Valente From mdehaan at redhat.com Sun Jan 14 00:07:25 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Sat, 13 Jan 2007 19:07:25 -0500 Subject: [et-mgmt-tools] Cluster Provisioning In-Reply-To: References: Message-ID: <45A9743D.8000207@redhat.com> Ronald Valente wrote: > Cobbler Community. > > I am currently working on an independent study to bring up a cluster > every night and tear it down before the labs re-open in the morning. > Here is a quick run down. > > The labs have PXE boot as the first option as the motherboard because > the students use it to select which OS they need to use. > > The lab has 80 computers 40 on each subnet. > > Two head nodes one for each subnet. > > It would be nice to use cobble in conjunction with a distributed file > system. Then each computer would boot via PXE on started, install the > OS and store the files on a distributed file system. Then after the > initial install sequence there would be no more boot time other than > booting from the distributed file system. We are currently try Rocks > clusters and its giving us more headaches then if we just rolled our > own distro. The only requirement is that we run condor. > > Regards, > Ron Valente > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools In general, cobbler supports anything kickstart can do, so this might be an Anaconda question or one better suited for kickstart-list at redhat.com ... Offhand, it seems like it would be easier to provision each box with a minimal local OS every night (for simplicity), and then just have them mount the distributed filesystem as appropriate -- but then I'm really not a distributed filesystem expert. Just the base OS packages and whatever it takes to make the machine manageable... If anyone else has any other ideas and comments, feel free to chime in. --Michael From rrv1544 at rit.edu Sun Jan 14 02:27:29 2007 From: rrv1544 at rit.edu (Ronald Valente) Date: Sat, 13 Jan 2007 21:27:29 -0500 Subject: [et-mgmt-tools] Cluster Provisioning In-Reply-To: <45A9743D.8000207@redhat.com> References: <45A9743D.8000207@redhat.com> Message-ID: Our labs are set to run PXE boot by default in the BIOS and that cannot change. Which is going to require some way to get the machines with the small local install. I agree that the OS should be installed on the machines but getting it there is the current issue. If the OS is run locally then we do not need anything like a distributed file system. This is because condor (the high performance computing app) that we are using handles all that. We just need a way to get the machines from there normal lab imaging environment to our modified provisioning environment. Regards, Ron Valente On Jan 13, 2007, at 7:07 PM, Michael DeHaan wrote: > Ronald Valente wrote: >> Cobbler Community. >> >> I am currently working on an independent study to bring up a >> cluster every night and tear it down before the labs re-open in >> the morning. Here is a quick run down. >> >> The labs have PXE boot as the first option as the motherboard >> because the students use it to select which OS they need to use. >> >> The lab has 80 computers 40 on each subnet. >> >> Two head nodes one for each subnet. >> >> It would be nice to use cobble in conjunction with a distributed >> file system. Then each computer would boot via PXE on started, >> install the OS and store the files on a distributed file system. >> Then after the initial install sequence there would be no more >> boot time other than booting from the distributed file system. We >> are currently try Rocks clusters and its giving us more headaches >> then if we just rolled our own distro. The only requirement is >> that we run condor. >> >> Regards, >> Ron Valente >> >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools > In general, cobbler supports anything kickstart can do, so this > might be an Anaconda question or one better suited for kickstart- > list at redhat.com ... > > Offhand, it seems like it would be easier to provision each box > with a minimal local OS every night (for simplicity), and then > just have them mount the distributed filesystem as appropriate -- > but then I'm really not a distributed filesystem expert. Just the > base OS packages and whatever it takes to make the machine > manageable... > > If anyone else has any other ideas and comments, feel free to chime > in. > > --Michael From mdehaan at redhat.com Mon Jan 15 15:23:01 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 15 Jan 2007 10:23:01 -0500 Subject: [et-mgmt-tools] Cluster Provisioning In-Reply-To: References: <45A9743D.8000207@redhat.com> Message-ID: <45AB9C55.4020006@redhat.com> Ronald Valente wrote: > Our labs are set to run PXE boot by default in the BIOS and that > cannot change. Which is going to require some way to get the machines > with the small local install. I agree that the OS should be installed > on the machines but getting it there is the current issue. If the OS > is run locally then we do not need anything like a distributed file > system. This is because condor (the high performance computing app) > that we are using handles all that. We just need a way to get the > machines from there normal lab imaging environment to our modified > provisioning environment. > > Regards, > Ron Valente I guess the last line in your email is your question... if not, please ask one, and I'll try to answer it instead :) Should you just want to use Cobbler to control PXE this block of machines, set the DHCP next-server information for the machines in question to point to your cobbler server. It is possible to specify different PXE servers for different machines based on their mac address information in /etc/dhcpd.conf. Cobbler doesn't require that you run it on the dhcp server or that it's the only PXE server on your network. Alternatively, you could convert your entire Linux provisioning environment over to cobbler and let it manage both environments as well as your dhcpd.conf configuration. This is what the cobbler "distro/profile/system" three-tiered concept is really intended for. You could have one or more profiles assigned to your regular machines, and a different profile (that does the condor setup, etc) assigned to your cluster machines. --Michael > On Jan 13, 2007, at 7:07 PM, Michael DeHaan wrote: > >> Ronald Valente wrote: >>> Cobbler Community. >>> >>> I am currently working on an independent study to bring up a cluster >>> every night and tear it down before the labs re-open in the morning. >>> Here is a quick run down. >>> >>> The labs have PXE boot as the first option as the motherboard >>> because the students use it to select which OS they need to use. >>> >>> The lab has 80 computers 40 on each subnet. >>> >>> Two head nodes one for each subnet. >>> >>> It would be nice to use cobble in conjunction with a distributed >>> file system. Then each computer would boot via PXE on started, >>> install the OS and store the files on a distributed file system. >>> Then after the initial install sequence there would be no more boot >>> time other than booting from the distributed file system. We are >>> currently try Rocks clusters and its giving us more headaches then >>> if we just rolled our own distro. The only requirement is that we >>> run condor. >>> >>> Regards, >>> Ron Valente >>> >>> _______________________________________________ >>> et-mgmt-tools mailing list >>> et-mgmt-tools at redhat.com >>> https://www.redhat.com/mailman/listinfo/et-mgmt-tools >> In general, cobbler supports anything kickstart can do, so this might >> be an Anaconda question or one better suited for >> kickstart-list at redhat.com ... >> >> Offhand, it seems like it would be easier to provision each box with >> a minimal local OS every night (for simplicity), and then just have >> them mount the distributed filesystem as appropriate -- but then I'm >> really not a distributed filesystem expert. Just the base OS packages >> and whatever it takes to make the machine manageable... >> >> If anyone else has any other ideas and comments, feel free to chime in. >> >> --Michael > From mdehaan at redhat.com Thu Jan 18 16:12:24 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 18 Jan 2007 11:12:24 -0500 Subject: [et-mgmt-tools] Cobbler 0.3.6 released Message-ID: <45AF9C68.4070700@redhat.com> The major feature for this release is support for kickstart status tracking as mentioned earlier in the list archives. If you have an existing installation, after the upgrade, it will still work absolutely fine, but to get kickstart tracking to work, you'll need to change the --url parameter in your kickstart files to get useful data from the "cobbler status" command. Anyhow, the kickstart URL changes are as follows: before: http://server/cobbler/... after: http://server/cobbler_track/... If you look at the new default kickstart files in /etc/cobbler (they should be saved with an .rpmnew extension for upgrades), you can also see the new TEMPLATE:: entry in the %post section. This is where cobbler writes in the code that signals kickstart completion. Add that too, and "cobbler status" will do a pretty good job of telling you when machines are finished installing. From the changelog: - locking feature now enabled - "enchant" now supports provisioning virtual images remotely when using --is-virt=yes - cobbler no longer restarts httpd if the config file already exists. - "cobbler repo sync" is now an alias for "cobbler reposync" - "cobbler list (something)" can now be invoked as "cobbler (something) list" - "cobbler list" just shows names of items now - "cobbler report" is now used for showing full information output - "list" (as well as report) are now sorted alphabetically - basic kickstart tracking feature. requests on /var/www/cobbler get logged to /var/log/cobbler. Fire away, and as usual, comments and ideas on the above are welcome. Upcoming ideas/improvements for Cobbler 0.3.7 / Koan 0.2.6: -- better default kickstarts that are hard drive type/size aware (using some good input gained from cobbler users and kickstart-list) -- koan installing into NFS roots for Xen, possible support for LVM partitions and hardware virt -- ... Thanks to David Mackintosh for suggesting many of the usability improvements in this release. --Michael From David.Mackintosh at xdroop.com Fri Jan 19 13:21:10 2007 From: David.Mackintosh at xdroop.com (David Mackintosh) Date: Fri, 19 Jan 2007 08:21:10 -0500 Subject: [et-mgmt-tools] Cobbler 0.3.6 released In-Reply-To: <45AF9C68.4070700@redhat.com> References: <45AF9C68.4070700@redhat.com> Message-ID: <20070119132110.GL27002@xdroop.com> Thanks for the upgrade. Those who are interested can find an updated cobbler_byname script which will work with the new changes at http://wiki.xdroop.com/space/RedHat/kickstart/Cobbler/cobbler_byname -- /\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 Fri Jan 19 20:29:30 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 19 Jan 2007 15:29:30 -0500 Subject: [et-mgmt-tools] Cobbler 0.3.6 released In-Reply-To: <45AF9C68.4070700@redhat.com> References: <45AF9C68.4070700@redhat.com> Message-ID: <45B12A2A.7080504@redhat.com> Michael DeHaan wrote: > The major feature for this release is support for kickstart status > tracking as mentioned earlier in the list archives. > > If you have an existing installation, after the upgrade, it will still > work absolutely fine, but to get kickstart tracking to work, you'll need > to change the --url parameter in your kickstart files to get useful > data from the "cobbler status" command. Anyhow, the kickstart URL > changes are as follows: > > before: http://server/cobbler/... > after: http://server/cobbler_track/... > > If you look at the new default kickstart files in /etc/cobbler (they > should be saved with an .rpmnew extension for upgrades), you can also > see the new TEMPLATE:: entry in the %post section. This is where > cobbler writes in the code that signals kickstart completion. Add > that too, and "cobbler status" will do a pretty good job of telling > you when machines are finished installing. > > From the changelog: > > - locking feature now enabled > - "enchant" now supports provisioning virtual images remotely when > using --is-virt=yes > - cobbler no longer restarts httpd if the config file already exists. > - "cobbler repo sync" is now an alias for "cobbler reposync" > - "cobbler list (something)" can now be invoked as "cobbler > (something) list" > - "cobbler list" just shows names of items now > - "cobbler report" is now used for showing full information output > - "list" (as well as report) are now sorted alphabetically > - basic kickstart tracking feature. requests on /var/www/cobbler get > logged to /var/log/cobbler. > > Fire away, and as usual, comments and ideas on the above are welcome. > > Upcoming ideas/improvements for Cobbler 0.3.7 / Koan 0.2.6: > -- better default kickstarts that are hard drive type/size aware > (using some good input gained from cobbler users and kickstart-list) > -- koan installing into NFS roots for Xen, possible support for LVM > partitions and hardware virt > -- ... > > Thanks to David Mackintosh for suggesting many of the usability > improvements in this release. > > > --Michael > > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools Incidentally there is some opportunity of adding remote syslogging support as well (probably by adding a small watcher/logger daemon), to complement the file access logs. I'll be looking into this for 0.3.7 also and the logging structure will be similar. It will likely allow for more fine grained status monitoring. --Michael From berrange at redhat.com Tue Jan 23 03:19:42 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 23 Jan 2007 03:19:42 +0000 Subject: [et-mgmt-tools] virtinst 0.100.0 and virt-manager 0.3.0 releases Message-ID: <20070123031942.GR7153@redhat.com> Following on from the recent libvirt 0.1.11 release, I'm pleased to announce new releases of the virtinst & virt-manager applications. The virtinst 0.100.0 release is a major re-factoring to make use of the libvirt inactive domain management APIs when provisioning guests. It also tries to clean up many of the Xen specific bits to facilitate future use with the QEMU backend of libvirt. From a usability point of view it also now displays progress information when downloading kernel & initrd and creating the filesystem images. The virt-manager 0.3.0 release brings a major functionality update, enabling of inactive domain management. This requires libvirt at least version 0.1.11 to provide implementations of inactive domain management for Xen 3.0.3 and Xen 3.0.4. With this new functionality the display will list all guests which are in the 'shutoff' state. The guest can be started with the 'Run' button in the virtual console window. The vistinst package must also be updated to at least version 0.100.0 to ensure that during provisioning of guests it uses the new inactive domain management APIs. Finally there have been a variety of minor UI fixes & enhancements such as progress bars during guest creation, reliability fixes to the virtual console and even greater coverage for translations. As of today, virtinst is now formally a part of the virt-manager project, so downloads for both virtinst & virt-manager are available from the same download page: http://virt-manager.et.redhat.com/download.html All historical release from virtinst 0.95.0 onwards are available there. In addition, to encourage / facilitate broader community development & feedback on the virtinst/virt-manager applications we have decided to designate et-mgmt-tools at redhat.com as the project primary mailing list: http://www.redhat.com/mailman/listinfo/et-mgmt-tools We welcome feedback on what additional capabilities / features people would like to see in future virtinst / virt-manager releases. As a taste of things to come, we have active developments plans for: - Secure authenticated remote management - Support for QEMU & KVM virtualization Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From mdehaan at redhat.com Tue Jan 23 16:46:01 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 23 Jan 2007 11:46:01 -0500 Subject: [et-mgmt-tools] [Cobbler] more on kickstart tracking... In-Reply-To: <45B12A2A.7080504@redhat.com> References: <45AF9C68.4070700@redhat.com> <45B12A2A.7080504@redhat.com> Message-ID: <45B63BC9.9070700@redhat.com> Hi folks, I've added some new code (and pushed the source, so get it now if you like) that does some new things with kickstart tracking, which was the major new feature in 0.3.6. Basically, I'm now saving all of the Anaconda installer activity on the remotes, so it can be viewed on the cobbler server. There is now a very small logging daemon installed (cobbler_syslogd) that keeps track of remote syslog information from provisioning machines. We log this to /var/log/cobbler/syslog/$ip, and the the file requests are logged to /var/log/cobbler/kicklog/$ip. The logging daemon is set up automatically by the RPM, and you can disable it using chkconfig if you decide you don't want it for whatever reason. In order to to take advantage of the existing feature with your existing setup, all you have to do is run "cobbler sync" once and everything will be updated automatically. Foremost, this gives one a bit better ability to diagnose failing kickstarts, because the syslog information is available remotely. Furthermoe, "cobbler status" uses data from both locations now, so it's a lot more accurate. One can see the last time any remote activity occurred, so that it is easier to detect stalled kickstarts. Anyhow, check it out, and I'll probably release this later this week... --Michael From haircut at gmail.com Tue Jan 23 23:58:26 2007 From: haircut at gmail.com (Adam Monsen) Date: Tue, 23 Jan 2007 15:58:26 -0800 Subject: [et-mgmt-tools] koan specfile suggestion: require python >= 2.4 Message-ID: <9ebd65110701231558t6f829915y5336c7429ba3b2dd@mail.gmail.com> koan appears to require a version of Python greater than 2.4. I humbly suggest correcting the corresponding specfile "Requires" line thusly. I'm happy to enter a bug report if you wish. Reference: http://www.mail-archive.com/libvir-list at redhat.com/msg00616.html -- Adam Monsen -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdehaan at redhat.com Wed Jan 24 00:01:33 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 23 Jan 2007 19:01:33 -0500 Subject: [et-mgmt-tools] koan specfile suggestion: require python >= 2.4 In-Reply-To: <9ebd65110701231558t6f829915y5336c7429ba3b2dd@mail.gmail.com> References: <9ebd65110701231558t6f829915y5336c7429ba3b2dd@mail.gmail.com> Message-ID: <45B6A1DD.9060206@redhat.com> Adam Monsen wrote: > koan appears to require a version of Python greater than 2.4. I humbly > suggest correcting the corresponding specfile "Requires" line thusly. > > I'm happy to enter a bug report if you wish. > > Reference: > http://www.mail-archive.com/libvir-list at redhat.com/msg00616.html > > -- > Adam Monsen > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools I'm not sure this is the case, as it was working on RHEL 3 very recently, and runs happily on RHEL4 and Centos 4. You might just not be rebuilding the RPM. What python-2.4ism's have you found? --Michael From berrange at redhat.com Wed Jan 24 00:08:28 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 24 Jan 2007 00:08:28 +0000 Subject: [et-mgmt-tools] koan specfile suggestion: require python >= 2.4 In-Reply-To: <9ebd65110701231558t6f829915y5336c7429ba3b2dd@mail.gmail.com> References: <9ebd65110701231558t6f829915y5336c7429ba3b2dd@mail.gmail.com> Message-ID: <20070124000827.GL19805@redhat.com> On Tue, Jan 23, 2007 at 03:58:26PM -0800, Adam Monsen wrote: > koan appears to require a version of Python greater than 2.4. I humbly > suggest correcting the corresponding specfile "Requires" line thusly. > > I'm happy to enter a bug report if you wish. > > Reference: http://www.mail-archive.com/libvir-list at redhat.com/msg00616.html That report is about libvirt-python not koan. There's no need to add a dependancy to the koan specfile to enforce a requirement of libvirt for python 2.3 - simply adding the Requires: line to the libvirt-python specfile is sufficient. Regards. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From mdehaan at redhat.com Wed Jan 24 00:17:38 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 23 Jan 2007 19:17:38 -0500 Subject: [et-mgmt-tools] koan specfile suggestion: require python >= 2.4 In-Reply-To: <20070124000827.GL19805@redhat.com> References: <9ebd65110701231558t6f829915y5336c7429ba3b2dd@mail.gmail.com> <20070124000827.GL19805@redhat.com> Message-ID: <45B6A5A2.9070007@redhat.com> Daniel P. Berrange wrote: > On Tue, Jan 23, 2007 at 03:58:26PM -0800, Adam Monsen wrote: > >> koan appears to require a version of Python greater than 2.4. I humbly >> suggest correcting the corresponding specfile "Requires" line thusly. >> >> I'm happy to enter a bug report if you wish. >> >> Reference: http://www.mail-archive.com/libvir-list at redhat.com/msg00616.html >> > > That report is about libvirt-python not koan. There's no need to add a > dependancy to the koan specfile to enforce a requirement of libvirt for > python 2.3 - simply adding the Requires: line to the libvirt-python > specfile is sufficient. > > Regards. > Dan. > Speaking of koan (if we are speaking about koan?) it doesn't even need that. Current behavior (again, to support koan on RHEL3 and places where Xen isn't installed) is to only try to import virt modules when running the virt commands, s.t. koan still works on non Xen aware platforms. If it's trying to import virt stuff when doing "--replace-self", we have issues though -- shouldn't be doing that. From haircut at gmail.com Wed Jan 24 00:05:38 2007 From: haircut at gmail.com (Adam Monsen) Date: Tue, 23 Jan 2007 16:05:38 -0800 Subject: [et-mgmt-tools] koan specfile suggestion: require python >= 2.4 In-Reply-To: <45B6A1DD.9060206@redhat.com> References: <9ebd65110701231558t6f829915y5336c7429ba3b2dd@mail.gmail.com> <45B6A1DD.9060206@redhat.com> Message-ID: <9ebd65110701231605g4510c415gd9fc1e8920f92fd3@mail.gmail.com> On 1/23/07, Michael DeHaan wrote: > > What python-2.4ism's have you found? > Just this one, also mentioned in the link in the original post: ImportError: /usr/lib/python2.3/site-packages/libvirtmod.so: undefined symbol: PyEval_ThreadsInitialized But I'm not sure it's a python 2.4 issue, just guessing based on Daniel P. Berrange's comments in his reply. -- Adam Monsen -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdehaan at redhat.com Wed Jan 24 00:55:10 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 23 Jan 2007 19:55:10 -0500 Subject: [et-mgmt-tools] Cobbler 0.3.6 released In-Reply-To: <45B12A2A.7080504@redhat.com> References: <45AF9C68.4070700@redhat.com> <45B12A2A.7080504@redhat.com> Message-ID: <45B6AE6E.8060403@redhat.com> For those of you who might have already upgraded to 0.3.6 and tried a "sync", you might have noticed I forgot mod_python as a Requires in the RPM. Do a "yum install mod_python" and you'll be good to go, this will be fixed in 0.3.7 (and is already fixed in source if you're using hg). Sorry for the excess of SPAM today :) --Michael From berrange at redhat.com Wed Jan 24 17:46:21 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 24 Jan 2007 17:46:21 +0000 Subject: [et-mgmt-tools] Supporting SuSE paravirt installs with virt-inst/virt-manager Message-ID: <20070124174621.GG3325@redhat.com> The current virt-install code for provisioning paravirtualized guests was originally written to work with Fedora / RHEL derived distros. Basically, given an NFS/HTTP/FTP install tree URL it will: 1. Fetch $INSTALL_URL/images/xen/vmlinux, save it to /var/lib/xen/images 2. Fetch $INSTALL_URL/images/xen/initrd, save it to /var/lib/xen/images 3. Boot guest pointing to these explicit kernel & ramdisk files This takes the user straight into anaconda. All very cool for Fedora / RHEL or CentOS users. Not so handy if you're trying to install paravirtualized SuSE or Debian images. Debian appears to be focused on a chroot based bootstrap approach for their guest installs - eg the install of the guest FS is done entirely from Dom0, only booting a guest once install is complete. This is not a model I want to go for in virt-install/virt-manager[1]. The good news though, is that distros in the SuSE family do support booting the regular YAST installer in a DomU, so I'm very interested in getting this working for virt-intsall. I found the following page describing the manual steps required to kick off a guest install http://www.suse.de/~kraxel/xen/suse-guest.html And have been trying to do a proof-of-concept automation of them in python. I've attached my code to this mail, but basically is goes along like this: 1. Fetch $INSTALL_URL/ls-lR.gz, save it to a temp file 2. Unzip it & scan the files looking for the latest version of the 'kernel-xen' and 'install-initrd' RPMs with matching architecture 3. Fetch $INSTALL_URL/$KERNEL_RPM saving it to a temp file 4. Fetch $INSTALL_URL/$INSTALL_INITRD_RPM saving it to a temp file 5. Use rpm2cpio & cpio to extract the /boot/vmlinuz-XXX file from the kernel RPM 6. Use rpm2cpio & cpio to extract the entire of $INSTALL_INITRD_RPM 7. Run the /usr/sbin/mkinstallinitrd script just extracted and point it to the $KERNEL_RPM file saved earlier 8. Boot guest pointing to the initrd from step 7 and kernel from step 5. So it is definitely possible to kick off paravirtualized SuSE installs, although the procss is rather long & convoluted - and the downloads take a non-trivial amount of time (20 MB for kernel RPM & 6MB for the install_initrd RPM). My main concern is that we're executing shell/perl scripts from the install_initrd RPM which we've downloaded from an arbitrary source :-( One option would be to not run the script in step 7 and install write equivalent code to build an initrd directly in the virtinst library. That would avoid the worry of running arbitrary scripts but may not be reliable long term if SuSE change the requirements for what goes in their initrds. It'd be really nice if SuSE just provided pre-built vmlinux & initrd files for installation as they already do with baremetal - but I've not found any such files on the various download sites for SuSE I've looked at. Any one have any ideas for making this process better ? Regards, Dan. [1] It requires root on Dom0 to do the chroot stuff - so guest install can in theory compromise the entire host & all guests within. Similarly you can't control resource usage & thus install will impact performance of all other guests; Finally, it has requirements for the bootstrap tools of each distro to be installed in the Dom0 -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -------------- next part -------------- #!/usr/bin/python import urlgrabber.grabber as grabber import urlgrabber.progress as progress import gzip import tempfile import os import re baseurl = "http://ftp.opensuse.org/pub/opensuse/distribution/10.2/repo/oss/" filelist="ls-lR.gz" def _copy_temp(fileobj, prefix, scratchdir): (fd, fn) = tempfile.mkstemp(prefix="virtinst-" + prefix, dir=scratchdir) block_size = 16384 try: while 1: buff = fileobj.read(block_size) if not buff: break os.write(fd, buff) finally: os.close(fd) return fn def fetch(url, prefix): data = grabber.urlopen(url, progress_obj = progress.TextMeter()) return _copy_temp(data, prefix, "/var/tmp") install_initrd = None kernel = None kernelname = "kernel-xen" print "Fetching " + baseurl + filelist tmpfn = fetch(baseurl + filelist, "filelist") print try: filelistData = gzip.GzipFile(tmpfn, mode = "r") arch = os.uname()[4] arches = [arch] if arch == "i686": arches.append("i586") arches.append("i386") kernelname = "kernel-xenpae" dir = None while 1: data = filelistData.readline() if not data: break if dir is None: for arch in arches: wantdir = "/suse/" + arch if data == "." + wantdir + ":\n": dir = wantdir break else: if data == "\n": dir = None else: if data[:5] != "total": filename = re.split("\s+", data)[8] if filename[:14] == "install-initrd": install_initrd = dir + "/" + filename elif filename[:len(kernelname)] == kernelname: kernel = dir + "/" + filename finally: os.unlink(tmpfn) kernelfn = None mkinitrdfn = None try: print "Fetching " + baseurl + kernel kernelfn = fetch(baseurl + kernel, "kernel") print print "Fetching " + baseurl + install_initrd install_initrdfn = fetch(baseurl + install_initrd, "install-initrd") print scratchfn = tempfile.mkdtemp(prefix="virtinst-scratch", dir="/var/tmp") (initrdfd, initrdfn) = tempfile.mkstemp(prefix="virtinst-initrd", dir="/var/tmp") os.close(initrdfd) os.system("cd " + scratchfn + " && " + \ "(rpm2cpio " + install_initrdfn + " | " + \ " cpio --quiet --extract --unconditional --make-directories)") os.system("cd " + scratchfn + " && " + \ "(rpm2cpio " + kernelfn + " | " + \ " cpio --quiet --extract --unconditional --make-directories '*vmlinuz*')") os.system("/usr/bin/perl " + scratchfn + "/usr/sbin/mkinstallinitrd " + \ "--libdir=" + scratchfn + "/usr/lib/install-initrd " + \ "--kernel-rpm=" + kernelfn + " " + \ initrdfn) finally: pass #if kernelfn is not None: # os.unlink(kernelfn) #if initrdfn is not None: # os.unlink(initrdfn) From benjhenrion at gmail.com Thu Jan 25 09:43:06 2007 From: benjhenrion at gmail.com (benjamin henrion) Date: Thu, 25 Jan 2007 10:43:06 +0100 Subject: [et-mgmt-tools] virt-manager Message-ID: Hello every body! I have installed Xen on fedora to try virt-manager. All is allright to install an fedora guest. But now i want to install an debian guest . And i don't find the address to have the debian medium. I'have tried this one "http://ftp2.fr.debian.org/debian/" and this one " http://ftp2.de.debian.org/debian/" but it doesn't match... I just know the Fedora medium: http://download.fedora.redhat.com/pub/fedora/linux/core/6/i386/os/ So, please i need debian medium ... Thanks ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From berrange at redhat.com Thu Jan 25 12:22:44 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 25 Jan 2007 12:22:44 +0000 Subject: [et-mgmt-tools] virt-manager In-Reply-To: References: Message-ID: <20070125122244.GC15872@redhat.com> On Thu, Jan 25, 2007 at 10:43:06AM +0100, benjamin henrion wrote: > Hello every body! > > I have installed Xen on fedora to try virt-manager. > All is allright to install an fedora guest. But now i want to install an > debian guest . > And i don't find the address to have the debian medium. I'have tried this > one "http://ftp2.fr.debian.org/debian/" and this one " > http://ftp2.de.debian.org/debian/" but it doesn't match... Unfortunately the Debian trees are not setup in a way which allows us to do paravirtualized Xen installs from virt-manager[1]. So for Debian you'll have to use full-virt instead, or run the Debian bootstrap scripts to manually create a DomU image. Dan. [1] virt-manager requires a vmlinuz & initrd file for Xen kernel which is able to boot straight into the installer. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From berrange at redhat.com Thu Jan 25 14:25:03 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 25 Jan 2007 14:25:03 +0000 Subject: [et-mgmt-tools] CPU flags for fullvirt on Itanium ? Message-ID: <20070125142503.GD29493@redhat.com> Currently virt-install / virt-manager look for two things when determining if a machine supports full-virtualization: a) The word 'hvm' in /sys/hypervisor/properties/capabilities b) The flag 'vmx' or 'svm' in /proc/cpuinfo The former is the primary check used in virt-install/virtmanager. The latter is used in virt-manager if the former fails so we can tell the user 'Your CPU supports full virt, but your BIOS has disabled it' With KVM support we're going to have to use the latter as the primary check since I don't believe KVM gives us better info based on the MSRR. Anyway back to $SUBJECT - I believe either, or both of these checks may well be wrong on Itanium, but have no full-virt ia64 box to test on. So can anyone confirm what capability is shown by Xen on ia64, and/or what CPU flags the OS will present for the VTi capability ? Simply emailing me the '/sys/hypervisor/properties/capabilities' and '/proc/cpuinfo' files would be best, so I can add them to a unit test suite. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From sdodson at redhat.com Thu Jan 25 15:16:51 2007 From: sdodson at redhat.com (Scott Dodson) Date: Thu, 25 Jan 2007 10:16:51 -0500 Subject: [et-mgmt-tools] CPU flags for fullvirt on Itanium ? In-Reply-To: <20070125142503.GD29493@redhat.com> References: <20070125142503.GD29493@redhat.com> Message-ID: <1169738211.3610.11.camel@dhcp231-117.rdu.redhat.com> On Thu, 2007-01-25 at 14:25 +0000, Daniel P. Berrange wrote: > Currently virt-install / virt-manager look for two things when determining > if a machine supports full-virtualization: > > a) The word 'hvm' in /sys/hypervisor/properties/capabilities > b) The flag 'vmx' or 'svm' in /proc/cpuinfo Should these cpu flags show up on systems running older kernels such as a RHEL4, 3, or 2.1 kernel? -- Scott Dodson w:919.754.4167 Red Hat, c:919.302.0997 GSS Lab Manager From berrange at redhat.com Thu Jan 25 15:20:27 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 25 Jan 2007 15:20:27 +0000 Subject: [et-mgmt-tools] CPU flags for fullvirt on Itanium ? In-Reply-To: <1169738211.3610.11.camel@dhcp231-117.rdu.redhat.com> References: <20070125142503.GD29493@redhat.com> <1169738211.3610.11.camel@dhcp231-117.rdu.redhat.com> Message-ID: <20070125152027.GE29493@redhat.com> On Thu, Jan 25, 2007 at 10:16:51AM -0500, Scott Dodson wrote: > On Thu, 2007-01-25 at 14:25 +0000, Daniel P. Berrange wrote: > > Currently virt-install / virt-manager look for two things when determining > > if a machine supports full-virtualization: > > > > a) The word 'hvm' in /sys/hypervisor/properties/capabilities > > b) The flag 'vmx' or 'svm' in /proc/cpuinfo > > Should these cpu flags show up on systems running older kernels such as > a RHEL4, 3, or 2.1 kernel? The CPU flags might, if you had new enough CPUs & kernel, but getting data from a Xen kernel would be preferred - the HV capabilities require it in fact. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From haircut at gmail.com Thu Jan 25 17:25:11 2007 From: haircut at gmail.com (Adam Monsen) Date: Thu, 25 Jan 2007 09:25:11 -0800 Subject: [et-mgmt-tools] koan specfile suggestion: require python >= 2.4 In-Reply-To: <45B6A5A2.9070007@redhat.com> References: <9ebd65110701231558t6f829915y5336c7429ba3b2dd@mail.gmail.com> <20070124000827.GL19805@redhat.com> <45B6A5A2.9070007@redhat.com> Message-ID: <9ebd65110701250925u72f57455lecd4820c51f4ec4@mail.gmail.com> On 1/23/07, Michael DeHaan wrote: [...] > > That report is about libvirt-python not koan. There's no need to add a > > dependancy to the koan specfile to enforce a requirement of libvirt for > > python 2.3 - simply adding the Requires: line to the libvirt-python > > specfile is sufficient. > > > > Regards. > > Dan. > > > Speaking of koan (if we are speaking about koan?) it doesn't even need > that. Current behavior (again, to support koan on RHEL3 and places where > Xen isn't installed) is to only try to import virt modules when running > the virt commands, s.t. koan still works on non Xen aware platforms. If > it's trying to import virt stuff when doing "--replace-self", we have > issues though -- shouldn't be doing that. > Here's the error message I saw, in case it helps. If not, please disregard. Sorry, I should've had this in the original post. # koan --virt --profile=c2profile --server=build01 - processing profile: c2profile - fetching configuration for profile: c2profile - url=http://build01/cobbler/profiles/c2profile - {'kickstart': 'http://build01/cobbler_track/kickstarts/c2profile/ks.cfg', 'name': 'c2profile', 'virt_ram': 512, 'repos': '', 'kernel_options': 'lang ksdevice=eth0 text devfs=nomount ramdisk_size=16438', 'virt_name': 'virtguest', 'virt_file_size': 5, 'distro': 'c2distro', 'virt_paravirt': 'True', 'ks_meta': ''} - fetching configuration for distro: c2distro - url=http://build01/cobbler/distros/c2distro - {'kernel': '/boot/vmlinuz-2.6-xen', 'ks_meta': '', 'kernel_options': 'lang ksdevice=eth0 text devfs=nomount ramdisk_size=16438', 'initrd': '/boot/initrd-xen-3.0.3-0.img', 'arch': 'x86', 'name': 'c2distro'} - downloading initrd initrd-xen-3.0.3-0.img to /tmp/initrd-xen-3.0.3-0.img - url=http://build01/cobbler/images/c2distro/initrd-xen-3.0.3-0.img - downloading kernel vmlinuz-2.6-xen to /tmp/vmlinuz-2.6-xen - url=http://build01/cobbler/images/c2distro/vmlinuz-2.6-xen - kernel saved = /tmp/vmlinuz-2.6-xen - initrd saved = /tmp/initrd-xen-3.0.3-0.img Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/koan/app.py", line 97, in main k.run() File "/usr/lib/python2.3/site-packages/koan/app.py", line 155, in run self.do_virt() File "/usr/lib/python2.3/site-packages/koan/app.py", line 296, in do_virt return self.do_net_install("/tmp",after_download) File "/usr/lib/python2.3/site-packages/koan/app.py", line 254, in do_net_install after_download(self, distro_data, profile_data) File "/usr/lib/python2.3/site-packages/koan/app.py", line 295, in after_download self.do_virt_net_install(profile_data, distro_data) File "/usr/lib/python2.3/site-packages/koan/app.py", line 595, in do_virt_net_install extra=kextra File "/usr/lib/python2.3/site-packages/koan/virtcreate.py", line 173, in start_paravirt_install import libvirt File "/usr/lib/python2.3/site-packages/libvirt.py", line 7, in ? import libvirtmod ImportError: /usr/lib/python2.3/site-packages/libvirtmod.so: undefined symbol: PyEval_ThreadsInitialized -- Adam Monsen -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdehaan at redhat.com Thu Jan 25 18:02:35 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 25 Jan 2007 13:02:35 -0500 Subject: [et-mgmt-tools] koan specfile suggestion: require python >= 2.4 In-Reply-To: <9ebd65110701250925u72f57455lecd4820c51f4ec4@mail.gmail.com> References: <9ebd65110701231558t6f829915y5336c7429ba3b2dd@mail.gmail.com> <20070124000827.GL19805@redhat.com> <45B6A5A2.9070007@redhat.com> <9ebd65110701250925u72f57455lecd4820c51f4ec4@mail.gmail.com> Message-ID: <45B8F0BB.4010609@redhat.com> Adam Monsen wrote: > On 1/23/07, *Michael DeHaan* > wrote: > [...] > > > That report is about libvirt-python not koan. There's no need to > add a > > dependancy to the koan specfile to enforce a requirement of > libvirt for > > python 2.3 - simply adding the Requires: line to the libvirt-python > > specfile is sufficient. > > > > Regards. > > Dan. > > > Speaking of koan (if we are speaking about koan?) it doesn't even need > that. Current behavior (again, to support koan on RHEL3 and places > where > Xen isn't installed) is to only try to import virt modules when > running > the virt commands, s.t. koan still works on non Xen aware > platforms. If > it's trying to import virt stuff when doing "--replace-self", we have > issues though -- shouldn't be doing that. > > > > Here's the error message I saw, in case it helps. If not, please > disregard. Sorry, I should've had this in the original post. > ... snip ... > File "/usr/lib/python2.3/site-packages/koan/virtcreate.py", line > 173, in start_paravirt_install > import libvirt > File "/usr/lib/python2.3/site-packages/libvirt.py", line 7, in ? > import libvirtmod > ImportError: /usr/lib/python2.3/site-packages/libvirtmod.so: undefined > symbol: PyEval_ThreadsInitialized > > ... snip ... > > -- > Adam Monsen I'm guessing what happened is that libvirt wants python 2.4 now and didn't earlier (Dan?). Koan does a lazy load of libvirt (only when virt commands are requested), so on 2.3 systems, you are free to use --replace-self but virt won't work anymore. Basically I don't want to require 2.4 in the specfile as that breaks koan for a lot of legitimate non-virt uses. It does sound like koan needs to print more helpful error messages about virt not working when you have only python 2.3 though. Anyhow, the spec file won't be edited, but the error messages can be worked on. "koan --replace-self" is used on a lot of Python 2.3 systems and that needs to continue to work everywhere, even on RHEL3 :) Hopefully that makes sense. --Michael From mdehaan at redhat.com Thu Jan 25 22:44:05 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 25 Jan 2007 17:44:05 -0500 Subject: [et-mgmt-tools] [Cobbler 0.3.6] mod_python piece of kickstart tracking busted for RHEL4U4, RHEL/Centos users please read. Message-ID: <45B932B5.8020503@redhat.com> Hi folks, As I've just recently found out during testing, the kickstart tracking in 0.3.6 apparently is incompatible with the Apache in RHEL4 U4. The new stuff in 0.3.7 to watch syslog is fine though, so I'll work on getting a fix out in 0.3.7 shortly. Basically I'm going to look at /etc/redhat-release to decide how much kickstart tracking to install based on what the server can support. Don't worry, you won't need to figure this out for yourselves :) After a "cobbler sync", the workaround (for now) is to just edit /etc/httpd.conf/conf.d/cobbler.conf FROM # # This configuration file allows 'cobbler' boot info # to be accessed over HTTP in addition to PXE. AliasMatch ^/cobbler(/.*)?$ "/var/www/cobbler$1" AliasMatch ^/cobbler_track(/.*)?$ "/var/www/cobbler$1" Options Indexes FollowSymLinks AllowOverride None Order allow,deny Allow from all AddHandler mod_python .py PythonOutputFilter watcher WATCHER AddOutputFilter WATCHER .rpm AddOutputFilter WATCHER .xml AddOutputFilter WATCHER initrd.img AddOutputFilter WATCHER vmlinuz AddOutputFilter WATCHER .py PythonDebug On to # # This configuration file allows 'cobbler' boot info # to be accessed over HTTP in addition to PXE. AliasMatch ^/cobbler(/.*)?$ "/var/www/cobbler$1" AliasMatch ^/cobbler_track(/.*)?$ "/var/www/cobbler$1" Options Indexes FollowSymLinks AllowOverride None Order allow,deny Allow from all Not doing so may keep some files, such as initrd.img files, from being downloaded in their original (uncorrupted) state. Thanks! This will be fixed very soon. --Michael From mdehaan at redhat.com Thu Jan 25 23:55:05 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 25 Jan 2007 18:55:05 -0500 Subject: [et-mgmt-tools] [Cobbler 0.3.6] mod_python piece of kickstart tracking busted for RHEL4U4, RHEL/Centos users please read. In-Reply-To: <45B932B5.8020503@redhat.com> References: <45B932B5.8020503@redhat.com> Message-ID: <45B94359.8000606@redhat.com> Michael DeHaan wrote: > Hi folks, > > As I've just recently found out during testing, the kickstart tracking > in 0.3.6 apparently is incompatible with the Apache in RHEL4 U4. ... This is now fixed, and I've already uploaded 0.3.8 to et.redhat.com and pushed it out to the mirrors. If you have 0.3.6 installed on RHEL4 or Centos 4, just delete "/etc/httpd/conf.d/cobbler.conf" and re-run "cobbler sync" after the upgrade, and cobbler will take care of it. Hopefully no one is too confused, if so, ask me. Also, everyone will probably want to run a "cobbler sync" after the upgrade to get the new syslog parameters added to the install kernels automatically. This will allow finer grained results from kickstart tracking, which is definitely a Good Thing (TM). If you don't sync, nothing bad will happen, but you just won't get the improved kickstart tracking/logging until you do. --Michael From mdehaan at redhat.com Fri Jan 26 00:06:28 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 25 Jan 2007 19:06:28 -0500 Subject: [et-mgmt-tools] [Cobbler 0.3.6] mod_python piece of kickstart tracking busted for RHEL4U4, RHEL/Centos users please read. In-Reply-To: <45B94359.8000606@redhat.com> References: <45B932B5.8020503@redhat.com> <45B94359.8000606@redhat.com> Message-ID: <45B94604.5040103@redhat.com> Michael DeHaan wrote: > Michael DeHaan wrote: >> Hi folks, >> >> As I've just recently found out during testing, the kickstart >> tracking in 0.3.6 apparently is incompatible with the Apache in RHEL4 >> U4. > > ... > > This is now fixed, and I've already uploaded 0.3.8 to et.redhat.com > and pushed it out to the mirrors. > If you have 0.3.6 installed on RHEL4 or Centos 4, just delete > "/etc/httpd/conf.d/cobbler.conf" and re-run "cobbler sync" after the > upgrade, and cobbler will take care of it. > Hopefully no one is too confused, if so, ask me. > Also, everyone will probably want to run a "cobbler sync" after the > upgrade to get the new syslog parameters added to the install kernels > automatically. This will allow finer grained results from kickstart > tracking, which is definitely a Good Thing (TM). If you don't sync, > nothing bad will happen, but you just won't get the improved kickstart > tracking/logging until you do. > > --Michael > > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools Also, after upgrade, the syslog watcher daemon (the thing that enables the spiffy new kickstart status commands) won't be running initially, so just "/sbin/service cobblersyslogd start" to engage that. Last email today, I promise. Maybe :) --Michael From smooge at gmail.com Fri Jan 26 04:52:26 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 25 Jan 2007 21:52:26 -0700 Subject: [et-mgmt-tools] Starting from scratch... where does one start. Message-ID: <80d7e4090701252052i67e202d4v40328b03cccef7b5@mail.gmail.com> So I am wanting to play with the various et tools with our RHEL systems (spanning from 2.1 to 4). I can see that cobbler would be used to help provision systems from a PXE boot line, and I would like to be able to use prm and cft to 'kickstart' our automated configuration environment... but I would like to get an idea of what the developers see as how these 'should' be put together before I go down a lot of blind alleys. So if someone is starting from scratch in building an enterprise environment.. where to begin :). -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From dlutter at redhat.com Fri Jan 26 17:57:44 2007 From: dlutter at redhat.com (David Lutterkort) Date: Fri, 26 Jan 2007 17:57:44 +0000 Subject: [et-mgmt-tools] Starting from scratch... where does one start. In-Reply-To: <80d7e4090701252052i67e202d4v40328b03cccef7b5@mail.gmail.com> References: <80d7e4090701252052i67e202d4v40328b03cccef7b5@mail.gmail.com> Message-ID: <1169834264.3445.240.camel@localhost.localdomain> On Thu, 2007-01-25 at 21:52 -0700, Stephen John Smoogen wrote: > So I am wanting to play with the various et tools with our RHEL > systems (spanning from 2.1 to 4). I can see that cobbler would be used > to help provision systems from a PXE boot line, and I would like to be > able to use prm and cft to 'kickstart' our automated configuration > environment... but I would like to get an idea of what the developers > see as how these 'should' be put together before I go down a lot of > blind alleys. So if someone is starting from scratch in building an > enterprise environment.. where to begin :). That's a very good question, and we haven't really expressed how this wil all fit together. I think the two things you want to familiarize yourself is (1) cobbler and (2) puppet; which one you want to start using first depends a little on what you see as your most urgent need: provisioning or getting a handle on config management. Eventually, you'd want to run both, probably on the same machine, and kickstart your boxes into a basic setup and have puppet give it a 'persona' (I attach a sample kickstart file that I use to kickstart my fc6 boxes that way; it'll also work with rhel5, but with older releases you need to jump through a couple of hoops to install puppet from FE in %post) Cft and prm are both a little rough still; prm (or the larger question of distributing config bits) needs some love, especially in the context of virtual appliances. I am in the process of defining best practices around organizing your config server (discussions on the puppet-users list) to make distribution cleaner and easier. You should be able to use cft by itself right now; it's at a very early stage, but already pretty useful for simple config tweaks. I would love to hear more about your ideas/expectations/experiences creating an infrastructure with these tools. And of course any questions you have. David -------------- next part -------------- # DomU kickstart with puppet install # Installs 147 packages / 590MB # Tested with FC6 # The machine running the puppetmaster must be called 'puppet' install reboot url --url URL_TO_INSTALL_TREE repo --name=extras --baseurl=URL_TO_EXTRAS_REPO lang en_US.UTF-8 keyboard us xconfig --driver "fbdev" --resolution 800x600 --depth 24 network --device eth0 --bootproto dhcp rootpw --iscrypted YOUR_ROOT_PASSWD_HERE firewall --enabled --port=22:tcp authconfig --enableshadow --enablemd5 selinux --enforcing timezone --utc America/Los_Angeles bootloader --location=mbr --driveorder=xvda --append="rhgb quiet" clearpart --all --initlabel --drives=xvda part /boot --fstype ext3 --size=100 --ondisk=xvda part pv.2 --size=0 --grow --ondisk=xvda volgroup domu --pesize=32768 pv.2 logvol / --fstype ext3 --name=lv00 --vgname=domu --size=1024 --grow logvol swap --fstype swap --name=lv01 --vgname=domu --size=272 --grow --maxsize=544 %packages --nobase crontabs dhclient dhcpv6_client nfs-utils openssh-clients openssh-server yum puppet %post --nochroot exec > /mnt/sysimage/root/post-nochroot.txt 2>&1 test -f /tmp/netinfo && cp /tmp/netinfo /mnt/sysimage/tmp/ %post exec > /root/post.txt 2>&1 /sbin/chkconfig --level 345 puppet on # Figure out the FQDN if [ -f /tmp/netinfo ] ; then FQDN=`(source /tmp/netinfo; [ -n "$DOMAIN" ] && echo $HOSTNAME.$DOMAIN || echo $HOSTNAME)` hostname $FQDN /usr/sbin/puppetd -o -v --waitforcert 600 fi