From clalance at redhat.com Mon Mar 3 21:07:50 2008 From: clalance at redhat.com (Chris Lalancette) Date: Mon, 03 Mar 2008 16:07:50 -0500 Subject: [et-mgmt-tools] [PATCH]: Disable accelerator keys when "grabbed" Message-ID: <47CC68A6.5020804@redhat.com> Hello, Currently in virt-viewer, when you type either Alt-f, Alt-s, or Alt-h, the accelerator for the menu on top kicks in. That's fine, except that when the pointer is grabbed, this is really not what the user expects; the user is expecting that key combination to go through to the guest. The attached patch does this; basically it disables the accelerators when the pointer is grabbed, and re-enabled them when the pointer is ungrabbed. Signed-off-by: Chris Lalancette -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-viewer-accelerator-disable.patch Type: text/x-patch Size: 3062 bytes Desc: not available URL: From clalance at redhat.com Mon Mar 3 21:07:57 2008 From: clalance at redhat.com (Chris Lalancette) Date: Mon, 03 Mar 2008 16:07:57 -0500 Subject: [et-mgmt-tools] [PATCH]: Make autogen.sh print out the right string at the end Message-ID: <47CC68AD.3060909@redhat.com> Trivial fix for a simple cut-n-paste error, so that autogen.sh says "Now type 'make' to compile virt-viewer". Signed-off-by: Chris Lalancette -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-viewer-autogen.patch Type: text/x-patch Size: 320 bytes Desc: not available URL: From mdehaan at redhat.com Mon Mar 3 21:06:48 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 03 Mar 2008 16:06:48 -0500 Subject: [et-mgmt-tools] FreeLinuxPC.org and a neat Cobbler trick/idea (WIP) Message-ID: <47CC6868.1040104@redhat.com> The UCLUG guys at FreeLinuxPC.org have a warehouse of 600 computers they are setting up to give away to kids that need them. Before this happens, they need to be securely erased. Now, we have instructions for using Cobbler to PXE DBAN (a secure erasure tool), and they could set up one network for erasure and another network for installation, but, at least theoretically, is it possible for Cobbler to install one OS (DBAN) and then install another right afterwards, using the Cobbler API to switch between them at reboot, so you don't have to move machines between networks or issue any cobbler commands at all? The theory is yes, though we're figuring this out. This is a fun problem, a good cause, and a chance to abuse the Cobbler API some. Here goes... Scenario: -- You have a bunch of new machines come in off trucks -- You need Cobbler records for each of them (per MAC), but do not want to record them manually -- Each new machine should be securely erased. -- After the machine is erased, it should get a new OS. -- once the final OS is installed, the system should not be PXE'd again Proposed Solution: -- First create two cobbler scripts using the Cobbler XMLRPC Read-Write API (to be provided later...stay tuned) -- add_system.cgi, which detects the MAC from HTTP vars and adds it to cobbler -- change_profile.cgi, which detects the MAC and takes a "profile" parameter, sets the system record for the MAC to the given profile -- Create a cobbler profile called "default" -- the default profile has "kssendmac" in the kernel args so the scripts can find the MAC -- wget http://cobbler.example.org/cgi-bin/add_system.cgi -- second wget to http://cobbler.example.org/cgi-bin/change_profile.cgi?profile=erase -- it does not call nopxe.cgi -- Create a second cobbler profile called "erase" -- modified DBAN initrd -- it first makes a wget to http://cobbler.example.org/cgi-bin/change_profile?profile=productionOS -- then it erases the machine and rebo -- it does not call nopxe.cgi -- "productionOS" is the final profile. -- it calls nopxe.cgi in post (already available in Cobbler) to stop the boot loop chain So basically, with a couple of scripts written in Cobbler API, we can boot a system three times, chaining what gets installed each time. I think the scripts above are interesting enough to be used on a wider basis -- particularly the idea of making sure all MACs get a cobbler system record. The "change profile" scripts are a bit of a security problem, but not in this case as it's a limited use network. Either way, I plan on polishing these up a bit, explaining them further on the Wiki, and making them more generally useful. --Michael From mdehaan at redhat.com Mon Mar 3 21:55:52 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 03 Mar 2008 16:55:52 -0500 Subject: [et-mgmt-tools] FreeLinuxPC.org and a neat Cobbler trick/idea (WIP) In-Reply-To: <47CC6868.1040104@redhat.com> References: <47CC6868.1040104@redhat.com> Message-ID: <47CC73E8.4020004@redhat.com> Michael DeHaan wrote: > The UCLUG guys at FreeLinuxPC.org have a warehouse of 600 computers > they are setting up to give away to kids that need them. > > Before this happens, they need to be securely erased. Now, we have > instructions for using Cobbler to PXE DBAN (a secure erasure > tool), and they could set up one network for erasure and another > network for installation, but, at least theoretically, is it possible > for Cobbler > to install one OS (DBAN) and then install another right afterwards, > using the Cobbler API to switch between them at reboot, so you don't have > to move machines between networks or issue any cobbler commands at > all? The theory is yes, though we're figuring this out. > > This is a fun problem, a good cause, and a chance to abuse the Cobbler > API some. Here goes... > > Scenario: > -- You have a bunch of new machines come in off trucks > -- You need Cobbler records for each of them (per MAC), but do not > want to record them manually > -- Each new machine should be securely erased. > -- After the machine is erased, it should get a new OS. > -- once the final OS is installed, the system should not be PXE'd > again > > Proposed Solution: > -- First create two cobbler scripts using the Cobbler XMLRPC > Read-Write API (to be provided later...stay tuned) > -- add_system.cgi, which detects the MAC from HTTP vars and adds it > to cobbler > -- change_profile.cgi, which detects the MAC and takes a "profile" > parameter, sets the system record for the MAC to the given profile > -- Create a cobbler profile called "default" > -- the default profile has "kssendmac" in the kernel args so the > scripts can find the MAC > -- wget http://cobbler.example.org/cgi-bin/add_system.cgi > -- second wget to > http://cobbler.example.org/cgi-bin/change_profile.cgi?profile=erase > -- it does not call nopxe.cgi > -- Create a second cobbler profile called "erase" > -- modified DBAN initrd > -- it first makes a wget to > http://cobbler.example.org/cgi-bin/change_profile?profile=productionOS > -- then it erases the machine and rebo > -- it does not call nopxe.cgi > -- "productionOS" is the final profile. > -- it calls nopxe.cgi in post (already available in Cobbler) to > stop the boot loop chain > > So basically, with a couple of scripts written in Cobbler API, we can > boot a system three times, chaining what gets installed each > time. > > I think the scripts above are interesting enough to be used on a wider > basis -- particularly the idea of making sure all MACs get a cobbler > system > record. The "change profile" scripts are a bit of a security > problem, but not in this case as it's a limited use network. Either > way, I plan on polishing these up a bit, explaining them further on > the Wiki, and making them more generally useful. > > --Michael > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools I have register_mac.cgi and change_profile.cgi now pushed to the master branch of git in the "scripts" directory. They are not installed by the RPM by default for security reasons, it's up to you as to how wide open your provisioning network should be. The next plan is to make new settings in the settings file for "allow_cgi_mac_registration" and "allow_cgi_profile_change" (default to off) so we can in fact ship these scripts and they will no longer need the XMLRPC_RW api. Currently register_mac.cgi will create a system record named after the mac (ex: AA_BB_CC_DD_EE_FF -- just like old style Cobbler) if there is no system anywhere in the Cobbler database with the given MAC. If there is a record, it will not overwrite or change it. Currently change_profile.cgi will change the profile matching the IP and/or MAC of the requestor (if one exists) to the profile requested, but will not make any changes if it is not found. This work will be done on the devel branch for Cobbler 0.9.X. Wiki docs TBD after more testing and cleanup there. --Michael From mdehaan at redhat.com Mon Mar 3 23:26:57 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 03 Mar 2008 18:26:57 -0500 Subject: [et-mgmt-tools] Koan Does VMware (it seems to work here, testing welcome) Message-ID: <47CC8941.501@redhat.com> Read about how to set it up here. https://fedorahosted.org/cobbler/wiki/KoanDoesVmware Having Cobbler managing your PXE infrastructure is a requirement since this a hybrid install method -- some parameters are pulled from Cobbler over XMLRPC, others are pulled from PXE (which we expect is Cobbler). VMware can not be supported to the same level as the libvirt backed offerings, but this looks pretty good, and I welcome more testing and feature contributions from heavy users of VMware. I've only tested this with the free VMware server. --Michael From Hua.Zhang at Sun.COM Tue Mar 4 13:55:26 2008 From: Hua.Zhang at Sun.COM (Henry Zhang) Date: Tue, 04 Mar 2008 21:55:26 +0800 Subject: [et-mgmt-tools] [Patch] delete button disable/available when Run/Shutdown a guest In-Reply-To: <20080301170021.BCD81618CA2@hormel.redhat.com> References: <20080301170021.BCD81618CA2@hormel.redhat.com> Message-ID: <47CD54CE.3000702@sun.com> Hi there, Please help to review this little patch. When you shutdown a guest in virt-manager, the Delete button status don't change, you have to click some other guest, then click back to this guest, and Delete button change to available. Meanwhile, when you Run a stopped guest, the Delete button also don't change to disable automatically... So add the attached patch for this problem. Thanks, Henry -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-manager-06-delete-button.diff Type: text/x-patch Size: 730 bytes Desc: not available URL: From crobinso at redhat.com Tue Mar 4 14:41:56 2008 From: crobinso at redhat.com (Cole Robinson) Date: Tue, 04 Mar 2008 09:41:56 -0500 Subject: [et-mgmt-tools] [Patch] delete button disable/available when Run/Shutdown a guest In-Reply-To: <47CD54CE.3000702@sun.com> References: <20080301170021.BCD81618CA2@hormel.redhat.com> <47CD54CE.3000702@sun.com> Message-ID: <47CD5FB4.6010605@redhat.com> Henry Zhang wrote: > Hi there, > > Please help to review this little patch. > > When you shutdown a guest in virt-manager, the Delete button status > don't change, you have to click some other guest, then click back to > this guest, and Delete button change to available. > Meanwhile, when you Run a stopped guest, the Delete button also don't > change to disable automatically... > > So add the attached patch for this problem. > > > Thanks, > Henry > > Hi, This has actually already been fixed upstream: http://hg.et.redhat.com/virt/applications/virt-manager--devel?cs=dc9c723e13ff Things can move pretty fast so its always good to make sure you have the latest checkout before submitting a patch. Thanks, Cole From berrange at redhat.com Tue Mar 4 14:55:51 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 4 Mar 2008 14:55:51 +0000 Subject: [et-mgmt-tools] [PATCH] fix typos for virtinst In-Reply-To: <200802290604.m1T64GFU029480@fjmscan502.ms.jp.fujitsu.com> References: <200802290604.m1T64GFU029480@fjmscan502.ms.jp.fujitsu.com> Message-ID: <20080304145551.GB6713@redhat.com> On Fri, Feb 29, 2008 at 03:04:15PM +0900, Atsushi SAKAI wrote: > Hi, > > It fix typos. > Before applying, ImageFetcher.py patch effects po file. > Please care. > > man/en/virt-install.1 | 2 +- > virtinst/ImageFetcher.py | 2 +- > virtinst/OSDistro.py | 2 +- > virtinst/util.py | 2 +- > 4 files changed, 4 insertions(+), 4 deletions(-) I've applied this change, and also subsequently re-generated the .pot file to contain latest translatable strings from the source. 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 Hua.Zhang at Sun.COM Tue Mar 4 15:18:15 2008 From: Hua.Zhang at Sun.COM (Henry Zhang) Date: Tue, 04 Mar 2008 23:18:15 +0800 Subject: [et-mgmt-tools] [Patch] delete button disable/available when Run/Shutdown a guest In-Reply-To: <47CD5FB4.6010605@redhat.com> References: <20080301170021.BCD81618CA2@hormel.redhat.com> <47CD54CE.3000702@sun.com> <47CD5FB4.6010605@redhat.com> Message-ID: <47CD6837.40706@sun.com> Hi, Sure the change is so fast.... So I just noticed another problem, in virt-manager, most of GtkEntry widget can't recognize Enter, for example when create a guest, after input some characters for system name, then with Enter, it can't go forward to next step, you have to click Forward button. I think we should make the text entry sensitive to Enter. Same problem occur when try to input password for access VNC viewer... Is there a patch ready for this problem? Thanks, Henry Cole Robinson ??: > Henry Zhang wrote: >> Hi there, >> >> Please help to review this little patch. >> >> When you shutdown a guest in virt-manager, the Delete button status >> don't change, you have to click some other guest, then click back to >> this guest, and Delete button change to available. >> Meanwhile, when you Run a stopped guest, the Delete button also don't >> change to disable automatically... >> >> So add the attached patch for this problem. >> >> >> Thanks, >> Henry >> >> > > Hi, > > This has actually already been fixed upstream: > > http://hg.et.redhat.com/virt/applications/virt-manager--devel?cs=dc9c723e13ff > > Things can move pretty fast so its always good to make sure you have > the latest checkout before submitting a patch. > > Thanks, > Cole > From rjones at redhat.com Tue Mar 4 16:06:13 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 4 Mar 2008 16:06:13 +0000 Subject: [et-mgmt-tools] Re: [Libvir] a couple of questions -Newbie In-Reply-To: <47CD7252.6090902@gmail.com> References: <47CC3FED.9060200@gmail.com> <20080303221247.GP32279@amd.home.annexia.org> <47CD7252.6090902@gmail.com> Message-ID: <20080304160613.GA10653@amd.home.annexia.org> On Tue, Mar 04, 2008 at 09:01:22AM -0700, Spencer Parker wrote: > Now when I run virt-top with the script option it just hangs...how long > till it dies? Or is there a way to daemonize it? Which version of virt-top is this? Script mode is designed to run forever. If used in conjunction with --csv then you'll get an ever longer CSV file. But you also add either '-n ' or '--end-time